אינטגרציה של LlamaIndex ל-RAG ולאינדוקס נתונים

LlamaIndex: מדוע החיפוש במאגר הידע מחזיר זבל

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

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

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

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

מה נותן אינדוקס נתונים מנוהל בפועל

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

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

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

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

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

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

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

מצבי עבודה של LlamaIndex: השוואת גישות

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

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

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

שלבי ההטמעה: מביקורת הנתונים ועד למסירה

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

1. ביקורת מקורות הנתונים. אוספים את מה שיש: נהלים, מאגר ידע, טבלאות, סריקות התכתבויות. מתעדים פורמטים, בעלים, תדירות שינויים והרשאות גישה — מזה תלוי מה אפשר לאנדקס ומה חייב להישאר חסום.
2. סכימת האינדקס. ב-LlamaIndex מתארים לאילו מקטעים מתפצל המסמך ואילו מטא-נתונים מוצמדים להם: פרק, תאריך, תפקיד המשתמש. מקטע גדול מטשטש את התשובה, קטן מאבד הקשר — את הגודל מכיילים במדידות, ולא לפי העין.
3. כיול החיפוש. בונים החזרה היברידית: חיפוש לפי משמעות ועוד חיפוש לפי ניסוחים מדויקים ומק"טים, עם דירוג מחדש. מכיילים את מספר המקטעים שנשלחים למודל: יותר — תשובה מלאה יותר, אבל השהיה גבוהה יותר.
4. בדיקה על שאלות ייחוס. לוקחים 50–100 שאלות אמיתיות של עובדים עם תשובות ידועות ומודדים אם המקור הנדרש נכנס לטופ של ההחזרה. פערים מפרקים: בדרך כלל מדובר בטעויות פיצול או במילים נרדפות שלא נלקחו בחשבון.
5. סירוב והרשאות. בודקים שהמערכת עונה «אין נתונים במקורות», ולא משלימה מדעתה, ושהעובד רואה רק מסמכים המותרים לו. התרחישים האלה שוברים אמון מהר מכול.
6. מסירת הפתרון. מוסרים קונפיגורציות, סכימת אינדקס, נוהל אינדוקס מחדש והנחיה לבעל מאגר הידע, ומראים כיצד למדוד איכות בעצמכם לאחר תיקונים.

תוצרי האינטגרציה של LlamaIndex: מה נשאר לכם

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

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

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

קייס: צמצמנו פי שלושה את שיעור התשובות הלא-רלוונטיות

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

מה שינינו באינדוקס

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

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

כיצד מדדנו את התוצאה

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

שיעור התשובות עם מקור לא-רלוונטי ירד מ-38% ל-12%, הפגיעה בטופ-3 של ההחזרה עלתה מ-54% ל-89%, ושיעור הפניות שנסגרו ללא הסלמה לקו השני — מ-61% ל-84%. הכנת התשובה התקצרה משש דקות לשתיים.

במה שונה חיפוש היברידי מחיפוש וקטורי?

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

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

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

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

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

ספקות טכניים לפני אינטגרציה של LlamaIndex

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

מה תהיה העומס על מאגר הנתונים?

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

כיצד מתעדכן האינדקס?

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

כיצד מובטחת פרטיות הנתונים?

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

כמה מאמץ דורש התחזוקה?

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

ספרו לנו על המשימה — נחזור עם אומדן ותוכנית

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

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

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