یک سامانه RAG فقط زمانی آماده بهرهبرداری است که روی دادههای واقعی سازمان، برای کاربران مجاز و در شرایط عملیاتی قابل پیشبینی آزموده شده باشد. یک دموی روان یا چند پاسخ درست، مدرک پذیرش نیست. پیش از انتشار باید معلوم شود سامانه چه پرسشهایی را پاسخ میدهد، چه زمانی باید از پاسخدادن خودداری کند، منبع هر ادعا چیست، آیا مجوزهای دسترسی را رعایت میکند و پس از تغییر اسناد چه رفتاری دارد.
این راهنما یک روش اجرایی برای **ارزیابی RAG سازمانی** ارائه میکند: ابتدا ریسک و معیار پذیرش را تعریف میکنید، سپس بازیابی و تولید پاسخ را جدا میسنجید، آزمونهای امنیت و تازگی داده را اجرا میکنید و در پایان با شواهد قابل تکرار درباره go/no-go تصمیم میگیرید. اعداد قبولی باید از نیاز و تحمل ریسک همان سازمان استخراج شوند؛ هیچ آستانه جهانی برای دقت، تأخیر یا هزینه وجود ندارد.
ارزیابی RAG سازمانی دقیقاً چه چیزی را میسنجد؟
در RAG، سامانه پیش از تولید پاسخ، بخشهایی از منابع دانشی را بازیابی و همراه پرسش به مدل ارائه میکند. اگر برای شناخت رابطه منابع، فراداده و مالکیت محتوا به زمینه بیشتری نیاز دارید، راهنمای مدیریت دانش با هوش مصنوعی نقطه شروع مرتبطی است. در این مقاله وارد طراحی عمومی معماری نمیشویم؛ موضوع ما اثبات آمادگی یک پیادهسازی مشخص برای استفاده واقعی است.
ارزیابی پذیرش باید چهار پرسش مستقل را جواب دهد:
- آیا سند یا قطعه مناسب بازیابی میشود؟
- آیا پاسخ فقط بر شواهد بازیابیشده تکیه دارد و آنها را درست تفسیر میکند؟
- آیا کاربر فقط اطلاعاتی را میبیند که مجاز به دیدن آن است؟
- آیا سرویس با حجم، هزینه، تأخیر و نرخ خطای قابل قبول سازمان کار میکند؟
پاسخ ظاهراً درست با منبع اشتباه، سامانه قابل اتکایی نمیسازد و بازیابی مناسب نیز تولید پاسخ درست را تضمین نمیکند. بنابراین یک امتیاز کلی برای پذیرش کافی نیست.
پیش از ساخت مجموعه آزمون، مرز ریسک را تعیین کنید
کاربرد و تصمیم مجاز را روشن کنید
نخست یک جمله عملیاتی بنویسید: «این سامانه به چه کسی، برای انجام چه کاری و بر اساس کدام منابع کمک میکند؟» دستیار جستوجوی آییننامه با سامانهای که پیشنهاد حقوقی، پزشکی یا مالی میدهد سطح ریسک یکسانی ندارد. مشخص کنید خروجی صرفاً برای یافتن اطلاعات است، پیشنویس میسازد یا مبنای یک تصمیم اثرگذار قرار میگیرد. هرچه پیامد خطا سنگینتر باشد، دامنه خودکارسازی باید محدودتر و بازبینی انسانی جدیتر باشد.
چارچوب مدیریت ریسک هوش مصنوعی NIST فعالیتها را در چهار حوزه حاکمیت، نگاشت، اندازهگیری و مدیریت سامان میدهد. این نگاه، تعیین مالک ریسک، افراد متأثر و اقدام اصلاحی را کنار سنجش کیفیت قرار میدهد.
موارد توقف و پاسخندادن را تعریف کنید
پیش از آزمایش، رفتار مطلوب در نبود مدرک را بنویسید. سامانه باید در پرسش خارج از دامنه، سند ناکافی، تعارض منابع یا نبود مجوز چگونه پاسخ دهد؟ گاهی پاسخ درست «اطلاعات کافی ندارم» است. همچنین تعیین کنید چه موضوعهایی همیشه به کارشناس ارجاع میشوند، چه عبارتهایی نیازمند هشدارند و چه پاسخهایی نباید بدون استناد نمایش داده شوند.
معیارها را با قالب «شرط، رفتار مورد انتظار، مدرک» ثبت کنید. برای نمونه، در پرسش یک کارمند درباره اطلاعات محرمانه مدیران، هیچ قطعه غیرمجازی نباید وارد زمینه مدل شود و لاگ بازیابی باید اعمال مجوز را نشان دهد.
یک مجموعه طلایی نماینده بسازید، نه مجموعهای از سؤالهای آسان
مجموعه طلایی یا golden set باید نمونهای از واقعیت سازمان باشد، نه نمایش بهترین حالت. پرسشها را از جستوجوهای واقعی، وظایف کارکنان و خطاهای شناختهشده جمع کنید. متخصص موضوع نیز منبع، اجزای ضروری پاسخ و نتیجه مورد انتظار بازیابی را تأیید کند.
حداقل این گروهها را پوشش دهید:
- **قابل پاسخ:** یک یا چند منبع معتبر پاسخ روشن دارند.
- **غیرقابل پاسخ:** پاسخ در مخزن دانش نیست و سامانه باید محدودیت را اعلام کند.
- **مبهم:** پرسش به روشنسازی واحد، تاریخ، نقش یا موضوع نیاز دارد.
- **متعارض:** دو سند ادعای متفاوت دارند و تقدم منبع باید اعمال یا تعارض آشکار شود.
- **قدیمی:** نسخه منسوخ هنوز در آرشیو وجود دارد، اما نباید مبنای پاسخ جاری باشد.
- **چندزبانه:** پرسش و منبع ممکن است فارسی، انگلیسی یا ترکیبی باشند.
- **منفیِ دسترسی:** پاسخ وجود دارد، اما کاربر آزمون اجازه بازیابی آن را ندارد.
برای هر مورد، گروه کاربری، زبان، منابع مرتبط و ممنوع، نسخه سند، تاریخ اعتبار و پاسخ مرجع را نگه دارید. اگر ورودیها PDF اسکنشده یا فایلهای ناهمگوناند، کیفیت استخراج متن را نیز جداگانه بسنجید؛ راهنمای پردازش هوشمند اسناد این مرحله را توضیح میدهد.
مجموعه توسعه را از ارزیابی نهایی جدا کنید تا تنظیم سامانه بر سؤالهای آزمون، نتیجه را خوشبینانه نکند. شکستهای واقعی را نیز با حفظ حریم خصوصی به رگرسیون بیفزایید.
بازیابی را مستقل از تولید پاسخ ارزیابی کنید
برای هر پرسش، خروجی خام موتور جستوجو را قبل از ورود به مدل ذخیره کنید: شناسه سند و قطعه، رتبه، امتیاز، فیلترهای اعمالشده و نسخه شاخص. این جداسازی نشان میدهد خطا از جستوجو، خردکردن سند، فراداده، بازرتبهبندی یا مدل پاسخگو آمده است.
راهنمای رسمی ارزیابی بازیابی در معماری RAG مایکروسافت سه معیار متداول را توضیح میدهد:
- **Precision@K:** از K نتیجه اول، چه نسبتی واقعاً مرتبط است؟ برای جلوگیری از ورود متنهای نامرتبط به زمینه مفید است.
- **Recall@K:** از تمام شواهد مرتبطی که برای پاسخ لازماند، چه نسبتی در K نتیجه اول آمده است؟ برای پرسشهای چندبخشی اهمیت بیشتری دارد.
- **MRR:** اولین نتیجه مرتبط معمولاً در چه رتبهای ظاهر میشود؟ وقتی کیفیت نتیجه اول نقش تعیینکننده دارد، این معیار گویاست.
K را متناسب با اندازه واقعی زمینه انتخاب کنید. نتیجه را بر اساس نوع پرسش، زبان، سطح دسترسی و نوع سند برش دهید؛ میانگین خوب ممکن است شکست یک گروه را پنهان کند. خطاها را نیز به سند نامرتبط، قطعهبندی نامناسب، نسخه قدیمی یا فیلتر مجوز اشتباه دستهبندی کنید.
تولید پاسخ را با چند معیار مکمل بسنجید
پس از تأیید شواهد بازیابیشده، خروجی را بسنجید. راهنمای رسمی مایکروسافت برای ارزیابی سرتاسری RAG بر انتخاب معیار متناسب با بارکاری تأکید میکند. این ابعاد را جدا نگه دارید:
- **اتکا به منبع یا groundedness:** آیا هر ادعای قابل بررسی در پاسخ، پشتوانهای در متن بازیابیشده دارد؟
- **درستی:** آیا مدل شواهد را درست فهمیده و نتیجه نادرست از جملههای صحیح نگرفته است؟
- **کاملبودن:** آیا تمام بخشهای ضروری پاسخ مرجع پوشش داده شده یا نکته مهمی حذف شده است؟
- **ارتباط:** آیا پاسخ مستقیماً به پرسش میپردازد و از حاشیه غیرضروری دور است؟
- **کیفیت استناد:** آیا ارجاع واقعاً همان ادعا را پشتیبانی میکند و کاربر میتواند به سند و بخش مربوط برسد؟
- **رفتار در نبود پاسخ:** آیا سامانه بهجای ساختن جواب، محدودیت را اعلام و مسیر بعدی را پیشنهاد میکند؟
داوری خودکار برای اجرای گسترده مفید است، اما معیارهای کیفی و داور مدل باید با نمونههای ارزیابیشده توسط انسان کالیبره شوند. راهنمای OpenAI درباره ارزیابیهای متناسب با مسئله کسبوکار نیز بر تعریف خروجی مطلوب با کمک متخصص موضوع و حفظ انسان در حلقه ارزیابی تأکید دارد. نمونههای مرزی و اختلاف داوران را دستی بررسی کنید؛ نمره یک داور خودکار را حقیقت قطعی فرض نکنید.
ردیابی منبع و نسخه را جزو پاسخ قابل پذیرش بدانید
هر پاسخ باید تا سند مبنا، نسخه، تاریخ اعتبار و محل دقیق شواهد قابل ردیابی باشد. مقصد حذفشده، غیرمجاز یا نامرتبط، استناد قابل حسابرسی محسوب نمیشود.
انتشار نسخه جدید، انقضای دستورالعمل، وجود دو نسخه مشابه، انتقال سند و اصلاح یک بند را آزمایش کنید. بررسی کنید کدام نسخه بازیابی میشود و پاسخ چگونه اعتبار آن را بیان میکند. نسخه شاخص، مدل و تنظیمات بازیابی را نیز برای بازسازی شکست ثبت کنید.
امنیت را پیش از سنجش کیفیت عبور دهید
کنترل دسترسی باید قبل از بازیابی اعمال شود
پنهانکردن لینک یا حذف متن پس از تولید پاسخ کافی نیست؛ سند غیرمجاز نباید وارد زمینه مدل شود. آزمونها را با هویتهای واقعیِ نماینده نقشها اجرا کنید: کارمند، مدیر، پیمانکار، کاربر واحد دیگر، کاربر تعلیقشده و حساب بدون گروه. راهنمای کنترل دسترسی در سطح سند Azure AI Search توضیح میدهد که مجوزهای سند باید در ورود داده همگام و هنگام پرسوجو اعمال شوند.
برای هر هویت، بازیابی و پاسخ نهایی را بررسی کنید. تغییر عضویت گروه و حذف مجوز را نیز بیازمایید؛ تأخیر همگامسازی میتواند پنجره نشت ایجاد کند. برای محدودیتهای محل استقرار و نگهداری داده، راهنمای استقرار خصوصی هوش مصنوعی به تعریف الزام فنی کمک میکند.
تزریق دستور و سند آلوده را عمداً آزمایش کنید
یک سند میتواند عبارتی مانند «دستورهای قبلی را نادیده بگیر» یا متنی پنهان داشته باشد. RAG بهخودیخود این خطر را حذف نمیکند. راهنمای OWASP درباره Prompt Injection و راهنمای ضعفهای بردار و embedding به حمله از طریق محتوای بازیابیشده، مسمومسازی و نشت اطلاعات اشاره میکنند.
سند آلوده، دستور پنهان، ادعای جعلی با شباهت واژگانی بالا و تلاش برای استخراج داده نقش دیگر را آزمایش کنید. انتظار را دقیق بنویسید: قرنطینه، پردازش بهعنوان داده، علامتگذاری استناد یا توقف درخواست. نتیجه باید بدون افشای اطلاعات حساس در لاگ امنیتی پیگیری شود.
تازگی، بهروزرسانی و حذف را سرتاسری بررسی کنید
اصلاح بند، انقضای نسخه، حذف سند و تغییر دسترسی را از منبع تا استخراج، embedding، شاخص، حافظه پنهان و پاسخ نهایی بررسی کنید. معیار پذیرش باید زمان مشاهده تغییر و مالک همگامسازی ناموفق را مشخص کند.
پس از حذف منبع، شناسه و عبارتهای منحصربهفرد آن را مستقیم و غیرمستقیم جستوجو و حافظه پنهان را بررسی کنید. اگر نسخه تاریخی باید بماند، نقش مجاز و نحوه نمایش قدیمیبودن آن را تعیین کنید.
معیارهای عملیاتی را با بار واقعی سازمان اندازه بگیرید
کیفیت بالا در آزمایش تککاربره، آمادگی تولید را اثبات نمیکند. برای هر مسیر اصلی، زمان بازیابی، زمان تولید، زمان کل، نرخ خطا، مصرف توکن یا منابع، هزینه هر درخواست و دسترسپذیری سرویسهای وابسته را اندازه بگیرید. توزیع و صدکها از میانگین تنها مفیدترند، زیرا کندیهای پراکنده را آشکار میکنند.
آستانه انتظار، نرخ خطا و سقف هزینه را سازمان تعیین کند. رفتار جایگزین در قطع جستوجو، مدل یا منبع هویت را نیز بنویسید. اوج مصرف، پرسش طولانی، سند حجیم، چندزبانه و محدودیت نرخ را بیازمایید و برای هر هشدار مالک مشخص کنید.
مشاهدهپذیری و آزمون رگرسیون را قبل از انتشار آماده کنید
مسیر درخواست باید بدون ذخیره بیضابطه اطلاعات حساس قابل پیگیری باشد. شناسه همبستگی، نسخه برنامه و مدل، تنظیمات بازیابی، زمان مراحل و نتیجه کنترل امنیتی مفیدند. نگهداری، ماسککردن و دسترسی به لاگ را نیز تعریف کنید.
با هر تغییر مدل، prompt، chunking، embedding، فیلتر، reranker یا شاخص، مجموعه رگرسیون را اجرا کنید. شکست تازه در کنترل دسترسی یا پاسخندادن باید انتشار را متوقف کند. نسخه ارزیابی و نتایج را برای حسابرسی نگه دارید.
مثال عملی: پذیرش دستیار سیاستهای منابع انسانی
فرض کنید دستیار باید از آییننامههای منابع انسانی، مزایا و رویههای مرخصی پاسخ دهد. مجموعه آزمون فقط سؤال «چند روز مرخصی دارم؟» نیست. تفاوت قرارداد، شعبه، تاریخ استخدام، نسخه آییننامه و سطح دسترسی باید در پرسشها بازتاب یابد.
| سناریو | انتظار از بازیابی | انتظار از پاسخ | مدرک پذیرش | |---|---|---|---| | مرخصی کارمند رسمی | نسخه جاری و بند مرتبط | پاسخ مشروط به نوع قرارداد با استناد دقیق | شناسه سند، نسخه و ارزیابی متخصص HR | | پرسش مبهم درباره «مزایا» | نتایج مرتبط بدون حدسزدن منظور | درخواست روشنسازی نقش یا نوع مزیت | ثبت مسیر گفتوگو و نبود ادعای بدون منبع | | سؤال درباره حقوق مدیران توسط کارمند | هیچ قطعه محرمانه | اعلام نبود دسترسی، بدون اشاره به محتوای سند | خروجی خام بازیابی و لاگ فیلتر مجوز | | سند قدیمی مرخصی | نسخه قدیمی پایینتر یا خارج از نتایج جاری | اتکا به نسخه معتبر و ذکر تاریخ | آزمون پس از انتشار نسخه جدید | | دستور مخرب داخل PDF | سند بهعنوان داده، نه دستور سامانه | نادیدهگرفتن فرمان مخرب و ثبت رخداد | نتیجه آزمون امنیت و شناسه رخداد |
تیم HR پاسخ مرجع را تأیید کند، تیم امنیت آزمون مجوز و تزریق را بسنجد، مالک محصول رفتار پاسخندادن را تصویب کند و عملیات ظرفیت را بسنجد. پذیرش جمع این شواهد است، نه یک امتیاز کلی.
چکلیست go/no-go برای روز تصمیم
پیش از بهرهبرداری، پاسخ هر مورد باید «بله»، «خیر» یا «پذیرش مشروط با مالک و موعد» باشد:
- کاربرد، کاربران، منابع مجاز و موارد خارج از دامنه مستند شدهاند.
- خطرهای اصلی و رفتار توقف یا ارجاع برای هرکدام تعریف شده است.
- مجموعه طلایی شامل نمونههای مثبت، منفی، مبهم، متعارض، قدیمی، چندزبانه و منفی دسترسی است.
- بازیابی مستقل سنجیده شده و شکستها بر اساس نوع پرسش و گروه کاربر دیده میشوند.
- groundedness، درستی، کاملبودن، استناد و پاسخندادن جداگانه ارزیابی شدهاند.
- کنترل دسترسی پیش از ورود اسناد به زمینه مدل اجرا و با هویتهای مختلف آزموده شده است.
- آزمون تزریق دستور، سند آلوده و تلاش برای نشت داده نتیجه قابل قبول دارد.
- فرایند افزودن، اصلاح، انقضا، حذف و تغییر مجوز سند سرتاسری تأیید شده است.
- آستانههای تأخیر، هزینه، ظرفیت و دسترسپذیری با توجه به نیاز سازمان تصویب شدهاند.
- لاگ، هشدار، مالک رخداد، مسیر بازگشت و آزمون رگرسیون آمادهاند.
- متخصص موضوع نمونههای حساس و اختلاف داور خودکار را بازبینی کرده است.
- نقصهای پذیرفتهشده، مسئول اصلاح، موعد و محدودیت استفاده برای کاربران شفافاند.
میانگین خوب نباید شکست امنیتی یا پرپیامد را بپوشاند. پذیرش مشروط نیز به کنترل جبرانی، مالک و موعد بازبینی نیاز دارد.
انتشار مرحلهای و پایش پس از بهرهبرداری
انتشار را از گروه کوچکی از کاربران نماینده آغاز کنید و گزارش پاسخ نامناسب را ساده نگه دارید. سؤالهای بیپاسخ، استنادهای بازنشده، ارجاع، بازخورد منفی و افزایش هزینه را پایش کنید. نمونههای واقعی پاکسازیشده را به رگرسیون برگردانید.
برنامه توقف و بازگشت مشخص کند چه رخدادی قابلیت را غیرفعال میکند، جایگزین زمان اختلال چیست و چه کسی اطلاعرسانی میکند. پس از تغییر منبع، مدل یا مجوز، آزمونهای مرتبط را دوباره اجرا کنید.
از معیار پذیرش تا سامانه قابل اتکا
ارزیابی RAG سازمانی زمانی ارزش دارد که معیارها را به ریسک واقعی و فرایند کاری وصل کند. جداسازی بازیابی از تولید، آزمون دادههای غیرقابل پاسخ و متعارض، کنترل مجوز پیش از retrieval، ردیابی نسخه، سنجش تازگی و اجرای رگرسیون، شواهدی میسازد که تصمیم بهرهبرداری بر آن تکیه کند.
اگر میخواهید مجموعه طلایی، معیارهای پذیرش، کنترلهای امنیتی و پایش عملیاتی را متناسب با منابع و نقشهای سازمان خود طراحی کنید، خدمات راهکارهای هوش مصنوعی ایزیساز میتواند مسیر تحلیل تا اجرای آزمونپذیر را پوشش دهد. برای بررسی کاربرد و ریسکهای پروژه خود، با تیم ایزیساز تماس بگیرید.