RAG لوکال چیست؟ ساخت دانشنامه خصوصی برای فایلهای واقعی
RAG لوکال به مدل اجازه میدهد به اسناد واقعی شما تکیه کند، بدون اینکه لازم باشد دانش شرکت را داخل وزن مدل آموزش دهید. کیفیت extraction، chunking، metadata، retrieval و ارزیابی معمولاً از بزرگتر کردن LLM مهمتر است.
RAG لوکال را اغلب با جمله «PDFهایت را بده و با آنها چت کن» معرفی میکنند. برای دمو جذاب است، ولی برای پروژه واقعی کافی نیست. اگر سیستم جواب اشتباه بدهد، باید بدانید خطا در استخراج متن بوده، chunking، retrieval یا خود مدل.
RAG حرفهای یک زنجیره قابلبررسی است: سند → استخراج → قطعهبندی → embedding → بازیابی → context → پاسخ → ارجاع.
RAG لوکال چه مسئلهای را حل میکند؟
مدل زبانی همه فایلهای خصوصی و آخرین اطلاعات سازمان شما را نمیشناسد. RAG بهجای آموزش دوباره مدل، هنگام سؤال بخشهای مرتبط سند را پیدا میکند و کنار سؤال به LLM میدهد.
کاربردهای واقعی:
- قراردادها؛
- راهنمای تولید؛
- سناریو و فیلمنامه؛
- مستندات فنی؛
- FAQ مشتری؛
- گزارش جلسه؛
- transcript مصاحبه.
لوکال بودن زمانی مهمتر میشود که این فایلها نباید بیدلیل به سرویس خارجی ارسال شوند.
معماری در شش مرحله
۱. Ingestion
PDF، DOCX، Markdown، HTML، subtitle یا transcript وارد میشود.
۲. Extraction
متن و ساختار استخراج میشود. PDF اسکنشده ممکن است OCR بخواهد.
۳. Chunking
متن به قطعههایی تقسیم میشود که هم معنا داشته باشند و هم برای retrieval مناسب باشند.
۴. Embedding
هر chunk به بردار عددی تبدیل میشود.
۵. Retrieval
سؤال کاربر embed میشود و نزدیکترین بخشها بازیابی میشوند.
۶. Generation
مدل پاسخ را با context بازیابیشده میسازد.
مشکل شماره یک: PDF بد
اگر extraction خراب باشد، بهترین LLM هم نجاتتان نمیدهد.
مشکلات رایج:
- ستونها جابهجا میشوند؛
- header/footer وارد متن میشوند؛
- جدول تبدیل به رشته بیمعنی میشود؛
- OCR عددها را غلط میخواند؛
- صفحه اسکنشده متن ندارد.
قبل از ساخت vector database، متن استخراجشده ۱۰ فایل واقعی را دستی ببینید.
Chunking جایی است که کیفیت ساخته میشود
تقسیم مکانیکی هر ۵۰۰ کاراکتر ساده است، اما اغلب بد.
بهتر است ساختار را حفظ کنید:
- تیتر و زیرتیتر؛
- پاراگراف؛
- بند قرارداد؛
- سؤال و جواب؛
- scene یا shot؛
- speaker در transcript.
Overlap باید هدف داشته باشد. overlap زیاد index را باد میکند و شباهت کاذب میسازد؛ overlap کم context را نصف میکند.
Metadata را جدی بگیرید
برای هر chunk اطلاعاتی مثل این نگه دارید:
- نام فایل؛
- نسخه؛
- تاریخ؛
- صفحه؛
- بخش؛
- پروژه؛
- سطح دسترسی.
بعداً retrieval را میتوان فیلتر کرد. کاربر تیم A نباید سند محرمانه تیم B را ببیند فقط چون embedding آن نزدیک است.
Semantic Search همیشه کافی نیست
Embedding معنای نزدیک را خوب پیدا میکند. Keyword search برای شماره قرارداد، کد محصول، اسم خاص یا عبارت دقیق گاهی بهتر است.
Hybrid Search میتواند candidateها را از هر دو روش بگیرد، ترکیب کند و بعد rerank انجام دهد.
Reranker چه میکند؟
Retriever سریع است و چند candidate برمیگرداند. reranker سؤال و candidateها را دقیقتر مقایسه میکند و ترتیب را اصلاح میکند.
در دیتابیس بزرگ، این مرحله میتواند تفاوت واضحی ایجاد کند، هرچند latency اضافه دارد.
مدل باید اجازه داشته باشد «نمیدانم» بگوید
یکی از مهمترین قوانین prompt این است: اگر جواب در context نیست، حدس نزن.
همچنین پاسخ باید به منبع، نام سند یا صفحه ارجاع دهد. citation باعث میشود کاربر بتواند ادعا را بررسی کند.
ارزیابی را با سه سؤال خوشگل تمام نکنید
مجموعه تست بسازید:
- سؤال ساده؛
- سؤال چندمرحلهای؛
- سؤال عددی؛
- سؤال با سند قدیمی و جدید؛
- سؤال بدون پاسخ؛
- سؤال با دو سند متناقض؛
- اسم و کد دقیق.
برای هر سؤال مشخص کنید retrieval درست چه chunkهایی است.
بعد دو لایه را جدا بسنجید:
Retrieval quality: آیا سند درست پیدا شد؟
Answer quality: آیا مدل از همان سند درست استفاده کرد؟
اگر این دو را قاطی کنید، ریشه خطا پیدا نمیشود.
موتور مدل را کجا اجرا کنیم؟
LLM میتواند از طریق Ollama یا LM Studio اجرا شود. برای معماری service، Ollama و Open WebUI را ببینید.
LM Studio در مستندات خود قابلیت chat with documents آفلاین را هم توضیح میدهد: مستندات LM Studio
برای پروژه سفارشی میتوانید embedding model و vector store را مستقل انتخاب کنید.
مثال: آرشیو تولید فیلم
فرض کنید ۳۰۰ فایل دارید:
- brief؛
- script؛
- breakdown؛
- call sheet؛
- transcript؛
- گزارش تولید.
metadata شامل project، department، date و document_type است.
کارگردان میپرسد: «در نسخه آخر فیلمنامه، دلیل تغییر لوکیشن صحنه ۲۷ چه بود؟»
سیستم باید:
- نسخه آخر را فیلتر کند؛
- scene 27 و یادداشت مرتبط را پیدا کند؛
- پاسخ دهد؛
- سند و صفحه را نشان دهد.
این RAG واقعی است، نه صرفاً چت با PDF.
RAG یا Fine-tune؟
RAG برای دانش متغیر و اسناد مناسب است. Fine-tune بیشتر برای تغییر رفتار، سبک، format یا تخصص رفتاری مدل استفاده میشود.
قیمت محصولی که هر هفته عوض میشود نباید داخل وزن مدل حک شود؛ باید از منبع داده بازیابی شود.
امنیت
- فایل منبع را read-only نگه دارید؛
- index را version کنید؛
- سطح دسترسی metadata داشته باشید؛
- log را محدود کنید؛
- backup بگیرید؛
- حذف واقعی داده را تست کنید.
برای زیرساخت کاملتر امنیت و بکاپ Local AI را ببینید.
چکلیست RAG خوب
- extraction را دستی دیدهام؟
- chunk براساس ساختار است؟
- metadata کافی دارم؟
- سؤال بدون جواب را تست کردهام؟
- citation دارم؟
- retrieval و generation جدا ارزیابی میشوند؟
- سطح دسترسی کنترل شده؟
- نسخه سند مشخص است؟
مدل متوسط با retrieval خوب اغلب از مدل بزرگ با retrieval ضعیف مفیدتر است.
پرسشهای متداول
RAG چه فرقی با Fine-tune دارد؟
در RAG دانش بیرونی هنگام پاسخ بازیابی و به مدل داده میشود؛ Fine-tune وزن یا رفتار مدل را تغییر میدهد. برای اسناد بهروز، RAG معمولاً انعطافپذیرتر است.
آیا RAG میتواند کاملاً لوکال باشد؟
بله، extraction، embedding، vector store و LLM میتوانند روی زیرساخت محلی اجرا شوند، اگر componentهای انتخابی این حالت را پشتیبانی کنند.
چرا RAG جواب اشتباه میدهد؟
متن ممکن است بد استخراج شود، chunking ضعیف باشد، retrieval سند نامربوط بیاورد یا مدل خارج از context حدس بزند.
برای RAG مدل خیلی بزرگ لازم است؟
نه الزاماً. کیفیت retrieval و ساخت context در بسیاری از پروژهها بهاندازه یا بیشتر از اندازه LLM اهمیت دارد.
