اگر هر بار مجبورید یک اشتباه تکراری را به عامل هوش مصنوعی خود یادآوری کنید، در واقع در حال مدیریت یک سیستم بیحافظه هستید. این چرخهٔ فرسایشی زمانی میشکند که دستورالعملها را از فضای چت خارج کرده و به یک سند رسمی تبدیل کنید.
به گزارش وبسایت dev.to در ۲۹ اوت ۲۰۲۶، راهکار مقابله با فراموشی مدلها، جایگزینی گفتگوها با یک «قرارداد» (Contract) است؛ یک فایل متنی واحد و نسخهبندیشده که در ابتدای هر جلسه برای مدل بارگذاری میشود. همانطور که در بحثهای گذشتهی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، کنترل دقیق روی ورودیها تنها راه رسیدن به خروجیهای پیشبینیپذیر است. این رویکرد در واقع پاسخی به چالشهای مدیریت حافظه در عاملهاست، مشابه آنچه در راهکار Trigger.dev برای حفظ حافظهٔ عاملها از طریق ماشینهای اختصاصی بررسی کردیم.
بسیاری از کاربران با هوش مصنوعی زاینده (Generative AI) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — بهصورت مجموعهای از درخواستهای لحظهای تعامل میکنند. اما این روش فاقد کنترل نسخه و قابلیت بازرسی است. تفاوت این دو رویکرد شبیه تفاوت یک دفترچه راهنمای شرکتی با تعدادی یادداشت چسبان (Sticky Notes) است؛ دفترچه راهنما تضمین میکند همه کارکنان، فارغ از زمان استخدامشان، از یک استاندارد واحد پیروی کنند. با تبدیل دستورالعملهای عامل (Agent) به یک کد منبع، شما از مدیری که مدام تکرار میکند، به بازرسی تبدیل میشوید که قوانین را بهینهسازی میکند. این بهینهسازی بهویژه در محیطهای توسعه حیاتی است، چرا که جلوگیری از پوسیدگی زمینه میتواند بازدهی عاملهای کدنویسی را بهطور چشمگیری افزایش دهد.
چهار ستون اصلی یک قرارداد
یک قرارداد کارآمد برای جلوگیری از بروکراسی، سطح سختگیری را بر اساس میزان ریسک تنظیم میکند و از چهار نوع دستورالعمل تشکیل شده است:
- همیشه (ALWAYS): اقداماتی اجباری که عامل باید بدون درخواست انجام دهد؛ مثلاً خواندن فهرست فایلها پیش از باز کردن آنها.
- هرگز (NEVER): مرزهای سخت و غیرقابل تغییر؛ مانند ممنوعیت ارسال دادههای شخصی یا دسترسی به حسابهای مالی.
- در صورت شکست (ON FAILURE): الزام به ثبت دلیل دقیق خطا بهجای ورود به حلقههای تکرار بیصدا. نویسنده تأکید میکند که «ساختن جواب برای پر کردن خلأها»، نابخشودنیترین نوع توهم (Hallucination) — وقتی مدل با اطمینان چیزی میگوید که اصلاً وجود ندارد، شبیه دوستی که خاطرهای را اشتباه تعریف میکند — است.
- در مورد اعداد (ON NUMBERS): قانونی که میگوید هیچ عددی نباید بدون ذکر روش محاسبه ارائه شود، در غیر این صورت باید بهعنوان «تأییدنشده» برچسب بخورد.
این چرخش راهبردی، پرسش اصلی را از «آیا کاری را که گفتم انجام دادی؟» به «کدام قانون شکست خورد؟» تغییر میدهد. در این حالت، خطا به مشکلی کوچک و قابل حل تبدیل میشود که حتی یک عامل دوم میتواند آن را تشخیص دهد. وقتی عامل اشتباه میکند، کاربر قانون را یکبار اصلاح میکند و آن دسته از خطاها را برای همیشه از تمام جلسات آینده حذف میکند.
برای کسانی که قصد پیادهسازی این روش را دارند، یک قاعده ساده پیشنهاد شده است: هر اصلاحی که برای دومین بار تکرار شد، باید به یک قانون مکتوب تبدیل شود، وگرنه قطعاً برای بار سوم هم تکرار خواهد شد. این تغییر، رفتار عامل را از یک گفتگوی متزلزل به یک سامانه پایدار و قابل بازرسی تبدیل میکند.
گام بعدی شما
- یک فایل ساده با پسوند
.txtیا.mdایجاد کنید و چهار دستهبندی ذکرشده را در آن بنویسید. - در ابتدای هر تعامل، به عامل دستور دهید این فایل را بهعنوان «محدودیت سیستمی اصلی» بخواند.
- هر خطای تکراری را بلافاصله به یکی از چهار ستون قرارداد تبدیل کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو