یک مدل را به چند سند وصل می‌کنیم، پرسشی می‌پرسیم و پاسخ خوبی می‌گیریم. دمو آماده است. اما مشتری بعدی سؤال مبهمی می‌پرسد، یکی از سندها قدیمی است و سرویس مدل هم برای چند ثانیه پاسخ نمی‌دهد. حالا باید چه اتفاقی بیفتد؟
به نظرم مهندسی AI از همین سؤال شروع می‌شود: چگونه قابلیتی بسازیم که در شرایط واقعی، با هزینه و کیفیت قابل قبول کار کند؟
دقیقاً چه چیزی را مهندسی می‌کنیم؟
در این نوشته منظور از مهندسی AI، ساخت محصول با مدل‌های آماده است؛ نه پژوهش برای آموزش یک مدل بنیادی. کار فقط نوشتن پرامپت نیست. باید ورودی را کنترل کنیم، داده مناسب را به مدل برسانیم، خروجی را بسنجیم و برای شکست مسیر مشخص داشته باشیم.
مهندسی نرم‌افزار معمولاً از ما می‌خواهد رفتار سیستم را مشخص کنیم. در محصول مبتنی بر مدل زبانی، بخشی از خروجی احتمالی است. بنابراین علاوه بر اینکه «کد اجرا شد»، باید بپرسیم «پاسخ برای این کاربرد قابل قبول بود؟»
مثال: دستیار پشتیبانی که نباید حدس بزند
فرض کنیم می‌خواهیم دستیار به پرسش‌های مشتری درباره شرایط خدمات جواب بدهد. این یک مثال آموزشی است. معیار موفقیت را پیش از انتخاب مدل بنویسیم: پاسخ باید به سند معتبر تکیه کند، منبع را نشان بدهد و وقتی اطلاعات کافی نیست، کار را به پشتیبان برگرداند.
در این کاربرد، جست‌وجو و آوردن بخش مرتبط سند به ورودی مدل، یا RAG، می‌تواند کمک کند. اما RAG تضمین صحت نیست. ممکن است متن اشتباه بازیابی شود، سند از تاریخ اعتبارش گذشته باشد یا مدل از متن نتیجه نادرستی بگیرد. لازم است کیفیت بازیابی و کیفیت پاسخ را جداگانه بررسی کنیم.
اول آزمون را بنویسیم، بعد دمو را بهتر کنیم
برای یک آزمایش اولیه می‌توان با ۳۰ تا ۵۰ پرسش نماینده شروع کرد؛ این پیشنهاد شروع است، نه حجم نمونه علمی یا تضمین کیفیت. مجموعه باید سؤال معمولی، سؤال مبهم، اطلاعات متناقض، موضوع خارج از دامنه و تلاش برای تغییر دستورهای سامانه را داشته باشد. برای هر مورد بنویسیم چه پاسخی پذیرفتنی است و چه رفتاری خطا محسوب می‌شود.
فقط میانگین کیفیت کافی نیست. نرخ پاسخ بی‌منبع، نرخ ارجاع درست به انسان، زمان پاسخ و هزینه هر درخواست را هم ببینیم. خطای یک پاسخ درباره ساعت کاری با خطای وعده بازپرداخت پول یکسان نیست؛ شدت پیامد باید در ارزیابی دیده شود.
در راهنمای ارزیابی عامل‌های AI در Anthropic هم بر ارزیابی رفتار و نتیجه، با چند روش مکمل، تأکید شده است. برای محصول خودمان باید معیارهای متناسب با کاربرد را تعریف کنیم؛ یک امتیاز عمومی جای آن را نمی‌گیرد.
مدل نباید مالک مجوزها باشد
اگر دستیار به ابزار متصل است، پیشنهاد مدل نباید به‌تنهایی مجوز اقدام باشد. دسترسی کاربر، اجازه فراخوانی ابزار و اعتبار ورودی باید در کد بررسی شود. متنی که از یک سند بازیابی می‌شود داده است؛ نباید بتواند اختیار سامانه را تغییر دهد.
برای کارهای دارای پیامد، مثل تغییر اشتراک یا ارسال پیام، مرحله تأیید، ثبت نتیجه و امکان جبران لازم است. همچنین باید از تکرار ناخواسته اقدام پس از قطع ارتباط جلوگیری کرد. این‌ها مسئولیت طراحی سیستم‌اند، نه چیزی که با «لطفاً اشتباه نکن» حل شود.
چه زمانی Agent نسازیم؟
اگر کار با یک جست‌وجوی ساده، یک قانون مشخص یا یک جریان ثابت حل می‌شود، شروع با عامل خودمختار احتمالاً هزینه و خطای بیشتری ایجاد می‌کند. راهنمای Building effective agents هم پیشنهاد می‌کند از راه‌حل ساده شروع کنیم و پیچیدگی را وقتی اضافه کنیم که نتیجه را بهتر می‌کند.
برای همان دستیار پشتیبانی، مسیر اولیه می‌تواند این باشد: جست‌وجوی سند، تهیه پاسخ مستند، بررسی خروجی و ارجاع موارد نامطمئن. اگر این مسیر جواب می‌دهد، داشتن چند عامل به‌خودی‌خود مزیت نیست.
قبل از تحویل، این پنج پاسخ باید روشن باشد
- چه مسئله‌ای حل می‌شود و روش فعلی چه ضعفی دارد؟
- کدام داده معتبر است و چه کسی آن را به‌روز می‌کند؟
- کیفیت با چه آزمونی سنجیده می‌شود؟
- در صورت خطا، تأخیر یا قطع سرویس چه اتفاقی می‌افتد؟
- چه کسی مالک هزینه، پایش و اصلاح سامانه است؟
مهندس AI کسی است که می‌تواند درباره این پنج مورد تصمیم قابل دفاع بگیرد. انتخاب مدل بخشی از کار است؛ قابل اتکا کردن نتیجه، بخش بزرگ‌تر آن.
