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