سوال مصاحبه هوش مصنوعی ۲: چگونه از قابلیت اطمینان فراخوانی ابزار توسط مدل زبانی بزرگ (LLM) اطمینان حاصل کنیم

چگونه می‌توان اطمینان حاصل کرد که مدل زبانی بزرگ (LLM) هنگام فراخوانی ابزار به‌طور قابل اعتماد و کنترل‌شده عمل می‌کند، نه اینکه صرفاً به اعلان‌ها برای "متقاعد کردن" مدل تکیه کند. نیاز به یک چارچوب محدودیت چندلایه به‌صورت سیستماتیک است.

مانند مثال جستجوی آب‌وهوا، سه رفتار "تخیلی" رایج مدل در فراخوانی ابزار:
1. فراخوانی نکردن ابزار و پاسخ مستقیم ساختگی.
2. ارسال پارامترهای با فرمت اشتباه هنگام فراخوانی ابزار (مانند ابزاری که "پس‌فردا" را پشتیبانی نمی‌کند، اما پارامتر date="پس‌فردا" ارسال می‌شود).
3. تبدیل خودسرانه فرمت پارامتر (مانند تبدیل خودسرانه "پس‌فردا" به تاریخ مشخص)، حتی اگر ابزار چنین نیازی نداشته باشد.

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

برای حل این مشکل، نیاز به یک راه‌حل مهندسی چندلایه است:

1. لایه اول: بهینه‌سازی اعلان (محدودیت نرم)
2. موقعیت‌یابی به عنوان نقطه شروع چارچوب محدودیت، اما به هیچ وجه نقطه پایان.
3. باید اعلان را به عنوان "قرارداد عملیاتی" در نظر گرفت که به وضوح هدف ابزار، نوع هر پارامتر، مرزها را توضیح داده و نمونه‌هایی از مقادیر غیرمجاز را ذکر کند.

4. باید مثال‌های Few-shot اضافه کرد، با نمایش نمونه‌های "ورودی صحیح → فراخوانی صحیح"، از یادگیری زمینه‌ای برای تثبیت الگوی رفتار مدل استفاده کرد.

5. لایه دوم: معرفی JSON Schema (محدودیت سخت)

6. این گام کلیدی از "استدلال" به "تنظیم نرده" است.
7. با تعریف ساختاریافته قابل خواندن و تأیید توسط ماشین (JSON Schema) به جای توصیف پارامتر با زبان طبیعی. می‌توان نوع فیلد، الزامی بودن، محدوده مقادیر شمارشی را به شدت تعریف کرد و با تنظیم additionalProperties: false از خروجی هر فیلد تعریف‌نشده توسط مدل جلوگیری کرد.

8. پلتفرم‌های اصلی API از این محدودیت خروجی ساختاریافته در مرحله رمزگشایی مدل پشتیبانی می‌کنند و از منبع تولید از نقض قالب جلوگیری می‌کنند.

9. لایه سوم: ایجاد حلقه اعتبارسنجی-تعمیر-تلاش مجدد (پشتیبان اجرا)

10. حتی با وجود Schema، باز هم باید پس از دریافت خروجی مدل، اعتبارسنجی نحوی و Schema انجام شود.

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

12. سطح معماری: جداسازی مسئولیت‌ها

13. باید تصمیم‌گیری را از اجرا جدا کرد و یک معماری سه‌لایه تشکیل داد:
    • لایه مدل: فقط مسئول تصمیم‌گیری (تشخیص اینکه کدام ابزار فراخوانی شود، چه پارامترهایی تولید شود).
    • لایه چارچوب: مسئول چارچوب اجرا، شامل اعتبارسنجی Schema، فراخوانی ابزار، مدیریت تلاش مجدد و یکپارچه‌سازی نتایج. این اطمینان می‌دهد که خطاهای مدل مستقیماً بر امنیت ابزار تأثیر نمی‌گذارد و تغییرات ابزار نیازی به تنظیم مکرر اعلان‌ها ندارد.
    • لایه ابزار: پیاده‌سازی قابلیت‌های تجاری خاص.
14. چارچوب‌هایی مانند LangChain و LlamaIndex دقیقاً چنین کاری انجام می‌دهند.

محدودیت‌های راه‌حل فعلی: می‌تواند مشکل فرمت پارامتر را به خوبی مدیریت کند، اما پوشش اعتبارسنجی معنای پارامتر (مانند معادل بودن "شانگهای" و "هو") هنوز کافی نیست. این چالش مهندسی آینده خواهد بود.

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