تصور کنید یک عامل هوش مصنوعی با اطمینان کامل پیام «تمام تستها پاس شدند» را میفرستد، اما نمیتواند دقیقاً بگوید چه دستوری را اجرا کرده است. این پیام در نبودِ مدرک، هیچ ارزشی ندارد.
در ۲۳ ژوئیه ۲۰۲۶، یک راهنمای کاربردی در وبسایت dev.to به شکست بحرانی در گردشکارهای عاملمحور (Agentic) اشاره کرد: «شکاف اثبات» (Provenance Gap). این وضعیت زمانی رخ میدهد که یک عامل (Agent) — شبیه به دستیاری که کار را انجام میدهد اما رسید دریافت نمیکند — در تلاش مجدد برای رسیدن به جواب، سوابق تحویل را از دست میدهد. این سوابق شامل لاگها، تفاوتهای کد (Diffs) و وضعیت محیط اجرای برنامه است که برای اعتماد به پاسخ نهایی ضروری هستند. در واقع بسیاری از این شکستها ریشه در اختلالات زیرساختی و خطاهای شبکهای دارند که منجر به گم شدن ردپای عملیات در محیطهای عملیاتی میشود.
همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن دیدیم، اعتماد کورکورانه به خروجی مدلها ریسکهای سیستمی دارد. در اینجا نیز اگر عاملی سه فایل را ویرایش کند و در لحظه ارسال نتایج، اتصالش قطع شود و سپس سیستم دوباره تلاش کند، بازبین ممکن است تنها یک پیام تایید دریافت کند، بدون اینکه بداند دقیقاً چه تغییری در کدها رخ داده است. طبق گزارش dev.to، این یک باگ در کد نیست، بلکه شکست در «سند حقیقت» است. این موضوع یادآور الگوهای شکست در آزمونهای خودکار است که در آنها سیستم با وجود نمایش چراغ سبز، در واقعیت با خطای منطقی مواجه شده است.
بر اساس این گزارش، بازبینها برای جلوگیری از مثبتهای کاذب باید ادعاهای مدل را در سه وضعیت دستهبندی کنند:
- اثباتشده (PROVEN): مدارک ارائه شده مستقیماً ادعای خاص را تایید میکنند.
- اثباتنشده (UNPROVEN): ادعا ممکن است درست باشد، اما مدارک لازم موجود نیست.
- مسدود (BLOCKED): بازبین به محیط اجرا یا آرتیفکتهای مورد نیاز دسترسی ندارد.
برای بستن این شکاف، نویسنده پیشنهاد میکند بهجای درخواست خلاصه، یک «بسته اصلاحی» (Correction Packet) بخواهید. یک بسته معتبر باید شامل ادعاهای دقیق تکمیل، لیست فایلهای تغییر یافته، دستور تایید اجرا شده و وضعیت دقیق شاخه (Branch) کد باشد. برای مدیریت دقیقتر این نوسانات و بازسازی مسیر طی شده توسط مدل، میتوان از رویکردهایی نظیر Retrace برای دیباگ کردن استفاده کرد تا هر مرحله از اجرای عامل قابل بازبینی باشد.
این تغییر رویکرد، پیشفرض نظارت بر عاملها را عوض میکند. بازبین بهجای اعتماد به فصاحت کلامی مدل، مانند یک حسابرسِ مدارک عمل میکند. اگر تلاش مجدد مدل تنها یک ادعای نهایی برگرداند، بازبین نباید بستر گمشده را حدس بزند و باید نتیجه را «اثباتنشده» علامت بزند.
در کارهای کمریسک مثل ویرایش متنی، یک لاگ ساده کافی است. اما برای تغییرات حساس — مانند قوانین احراز هویت یا منطق صورتحساب — اجرای مجدد تست توسط انسان اجباری است. عمق بازبینی باید همواره با ریسک تغییر متناسب باشد.
برنامهنویسان میتوانند این فرآیند حسابرسی را با استفاده از AI Completion Evidence Auditor Lite پیاده کنند؛ کاربرگ مخصوصی که پیامهای تکمیل را با خروجیهای واقعی ساخت (Build) مقایسه میکند تا مطمئن شود رنگ سبز در محیط چت با رنگ سبز در محیط تولید (Production) یکی است.
گام بعدی شما
- در هر بازبینی کد توسط AI، از مدل بخواهید «بسته اصلاحی» شامل Diff و دستور تست را ارائه دهد.
- برای هر تغییر در بخشهای حساس (Security/Billing)، تستها را بهصورت دستی و مستقل اجرا کنید.
- از متد دستهبندی سه-گانه (اثباتشده/نشده/مسدود) برای مدیریت تسکهای برونسپاری شده به AI استفاده کنید.
اما این چالشهای اعتبارسنجی تنها بخشی از داستان است؛ برای درک اینکه چگونه ساختارهای جدید استدلالی میتوانند این توهمات را کاهش دهند، تحلیل ما دربارهی مدلهای Reasoning را بخوانید.
گفتگو