התמודדות עם בעיית אובדן ההקשר (Lost Context) במערכות RAG: שתי טכניקות מתקדמות

הקדמה: האתגר של סוכני RAG

אם אי פעם בניתם סוכן המבוסס על Retrieval Augmented Generation (RAG), ודאי נתקלתם במצבים בהם הסוכן אינו מסוגל לענות על שאלות במדויק או שהוא "ממציא" תשובה (הזיות). תופעות אלו נגרמות לרוב בשל "בעיית אובדן ההקשר" (Lost Context Problem). מאמר זה יסביר מהי בעיה זו ויציג שתי טכניקות חדשניות שניתן להשתמש בהן כדי להתגבר עליה, לשפר את דיוק השליפה ולהפחית הזיות.

מהי "בעיית אובדן ההקשר"?

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

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

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

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

סקירה קצרה: RAG וקיטוע (Chunking)

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

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

טכניקה 1: עיבוד מאוחר של מקטעים (Late Chunking)

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

כיצד זה עובד?

בגישת RAG סטנדרטית, מבצעים קיטוע *לפני* יצירת ההטמעות. בגישת ה-Late Chunking, התהליך הפוך: מבצעים הטמעה *לפני* הקיטוע. הדבר מתאפשר הודות למודלי הטמעה עם חלונות הקשר ארוכים (בדומה למודלי שפה גדולים (LLMs) מודרניים).

1. טוענים את המסמך כולו (או חלק גדול ככל שניתן בהתאם למגבלת חלון ההקשר של מודל ההטמעה) למודל ההטמעה.
2. כל טוקן במסמך מקבל וקטור הטמעה, כאשר כל ההטמעות נוצרות בו-זמנית ובתוך ההקשר של המסמך כולו.
3. לאחר מכן, מיישמים אסטרטגיית קיטוע (למשל, חלוקה למשפטים, פסקאות, מקטעים באורך קבוע וכו').
4. במקום לשלוח את המקטעים שנוצרו למודל ההטמעה, מזהים אילו וקטורים (שנוצרו בשלב 2) משויכים לכל מקטע טקסט.
5. משתמשים בטכניקת "איגום" (Pooling) או "צבירה" (Aggregating) כדי למצע את הווקטורים הללו וליצור וקטור יחיד המייצג את המקטע. וקטור זה מאוחסן במאגר הווקטורים.

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

יתרונות ושיקולי יישום

היתרון המרכזי הוא ייצוג מדויק יותר של הטקסט, השומר על ההקשר. טכניקה זו תלויה בזמינותם של מודלי הטמעה עם חלון הקשר ארוך. לדוגמה, מודלים כמו אלו של Mistral או Quinn תומכים בעשרות אלפי טוקנים. מודל Gina's Embedding V3 תומך בכ-8,000 טוקנים. ככל שהמסמך ארוך יותר, כך השיפור היחסי בתוצאות השליפה צפוי להיות דרמטי יותר, מכיוון שיש יותר הקשר שעלול ללכת לאיבוד בשיטות סטנדרטיות.

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

טכניקה 2: אחזור מודע הקשר עם הטמנת הקשר (Contextual Retrieval with Context Caching)

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

כיצד זה עובד?

1. מחלקים את המסמך למקטעים.
2. במקום לשלוח ישירות למודל הטמעה, שולחים כל מקטע ל-LLM *יחד עם המסמך המקורי כולו*.
3. מבקשים מה-LLM לנתח את המקטע בהקשר של המסמך המלא ולספק תיאור קצר (Blurb) המסביר כיצד המקטע משתלב במסמך.
4. מוסיפים את התיאור הקצר הזה למקטע המקורי.
5. שולחים את הטקסט המשולב (תיאור + מקטע) למודל הטמעה ליצירת וקטורים.

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

הטמנת הקשר (Context Caching)

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

יתרונות ואתגרים

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

• זמן עיבוד (Ingestion): התהליך עלול להיות איטי מאוד. בדוגמה מהמקור, עיבוד מסמך PDF אחד בן 180 עמודים ארך כ-27 דקות.
• עלות: גם עם הטמנה, קריאות מרובות ל-LLM (אחת לכל מקטע) יכולות להצטבר לעלות גבוהה. באותה דוגמה, העלות הייתה כ-$1.30 למסמך.
• מגבלות קצב (Rate Limits): נפח קריאות גבוה ל-LLM עלול להיתקל במגבלות API. הדבר דורש טיפול בקריאות באצוות (Batches) והמתנות בין אצווה לאצווה.
• סילומיות (Scalability): גישה זו פחות מתאימה לעיבוד מיליוני מסמכים.

למרות האתגרים, מחקר של Anthropic הראה שהטכניקה הפחיתה את שיעור הכשל בשליפת 20 המקטעים המובילים ב-35%, ובשילוב עם מודל דירוג מחדש (reranking), ההפחתה הגיעה ל-67%.

השוואה בין הטכניקות

Late Chunking:

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

Contextual Retrieval with Context Caching:

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

סיכום

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

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