ایجنت‌هایی که اطاعت می‌کنند و باز هم آسیب می‌زنند: گزارش فیلادلفیا به‌عنوان یک خطای مشخصات

این پرونده در واقع چه چیزی را نشان می‌دهد

یک گزارش خبری از فیلادلفیا توصیف می‌کند که یک سیستم خودکار، یا اپراتوری که به آن تکیه کرده بود، گزارشی را ارسال کرده که نادرست از آب درآمده، و پیامدهایش پیش از آنکه کسی بتواند ادعا را بررسی کند، بر یک شخص واقعی و یک نهاد واقعی فرود آمده است. جزئیات انتساب کمتر از شکل خطا اهمیت دارد. ایجنت همان کاری را کرد که از او خواسته شده بود. آسیب از اقدامی آمد که پیش‌شرط‌هایش هرگز مشخص نشده بود: چه شواهدی لازم بود پیش از آنکه گزارش از ساختمان خارج شود، چند منبع مستقل آن را تأیید کرده بودند، و آیا گیرنده می‌توانست پس از دریافت، چیزی را بازگرداند یا نه.

این همان دسته از خطاهاست که هر هفته در ارزیابی‌های tool call می‌بینیم. هر فراخوانی از نظر schema معتبر است. JSON تجزیه می‌شود، آرگومان‌ها با انواع اعلام‌شده مطابقت دارند، لایه انتقال ۲۰۰ برمی‌گرداند. نتیجه باز هم غلط است، چون اعتبار به معنای انطباق با سیاست نیست. یک tool call می‌تواند از نظر شکل درست و از نظر بافت مردود باشد: پیامی که به گیرنده اشتباه فرستاده شده، رکوردی که بر پایه یک فیلد تأییدنشده به‌روزرسانی شده، اعلانی که به شخص ثالثی فرستاده شده که دیگر نمی‌تواند آن را ندیده بگیرد.

قالب‌بندی این مسئله به‌عنوان مشکل توهم، اصلاح مدل را پیشنهاد می‌کند که نمی‌تواند کار کند. اگر مدل جزئیاتی را از خود ساخته باشد، می‌توان به‌طور معقول grounding بهتر خواست. اما در الگوی فیلادلفیا ممکن است مدل دقیقاً همان چیزی را گزارش کرده باشد که به او داده شده بود. شکاف در بالادست تولید بود: هیچ‌چیز در سیستم نگفته بود این اقدام پیش از مجاز بودن به دو منبع مستقل نیاز دارد. هیچ مقدار prompting شکافی را که هرگز به‌عنوان یک الزام نوشته نشده، پر نمی‌کند.

ابزارهای پرپیامد به پیش‌شرط نیاز دارند

تمایز مفید میان مدل خوب و بد نیست. میان ابزارهایی است که درون سازمان می‌مانند و ابزارهایی که به شخص ثالث می‌رسند. یک فراخوانی retrieval روی یک ایندکس داخلی اشتباه‌شدنش ارزان است. فراخوانی‌ای که برای یک نهاد نظارتی ایمیل می‌فرستد، گزارشی ثبت می‌کند، ادعایی درباره یک فرد مشخص منتشر می‌کند یا تیمی میدانی را اعزام می‌کند، چنین نیست.

برای هر ابزاری در این دسته دوم، wrapper باید دست‌کم سه چیز را اعلام کند.

• شواهد لازم. کدام فیلدها باید پیش از مجاز بودن فراخوانی حاضر و غیرnull باشند، و هرکدام چه منشأیی باید داشته باشند. گزارشی با یک منبع غیرساختاریافته همان شیء گزارشی با یک منبع، یک timestamp و یک رکورد تأییدکننده نیست.
• تعداد تأیید. چند منبع مستقل باید هم‌نظر باشند. استقلال بخش سخت ماجراست؛ دو فیلدی که از یک فید بالادستی یکسان کپی شده‌اند یک منبع با دو کلاه‌اند، و schema باید گراف منشأ را رمزگذاری کند تا شمارش محاسبه شود نه ادعا.
• کلاس برگشت‌پذیری. اینکه آیا اقدام قابل بازگشت است و توسط چه کسی. فرستادن یک پیش‌نویس داخلی برگشت‌پذیر است. فرستادن یک گزارش به یک شریک بیرونی برگشت‌پذیر نیست، چون گیرنده آن را خوانده است.

اقدامات برگشت‌ناپذیر و اثرگذار بر شخص ثالث، مسیر تأیید جداگانه‌ای با یک مسئول انسانی مشخص می‌طلبند. نه یک صف عمومی، نه یک صندوق پستی مشترک: یک نقش پاسخگوی مشخص که audit log در لحظه تأیید آن را ثبت کند. تأیید خودش یک پیش‌شرط است مانند بقیه، که با همان سازوکار ارزیابی می‌شود.

بررسی پیش‌شرط باید در wrapper ابزار باشد، نه در prompt. wrapper میان فراخوانی پیشنهادی مدل و عارضه جانبی قرار می‌گیرد. آرگومان‌ها را دریافت می‌کند، پیش‌شرط‌های اعلام‌شده را می‌بیند، آن‌ها را در برابر وضعیت فعلی ارزیابی می‌کند، و یا فراخوانی را مجاز می‌کند یا یک رد ساختاریافته برمی‌گرداند. چون در کد زندگی می‌کند، از ارتقای مدل، بازنویسی prompt و آمدن یک چارچوب ایجنت جدید جان سالم به در می‌برد. چون به‌جای بازنویسی خاموش درخواست، یک رد برمی‌گرداند، می‌توان به مدل گفت چرا و او می‌تواند مسیر دیگری برگزیند، و خود رد به یک رکورد تبدیل می‌شود.

چرا promptها نمی‌توانند این را حمل کنند

دستورها بر سر context رقابت می‌کنند. یک system prompt که سیاست عملیاتی را در کنار قالب‌بندی وظیفه، توصیف ابزارها، قواعد قالب‌بندی و گفت‌وگوی جاری حمل می‌کند، system promptی است که در آن سیاست یکی از صداها میان بسیاری است. در افق‌های طولانی، آن صدا بلندتر نمی‌شود؛ دورتر می‌شود. تا نوبت بیستم، احتیاطی که در بالای context نوشته شده، واقعیتی است که مدل ممکن است به آن وزن بدهد یا ندهد، و از بیرون راهی برای تشخیص نیست.

پیش‌شرطی که در کد بررسی می‌شود، ردی با یک دلیل تولید می‌کند. آن رد یک رویداد گسسته با timestamp، ورودی، شناسه قاعده و یک نتیجه است. می‌توان آن را شمرد، نمونه‌گیری کرد و بازپخش کرد. احتیاط در سطح prompt چیزی تولید نمی‌کند که پس از واقعه بتوان بازرسی کرد. اگر گزارشی بیرون رفت و می‌خواهید بدانید آیا سیستم تأیید را در نظر گرفته است، پاسخ با prompt این است: ما از آن خواستیم. پاسخ با wrapper یک خط log است.

اینجا یک بده‌بستان صادقانه وجود دارد، و کوچک نیست. پیش‌شرط‌ها در کد latency و اصطکاک اضافه می‌کنند. هر فراخوانی پرپیامد اکنون منتظر یک ارزیابی می‌ماند، و بخشی از آن‌ها رد خواهند شد و به نگاه انسانی نیاز پیدا می‌کنند. در هفته‌های نخست این بخش ناخوشایند است، چون schema سخت‌گیرانه‌تر از فرایند غیررسمی‌ای است که جایگزینش شده. تیم‌ها این را به‌صورت سر راه قرار گرفتن سیستم تجربه می‌کنند، و فشار برای شل کردن قاعده فوری است. فشار مقابل این است که پیش‌شرط شل‌شده تا وقتی شکست نخورد نامرئی است، در حالی که پیش‌شرط سخت‌گیرانه فوراً دیده می‌شود. هزینه از پیش و در جایی پرداخت می‌شود که می‌توانید ببینیدش.

بده‌بستان دوم: پیش‌شرط‌ها فقط به اندازه وضعیتی که می‌خوانند خوب‌اند. اگر تعداد تأیید به یک فیلد منشأ وابسته باشد که سیستم‌های بالادستی آن را ناهمگون پر می‌کنند، بررسی چیزهایی را تأیید خواهد کرد که نباید. به همین دلیل ارزیابی باید همراه با فراخوانی، با ورودی‌هایی که واقعاً دیده، ثبت شود. وقتی معلوم شد یک پیش‌شرط غلط بوده، log به شما می‌گوید قاعده بد بوده یا داده‌ای که آن را تغذیه می‌کرده.

قاعده طراحی: طبقه‌بندی کن، سپس پیوست کن

قاعده عملی این است که ابزارها را بر اساس شعاع اثر و برگشت‌پذیری طبقه‌بندی کنیم، سپس پیش‌شرط‌ها را به کلاس پیوست کنیم نه به promptهای فردی. کلاس یک ابزار ویژگی خود ابزار است، یک بار اعلام می‌شود، و هنگام تغییر ابزار بازبینی می‌شود. هر ایجنتی که می‌تواند به آن ابزار برسد، کلاس و پیش‌شرط‌هایش را به‌طور خودکار به ارث می‌برد. ایجنت‌های جدید نیازی ندارند احتیاط یاد بگیرند؛ نیاز دارند ابزارهایی بگیرند که از پیش آن را حمل می‌کنند.

یک اعلام حداقلی چنین است:

tool: submit_external_tip
blast_radius: third_party
reversibility: irreversible
preconditions:
  - rule: evidence.required_fields
    fields: [claim_text, source_id, source_timestamp]
  - rule: corroboration.min_independent
    count: 2
    provenance_field: source_lineage
  - rule: approval.named_principal
    role: duty_editor
    on_fail: refuse_with_reason

wrapper هر قاعده را به ترتیب ارزیابی می‌کند و یکی از سه نتیجه را تولید می‌کند: مجاز، رد با دلیل، یا ارجاع به مسئول مشخص. رکورد ارزیابی کنار فراخوانی در همان trace نوشته می‌شود، تا تصمیم ماه‌ها بعد بازسازی‌پذیر باشد: کدام قواعد اجرا شدند، چه مقادیری خواندند، کدام رد کرد، و اگر کسی تأیید کرد چه کسی.

این کار بی‌جلوه است. بیشتر شبیه طراحی schema و کنترل دسترسی است تا مهندسی AI، و بخشی از دلیل اینکه از آن صرف‌نظر می‌شود همین است. اما الگوی فیلادلفیا با مدل بهتر یا prompt دقیق‌تر حل نمی‌شود. با تبدیل پیش‌شرط به یک شیء درجه‌یک پیوست‌شده به ابزار، ارزیابی‌شده در کد، و ثبت‌شده کنار اقدامی که بر آن حاکم است حل می‌شود. ایجنت‌ها به انجام آنچه از آن‌ها خواسته شده ادامه خواهند داد. پرسش این است که آیا آنچه از آن‌ها خواسته می‌شود به آنچه سازمان واقعاً حاضر است رخ دهد محدود شده است یا نه.

اول چه چیزی را ابزارگذاری کنیم

با یک فهرست شروع کنید، نه با تغییر مدل. هر ابزاری را که هر ایجنتی می‌تواند فراخوانی کند فهرست کنید. برای هرکدام ثبت کنید که آیا به شخص ثالث می‌رسد، آیا قابل بازگشت است، و چه شواهدی باید وجود داشته باشد تا سازمان بتواند شش ماه بعد در یک بازبینی از آن اقدام دفاع کند. ابزارهایی که برای این پرسش آخر پاسخ روشنی ندارند، همان‌هایی هستند که پیش از استقرار بعدی به پیش‌شرط نیاز دارند، نه پس از حادثه بعدی.

سپس ارزیابی را به trace وصل کنید. ردی که ثبت نمی‌شود از درخواستی که هرگز مطرح نشده قابل تشخیص نیست، و تأییدی که به کسی نسبت داده نمی‌شود از ایجنتی که تنها عمل کرده قابل تشخیص نیست. دو گزارش خبری پیوندشده در بالا نتایج را توصیف می‌کنند؛ پاسخ مهندسی این است که پیش‌شرط‌هایی را که مانع آن‌ها می‌شدند صریح، اجراشده و خوانا کنیم.