RAG Agent ו-Chunks: איך ai agent בוחר חתיכות ידע חכמות

כששואלים שאלה – והמודל לא באמת "זוכר" כלום

לפעמים אני יושב מול מסך, כותב שאלה ל-ai agent חדש שבדקתי, ומרגיש כאילו אני מדבר עם מתמחה חרוץ, שקרא המון – אבל לא ממש זוכר איפה ראה מה. הוא זוכר "בערך". הוא ממציא קצת. לפעמים הוא חכם, לפעמים הוא פשוט בטוח בעצמו. וזה הרגע שבו retrieval augmented generation agent, או בקיצור RAG agent, נכנס לסיפור.

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

נשמע קטנוני? למה שזה ישנה אם החוזה מחולק לפסקאות של 200 מילים או 800? מתברר שזה משנה. מאוד. זה ההבדל בין ai agent שמרגיש כמו עוזר אישי רציני, לבין אחד שמחזיר תשובות כלליות, או גרוע מזה – מפספס סעיף קריטי.

מה זה בעצם RAG Agent, ומה לעזאזל קשור ל-Chunks?

נתחיל מהבסיס, בלי יותר מדי מונחים מפוצצים. RAG agent הוא סוג של ai agent שלא מסתמך רק על מה שהמודל "הגדול" שלו למד בזמן האימון, אלא גם על מאגר מסמכים חיצוני. זה יכול להיות knowledge base פנימי של חברה, תיקייה ב-SharePoint, או אפילו אוסף PDFים ששכבתם עליהם כמה שנים.

התהליך פחות או יותר כזה (פשטני, אבל עובד):

השלבים בדרך לתשובה "חכמה"

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

1. השאלה עוברת ל"רכיב החיפוש" של ה-RAG agent, בדרך כלל מנוע שעובד עם embeddings.
2. המנוע הזה מנסה למצוא במסמכים חלקים רלוונטיים – לא מסמכים שלמים, אלא חתיכות מהם.
3. החתיכות האלו מוזרקות למודל השפה, שמנסה לכתוב תשובה שמבוססת על הטקסט שקיבל.
4. המשתמש רואה תשובה שנראית חכמה, ומקווה שהיא גם נכונה.

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

Chunking: האמנות (והמדע) של לחתוך מסמך בלי להרוס אותו

Chunking הוא השלב שבו אתם אומרים ל-ai agent שלכם: "עד כאן פסקה אחת. מכאן – חתיכה חדשה". אבל מה זה "עד כאן"? משפט? פסקה? כותרת? סעיף בחוזה? 300 תווים? 1,000 טוקנים?

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

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

Chunk לפי אורך? לפי מבנה? לפי שניהם?

בעולם האמיתי, רוב הצוותים מתחילים בשאלה: "מה גודל ה-chunk המומלץ ל-RAG?" זאת שאלה שכולם שואלים, ומעטים אוהבים את התשובה: "זה תלוי".

אבל בואו ננסה לעשות קצת סדר:

• Chunking לפי אורך קבוע – הכי פשוט למימוש, הכי קל להסבר. חותכים כל X תווים / טוקנים. נגמר.
• Chunking מבוסס מבנה – חותכים לפי כותרות, סעיפים, bullets, פסקאות.
• Chunking היברידי – קודם לפי מבנה, ואז מאחדים או מפצלים לפי אורך מינימלי/מקסימלי.

בפועל, ai agent רציני, במיוחד כזה שעובד בסביבה עסקית או משפטית בישראל, כמעט תמיד יסתיים במשהו היברידי. כי מסמכים אמיתיים – בניגוד לדוגמאות בבלוגים – לא בנויים יפה. אף אחד לא סיפר למחלקת הכספים שלכם על "best practices ל-chunking".

איך גודל ה-Chunk משפיע על איכות התשובה?

כאן נכנסת השאלה הקריטית: למה בכלל להשקיע זמן וכאב ראש בבחירת גודל chunk, overlap, לוגיקה של חיתוך ועוד?

דיוק החיפוש לעומת עומק ההקשר

ניקח שני תרחישים קלאסיים:

1. Chunks קטנים מדי

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

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

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

2. Chunks גדולים מדי

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

כשכל chunk מכיל עמוד שלם, או אפילו כמה, כמה בעיות מופיעות:

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

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

Overlap: למה לפעמים צריך לחזור על עצמך בכוונה

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

היתרונות של חפיפה בין chunks

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

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

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

אבל גם פה אפשר להגזים

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

במילים פשוטות: overlap הוא כמו מלח. בלי – התוצאה תצא תפל. יותר מדי – תהרוס את המנה.

לא רק טקסט: Chunking שמתאים לתחום ולתוכן

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

חוזים ומשפטים

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

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

ai agent משפטי שלא מבין את המבנה הזה – ייתן תשובות שחסרות "קילומטרז'" משפטי. זה לא שהוא "טיפש", הוא רק לא רואה את התמונה המלאה.

קוד ומערכות טכניות

כשמדובר בקוד, chunking צריך לחשוב כמו מתכנת:

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

המשמעות היא שלפעמים צריך build pipeline מותאם – שמבין את הקוד, לא רק את התווים. כלומר, ליצור code-aware chunking, ולא "לקחת כל 500 תווים ולחתוך".

תיעוד מוצר, מדריכים, help center

כאן מבנה המסמך בד"כ יותר ידידותי: כותרות, תתי-כותרות, bullet points. RAG agent שנבנה מעל help center יכול לנצל את זה:

• כל מאמר הופך ליחידת על.
• בתוך המאמר – כותרת H2/H3 יכולה להיות גבול טבעי ל-chunk.
• אם עדיין ארוך מדי – לחתוך לפי פסקאות, תוך שמירה על מינימום ומקסימום אורך.

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

ישראל, עברית, ובלגן של מסמכים אמיתיים

יש עוד שכבה שהרבה פתרונות RAG בינלאומיים לא לגמרי מתמודדים איתה: עברית, ויותר מזה – עברית עסקית-ישראלית.

מסמכים בעברית נוטים להיות:

• פחות אחידים במבנה.
• מלאים בראשי תיבות פנימיים (שלא תמיד יש להם הסבר).
• משלבים עברית-אנגלית-מספרים באותה שורה.

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

דוגמה קטנה מהשטח

בפרויקט אחד שנחשפתי אליו, צוות פיתוח ישראלי בנה RAG agent עבור מחלקת שירות. הם התחילו ב-chunking לפי 1,000 תווים, בלי מבנה, בלי חוכמות. המערכת עבדה – אבל התשובות לא תמיד היו מדויקות.

אחרי כמה סבבים של fine-tuning, הם עברו למודל אחר:

• קודם לחתוך לפי כותרות במאמרי ה-help center.
• אחר כך לחתוך פסקאות ארוכות במיוחד – אבל להשאיר לפחות שתי פסקאות בכל chunk.
• להוסיף overlap של פסקה אחת בין chunks סמוכים, כדי לשמור על רצף.

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

שאלות ותשובות: מה שכולם שואלים על Chunking ו-RAG

איך לבחור גודל chunk התחלתי ל-RAG agent?

המלצה פרקטית, לא מוחלטת: להתחיל בטווח של 300–800 טוקנים (בערך חצי עמוד עד עמוד וחצי טקסט), עם overlap של 10–20%. אחר כך למדוד: אחוזי דיוק, שביעות רצון משתמשים, כמות "המצאות". ולא לפחד לכוונן.

האם כדאי שכל סוג תוכן יקבל אסטרטגיית chunking נפרדת?

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

מה קורה אם לא עושים chunking בכלל?

אם תנסו להאכיל את מנוע ה-retrieval במסמכים שלמים, לרוב:

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

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

כמה overlap זה "נורמלי"?

אין מספר קדוש, אבל ברוב המערכות תראו משהו בין 10% ל-30% מהאורך. אם ה-chunk שלכם 500 טוקנים, overlap של 50–150 טוקנים הוא אזור הגיוני להתחלה.

איך יודעים אם בעיה היא ב-chunking או במודל עצמו?

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

טבלה מסכמת: מה משפיע על מה?

פרמטר	מה זה בפועל?	השפעה חיובית אפשרית	סיכון כשמגזימים	הערות לגבי ai agent
גודל chunk	אורך החתיכה (טוקנים/תווים/פסקאות)	יותר הקשר, פחות "המצאות"	פחות דיוק בחיפוש, בזבוז טוקנים	משפיע ישירות על איכות תשובות ה-RAG agent
Overlap	חפיפה בין chunk אחד לבא אחריו	שימור המשכיות, פחות חיתוך באמצע רעיון	כפילויות, עומס על האינדקס	קריטי במסמכים משפטיים וטכניים מורכבים
מבנה-מבוסס (structure-aware)	חיתוך לפי כותרות, סעיפים, פונקציות	לכידת יחידות משמעותיות של ידע	מורכבות פיתוח, תלות באיכות המסמך	גורם ל-ai agent להרגיש "מבין תחום"
סוג מסמך	חוזה, קוד, תיעוד, פרוטוקול וכו'	אפשר להתאים אסטרטגיה ל-domain	יותר קונפיגורציה, צריך תחזוקה	מפתח אם בונים ai agent לארגון גדול
שפה ותווים	עברית, אנגלית, שילובים, ראשי תיבות	פחות טעויות parsing, פחות שיבושים	דורש בדיקות אמיתיות על קורפוס מקומי	בישראל – חובה להתייחס לעברית ברצינות
כמות מסמכים	גודל ה-knowledge base	יותר ידע נגיש ל-RAG agent	אם chunking גרוע – קשה מאוד לשלוף נכון	ככל שהמאגר גדל, איכות chunking קריטית יותר

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

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

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

כמה תובנות פרקטיות, בלי להפוך את זה ל"צ'ק ליסט"

להתחיל פשוט – אבל למדוד

אל תבזבזו חודשים על תכנון chunking מושלם לפני שהפעלתם בכלל את ה-RAG agent. אפשר להתחיל עם:

• אורך בינוני (500–700 טוקנים).
• overlap מתון.
• חיתוך בסיסי לפי פסקאות/כותרות כשיש.

אחר כך – למדוד: כמה פעמים התשובות לא מדויקות? באיזה סוגי מסמכים? באיזה תחומים? שם תבינו איפה לשפר את ה-chunking.

לדבר עם מי שמשתמשים במערכת

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

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

יתכן מאוד שבמערכת אחת תצטרכו:

• אסטרטגיית chunking אחת לחוזים.
• אחרת לתיעוד פנימי.
• שלישית לקוד.

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

מבט קדימה: כש-ai agent יחליט לבד איך לחתוך

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

RAG agent עתידי אולי יפעיל ai agent נוסף מאחורי הקלעים, שתפקידו היחיד יהיה להיות "עורך תוכן": לקחת מסמך, לפרק אותו ליחידות הגיוניות, לשים תגיות, ולסמן הקשרים.

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

סיכום: היכן שהטקסט נגמר, וההחלטות מתחילות

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

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

אם אתם שוקלים להקים או לשפר RAG agent בארגון שלכם, אם אתם מתלבטים לגבי גודל ה-chunk, overlap, או איך להתמודד עם הבלגן של מסמכים בעברית, אפשר וצריך לדבר על זה ברצינות. נשמח לסייע בייעוץ ראשוני ללא עלות – פשוט כדי למנוע את אותן טעויות שחוזרות בכל פרויקט של ai agent, ולחסוך לכם כמה סבבי "למה זה לא עובד כמו שחשבנו".