تصور کنید چت‌بات شرکت شما با اطمینان کامل به کارمندش می‌گوید سقف بازپرداخت هزینه‌های سفر ۲۰۰ دلار است، در حالی که دستورالعمل داخلی شرکت مبلغ را ۳۵۰ دلار تعیین کرده است. این تضاد دقیقاً همان نقطه‌ای است که مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — شکست می‌خورند.
این مدل‌ها به‌جای خواندن اسناد به‌روز شما، بر اساس الگوهای احتمالی که سال‌ها پیش از اینترنت جذب کرده‌اند، حدس می‌زنند. مشکل بنیادی مدل‌های خام در محیط عملیاتی، فقدان آگاهی از اسناد داخلی، مشخصات محصول یا آخرین قیمت‌های شماست. در نتیجه، وقتی با شکاف دانشی مواجه می‌شوند، نمی‌گویند «نمی‌دانم»، بلکه یک جعل باورپذیر ارائه می‌دهند. این چالش دقیقاً همان دلیلی است که معماری‌های RAG برای حل مشکل تاریخ انقضای دانش در مدل‌های زبانی طراحی شده‌اند.
همان‌طور که در تحلیل قبلی ما درباره‌ی چارچوب Graffiti اشاره کردیم، تمرکز بر ردیابی منشأ داده‌ها حیاتی است. تولید بازیابی‌افزا (RAG) با تغییر نحوه دسترسی مدل به اطلاعات، ریشه این خطاها را خشک می‌کند. در یک سیستم RAG، مدل دیگر سعی نمی‌کند «همه چیز را بداند»، بلکه شبیه مشاوری عمل می‌کند که ابتدا قرارداد را باز می‌کند، بخش مربوطه را سریع می‌خواند و پاسخ را از متنِ پیش‌رو استخراج می‌کند. این دقیقاً همان کاری است که مدل‌های زبانی در آن مهارت فوق‌العاده‌ای دارند.
بدون RAG، مسیر این است: پرسش کاربر $\rightarrow$ حدس مدل از داده‌های آموزش $\rightarrow$ پاسخ (احتمالاً توهم‌آلود). اما با RAG، مسیر به این شکل تغییر می‌کند: پرسش کاربر $\rightarrow$ بازیابی اسناد مرتبط $\rightarrow$ مطالعه اسناد توسط مدل $\rightarrow$ پاسخ مبنی‌ساز (Grounded).
این ساختار توهمات را به‌طور کامل حذف نمی‌کند، اما به مدل یک «پایگاه واقعی» برای تکیه می‌دهد و سیستم را قابل حسابرسی می‌کند؛ یعنی اگر پاسخی غلط باشد، می‌توان دقیقاً ردیابی کرد که کدام تکه از متن بازیابی شده و چرا باعث این خطا شده است.
به نقل از راهنمای فنی منتشر شده در وب‌سایت dev.to در ۲۵ ژوئیه ۲۰۲۶، فرآیند RAG به دو فاز مجزا تقسیم می‌شود: «نمایه‌سازی» و «بازیابی + تولید». این تفکیک حیاتی است چون نمایه‌سازی به‌صورت آفلاین و یک‌باره انجام می‌شود، اما بازیابی هر بار با هر پرسش کاربر به‌صورت آنلاین رخ می‌دهد.
فاز ۱: خط لوله نمایه‌سازی (Indexing Pipeline)
نمایه‌سازی یک فرآیند آماده‌ساز است که در پاسخ به پرسش کاربر اتفاق نمی‌افتد، بلکه طبق برنامه یا هنگام آپلود سند جدید اجرا می‌شود. هدف این است که یک پایگاه‌داده برداری (Vector Database) ایجاد شود تا عملیات «یافتن محتوای مشابه با این پرسش» سریع و ارزان باشد.
بارگذاری اسناد و استخراج داده‌ها
همه چیز با بارگذارهای سند شروع می‌شود، مانند PyPDFLoader یا WebBaseLoader در کتابخانه LangChain. این ابزارها منابع مختلفی را پشتیبانی می‌کنند:
- PDFها: استخراج متن صفحه به صفحه.
- صفحات وب: دریافت و پاک‌سازی HTML.
- متون ساده: استفاده از
TextLoader. - جداول: تبدیل هر سطر CSV به یک سند.
- اسناد Word: مدیریت توسط
UnstructuredWordDocumentLoader. - Notion: بارگذاری برای محیط‌های کاری صادر شده.
در محیط عملیاتی، استفاده از متاداده (Metadata) مثل آدرس URL یا شماره صفحه حیاتی است. این کار برای فیلتر کردن پاسخ‌ها (مثلاً «فقط از سیاست‌های منابع انسانی جست‌وجو کن») و ارجاع دقیق در پاسخ نهایی ضروری است. طبق گزارش‌های فنی، PDFهای اسکن‌شده (تصویری) بزرگ‌ترین چالش هستند و حتماً باید پیش از بارگذاری، پردازش نویسه‌خوانی نوری (OCR) شوند.
تکه‌بندی متن (Chunking)
به دلیل محدودیت پنجرهٔ زمینه (Context Window) — که شبیه میز کاری است که فقط جای چند ورق کاغذ دارد، نه کل کتابخانه — اسناد باید به تکه‌های کوچک‌تر تقسیم شوند. بازه بهینه برای هر تکه بین ۲۰۰ تا ۵۰۰ توکن (Token) است.
- توازن اندازه: تکه‌های خیلی کوچک (مثلاً ۱۰۰ توکن) معنا را از دست می‌دهند. تکه‌های خیلی بزرگ (مثلاً ۲۰۰۰ توکن) دقت جست‌وجوی معنایی (Semantic Search) را پایین می‌آورند.
- هم‌پوشانی (Overlap): برای اینکه یک ایده در مرز دو تکه قطع نشود، توسعه‌دهندگان از «هم‌پوشانی تکه» (مثلاً ۵۰ کاراکتر) استفاده می‌کنند تا انتهای یک تکه در ابتدای تکه بعدی تکرار شود.
بردارهای معنایی و ذخیره‌سازی
این تکه‌ها سپس از یک مدل بردار معنایی (Embedding) — مانند text-embedding-3-small شرکت OpenAI — عبور می‌کنند. این فرآیند متن را به لیستی از اعداد (مثلاً ۱۵۳۶ بُعد) تبدیل می‌کند که معنای ریاضی کلمات را نمایندگی می‌کند. در اینجا ما با جست‌وجوی کلمات کلیدی طرف نیستیم؛ بلکه اگر کاربر بپرسد «چطور رمز عبور را عوض کنم؟»، سیستم متونی را می‌یابد که درباره «تغییر اعتبارنامه حساب» هستند، چون بردارهای آن‌ها در فضای ریاضی نزدیک به هم هستند. با این حال، تکیه صرف بر این متد همیشه جواب نمی‌دهد و گاهی ترکیب جست‌وجوی معنایی و کلمات کلیدی در محیط‌های صنعتی نتایج بسیار دقیق‌تری ارائه می‌دهد.
گزینه‌های رایج برای ذخیره این بردارها عبارت‌اند از:
- FAISS: مناسب برای توسعه سریع و حافظه موقت.
- Chroma: ذخیره‌ساز سبک برای محیط‌های محلی.
- Pinecone: پایگاه‌داده ابری برای مقیاس‌های تجاری.
- Weaviate: گزینه متن‌باز برای فیلترهای پیچیده.
- pgvector: افزونه‌ای برای تیم‌هایی که از Postgres استفاده می‌کنند.
فاز ۲: بازیابی و تولید
وقتی کاربر سوال می‌پرسد، «مسیر زنده» فعال می‌شود. در این مرحله، پرسش کاربر به بردار تبدیل شده، شبیه‌ترین تکه‌ها یافت می‌شوند و سپس در قالب یک پرامپت به مدل تزریق می‌شوند.
فرآیندهای پیشرفته بازیابی
جست‌وجوی ساده بر اساس شباهت همیشه کافی نیست. استراتژی‌های پیشرفته‌تری وجود دارد:
- مرتبط‌ترین حاشیه حداکثری (MMR): توازن بین شباهت و تنوع. این روش مانع می‌شود که پنج تکه کاملاً مشابه بازیابی شوند و سعی می‌کند نتایج متنوع‌تری را بیاورد.
- آستانه امتیاز شباهتی: فقط تکه‌هایی با امتیاز بالا (مثلاً بالای ۰.۷) وارد مدل می‌شوند تا داده‌های بی‌ربط باعث گیج شدن مدل نشوند.
- بازیابی چندپرسشی (Multi-Query): مدل ابتدا ۳ تا ۵ بازنویسی از سوال کاربر می‌سازد و هر کدام را جداگانه جست‌وجو می‌کند تا هیچ محتوای مرتبطی از قلم نیفتد.
حفاظ‌های تولید (Generation Guardrails)
در نهایت، تکه‌های بازیابی شده در یک قالب پرامپت قرار می‌گیرند. برای تضمین پاسخ مبنی‌ساز، دمای (Temperature) مدل روی ۰ تنظیم می‌شود تا از خلاقیت‌های بی‌مورد جلوگیری شود. پرامپت سیستمی باید سخت‌گیرانه باشد: «فقط از متن بازیابی شده پاسخ بده. اگر جواب در متن نیست، بگو نمی‌دانم.»
عیب‌یابی شکست‌های رایج
سیستم‌های RAG معمولاً به شکل‌های پیش‌بینی‌پذیری شکست می‌خورند:
- نادیده گرفتن بستر: اگر مدل با وجود داده‌های درست، باز هم توهم زد، پرامپت سیستمی ضعیف است یا دما روی ۰ نیست.
- تکه‌های بی‌ربط: این خطا معمولاً ریشه در تکه‌بندی (Chunking) دارد. یا تکه‌ها خیلی بزرگ‌اند یا هم‌پوشانی ندارند.
- فقدان اطلاعات: اگر داده در منبع هست اما بازیابی نمی‌شود، احتمالاً مشکل از فرمول‌بندی پرسش است (راهکار: Multi-Query) یا PDFها به درستی OCR نشده‌اند. این نکته تأییدی بر این موضوع است که بسیاری از شکست‌های سیستم‌های RAG ریشه در خطای بازیابی دارند و نه لزوماً ضعف در توان استدلالی مدل.
- شکاف حسابرسی: اگر پاسخ درست است اما منبع ندارد، متاداده‌ها در مرحله فرمت‌بندی نهایی حذف شده‌اند.
در نهایت، پیاده‌سازی RAG نقش مدل را از «دانای کل» به «استدلال‌گر روی متن» تغییر می‌دهد. برای متخصصان، کیفیت هوش مصنوعی اکنون به یک «مشکل لوله‌کشی» تبدیل شده است؛ اگر بازیابی متن درست نباشد، هیچ amount از مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن، مثل کسی که می‌داند چطور از یک مشاور باتجربه بهترین جواب را بگیرد — نمی‌تواند پاسخ نهایی را اصلاح کند.
گام بعدی شما
- اگر از PDFهای اسکن‌شده استفاده می‌کنید، حتماً لایه‌ی Tesseract یا Google Vision را برای OCR پیش از تکه‌بندی اضافه کنید.
- برای کاهش توهمات در پاسخ‌ها، مقدار
Temperatureرا دقیقاً روی ۰ قرار دهید و در پرامپت سیستمی عبارت «فقط بر اساس متن» را با تأکید تکرار کنید. - اگر نتایج بازیابی شما تکراری است، استراتژی MMR را با تغییر پارامتر
lambda_multتست کنید.
اما تأثیر این معماری بر هزینه‌های استنتاج در مقیاس میلیونی بسیار پیچیده‌تر است؛ در تحلیل بعدی به بررسی بهینه‌سازی‌های هزینه در پایگاه‌داده‌های برداری خواهیم پرداخت.
گفتگو