רוב המדריכים על RAG מסתיימים בדיוק בנקודה שבה סביבת הייצור (production) מתחילה. אתם מפצלים את המסמכים שלכם לצ'אנקים (chunks) של 512 טוקנים, מעבירים אותם דרך מודל embedding יחיד, וקוראים לבסיס נתונים וקטורי עם שליפת top-k פשוטה. בדמו, זה נראה משכנע. תשאלו את הבוט על מדיניות החופשות של החברה שלכם והוא יחזיר פסקה קוהרנטית. כולם מהנהנים. לרוע המזל, דמואים משקרים.

סביבת הייצור חושפת כל קיצור דרך. צ'אנקים קבועים חותכים חוזים משפטיים באמצע סעיפי שיפוי. תיעוד API הופך לרעש חופף ששטף את האות (signal) שאתם באמת צריכים. השיהוי (latency) עולה עד שמשתמשים נוטשים את השאילתה לפני שהתשובה מגיעה. אנחנו נתקלנו בקיר הזה ונאלצנו לבנות מחדש. שכבת השליפה שלנו התפתחה מ-"חיפוש סמנטי ותקווה" לצינור (pipeline) מבוקר ומנוטר. התוצאה הייתה Recall של 95% וקיצוץ של 40% בשיהוי. הנה מה שעבד באמת.

התאימו את אסטרטגיית ה-Chunking למסמך

ברירת המחדל של 512 טוקנים נשמרת כי היא קלה, לא כי היא נכונה. מסמכים שונים נושאים משמעות בצורה שונה, ואסטרטגיית ה-chunking שלכם צריכה לשקף זאת.

עבור חוזים משפטיים, השתמשו ב-recursive chunking המכבד גבולות מבניים. השפה המשפטית היא מקוננת. סעיף תלוי בסעיף שמעליו, וחיתוך קבוע באמצע משפט הורס את הלוגיקה של התחייבות. recursive chunking מנסה לבצע פיצולים קודם כל לפי מפרידים טבעיים — פסקאות, ואז משפטים — לפני שהוא כופה מגבלת טוקנים. זה שומר על סעיפי שיפוי או אחריות שלמים.

עבור תיעוד API, השתמשו ב-function-aware chunking. מפתחים לא מחפשים פסקאות אקראיות; הם מחפשים נקודות קצה (endpoints), פרמטרים וחתימות שגיאה. צ'אנק צריך להכיל את חתימת הפונקציה המלאה, התיאור שלה וסכימת ההחזרה (return schema) כיחידה לוגית אחת. אם תפצלו את הבלוק הזה לחצי, מערכת השליפה תחזיר חצי מההקשר ומודל הגנרציה יפיק הזיות (hallucinates) לגבי השאר.

עבור כרטיסי תמיכה, הסתמכו על semantic chunking שעוקב אחר תורות שיחה (conversation turns). שרשראות תמיכה הן ליניאריות וחזרתיות. לקוח חוזר על הבעיה, סוכן מבקש לוגים, הלקוח מצרף אותם. כל תור הוא יחידה סמנטית בפני עצמה. chunking לפי תורות שומר על כך שנדע מי אמר מה ומתי, מה שחשוב כשמשתמש שואל, "מה הסוכן הציע ביום שלישי?"

עבור וויקי פנימיים, נסו agentic chunking. העבירו ל-LLM סעיף ובקשו ממנו להחליט היכן נושא אחד מסתיים ונושא אחר מתחיל. זה עולה יותר בזמן ההזנה (ingest), אך וויקיים הם מבולגנים. דפים מכילים עדכונים לא קשורים מצוותים שונים, וגבול שהוגדר על ידי אדם לעיתים רחוקות עוזר. מתן אפשרות למודל לצייר גבולות על בסיס שינויי נושא מפחית את הרעש באופן דרמטי.

הרצת מספר אסטרטגיות בצינור אחד דורשת תיוג מסמכים לפי סוג בזמן ההזנה. המשמעת הקטנה הזו בסכימה משתלמת באופן מיידי.

שלבו שיטות חיפוש, אל תבחרו רק אחת

חיפוש וקטורי מבין כוונה (intent), אך הוא נכשל באופן עקבי בהתאמות מדויקות. בקשו קוד שגיאה ERR_CONNECTION_REFUSED או SKU ספציפי, ו-embeddings צפופים לעיתים קרובות יחזירו תוצאות דומות מבחינה מושגית אך שגויות מבחינה עובדתית. BM25, שיטת השליפה הקלאסית מבוססת מילות המפתח (sparse retrieval), מטפלת במחרוזות מדויקות בצורה נפלאה אך מפספסת ניואנסים סמנטיים. אתם צריכים את שניהם.

השתמשו ב-hybrid retrieval. הריצו חיפוש וקטורי ו-BM25 במקביל. לאחר מכן שלבו אותם באמצעות Reciprocal Rank Fusion (RRF). RRF מתגמל מסמכים ששתי השיטות מסכימות עליהם כרלוונטיים, תוך שהוא עדיין מעלה מועמדים חזקים מכל אחת מהגישות. המתמטיקה פשוטה והתוצאה יציבה: אף שיטת שליפה בודדת לא שולטת בדירוג הסופי.

לאחר המיזוג (fusion), הוסיפו cross-encoder reranker. השלב הראשון — שליפה וקטורית ו-sparse — הוא מהיר ורחב. ה-cross-encoder לאחר מכן מדרג כל זוג שאילתה-מסמך עם תשומת לב מלאה (full attention), מה שאומר שהוא למעשה קורא את המועמד מול השאלה המקורית. כן, זה מוסיף שיהוי. במקרה שלנו, בערך חמישים עד מאה מילישניות. אך השיפור ב-precision חד מספיק כדי שהטרייד-אוף יהיה ברור. אתם לא יכולים להרשות לעצמכם לדלג על זה אם אכפת לכם מה-Recall.

תקנו את השאילתה לפני שמתקנים את האינדקס

משתמשים לא כותבים שאילתות עבור מנוע החיפוש שלכם. הם כותבים אותן עבור בני אדם. "זה לא עובד" היא שאילתת תמיכה נפוצה. תיאור תכונה מעורפל הוא חיפוש נפוץ בוויקי פנימי. אם תחפשו באינדקס עם הקלט הגולמי הזה, תקבלו זבל בחזרה.

הפכו את השאילתה לפני שהיא מגיעה ל-retriever.

Use query expansion to generate multiple versions of the user’s question. If someone types “server down,” your system should also search for “service unavailable,” “502 error,” and “connection timeout.” Covering these intent variants moved our recall from 78% to 96%. It is a single step, and it costs almost nothing compared to the gain.

Use query decomposition for complex questions. When a user asks something like “How do I migrate from the legacy billing API to the new one and what breaking changes affect enterprise accounts?,” break it into sub-questions. One sub-question targets migration steps. Another targets enterprise-specific breaking changes. Each hits a different part of the index. The downstream language model synthesizes the final answer from well-retrieved chunks rather than guessing across a noisy context window.

Stop Guessing Hyperparameters

Once you have multiple chunking strategies, hybrid retrieval, and query transformation, you face a combinatorial problem. Chunk size, overlap, fusion weights, reranker depth, and expansion count all interact. Tweaking one in isolation breaks another. Grid search across this space is wasteful and slow.

Use Bayesian optimization instead. Treat this like a machine learning tuning job. Define your objective clearly: maximize recall while keeping latency under a ceiling. Build a golden dataset — a few hundred representative questions where you know precisely which chunks should be retrieved. Then let the Bayesian search explore the configuration space efficiently. It builds a probabilistic model of what works and tests the most promising regions next.

Every candidate configuration must pass the golden dataset before it reaches staging. If a new chunk size drops recall or a heavier reranker pushes you past the latency budget, the optimization catches it automatically. This removes opinion from the room. You stop debating whether 256 or 512 tokens is “better” and start reading the results.

The Outcome

The pipeline changes compounded exactly as we hoped.

  • Recall@10 climbed from 78% to 95%.
  • P95 latency dropped from 850 ms to 320 ms.
  • Hallucination rate fell from 12% to 3%.
  • Cost per query dropped by 38%, largely because better retrieval let us use a smaller generation model and fewer prompt tokens.

The latency reduction surprised some people on the team. Adding rerankers and query expansion sounds like it should slow things down. But because retrieval quality improved, the generation model needed less prompting, less speculation, and fewer retries. Good retrieval makes everything downstream cheaper.

Treat Retrieval Like Infrastructure

Retrieval is not a notebook you run once and forget. It is infrastructure, and it should be managed like code. Version your chunking strategies. When the legal team releases a new contract template, test your recursive splitter before it reaches production. Maintain your golden dataset as living documents, not a static CSV from last quarter. Automate your evaluations in CI so that a pull request modifying an embedding model or a fusion weight gets a comment with recall and latency numbers before a human ever reviews it.

Your users will never ask which embedding model you run. They will not care about your chunking heuristic or your reranker architecture. They care if the answer is correct, if it arrives fast, and if they can trust it. Build a pipeline that earns that trust, measure it honestly, and stop treating retrieval like an afterthought.

Source: Optimizing RAG At Scale
Join the discussion: GyaanSetu AI Community