تصور کنید یک عامل هوش مصنوعی در سکوتی مرگبار، توانایی برنامه‌ریزی خود را نابود می‌کند چون بیش از حد به تأییدات خودش اعتماد کرده است. این ریسک در تحلیل فنی ۱۰ سپتامبر ۲۰۲۶ در وب‌سایت dev.to بررسی شد؛ جایی که مشخص شد برچسب‌های «رایگان» تولید شده توسط عامل‌ها، در حالی که از طریق بررسی موفقیت یا شکست یک اقدام به دست می‌آیند، اغلب بازتابی از نقاط کور خود مدل هستند، نه حقیقت محض.
بسیاری از توسعه‌دهندگان از یک مدل تأییدکننده (Verifier) استفاده می‌کنند تا تصمیم بگیرند آیا عامل باید یک اقدام شکست‌خورده را تکرار کند یا خیر، و سپس نتیجه را دور می‌اندازند. این یک اتلاف سرمایه است. فرآیند معمول این است: یک مدل به اسکرین‌شات و دستورالعمل نگاه می‌کند، مختصات کلیک را برمی‌گرداند و اجرا می‌کند. سپس مدل دوم، اسکرین‌شات‌های قبل و بعد را مقایسه می‌کند تا به یک سؤال پاسخ دهد: آیا اثر مورد نظر رخ داده است یا خیر؟
با ذخیره هر اقدامی که تأییدکننده آن را به عنوان یک حقیقت بادوام پذیرفته، توسعه‌دهندگان می‌توانند سیستمی بسازند که در آن دقت از اجرای دوم به بعد به‌صورت تصاعدی رشد کند. اولین تماس با یک اپلیکیشن «سرد» است، اما اجراهای بعدی از این حقایق ذخیره‌شده بهره می‌برند. با این حال، پذیرفتن این برچسب‌ها به عنوان حقیقت مطلق، منجر به یک حلقه بازخورد خطرناک می‌شود که در آن عامل یاد می‌گیرد با اعتمادبه‌نفس کامل، اشتباه کند. این چالش‌های ساختاری در مدیریت حلقه‌های بازخوردی، یادآور آن است که چرا مقیاس‌پذیری عامل‌های هوش مصنوعی به معماری Loop وابسته است تا از فروپاشی سیستم در ابعاد بزرگ جلوگیری شود.
توهمِ دقت
داده‌های یک سامانه مبنی‌سازی (Grounding) — شبیه به نقشه‌ای که کلمات انتزاعی را به اشیای واقعی روی صفحه می‌چسباند — نشان می‌دهد چرا اعداد کلی گمراه‌کننده هستند. در آزمونی با ۸۰ تلاش مبنی‌سازی در ۲۶ اجرا، تأییدکننده ۶۹ مورد را موفق دانست که نرخ موفقیت ۰.۸۶۲۵ را نشان می‌دهد. در حالی که این عدد بالا به نظر می‌رسد، نویسنده هشدار می‌دهد که ۸۶.۲۵٪ مربوط به درست بودن «مبنی‌ساز» (Grounder) است، در حالی که تأییدکننده ابزاری بود که ۱۱ شکست دیگر را شکار کرد. خلط این دو مقدار منجر به اعتماد به جزء اشتباه سیستم می‌شود.
تجزیه نتایج بر اساس نوع اقدام، یک شکست بحرانی را افشا می‌کند:
- تایپ کردن: ۲۱ از ۲۱ مورد موفق. تایپ کردن در یک فیلد مکان‌یابی‌شده عملاً حل شده است.
- کلیک کردن: ۴۳ از ۵۰ مورد موفق (۰.۸۶). این بخش حجم اصلی داده‌ها را می‌سازد و عدد نهایی را تعیین می‌کند.
- کشیدن (Dragging): ۰ از ۴ مورد موفق. این یک خطای گرد کردن یا آماری نیست، بلکه یک شکست مطلق است.
- انتظار، نگه داشتن و فشردن کلید: به ترتیب ۳ از ۳، ۱ از ۱ و ۱ از ۱ مورد موفق شدند، هرچند تعداد نمونه‌ها برای نتیجه‌گیری آماری بسیار کم است.
نرخ موفقیت صفر در عملیات «کشیدن» به این دلیل است که اهداف نهایی (Drop Targets) اغلب تا زمانی که حرکت (Gesture) در جریان نباشد، روی صفحه ظاهر نمی‌شوند و در لحظه هدف‌گیری، چیزی برای مبنی‌سازی وجود ندارد. نویسنده اشاره می‌کند که کدهای پیچیده‌ای برای حل این مشکل نوشته شده‌اند — از جمله فشردن، تکان دادن برای نمایش جایگاه‌ها و ارسال توکی‌های بومی HTML5 در کنار اشاره‌گرها — دقیقاً به این دلیل که نسخه ساده و ابتدایی امتیاز صفر می‌گیرد. کدهای پیچیده معمولاً «اعترافی» به این شکست‌های مدل‌های زیربنایی هستند.
محدودیت‌های اندازه‌گیری و زمینه
باید توجه داشت که تمام ۸۰ نمونه از یک دامنه واحد بوده‌اند. این یک اندازه‌گیری از یک اپلیکیشن خاص است، نه یک ادعای دقت کلی. برای حفظ دقت و سخت‌گیری، فایل‌های پایه دارای برچسب زمانی و کد commit sha هستند، زیرا این اعداد «نیمه‌عمر» دارند و با تغییر مدل یا رابط کاربری منقضی می‌شوند.
علاوه بر این، تأییدکننده خود یک پیشگو (Oracle) نیست. نویسنده به یک مورد باز اشاره می‌کند که در آن یک تأییدیه کاملاً غلط بود: یک بررسی دسترسی‌پذیری، یک کنترل رندر شده توسط کلاینت را قبل از اتمام رندر اسکن کرد، آن را «بدون نام» خواند و این یافته در مراحل بعدی با شدت بحرانی تأیید شد. برچسب خوب است، اما حقیقت مرجع (Ground Truth) نیست.
پنج قانون برای اعتماد به برچسب‌های ناقص
برای جلوگیری از مسموم‌سازی پایگاه دانش عامل، نویسنده پنج حفاظ معماری سخت‌گیرانه پیشنهاد می‌کند. اگر تأییدکننده یک پیشگوی مطلق بود، این‌ها غیرضروری بودند، اما چون ناقص است، اجباری هستند:
۱. هرگز از شکست‌ها یاد نگیرید: فقط مراحلی که تأییدکننده آن‌ها را تأیید کرده است به حقیقت تبدیل شوند. یادگیری از شکست‌ها به عنوان نمونه‌های منفی وسوسه‌انگیز است، اما شکست فقط می‌گوید این تلاش غلط بود، نه اینکه جواب درست چه بود. ذخیره یک شکست، صرفاً ذخیره یک حدس است.
۲. تنوع در خانواده‌های مدل: عامل (Actor)، برنامه‌ریز (Planner) و تأییدکننده (Verifier) باید از خانواده‌های مدل متفاوتی باشند. اگر یک خانواده هم اجرا کند و هم چک کند، خطاهایشان همبسته می‌شود و تأییدکننده تبدیل به پژواک اشتباهات عامل می‌شود. نقطه کور در عامل نباید به‌طور خودکار نقطه کور در تأییدکننده باشد.
۳. امتیازدهی سلسله‌مراتبی به اعتماد: اعتماد بر اساس منبع امتیازدهی می‌شود و تکرار شواهد تنها راه افزایش آن است:
* عبور تمیز (Clean Pass): امتیاز اولیه ۰.۶
* بازیابی پس از برنامه‌ریزی مجدد (Replan Recovery): امتیاز اولیه ۰.۵۵، زیرا بازیابی شواهد ضعیف‌تری نسبت به عبور تمیز است.
* تأیید انسانی: امتیاز ۰.۹ و اولویت بالاتر از تمام منابع دیگر.
* مشاهدات تکراری: افزودن ۰.۱ به ازای هر مشاهده، با سقف زیر ۱.۰. این افزایش در هر اجرا «تکرارناپذیر» (Idempotent) است تا یک اجرای پرحرف، حدس‌های خودش را ارتقا ندهد.
* کف: هیچ داده‌ای زیر کف ۰.۴ هرگز تزریق نمی‌شود.
۴. ادغام منعطف (Fuzzy Merging): برای جلوگیری از نویز، سیستم باید نیات مشابه را ادغام کند. یک برنامه‌ریز ممکن است در یک اجرا بگوید «برو به تب داشبوردها» و در اجرای بعد بگوید «به تب داشبوردها برو». سیستم وقتی هم‌پوشانی توکن‌ها از آستانه ۰.۶ جاکارد فراتر رود، کاندیداها را در موارد مشابه ادغام می‌کند.
۵. وتوی دائمی انسانی: هر اقدامی که توسط انسان رد شود، هرگز باز نمی‌گردد، فارغ از اینکه بعداً چه مقدار شواهد جمع شود. این تنها توقف سخت در سیستم است.
ظرافت‌های پیش‌نیاز
یک قانون ششم ظریف درباره بازیابی وجود دارد. وقتی یک مرحله شکست‌خورده بعداً با برنامه‌ریزی مجدد اصلاح می‌شود، مراحلی که برنامه‌ریزی مجدد در این فاصله درج کرده است، ارزش ذخیره به عنوان «پیش‌نیاز» را دارند. برای مثال، «جست‌وجو برای فیلد» قبل از «کشیدن فیلد»، دانش واقعی است. یادگیری اقدام اتمی به تنهایی باعث می‌شود عامل مرحله‌ای را تکرار کند که هنوز نمی‌تواند کار کند.
حالت شکست خاموش
فراتر از مسمومیت داده‌ها، یک ریسک ساختاری به نام «برنامه‌ریزی خالی» وجود دارد. وقتی دانش یادگرفته‌شده بیش از حد در پرامپت برنامه‌ریز تزریق شود، مدل ممکن است به آستانه‌ای برسد که کلاً دست از برنامه‌ریزی بکشد و یک لیست خالی برگرداند. این یک خطای سنتی نیست؛ پرامپت درست است اما خروجی تهی است.
برای حل این مشکل، بلوک زمینه یادگرفته‌شده باید فشرده بماند:
- اثرات (Effects) حذف شوند.
- ورودی‌ها بر اساس اقدام و هدف تکراری‌زدایی شوند.
- طول متن محدود شود.
- عملیات‌های ساده کشیدن (Drag) و اسکرول کردن کاملاً حذف شوند، زیرا فقط در کنار پیش‌نیازهایشان معنا دارند.
به‌طور حیاتی، سیستم باید یک «مسیر بدون تزریق» به عنوان جایگزین (Fallback) داشته باشد. اگر اولین تلاش با زمینه یادگرفته‌شده یک برنامه خالی برگرداند، عامل باید بدون هیچ زمینه یادگرفته‌شده‌ای دوباره تلاش کند. این کار باعث دور زدن شکست و پاسخ‌های خالی کش‌شده می‌شود و همزمان یک رویداد قابل مشاهده برای اپراتور صادر می‌کند.
نقشه راه پیاده‌سازی
برای کسانی که حلقه‌های عاملی می‌سازند، نویسنده ترتیب خاصی از عملیات را پیشنهاد می‌کند تا از ۶ ماه تلاش بیهوده جلوگیری شود. این ترتیب تقریباً عکس چیزی است که ساختنش «لذت‌بخش» است:
۱. ثبت احکام تأییدکننده: هر حکم را به ازای هر اقدام، به همراه دستور و نتیجه ذخیره کنید. تا زمانی که این وجود نداشته باشد، نمی‌توانید هیچ چیزی را اندازه بگیرید.
۲. اندازه‌گیری نرخ موفقیت بر اساس نوع اقدام: این کار را قبل از ساخت هرگونه سیستم یادگیری انجام دهید. یک عدد کلی این حقیقت را که «کشیدن» در ۰٪ است پنهان می‌کرد، در حالی که این موضوع اساساً تغییر می‌دهد که بعداً چه چیزی باید ساخته شود.
۳. تفکیک عامل و تأییدکننده در خانواده‌های مدل: حتی اگر هزینه بیشتری داشته باشد، این ارزان‌ترین راه برای دستیابی به صحت است و بازسازی آن در مراحل بعدی سخت‌تر است.
۴. ذخیره اقدامات تأییدشده به عنوان پیش‌فرض (Priors): تنها در این مرحله باید از اقدامات تأییدشده پشت یک کفِ اعتماد استفاده کنید. این پیش‌فرض باید راهنمایی باشد که مبنی‌ساز را هدایت کند، نه یک دستور سخت‌گیرانه؛ مبنی‌ساز همچنان باید جست‌وجو کند.
۵. حفظ قابلیت مشاهده انسانی: وتوی انسانی و لیستی قابل مشاهده از آنچه سیستم فکر می‌کند یاد گرفته است را حفظ کنید. اگر نتوانید به انسان نشان دهید عامل چه چیزی یاد گرفته، نمی‌توانید آن را عیب‌یابی کنید.
نتیجه‌گیری
عامل‌های خود-بهبودبخش اغلب طوری بحث می‌شوند که انگار بخش سخت آن، الگوریتم یادگیری است. در واقعیت، یادگیری نیمی از مسیر و بخش آسان است. نیمه سخت این است که سیگنال نظارتی گاهی اشتباه است و شما نمی‌توانید تشخیص دهید چه زمانی. هر مکانیزمی که ارزش ساختن داشته باشد، در واقع حفاظی در برابر آن سیگنال است، نه صرفاً استفاده از آن.
برچسب را قبل از اعتماد اندازه بگیرید، عامل را از بررسی‌کننده جدا کنید تا اشتباهاتشان با هم موافق نباشند، و مسیری را نگه دارید که وقتی زمینه یادگرفته‌شده خالی است، کار کند. اگر این کار را بکنید، برچسب رایگان واقعاً رایگان است. در غیر این صورت، سیستمی ساخته‌اید که با اعتمادبه‌نفس بیشتر، بدون اینکه درست‌تر شود، اشتباه می‌کند؛ چیزی که قطعاً بدتر از سیستمی است که با آن شروع کردید.
گفتگو