تصور کنید یک ابزار خودکار برای مدیریت گزارش‌های گیت‌هاب دارید که به‌جای کمک به شما، هر ۳۰ دقیقه یک بار یک کار تکراری و بیهوده را انجام می‌دهد، اما هیچ نموداری در داشبوردتان این نقص را نشان نمی‌دهد. این دقیقاً همان نقطه‌ای است که تفاوت بین «مشاهده خروجی» و «بازرسی تصمیم» مشخص می‌شود.
به گزارش یک توسعه‌دهنده مستقل، یک فایل ساده از نوع JSONL ارزش بسیار بیشتری نسبت به خروجی نهایی یک عامل (Agent) — شبیه به کارمندی که دستورات را می‌گیرد و اجرا می‌کند — برای طبقه‌بندی مسائل در MonkeyCode داشت. او با ثبت هر تصمیم مدل به عنوان یک «رسید» (Receipt)، شامل هش پرامپت، تعداد توکن‌ها و برچسب زمانی، خطای تکرارشونده‌ای را در خط لوله (Pipeline) یافت که در داشبوردهای سنتی تحلیل داده‌ها کاملاً نامرئی بود.
این رویکرد در زمانی مطرح می‌شود که بسیاری از نمونه‌های اولیه هوش مصنوعی در تبدیل شدن به محصولات قابل‌اعتماد شکست می‌خورند. همان‌طور که در تحلیل قبلی ما درباره‌ی دلایل شکست نمونه‌های اولیه AI اشاره کردیم، مشکل اصلی معمولاً نبود دید کافی نسبت به «چرایی» انتخاب‌های مدل است. اکثر توسعه‌دهندگان به نمونه‌برداری یا نمودارهای سطح بالا تکیه می‌کنند که دقیقاً همان ناهنجاری‌های حیاتی را حذف می‌کنند و باعث می‌شوند سیستم در سطح کلان سالم به نظر برسد، در حالی که در جزئیات دچار فروپاشی است. این چالش با رویکرد بازرسی ۱۰۰ درصدی لاگ‌ها توسط عامل‌های خودکار که پیش‌تر بررسی کردیم، هم‌راستا است تا نقاط کور سیستم آشکار شوند.
زمینه آزمایش
این آزمایش روی یک مخزن کوچک شامل ده‌ها مسئله باز، شامل ترکیبی از باگ‌ها، نقص‌های مستندات و پرسش‌های عمومی انجام شد. هدف به‌طور عمدی ساده و حتی خسته‌کننده طراحی شده بود: طبقه‌بندی هر مورد در یکی از چهار دسته باگ، مستندات، پرسش یا بهبود، و ثبت هر تصمیم در یک خط JSON.
برای رایگان نگه داشتن هزینه، توسعه‌دهنده از دسترسی رایگان به مدل‌ها و گزینه سرور رایگان MonkeyCode استفاده کرد. کل عملیات در محدوده سهمیه ۱۰ میلیون توکن (Token) — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — جای گرفت. از آنجا که پروژه متن‌باز بود، توسعه‌دهنده توانست پیش از اعتماد کامل به سیستم، مکانیسم‌های داخلی آن را به‌طور دقیق تأیید و بررسی کند.
مکانیسم «رسید»
برای پیاده‌سازی این عادت ثبت کامل، یک عامل طراحی شد تا مسائل گیت‌هاب را طبقه‌بندی کند. سیستم به‌طور عمدی از پیچیدگی‌های رایج تهی شد؛ یعنی هیچ پایگاه‌داده برداری (Vector Store)، هیچ چارچوب ارزیابی (Evaluation Harness) و هیچ ارکستراسیون پیچیده‌ای در آن نبود.
در عوض، یک قانون سخت‌گیرانه اجرا شد: هیچ عاملی نباید بدون گذاشتن رسید تصمیم بگیرد. بدون این کار، یک پاسخ اشتباه تبدیل به «شبحی» می‌شود که نمی‌توان از آن بازجویی کرد. برای جلوگیری از چنین خطاهای پیش‌بینی‌نشده‌ای، می‌توان از لایه نگهبان برای کنترل خروجی‌های پرهزینه استفاده کرد تا ریسک اجرای دستورات نادرست کاهش یابد. یک رسید کامل شامل موارد زیر است:
- متن دقیق پرامپت ورودی
- مدل خاص مورد استفاده
- تعداد کل توکن‌ها
- حکم نهایی مدل
- برچسب زمانی دقیق
پیاده‌سازی فنی
هسته این عامل یک اسکریپت پایتون به نام decide.py است که مسئله را می‌خواند، پرامپت را می‌سازد، مدل را فراخوانی می‌کند و نتیجه را به فایل JSONL اضافه می‌کند. در این پرامپت، از مدل خواسته شده دقیقاً یک برچسب و یک امتیاز اطمینان بین ۰ و ۱ ارائه دهد و برای ثبات در پاسخ‌ها، دمای (Temperature) مدل روی ۰.۲ تنظیم شده است.
یک جزئیات حیاتی در این ساختار، استفاده از «هش پرامپت» است. با ذخیره هش SHA-256 از پرامپت (کوتاه شده به ۱۲ کاراکتر)، توسعه‌دهنده می‌تواند دقیقاً آنچه مدل دیده است را بازسازی کند، حتی اگر متن اصلی مسئله در گیت‌هاب بعداً ویرایش شود. این فیلد ساده، یک لاگ معمولی را به یک ردپای حسابرسی رسمی تبدیل می‌کند.
زمان‌بندی توسط یک کرون‌جاب (Cron job) و یک حلقه بش (triage.sh) مدیریت می‌شود. هر ۳۰ دقیقه، این حلقه مسائل باز را از طریق GitHub CLI (gh issue list) دریافت کرده، جزئیات مسئله را مشاهده می‌کند و سپس اسکریپت تصمیم‌گیری را اجرا می‌کند.
زیرساخت برای حذف هزینه‌ها مینیمال نگه داشته شد. توسعه‌دهنده از سهمیه ۱۰ میلیون توکنی MonkeyCode و یک سرور رایگان برای میزبانی یک اپلیکیشن FastAPI ساده (serve.py) استفاده کرد. این اپلیکیشن صرفاً فایل JSONL را در یک صفحه HTML استاتیک نمایش می‌دهد که ۲۰ تصمیم آخر را در یک جدول رندر می‌کند. طبق اعلام توسعه‌دهنده، چون این عملیات فقط خواندن فایل است و نیاز به محاسبات سنگین ندارد، سرور رایگان کاملاً پاسخگو بود.
کشف خطا
در عرض یک هفته، این دفتر ثبت را به چند ده رکورد رساند و یک ناکارآمدی فاحش را آشکار کرد. لاگ‌ها نشان دادند که مسئله شماره ۱۲ هر ۳۰ دقیقه یک بار دوباره پردازش می‌شود. هش پرامپت و حکم نهایی یکسان بود، اما عامل مدام «یک سیگار تکراری را روشن می‌کرد»؛ زیرا حلقه بش تمام مسائل باز را پردازش می‌کرد، نه فقط موارد جدید را. این نقص در ۵ ثانیه از طریق دفتر ثبت مشخص شد، در حالی که یک داشبورد تحلیلی آن را پشت نمودارهای کلی پنهان می‌کرد.
علاوه بر باگ خط لوله، لاگ‌ها نکته‌ای درباره رفتار مدل فاش کردند. امتیازات اطمینان در دو نقطه حداکثری و حداقلی متمرکز شده بودند و به‌ندرت در میانه قرار می‌گرفتند. این یعنی برچسب‌های محدود، فشار اصلی را تحمل می‌کردند و فضای کمی برای تردید مدل باقی می‌ماند؛ ویژگی‌ای که برای ثبات عالی است اما برای کسانی که به‌دنبال ظرافت‌های تحلیلی هستند، یک تله است.
تغییر در استراتژی عیب‌یابی
این آزمایش نشان می‌دهد که زیرساخت‌های لایه رایگان، نحوه ثبت داده‌ها را تغییر می‌دهند. در محیط‌های پولی، توسعه‌دهندگان برای کاهش هزینه معمولاً ۱۰٪ از لاگ‌ها را نمونه‌برداری می‌کنند. اما وقتی ثبت رایگان است، ریاضیات تغییر می‌کند و امکان ثبت ۱۰۰٪ فراهم می‌شود. این امر لاگ را از یک ابزار نمونه‌برداری به یک ردپای کامل حسابرسی تبدیل می‌کند.
برای یک توسعه‌دهنده کاربردی، این یعنی «رسید» ارزشمندتر از «حکم» است. حکم به شما می‌گوید چه اتفاقی افتاده، اما رسید توضیح می‌دهد چرا اتفاق افتاده است — با ارائه ورودی دقیق، مدل و تعداد توکن‌ها. تفاوت این دو، تفاوت بین حدس زدن درباره شکست یک عامل و بازجویی از آن با استفاده از داده‌هاست.
محدودیت‌ها
توسعه‌دهنده تأکید می‌کند که این معماری سبک برای همه مناسب نیست. محدودیت‌های سرور رایگان در واقع به بهبود معماری کمک کرد، چون اجبار کرد ابزار کوچک بماند و از دیتابیس، صف یا ارکستراسیون استفاده نشود.
با این حال، این روش برای ابزارهای کوچک و آزمایش‌هاست، نه محیط‌های عملیاتی (Production). این رویکرد توصیه نمی‌شود برای:
- کاربرانی که به توافق‌نامه سطح خدمات (SLA) سخت‌گیرانه نیاز دارند
- کسانی که با داده‌های حساس سروکار دارند (جایی که مکان ذخیره لاگ یک ریسک امنیتی است) — در چنین مواردی، استفاده از مکانیزم‌های GuardRail برای کنترل دسترسی ضروری است تا از دسترسی غیرمجاز عامل‌ها به داده‌های حساس جلوگیری شود.
- حجم کارهای میلیونی در شب که سهمیه توکن‌های رایگان را سریعاً تمام می‌کند
اگر در حال ساخت ابزارهای کوچک هستید، از همین حالا با لاگ‌های خود به‌عنوان محصول اصلی برخورد کنید. الگوهای هش پرامپت را زیر نظر بگیرید تا ببینید آیا عامل شما در حال تکرار کارهاست یا بر اساس تغییرات جزئی ورودی، دچار توهم (Hallucination) — شبیه به دوستی که خاطره‌ای را اشتباه تعریف می‌کند — شده است یا خیر.
گام بعدی شما
- در پروژه‌های کوچک، به‌جای تکیه بر داشبوردهای بصری، یک فایل JSONL برای ثبت تمام ورودی‌ها و خروجی‌های مدل ایجاد کنید.
- برای هر درخواست به مدل، یک هش SHA-256 از پرامپت ذخیره کنید تا بتوانید در صورت تغییر داده‌های منبع، تصمیم مدل را بازسازی کنید.
- توزیع امتیازات اطمینان (Confidence Scores) را بررسی کنید تا بفهمید مدل شما واقعاً مطمئن است یا صرفاً به دلیل محدودیت برچسب‌ها، مجبور به انتخاب یکی از گزینه‌هاست.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو