درسهای یه RAG سازمانی که روزی ۱۵ هزار سؤال جواب میده
هوش مصنوعیخلاصهٔ کاملتر
نویسنده با یه سؤال ساده شروع میکنه: اطلاعاتی که یه کارمند لازم داره واقعاً کجا زندگی میکنه؟ جواب صادقانهش اینه — یه جایی تو اسلک، شاید تو یه سند Confluence از ۲۰۲۱، احتمالاً تو یه ایشو گیتهاب که شش ماه پیش بسته شده، و قطعاً هیچجای قابلپیدا کردن. قرار بود پایگاههای دانش هوش مصنوعی این رو حل کنن؛ بیشترشون نکردن.
قبل از بررسی شکستها، خود RAG رو توضیح میده: کاربر سؤال میپرسه، سیستم تو یه انبار دانش دنبال محتوای مرتبط میگرده، محتوای بازیابیشده بهعنوان زمینه به مدل داده میشه و مدل جواب رو بر پایهٔ همون میسازه. مزیتش نسبت به fine-tuning هم روشنه: دانش رو بدون بازآموزی مدل بهروز میکنی، سیستم میتونه منبع بده و جواب قابلراستیآزمایی بشه، با دادهٔ خصوصی کار میکنه، و مدل زیرین قابل تعویضه.
ولی به گفتهٔ نویسنده، نمونهٔ اولیهٔ RAG سخت نیست؛ نسخهٔ سازمانی سخته، چون باید همزمان حجم بالا، تنوع منابع، تأخیر زیر یه ثانیه، نرخ توهم پایین، کنترل دسترسی و تازگی داده رو تأمین کنه — و بیشتر سیستمها روی دو سه تای اینها همزمان زمین میخورن.
حالتهای شکست هم قابلپیشبینیان. اول تکهکردن: قطعهٔ خیلی بزرگ بازیابی رو بیدقت میکنه و قطعهٔ خیلی کوچیک زمینه رو از مدل میگیره؛ استراتژیهای پیشفرض که فقط بر اساس تعداد توکن یا شکست پاراگراف میبرن، ساختار سند رو نادیده میگیرن و نتیجهش نصفشدن یه جدول یا تکهتکه شدن یه گفتگوی اسلک تو دوازده بردار جداست. دوم ناهماهنگی بازیابی با نیت سؤال: جستجوی برداری برای سؤالهای مفهومی خوبه ولی برای جستجوی مشخص ضعیفه، و اینجا جستجوی کلیدواژهای بهتر عمل میکنه. سوم نبود حلقهٔ بازخورد، و چهارم تأخیر انباشته در مقیاس.
سیستم Cerebras از سه منبع تغذیه میشه: اسلک برای بحثهای غیررسمی، گیتهاب برای تصمیمهای فنی، و Confluence برای مستندات رسمی — یعنی کل چرخهٔ تولید دانش تو یه شرکت فناوری. خط لولهٔ مصرف داده پیوستهست نه دستهای، چون به روایت نویسنده دانش کهنه سریعترین راه نابودی اعتماد کاربره. تکهکردن هم منبعآگاهه: رشتهٔ اسلک یکجا نگه داشته میشه چون زمینهٔ گفتگویی مهمه، ایشو گیتهاب با حفظ عنوان و برچسبها تو فراداده تکه میشه، و صفحهٔ Confluence حول سرتیترها بریده میشه نه بر اساس شمارش توکن.
لایهٔ بازیابی ترکیبیه: جستجوی برداری معنایی کنار تطبیق کلیدواژهای BM25، و بعد ادغام و رتبهبندی مجدد نتایج با یه مدل کوچیکتر قبل از تحویل به مدل اصلی. نویسنده این رو یه انتخاب معمارانهٔ معنادار میدونه: خیلی از سیستمها رتبهبندی مجدد رو بخاطر تأخیرش حذف میکنن، ولی وقتی استنتاج بهقدر کافی سریع باشه این هزینه قابلپرداخته. نکتهٔ عمیقتر همینه — سرعت فقط یه معیار کارایی نیست، تعیین میکنه اصلاً کدوم تصمیمهای معماری در دسترس تو هستن: بازیابی قطعههای بیشتر، بسط کوئری، و بازیابی موازی از چند منبع. رابط کاربریش هم عمداً همون اسلکه، چون اگه پایگاه دانش آدمها رو مجبور کنه جریان کارشون رو عوض کنن، پذیرشش افت میکنه.
پنج اصلی که نویسنده جمعبندی میکنه: استراتژی تکهکردن رو با نوع محتوا جور کن و فرادادههای ساختاری رو نگه دار تا موقع بازیابی قابل فیلتر باشن؛ بازیابی ترکیبی رو جدی بگیر چون جستجوی معنایی و کلیدواژهای مکمل همدیگهان؛ از روز اول برای مصرف پیوسته بساز؛ بهجای فقط جواب، منبع رو هم نشون بده چون توهم یه خاصیت این فناوریه نه یه باگ قابلوصله؛ و چیزهایی مثل حجم پرسش، تأخیر، دقت بازیابی، بازخورد کاربر و نرخ سؤالهای بیجواب رو اندازه بگیر.
نکتهٔ پایانی و شاید مهمترین حرف مقاله، جواب به این سؤاله که رایجترین اشتباه تیمها چیه: بهینهسازی مدل و کمسرمایهگذاری روی بازیابی. تیمها وقتشون رو صرف مقایسهٔ مدلها میکنن در حالی که تکهکردن پیشفرض و بازیابی تکمسیره دستنخورده مونده — و اگه قطعههای بازیابیشده غلط باشن، هیچ مدلی جواب خوب نمیده.
نکات کلیدی:
- بیشتر شکستهای RAG سازمانی از تکهکردن بد، بازیابی تکمسیره و دادههای کهنه میاد، نه از انتخاب مدل
- تکهکردن باید منبعآگاه باشه: رشتهٔ اسلک، ایشو گیتهاب و صفحهٔ ویکی سه رفتار متفاوت میخوان
- بازیابی ترکیبی معنایی و کلیدواژهای، بهعلاوهٔ رتبهبندی مجدد، بیشترین اثر رو روی دقت داره
- مصرف پیوستهٔ داده لازمه؛ دانش کهنه اعتماد کاربر رو سریعتر از هر خطای دیگهای از بین میبره
- سرعت استنتاج یه قید طراحیه: تعیین میکنه چه معماریهایی اصلاً ممکنان
- نشون دادن منبع کنار جواب، هم توهم رو مهار میکنه هم حلقهٔ بازخورد میسازه
