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