בזבזתי 500$ על תשתית RAG לפני שתיקנתי את 7 הטעויות האלו

בניתי RAG pipeline לחיפוש במסמכים פרטיים. זה עלה לי 500$ במחשוב ושבועות של ניפוי שגיאות (debugging). התוצאות היו גרועות. המשתמשים קיבלו תשובות שגויות והשאילתות היו איטיות.

ביצעתי ביקורת (audit) ל-pipeline. מצאתי 7 טעויות. התיקון שלהן שינה הכל.

  1. חלוקת טוקנים (Token Chunking) קבועה חילקתי מסמכים לפי 512 טוקנים. זה הרס את ההקשר. הסבר על API היה נקטע באמצע משפט. ה-LLM קיבל מקטעים ונתן תשובות גרועות. התיקון: שימוש ב-semantic chunking.
  • חלוקה לפי גבולות טבעיים כמו פסקאות או כותרות.
  • שימוש ב-parent-document retrieval.
  • יצירת child chunks קטנים לחיפוש.
  • החזרת ה-parent document המלא ל-LLM.
  • הוספת חפיפה (overlap) של 10-20% בין ה-chunks.
  1. משקלים לא נכונים בחיפוש היברידי (Hybrid Search) השתמשתי בחלוקה של 50/50 בין חיפוש וקטורי (vector search) לחיפוש מילות מפתח (keyword search). זה נכשל במסמכים טכניים. משתמשים טכניים זקוקים להתאמות מדויקות של מילות מפתח. התיקון: שימוש במשקלים דינמיים.
  • שאילתות עובדתיות: 35% וקטורי, 65% מילות מפתח.
  • שאילתות סמנטיות: 75% וקטורי, 25% מילות מפתח.
  • שאילתות כלליות: 60% וקטורי, 40% מילות מפתח.
  1. כוונון יתר (Over-tuning) של פרמטרי HNSW קבעתי את ef_construction למקסימום. זה הפיל את השרת שלי. זה השתמש בכל ה-RAM הזמין. התיקון: שימוש בפרמטרים מתאימים.
  • קביעת M בין 8 ל-32.
  • קביעת ef_construction ל-200.
  • קביעת ef_search ל-50. שימוש בזיכרון ירד ב-70%.

  1. מודלי Embedding כלליים השתמשתי במודל שאומן על ויקיפדיה. המסמכים שלי היו מדריכי הנדסה טכניים (runbooks). המודל לא הבין את התחום שלי. התיקון: שימוש במודל שעבר fine-tuning לתוכן טכני או קוד.

  2. היעדר שכתוב שאילתות (Query Rewriting) משתמשים שואלים שאלות בשפה טבעית. מסמכים טכניים משתמשים במונחים פורמליים. הם לא תואמים. התיקון: הוספת שלב LLM קל לשכתוב שאילתות.

  • המשתמש שואל: "why is my build slow"
  • המערכת משכתבת ל: "CI pipeline performance optimization"
  • זה שיפר את ה-recall ב-40%.

  1. תוצאות כפולות (Redundant Results) שליפת 10 ה-chunks המובילים הניבה לעיתים קרובות את אותה פסקה שלוש פעמים. ה-LLM חזר על עצמו. התיקון: שימוש ב-Maximal Marginal Relevance (MMR) כדי להבטיח גיוון בתוצאות.

  2. בדיקה של הדבר הלא נכון בדקתי את כל ה-pipeline בבת אחת. לא ידעתי אם הבעיה היא בשליפה (retrieval) או ב-LLM. התיקון: הפרדת הערכת השליפה (retrieval evaluation).

  • מעקב אחר hit rate.
  • מעקב אחר Mean Reciprocal Rank (MRR).
  • בניית סט בדיקה של 100 זוגות שאילתה-מסמך.

תוצאות לאחר התיקונים:

  • רלוונטיות התשובה: 45% עד 85%
  • Latency: 3.2s עד 1.8s
  • עלות חודשית: $180 עד $95

תקן קודם את ה-chunking. לאחר מכן את ה-weights. ואז את איכות ה-embedding.

מקור: https://dev.to/kollittle/i-spent-500-on-rag-infrastructure-before-realizing-these-7-mistakes-were-killing-my-results-iph