Parent Document Retriever ל-RAG: שיפור שלמות אחזור ההקשר ב-19%

Parent Document Retriever: היכן הולך לאיבוד הקונטקסט של התשובה

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

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

במסמכים ארוכים — תקנות, חוזים, הוראות — כך הולכים לאיבוד עד 19% מהמידע הדרוש, וזה כבר לא מקרה נדיר אלא תכונה מערכתית של הסכמה.

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

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

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

יותר קונטקסט רלוונטי בתשובה

הסכמה Parent Document Retriever מפרידה בין חיפוש להזנה: ההשוואה נעשית לפי קטעים קטנים, ולמודל עובר בלוק האב כולו — עם כותרת, טבלה והסתייגויות. חלק הקטעים הרלוונטיים בתוצאות עולה ב-15–19% בקורפוסים של תיעוד טכני.

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

השהיית התשובה נשארת באותו סדר גודל

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

נפח האחסון גדל רק בטקסט

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

היכן חילוץ היררכי לא מנצח

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

Retriever רגיל מול היררכיה: השוואת גישות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: שלמות חילוץ הקונטקסט עלתה ב-19%

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

עברנו לחילוץ דו-רמתי: החיפוש מתבצע לפי קטעים קטנים, ולקונטקסט של המודל מוצב מדור האב כולו — גישת Parent Document Retriever. הקורפוס הורכב מחדש בהיררכיה «סעיף → מדור → מסמך» עם מטא-נתונים על מהדורה ותחום תחולה: סינונים לפיהם חוסמים מהדורות שבוטלו, והן כבר לא מתערבבות בתוצאות.

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

מדדים לפני ואחרי

שלמות החילוץ עלתה מ-0.68 ל-0.81 — פלוס 19% ביחס לרמה הבסיסית על אותו מערך שאילתות. שיעור התשובות עם הפניה לסעיף שבוטל או לא קיים ירד כמעט פי שלושה.

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

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

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

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

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

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

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

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

שאלות נפוצות של מהנדסים: מה נשבר בפועל

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

בכמה יגדל נפח האחסון?

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

איך למדוד איכות אם אין סימון ייחוס?

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

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

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

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

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

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית.