ریبکس: بررسی کیفیت پاسخ و جلوگیری از تکرار خطا
P27
برنامه شروع
خطای ریبکس به پاسخ مرجع، اصلاح مشخص و آزمون جلوگیری از تکرار تبدیل شود.
قدم اول
۲۰ نمونه مجاز را با کارشناس موضوع به پاسخ مرجع و علت خطا تبدیل کنید؛ نسخه پاسخ و ردگیری اجرای هر نمونه را ثبت کنید.
- مسئول پیشنهادی
- مسئول کیفیت ریبکس با کارشناس موضوع
- معیار نتیجه
- خطای هدف اصلاح شود، خطای بحرانی تازه ایجاد نشود و زمان بازبینی بیشتر نشود؛ نمونه نهایی ارزیابی از تنظیم جدا بماند.
ورودیهای لازم
- نمونههای مجاز خطا و موفقیت
- نسخه مدل، سند، ابزار و ردگیری
- پاسخ مرجع و شدت تأییدشده
کمک هوش مصنوعی: شباهت خطاها و برچسب اولیه پیشنهاد کند؛ پاسخ مرجع، علت و شدت با بازبین و آزمون عدد و دسترسی با برنامه تأیید شوند.
روش آزمون و ابزارها
مقایسه با روش فعلی
نمونه بینام در جدول با شناسه گفتگو، نسخه، نوع خطا، منبع، پاسخ قابل قبول و مسئول اصلاح؛ اجرای یکسان نسخه فعلی و جدید و بازبینی کور انسانی. مقایسه با همین روش دستی، فایده مدل دستهبندی را روشن میکند.
نمونه آزمون
طرح پیشنهادی: ۲۰۰ مورد بینام شامل ۱۰۰ مورد از انواع خطای موجود و ۱۰۰ مورد موفق/معمولی؛ ۴۰ مورد برای آزمون نهایی کنار گذاشته شود و ۴۰ مورد را دو بازبین مستقل ببینند. برای تخمین نرخ واقعی خطا نمونه تصادفی جدا از ترافیک لازم است؛ این مجموعه متوازن نماینده فراوانی تولید نیست.
- درصد تکمیل درست کار و امتناع/ارجاع درست به تفکیک سناریو
- خطای عدد، منبع، تازگی، حریم خصوصی و ادعای ابزار ناموجود به تفکیک شدت
- توافق بازبینها و اختلاف داور مدل با انسان
- دقیقه بازبینی و هزینه کل به ازای مورد پذیرفتهشده
معیار پیشنهادی پذیرش
پیشنهاد برای توافق مالک کیفیت: هیچ خطای بحرانی تازه در آزمون نهایی؛ اصلاح موارد هدف بدون افت دستههای دیگر؛ زمان کل بازبینی از روش دستی بیشتر نشود. حد عددی تکمیل پس از baseline تعیین شود؛ اینها نتیجه یا آستانه مصوب نیستند.
ابزارهای مرتبط
منابع فنی
- C01 · Promptfoo — Assertions and metrics — آزمون قطعی، اعتبارسنجی ساختار، معیار هزینه و تأخیر و داوری مدل؛ مبنای طراحی مجموعه آزمون نسخهها.
- C02 · Langfuse — Model usage and cost tracking — تفکیک مصرف و هزینه دریافتشده از هزینه استنباطی بر اساس نام مدل و جدول قیمت؛ امکان تعریف قیمت سفارشی.
- C15 · OWASP — LLM prompt injection prevention — ورودی خارجی نامطمئن، اعتبارسنجی آرگومان ابزار و مجوز در کد، حداقل دسترسی و تأیید اقدام حساس؛ فیلتر متن بهتنهایی کافی نیست.
جزئیات پروژه و منابع

این پروژه چه کمکی به کار روزانه میکند؟
یک مثال فرضی: تیم متن راهنمای ریبکس را تغییر داده و میخواهد بداند پاسخهای قبلی خراب نشدهاند. ابزار سؤالهای ثابت را با نسخه جدید دوباره اجرا میکند.
برای شروع، چه چیزی آماده میشود؟
برای هر سؤال، پاسخ قبلی و جدید، منبع و نظر بازبین کنار هم میآیند؛ مثلاً «خطای قبلی رفع شد، اما شرط حساب در پاسخ دیگر حذف شده است».
در مرحله بعد، چه میتوان اضافه کرد؟
اشتباههای مهم گفتگوهای واقعی، پس از حذف اطلاعات شخصی، به سؤالهای آزمون اضافه میشوند.
نمره میانگین خوب نباید خطای حساس را پنهان کند؛ نمونههای مهم بازبینی انسانی میشوند.
مراحل پیشنهادی کار
- مرحله ۱
بازخورد کاربر
بازخورد کاربر
- مرحله ۲
پیداکردن مدارکی که اجازه بررسی آنها را داریم
متن گفتوگو و مراحل اجرای همان پاسخ را با دسترسی مجاز بررسی میکنیم.
- مرحله ۳
جداکردن مشکلهای متفاوت و حذف موارد تکراری
موارد تکراری را کنار هم میگذاریم و شدت هر مشکل را مشخص میکنیم.
- مرحله ۴
مشخصکردن معیارهای بررسی پاسخ
بازبین پاسخ درست و معیار بررسی آن را تعیین میکند.
- مرحله ۵
آزمون نسخه
نسخه تازه مدل، دستور یا ابزار را با همان نمونهها آزمایش میکنیم.
- مرحله ۶
انتشار پس از تأیید و پیگیری نتیجه
پس از مجوز انتشار، همان مشکل را در استفاده واقعی هم پیگیری میکنیم.
زمان، درستی خروجی و فایده کار را بسنجیم
۱. زمان و هزینه انجام کار
زمان بازخورد کاربر تا علت و آزمون معتبر
۲. کیفیت و اعتبار
نرخ موفقیت مجموعه نمونه یکسان، با تفکیک شدت و توانایی واقعی
۳. فایده و نتیجه اقتصادی
بازگشت کاربر/ارتقای طرح اشتراک پس از پاسخ موفق؛ هزینه هر حل معتبر
توضیحات بیشتر برای اجرا و بررسی نتیجه
این کار کجا ثبت میشود؟
ادمین ریبکس منبع بازخورد کاربر؛ یک کار تیمیک به issue ریشهای و test case متصل؛ داده خصوصی حذف شود
هر مرحله را چه کسی انجام میدهد و به چه کسی تحویل میدهد؟
- ۱
خدمات یا کارشناس موضوع، پاسخ اشتباه را مشخص میکند
- ۲
تیم فنی، علت را رفع میکند
- ۳
بازبین مستقل، پاسخ اصلاحشده را آزمایش میکند
- ۴
تیم محصول، درباره انتشار تصمیم میگیرد.
خدمات یا کارشناس موضوع، پاسخ اشتباه را مشخص میکند ← تیم فنی، علت را رفع میکند ← بازبین مستقل، پاسخ اصلاحشده را آزمایش میکند ← تیم محصول، درباره انتشار تصمیم میگیرد.
از کجا بفهمیم آزمون اولیه موفق بوده است؟
حداقل ۱۰۰ نمونه از گروههای مختلف بررسی شود. دو بازبین، ۲۰٪ نمونهها را جداگانه بررسی کنند و بخشی از نمونهها فقط برای آزمون نهایی کنار گذاشته شود. پیش از عرضه، خطاهای بحرانی رفع یا قابلیت مربوط غیرفعال شود.
چه زمانی باید کار را متوقف کنیم؟
تغییر نام دسته یا prompt برای سبز شدن ارزیابی کافی نیست؛ افزایش خطای حساس توقف انتشار است.
چه کارهای دیگری میتوان به این پروژه اضافه کرد؟ 1 مورد
آزمون قبل و بعد
نمونههای مشکلدار پیش از اصلاح به آزمون پذیرش تبدیل شوند.
برای شروع چه لازم است و بعد چه میکنیم؟
چه چیزهایی باید آماده باشد؟
این موارد باید از پروژههای مرتبط آماده شوند؛ کاملشدن همه امکانات آن پروژهها لازم نیست.
- P03؛ دیدن پروژه مرتبط
برای هر کار، مسئله، مسئول، موعد و نشانه تحویل درست نوشته شود؛ مثلاً «فرم با شماره آزمون ثبتنام را کامل کند».
مراحل پیشنهادی اجرا و توسعه
این مراحل برنامه پیشنهادیاند؛ انجامشدن آنها هنوز تأیید نشده است.
- مرحله ۱تعریف سؤال مرجع
نمونه سؤال و پاسخ قابل قبول را با بازبین آماده کنید.
- مرحله ۲آزمون نسخه جدید
پاسخهای قبل و بعد را کنار هم بگذارید تا خطای تازه پیدا شود.
- مرحله ۳بررسی علت و نمونه واقعی
مسیر تولید پاسخ را بررسی و نمونههای مجاز واقعی را با نظر انسان ارزیابی کنید.