اگر امروز برای بهبود پاسخ‌های هوش مصنوعی روی مهندسی پرامپت سرمایه‌گذاری می‌کنید، احتمالاً دارید روی یک ساختمان با پیِ شکسته بنا می‌سازید. حقیقت این است که یک سامانه تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — تنها به اندازه داده‌هایی که بازیابی می‌کند صادق است. اگر خط لوله شما یک جدول به‌هم‌ریخته از فایل PDF یا یک سیاست قدیمی را به مدل می‌دهد، مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیارد‌ها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — نمی‌تواند با استدلال به حقیقت برسد؛ چون واقعیتِ عملیاتی او از پیش تحریف شده است. شکست سیستم RAG شما به دلیل توهم مدل نیست؛ بلکه به این دلیل است که تنها «واقعیت‌های» موجود برای مدل، یک جدول PDF مخدوش، یک سیاست منقضی شده، تکه‌ای از متن بدون زمینه و سه پاراگراف تقریباً تکراری بوده‌اند که شواهد بهتر را از نتایج برتر (top-k) حذف کرده‌اند. این موضوع نشان می‌دهد که بسیاری از توهمات در واقع نتیجه‌ی خطای بازیابی و نه نقص در مرحله تولید هستند.
بسیاری از تیم‌های مهندسی هفته‌ها وقت خود را صرف تنظیم پرامپت‌ها یا بحث درباره پنجره‌های متنی (Context Windows) می‌کنند، اما سقف واقعی عملکرد اغلب در مراحل ورود داده (Ingestion)، تکه‌بندی (Chunking)، نمایه‌سازی (Indexing)، فیلتر کردن، رتبه‌بندی و تبدیل پرس‌وجو تعیین می‌شود. همان‌طور که در گزارش ۹ سپتامبر ۲۰۲۶ در وب‌سایت dev.to اشاره شده است، خط لوله بازیابی یک لایه جست‌وجوی خنثی نیست؛ بلکه دروازه‌بانی است که تصمیم می‌گیرد مدل اجازه دارد چه چیزی را بداند. تا زمانی که LLM زمینه بازیابی‌شده را دریافت کند، ممکن است پاسخ از پیش غیرممکن شده باشد.
با تکیه بر پوشش قبلی ما درباره اینکه چگونه بررسی‌های ساده بازه (span checks) در پایتون می‌تواند جلوی توهمات مربوط به تاریخ را بگیرد، روشن می‌شود که نبرد برای دقت در مرحله پیش‌پردازش برده یا باخته می‌شود. اگر لایه ورود داده ساختار یک سند را نابود کند، لایه بردار معنایی (Embedding) — که مثل کارت معرفی عددی برای هر واژه است و همسایگی کلمات را مشخص می‌کند — صرفاً «زباله» را کدگذاری می‌کند. در واقع، LLM در پایین‌دستِ خط لوله‌ای قرار دارد که پیش از آن، واقعیت را تحریف کرده است.
تله‌ی ورود داده
ورود داده اغلب به عنوان یک مرحله خسته‌کننده پیش‌پردازش دیده می‌شود، اما بحرانی‌ترین خطاها همین‌جا رخ می‌دهند. وقتی سیستم یک PDF پیچیده را به متنی تک‌بعدی تبدیل می‌کند، روابطی را که محتوا را معنادار می‌کنند، نابود می‌کند. اسناد فقط مجموعه‌ای از کلمات نیستند؛ آن‌ها حاوی عناوین، لیست‌ها، جداول، بلوک‌های کد، کپشن‌ها، پاورقی‌ها، زمینه صفحه و سلسله‌مراتب سندی هستند. ما پیش‌تر در تحلیل خود اشاره کردیم که لایه ورود داده می‌تواند گلوگاه پنهانی باشد که کل سیستم RAG را پیش از رسیدن به مرحله بازیابی دچار شکست می‌کند.
تصور کنید پایگاه دانشی را در نظر بگیرید که پاسخ صحیح را در جدولی داخل یک PDF دارد. کاربر سوالی ساده می‌پرسد، اما مدل پاسخ‌های بی‌معنی می‌دهد چون تکه بازیابی‌شده به این شکل است:Plan A 10 20 50 Plan B 15 25 75 Monthly Annual
در اینجا جدول از نظر فنی بازیابی شده است، اما معنای آن در حین استخراج نابود شده است. اگر مجموعه داده‌های شما شامل PDFها، تصاویر اسکن شده، اسلایدهای ارائه یا HTMLهای دارای کدهای تکراری ناوبری است، تجزیه (Parsing) یکی از تاثیرگذارترین بخش‌های سیستم RAG شماست.
برای حل این مشکل، ورود داده را «آگاه به نوع سند» (document-type aware) کنید. یک لایه ورود داده کاربردی باید به جای متن خام، بلوک‌های ساختاریافته تولید کند (مثلاً با استفاده از یک dataclass به نام ParsedBlock شامل block_id ،doc_id ،kind ،section_path ،content و source_location). برای جداول، سلول‌ها را به صورت یک خط ساده رها نکنید. آن‌ها را به Markdown، CSV یا یک ساختار JSON فشرده تبدیل کنید. یک جدول Markdown روابط سطر و ستونی را برای مدل فراهم می‌کند که یک رشته متنی تخت فاقد آن است.
جراحی زمینه در برابر تکه‌بندی ساده
تکه‌بندی ساده (Naive chunking) — یعنی تقسیم متن بر اساس تعداد توکن‌های ثابت — اغلب منجر به ایجاد تکه‌های «یتیم معنایی» می‌شود. این در واقع جراحی زمینه است، نه تکه‌بندی متن. شما ممکن است تکه‌ای را بازیابی کنید که می‌گوید: «محدودیت ۵۰ مورد برای هر فضای کاری است. فراتر رفتن از آن باعث توقف نرم می‌شود»، اما اگر کاربر پرسیده باشد «محدودیت نرخ API برای حساب Enterprise چیست؟»، این تکه بی‌فایده است چون موضوع (Subject) در تکه قبلی مانده است.
تعداد توکن‌های ثابت به طور معمول در نقاط حساس برش می‌زنند:
- بین یک عنوان و محتوای آن
- بین یک سوال و پاسخ آن
- بین یک تعریف و نحوه استفاده از آن
- بین یک لیست و مقدمه آن
- بین یک ضمیر و مرجع آن
برای رفع این نقص، توسعه‌دهندگان باید از مرزهای زمینه‌ای استفاده کنند. یک تکه باکیفیت باید عنوان سند، مسیر بخش و زمینه عنوان‌های نزدیک را با خود حمل کند. الگوی «والد-فرزند» (parent-child) بسیار موثر است: بازیابی با تکه‌های کوچک و دقیق انجام شود، اما بخش بزرگ‌تر (والد) به LLM ارسال شود. اگر تکه‌های شما اغلب با کلماتی مثل «این»، «آن»، «موردهای بالا» یا «همان‌طور که توصیف شد» شروع می‌شوند، استراتژی تکه‌بندی شما احتمالاً زمینه ارجاعی (referential context) را می‌شکند.
محدودیت‌های شباهت برداری
شباهت برداری با مرتبط بودنِ شواهد یکی نیست. مدل‌های برداری کلی، شباهت‌های معنایی کلی را کدگذاری می‌کنند اما اغلب تفاوت‌های تخصصی دامنه را حذف می‌کنند. آن‌ها به طور خودکار تفاوت‌هایی را که در محصول خاص شما، زبان حقوقی یا اصطلاحات داخلی‌تان اهمیت دارد، نمی‌فهمند.
در محیط عملیاتی، این موضوع باعث شکست‌های ظریفی می‌شود که در آن بازیابی‌کننده متنی محتمل اما غلط برمی‌گرداند:
- «Environment» (محیط): ممکن است در اسناد شما به معنای محیط استقرار (deployment environment) باشد، اما مدل آن را به عنوان یک محیط رایانشی کلی در نظر می‌گیرد.
- «Workspace» (فضای کاری): ممکن است در محصول شما به معنای یک کانتینر مستاجر (tenant container) باشد، اما مدل آن را یک مفهوم کلی از رابط کاربری می‌بیند.
- «Policy» (سیاست/بیمه‌نامه): ممکن است در یک مجموعه داده به معنای بیمه‌نامه و در دیگری به معنای سیاست دسترسی باشد.
جست‌وجوی برداری خالص اغلب در مسائل «تطبیق دقیق» (exact-match) مانند نام محصولات، کدهای خطا، SKUها یا شماره بندهای قانونی شکست می‌خورد. یک خط لوله در سطح تولید به رویکرد ترکیبی نیاز دارد:
- جست‌وجوی کلیدواژه‌ای: برای اصطلاحات دقیق، شناسه‌ها و نام‌ها.
- جست‌وجوی برداری: برای بازنویسی‌های معنایی.
- تلفیق رتبه متقابل (RRF): برای ترکیب این نتایج در یک لیست رتبه‌بندی شده واحد با استفاده از فرمولی مانند
1.0 / (k + rank).
انتخاب شواهد و بازرتبه‌بندی
شباهت به معنای دلیل یا شاهد نیست. یک تکه ممکن است از نظر موضوعی به پرسشی درباره «استرداد وجه» مرتبط باشد، اما نتواند به سوال خاص «استرداد وجه بعد از ۶۰ روز» پاسخ دهد. مدل متن مرتبط را می‌بیند، اما شواهد کافی را نمی‌یابد و شروع به حدس زدن می‌کند. اینجاست که درک معماری سیستم در برابر نقص مدل اهمیت می‌یابد تا بفهمیم چرا حتی با وجود بازیابی درست، خروجی نهایی همچنان دچار خطا می‌شود.
برای حل این مشکل، تیم‌ها باید یک بازرتبه‌بندی (Reranker) از نوع Cross-Encoder پیاده‌سازی کنند. در حالی که Bi-Encoderها (جست‌وجوی برداری) سریع هستند، Cross-Encoderها جفت‌های پرس‌وجو-تکه را با دقت بیشتری امتیازدهی می‌کنند. استراتژی درست این است: بازیابی گسترده و رتبه‌بندی دقیق:
۱. جست‌وجوی برداری ۱۰۰ کاندید برمی‌گرداند.
۲. جست‌وجوی کلیدواژه‌ای ۱۰۰ کاندید برمی‌گرداند.
۳. تلفیق (Fusion) ۵۰ کاندید تولید می‌کند.
۴. بازرتبه‌بندی (Reranker) بر اساس یک امتیاز کف (مثلاً ۰.۳۰)، تنها ۵ تا ۸ تکه را برای LLM انتخاب می‌کند.
اگر با کاهش تعداد تکه‌های بازیابی‌شده، کیفیت پاسخ بهبود می‌یابد، مشکل از «انتخاب شواهد» است، نه طول زمینه (context length).
لایه اعتماد و نسخه‌بندی
اعتماد در محیط عملیاتی در متادیتاها نهفته است. اگر کنترل دسترسی فقط در رابط کاربری باشد و نه در فیلتر بازیابی، سیستم RAG به ابزاری برای دور زدن مجوزها تبدیل می‌شود. بازیابی باید مرزهای مستاجر (tenant boundaries)، گروه‌های کاربری، وضعیت سند و جغرافیا را رعایت کند.
هر تکه نمایه‌سازی شده باید متادیتایی مانند tenant_id ،acl_groups ،status (مثلاً «منتشر شده»)، version و برچسب‌های زمانی effective_at را حمل کند. بازیابی باید پیش از رتبه‌بندی، احراز هویت شود تا از دیدن اطلاعاتی توسط مدل که نباید استفاده کند، جلوگیری شود.
نسخه‌بندی نیز به همان اندازه حیاتی است. سیستم‌های بازیابی به تطبیق معنایی حساس هستند، نه حقیقت تاریخی. اگر یک سیاست سال ۲۰۲۴ در کنار به‌روزرسانی سال ۲۰۲۶ در ایندکس باقی بماند، مدل ممکن است با اطمینان توصیه‌ای قدیمی ارائه دهد چون نسخه قدیمی رتبه برداری کمی بهتری دارد. نسخه‌بندی از طریق برچسب‌های زمانی effective_at و superseded_at برتر از حذف ساده است، زیرا ممکن است برای حسابرسی‌ها یا اختلافات، همچنان به پاسخ‌های تاریخی نیاز داشته باشید. وقتی نسخه جدیدی منتشر می‌شود، نسخه قدیمی را به عنوان «جایگزین شده» (superseded) علامت‌گذاری کنید.
پر کردن شکاف واژگانی
کاربران به‌ندرت از اصطلاحات دقیق مستندات استفاده می‌کنند. کسی که می‌پرسد «چرا استقرارم شکست خورد؟» نیاز دارد سیستم لاگ‌هایی را پیدا کند که به «timeout در کشیدن تصویر کانتینر» اشاره می‌کنند. ارسال مستقیم پرسش کاربر به ایندکس، فرض را بر این می‌گذارد که کاربر اصطلاحات صحیح را می‌داند؛ فرضی که در دنیای واقعی همیشه شکست می‌خورد.
تبدیل پرسش قبل از بازیابی — با استفاده از برنامه‌ریزی پرس‌وجو به کمک LLM یا گسترش قطعی (deterministic expansion) — نرخ بازیابی را در مواجهه با عدم تطابق واژگانی افزایش می‌دهد. این کار شامل ایجاد یک شیء RewrittenQuery است که شامل یک پرس‌وجوی استاندارد، گسترش‌ها (مثلاً «خطای خط لوله CI»، «timeout خط لوله انتشار») و فیلترهای استنباط شده باشد. با این حال، این بازنویسی‌ها باید ثبت (log) و ارزیابی شوند تا از توهم محدودیت‌ها توسط سیستم جلوگیری شود.
خطر داده‌های تکراری
محتوای تکراری رتبه‌بندی را مسموم می‌کند. اگر یک راهنمای شروع به کار در پنج پوشه کپی شده باشد، ۵ نتیجه برتر ممکن است ۵ نسخه از یک پاراگراف باشند و شواهد تکمیلی را بیرون برانند. این اتفاق زمانی می‌افتد که اسناد بین فضاهای مختلف کپی شوند، قالب‌ها متون تکراری تولید کنند یا خزش‌های وب شامل سربرگ‌ها و پانویس‌های تکراری باشند.
حذف تکرار باید در دو مرحله رخ دهد:
- در هنگام ورود داده: استفاده از هش محتوا (مثلاً SHA-256 از متن نرمال شده) برای نادیده گرفتن یا استانداردسازی تکرارهای دقیق.
- در هنگام بازیابی: پیاده‌سازی قوانین تنوع‌بخشی، مانند محدود کردن تعداد تکه‌های بازیابی شده از یک سند واحد، مگر اینکه شامل بخش‌های کاملاً متفاوتی باشند.
اندازه‌گیری خط لوله
ارزیابی تنها پاسخ نهایی، توسعه‌دهنده را کور می‌کند. شما نمی‌توانید بفهمید که آیا سند درست غایب بود، رتبه‌اش خیلی پایین بود یا توسط پرامپت نادیده گرفته شد. شما باید شکست‌های بازیابی را از شکست‌های تولید جدا کنید.
بازیابی باید به طور جداگانه با استفاده از مجموعه‌ای از سوالات، تکه‌های شواهد مورد انتظار و تکه‌های منفی شناخته شده ارزیابی شود. معیارهای کلیدی عبارتند از:
- Recall@k: آیا شواهد لازم در k نتیجه اول بودند؟
- MRR (Mean Reciprocal Rank): اولین تکه درست در چه رتبه‌ای ظاهر شد؟
- Precision@k: چند تکه بازیابی‌شده واقعاً مفید بودند؟
- آلودگی زمینه (Context Contamination): چند بار تکه‌های قدیمی یا ممنوعه ظاهر شدند؟
- نقض مجوزها: آیا تکه‌های غیرمجاز قابل بازیابی بودند؟
اگر Recall@5 پایین باشد، هیچ مقدار مهندسی پرامپت نمی‌تواند سیستم را نجات دهد.
قرارداد بازیابی برای محیط عملیاتی
برای انتقال RAG از یک دمو به یک ابزار قابل اعتماد، یک «قرارداد بازیابی» تعریف کنید — مجموعه‌ای از تضمین‌هایی که خط لوله باید پیش از دیدن داده‌ها توسط LLM برآورده کند. این شامل حسابرسی‌های زیر است:
- ورود داده: آیا جداول در فرمت‌های قابل خواندن برای مدل حفظ شده‌اند؟ آیا متون تکراری (boilerplate) حذف شده‌اند؟
- تکه‌بندی: آیا هر تکه را می‌توان به طور مستقل درک کرد؟ آیا به اسناد والد متصل هستند؟
- بازیابی: آیا مرحله بازرتبه‌بندی وجود دارد؟ آیا جست‌وجوی ترکیبی پیاده شده است؟
- اعتماد: آیا مرزهای مستاجر و تاریخ‌های
superseded_atدر فیلترها اعمال شده‌اند؟ - پرس‌وجو: آیا پرس‌وجوهای بازنویسی شده ثبت و ارزیابی می‌شوند؟
این تغییر دیدگاه — از «چرا LLM توهم زد؟» به «خط لوله چه شواهدی را به LLM اجازه داد ببیند؟» — تنها راه اطمینان از این است که سیستم شما در محیط عملیاتی حقیقت را می‌گوید.
گام بعدی شما
- بررسی کنید آیا جداول PDF شما در مرحله استخراج به متن تخت تبدیل می‌شوند یا ساختار Markdown را حفظ می‌کنند.
- یک لایه بازرتبه‌بندی (Reranker) را به خط لوله خود اضافه کنید تا از ارسال شواهد «شبیه اما بی‌ربط» به مدل جلوگیری کنید.
- متادیتای نسخه‌بندی را به تکه‌های داده اضافه کنید تا مدل پاسخ‌های سال‌های گذشته را به جای نسخه جاری ارائه ندهد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو