تصور کنید برنامه‌نویسی هستید که یک تغییر حساس را به یک عامل هوش مصنوعی می‌سپارد و در پاسخ، گزارشی دریافت می‌کند که تمام تست‌ها با موفقیت پاس شده‌اند؛ اما به محض استقرار در محیط تولید، سیستم کرش می‌کند. این شکاف خطرناک به این دلیل رخ می‌دهد که اکثر عامل‌ها به‌جای ثبت آنچه «واقعاً اجرا شده»، آنچه را که «ادعا می‌کنند اتفاق افتاده» ثبت می‌کنند. وقتی ادعای مدل با نتیجه واقعی همخوانی ندارد، شما مجبورید در میان انبوهی از لاگ‌ها بگردید تا بفهمید داستان از کجا منحرف شد؛ اما مشکل اینجاست که خودِ لاگ هم نمی‌تواند به شما کمک کند، چون به‌جای شواهد اجرایی، گزارش‌های مدل را ذخیره کرده است.
در حالی که صنعت به سمت مهندسی نرم‌افزار خودکار حرکت می‌کند، اتکا به خود-گزارش‌دهی (Self-reporting) یک نقطه کور مرگبار ایجاد کرده است. یک گزارش، تا زمانی که اجرای آن توسط شواهد اجرایی پشتیبانی نشود، صرفاً یک گزارش است و بیش از آن نیست. وقتی توسعه‌دهنده‌ای یک گزارش خلاصه را بدون این شواهد می‌پذیرد، در واقع در حال بررسی یک داستان تخیلی است. این مسئله به‌ویژه زمانی حاد می‌شود که تیم‌ها، عامل‌های هوش مصنوعی را در خط لوله‌های CI/CD ادغام می‌کنند؛ جایی که «شعاع تخریب» (Blast Radius) یک اشتباه می‌تواند فاجعه‌بار باشد. این نوع عدم انطباق میان ادعای مدل و واقعیت اجرایی، ریشه در همان شکاف‌های مهندسی دارد که منجر به شکست بسیاری از پروژه‌های هوش مصنوعی می‌شود.
زمینه و بستر حسابرسی
پرسش بنیادین در اینجا این نیست که «آیا تست‌ها پاس شدند؟»، بلکه این است که: «چه چیزی باید ثبت شود تا این پاسخ بعداً قابل بازبینی و چک کردن باشد؟»
تغییر تمرکز از «اعتماد» به «حسابرسی» (Auditability)، یک پرسش مبهم درباره اعتماد را به یک مسئله عینی درباره شواهد تبدیل می‌کند. این رویکرد مستلزم یک تفکیک سخت‌گیرانه بین سه نوع داده است تا اطمینان حاصل شود که وقتی گزارشی با واقعیت همخوانی ندارد، رکوردها همچنان ارزش خواندن و تحلیل داشته باشند.
به نقل از گزارشی که در ۲ سپتامبر ۲۰۲۶ در dev.to منتشر شد، راهکار اصلی تغییر رویکرد از «قابل اعتماد کردن» عامل‌ها به «قابل حسابرسی کردن» اجراهای آن‌هاست. این امر مستلزم تفکیک سخت‌گیرانه سه نوع داده است:
سلسله‌مراتب شواهد
- درخواستی (Requested): این‌ها صرفاً قصد و نیت هستند. وقتی تسکی را شروع می‌کنید، یک مدل، سطح تلاش (Effort Level)، یک محیط سندباکس یا یک سیاست تایید را تعیین می‌کنید. این‌ها درخواست هستند. بین درخواست و فراخوانی نهایی، ارائه‌دهندگان، ابزارها، لایه‌های مسیریابی و مقادیر پیش‌فرض قرار دارند. هر یک از این‌ها می‌توانند مقدار درخواستی را جایگزین کنند. بنابراین، درخواست‌ها باید به عنوان «درخواست» برچسب بخورند؛ آن‌ها به شما می‌گویند که سیاستِ مورد نظر چه بوده، اما دلیل و شاهد نیستند. برای مثال، ثبت عبارت
model: claude-x-largeمبهم است، مگر اینکه مشخص شود این مدل «درخواست شده» یا «واقعاً اجرا شده» است. - مشاهده‌شده (Observed): این یک ادعا است که منبعی دارد و قدرت منابع با هم متفاوت است. ضعیف‌ترین مشاهده زمانی است که یک ابزار صرفاً مقدار ورودی را می‌پذیرد؛ این ثابت می‌کند که درخواست به‌درستی شکل گرفته بود، اما هیچ چیز درباره اینکه چه کسی فراخوانی را پاسخ داده نمی‌گوید. مشاهده قوی‌تر زمانی رخ می‌دهد که متادیتای ارائه‌دهنده، مقدار را بازمی‌گرداند، زیرا در این حالت مقدار از درخواست اولیه نشأت نگرفته است.
- اثری (Effective): این قوی‌ترین سطح سلسله‌مراتب است. این داده بومیِ ارائه‌دهنده (Provider-native) است و مستقیماً به آن فراخوانی خاص گره خورده است.
یک قانون حیاتی در این سلسله‌مراتب این است که هرگز نباید یک مشاهده ضعیف را به عنوان یک اثر قوی ثبت کرد. اگر فقط سطح اول (درخواستی) در دسترس است، رکورد باید دقیقاً همین را بگوید. نباید صرفاً به دلیل اینکه در گزارش نهایی زیباتر به نظر می‌رسد، از کلمه «تایید شد» استفاده کرد.
گره زدن شواهد به SHA
شواهد تنها زمانی معنا دارند که بدانیم دقیقاً مربوط به کدام نسخه از کد هستند. هر کد خروجی، مشاهده یا تاییدیه، حقیقتی درباره یک بازبینی (Revision) خاص است. برای حفظ این نظم، رکوردها باید به یک commit SHA (شناسه یکتای هر تغییر در گیت) گره بخورند، نه به نام یک شاخه (Branch) یا خلاصه گفتگو.
- نام شاخه‌ها اشاره‌گرهایی هستند که جابه‌جا می‌شوند. عبارتی مثل «در شاخه main بررسی شد» پس از پیشروی کد در main، بی‌معنا می‌شود.
- خلاصه‌های گفتگو بازسازی مدل از اقدامات خودش است که دقیقاً همان خود-گزارش‌دهی است که می‌خواهیم از آن دوری کنیم.
- SHAها شکاف‌ها را نمایان می‌کنند. بررسی ثبت‌شده برای یک کامیت، هیچ ارزشی برای نسخه اصلاح‌شده ندارد چون SHA تغییر کرده است.
محدودیت‌های شواهد اجرایی
باید صریح بود: شواهد اجرایی ثابت نمی‌کنند که کد «درست» است. یک اجرا می‌تواند کاملاً مستند باشد — با تمام کدهای خروجی ثبت‌شده و تمام شناسه‌های متصل به کامیت درست — اما تغییرات همچنان غلط، ناامن یا بدطراحی شده باشند. شواهد اجرایی فقط به یک پرسش محدود پاسخ می‌دهند: «وقتی این کاندید اجرا شد، دقیقاً چه اتفاقی افتاد؟». این داده‌ها ورودیِ قضاوت انسانی هستند، نه جایگزین آن.
بر اساس پژوهش‌های اخیر، این سخت‌گیری الزامی است:
- وانگ، پرادل و لیو (۲۰۲۵) دریافتند که وصله‌های (Patches) علامت‌گذاری شده به عنوان «حل‌شده» در SWE-bench Verified، اغلب با اصلاحات واقعی توسعه‌دهندگان تفاوت داشتند و برخی از آن‌ها آشکارا غلط بودند.
- هوانگ و همکاران (۲۰۲۳) نشان دادند که مدل‌های زبانی بزرگ (LLM) در اصلاح استدلال‌های خود بدون بازخورد خارجی مشکل دارند. این یعنی عبارت «به نظر خوب می‌رسد» از زبان مدل، ضعیف‌ترین سیگنال ممکن در محیط است.
انسان در حلقه و استقلال ساختاری
با این تغییر رویکرد، نقش انسان تغییر می‌کند. اتوماسیون می‌تواند شواهد را جمع‌آوری کند و تا نزدیکی خط تصمیم پیش برود، اما برای تصمیماتی با اثرات گسترده (Blast Radius) مانند ادغام در کد اصلی (Merge)، استقرار در تولید یا تغییرات در تجهیزات فیزیکی و شبکه، یک انسان باید از این خط عبور کند. سازنده نمی‌تواند بازبین نهایی خودش باشد.
برای حفظ استقلال، «بازبین» باید از خانواده مدل متفاوتی نسبت به «سازنده» باشد. این جداسازی ساختاری مانع از تمایل مستند مدل‌ها می‌شود که وقتی در نقش قاضی هستند، خروجی‌های مشابه خودشان را ترجیح دهند. بازبینی که شروع به اصلاح کد می‌کند، استقلال خود را برای آن بازبینی خاص از دست می‌دهد؛ او باید دقیقاً همان SHA را قضاوت کند که خودش آن را نساخته است، بدون اینکه اجازه اصلاح آن را داشته باشد.
هدف این است که قابلیت اطمینان هوش مصنوعی را به عنوان یک مسئله حسابداری ببینیم که راهکاری عینی دارد: ثبت دقیق اتفاقات، با سطح اعتبار درست و گره‌خورده به یک SHA. برای کسانی که این سیستم‌ها می‌سازند، گام بعدی پیاده‌سازی لایه‌های تایید مستقل مانند Kelruno است که هدفش جداسازی سازنده از حسابرس برای تضمین تغییرناپذیری شواهد اجرایی است. در همین راستا، ابزارهایی مانند ProofRun با استفاده از رسیدهای رمزنگاری تلاش می‌کنند تا ادعای موفقیت عامل‌های کدنویس را به صورت ریاضی بسنجند.
گام بعدی شما
- در سیستم‌های عامل‌محور خود، لاگ‌های متنی را با شواهد متصل به SHA جایگزین کنید.
- برای بازبینی کدها، از یک مدل زبانی متفاوت با مدل سازنده استفاده کنید تا سوگیری تایید کاهش یابد.
- هرگز گزارش «تست‌های پاس شده» را بدون دسترسی به خروجی خام (Raw Output) محیط اجرا نپذیرید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو