צוותים המעבירים Retrieval-Augmented Generation (RAG) מדמו (demo) לשירות ייצור (production) נתקלים בכמה החלטות קריטיות המבדילות בין עוזר שימושי לבין כזה שיוצר רעש. חמש בחירות עיצוביות — chunking, embedding model, vector store, hybrid search, ו-evaluation — שולטות על הדיוק (precision), ה-recall והשיהוי (latency) שהמשתמשים האמיתיים חווים.
למה המעבר מפרוטוטייפ לייצור כל כך חשוב
רוב המדריכים מריצים pipeline של RAG בכמה עשרות שורות קוד, ואז עוצרים לפני הקפדנות ההנדסית הנדרשת לתעבורה חיה (live traffic).
1. אסטרטגיית chunking – שער האיכות הראשון
גודל ה-chunk הוא הקריטי ביותר. chunks גדולים מטשטשים את האות עם טקסט לא קשור; chunks קטנים מדי מסירים את ההקשר הסובב שהמודל זקוק לו כדי לייצר תשובות קוהרנטיות. חלוקה לפי גודל קבוע מתעלמת מהמבנה הטבעי של חומר המקור.
כלל אצבע מעשי
- חלקו על גבולות לוגיים: כותרות במסמכים, ירידות שורה בפסקאות במאמרים, הגדרות פונקציות בקוד.
- שמרו על chunks קטנים מספיק כדי לאפשר שליפה מדויקת, אך שמרו על ה-parent section הגדול יותר עבור שלב ה-generation של ה-LLM. תבנית "parent-child" זו מאפשרת ל-retriever להציג קטע ממוקד בזמן שה-generator רואה מספיק הקשר כדי להישאר עובדתי.
2. Embedding models – כיצד נמדד הדמיון
מודל ה-embedding הופך טקסט לווקטורים שמנוע חיפוש הדמיון משווה. מודל חזק ורב-תכליתי כמו text-embedding-3-large של OpenAI מספק בסיס איתן לרוב התחומים. אם הקורפוס נמצא בתחום מתמחה מאוד — חוות דעת משפטיות, רשומות רפואיות, מפרטים טכניים — בדקו מודל ספציפי לדומיין (domain-specific), אך רק לאחר שמדדתם שיפור מוחשי על הנתונים שלכם.
מתי להחליף
- החליפו רק אם אתם רואים שיפור מדיד בציוני הרלוונטיות שחשובים לאפליקציה שלכם (למשל, context precision גבוה יותר).
3. Vector database – הרחבת מאגר הנתונים
בחרו vector store שמתאים לתשתית הקיימת שלכם ולמספר הווקטורים הצפוי.
- pgvector רץ בתוך PostgreSQL ומטפל בנוחות בעד כמיליון וקטורים. הוא אידיאלי לצוותים שכבר מפעילים מסד נתונים רלציוני וזקוקים לפתרון בעל תחזוקה נמוכה.
- Qdrant מצטיין בטווח של 1M–100M, ומספק תפוקה (throughput) גבוהה יותר ושיהוי (latency) נמוך יותר עבור קורפוסים גדולים יותר.
- Pinecone מספק שירות ענן מנוהל לחלוטין, מה שמסיר את הנטל התפעולי של אירוח עצמי (self-hosting).
4. Hybrid search ו-reranking – איזון בין משמעות לדיוק
חיפוש וקטורי טהור מצטיין בדמיון סמנטי אך עלול לפספס התאמות מילות מפתח מדויקות שמשתמשים מצפים להן. חיפוש היברידי (Hybrid search) רובד אינדקס מילות מפתח מסורתי מסוג BM25 מעל אינדקס הווקטורים, ולאחר מכן ממזג את שתי רשימות התוצאות. Reciprocal Rank Fusion (RRF) מקצה לכל מועמד ציון המבוסס על הדירוג שלו בשתי הרשימות ומשלב אותם, מה שמגביר פריטים שמופיעים גבוה באחת מהן.
Reranking מוסיף מסנן דיוק סופי. לאחר השליפה ההיברידית, הזינו את ה-top-N (בדרך כלל 50) המועמדים ל-cross-encoder — מודל שמעריך ציון לצמד שאילתה-מסמך במשותף. הציונים של ה-cross-encoder מחליפים את מספרי הדמיון המקוריים, מה שמאפשר לכם לבחור את ה-chunk הרלוונטי ביותר לפני העברתו ל-LLM. שלב נוסף זה מניב לעיתים קרובות קפיצה ניכרת באיכות התשובה, במיוחד עבור קורפוסים ארוכים או רועשים.
5. Evaluation ו-abstention – מדידת מה שחשוב
אינכם יכולים לשפר מערכת שאינכם מודדים. מסגרת העבודה RAGAS מציעה ארבעה מדדים שביחד לוכדים את הבריאות של pipeline של RAG:
- Context Precision – הפרופורציה של ה-chunks שנשלפו המכילים בפועל את התשובה.
- Context Recall – החלק מכל ה-chunks הרלוונטיים שנשלפו.
- Faithfulness – המידה שבה התשובה שנוצרה נשארת בתוך ההקשר שנשלף, תוך הימנעות מהזיות (hallucinations).
- Answer Relevance – עד כמה התשובה הסופית מספקת את השאילתה המקורית.
עקבו אחר המדדים הללו על סט בדיקה מתגלגל (rolling test set) המשקף את תעבורת הייצור.
מנגנון הגנה אחרון, שלעיתים קרובות נשכח, הוא abstention (הימנעות). במקום לאלץ את המודל לענות בביטחון נמוך, הגדירו סף (threshold) לציון ה-faithfulness או ה-relevance שמפעיל תגובת "אני לא יודע". משתמשים מעדיפים הודאה ברורה בחוסר ודאות על פני תשובה בטוחה אך שגויה, והגיבוי (fallback) מפחית עלויות תמיכה בהמשך הדרך.
התייחסו לכל אחד מחמשת התחומים הללו כנקודת החלטה ולא כהגדרה של "הגדר והשכח" (set-and-forget), ותוכלו להפוך את ה-RAG מדמו מרשים לשירות ייצור אמין. התמורה: מערכת שעונה במהירות, נשארת בנושא, ויודעת מתי לשתוק.