Semantic Chunking — איך מחלקים מסמכים נכון לפני Embedding

מאת צוות מדיה דיל · 09.08.2026 · AI · 9 דק׳

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

מסמך מדיניות החזרות מכיל את המשפט: "מוצרים אלקטרוניים ניתנים להחזרה תוך 14 יום, למעט אם נפתחה האריזה." חלוקה נאיבית לפי 500 תווים קבועים חותכת בדיוק בין שני חלקי המשפט - "מוצרים אלקטרוניים ניתנים להחזרה תוך 14 יום" נכנס לקטע אחד, ו"למעט אם נפתחה האריזה" נכנס לקטע הבא. כשמישהו שואל "האם אפשר להחזיר טלוויזיה שפתחתי?", מנוע החיפוש עשוי לשלוף רק את הקטע הראשון - וה-AI עונה בביטחון מלא "כן, אפשר להחזיר תוך 14 יום", בעוד שהתשובה הנכונה היא בדיוק ההפך. זו לא בעיה במודל השפה, לא בחיפוש, ולא ב-Embedding - זו בעיה בשלב שקורה הרבה לפני כל אלה: Chunking, חלוקת המסמך לקטעים, שנעשית בצורה שלא מכבדת את גבולות המשמעות בטקסט.

ההשפעה על איכות ה-Embedding עצמו

יש עוד ממד שלרוב לא מקבל מספיק תשומת לב: איכות ה-Chunking לא משפיעה רק על מה שקורה בשלב החיפוש, אלא כבר על איכות ה-Embedding עצמו בזמן היצירה. Embedding הוא בעצם דחיסה של המשמעות הטקסטואלית לוקטור בגודל קבוע - וככל שהטקסט שנדחס "מבולגן" יותר (מכיל התחלה של רעיון אחד וסוף של רעיון שלא קשור), כך הוקטור שנוצר הוא ממוצע מטושטש יותר, שפחות מדויק בייצוג כל אחד מהרעיונות בנפרד. Chunk שמכיל יחידת משמעות אחת ברורה מייצר Embedding "חד" יותר, שקל יותר להתאים בדיוק לשאילתות רלוונטיות - וזו הסיבה שהשקעה ב-Chunking נכון היא לא רק "נוחות" לוגית אלא משפרת ישירות את איכות ה-Embeddings עצמם שנשמרים ב-Vector Database.

למה חלוקה לפי מספר תווים קבוע היא ברירת מחדל מסוכנת

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

איך בפועל מזהים "ירידה בדמיון" בין משפטים

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

גישות מבוססות משמעות

חלוקה לפי מבנה מסמך (Structure-aware)

הגישה הפשוטה יחסית והאפקטיבית ביותר כשהמסמכים כתובים בפורמט מובנה (Markdown, HTML, מסמכי Word עם כותרות): מחלקים לפי כותרות, סעיפים ופסקאות טבעיים, לא לפי ספירת תווים שרירותית. כל Chunk מכיל יחידה שלמה מבחינה לוגית - סעיף שלם, פסקה שלמה - גם אם אורכה משתנה בין קטע לקטע.

חלוקה לפי דמיון סמנטי (Embedding-based splitting)

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

חלוקה מונחית LLM

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

בדיקה אמפירית של אסטרטגיית Chunking - איך עושים זאת בפועל

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

גודל Chunk - איזון בין הקשר לדיוק

גודל ה-Chunk הוא Trade-off ולא "ככל שיותר גדול יותר טוב":

• Chunks קטנים מדי - כל קטע נושא כמות מידע מוגבלת ולפעמים חסר הקשר קריטי (בדיוק כמו הדוגמה של תנאי החריגה שנחתך). מצד שני, הם מדויקים יותר בחיפוש - קל יותר להתאים שאילתה ממוקדת לקטע קצר וממוקד.
• Chunks גדולים מדי - שומרים הקשר טוב יותר, אבל "מדללים" את האות הסמנטי - Embedding של קטע ארוך שעוסק בכמה נושאים שונים הוא ממוצע מטושטש של כולם, ופחות מדויק בהתאמה לשאלה ממוקדת. הם גם "מבזבזים" יותר טוקנים בפרומפט הסופי לכל קטע שנבחר.

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

מטא-דאטה על כל Chunk - לא רק הטקסט עצמו

Chunk טוב הוא לא רק מחרוזת טקסט - הוא צריך לשאת איתו מטא-דאטה שמאפשרת סינון וקונטקסט נוסף בזמן החיפוש. לפחות שלושה שדות מטא-דאטה שווים הכללה כמעט תמיד: מקור המסמך (איזה קובץ, איזה סעיף בדיוק, כדי לאפשר ציטוט מדויק במקור), תאריך עדכון אחרון (לתמיכה בסינון לפי עדכניות, כפי שנדון גם ב-RAG 2.0), והיררכיה (איזו כותרת-על שייכת ל-Chunk הזה - למשל "מדיניות החזרות > אלקטרוניקה > תנאים מיוחדים"). שדה ההיררכיה שימושי במיוחד כי הוא מאפשר "לצרף" בחזרה הקשר רחב יותר גם כשה-Chunk עצמו קצר וממוקד - אפשר להזריק לפרומפט את שם הכותרת-העל יחד עם תוכן ה-Chunk, מה שמשחזר חלק מההקשר שאבד בחלוקה בלי צורך ב-Chunk גדול יותר.

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

Overlap - למה חופפים בין קטעים

גם עם חלוקה סמנטית טובה, שווה להשאיר חפיפה (Overlap) קטנה בין קטעים סמוכים - למשל, סוף הקטע הקודם חוזר גם בתחילת הקטע הבא. זה מגן מפני מקרים שבהם משפט מפתח נמצא בדיוק על גבול, ומבטיח שהוא לא "יאבד" לגמרי גם אם החלוקה לא הייתה מושלמת. Overlap טיפוסי הוא בסביבות 10-20% מגודל ה-Chunk, אבל גם כאן - ערך גבוה מדי פשוט מכפיל עלות אחסון ועיבוד בלי תועלת מקבילה.

דוגמה להשוואה בין חלוקה נאיבית לסמנטית

// חלוקה נאיבית (500 תווים קבועים) - חותכת באמצע תנאי
Chunk A: "...מוצרים אלקטרוניים ניתנים להחזרה תוך 14 יום"
Chunk B: "למעט אם נפתחה האריזה. יוצא מהכלל: מוצרי..."

// חלוקה מבוססת מבנה - שומרת את הסעיף השלם יחד
Chunk A: "מוצרים אלקטרוניים ניתנים להחזרה תוך 14 יום,
          למעט אם נפתחה האריזה."
Chunk B: "יוצא מהכלל: מוצרי היגיינה אישית אינם ניתנים
          להחזרה בכל מקרה, גם באריזה סגורה."

Chunking עבור קוד ומסמכים טכניים - מקרה מיוחד

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

שילוב עם שאר הצינור

Semantic Chunking הוא שלב הכנה בסיסי - הוא קורה לפני שכל שאר צינור ה-RAG בכלל מתחיל לפעול, ולכן איכותו קובעת "תקרת זכוכית" לכל השאר: Hybrid Search טוב לא יכול למצוא מידע שנחתך בין שני קטעים, ו-Reranking מדויק לא יכול לדרג קטע גבוה אם הוא חסר את המידע הקריטי. במסמכים לא מובנים (סריקות, תמונות, טבלאות מורכבות), שלב ה-Chunking שזור לרוב עם עיבוד קדם-נתונים רחב יותר, כמפורט בהנדסת נתונים לא מובנים ובDocument Intelligence.

שאלות נפוצות

מה גודל Chunk מומלץ להתחיל ממנו?

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

האם Semantic Chunking תמיד עדיף על חלוקה קבועה?

כמעט תמיד ברמת האיכות, אבל הוא יקר יותר לחישוב (במיוחד הגרסה מונחית ה-LLM). לתוכן פשוט וחסר מבנה מורכב, ההבדל בפועל עשוי להיות קטן.

מה קורה כשמסמך מתעדכן - צריך לחלק הכל מחדש?

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

האם טבלאות דורשות טיפול מיוחד ב-Chunking?

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

האם Overlap גדול יותר תמיד משפר תוצאות?

לא באופן ליניארי - מעבר לנקודה מסוימת, Overlap גדול רק מכפיל עלות אחסון ועיבוד בלי שיפור משמעותי בדיוק. 10-20% הוא טווח סביר להתחלה.

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

תגיות: Semantic Chunking · Chunking · Embeddings · RAG · Document Processing · Vector Database

← חזרה לבלוג · צור קשר