شکست معمولاً در مرز رخ می‌دهد
وقتی یک ایجنت ابزاری را فراخوانی می‌کند و فراخوانی اشتباه پیش می‌رود، غریزه اول سرزنش مدل است. پرامپت به‌اندازه کافی واضح نبود، استدلال سطحی بود، کانتکست نویزی بود. در عمل، سهم بزرگی از این شکست‌ها پیش از آنکه مدل اصلاً استدلال کند تعیین می‌شود: در اسکیمای ابزار. اسکیما قرارداد میان مدل و سیستم است. اگر آن قرارداد مبهم باشد، مدل شکاف‌ها را با حدس‌های محتمل پر می‌کند و ابزار آن‌ها را اجرا می‌کند.
این مقاله استدلال می‌کند که طراحی رابط باید به‌عنوان اهرم اصلی قابلیت اطمینان برای سیستم‌های ایجنت در نظر گرفته شود، پیش از مهندسی پرامپت. پرامپت‌ها رفتار را به‌صورت احتمالاتی شکل می‌دهند. اسکیماها آن را به‌صورت ساختاری الزام می‌کنند.
فراخوانی ابزار واقعاً کجا شکست می‌خورد
سه الگو سهم نامتناسبی از فراخوانی‌های بد ابزار را تشکیل می‌دهند.
نام‌های مبهم پارامتر. فیلدی به نام target یا value یا options مدل را دعوت می‌کند تا معنا را از کانتکست استنتاج کند. مدل آرگومانی تولید می‌کند که از نظر نحوی معتبر و از نظر معنایی نادرست است. ابزار آن را می‌پذیرد. خطا بعداً ظاهر می‌شود، اغلب به‌صورت یک مشکل داده‌ای پایین‌دستی نه یک فراخوانی ناموفق. نام‌هایی مثل target_user_id و retention_days پرگو نیستند؛ رفع ابهام می‌کنند.
فیلدهای اختیاری بدون مقدار پیش‌فرض. اگر اسکیما فیلدی را اختیاری علامت بزند اما ابزار مقدار پیش‌فرض و مسیر مدیریت null نداشته باشد، مدل باید برای کامل کردن فراخوانی مقداری از خود بسازد. این کار را خواهد کرد. مقدار ساختگی معقول به نظر می‌رسد و به شکلی نادرست خواهد بود که تشخیصش دشوار است. اختیاری بودن ادعایی درباره رفتار ابزار است، نه اشاره‌ای به مدل.
آرگومان‌های متن آزاد. یک آرگومان رشته‌ای بدون ساختار، قصد را در نثر فرو می‌ریزد. ابزار نمی‌تواند نثر را اعتبارسنجی کند. مدل را نمی‌توان با نثر اصلاح کرد. فیلدی که "send the report to the team tomorrow morning" را می‌پذیرد، منطق زمان‌بندی را به ذهن مدل هل داده است، جایی که نه قابل بازرسی است و نه قابل آزمون.
این‌ها شکست‌های استدلال نیستند. شکست‌های مشخصات‌دهی هستند که خود را به‌صورت شکست استدلال نشان می‌دهند.
قواعد طراحی برای اسکیمای ابزار
اسکیمای ابزار باید با همان دقت یک API عمومی رفتار شود، چون دقیقاً همان است.
هر آرگومان نوع‌دار، کران‌دار و در مرز اعتبارسنجی‌شده. نوع‌ها لازم‌اند اما کافی نیستند. رشته‌ای که باید یکی از یک مجموعه ثابت باشد باید enum باشد. عددی که باید در یک بازه باشد باید بازه را حمل کند، و مرز باید مقادیر خارج از آن را پیش از اجرا رد کند. اعتبارسنجی در مرز یعنی ابزار هرگز آرگومانی که نمی‌تواند مدیریت کند را نمی‌بیند، و مدل وقتی یکی تولید کرده باشد سیگنالی قطعی دریافت می‌کند.
پیش‌شرط‌ها در توضیحات بیان شوند، نه از کانتکست فرض شوند. اگر ابزاری مستلزم وجود یک منبع است، یا موفقیت یک فراخوانی پیشین، این باید در توضیحات بیاید. مدل به‌طور قابل اتکا پیش‌شرط‌ها را از تاریخچه گفتگو استنتاج نمی‌کند، و نباید مجبور باشد. توضیحی که می‌گوید «نیازمند یک session id فعال است که از open_session به دست می‌آید» یک مشخصات است. توضیحی که می‌گوید «کار را انجام می‌دهد» یک امیدواری است.
خطاها به‌صورت کدهای نوع‌دار با راهنمای رفع بازگردانده شوند. وقتی فراخوانی در اعتبارسنجی شکست می‌خورد، پاسخ باید ماشین‌خوان باشد: کدی که ایجنت بتواند بر اساس آن شاخه بزند، به‌همراه اشاره‌ای کوتاه درباره اینکه چه چیزی قرارداد را برآورده می‌کند. Stack trace و پیام‌های خطای متن آزاد، تجزیه را دوباره به مدل برمی‌گردانند، که دقیقاً همان کاری است که اسکیما قرار بود حذف کند.
یک مکانیزم مشخص: مسیر فراخوانی دو مرحله‌ای. مدل آرگومان‌ها را بر اساس اسکیما صادر می‌کند. یک اعتبارسنج انواع، کران‌ها، enumها و پیش‌شرط‌ها را بررسی می‌کند و یا یک شیء آرگومان نرمال‌شده بازمی‌گرداند یا یک رد نوع‌دار. تنها اشیاء نرمال‌شده به پیاده‌سازی ابزار می‌رسند. پیاده‌سازی ابزار سپس می‌تواند فرض کند ورودی‌هایش خوش‌ساخت‌اند، که شاخه‌زنی دفاعی را از مسیر اجرا حذف می‌کند و شکست‌ها را به یکی از دو جا نسبت‌پذیر می‌سازد: آرگومان مدل یا رفتار ابزار.
چرا پرامپت‌ها نمی‌توانند جبران کنند
وسوسه‌انگیز است که یک system prompt طولانی‌تر بنویسیم که عجایب ابزار را توضیح دهد. این مقیاس‌پذیر نیست، به سه دلیل.
پیروی از دستور با طول کانتکست و تعداد ابزار افت می‌کند. با رشد تعداد ابزارهای در دسترس، توجه مدل به هر دستور واحد نازک می‌شود. قاعده‌ای که یک بار در یک پرامپت طولانی گفته شده با هر چیز دیگری در پنجره رقابت می‌کند. اسکیما در هر فراخوانی صرف‌نظر از تعداد ابزارهای حاضر الزام می‌شود.
اسکیما الزام می‌شود؛ پرامپت رعایت می‌شود. این عدم تقارن اصلی است. اعتبارسنجی به‌صورت قطعی اجرا می‌شود. پایبندی به پرامپت احتمالی است که با عبارت‌بندی، ترتیب و کانتکست تغییر می‌کند. وقتی قابلیت اطمینان مهم است، مکانیز
تغییرات اسکیما آرتیفکت‌های قابل بازبینی هستند. یک diff در اسکیمای ابزار یک diff در یک قرارداد است. می‌توان آن را بازبینی، نسخه‌بندی، آزمون و بازگردانی کرد. یک تغییر کوچک در پرامپت تغییری در یک دستور زبان طبیعی است که اثراتش محلی و به‌سادگی کران‌دار نیست. تیم‌هایی که پرامپت را به‌عنوان لایه قابلیت اطمینان در نظر می‌گیرند به قابلیت اطمینانی می‌رسند که قابل بازبینی نیست.
معاوضه صادقانه: اسکیماهای سخت‌گیرانه انعطاف را هزینه می‌کنند. یک ابزار با نوع‌دهی محکم نمی‌تواند یک درخواست با مشخصات شل را جذب کند، و برخی موارد استفاده مشروع در مرز رد می‌شوند به‌جای آنکه به‌صورت ظریف مدیریت شوند. جایگزین، ابزاری است که هر چیزی را می‌پذیرد و به‌صورت غیرقابل پیش‌بینی شکست می‌خورد. برای بیشتر سیستم‌های تولیدی، یک رد نوع‌دار ارزان‌تر از یک نتیجه اشتباه خاموش است. جایی که انعطاف واقعاً لازم است، باید به‌صراحت مدل‌سازی شود، مثلاً به‌صورت یک discriminated union از واریانت‌های درخواست نوع‌دار، نه به‌صورت یک رشته بی‌نوع.
مهاجرت و نسخه‌بندی
ابزارها API هستند. آن‌ها به پنجره‌های منسوخ‌سازی، نام‌های نسخه‌بندی‌شده، و دوره‌ای نیاز دارند که در آن هم اسکیماهای قدیمی و هم جدید حل شوند. ایجنتی که شکل یک ابزار را از طریق توضیحاتش یاد گرفته است فوراً با یک تغییر شکننده سازگار نمی‌شود، و ارزیابی‌های ساخته‌شده حول آن نیز همین‌طور.
دو متریک جایشان در داشبورد درجه‌یک است، در کنار latency و هزینه:
- نرخ موفقیت فراخوانی به‌ازای هر ابزار. تفکیک‌شده بر اساس ابزار، نه تجمیع‌شده. نرخ موفقیت در سطح سیستم، آن یک ابزاری که شکست می‌خورد را پنهان می‌کند.
- نرخ رد آرگومان. نسبت فراخوانی‌هایی که توسط اعتبارسنج پیش از اجرا رد می‌شوند. نرخ رد روبه‌افزایش سیگنالی زودهنگام است که اسکیما مبهم است، توضیحات گمراه‌کننده است، یا از مدل مقداری خواسته می‌شود که نمی‌تواند بداند.
این دو متریک مسائل اسکیما را از مسائل استدلال جدا می‌کنند. ابزاری با نرخ رد بالا و کد رد واضح به شما می‌گوید قراردادش نامشخص است. ابزاری با نرخ موفقیت بالا در فراخوانی‌هایی که بعداً نتایج اشتباه تولید می‌کنند به شما می‌گوید اعتبارسنجی‌اش بیش از حد مجاز است. هیچ‌کدام از این سیگنال‌ها در یک پرامپت دیده نمی‌شود.
این در عمل چه چیزی را تغییر می‌دهد
در نظر گرفتن سطح ابزار به‌عنوان یک مسئله اسکیما، تغییر می‌دهد که تلاش مهندسی کجا می‌رود. طراحی اسکیما به فعالیتی قابل بازبینی با آزمون‌های خودش تبدیل می‌شود. توضیحات به مشخصاتی با پیش‌شرط‌ها و پس‌شرط‌ها تبدیل می‌شوند. خطاها بخشی از رابط می‌شوند نه یک پس‌اندیشه. پرامپت‌ها هنوز مهم‌اند، اما کاری را می‌کنند که در آن خوب‌اند: شکل‌دهی لحن، استراتژی و تجزیه. آن‌ها بار الزام یک قرارداد را حمل نمی‌کنند.
نکته گسترده‌تر این است که قابلیت اطمینان ایجنت عمدتاً یک انضباط رابط است. مدلی که در برابر یک رابط مبهم خوب استدلال می‌کند همچنان فراخوانی‌های مبهم تولید می‌کند. مدلی که در برابر یک رابط دقیق به‌قدر کافی استدلال می‌کند فراخوانی‌هایی تولید می‌کند که می‌توان آن‌ها را بررسی، رد و اصلاح کرد. سیستم دوم همان است که می‌توان آن را بهره‌برداری کرد.