פיצול מסמכים ל-RAG (רקורסיבי, סמנטי, ברמת משפט)

מדוע אסטרטגיות chunking קובעות את איכות התשובות

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

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

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

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

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

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

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

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

אסטרטגיות chunking: השוואת גישות

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

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

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

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

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

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

ארטיפקטים: קונפיגורציית חיתוך, סכמות ותקנונים

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

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

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

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

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

מה היה בבסיס המקורי

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

העוזר החזיר שורת «סה"כ» בלי כותרת, או סעיף ברמה שלישית בלי הכותרת האב: פורמלית דומה, מבחינת המשמעות — החמצה. על סט בקרה של 400 שאלות, דיוק הפגיעה במקור עמד על כ-64%.

מה שינו ומה יצא

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

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

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

מה לעשות אם הבסיס כבר מחותך בשיטה הישנה?

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

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

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

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

ספקות טכניים נפוצים בנוגע לחיתוך מסמכים

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

מה קורה עם טבלאות?

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

כיצד בודקים את איכות החיתוך?

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

האם נצטרך לבנות מחדש את הבסיס בעת החלפת סכמה?

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

נדון במשימה ונחזור עם תוכנית עבודה

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

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

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

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

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