تولید تقویت‌شده با بازیابی (RAG) در یک دموی ساده آسان به نظر می‌رسد: اسناد را در یک پایگاه داده برداری می‌ریزیم، پنج قطعه برتر را بازیابی می‌کنیم و در پرامپت قرار می‌دهیم. اما همین دمو در محیط عملیاتی معمولاً ظرف چند هفته از کار می‌افتد. پاسخ‌ها به نسخه قدیمی یک دستورالعمل استناد می‌کنند، جدول‌ها به متنی درهم‌ریخته تبدیل می‌شوند و هیچ‌کس نمی‌تواند بگوید «بهبود» هفته گذشته واقعاً کمک کرد یا آسیب زد. مشکل به‌ندرت از خود مدل است؛ مشکل در بازیابی است. اگر می‌پرسید RAG چیست، پاسخ کوتاه این است: مدل زبانی پیش از پاسخ، اسناد مرتبط را بازیابی می‌کند.
در این مقاله سه تصمیم کلیدی را مرور می‌کنیم، یعنی قطعه‌بندی، امبدینگ و نمایه‌سازی، و ارزیابی، و همچنین عادت‌های مهندسی‌ای که باعث می‌شود یک سامانه RAG پس از راه‌اندازی هم کیفیت خود را حفظ کند.
از پرسش‌ها شروع کنید، نه از اسناد
پیش از نوشتن حتی یک خط کد، ۱۰۰ تا ۳۰۰ پرسش واقعی از کسانی جمع کنید که قرار است از سامانه استفاده کنند: کارشناسان پشتیبانی، تحلیل‌گران، واحد تطبیق و انطباق. برای هر پرسش مشخص کنید پاسخ در کدام سند و در حالت ایدئال در کدام پاراگراف آمده است. این مجموعه، مجموعه طلایی شماست؛ ارزشمندترین دارایی پروژه، چون هر تصمیم بعدی را از سلیقه به اندازه‌گیری تبدیل می‌کند.
مجموعه طلایی نوع سامانه‌ای را که می‌سازید هم روشن می‌کند. اگر بیشتر پرسش‌ها از نوع جست‌وجوی مستقیم باشند («الزام وجه تضمین برای محصول X چقدر است؟»)، بازیابی دقیق قطعه‌های کوتاه اهمیت دارد. اگر از نوع ترکیب و جمع‌بندی باشند («تغییرات قوانین پذیرش مشتری در امسال را خلاصه کن»)، به زمینه گسترده‌تر، فراداده تاریخ و نسخه، و احتمالاً بیش از یک مرحله بازیابی نیاز دارید.
قطعه‌بندی: معنا را حفظ کنید، نه تعداد کاراکتر را
بیشترین افت کیفیت در مرحله قطعه‌بندی رخ می‌دهد. تقسیم با اندازه ثابت (مثلاً ۱۰۰۰ کاراکتر با ۲۰۰ کاراکتر هم‌پوشانی) نقطه شروع معقولی است، اما جمله‌ها را می‌برد، عنوان‌ها را از محتوایشان جدا می‌کند و جدول‌ها را تکه‌تکه می‌کند.
راهبردهای بهتر، به ترتیب تقریبی میزان زحمت:
- تقسیم مبتنی بر ساختار. ابتدا قالب سند را تجزیه کنید: عنوان‌های Markdown یا HTML، بلوک‌های چیدمان PDF و سبک‌های Word. بر اساس بخش و پاراگراف تقسیم کنید و سپس قطعه‌های کوچک را تا رسیدن به اندازه هدف ادغام کنید؛ برای بیشتر متن‌ها ۳۰۰ تا ۸۰۰ توکن مناسب است.
- زمینه را همراه قطعه نگه دارید. پیش از امبدینگ، عنوان سند و مسیر سرفصل‌ها را به ابتدای متن هر قطعه اضافه کنید («قوانین معاملات › وجه تضمین › معاملات روزانه»). همین یک تغییر اغلب بازخوانی را به‌وضوح بهتر می‌کند، چون بسیاری از قطعه‌ها به‌تنهایی معنای کاملی ندارند.
- با جدول‌ها و فهرست‌ها جداگانه رفتار کنید. جدول را به Markdown یا به یک ردیف در هر خط همراه با نام ستون‌ها تبدیل کنید. ردیفی مثل
محصول: آتی طلا | وجه تضمین اولیه: ۸٪بسیار بهتر از شبکه‌ای از اعداد بی‌برچسب بازیابی می‌شود. - بازیابی والد و فرزند. قطعه‌های کوچک را برای تطبیق دقیق نمایه کنید، اما بخش بزرگ‌تر والد را به مدل بدهید. به این ترتیب هم بازیابی دقیق دارید و هم زمینه کافی برای پاسخ درست.
روی هر قطعه فراداده نگه دارید: منبع، نسخه، تاریخ اعتبار، زبان و سطح دسترسی. برای فیلتر کردن، استناد و کنترل دسترسی به آن نیاز خواهید داشت.
امبدینگ و نمایه‌سازی در پایگاه داده برداری
مدل امبدینگ را با آزمودن روی مجموعه طلایی خودتان انتخاب کنید، نه بر اساس رتبه در جدول‌های مقایسه. چندزبانه بودن در اینجا بسیار مهم است. اگر پیکره شما ترکیبی از فارسی و انگلیسی است، بازیابی بین‌زبانی را صریحاً بیازمایید: پرسش فارسی روی اسناد انگلیسی و برعکس. برخی مدل‌های قوی انگلیسی روی خط فارسی، یکسان‌سازی حروف و نیم‌فاصله عملکرد ضعیفی دارند.
نکته‌های کاربردی:
- متن را یکسان‌سازی کنید، هم پیش از امبدینگ و هم هنگام پرسش: نرمال‌سازی یونیکد، یکسان کردن «ي/ی» و «ك/ک»، ارقام و فاصله‌ها. ناهمخوانی در یکسان‌سازی بی‌صدا بازخوانی را از بین می‌برد.
- از جست‌وجوی ترکیبی استفاده کنید. بردارهای متراکم را با یک نمایه واژگانی مانند BM25 ترکیب کنید. بازیابی برداری در فهم هم‌معنایی قوی است و جست‌وجوی واژگانی در کدهای محصول، نام‌ها و اصطلاحات دقیق. دو فهرست نتیجه را با ادغام رتبه متقابل (RRF) ترکیب کنید که به هم‌سنجی امتیازها نیازی ندارد.
- رتبه‌بندی مجدد اضافه کنید. ۳۰ تا ۵۰ نامزد را ارزان بازیابی کنید و سپس با یک مدل cross-encoder که پرسش و متن را با هم می‌خواند، دوباره رتبه‌بندی کنید. این مدل‌ها برای هر مورد کندترند، اما سه نتیجه برتر را که مدل واقعاً می‌بیند به‌شدت بهتر می‌کنند.
- انتخاب نمایه تابع مقیاس است. تا چند میلیون قطعه، HNSW در یک پایگاه برداری بالغ یا در PostgreSQL با افزونه pgvector معمولاً کافی است. پارامترهایی مانند
ef_searchوMرا بر اساس بازخوانی روی مجموعه طلایی تنظیم کنید، نه مقادیر پیش‌فرض. - برای نمایه نسخه نگه دارید. ثبت کنید هر نمایه با کدام مدل امبدینگ و کدام پیکربندی قطعه‌بندی ساخته شده است. تغییر هر کدام یعنی امبدینگ دوباره کل پیکره. نمایه‌های موازی (blue/green) طراحی کنید تا بتوانید جابه‌جا شوید و در صورت لزوم برگردید.
ارزیابی: بازیابی را جدا از تولید پاسخ بسنجید
بیشتر تیم‌ها فقط پاسخ نهایی را ارزیابی می‌کنند و همین ریشه مشکلات را پنهان می‌کند. در دو لایه اندازه بگیرید.
شاخص‌های بازیابی با مجموعه طلایی:
- Recall@k: آیا قطعه درست در k نتیجه برتر هست؟ این سقف کیفیت پاسخ است. اگر recall@5 برابر ۶۰٪ باشد، هیچ مهندسی پرامپتی آن ۴۰٪ باقی‌مانده را نجات نمی‌دهد.
- MRR یا nDCG: قطعه درست در چه رتبه‌ای قرار می‌گیرد؟
- نتایج را به تفکیک نوع پرسش، زبان و منبع ببینید. میانگین‌ها بخش‌های ضعیف را پنهان می‌کنند.
شاخص‌های تولید پاسخ که هم انسان و هم یک ارزیاب مبتنی بر مدل زبانی (که با داوری انسانی هم‌سنجی شده) قضاوت می‌کنند:
- وفاداری به منبع: آیا هر ادعای پاسخ در زمینه بازیابی‌شده پشتوانه دارد؟
- ارتباط پاسخ: آیا به همان پرسشی که مطرح شده پاسخ می‌دهد؟
- درستی استناد: آیا منابع ذکرشده واقعاً حاوی آن ادعا هستند؟
ارزیابی کامل را با هر تغییر در قطعه‌بندی، امبدینگ، پرامپت یا مدل، در CI و درست مانند آزمون‌های واحد اجرا کنید. افت دودرصدی بازخوانی که کسی متوجهش نشده، همان مسیری است که سامانه‌های RAG از آن فرسوده می‌شوند.
الزامات عملیاتی که اختیاری نیستند
- کنترل دسترسی در زمان بازیابی. فیلتر سطح دسترسی کاربر را داخل خود پرسش جست‌وجو اعمال کنید، نه پس از تولید پاسخ. مدل نمی‌تواند پاراگراف محرمانه‌ای را که دیده «ندیده» بگیرد.
- تازگی داده. ورود افزایشی بسازید: اسناد تغییرکرده را تشخیص دهید، فقط همان‌ها را دوباره قطعه‌بندی کنید و قطعه‌های منسوخ را حذف کنید. تاریخ منبع را در پاسخ نشان دهید.
- رفتار امتناع. اگر بهترین امتیاز بازیابی از آستانه کمتر بود، صادقانه بگویید و مسیر ارجاع پیشنهاد کنید، به جای اینکه بگذارید مدل بداهه‌پردازی کند.
- مشاهده‌پذیری. پرسش، شناسه قطعه‌های بازیابی‌شده، امتیازها، پرامپت و پاسخ را ثبت کنید. وقتی کاربری پاسخی را نادرست گزارش می‌کند، باید بتوانید دقیقاً همان رخداد را بازسازی کنید.
- حلقه بازخورد. هر پاسخ گزارش‌شده نامزدی برای مجموعه طلایی است. این مجموعه باید هر ماه بزرگ‌تر شود.
یک معماری اولیه معقول برای پایپ‌لاین RAG
برای بیشتر سازمان‌ها نسخه نخست مستحکم این است: قطعه‌بندی مبتنی بر ساختار همراه با زمینه سرفصل‌ها، یک مدل امبدینگ چندزبانه، بازیابی ترکیبی با ادغام رتبه متقابل، یک رتبه‌بند مجدد cross-encoder، پرامپتی که استناد را الزامی می‌کند و مجموعه ارزیابی‌ای که با هر تغییر اجرا می‌شود. این معماری عجیب و پیچیده نیست و از روز اول به عامل هوشمند یا پایگاه داده گرافی نیاز ندارد؛ اما به انضباط در داده و اندازه‌گیری نیاز دارد.
کیفیت RAG بیش از هر چیز یک مسئله بازیابی اطلاعات است که در انتهای آن یک مدل زبانی قرار دارد. با همین نگاه به آن بپردازید و از ابتدا روی مجموعه طلایی سرمایه‌گذاری کنید تا سامانه با گذشت زمان بهتر شود، نه اینکه آرام‌آرام از مسیر خارج شود.