دو هفته پیش یه پروژه چتبات پشتیبانی رو تحویل دادم. دمو عالی بود. مشتری سوال میپرسید، مدل جواب میداد، همه راضی بودن. بعد رفت پروداکشن. روز سوم یه کاربر پرسید «سیاست مرجوعی محصولی که ماه پیش خریدم چیه؟» و مدل با کمال اعتمادبهنفس یه جواب ساختگی داد. نه اینکه جواب بد بود، نه. جواب قشنگ بود، منطقی بود، و کاملاً اشتباه بود. چون مدل هیچوقت سیاست مرجوعی اون شرکت رو ندیده بود؛ فقط از الگوهای عمومی یه جواب «قابلقبول» سرهم کرده بود.
تصویر ۱: چتباتی که با اطمینان کامل، جوابی ساختگی تحویل مشتری میدهد.
اون لحظه فهمیدم، دوباره، چون قبلاً هم این درس رو گرفته بودم، که یه LLM خام، هرچقدر هم بزرگ، برای کار سازمانی بهتنهایی کافی نیست.
مشکل کجاست؟
سه تا محدودیت ساختاری هست که با پرامپتنویسی بهتر حل نمیشن:
اولی توهم (Hallucination)ه. مدل وقتی جواب دقیق رو نمیدونه، نمیگه «نمیدونم». با همون لحن مطمئن همیشگی یه چیزی میسازه که به نظر درست میاد. این برای یه چتبات عمومی شاید قابلتحمل باشه؛ برای پشتیبانی مشتری که داره درباره پولش سوال میپرسه، نه.
دومی دانش منجمده. مدل تا یه تاریخ مشخص آموزش دیده. قیمت جدید، محصول جدید، بخشنامه هفته پیش، هیچکدوم براش وجود نداره.
سومی و مهمترینش: مدل هیچوقت اسناد داخلی شما رو ندیده. دیتابیس محصولات، مستندات فنی، آییننامههای منابع انسانی، هیچکدوم. مگر اینکه خودتون بهش بدید.
حالا راهحل سادهلوحانه اینه که کل مستندات رو کپی کنی توی پرامپت. برای یه شرکت پنجنفره با سه صفحه سند شاید کار کنه. برای هر چیز بزرگتر، یا از پنجره کانتکست بیرون میزنی، یا هزینه هر کوئری اونقدر بالا میره که عملاً بهصرفه نیست.
RAG دقیقاً همین شکاف رو پر میکنه
ایده سادهست: بهجای اینکه همهچیز رو به مدل حفظ بدی یا هر بار کل مستندات رو بفرستی، موقع پرسش فقط تکههای مرتبط رو پیدا کن و بذار جلوی مدل. مدل دیگه حدس نمیزنه؛ بر اساس چیزی که جلوشه جواب میده. همون سیاست مرجوعیای که ماه پیش نوشته شده، دقیقاً همون لحظه از توی مستنداتت کشیده میشه بیرون و میره زیر دست مدل.
تصویر ۲: دیاگرام پایپلاین RAG؛ فاز آفلاین (سمت چپ) دانش شما رو آماده و ایندکس میکند، فاز آنلاین (سمت راست) موقع پرسش کاربر، فقط تکههای مرتبط را بازیابی و به مدل میدهد.
این یعنی مدل هم کمتر توهم میزنه، هم به دادههای خصوصیت دسترسی داره، هم دانشش با هر آپدیت مستندات تازه میمونه، بدون اینکه نیاز باشه مدل رو از نو آموزش بدی.
این مقاله قراره چیکار کنه؟
راستش رو بخوام بگم، من از خوندن مقالههایی که RAG رو «توضیح» میدن خسته شدم. یه دیاگرام میذارن، سه تا تعریف مینویسن، تموم. این قرار نیست اون باشه.
تا آخر این مقاله:
یه پایپلاین کامل RAG میسازی. از آمادهسازی داده تا تولید پاسخ. کد واقعی، نه شبهکد.
میفهمی چرا اکثر پروژههای RAG توی فاز «دموی قشنگ» گیر میکنن و هیچوقت به پروداکشن نمیرسن. (Spoiler: معمولاً مشکل از chunking و retrievalه، نه از مدل.)
یاد میگیری کیفیت جوابها رو با عدد بسنجی، نه با اینکه «به نظرم خوبه».
و در نهایت یه سیستم قابل دیپلوی داری. حالا میخوای روی یه VPS ارزون خودمیزبان بسازیش، میخوای از API خارجی استفاده نکنی چون داده سازمانیت نباید از مرز رد بشه، یا اصلاً دسترسی نداری، مسیر فنی یکیه؛ فقط ابزار فرق میکنه.
تصویر ۳: مقایسه سه رویکرد؛ Prompt Engineering، Fine-Tuning و RAG. در RAG دانش بهجای اینکه داخل مدل حک شود، موقع پرسش از بیرون به آن داده میشود.
فصل بعد RAG رو به زبون ساده تعریف میکنیم و میبینیم کجا از Fine-Tuning و Prompt Engineering جدا میشه. بعدش مستقیم میریم سراغ ساختن.
دیدگاهتان را بنویسید