אנשים ממשיכים לכתוב מאסרי דוד ל-RAG. בטח כבר ראיתם את הכותרות. חלונות הקשר ארוכים הרגו אותו. סוכנים החליפו אותו. כל התבנית הפכה למיושנת. האמת צרה והרבה יותר שימושית. RAG לא מת. מה שבאמת קרס היה האשליה הנוחה שאפשר לקחת ערימה של מסמכים, לחלק אותם למקטעים (chunks), להזין אותם למסד נתונים וקטורי, ופתאום להחזיק ב-AI אמין ואמיתי.
לפני כמה שנים, הטיעון היה מפתה בפשטותו. הטמיעו (Embed) את בסיס הידע שלכם. חברו אותו ל-LLM. שאלו שאלה, וצפו במודל עונה תוך שימוש בנתונים שנשלפו בלבד. עבור דמואים מבוקרים ובוטים קטנים של שאלות ותשובות (FAQ), זה באמת עבד. מדריך עזרה בן עשרים עמודים. ויקי פנימית מסודרת. הבוט היה מצטט פחות או יותר את הפסקה הנכונה, וההנהלה הייתה מאשרת את הפיילוט. אבל פיילוטים הם לא סביבת ייצור (Production). אבות-טיפוס אינם מכילים את הצלקות של פעילות עסקית אמיתית.
נתוני ייצור הם מבולגנים. הם מכילים את אותה הערת פתרון תקלה שמועתקת בעשרות קבצים, שלכל אחד מהם חותמות זמן מעט שונות ותגיות סטטוס סותרות. הם מכילים טבלאות מורכבות שמתפרסות על פני דפים, מה שיוצר חוסר היגיון כאשר מפצל (splitter) חותך אותן באמצע. הם שומרים על סתירות ללא התנצלות. מדריך המדיניות של 2023 אומר דבר אחד. התיקון ממרץ 2024 אומר אחרת. ה-PDF הישן מעולם לא תוכנן לארכיון. התבנית הנאיבית של חלוקה למקטעים (chunk), אחסון ושליפה מתייחסת לכל פסקה כאל אי בודד. אין לה שום הבנה של היררכיה, היסטוריית גרסאות או פתרון קונפליקטים. המודל מהזיה (hallucinates) לא בגלל שה-LLM שבור, אלא בגלל שההקשר שהוא קיבל היה מקוטע, נטוש או פשוט שגוי.
חלק מהצופים טוענים שחלונות הקשר של מיליון טוקנים הופכים את השליפה ללא רלוונטית. הטיעון שלהם פשוט: פשוט תזרקו את כל הקורפוס לתוך ה-prompt ותתנו למודל לקרוא הכל. זה נשמע אלגנטי. זה גם אופטימי בצורה מסוערת. מודל עשוי להיות מסוגל טכנית לעכל נפח טקסט השווה לרומן קצר, אך איתור סעיף ספציפי אחד באמצע המרחב הזה נותר יכולת שונה לחלוטין. מחטים נשארות אבודות בערימות חציר. חלונות הקשר ארוכים מרחיבים את הקנבס הזמין, אך הם אינם פותרים את העבודה הקשה של החלטה מה ראוי לקבל מקום על הקנבס הזה. הבעיה מעולם לא הייתה פשוט שליפה. היא הייתה, ותמיד הייתה, הרכבת הקשר (context assembly).
משליפת מידע נאיבית להנדסת הקשר
בשנת 2026, התחום מבשיל. אנחנו עוברים מהשלב שבו RAG נחשב כצינור עיבוד (pipeline) ליניארי בודד לעבר ארכיטקטורה שמתייחסת להקשר כמוצר מהונדס בכוונה תחילה.
חיפוש היברידי על פני סמנטיקה טהורה. דמיון סמנטי הוא מצוין להבנת כוונה, אך הוא רשלן כשמדובר במזהים מדויקים. אם מהנדס מבצע שאילתה על קוד שגיאה ספציפי כמו ERR_CONNECTION_REFUSED או גרסת תוכנה כמו v3.2.1, חיפוש וקטורי טהור עלול לדלל את ההתאמה המדויקת בים של תוצאות דומות מבחינה מושגית אך לא רלוונטיות מבחינה מעשית. האבולוציה כאן היא ישירה. מערכות מודרניות משלבות שליפת וקטורים צפופה (dense vector retrieval) עם חיפוש מילות מפתח, תוך שימוש בשיטות כמו BM25 או אינדקסים הפוכים לצד embeddings. שמות מדויקים, קודי שגיאה, מחרוזות גרסה ומזהי מוצר נתפסים על ידי שכבת מילות המפתח, בעוד שהניואנס המושגי מטופל על ידי השכבה הוקטורית.
דירוג מחדש (reranking) לפני יצירה. שליפה נוטה באופן טבעי לכיוון של Recall (אחזור). אתם שולפים ארבעים או חמישים מקטעים כי אתם מפחדים לפספס את הפסקה המוזהבת היחידה. אך הזנת כל הרעש הזה למודל גדול מבזבזת טוקנים וקובעת את האות (signal) תחת ערימה של רעש. Reranking פותר זאת באמצעות מודל שני, בדרך כלל קטן יותר, שנותן ציון לכל מועמד על פי רלוונטיות לשאילתה הספציפית. חמשת הקטעים המובילים ממשיכים הלאה. השאר נזרקים. זה פועל כמסנן דיוק בין השליפה ליצירה, ומבטיח שמודל ההסקה היקר יקרא רק את מה שבאמת חשוב.
שליפה הקשרית ששומרת על משמעות. חלוקה למקטעים (chunking) היא אקט אלים. מפצל (splitter) יכול לנתק פסקה מכותרת הסעיף שלה, מכיתוב הטבלה שלה, מהצהרת הוויתור המשפטית שמקיפה אותה, או מהערת השוליים שמשנה את משמעותה. שליפה הקשרית (contextual retrieval) מפחיתה זאת על ידי העשרת השברים לפני שהם מגיעים למודל. אתם מוסיפים מטא-דאטה המציין מקור: קטע זה שייך לדוח האירועים של רבעון 3 לשנת 2024, סעיף השבתת מסד נתונים, חומרה קריטית. המודל רואה לא רק משפט צף, אלא פיסת מידע ממוקמת בהקשר. השבר מקבל מחדש את אחיזתו בהקשר.
ניתוב מודולרי לפי כוונה. לא כל שאלה שייכת למאגר וקטורי (vector store) מלא בתיעוד. משתמש ששואל איך לאפס סיסמה כנראה זקוק למאמר עזרה. משתמש ששואל מדוע ההכנסות ירדו בצפון-מזרח ברבעון האחרון זקוק לשאילתת SQL מול מחסן נתונים (data warehouse), ולא לפסקה דומה סמנטית על אסטרטגיית מכירות אזורית. מערכות בשלות מנתבות כעת שאילתות לפי כוונה (intent), ובוחרות בכלי המתאים. תיעוד עבור פרוצדורות. מסדי נתונים יחסיים עבור אנליטיקה מובנית. מאגרי לוגים (Log aggregators) עבור ניפוי שגיאות (trace debugging). ממשקי API עבור סטטוס חי. שכבת השליפה הופכת למנתב (dispatcher), ולא לתרבות חד-גונית.
לולאות חשיבה סוכנותיות (Agentic reasoning loops). לא ניתן לענות על שאלות מסוימות באמצעות שלב חיפוש בודד. הן דורשות ניסוח מחדש. שאילתה ראשונית מעורפלת עוברת הבהרה. טענות שנשלפו נבדקות מול מקור שני. אם התיעוד סותר את מפרט ה-API, המערכת מסמנת את הקונפליקט במקום להמציא פשרה. המודל מחליט מתי לחפש שוב, מתי לדייק את השאילתה שלו, ומתי הוא אסף מספיק ראיות כדי לענות. אין מדובר בשליפה בצעד אחד (one-shot retrieval). זוהי חשיבה מובנית המשתמשת בחיפוש כתת-תוכנית (subroutine).
GraphRAG לשאלות יחסיות. שאלות עסקיות מסוימות עוסקות בקשרים, לא במשפטים. איזה כשל ברכיב הצית אילו התראות המשך (downstream)? איזה ספק מספק לאיזו מפעל, ומהו המסלול החלופי? למי בארגון יש זכויות החלטה על שורת תקציב ספציפית זו? מקטעי טקסט שטוחים "משטחים" את מערכות היחסים הללו מכיוון שהם מעולם לא תוכננו לשמר טופולוגיה. גרפי ידע (Knowledge graphs) כן. כאשר השאלה נוגעת להשפעה, שושלת (lineage), תבניות או מבנה רשת, מעבר על גרף מספק הקשר ששום כמות של שליפת פסקאות לא יכולה לשכפל.
השאלות שבאמת חשובות
השיח סביב RAG חייב להשתנות. הפסיקו לשאול איך לבנות צינור (pipeline) RAG גנרי. התחילו לשאול איזו משימה ספציפית המודל חייב לפתור, אילו נתונים מדויקים הוא צריך כדי להיות מדויק, וכיצד אתם מוודאים שההקשר שנאסף מספיק. שאלות אלו דוחפות אתכם "למעלה בשרשרת" (upstream) אל איכות הנתונים, עיצוב סכימה (schema design), לולאות אימות ומקוריות המקור (source provenance). הן חושפות האם בסיס הידע שלכם בכלל מתאים לצריכה אוטומטית.
RAG הוא כבר לא תהליך ליניארי בודד שמתקינים פעם אחת ושוכחים. זוהי דיסציפלינה של הרכבת ההקשר הנכון כדי שמודל יוכל לחשוב בצורה יעילה. המשמעות היא להתייחס לשליפה כבעיית תכנון מערכת, ולא כייבוא של ספרייה (library import).
הכלים הופכים למדויקים יותר. החיפוש הוא היברידי. הניתוב הוא חכם. השליפה היא מדורגת, מועשרת ומאומתת. האשליות הפשוטות של 2022 היו חייבות לקרוס כדי שמשהו מועיל באמת יוכל לתפוס את מקומן. התפקיד שלכם כעת אינו רק לשלוף טקסט ממסד נתונים. התפקיד שלכם הוא לבנות מערכות שיודעות מה המודל צריך עוד לפני שהמודל מתחיל לחשוב.
אם אתם בונים בתחום הזה, קהילת הלמידה של GyaanSetu היא מקום להחלפת הערות מעשיות עם אנשים שפותרים את אותן בעיות: https://t.me/GyaanSetuAi