من ۵۰۰ دلار برای زیرساخت RAG هزینه کردم، قبل از اینکه این ۷ اشتباه را برطرف کنم

من یک خط لوله (pipeline) RAG برای جستجوی اسناد خصوصی ساختم. این کار ۵۰۰ دلار هزینه پردازشی و هفته‌ها عیب‌یابی برای من داشت. نتایج بد بودند. کاربران پاسخ‌های اشتباه دریافت می‌کردند و پرس‌وجوها (queries) کند بودند.

من خط لوله را بازبینی کردم. ۷ اشتباه پیدا کردم. اصلاح آن‌ها همه چیز را تغییر داد.

۱. تکه‌بندی (Chunking) ثابت بر اساس توکن من اسناد را بر اساس ۵۱۲ توکن تقسیم می‌کردم. این کار بافت (context) را از بین می‌برد. مثلاً توضیح یک API در وسط جمله قطع می‌شد. LLM قطعات پراکنده را دریافت می‌کرد و پاسخ‌های بی‌ارزش می‌داد. راه حل: استفاده از تکه‌بندی معنایی (semantic chunking).

  • تقسیم بر اساس مرزهای طبیعی مانند پاراگراف‌ها یا تیترها.
  • استفاده از بازیابی سند والد (parent-document retrieval).
  • ایجاد تکه‌های کوچک فرزند (child chunks) برای جستجو.
  • بازگرداندن سند والد کامل به LLM.
  • اضافه کردن ۱۰ تا ۲۰ درصد هم‌پوشانی (overlap) بین تکه‌ها.

۲. وزن‌دهی نامناسب در جستجوی ترکیبی (Hybrid Search) من از تقسیم ۵۰/۵۰ برای جستجوی برداری (vector) و کلیدواژه‌ای (keyword) استفاده کردم. این روش برای اسناد فنی شکست خورد. کاربران فنی به تطابق دقیق کلیدواژه‌ها نیاز دارند. راه حل: استفاده از وزن‌های پویا.

  • پرس‌وجوهای واقع‌گرایانه: ۳۵٪ برداری، ۶۵٪ کلیدواژه‌ای.
  • پرس‌وجوهای معنایی: ۷۵٪ برداری، ۲۵٪ کلیدواژه‌ای.
  • پرس‌وجوهای عمومی: ۶۰٪ برداری، ۴۰٪ کلیدواژه‌ای.

۳. تنظیم بیش از حد پارامترهای HNSW من ef_construction را روی حداکثر قرار دادم. این کار باعث از کار افتادن سرورم شد. تمام رم (RAM) موجود را اشغال کرد. راه حل: استفاده از پارامترهای مناسب.

  • مقدار M را بین ۸ تا ۳۲ قرار دهید.
  • مقدار ef_construction را روی ۲۰۰ قرار دهید.
  • مقدار ef_search را روی ۵۰ قرار دهید. مصرف حافظه ۷۰٪ کاهش یافت.

۴. مدل‌های Embedding عمومی من از مدلی استفاده کردم که روی ویکی‌پدیا آموزش دیده بود. اسناد من دستورالعمل‌های فنی مهندسی (engineering runbooks) بودند. مدل حوزه تخصصی من را درک نمی‌کرد. راه حل: استفاده از مدلی که برای محتوای فنی یا کد، بازتنظیم (fine-tuned) شده باشد.

۵. عدم بازنویسی پرس‌وجو (Query Rewriting) کاربران سوالات طبیعی می‌پرسند. اسناد فنی از اصطلاحات رسمی استفاده می‌کنند. این دو با هم مطابقت ندارند. راه حل: اضافه کردن یک مرحله سبک با استفاده از LLM برای بازنویسی پرس‌وجوها.

  • کاربر می‌پرسد: "why is my build slow"
  • سیستم بازنویسی می‌کند به: "CI pipeline performance optimization"
  • این کار نرخ فراخوانی (recall) را ۴۰٪ بهبود بخشید.

۶. نتایج تکراری بازیابی ۱۰ تکه برتر اغلب یک پاراگراف را سه بار تکرار می‌کرد. LLM حرف خودش را تکرار می‌کرد. راه حل: استفاده از Maximal Marginal Relevance (MMR) برای تضمین تنوع در نتایج.

۷. تست کردن مورد اشتباه من کل خط لوله را به صورت یکجا تست می‌کردم. نمی‌دانستم مشکل از بازیابی (retrieval) است یا از LLM. راه حل: جداسازی ارزیابی بازیابی.

  • نرخ برخورد (hit rate) را پیگیری کنید.
  • میانگین رتبه معکوس (MRR) را پیگیری کنید.
  • یک مجموعه تست شامل ۱۰۰ جفت پرس‌وجو-سند بسازید.

نتایج پس از اصلاحات:

  • مرتبط بودن پاسخ: 45% تا 85%
  • تأخیر: 3.2 ثانیه تا 1.8 ثانیه
  • هزینه ماهانه: 180 دلار تا 95 دلار

ابتدا تکه‌بندی را اصلاح کنید. سپس وزن‌ها. و سپس کیفیت جاسازی.

منبع: https://dev.to/kollittle/i-spent-500-on-rag-infrastructure-before-realizing-these-7-mistakes-were-killing-my-results-iph