RAG על ChromaDB: מאב-טיפוס לפרודקשן

מדוע אב-טיפוס RAG לא מגיע לשלב הפעלה בייצור

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

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

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

השלישי — נוהל העדכון. מסמכים חיים: משהו משתנה מדי יום, משהו מבוטל. באב-טיפוס מבצעים אינדוקס מחדש ידנית ובאופן מלא, ולכן האינדקס מתרחק בשקט מהמציאות, ואין במה להבחין בכך — אין מדדי איכות וכיסוי.

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

מה נותן צינור RAG מנוהל בהפעלה

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

חיפוש היברידי במקום חיפוש וקטורי אחד

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

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

מה נראה בהפעלה

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

עדכון מאגר הידע הופך לנוהל: מסמך שהשתנה עובר אינדוקס מחדש תוך דקות, והגרסה הישנה לא מתערבבת בתשובות חדשות.

את הבסיס הטכני לכך נותנת ChromaDB: הקטעים נשמרים יחד עם מטא-נתונים — הרשאות גישה, גרסת מסמך ותאריך שינוי, ולכן הסינון מתבצע לפני החיפוש ולא אחריו. בהמשך נפרט מה בדיוק בודקים לפני העלאת הצינור לפרודקשן.

מצבי חיפוש: וקטורי, היברידי, עם דירוג מחדש

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

ברגע שבטקסט מופיעים מקטים, מספרי סעיפים וראשי תיבות, קרבה סמנטית מחטיאה: המודל לא מבחין בין "AB-1200" ל-"AB-2100".

בפועל המצבים לא מחליפים זה את זה אלא משלימים זה את זה: ההיברידי מעלה כמה עשרות מועמדים, הדירוג מחדש משאיר 3–5 קטעים רלוונטיים באמת, שמועברים להקשר של המודל.

ב-RAG על ChromaDB הדבר מוגדר ברמת השאילתה, ולכן החלפת מצב אינה דורשת בנייה מחדש של האינדקס — משתנה רק שכבת התוצאות, לא הנתונים עצמם.

כיצד אנו מטמיעים RAG: שלבי עבודה הנדסית

לפני כתיבת קוד אנו מנתחים את הנתונים: אילו מקורות קיימים, באיזה פורמט הם, באיזו תדירות משתנים ומי אחראי לעדכניות. באותו שלב אנו אוספים שאלות בקרה — כמה עשרות שאילתות אמיתיות של עובדים יחד עם תשובות שאנו מחשיבים נכונות.

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

1. מלאי מקורות. מסמנים בעלים, פורמט ותדירות עדכון של כל מסמך — מכך תלוי לוח הזמנים לחישוב מחדש של האינדקס.
2. תרשים הצינור. לפני הקוד משרטטים את נתיב הנתונים: כיצד מסמך נכנס לאינדקס, כיצד מתפצל לקטעים, כיצד מתעדכן וכיצד נעלם מסמך מיושן.
3. הגדרת חיפוש. בוחרים מודל הטמעות, גודל קטע ותוצאה היברידית — וקטור יחד עם חיפוש לפי מילות מפתח. קטעים לא רלוונטיים מנותקים, אחרת המודל עונה על רעש.
4. יצירה וציטוט. אוספים הקשר ומנהיגים כלל: התשובה מפנה למסמך המקורי, וברמת ביטחון נמוכה המערכת אומרת בכנות שאין נתונים.
5. בדיקה על שאלות בקרה. מחשבים שיעור תשובות נכונות ושיעור בדיות; את הפיצול לקטעים ואת נוסח הרמזים משנים עד שהמדדים מגיעים ליעד.
6. קבלת הפתרון ומסירה להפעלה. מקבעים מדדים, מוסרים לצוות את התרשים, הגדרות מאגר וקטורי על ChromaDB ואת נוהל העדכון. התורן יודע לבדוק לוגים ואיכות תוצאות.

הרכב האספקה: תצורות, תרשימי צינור, נהלים

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

כל מה שקובע את התנהגות המערכת בהפעלה בייצור נמצא במאגר הקוד ובתיעוד — כולל מה שבדרך כלל הולך לאיבוד במסירה: כיצד מתעדכן האינדקס ומי מורשה לגשת למסמכים.

• תצורות — פרמטרים להתחברות למאגר וקטורי ולמודל, גדלי קטעים וחפיפות, מספר המועמדים המוחזרים: קובצי סביבה, ולא ערכים בקוד.
• תרשים הצינור — נתיב המסמך מהעלאה וניקוי ועד פיצול, וקטוריזציה וכתיבה לאוסף, ואז חיפוש ויצירת תשובה; נקודות כשל מסומנות בנפרד.
• כללי גישה למסמכים — מטריצת תפקידים, ירושת הרשאות מהמקור, סינון בשלב החיפוש: המשתמש לא מקבל קטע שאינו מורשה לו.
• נוהל עדכון האינדקס — לוח זמנים לאינדוקס מלא ומוסיף, טיפול במסמכים שהשתנו ונמחקו, התאמה מול המקור.
• תיעוד הפתרון — תיאור ארכיטקטורה, הרצה מקומית, רשימת מדדי איכות תשובה והשהיה, סדר פעולות בעת ירידה בביצועים.
• סט שאלות בדיקה עם מקורות ייחוס — לקבלה ולרגרסיה לאחר החלפת מודל, ובנוסף הליך rollback: תמונת מצב של האוסף וגרסת תצורה הצמודות לריליס.

חבילה כזו מסירה את התלות בספק: את המערכת אפשר לפתח, לבדוק ולהעביר בתוך הצוות, בלי לשחזר את הלוגיקה מתוך הקוד.

מקרה בוחן: חיפוש במאגר ידע לשירות תמיכה

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

בקו הראשון זה הביא ל-4–6 דקות לחיפוש תשובה, כ-40% מהתשובות נשלחו בלי עיגון במקור, ומקרים שנויים במחלוקת הוסלמו לקו השני — שם הצטברה שליש מהפניות.

מה עשינו

הקמנו מערך חיפוש על ChromaDB: המסמכים נחתכו לקטעים עם חפיפה של 10–15% מהאורך, כדי שהתשובה לא תיקרע בגבול המשמעות, ועברו אינדוקס. החיפוש מתבצע בשני שלבים — קרבה סמנטית בתוספת מסננים לפי סוג מסמך, מחלקה ותאריך עדכניות, ולכן נוהל מיושן אינו מכסה נוהל בתוקף.

בתוצאות מוטבע קישור קשיח לקטע המקורי: הנציג פותח את המקור ומשווה את הניסוח, ולא סומך על המודל בעיניים עצומות.

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

מה יצא

• זמן חיפוש תשובה: 4–6 דקות → 25–40 שניות.
• שיעור תשובות עם עיגון במקור: 40% → 92%.
• פניות לקו השני: מינוס 35%.
• שאלות שנסגרו בקו הראשון בלי הסלמה: 78%.

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

במה שונה RAG מכיוונון עדין של המודל

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

מכאן ההבדל בעדכון הידע. במערך חיפוש מספיק להעלות מסמכים שהשתנו ולחשב מחדש אינדקסים — תיקון בנוהל או בהוראה מופיע בתשובות עוד באותו יום, בלי לעצור את השירות.

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

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

RAG או כיוונון עדין נבחרים גם לפי דרישות ליכולת אימות: במערך חיפוש רואים מאיזה קטע הורכבה התשובה, ואת הקישור למקור אפשר לבדוק בלי לפרק משקולות.

בפועל לרוב עובד שילוב: את המודל מכווננים עדין על פורמט ותחום תוכן, ואת הידע מחזיקים ב-ChromaDB ומעדכנים אינדוקס בכל תיקון מסמכים. אז שיעור התשובות עם קישור למקור עולה, וזמן עדכון הידע נמדד בשעות, לא במחזורי אימון מחדש.

ספקות טכניים: איכות, נתונים, גישה

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

כיצד מתעדכן מאגר הידע?

האינדוקס מוסיף: מסמך השתנה — רק הוא מחושב מחדש. מסמך שנמחק יוצא מהתוצאות יחד עם הקטעים שלו, ולכן הוראות מבוטלות לא צפות בתשובות.

האם הרשאות הגישה נאכפות?

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

מה אם יהיה צורך להחליף מאגר?

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

האם אפשר לבצע rollback לעדכון כושל?

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

נדון במשימה שלכם: ממה נתחיל את העבודה

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

• קורפוס מסמכים בפורמטים המקוריים — ייצוא לתקופה אופיינית, ולא תיקייה "לצורך המחשה" אחת: על חמישה קבצים אי אפשר לבדוק כיצד החיפוש מתנהג עם כפילויות וסתירות בין גרסאות של נוהל.
• תדירות עדכון ובעל הנתונים — עדכון פעם ברבעון באופן ידני או זרם קבוע ממערכת פנימית: מכך תלוי אם אנו עושים טעינה חד-פעמית או אינדוקס מחדש קבוע עם מחיקת מיושן.
• הרשאות גישה: מי רשאי לראות אילו מדורים והאם יש לסנן תוצאות לפי מחלקות או תפקידים. זה משפיע על סכימת האחסון ועל המקום המדויק שבו מיושם הסינון.
• 15–30 שאלות אמיתיות של משתמשים עם תשובות צפויות וציון מקור — על מדגם זה אנו מקבעים את קריטריון הקבלה ומודדים איכות, ולא מתווכחים עליה בהדגמה.
• נקודות השתלבות ומגבלות המערכת: לאן החיפוש מחזיר תשובה (צ'אט, פורטל פנימי, עמדת נציג), האם מותר להוציא נתונים לשירותים חיצוניים או שהכול חייב לעבוד במערכת סגורה.
• קשיים נוכחיים במספרים: כמה זמן לוקח חיפוש תשובה כיום, איזה שיעור פניות נשאר בלי תשובה, אילו טעויות חוזרות ביותר.
• קריטריון מוכנות: שיעור השאלות שעבורן נמצאה תשובה ואומתה בקישור למסמך, וזמן התשובה המותר.

תארו את המשימה בצורה חופשית וצרפו את מה שיש בהישג יד — את השאר נדייק בשיחה. נחזור עם הערכה ותוכנית עבודה: שלבים, תוכן של כל שלב, תחום האחריות של הצוות שלכם ונקודות שבהן אפשר לעצור ולעדכן את ההיקף בלי לאבד את מה שכבר נעשה.