خیلی از سازمان‌ها دستیاری می‌خواهند که از روی آیین‌نامه‌ها، مستندات محصول یا سوابق پشتیبانی خودشان جواب بدهد. مدل زبانی این اطلاعات را نمی‌داند، پس باید در لحظه پرسش به آن داده شود. RAG یا «تولید پاسخ با بازیابی» همین کار را می‌کند: اول قطعه‌های مرتبط را پیدا می‌کند و بعد آن‌ها را همراه پرسش به مدل می‌دهد.
اول بپرسید اصلاً RAG لازم است یا نه
این سؤال را کمتر کسی می‌پرسد. Anthropic در راهنمای خود می‌گوید اگر پایگاه دانش شما کوچک‌تر از حدود ۲۰۰ هزار توکن باشد، می‌توانید کل آن را در پرامپت بگذارید و با کش کردن پرامپت هزینه را پایین بیاورید. برای بسیاری از کسب‌وکارهای کوچک همین راه ساده‌تر و بهتر است.
RAG وقتی لازم می‌شود که حجم اسناد از این بیشتر است یا مدام تغییر می‌کند.
مسیر یک سیستم RAG خوب
- تکه کردن اسناد. متن‌ها به قطعه‌هایی در حد چند صد توکن شکسته می‌شوند. اندازه قطعه و محل برش روی کیفیت اثر مستقیم دارد و باید آزمایش شود.
- افزودن زمینه به هر قطعه. جمله «درآمد نسبت به فصل قبل ۳ درصد بیشتر شد» بدون نام شرکت و فصل به درد نمی‌خورد. می‌توان از مدل خواست برای هر قطعه توضیح کوتاهی بنویسد که جایش را در سند روشن کند.
- ساخت دو نمایه. جست‌وجوی معنایی مفهوم را پیدا می‌کند و جست‌وجوی کلیدواژه‌ای مثل BM25 عبارت‌های دقیق مثل کد خطا یا شماره قرارداد را. این دو در موارد متفاوتی خطا می‌کنند و کنار هم بهتر کار می‌کنند.
- رتبه‌بندی دوباره. از میان نتایج اولیه، یک مدل رتبه‌بند مرتبط‌ترین‌ها را جدا می‌کند.
- تولید پاسخ با ارجاع. مدل فقط از روی همین قطعه‌ها جواب می‌دهد و می‌گوید پاسخ را از کدام سند برداشته است.
این مراحل چقدر فرق می‌گذارند
Anthropic نتیجه آزمایش خود را منتشر کرده است. سنجه آن، درصد قطعه‌های مرتبطی است که در ۲۰ نتیجه اول پیدا نمی‌شوند:
- روش پایه: ۵٫۷ درصد خطا
- با افزودن زمینه به قطعه‌ها: ۳٫۷ درصد
- همراه با BM25: ۲٫۹ درصد
- همراه با رتبه‌بندی دوباره: ۱٫۹ درصد
این اعداد نتیجه آزمایش روی داده‌های همان پژوهش است و تضمینی برای داده شما نیست. پیام اصلی‌اش این است که مسیر را باید روی داده خودتان سنجید.
کیفیت را چطور بسنجیم
«به نظر خوب جواب می‌دهد» معیار نیست. دو بخش را جدا بسنجید:
- بازیابی: آیا قطعه درست پیدا شد؟
- پاسخ: آیا پاسخ واقعاً از همان قطعه‌ها درآمده و به پرسش جواب داده است؟
برای این کار فهرستی از پرسش‌های واقعی کاربران با پاسخ درستشان بسازید و هر بار که چیزی را تغییر دادید دوباره اجرا کنید. فهرست پرسش‌هایی که نباید جواب داده شوند هم مهم است. دستیار خوب وقتی پاسخ را نمی‌داند باید بگوید نمی‌داند.
سه خطر که باید از اول به آن‌ها فکر کنید
- دسترسی. اگر کارمند معمولی به سند مدیریت دسترسی ندارد، دستیار هم نباید آن را برایش بیاورد. سطح دسترسی باید در مرحله بازیابی اعمال شود، نه با خواهش از مدل.
- تزریق پرامپت. متن داخل اسناد می‌تواند دستور مخرب باشد. مدل را مثل کاربر نامطمئن در نظر بگیرید و اختیاراتش را محدود کنید.
- کهنگی. وقتی آیین‌نامه عوض می‌شود، نمایه هم باید همان موقع به‌روز شود و تاریخ سند کنار پاسخ بیاید.
جمع‌بندی
اول مسئله را روشن کنید، بعد ساده‌ترین راه را امتحان کنید و فقط وقتی پیچیده‌اش کنید که اندازه‌گیری نشان بدهد لازم است. اگر می‌خواهید بررسی کنیم هوش مصنوعی کجای کار شما واقعاً به‌صرفه است، خدمت هوش مصنوعی از همین سؤال شروع می‌شود.