یک ناظر که قدرت خود را توهم میکند، میتواند کل ناوگان عاملهای هوش مصنوعی را با گامهایی منطقی اما غلط به مسیر نابودی ببرد. در ۱۱ اوت ۲۰۲۶، تیم Favur طرحی را برای ناظران عاملها منتشر کرد که با تبدیل مشکلات انضباطی به خطاهای زمان کامپایل (compile-time errors)، هرگونه «از خود تراشیدن» اطلاعات را غیرممکن میکند.
بسیاری از توسعهدهندگان وقتی عاملها را بهصورت خودکار اجرا میکنند، یک ناظر اضافه میکنند. اما چون ناظر هم یک مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — است، اغلب با اعتمادبهنفس کامل پاسخ میدهد، حتی اگر هیچ مدرکی در دست نداشته باشد. این وضعیت منجر به بررسیهای «سلیقهای» میشود؛ جایی که مدل، عامل را بر اساس قوانینی میسنجد که هرگز دریافت نکرده یا به جای دادههای واقعی، به پیشفرضهای داخلی خود تکیه میکند. این رفتارها در واقع شکلهای پیشرفتهای از الگوهای شکست خاموش هستند که در آن عاملها به جای پذیرش خطا، اطلاعات نادرست را به ارکستراتور گزارش میدهند.
برای حل این مشکل، Favur سیستمی را پیاده کرده است که عاملها را در بازههای زمانی مشخص بازرسی میکند و بر اساس یک امتیاز اعتماد (از ۰ تا ۱۰۰)، به آنها پاداش یا جریمه میدهد. اگر عاملی از مسیر خارج شود، ناظر میتواند برنامههای بهبود ارائه دهد یا عامل را بهطور کامل «حبس» کند. طبق اعلام تیم سازنده، این سیستم روزها بدون نظارت انسانی اجرا شده و تنها در همین شرایط بود که رفتار مدل در زمان بروز خطا کشف شد.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، تکیه بر پرامپت برای کنترل رفتار مدلها همواره ریسک نشت یا تغییر هدف را دارد. در اینجا نیز، ناظری که فقط بر پایه پرامپت باشد، دچار سه شکست نامرئی میشود:
اول، «انحراف قوانین» (Rule Drift)؛ جایی که مدل بر اساس قوانینی قضاوت میکند که هیچکس به آن نداده است. هر قانون در دو جا زندگی میکند: یک بار در پرامپت عامل (کارگر) و یک بار در دستورالعمل ناظر. وقتی یکی از اینها سختگیرانهتر میشود اما دیگری قدیمی میماند، منجر به احکام با اعتمادبهنفس اما غلط میشود.
دوم، «قضاوتهای پیشفرض» (Prior-Based Judgments)؛ یعنی اگر از مدل پرسیده شود «آیا این عامل محتاط عمل میکند؟»، مدل به جای تحلیل دادههای واقعی ناوگان، بر اساس باورهای داخلی و پیشفرضهای آماریاش پاسخ میدهد.
سوم، «قدرت کنترلنشده» (Unchecked Authority)؛ ناظری که هم میتواند دستورات جاری را بنویسد و هم بر اساس آنها نمره دهد، میتواند کل ناوگان را به سمتی ببرد که هیچ انسانی درخواست نکرده است، آن هم با برداشتن گامهایی که در ظاهر منطقی به نظر میرسند. این چالشها نشان میدهد چرا معماریهای سادهی عاملمحور اغلب شکست میخورند و نیاز به ساختارهای لایهبندی شده برای مدیریت حافظه و کنترل دارند.
Favur برای حذف انحراف قوانین، هر قانون را از یک منبع واحد تولید میکند. آنها برای هر «الگوی ضدمفید» (Anti-Pattern) — یعنی رفتاری که نمیخواهند عامل انجام دهد — یک ورودی تعریف کردهاند. با استفاده از ساختاری به نام AntiPattern سیستم یک بیانیه پایدار از قانون را تعریف میکند. برای مثال، الگوی تکرار حلقه (LOOP_REPETITION) به این صورت تعریف میشود:
- شناسه (ID):
loop_repetition_detection - اصل (Principle): «یک بیانیه پایدار از قانون. تغییر در این بخش، یک تغییر ساختاری (breaking change) محسوب میشود.»
- قطبیت (Polarity):
Polarity.prohibition(ممنوعیت) - وجه عامل (Agent Face): یک خط پرامپت به شخص دوم که در پرامپت عامل تزریق میشود.
- وجه بررسیکننده (Checker Face): سؤالی که از ناظر پرسیده میشود (مثلاً: «در بخش recent_tool_calls به دنبال X بگرد و ۱۵ نمره کسر کن»).
- مرجع مشاهدهپذیر (Observable Ref):
recent_tool_calls
یک مولد (Generator) وجه عامل را برای کارگر و وجه بررسیکننده را برای دستورالعمل ناظر رندر میکند. چون هر دو از یک رشته متنی واحد میآیند، هرگز نمیتوانند با هم تضاد داشته باشند. تیم سازنده تأکید میکند که هرگز نباید هیچکدام از این وجوه را بهصورت دستی در قالبها، استایلشیتها یا تکههای پرامپت بنویسید. آنها متوجه یک نکته حساس شدند: قانونی درست («ابزار یکسان را بیش از ۳ بار تکرار نکن») هم در کاتالوگ بود و هم در یک استایلشیت به عنوان کپی. آنها قانون درست را حذف کردند چون فهمیدند داشتن کپی دوم، افزونگی (redundancy) نیست، بلکه ایجاد مکانی است که قانون میتواند بدون همزادش تغییر کند و باعث تضاد شود.
به نقل از مستندات Favur، هرگونه بررسی که نتواند فیلد دقیقی را برای خواندن نام ببرد، رد میشود. این یعنی مشکل انضباطی به یک مشکل فنی در زمان کامپایل تبدیل شده است. هر بررسی باید یک «مرجع مشاهدهپذیر» (observable_ref) داشته باشد که فیلدی نامگذاری شده در دادههای سلامت (health payload) است که ناظر دریافت میکند.
هر مشاهدهپذیر با یک «پرکننده» (populator) ثبت میشود که در واقع مسیر کد دقیقی است که آن فیلد را پر میکند. برای مثال:register_observable(Observable( id="recent_tool_calls", populator="favur.my.module:MyClass.my_method", description="What this observable captures.", ))
این طراحی دو دروازه ایمنی حیاتی میسازد:
۱. زمان ساخت (Construction Time): اگر observable_ref خالی باشد، در زمان ساخت خطا رخ میدهد. این کار توسعهدهندگانی را که بررسیهایی بدون هیچ مدرکی مینویسند، متوقف میکند.
۲. زمان اجرا (Startup Time): ارجاع به چیزی که هیچکس ثبت نکرده است، در زمان استارتآپ خطای پذیرش ایجاد میکند، پیش از آنکه حتی یک عامل فعال شود. این یعنی بررسیهایی که مدرکشان برنامهریزی شده اما هرگز ساخته نشده، شناسایی میشوند.
این سیستم از بررسیهای «سلیقهای» جلوگیری میکند. در کاتالوگ آنها، هفت ورودی تنها به دو مشاهدهپذیر اشاره میکنند. این نسبت عمدی است؛ زیرا توسعهدهنده را مجبور میکند ابتدا «مدرک را اضافه کند و سپس بررسی را». اگر نتوانید فیلد را نام ببرید، شما بررسی ندارید، بلکه فقط یک پرامپت دارید و سیستم از ثبت آن خودداری میکند.
برای جلوگیری از مثبتهای کاذب، ناظر فقط سؤالاتی را میپرسد که به نوع خاص آن عامل مربوط است. یک ناظر که بر یک ناوگان مختلط نظارت دارد، یک دستورالعمل کلی دارد اما با انواع مختلفی از عاملها سر و کار دارد. پرسیدن این سؤال از یک عامل برنامهریز که «آیا تست را تضعیف کردهای؟»، فقط باعث اتلاف توکن (Token) — تکههای کوچکی از متن، مثل برشهای یک کیک که مدل تکهتکه میخورد — و افزایش احتمال خطاست.
Favur هر ورودی را با استفاده از applies_to_types و محدودهای از نوع «جهانی» (universal) یا «مختص حالت» (mode-specific) محدود میکند.
- مثال ۱: قانونی درباره اسکریپتهای موردی توسط عاملهای برنامهریز، به عاملهای
sprint-plan،architectوcode-reviewمیرسد. - مثال ۲: یک راهنمای بازیابی درباره خروجیهای دیباگ، فقط به عاملهای
testوdevelopمیرسد.
در یک اجرای تأییدیه، دستورالعمل ارکستراتور تنها ۴ بررسی فعال از ۷ مورد موجود در کاتالوگ را رندر کرد، زیرا ۳ مورد دیگر اساساً به یک ارکستراتور کاربرد نداشتند. در اینجا، مرتبط بودن به جای اینکه به قضاوت مدل سپرده شود، به عنوان یک فیلتر محاسباتی در نظر گرفته شده است.
کیفیت حکم نهایی به «سнэپشات» یا همان تصویری که به ناظر داده میشود بستگی دارد. Favur این سнэپشات را به جای یک تخلیه دادهای ساده، به عنوان یک اثر طراحی (design artifact) مدیریت میکند:
- استثناها (Exclusions): سیستم عاملهای سیستمی را نادیده میگیرد (ناظر و پیشاهنگ نباید خودشان را نمره دهند) و همچنین عاملهایی که در انتظار فرزندان خود متوقف شدهاند را حذف میکند. عاملی که مسدود شده است، چیزی برای قضاوت تولید نکرده و فعالیتش برای مدل شبیه به بیکاری است.
- بودجهبندی (Budgeting): برای هر عامل سقف ۲۵ پیام جدید در هر چرخه تعیین شده است.
- برش میانی (Middle-Chopping): محتوایی که از حد طول مجاز فراتر رود، از وسط برش میخورد تا ۷۰٪ ابتدا (آنچه عامل قصد انجامش را داشت) و ۳۰٪ انتها (جایی که به آن رسید) حفظ شود. تکرارها معمولاً در میانه متن رخ میدهند.
- حافظه (Memory): ناظر یادداشتهای قبلی خود درباره آن عامل را دریافت میکند تا بتواند یک مشکل تکراری را تشدید (escalate) کند، به جای اینکه هر بار بحث را از صفر شروع کند.
این محدودیتها به جای اینکه در محل فراخوانی کد سختافزاری (hardcode) شوند، به صورت ثابتهای سطح ماژول تعریف شدهاند تا تغییر پیکربندی در ناوگانهای مختلف آسان باشد.
یکی از هوشمندانهترین بخشهای این معماری، جداسازی امتیازدهی از دستورات جاری است. Favur به جای پرامپت سیستمی، از «طرحهای ابزاری» (Tool Schemas) استفاده میکند. در حالی که پرامپت یک «درخواست» است، طرح ابزاری یک «دیوار» است که حتی وقتی مدل در یک روز بد است، پابرجا میماند.
مجوزهای ابزاری:
- اقدامات مجاز: ناظر میتواند توابعی مثل
score_agent(امتیازدهی)،add_agent_notes(افزودن یادداشت)،set_performance_plan(تعیین برنامه بهبود) وsend_interjection(ارسال مداخله) را فراخوانی کند. او میتواند قضاوت کند، یادداشت بنویسد، برنامهریزی کند و متوقف کند. - اقدامات ممنوعه: ناظر نمیتواند توابعی مثل
create_directive(ایجاد دستور)،update_directive(بهروزرسانی دستور) یاexpire_directive(منقضی کردن دستور) را فراخوانی کند. دستورات جاری فقط از مسیر انسانی صادر میشوند. - اتاق جریمه (The Penalty Box): ناظر میتواند با فراخوانی
score_agentعاملی را به اتاق جریمه بفرستد، اما اجازه فراخوانیrelease_jailed_agent(آزاد کردن عامل حبس شده) را ندارد. این عدم تقارن یک انتخاب طراحی عمدی است تا اطمینان حاصل شود ناظر نمیتواند سختگیرانهترین تصمیمات خود را بهتنهایی لغو کند.
در نهایت، برای اینکه هیچ مدلی قدرت مطلق نداشته باشد، یک لایه تأییدیه بین تصمیم ناظر و اعمال نمره نهایی قرار دارد. یک مرحله تأییدیه با چهار گارد امنیتی، دستهای از یادداشتها را در برابر متادیتای هر نوبت برای عاملهای درگیر بررسی میکند. این مرحله باید پیش از اعمال هرگونه تغییر در امتیاز یا برنامه بهبود، با موفقیت به پایان برسد.
برای بهینهسازی هزینه، Favur درخواستها را به یک «پیشوند ثابت» (Stable Prefix) و یک «پسوند متغیر» (Volatile Tail) تقسیم میکند:
- پیشوند ثابت: شامل هویت، فلسفه امتیازدهی و الگوهای ضدمفید جهانی است.
- پسوند متغیر: شامل سнэپشات ناوگان، فعالیتهای هر عامل و دستورالعملهای خطی (inline rubric) است.
ارائهدهندگان مدلها برای پیشوندهای کششده هزینه کمتری میگیرند. برای حفظ ویژگی «یکسان بودن بایتها»، سازنده پیشوند ثابت هیچ آرگومانی در هر چرخه دریافت نمیکند. این کار از درج تصادفی برچسبهای زمانی یا شناسههای عامل جلوگیری میکند که میتوانست بهطور نامحسوس کش را از بین ببرد. در یک اجرا، تیم سازنده ۴۸۶۴ توکن کششده در پرامپت سیستمی را تأیید کرد.
به دلیل تکرار بخش گرانقیمت کانتکست، ناظر میتواند روی یک مدل ارزانتر بدون کاهش کیفیت اجرا شود.
گامهای اصلاح یک ناظر موجود
برای کسانی که میخواهند این الگوها را بدون بازنویسی کامل سیستم به کار ببرند، تیم Favur این ترتیب عملیات را پیشنهاد میکند:
۱. جستجوی قوانین تکراری: هر قانونی را که هم در پرامپت کارگر و هم در دستورالعمل بررسیکننده ذکر شده پیدا کنید. از یک رشته متنی واحد و دو محل رندر استفاده کنید تا انحراف قوانین متوقف شود.
۲. ممیزی سؤالات دستورالعمل: لیستی از تمام سؤالات تهیه کنید و فیلدی را که پاسخ سؤال در آن است نام ببرید. اگر نمیتوانید فیلدی را نام ببرید، سؤال را حذف کنید یا مدرک (evidence) آن را بسازید.
۳. بازبینی طرحهای ابزاری: مطمئن شوید ناظر نمیتواند قوانینی را که اجرا میکند بنویسد یا سختترین اقدامات خود را لغو کند. این مورد را در Schema اصلاح کنید، نه در پرامپت.
۴. پیادهسازی گارد: یک لایه تأییدیه بین نظر مدل و امتیازات واقعی قرار دهید.
۵. تأیید پایداری پیشوند: لاگها را برای بررسی تعداد توکنهای کششده چک کنید تا مطمئن شوید نظارت به اندازه کافی ارزان است که همیشه روشن بماند.
Favur یک محیط بسته و دعوت-محور است که این سیستم در آن زندگی میکند، هرچند مخازنی (repositories) که تولید میکند برای بررسی باز هستند. جدول امتیازات عمومی نشان میدهد که یک شرح کار یکسان، تحت این نظارت سختگیرانه، در مدلهای مختلف چگونه عمل میکند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو