مدل‌های زبانی درباره اسناد داخلی شرکت شما چیزی نمی‌دانند: آیین‌نامه‌ها، قراردادها، مستندات فنی و پاسخ‌های پشتیبانی. راه حل رایج این مشکل آموزش دوباره مدل نیست، بلکه RAG است؛ روشی که در لحظه پرسش، بخش‌های مرتبط اسناد را پیدا و در اختیار مدل قرار می‌دهد. در این راهنما ساخت چت‌بات RAG روی اسناد سازمانی را از معماری تا انتخاب مدل Embedding، پایگاه داده برداری، نکات زبان فارسی و ارزیابی توضیح می‌دهیم.
فهرست مطالب
RAG چیست؟
RAG (Retrieval-Augmented Generation یا تولید تقویت‌شده با بازیابی) دو مرحله دارد: ابتدا بخش‌های مرتبط با پرسش کاربر از میان اسناد بازیابی می‌شوند، سپس این بخش‌ها همراه پرسش به مدل زبانی داده می‌شوند تا پاسخ را بر اساس آن‌ها تولید کند. نتیجه، پاسخی است که به اسناد شما متکی است، قابل ارجاع است و با به‌روزرسانی اسناد، بدون آموزش دوباره مدل به‌روز می‌شود.
RAG یا فاین‌تیون؟
| RAG | فاین‌تیون | |
|---|---|---|
| هدف اصلی | افزودن دانش و اطلاعات | تغییر رفتار، لحن و قالب پاسخ |
| به‌روزرسانی دانش | با افزودن سند، فوری | نیاز به آموزش دوباره |
| ارجاع به منبع | دارد | ندارد |
| هزینه شروع | کم | بیشتر؛ داده آموزشی و GPU |
برای چت‌بات روی اسناد، تقریباً همیشه RAG نقطه شروع درست است. فاین‌تیون مکمل است، نه جایگزین؛ توضیح در استنتاج یا فاین‌تیون و فاین‌تیون با QLoRA.
معماری چت‌بات RAG
- ورود اسناد: خواندن PDF، Word، صفحات وب و پایگاه دانش؛ استخراج متن و پاک‌سازی.
- قطعه‌بندی (Chunking): تقسیم متن به بخش‌های چندصد کلمه‌ای.
- Embedding: تبدیل هر قطعه به یک بردار عددی که معنای آن را نشان می‌دهد.
- ذخیره: نگهداری بردارها و متن در پایگاه داده برداری همراه با فراداده (منبع، تاریخ، سطح دسترسی).
- پرسش: تبدیل پرسش کاربر به بردار و یافتن نزدیک‌ترین قطعه‌ها.
- تولید: ارسال قطعه‌های یافت‌شده و پرسش به مدل زبانی با دستور «فقط بر اساس این متن‌ها پاسخ بده».
آماده‌سازی و قطعه‌بندی اسناد
کیفیت RAG بیش از هر چیز به کیفیت داده بستگی دارد:
- استخراج متن دقیق: PDFهای اسکن‌شده OCR لازم دارند؛ جدول‌ها را با ساختار نگه دارید.
- قطعه‌بندی معنادار: بر اساس عنوان‌ها و پاراگراف‌ها، نه برش کورکورانه هر N کاراکتر. اندازه رایج ۳۰۰ تا ۸۰۰ توکن با کمی همپوشانی است.
- افزودن زمینه: عنوان سند و بخش را به ابتدای هر قطعه اضافه کنید تا قطعه به‌تنهایی معنا داشته باشد.
- حذف تکراری‌ها و نسخه‌های قدیمی: وجود سه نسخه از یک آیین‌نامه، پاسخ متناقض می‌سازد.
نکات فارسی: حروف عربی و فارسی را یکسان کنید (ی و ی، ک و ک)، نیم‌فاصله‌ها را یکدست کنید و اعداد فارسی و انگلیسی را در صورت نیاز همسان کنید؛ در غیر این صورت «کتاب» و «کتاب» دو کلمه متفاوت دیده می‌شوند.
مدل Embedding و زبان فارسی
مدل Embedding باید زبان اسناد را خوب بفهمد. مدل‌های چندزبانه مثل BAAI/bge-m3 یا خانواده multilingual-e5 از فارسی پشتیبانی می‌کنند و روی سرور خودتان اجرا می‌شوند. پیش از انتخاب نهایی، چند مدل را روی پرسش‌های واقعی کاربران و اسناد خودتان مقایسه کنید. Ollama هم مدل‌های Embedding را سرو می‌کند؛ راهنما در Ollama چیست.
نکته مهم: اگر مدل Embedding را عوض کنید، همه اسناد باید دوباره Embed شوند؛ بردارهای دو مدل با هم قابل مقایسه نیستند.
پایگاه داده برداری
| گزینه | مناسب برای |
|---|---|
| PostgreSQL + pgvector | تیم‌هایی که PostgreSQL دارند؛ داده و فراداده در یک جا |
| Qdrant | جستجوی برداری سریع با فیلتر فراداده، قابل اجرا با Docker |
| Chroma | نمونه اولیه و پروژه‌های کوچک |
برای بیشتر سازمان‌ها با ده‌ها هزار تا چند میلیون قطعه، pgvector یا Qdrant کافی است. نمونه اجرای PostgreSQL با Docker در n8n، PostgreSQL و Ollama.
بازیابی بهتر: ترکیبی و Rerank
- جستجوی ترکیبی (Hybrid): جستجوی برداری معنا را می‌فهمد اما گاهی کدها، شماره‌ها و نام‌های خاص را از دست می‌دهد. ترکیب آن با جستجوی کلیدواژه‌ای (BM25) دقت را بالا می‌برد.
- Rerank: ابتدا ۲۰ تا ۵۰ قطعه را بازیابی و سپس با یک مدل Reranker مرتب کنید و فقط چند قطعه برتر را به مدل بدهید.
- فیلتر فراداده: محدود کردن جستجو به دپارتمان، نوع سند یا تاریخ.
- بازنویسی پرسش: در گفتگوهای چندمرحله‌ای، پرسش‌هایی مثل «مدت آن چقدر است؟» را با توجه به تاریخچه به پرسش کامل تبدیل کنید.
تولید پاسخ با ارجاع
دستور سیستم (System Prompt) باید مدل را به پاسخ فقط بر اساس متن‌های ارائه‌شده، ذکر منبع و گفتن «در اسناد پیدا نشد» در صورت نبود پاسخ ملزم کند. مدل‌های متن‌باز مثل Qwen، Llama یا Gemma با پشتیبانی مناسب از فارسی روی سرور GPU اجرا می‌شوند. اندازه مدل و حافظه لازم را در VRAM لازم برای LLM و ابزار سرو را در Ollama یا vLLM ببینید. یک API سازگار با OpenAI، اتصال چت‌بات به برنامه‌های دیگر را ساده می‌کند؛ راهنما در ساخت API سازگار با OpenAI.
ارزیابی و بهبود
- مجموعه‌ای از ۵۰ تا ۲۰۰ پرسش واقعی با پاسخ و منبع درست بسازید.
- بازیابی را جداگانه بسنجید: آیا قطعه درست بین چند نتیجه اول هست؟
- پاسخ‌ها را از نظر درستی، وفاداری به منبع و کامل بودن بررسی کنید.
- بازخورد کاربران (پسندیدم/نپسندیدم) را جمع‌آوری کنید و پرسش‌های بدون پاسخ را برای تکمیل اسناد بررسی کنید.
بیشترین بهبود معمولاً از اصلاح قطعه‌بندی، داده و بازیابی می‌آید، نه از عوض کردن مدل زبانی.
زیرساخت و امنیت
- میزبانی داخلی: اجرای مدل و پایگاه داده روی سرور خودتان، اسناد محرمانه را از ارسال به سرویس‌های خارجی دور نگه می‌دارد. مقایسه در سرور GPU یا API.
- کنترل دسترسی: هر کاربر فقط باید پاسخ را از اسنادی بگیرد که اجازه دیدنشان را دارد؛ سطح دسترسی را در فراداده ذخیره و در جستجو فیلتر کنید.
- تزریق دستور (Prompt Injection): متن داخل اسناد ممکن است حاوی دستور برای مدل باشد؛ آن را داده بدانید و ابزارهای حساس را به مدل ندهید.
- لاگ و حریم خصوصی: پرسش‌های کاربران ممکن است اطلاعات حساس داشته باشد؛ مدت نگهداری لاگ‌ها را محدود کنید.
برای شروع سریع با رابط کاربری آماده و امکان بارگذاری سند، Open WebUI گزینه خوبی است.
سوالات متداول
برای چت‌بات RAG چه سخت‌افزاری لازم است؟
Embedding و پایگاه داده روی CPU هم اجرا می‌شوند؛ مدل زبانی برای پاسخ سریع به GPU نیاز دارد. برای مدل‌های ۷ تا ۱۴ میلیارد پارامتری کوانتیزه‌شده، یک GPU با ۱۶ تا ۲۴ گیگابایت VRAM نقطه شروع مناسبی است.
چرا چت‌بات جواب اشتباه می‌دهد؟
معمولاً قطعه درست بازیابی نشده است. ابتدا بررسی کنید چه قطعه‌هایی به مدل رسیده؛ اگر درست نبودند، قطعه‌بندی، مدل Embedding یا جستجوی ترکیبی را اصلاح کنید.
اسناد به‌روز شوند، چه باید کرد؟
فقط اسناد تغییرکرده را دوباره پردازش و قطعه‌های قدیمی آن‌ها را حذف کنید. یک شناسه پایدار برای هر سند این کار را ساده می‌کند.
آیا RAG توهم مدل را کاملاً حذف می‌کند؟
خیر، اما به‌شدت کاهش می‌دهد. نمایش منبع کنار پاسخ به کاربر امکان بررسی می‌دهد.
زیرساخت هوش مصنوعی داخلی
سرورهای GPU تراست هاست برای اجرای مدل‌های زبانی و چت‌بات‌های RAG روی اسناد سازمانی، در دیتاسنتر داخل کشور آماده‌اند.
