RAG چیست؟ راهنمای ساخت پاسخ مستند از دانش اختصاصی

فرض کنید تازه‌ترین شرایط خدمات یک شرکت در یک فایل داخلی نوشته شده، اما دستیار هوش مصنوعی از روی دانسته‌های عمومی خودش پاسخ می‌دهد. پاسخ ممکن است خوش‌خوان باشد و حتی شبیه پاسخ درست به نظر برسد، ولی هیچ تضمینی وجود ندارد که با قرارداد یا رویهٔ امروز شرکت سازگار باشد. مسئله در اینجا فقط قدرت مدل نیست؛ مدل به منبع موردنیاز دسترسی ندارد.

RAG یا «تولید تقویت‌شده با بازیابی» راهی برای متصل کردن تولید پاسخ به شواهد بیرونی است. در این راهنما، به‌جای فهرست کردن ابزارها، مسیر یک سؤال را دنبال می‌کنیم: چه چیزی باید از منبع استخراج شود، کدام بخش به مدل برسد، پاسخ چگونه قابل بررسی بماند و در چه شرایطی اصلاً به RAG نیاز نداریم.

RAG چیست و چه چیزی را تغییر می‌دهد؟

در الگوی پایه، سامانه پیش از پاسخ‌گویی، اطلاعات مرتبط با سؤال را از یک مجموعهٔ بیرونی بازیابی می‌کند. سپس سؤال و شواهد منتخب را در اختیار مدل زبانی می‌گذارد. مقالهٔ اولیهٔ RAG در سال ۲۰۲۰، ترکیب حافظهٔ پارامتری مدل با حافظهٔ غیرپارامتریِ قابل بازیابی را بررسی کرد. این تعریف، نقطهٔ شروع مفهوم است؛ یک سامانهٔ عملیاتی علاوه بر آن به کنترل داده، مجوز و ارزیابی نیاز دارد. ۱

تفاوت مهم این است که دانش تازه لزوماً نباید با آموزش دوباره وارد وزن‌های مدل شود. می‌توان منبع بیرونی را به‌روزرسانی کرد و مسیر بازیابی را به نسخهٔ تازه رساند. البته این اتفاق خودکار و بی‌دردسر نیست: اگر سند جدید هنوز وارد نمایه نشده باشد یا نسخهٔ قبلی حذف نشده باشد، سامانه ممکن است همچنان از اطلاعات نادرست استفاده کند. «متصل به داده» باید یک وضعیت قابل مشاهده باشد، نه یک عبارت تبلیغاتی.

یک پاسخ مفید دو پرسش را جواب می‌دهد: «چه می‌گویی؟» و «بر اساس کدام شاهد می‌گویی؟» RAG زمانی ارزشمند می‌شود که کاربر بتواند دومی را هم بررسی کند.

مسیر یک سؤال، از سند تا پاسخ

برای طراحی، بهتر است مسیر را به دو جریان تقسیم کنیم. جریان اول آماده‌سازی دانش است: دریافت فایل، استخراج محتوا، تشخیص ساختار، ثبت مشخصات و ساخت نمایه. جریان دوم با سؤال کاربر شروع می‌شود: تشخیص دامنه، اعمال مجوز، بازیابی، انتخاب شواهد و تولید پاسخ. این تفکیک کمک می‌کند هنگام خطا بدانیم کدام بخش را باید بررسی کنیم.

در جریان آماده‌سازی، عنوان، شناسه، نسخه، تاریخ و مجوز سند کنار متن نگه داشته می‌شوند. یک پاراگراف بدون این زمینه ممکن است قابل خواندن باشد، اما نتوان فهمید دربارهٔ کدام محصول یا کدام دورهٔ زمانی حرف می‌زند. در جریان پاسخ‌گویی نیز بازیابیِ چند قطعه به‌تنهایی کافی نیست؛ باید مشخص شود کدام قطعه واقعاً از ادعای پاسخ پشتیبانی می‌کند.

یک مثال قابل لمس: دستیار محتوای آموزشی

این مثال، سناریوی طراحی است. فرض کنید یک متخصص، مجموعه‌ای از جزوه‌ها و درس‌ها دارد و می‌خواهد مخاطب بتواند سؤال بپرسد. سؤال «تفاوت روش الف و ب چیست؟» شاید به دو جلسهٔ جداگانه مربوط باشد. اگر فقط یک قطعه بازیابی شود، پاسخ ممکن است نیمی از مقایسه را پوشش دهد. بنابراین مجموعهٔ آزمون باید سؤال‌های تک‌منبعی و چندمنبعی را از هم جدا کند.

در چنین محصولی، اطلاعاتی مانند نام دوره، عنوان جلسه، سطح مخاطب و شمارهٔ صفحه ارزش عملی دارند. پاسخ می‌تواند ابتدا تفاوت اصلی را توضیح دهد و سپس کاربر را به هر دو بخش درس برساند. اگر یکی از روش‌ها در مجموعه توضیح داده نشده باشد، رفتار مناسب این است که سامانه محدودیت پوشش را بگوید؛ نه اینکه دانش عمومی را بی‌علامت با محتوای اختصاصی مخلوط کند.

ارزیابی این تجربه فقط با پرسیدن چند سؤال آسان انجام نمی‌شود. باید سؤال مبهم، اصطلاح هم‌معنا، سؤال خارج از دوره و پرسشی که پیش‌فرض نادرست دارد نیز وارد آزمون شوند. مثلاً اگر کاربر دو مفهوم متفاوت را یکی فرض کرده باشد، پاسخ خوب ابتدا ابهام را روشن می‌کند. کیفیت محصول از همین رفتارهای مرزی مشخص می‌شود.

RAG با جست‌وجوی معمولی چه فرقی دارد؟

در جست‌وجوی معمولی، خروجی می‌تواند فهرستی از سندها یا بخش‌های مرتبط باشد. کاربر آن‌ها را باز می‌کند و پاسخ را خودش می‌سازد. در تجربهٔ RAG، یک لایهٔ تولید، شواهد را به پاسخ متناسب با سؤال تبدیل می‌کند. همین لایه، هم فرصت ایجاد می‌کند و هم خطای تازه: ممکن است خلاصه‌سازی، شرط یا استثنای مهمی را حذف کند.

اگر کار اصلی کاربر یافتن فایل با نام یا شناسه است، شاید همان جست‌وجوی دقیق بهتر باشد. اگر می‌خواهد چند بخش پراکنده را با زبان ساده بفهمد، RAG می‌تواند مفیدتر شود. انتخاب این دو نباید مسابقهٔ جذابیت فناوری باشد. یک صفحهٔ جست‌وجوی دقیق که کار را درست انجام می‌دهد، از چتی که پاسخ بی‌منبع می‌دهد ارزشمندتر است.

RAG، پنجرهٔ زمینهٔ بلند یا آموزش تکمیلی؟

این روش‌ها الزاماً رقیب کامل یکدیگر نیستند. پنجرهٔ زمینهٔ بلند اجازه می‌دهد محتوای بیشتری در یک درخواست قرار بگیرد. آموزش تکمیلی می‌تواند برای رفتار، سبک یا مهارت مشخص مدل مطرح شود. RAG بیشتر به انتخاب و رساندن دانش بیرونی در زمان پاسخ مربوط است. برای تصمیم، باید نیاز واقعی و محدودیت عملیات را جداگانه نوشت.

مطالعهٔ مقایسه‌ای RAG و مدل‌های دارای زمینهٔ بلند نشان می‌دهد تصمیم، به سناریو و موازنهٔ کیفیت و هزینه وابسته است. از این نتیجه نمی‌توان نسخهٔ یکسانی برای همهٔ پروژه‌ها ساخت. ۲ اگر مجموعهٔ کوچک و ثابتی دارید، ابتدا روش سادهٔ ارسال مستقیم را هم به‌عنوان خط مبنا آزمایش کنید؛ سپس ارزش بازیابی را با همان سؤال‌ها بسنجید.

چرا «پاسخ با منبع» به‌تنهایی کافی نیست؟

ممکن است یک پاسخ سه پیوند داشته باشد، اما هیچ‌یک ادعای اصلی را تأیید نکند. در ارزیابی باید میان وجود ارجاع و درستی ارجاع فرق بگذاریم. برای نمونه، سندی دربارهٔ مرخصی سالانه، لزوماً شاهدِ پاسخ دربارهٔ مرخصی استعلاجی نیست؛ حتی اگر هر دو در یک آیین‌نامه باشند. ارجاع بهتر است تا بخش یا صفحهٔ مرتبط پیش برود.

همچنین باید روشن باشد در نبود شواهد چه رخ می‌دهد. سکوت مدل دربارهٔ کمبود اطلاعات، تجربهٔ اعتمادپذیری نمی‌سازد. یک رفتار مناسب می‌تواند درخواست توضیح بیشتر، نمایش منابع نزدیک یا اعلام ناتوانی در پاسخ از روی دادهٔ موجود باشد. انتخاب رفتار به نوع محصول بستگی دارد؛ ولی نباید به اتفاق واگذار شود.

یک پایلوت مفید چه چیزهایی دارد؟

پایلوت خوب، نسخهٔ کوچکِ مسئلهٔ واقعی است. اگر محصول نهایی با فایل اسکن‌شده، جدول و چند نقش کاربری کار می‌کند، پایلوتی با چند فایل متنی تمیز همهٔ ریسک‌ها را نشان نمی‌دهد. نمونهٔ داده باید دشواری‌های مهم را پوشش دهد؛ حتی اگر حجم آن کم باشد.

پیش از ساخت رابط، برای چند گروه سؤال پاسخ مرجع و منبع معتبر مشخص کنید. سپس خطاها را دسته‌بندی کنید: منبع وجود ندارد، استخراج ناقص است، بازیابی ضعیف است، شواهد درست‌اند اما پاسخ بد است یا کاربر مجوز ندارد. این دسته‌بندی از تغییر بی‌هدف مدل و ابزار جلوگیری می‌کند.

خروجی پایلوت بهتر است شامل این موارد باشد: دامنهٔ پوشش، معیار پذیرش، مجموعهٔ آزمون، گزارش خطا، زمان پاسخ، هزینهٔ مسیر و روش به‌روزرسانی. تصمیم ادامهٔ پروژه باید بر اساس همین خروجی گرفته شود. تعداد قابلیت‌های نمایشی، جای این شواهد را نمی‌گیرد.

پرسش‌های رایج دربارهٔ شروع

آیا RAG جلوی همهٔ پاسخ‌های نادرست را می‌گیرد؟

خیر. بازیابی می‌تواند اطلاعات نامرتبط برگرداند و مدل هم می‌تواند شواهد را بد تفسیر کند. طراحی پاسخِ بدون شواهد، کنترل تعارض و ارزیابی، همچنان لازم‌اند. پژوهش‌هایی مانند Self-RAG مشخصاً به بازیابی و نقد خروجی می‌پردازند؛ آن‌ها نشان‌دهندهٔ اهمیت کنترل کیفیت‌اند، نه تضمین بی‌خطا شدن هر محصول. ۳

برای شروع چه مقدار داده لازم است؟

عدد ثابتی وجود ندارد. یک مجموعهٔ کوچکِ معتبر برای یک مسئلهٔ محدود می‌تواند کافی باشد. در مقابل، هزاران فایل تکراری یا منسوخ ممکن است کیفیت را پایین بیاورند. سؤال بهتر این است: آیا پاسخ پرسش‌های هدف در دادهٔ موجود هست و آیا می‌توان منبع آن را تشخیص داد؟

نخستین گام عملی چیست؟

ده تا چند ده سؤال واقعیِ نماینده، منبع پاسخ هرکدام و چند نمونهٔ خارج از دامنه را آماده کنید. این مجموعه، هم گفت‌وگو دربارهٔ محصول را دقیق‌تر می‌کند و هم بعدها برای مقایسهٔ نسخه‌ها به کار می‌آید. پس از آن می‌توان دربارهٔ بخش‌بندی، بازیابی ترکیبی و طراحی رابط تصمیم گرفت.