در مقاله‌های قبلی سایت، از مدل زبانی و Embedding تا RAG و Agent جلو آمدیم. حالا فرض کنیم قرار است همین مفاهیم را در یک دستیار پشتیبانی به کار ببریم: کاربر سؤال می‌پرسد و سیستم از روی مستندات محصول پاسخ می‌دهد. اولین تصمیم وسوسه‌انگیز، انتخاب مدل است؛ اما هنوز نمی‌دانیم پاسخ خوب برای این محصول دقیقاً چه شکلی است.
در این بخش، معیار موفقیت دستیار را پیش از مقایسه مدل‌ها می‌نویسیم. مخاطب، توسعه‌دهنده‌ای است که مبانی RAG را می‌شناسد و می‌خواهد محصول قابل سنجش بسازد. خروجی یک قرارداد ارزیابی کوچک است: چه سؤال‌هایی داخل محدوده‌اند، چه پاسخی پذیرفتنی است، چه زمانی باید جواب نداد و کیفیت را در کنار تأخیر و هزینه چگونه دید.
موفقیت را با تعداد پاسخ اشتباه نگیریم
دستیاری که به همه سؤال‌ها جواب می‌دهد، لزوماً مفیدتر نیست. اگر مستندات درباره یک قابلیت چیزی نگفته باشند، پاسخ قطعی می‌تواند کاربر را به مسیر غلط ببرد. در مقابل، جواب «اطلاعات کافی ندارم» وقتی سند روشن وجود دارد نیز شکست محصول است. بنابراین هم پاسخ‌گویی و هم خودداری از پاسخ باید متناسب با شواهد سنجیده شوند.
برای مثال، کاربر می‌پرسد «چطور عضو جدید به تیم اضافه کنم؟» و سند راهنما مراحل دعوت را توضیح می‌دهد. پاسخ خوب باید مراحل مرتبط را بگوید، شرط نقش کاربر را اگر در سند آمده حفظ کند و به همان راهنما ارجاع بدهد. اضافه‌کردن یک دکمه خیالی یا حدس‌زدن مجوزها، حتی با نثر روان، قابل قبول نیست.
محدوده محصول را به زبان ساده بنویسیم
دستیار نمونه فقط راهنمای استفاده از محصول را از اسناد مجاز پاسخ می‌دهد. به اطلاعات حساب یا سفارش واقعی کاربر دسترسی ندارد و تغییری در آن‌ها ایجاد نمی‌کند. این مرز باید هم در طراحی فنی و هم در تجربه کاربر روشن باشد. اگر کاربر وضعیت پرداخت شخصی‌اش را بپرسد، دستیار نباید از روی یک مقاله عمومی نتیجه بسازد.
- داخل محدوده: توضیح مراحل کار، پیدا کردن صفحه راهنما و روشن‌کردن اصطلاحات مستندشده.
- نیازمند سؤال تکمیلی: پرسشی که نام قابلیت یا موقعیت استفاده در آن مبهم است.
- خارج از محدوده: مشاهده اطلاعات خصوصی حساب یا انجام عملیات تغییردهنده بدون ابزار و مجوز لازم.
- فاقد شاهد: ادعایی که در منابع فعلی پشتیبانی نمی‌شود، حتی اگر مدل آن را محتمل بداند.
این مرزبندی، توصیه‌ای برای همه دستیارها نیست؛ قرارداد محصول نمونه ماست. اگر بعداً ابزار مشاهده سفارش اضافه شود، هم محدوده و هم آزمون‌ها باید تغییر کنند. قابلیت جدید فقط یک خط در پرامپت نیست؛ دسترسی، ثبت رویداد و رفتار خطای خودش را دارد.
یک سؤال را از ابتدا تا نتیجه بررسی کنیم
سؤال نمونه این است: «همکارم لینک دعوت را باز کرده ولی وارد تیم نشده؛ چه کار کند؟» برای پاسخ، شاید باید سند دعوت اعضا و سند انقضای لینک بررسی شوند. اگر اطلاعات درباره زمان ارسال دعوت نداریم، سیستم می‌تواند ابتدا پرسش روشن‌کننده بپرسد؛ لازم نیست مستقیماً یکی از علت‌های احتمالی را قطعی اعلام کند.
در ارزیابی، فقط متن آخر را نگاه نکنیم. بررسی کنیم آیا سند مرتبط پیدا شده، آیا محدودیت آن درست منتقل شده و آیا قدم بعدی برای کاربر روشن است. اگر بازیابی سند اشتباه باشد، عوض‌کردن مدل ممکن است مشکل را پنهان کند ولی الزاماً آن را حل نمی‌کند.
| بخش | پرسش ارزیابی | نمونه شکست |
|---|---|---|
| بازیابی | سند مرتبط در اختیار پاسخ‌دهنده بود؟ | انتخاب راهنمای ورود به‌جای دعوت اعضا |
| پشتیبانی ادعا | جمله‌های مهم به سند متکی‌اند؟ | حدس‌زدن زمان انقضای لینک |
| اقدام‌پذیری | کاربر می‌داند چه کند؟ | تکرار کلی مسئله بدون قدم بعدی |
| مرز دسترسی | پاسخ از منابع مجاز آمده است؟ | استفاده از سند متعلق به تیم دیگر |
روبریک پاسخ را کوچک و روشن نگه داریم
در شروع، می‌توان چند شرط قابل بررسی داشت: پاسخ به سؤال مرتبط باشد، ادعاهای اصلی پشتوانه داشته باشند، مرحله ضروری حذف نشده باشد و اطلاعات خارج از دسترسی وارد پاسخ نشده باشد. هر شرط باید توضیح و نمونه داشته باشد تا دو بازبین برداشت کاملاً متفاوتی نکنند.
برای سؤال دعوت، «روان بودن» به‌تنهایی کافی نیست. پاسخ شاید بسیار خوش‌خوان باشد ولی شرط نقش مدیر تیم را حذف کند. در مقابل، یک پاسخ کمی خشک که مراحل درست و مرجع معتبر دارد می‌تواند از نظر فنی پذیرفتنی باشد و در بازبینی زبان بهتر شود. کیفیت فنی و نگارشی را جدا بسنجیم تا دلیل رد یا قبول روشن بماند.
خط مبنا را قبل از پیچیده‌کردن سیستم بسازیم
یک جست‌وجوی ساده در راهنما یا فهرست پیوندهای مرتبط می‌تواند خط مبنای اولیه باشد. اگر دستیار جدید نسبت به این روش کمکی نمی‌کند، اضافه‌کردن مدل بزرگ‌تر به‌تنهایی توجیه ندارد. باید ببینیم کاربر کجا به پاسخ ترکیبی یا توضیح تعاملی نیاز دارد و کجا یک لینک مستقیم کافی است.
خط مبنا را روی همان سؤال‌هایی بسنجید که برای مدل استفاده می‌کنید. تغییر هم‌زمان سؤال‌ها، اسناد و معیارها مقایسه را مبهم می‌کند. نسخه مجموعه سؤال، نسخه اسناد، تنظیمات بازیابی و مشخصات مدل را نگه دارید تا بعداً معلوم باشد نتیجه متعلق به چه شرایطی بوده است.
در این مقاله هیچ مقایسه مدلی اجرا نشده و عددی درباره برتری یک گزینه ارائه نمی‌کنیم. پیشنهاد این است که ابتدا قاب مقایسه ساخته شود؛ نمونه‌های داده و ابزار اجرای تکرارپذیر در دو بخش بعدی اضافه خواهند شد.
چند امتیاز را در یک عدد پنهان نکنیم
ممکن است مدلی پاسخ دقیق‌تری بدهد ولی دیرتر پاسخ دهد یا هزینه بیشتری داشته باشد. یک امتیاز تجمیعی بدون توضیح وزن‌ها، این معامله را پنهان می‌کند. بهتر است کیفیت پاسخ، نرخ ارجاع درست، رفتار در نبود شاهد، تأخیر و هزینه را کنار هم گزارش کنیم.
برای تأخیر، زمان رسیدن به اولین بخش قابل استفاده و زمان تکمیل پاسخ می‌توانند متفاوت باشند. برای هزینه نیز فقط قیمت یک فراخوانی کافی نیست؛ بازیابی، تلاش دوباره و پردازش سند ممکن است سهم داشته باشند. مقدار هدف را از نیاز محصول می‌گیریم و ادعای بهینه‌بودن را با داده همان مسیر بررسی می‌کنیم.
پژوهش HELM نمونه‌ای از نگاه چندمعیاره به ارزیابی مدل‌هاست. آن پژوهش جای مجموعه آزمون اختصاصی محصول ما را نمی‌گیرد، اما یادآوری می‌کند که یک معیار تنها تصویر کاملی از رفتار سیستم نمی‌دهد. برای دستیار فارسی هم باید سؤال و متن فارسی نماینده کاربران خودمان داشته باشیم.
خودداری از پاسخ هم خروجی طراحی‌شده است
وقتی سند کافی نداریم، پیام باید روشن و مفید باشد: چه چیزی معلوم نیست، چه اطلاعاتی می‌تواند کمک کند و مسیر بعدی چیست. جمله مبهم «مشکلی پیش آمد» کاربر را راهنمایی نمی‌کند. از طرف دیگر، توضیح طولانی درباره محدودیت‌های مدل هم لزوماً لازم نیست؛ کاربر دنبال حل مسئله خودش است.
برای ارزیابی این رفتار، نمونه‌هایی لازم داریم که پاسخشان واقعاً در منابع نیست و نمونه‌هایی که با یک سؤال تکمیلی قابل حل‌اند. اگر فقط سؤال‌های ساده و دارای سند را بسنجیم، ممکن است سیستم در آزمون خوب باشد ولی در اولین ابهام واقعی با اعتماد بیش از حد جواب بدهد.
داور خودکار جای تعریف معیار را نمی‌گیرد
می‌توان بخشی از بررسی را با قواعد ثابت یا مدل داور انجام داد، اما ابتدا باید بدانیم چه چیزی را می‌سنجیم. بررسی وجود لینک با بررسی پشتیبانی واقعی لینک یکی نیست. مدل داور هم ممکن است اشتباه کند یا به سبک نوشتار حساس باشد؛ نمونه‌ای از نمره‌ها باید با بازبینی انسانی کالیبره شود.
برای شرط‌های قطعی مثل معتبر بودن قالب یا خارج‌نشدن شناسه سند از فهرست مجاز، قواعد برنامه‌نویسی‌شده مناسب‌اند. برای کیفیت توضیح، روبریک و بازبینی نمونه‌ها کمک بیشتری می‌کند. اگر بین دو روش اختلاف وجود دارد، اختلاف را بررسی کنیم؛ میانگین‌گرفتن کورکورانه علت را روشن نمی‌کند.
قرارداد ارزیابی نسخه اول
یک سند کوتاه بسازید که شامل محدوده، گروه‌های سؤال، تعریف پاسخ پذیرفتنی، رفتار نبود شاهد و روش ثبت نتیجه باشد. مسئول به‌روزرسانی سند و زمان بازبینی را هم تعیین کنید. تغییر محصول یا اسناد باید بتواند این قرارداد را تغییر دهد؛ در غیر این صورت آزمون‌ها به واقعیت قدیمی وفادار می‌مانند.
برای تمرین، شش سؤال تألیفی بنویسید: دو سؤال مستقیم از سند، دو سؤال مبهم و دو سؤال خارج از محدوده. برای هرکدام، پاسخ لازم نیست دقیقاً یک جمله ثابت باشد؛ موارد ضروری، ادعاهای ممنوع و مرجع قابل قبول را مشخص کنید. از پرسش‌های واقعی کاربران فقط با مجوز و حذف اطلاعات حساس استفاده کنید.
در بخش بعد، از این طرح به ساخت Golden Dataset می‌رسیم: انتخاب نمونه‌های نماینده، پوشش حالت‌های دشوار، ثبت منشأ داده و نگه‌داشتن بخشی از سؤال‌ها برای ارزیابی مستقل. بعد از آن، ابزار اجرای تکرارپذیر را می‌سازیم تا تغییر مدل یا بازیابی را با نتیجه قابل مقایسه بسنجیم.
منابع و ادامه مطالعه
- پژوهش Holistic Evaluation of Language Models؛ مرجع نگاه چندمعیاره به ارزیابی مدل‌های زبانی.
- راهنمای مهندسی Anthropic درباره ارزیابی سیستم‌های عامل‌محور؛ برای شناخت اجزای آزمون، تکرار اجرا و روش‌های داوری.