اگر تصور میکنید با ارتقای مدل زبانی خود به نسخهای هوشمندتر، تمام خطاهای عاملهایتان ناپدید میشود، سخت در اشتباهید. حقیقت این است که تکیه بر حافظه داخلی مدل برای اصلاح خطاها، بزرگترین دروغ در توسعهی عاملهای هوش مصنوعی است.
به نقل از وو جی (Wu Ji)، متخصص مهندسی AI، محدودیتهای نرم (Soft Constraints) بهشدت ناپایدارند و بهسرعت محو میشوند؛ بنابراین باید دست از تکرار جملهی «دفعه بعد دقت کن» در پرامپتها بردارید. او در راهنمای جامع خود که در ۱ اوت ۲۰۲۶ منتشر شد، مفهوم «لایه نشانی اصلاحات» (Correction Sedimentation) را بهعنوان مرز میان نمونههای اولیه آزمایشگاهی و سامانههای تجاری پایدار معرفی کرد. در حالی که پروتوتایپها به حافظهی ناپایدار مدل وابستهاند، سامانههای صنعتی برای تضمین عدم تکرار خطا، به یک لایهی مهندسیشده نیاز دارند تا اطمینان حاصل شود که هیچ اشتباهی هرگز تکرار نمیشود.
تلهی محدودیتهای نرم
وقتی یک عامل (Agent) — شبیه به کارمندی است که وظایفی را بهصورت خودکار انجام میدهد — اشتباه میکند و توسعهدهنده میگوید «دفعه بعد دقت کن»، عامل معمولاً پاسخ میدهد «متوجه شدم، یاد میگیرم». اما یک هفته بعد، همان خطا با ظاهری جدید بازمیگردد.
این اتفاق به این دلیل رخ میدهد که حافظهی یک مدل زبانی بزرگ (LLM) — که مثل کتابخانهداری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — یک محدودیت نرم است. این حافظه از سه شکست اصلی رنج میبرد:
- در گفتگوهای چندمرحلهای (Multi-turn dialogs) فراموش میشود. در این زمینه، استفاده از فایلهای حافظه محلی میتواند راهکاری برای توقف بازنشانی زمینه در جلسات طولانی باشد.
- در متنهای طولانی، تمرکز یا توجه (Attention) مدل دچار پراکندگی میشود و از مسیر خارج میگردد.
- تحت فشار، مدل به حالت تولید «راحتترین» و رایجترین پاسخهای خود بازمیگردد.
وقتی به مدل میگویید «به یاد داشته باش»، مدل تنها در همان لحظه موافقت میکند. مدلهای زبانی فاقد توانایی جاسازی (Embed) یک قانون در سطح سیستم هستند. بنابراین، همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، برای خروج از این وضعیت باید از «درمان علائم» به «ایجاد محدودیتهای سخت» کوچ کنیم.
این کار شبیه نصب نردههای ایمنی در یک ساختمان است؛ شما به مردم نمیگویید «مراقب باشید سقوط نکنید»، بلکه مانعی فیزیکی میسازید که سقوط را غیرممکن کند. این رویکرد، هدف را از «هرگز اشتباه نکردن» به «بهبود خودکار پس از هر اشتباه» تغییر میدهد.
حلقهی پنجمرحلهای لایهنشانی
بر اساس گزارش dev.to، فرآیند لایهنشانی اصلاحات به صورت یک حلقه بسته عمل میکند که هر اصلاح انسانی را به تکامل سیستم تبدیل میکند. این فرآیند از پنج مرحله متمایز پیروی میکند:
۱. وقوع خطا: عامل خروجی غیرمجاز تولید میکند. این خروجی یا توسط یک گیت (Gate) متوقف میشود یا توسط یک توسعهدهنده انسانی شناسایی میگردد.
۲. ثبت: خطا در یک مخزن ذخیرهسازی شکستها (Failure Store) ثبت میشود. این فقط یک پیام خطا نیست، بلکه شامل جزئیات صحنه، زنجیره فراخوانی ابزارها (Tool-call chain)، خلاصهای از زمینه و نوع خطا است. برای مثال، توسعهدهنده ممکن است دستوری مانند این اجرا کند:failure_capture.py --record --scene email --tool-calls '["fetch_inbox", "send_email"]' --error "user asked to forward the email to sunny, but the agent queried shipping costs"
۳. استخراج علت ریشهای: تحلیل بر روی خلأ سیستمی تمرکز میکند، نه توصیف سطحی. بهجای گفتن اینکه «عامل از ابزار اشتباه استفاده کرد»، علت ریشهای اینگونه شناسایی میشود: «ابزار smtp_send در لیست سفید ابزارهای صحنه ایمیل موجود نیست». این نوع توهمات در هنگام تعامل با ابزارها، ریشه در شکاف قصد و عمل دارد که باعث میشود مدلها اجرای ابزار را شبیهسازی کنند بهجای اجرای واقعی آنها.
۴. جاسازی قانون: علت ریشهای به یک محدودیت اجرایی سیستم تبدیل میشود. این کار شامل اصلاح تنظیمات صحنه (SCENE_CONFIG) است.
- قبل از سختسازی:
SCENE_CONFIG = { "email": { "tools": ["imap_fetch", "contact_lookup"] } }(در اینجا smtp_send غایب است). - بعد از سختسازی:
SCENE_CONFIG = { "email": { "tools": ["imap_fetch", "smtp_send", "contact_lookup"], "gates": ["check_forward_intent"] } }(در اینجا smtp_send اضافه شده و یک گیت جدید برای بررسی قصد ارسال پیوست شده است).
۵. عدم تکرار: زمانی که قانون جاسازی شد، سیستم بهطور خودکار جلوی خطا را میگیرد. خطا غیرممکن میشود و دیگر هیچکس نیاز به «دقت کردن» ندارد.
فیزیکیکردن قوانین
برای موفقیت این سازوکار، قوانین باید در لایهی سیستم «فیزیکی» شوند. نوشتن اصلاحات در پرامپت کافی نیست، زیرا توجه LLM در زمینههای طولانی کاهش مییابد. در عوض، قانون باید در قالب یک اسکریپت نوشته شود. مخزن خطاها بین گیتها و چهار هدف جاسازی خاص قرار میگیرد:
- اسکریپتهای تأیید: برای مثال، اسکریپت
verify/no_fabricated_data.pyیک بررسی خودکار پیش از نهایی شدن خروجی انجام میدهد تا دادههای جعلی حذف شوند. - بازبینی گیتها: گیتهای جدید در
gate-check.shعامل را در گرههای حیاتی متوقف میکنند تا مسیرهای نامعتبر مسدود شوند. - لیست سفید ابزارها: اضافه یا حذف ابزارها در
SCENE_CONFIGبرای ممنوع کردن برخی اقدامات در منبع. - تزریق SOP: بهروزرسانی دستورالعملهای استاندارد عملیاتی (SOP) صحنه، بهطوری که درست پیش از اجرا در سیستم تزریق شود.
پیادهسازی فنی و نگهداری
نویسنده برای مدیریت این اصلاحات، یک اسکیمای FailureRecord را با استفاده از دیتاکلاسهای پایتون پیشنهاد میدهد تا معیارهایی مانند زمان، شناسه صحنه و وضعیت را ردیابی کند:
from dataclasses import dataclass
@dataclass
class FailureRecord:
timestamp: str
scene_id: str
error_type: str # tool_misuse / format_error / missing_step
description: str # human description
root_cause: str # root-cause analysis
fix_rule: str # the embedded rule
status: str # pending / embedded
جاسازی یک اقدام یکباره نیست؛ قوانین ممکن است تحلیل شوند و انواع خطاهای جدید ظاهر شوند. این امر نیازمند یک برنامه بازبینی منظم است. هر دوشنبه، توسعهدهندگان باید با اجرای دستور scan_corrections.py --unembedded اسکن اصلاحات جاسازینشده را انجام دهند.
هر اصلاحی که جاسازی نشده باشد، دوباره به تحلیل علت ریشهای فرستاده میشود. علاوه بر این، هر قانون جاسازیشده باید از یک مجموعه آزمون رگرسیون (Regression Suite) عبور کند. تأیید رگرسیون این حلقه را میبندد و تضمین میکند که هر قانون پیش از اعتماد در محیط عملیاتی، اثبات شده باشد.
هوشمندی مدل در برابر مهندسی سیستم
یک باور غلط وجود دارد که جابهجایی به مدلهای «هوشمندتر» تمام مشکلات قابلیت اطمینان را حل میکند. در حالی که یک مدل قدرتمندتر نرخ وقوع خطاهای «ناشناخته» را پایین میآورد، اما هرگز بهتنهایی به نرخ موفقیت ۱۰۰٪ نمیرسد.
لایهنشانی اصلاحات، مکمل هوشمندی مدل است:
- مدل قویتر $\rightarrow$ کاهش نرخ وقوع خطاهای ناشناخته
- لایهنشانی اصلاحات $\rightarrow$ حذف نرخ تکرار خطاهای شناختهشده
سامانههای تجاری بهدنبال «هرگز اشتباه نکردن» نیستند، بلکه بهدنبال «بهبود خودکار پس از هر اشتباه» میجنگند. با تبدیل هر اصلاح انسانی به سوخت تکاملی، توسعهدهنده از یک ناظر درمانده به مهندسی تبدیل میشود که مرزهای رفتاری را قفل میکند. روز به روز، سیستم پایدارتر شده و هزینههای نگهداری کاهش مییابد.
مقاله بعدی: آخرین ستون ایمنی — ایزولاسیون ابزار و حداقل دسترسی (Least Privilege)، برای قفل کردن کامل مرزهای رفتاری عامل.
گام بعدی شما
- مخزن خطاهای فعلی خود را بررسی کنید و شناسایی کنید کدام خطاها بیش از ۳ بار تکرار شدهاند.
- بهجای اصلاح پرامپت، یک اسکریپت تأیید (Verify Script) برای خروجیهای حساس بنویسید.
- لیست ابزارهای در دسترس عامل خود را بر اساس «صحنههای کاری» (Scenes) محدود کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو