چگونه کیفیت پاسخ هوش مصنوعی را بسنجیم؟
سؤالی که پروژههای هوش مصنوعی را زمین میزند ساده است: «خوب شده؟» و جوابی که معمولاً داده میشود این است که چند نفر چند پرسش امتحان کردهاند و راضی بودهاند.
با این جواب نمیشود تصمیم گرفت. نه میشود گفت آمادهٔ تولید است، نه میشود فهمید تغییر هفتهٔ پیش کمک کرد یا نه.
مجموعهٔ آزمون، قبل از هر چیز دیگر
پیش از ساختن نمونهٔ اولیه، پنجاه تا صد پرسش واقعی جمع کنید و جواب درستشان را بنویسید.
سه قید که این مجموعه را مفید میکند:
پرسشها واقعی باشند. از تیکتها، تماسها، یا آنچه کارکنان واقعاً میپرسند. اگر خودتان بنویسیدشان، نتیجهٔ خوبی میگیرید که هیچ ربطی به واقعیت ندارد — چون شما بلدید چطور بپرسید.
حالتهای سخت هم باشند. پرسش مبهم، پرسشی که جوابش در اسناد نیست، پرسشی که دو سند متناقض دربارهٔ آن دارند. اگر مجموعهٔ آزمون فقط پرسشهای آسان دارد، نمرهٔ خوبی میگیرید و در تولید زمین میخورید.
جواب درست را کارشناس نوشته باشد، نه کسی که سامانه را میسازد.
این کار چند روز از وقت کارشناسان شما میگیرد و باید در برآورد دیده شود. بدون آن، هر تصمیمی دربارهٔ این پروژه سلیقهای است.
سه عددی که تصمیم میسازند
درصد پاسخ درست. واضح، و بهتنهایی گمراهکننده.
درصد «نمیدانم» درست. مواردی که جواب در اسناد نبوده و سامانه همین را گفته. این عدد باید بالا باشد، نه پایین.
درصد پاسخ قاطعِ غلط. جواب داده، مطمئن بوده، و اشتباه بوده.
عدد سوم تنها عددی است که واقعاً تصمیم میسازد و بیشتر از همه نادیده گرفته میشود. سامانهای که هشتاد درصد درست جواب میدهد و بیست درصد با اطمینان اشتباه میگوید، از سامانهای که شصت درصد جواب میدهد و بقیه را میگوید نمیدانم، بیاعتمادتر است — چون کاربر یاد میگیرد که به هیچکدام نمیشود اعتماد کرد.
آستانهٔ قابل قبول برای این عدد را قبل از دیدن نتیجه تعیین کنید. بعدش، همیشه یک دلیل پیدا میشود که چرا این مورد استثنا بوده.
در سامانههای RAG، دو مرحله را جدا بسنجید
اگر پاسخ از اسناد ساخته میشود، خطا میتواند از دو جای مختلف بیاید و درمانشان فرق دارد.
بازیابی: آیا متن درست پیدا شد؟ سنجهاش ساده است — در چند درصد موارد، قطعهای که جواب در آن بود جزو نتایج بازیابیشده بوده؟
تولید: با فرض اینکه متن درست داده شده، آیا جواب درست ساخته شد؟
اگر این دو را جدا نکنید، ماهها روی مدل کار میکنید در حالی که مشکل در بازیابی بوده — که در فارسی معمولاً همان است، و اغلب با نرمالسازی متن حل میشود، نه با مدل بهتر. تفصیلش در چالشهای پردازش زبان فارسی.
مدل بهعنوان داور
سنجیدن دستی صد پاسخ در هر تغییر، دوام نمیآورد. راهی که رایج شده این است که مدل دیگری خروجی را نمره بدهد.
جواب میدهد، با سه احتیاط:
نمرهٔ مدل داور باید یک بار با نمرهٔ انسان مقایسه شود تا بدانید چقدر میشود به آن تکیه کرد. اگر همبستگی ضعیف است، دارید نویز اندازه میگیرید.
معیار باید مشخص و باریک باشد. «کیفیت پاسخ» را داور خوب نمره نمیدهد؛ «آیا این جواب فقط از متن دادهشده آمده؟» را خوب نمره میدهد.
و برای تصمیمهای مهم — مثل اجازهٔ رفتن به تولید — نمونهگیری انسانی را کنار نگذارید.
بعد از راهاندازی
مجموعهٔ آزمون ثابت، تغییرات را میسنجد. کیفیت در تولید چیز دیگری است و به سه سیگنال دیگر نیاز دارد:
پرسشهایی که سامانه نتوانسته جواب دهد، مرتب بر اساس فراوانی. این فهرست مستقیماً میگوید کدام سند ناقص است.
مواردی که کاربر بعد از پاسخ سامانه باز هم به کارشناس ارجاع داده.
و اصلاحهایی که کارشناسان روی پیشنویسهای پیشنهادی انجام میدهند. اگر سامانهتان در حالت «پیشنهاد به کارشناس» کار میکند، این ارزشمندترین دادهٔ رایگانی است که تولید میشود — و در بیشتر پروژهها ذخیره نمیشود.
چیزی که نباید بسنجید
سرعت پاسخ را بهعنوان سنجهٔ کیفیت. مهم است، ولی مربوط نیست.
رضایت کاربر از رابط را با کیفیت پاسخ اشتباه نگیرید.
و طول پاسخ. جواب بلندتر لزوماً بهتر نیست و مدلها به بلندنویسی تمایل دارند.
اگر امروز شروع میکنید
اگر سامانهای دارید که کار میکند و معیاری ندارید، لازم نیست پروژهٔ تازهای تعریف کنید. پنجاه پرسش از لاگ یک هفتهٔ گذشته بردارید، جواب درستشان را با یک کارشناس بنویسید، و همان سه عدد را حساب کنید.
معمولاً همین یک بعدازظهر کافی است تا بحث از «حس میکنم بهتر شده» به یک عدد تبدیل شود. و از آن به بعد، هر تغییری که میدهید قابل دفاع است.