بازجویی از مدل یک روش بازبینی است

رویه

توصیف رایج کار با agentهای LLM این است که برخی افراد «فقط مدل را می‌کاوند» در حالی که دیگران اولین پاسخ را می‌پذیرند. این چارچوب‌بندی، بازجویی را یک خصلت می‌داند. چنین نیست. بازجویی یک روش بازبینی است: مجموعه‌ای تعریف‌شده از پرسش‌ها که پیش از آنکه یک خروجی به‌عنوان نتیجه به شمار آید، از آن پرسیده می‌شود. این تمایز اهمیت دارد زیرا روش‌ها را می‌توان نوشت، تخصیص داد، نمونه‌گیری کرد، ممیزی کرد و بهبود بخشید. خصلت‌ها را نمی‌توان.

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

این همان حرکتی است که یک code review خوب انجام می‌دهد. یک pull request به این دلیل merge نمی‌شود که diff محتمل به نظر می‌رسد؛ به این دلیل merge می‌شود که نویسنده می‌تواند توضیح دهد چرا این تغییر و نه تغییری دیگر، به چه چیزی وابسته است، و چگونه آزموده می‌شود. خروجی agent سزاوار همان برخورد است، و پوشش اخیر تیم‌هایی که از خروجی مدل بازجویی می‌کنند به‌جای اعتماد به پاسخ‌های نخست، توصیفی است از گسترش این انضباط، نه ظهور یک تیپ شخصیتی.

بازجویی در واقع چه می‌پرسد

یک بازجویی سودمند چهار پرسش دارد، و این پرسش‌ها در دسته‌های مختلف وظیفه تعمیم می‌یابند:

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

پرسش چهارم همان چیزی است که بازبینی را از دلجویی جدا می‌کند. پاسخی که با هیچ مشاهده در دسترسی ابطال‌پذیر نباشد، ادعا نیست؛ بیانی از قصد است. بازبینان باید با آن به همان ترتیب برخورد کنند.

این روش تنها زمانی کار می‌کند که agent بتواند مصنوعات میانی را آشکار کند. اگر retrieval، استفاده از ابزار و انتخاب شاخه درون یک جعبه سیاه رخ دهد و تنها متن نهایی منتشر شود، بازجویی چیزی برای چنگ زدن ندارد. بازبین به درخواست از مدل برای درون‌نگری تقلیل می‌یابد، که روایت محتمل تولید می‌کند نه شواهد. بنابراین الزام مهندسی بالادست بازبینی قرار دارد: اجرا باید ابزارگذاری شود تا مصنوعات برای نمایش وجود داشته باشند.

Close-up of woven blue carbon fibre textile with a subtle wave pattern and soft texture

چه چیزی باید ثبت شود تا این کار ممکن شود

سه دسته از سوابق بازجویی را ممکن می‌کنند. هیچ‌یک اختیاری نیست اگر قرار باشد روش چیزی بیش از نمایش باشد.

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

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

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

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

تبدیل آن به یک دروازه بازبینی

White smoke swirling into organic shapes against a black background است.

Server rack closeup

نخست، مجموعه کوچکی از پرسش‌های بازجویی برای هر دسته وظیفه تعریف کنید. یک وظیفه پرسش‌وپاسخ متمرکز بر retrieval به پرسش‌های منشأ و نسخه نیاز دارد. یک وظیفه برنامه‌ریزی به پرسش‌های گزینه‌های جایگزین و ابطال نیاز دارد. یک وظیفه متمرکز بر ابزار به پرسش‌های ساخت ورودی و مدیریت خطا نیاز دارد. مجموعه را کوچک نگه دارید — سه تا پنج پرسش برای هر دسته — تا پاسخ دادن به آن‌ها یک گام روتین باشد نه یک پروژه.

دوم، پاسخ‌ها را پیش از آنکه یک اجرا کامل علامت‌گذاری شود الزامی کنید. این یک گذار وضعیت است، نه یک پیشنهاد. اجرایی که نمی‌تواند به پرسش‌های دسته خود پاسخ دهد کامل نیست؛ در حالت انتظار است، و ارجاع داده می‌شود. این ارجاع همان سیگنال است: agentی که نمی‌تواند به پرسشی که باید بتواند پاسخ دهد پاسخ دهد، چیز مشخصی درباره retrieval یا ابزارگذاری خود به شما گفته است.

سوم، اجراها را با نرخ ثابت برای بازجویی انسانی نمونه‌گیری کنید. دروازه‌های خودکار شکست‌های ساختاری را می‌گیرند؛ انسان‌ها شکست‌های معنایی را. یک نرخ نمونه‌گیری ثابت — هر اجرا در یک دسته پرپیامد، کسری در دسته‌های کم‌پیامدتر — بار بازبینی انسانی را قابل پیش‌بینی و پوشش را صادق نگه می‌دارد.

ارزشمندترین خروجی این دروازه داوری فردی نیست. پرسش تکرارشونده بی‌پاسخ است. هنگامی که یک پرسش در بسیاری از اجراها شکست می‌خورد، اصلاح به retrieval یا ابزارگذاری تعلق دارد، نه به وصله prompt. وصله promptی که agent را وادار می‌کند پاسخی را روایت کند که ندارد، از خود شکست بدتر است، زیرا سیگنال را حذف می‌کند.

محدودیت‌ها و بده‌بستان‌ها

اطمینان خودگزارش‌شده شواهد نیست. هنگامی که agent می‌گوید مطمئن است، آن یک دنباله token تولیدشده است، نه یک اندازه‌گیری. این روش به مصنوعات بیرونی وابسته است — بازه‌های بازیابی‌شده، خروجی‌های ابزار، سوابق شاخه — و جایی که این‌ها وجود ندارند، بازجویی به درخواست از مدل برای توصیف خود تنزل می‌یابد. آن توصیف باید به‌عنوان یک ادعا ثبت شود، نه به‌عنوان یک یافته.

بازجویی همچنین latency و هزینه می‌افزاید. تولید سوابق اجرای ساختاریافته، نگه داشتن شاخه‌های ردشده، و پاسخ دادن به پرسش‌های دروازه همه compute و حافظه مصرف می‌کنند، و نمونه‌گیری انسانی زمان بازبین را مصرف می‌کند. به همین دلیل است که روش ابتدا به مسیرهای پرپیامد تعلق دارد: تصمیم‌هایی که بازگرداندنشان پرهزینه است، خروجی‌هایی که به مشتریان می‌رسند، یا کنش‌هایی که به سیستم‌های production دست می‌زنند. مسیرهای کم‌پیامدتر می‌توانند با ابزارگذاری سبک‌تر اجرا شوند تا زمانی که رویه تثبیت شود و ابزارگذاری به‌قدر کافی ارزان شود که گسترش یابد.

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

این فرایند بازبینی را کجا می‌گذارد

چارچوب‌بندی‌ای که باید بازنشسته شود این است که برخی مهندسان از مدل‌ها بازجویی می‌کنند و برخی نه. چارچوب‌بندی‌ای که باید پذیرفته شود این است که بازجویی یک دروازه با پرسش‌های تعریف‌شده، مصنوعات تعریف‌شده و ارجاع تعریف‌شده است. این دروازه تفاوت میان یک رویه ارزیابی و یک نظر است. همچنین تنها نسخه‌ای از این رویه است که از تغییر پرسنل، تغییر مدل، یا تغییر دسته وظیفه جان سالم به در می‌برد — یعنی تنها نسخه‌ای که ارزش ساختن دارد.

بازجویی از مدل یک روش بازبینی است، نه یک ویژگی شخصیتی