تصور کنید یک برنامهنویس یا دانشجویی است که برای مدیریت ددلاینهایش به هوش مصنوعی اعتماد میکند، اما مدل با اطمینان کامل، تاریخی را اختراع میکند که در متن وجود ندارد. این «دروغهای مطمئن» میتوانند کل تقویم کاری شما را به هم بریزند، مگر اینکه یک لایه تایید سختگیرانه را به سیستم اضافه کنید. در حالی که مدلهای زبانی بزرگ (LLM) اغلب شکافهای اطلاعاتی را با توهمات متقاعدکننده پر میکنند — مثلاً اختراع یک ماه یا ساعت خاص در حالی که منبع فقط به روز هفته اشاره کرده است — یک اسکریپت پایتون میتواند بهعنوان یک «کمربند ایمنی» برای دادههای استخراجشده توسط هوش مصنوعی عمل کند. با رد کردن هر تاریخی که بهعنوان یک بازه متوالی از کاراکترها در متن منبع ظاهر نشده باشد، این سازوکار مانع از نفوذ این نادقیقها میشود.
بسیاری از توسعهدهندگان در حال حاضر به مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — اعتماد میکنند تا تاریخها را مستقیماً استخراج کند. اما طبق گزارشهای فنی، این رویکرد منجر به «دروغهای مطمئن» میشود. برای مثال، یک مدل ممکن است عبارت «روز ۱۸ام» را ببیند و بهطور خودکار ماه و سال جاری را به آن بچسباند، یا یک زمان پیشفرض مانند ۲۳:۵۹ را اضافه کند، حتی اگر متن هرگز به آنها اشاره نکرده باشد. این وضعیت یک «شکست خاموش» ایجاد میکند که در آن کاربر به یک ورودی تقویم اعتماد میکند که در واقع اساساً ساختگی است.
زمینه: لحظهی کتابخانه
نیاز به این ابزار از یک شکست خاص در سهشنبه گذشته در طبقه سوم کتابخانه کیلام (Killam) نشأت گرفت. یک دانشجوی علوم کامپیوتر در هالیفاکس که چهار درس و دوازده مورد از بهاصطلاح ددلاینها را مدیریت میکرد، متوجه شد که وقتی یک جمله ساده — «لطفاً تکلیف ۲ را قبل از آزمایشگاه روز ۱۸ام ارسال کنید» — را در یک جعبه چت قرار میدهد، نتیجه یک برچسب زمانی مودبانه اما اختراعی است: 2026-09-18T23:59:00.
در متن منبع، نه ماه سپتامبر ذکر شده بود و نه ساعت ۲۳:۵۹. مدل این جای خالی را با اطمینان پر کرد؛ درست مثل همکلاسیای که در یک کوییز گروهی، با چهرهای جدی جای خالیها را پر میکند. برنامهریز شخصی این دانشجو تنها زمانی مفید است که دست از دروغ گفتن بردارد. این همان خطر «حلقههای عاملمحور» (Agentic Loops) است؛ اگر اولین فراخوانی یک روز را اختراع کند، دومی یک یادآور رزرو میکند و سومی ایمیلی به یک گروه چت میزند، خطا فوراً منتشر میشود. بخش بزرگی از این پشته (Stack) در واقع صرفاً یک دستور if-statement است که یک کت بلند پوشیده تا شبیه به هوش مصنوعی به نظر برسد.
زمینه: پرسش یادگیری
این پروژه بهطور عمدی بهگونهای طراحی شد که پرسش یادگیری آن محدود بماند. پرسش اصلی این است: با داشتن یک متن خام از تکلیف و یک تاریخ ISO کاندید، آیا این کاندید در متن ظاهر شده است، یا چیزی ماه، سال یا ساعت را حدس زده است؟ اگر برنامه نتواند به کاراکترهای دقیق اشاره کند، تاریخ را نمینویسد.
با تکیه بر نیاز به هوش مصنوعی مستند (Grounded AI)، این رویکرد اعتماد را از استدلال مدل به یک بررسی سختگیرانه تطبیق کاراکترها منتقل میکند. در واقع، با LLM نه بهعنوان منبع حقیقت، بلکه بهعنوان پیشنهاددهندهی کاندیدهایی برخورد میشود که باید در برابر رشته متنی خام تایید شوند. هدف، ساخت پارسری است که یا یک ددلاین مستند را برگرداند و یا یک رد ساختاریافته که دلیل شکست را نام میبرد.
سازوکار بررسی بازه (Span Check)
منطق اصلی بر یک فرآیند تجزیه دو مرحلهای استوار است. ابتدا، سیستم با استفاده از عبارتهای منظم (Regular Expressions) بهدنبال تاریخهای با فرمت ISO (YYYY-MM-DD) میگردد. اسکریپت از کد ISO_DATE = re.compile(r"\b(\d{4}-\d{2}-\d{2})\b") برای یافتن این بازهها استفاده میکند.
اگر یک تاریخ ISO معتبر در متن باشد، سیستم بلافاصله آن را میپذیرد و مدل را کاملاً نادیده میگیرد. اگر منبع از قبل حاوی یک تاریخ ISO باشد، مدل حق رای ندارد. این کار مانع از آن میشود که مدل بخواهد تاریخ را «بهبود» دهد؛ برای مثال، تاریخ 2026-09-18 را به 2026-09-19 تغییر دهد چون فرض میکند تکالیف معمولاً نیمهشب روز بعد تحویل داده میشوند.
اگر تاریخ ISO وجود نداشته باشد، سیستم از مدل میخواهد یک تاریخ کاندید پیشنهاد دهد. اما این کاندید از یک تابع به نام span_ground عبور میکند. این تابع تنها زمانی وضعیت «موفق» برمیگرداند که رشته دقیق کاندید بهصورت کلمه به کلمه (verbatim) در متن منبع وجود داشته باشد. اگر منبع عبارتی مبهم مثل «تا جمعه» باشد، برنامه باید بهجای انتخاب یک جمعه که مدل دوست دارد، درخواست را رد کند.
جزئیات: مدیریت ردها (Refusals)
به جای بازگرداندن یک مقدار ساده مثل 'null' یا 'error'، سیستم از یک کلاس داده (dataclass) ساختاریافته به نام Verdict استفاده میکند تا دلیل رد شدن تاریخ را دستهبندی کند. این کار به توسعهدهندگان اجازه میدهد تا حالتهای شکست خاصی را ثبت کنند که حتی در اتوبوس یا هنگام سخنرانی در کلاس قابل خواندن باشد:
- span_missing: مدل تاریخی را اختراع کرده (مثلاً اضافه کردن ماه/سال) که در متن نیست. این نتیجهی اصلی «دروغسنج» است.
- unresolvable_partial: متن بیش از حد مبهم است (مثلاً 'Due Friday') تا یک تاریخ ISO مستند استخراج شود و هیچ کاندیدی ارائه نشده است.
- ambiguous_multiple: متن شامل چندین تاریخ ISO است (مثلاً تاریخ پروژه نهایی و تاریخ پروپوزال) و سیستم برای جلوگیری از حذف بیصدای داده، از انتخاب یکی از آنها خودداری میکند.
- no_candidate: هیچ تاریخی در منبع یافت نشد و هیچ کاندیدی توسط مدل پیشنهاد نشد.
- ok: کاندید یک بازه متوالی در منبع است.
جزئیات: الزامات پیادهسازی
این پیادهسازی تنها به پایتون ۳.۱۱ یا جدیدتر و کتابخانههای استاندارد نیاز دارد و بهطور عمدی از وابستگیهای سنگین اجتناب میکند:
- بدون PyTorch
- بدون Vector Store
- بدون Agent SDK
پروژه در دو فایل deadlines.py و test_deadlines.py سازماندهی شده است. نویسنده تأکید میکند که باید با «شکست» شروع کرد؛ اگر اولین مثال یک رشته ISO تمیز باشد، توسعهدهنده احتمالاً یک regex مینویسد و آن را «هوش مصنوعی» مینامد.
جزئیات: یکپارچهسازی مدل
برای مرحلهی اختیاری میزبانی، نویسنده از دسترسی رایگان به مدلهای MonkeyCode و گزینه سرور رایگان استفاده کرد تا بودجه کلاس را صرف تجزیه تاریخ نکند. MonkeyCode متنباز است و بهعنوان یک سوکت برای این آزمایش عمل کرد. با این حال، منطق حیاتی تایید — یعنی بررسی span_ground — بهصورت محلی روی لپتاپ باقی میماند تا اطمینان حاصل شود که شبکه تبدیل به متغیر آزمایش نمیشود.
برای تست سیستم، مجموعهای از فیکسچرها (fixtures) استفاده شد تا اطمینان حاصل شود «کمربند ایمنی» کار میکند. کلاس FakeModel برای شبیهسازی مدلی به کار رفت که «از روی لطف» یک روز ناقص را تکمیل میکند. در یک مورد تست، پرامپتی که میگفت «ارسال قبل از آزمایشگاه روز ۱۸ام»، باعث شد مدل تاریخ 2026-09-18 را پیشنهاد دهد. بررسی بازه بهدرستی این مورد را به عنوان span_missing علامتگذاری کرد زیرا آن کاراکترهای خاص در متن اصلی نبودند.
تست حیاتی دیگر مربوط به two_dates بود که در آن متن هم تاریخ پروژه نهایی و هم تاریخ پروپوزال را لیست کرده بود. بهجای انتخاب اولی و حذف بیصدای دومی، سیستم وضعیت ambiguous_multiple را برگرداند. در یک برنامهریز، حذف بیصدای داده بدتر از کرش کردن است؛ رد کردن درخواست در زمان وجود بیش از یک بازه، شاید زشت باشد اما قابل مشاهده است.
اجتناب از تلههای رایج
نویسنده نسبت به چندین اشتباه رایج در تجزیه AI هشدار میدهد که میتوانند توهمات را با مراحل بیشتر بازسازی کنند:
۱. تلههای نرمالسازی: تلاش برای تبدیل «۱۸ام» به یک عدد صحیح از روز ماه و سپس چسباندن ماه جاری به بالای آن. این کار صرفاً توهم اولیه را خودکار میکند.
۲. شکستهای بیصدا: ثبت تنها deadline=None بدون ذکر دلیل. یک None بیصدا، دستهای کامل از شکستها را در حالی که شما به سمت کلاس میروید نادیده میگیرد. شیء Verdict تضمین میکند که دلیل ثبت شود.
۳. اتکای بیش از حد به مدل: فراخوانی مدل حتی زمانی که منبع از قبل دارای تاریخ ISO است. این کار به مدل فرصت میدهد تا بر اساس منطق داخلی خود به جای متن، تاریخ جدیدی اختراع کند.
برای کسانی که مسیر میزبانی را پیاده میکنند، نویسنده یک قالب با استفاده از urllib.request برای ارسال یک Payload JSON به یک Endpoint POST با مهلت ۳۰ ثانیه پیشنهاد میکند. با این حال، قانون ثابت است: اگر پاسخ میزبانی نتواند از span_ground عبور کند، فارغ از اینکه API رایگان است یا پولی، نباید در نمای هفتگی تقویم قرار گیرد.
محدودیتها و محدوده
این سیستم برای «دقت بالا» (Precision) طراحی شده است، نه «بازیابی بالا» (Recall). این یک دروازه محافظهکار است. بهطور عمدی مقدار زیادی از انگلیسی رایج دانشگاهی مانند «پایان هفته»، «قبل از آزمایشگاه» یا عادت Brightspace در ترکیب زمان محلی و UTC را رد میکند. این سیستم مناطق زمانی (Time Zones) را نمیفهمد.
این ابزار برای استفاده بهعنوان یک ثبتکننده رسمی یا یک عامل کاملاً خودمختار در نظر گرفته نشده است. نویسنده استدلال میکند عاملی که قادر به ارسال ایمیل به یک گروه چت باشد، اگر «if-statement» زیربنایی صادق نباشد، توهمات را سریعتر پخش میکند. یک کت بلند، if-statement را دانا نمیکند.
این رویکرد برای برنامهریزهای شخصی یا ابزارهایی مناسب است که در آنها یک ردِ قابل مشاهده، ترجیح بر یک پاسخ غلط اما مطمئن است. اگر کاربر به یک ایندکس جستجو از سرفصلهای قدیمی نیاز دارد که در آن حدس زدن ماه بهتر از هیچ است، این دروازه محافظهکار باید حذف شود. همچنین برای تاریخهایی که بهصورت اسکرینشات میرسند، نامناسب است.
گسترش و تستهای بیشتر
برای گسترش این ابزار، میتوان فیکسچر ششمی را اضافه کرد که در آن منبع میگوید «Sept 18, 2026». هدف این است که نرمالسازی را بهگونهای بنویسیم که آن عبارت را به 2026-09-18 نگاشت کند، اما تنها در صورتی که تکتک توکنهای آن عبارت در متن منبع تایید شوند. تست این مورد با «Sept 18» (بدون سال) فاش میکند که آیا نرمالساز هنوز بیش از حد سهلگیر است یا خیر.
در نهایت، درس این است که یک استخراجکننده، تقویم نیست و تکمیل مدل، یک کاندید است، نه یک حقیقت. اگر نمیتوانید به یک بازه اشاره کنید، ددلاینی ندارید؛ بلکه یک حدس دارید. پس از اتمام، فرد باید بتواند حکم (Verdict) را پیشبینی کند: ISO صریح؟ بپذیر. روز ناقص؟ رد کن. دو تاریخ ISO؟ رد کن. اختراع مدل؟ رد کن. اگر هر یک از اینها شما را غافلگیر کرد، فیلد یادداشت (note) را بلند بخوانید؛ یادداشت همان درس است و تاریخ فقط یک مدرک است.
گام بعدی شما
- اگر از LLM برای استخراج دادههای حساس (مثل تاریخ یا مبلغ) استفاده میکنید، یک تابع تطبیق رشتهای (String Match) ساده را بهعنوان لایه تایید نهایی اضافه کنید.
- بهجای استفاده از
nullبرای خطاهای استخراج، یک سیستم دستهبندی خطا (مانند کلاس Verdict) پیاده کنید تا بفهمید مدل کجا توهم میزند. - در سیستمهای عاملمحور، هرگز اجازه ندهید خروجی مدل بدون تایید توسط دادههای خام (Raw Data) به مرحله اجرا (Action) برسد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو