חלונות הקשר גדולים לא פותרים את הבעיה: למה מערכות AI טועות בחישובי נתונים
ניסוי על 100 אלף שורות נתונים מדגים בעיה קריטית במערכות RAG: ככל שמגדילים את חלון ההקשר, התשובות נראות משכנעות יותר אך אינן בהכרח מדויקות יותר. הפתרון אינו עוד טוקנים, אלא ניתוב חכם בין שליפה סמנטית לבין חישוב דטרמיניסטי.
האשליה המסוכנת של יותר הקשר
אחת ההבטחות הגדולות של מודלי שפה בשנה האחרונה היא חלון הקשר רחב יותר. אם בעבר מערכת בינה מלאכותית נאלצה להתמודד עם כמה אלפי טוקנים, כיום ניתן להזין לה מאות אלפים ואף מיליונים. לכאורה, זה אמור לפתור את אחת הבעיות המוכרות של RAG, שליפה מוגברת יצירה: המודל פשוט יראה יותר מידע ולכן יענה טוב יותר.
רוצה להישאר מעודכן ב-AI?
הירשם לדיוור השבועי שלנו וקבל עדכונים, המלצות על כלים, חדשות ודוחות מיוחדים
אלא שבמערכות נתונים עסקיות, ובמיוחד בקבצי CSV, טבלאות טרנזקציות ודשבורדים אנליטיים, ההנחה הזו מתפרקת במהירות. כאשר משתמש שואל "מהו סך ההוצאה לפי קטגוריה", הוא לא מבקש למצוא שורה רלוונטית. הוא מבקש לבצע פעולה חישובית מלאה על כל הנתונים. RAG, מטבעו, אינו מנוע חישוב. הוא מנגנון שמאתר מקטעים שנראים רלוונטיים ומעביר אותם למודל שפה.
למה RAG נכשל בשאלות אנליטיות
במערכת RAG נאיבית, כל שורת נתונים הופכת לטקסט שטוח. במקום טבלה עם טיפוסים, שדות, סכומים וקשרים, המודל מקבל רצף מילים ומספרים. כשהוא מתבקש לחשב סכום כולל או ממוצע לפי קבוצה, הוא אינו מריץ SUM או GROUP BY. הוא מנסה להסיק תשובה מתוך דגימה חלקית של הטקסט שהוחזר לו.
כאן נוצר כשל שקט במיוחד. בחלון הקשר קטן, הטעות גלויה: אם המודל רואה חמש שורות בלבד ומחזיר סכום זעיר, קל להבין שמשהו חסר. אבל כאשר הוא מקבל אלפי שורות, התשובה מתחילה להיראות כמו דוח מקצועי. יש טבלאות, פירוט, ניסוח בטוח ומספרים מדויקים לכאורה. בפועל, גם אם המודל ראה 8% מהנתונים בלבד, הוא עשוי להציג תשובה כאילו סרק את כל המאגר.
זו אינה רק בעיית דיוק. זו בעיית אמון. מנהל מוצר, אנליסט או סמנכ"ל כספים עלולים לקבל החלטה על בסיס תשובה שנראית סמכותית אך מבוססת על מדגם לא מוצהר. בעולם עסקי, תשובה חלקית שמתחזה לתשובה מלאה מסוכנת יותר משגיאה גלויה.
הפתרון: ניתוב לפני שליפה
הגישה הנכונה אינה לשפר את מנוע השליפה בכל מחיר, אלא להחליט מראש איזה סוג שאלה נשאל. שאלות כמו "כמה", "מהו הסכום", "מה הממוצע", "איזו מדינה עם ההוצאה הנמוכה ביותר" או "מה אחוז העסקאות החשודות" חייבות לעבור למנוע חישוב דטרמיניסטי. שאלות כמו "מצא עסקאות של לקוח מסוים" או "הצג דוגמה מטקסס" יכולות להישאר במסלול RAG.
שכבת ניתוב כזו יכולה להיות פשוטה יחסית. היא מזהה פעלים אנליטיים, השוואות מספריות וכוונות חיפוש, ומפנה כל בקשה למסלול המתאים. בשאלות חישוביות, המערכת סורקת את כל הנתונים ומבצעת פעולה מוגדרת, למשל סכום, ספירה, ממוצע, מינימום, מקסימום או יחס. בשאלות חיפוש, היא משתמשת בשליפה סמנטית.
הנקודה החשובה היא שהפתרון אינו בהכרח יקר. סריקה של 100 אלף שורות לצורך אגרגציה בסיסית יכולה להסתיים בעשרות עד מאות מילישניות, לעיתים מהר יותר מקריאת API למודל שפה. כלומר, במקרים רבים התשובה המדויקת אינה רק אמינה יותר, אלא גם יעילה יותר.
המשמעות לשוק ה-AI הארגוני
הלקח רחב בהרבה מניסוי בודד. ארגונים שמטמיעים עוזרי AI על גבי מחסני נתונים, מערכות BI או קבצי משתמשים חייבים להפריד בין הבנת שפה לבין ביצוע חישוב. מודל שפה מצוין בפירוש כוונה, ניסוח תשובות והנגשת מידע. הוא אינו תחליף למנוע שאילתות, למסד נתונים או לשכבת סמנטיקה עסקית.
הדור הבא של מערכות AI ארגוניות לא ייבנה סביב "עוד הקשר" בלבד, אלא סביב ארכיטקטורה היברידית: מודל שפה בקדמת הממשק, נתב כוונות באמצע, ומנועי חישוב, חיפוש והרשאות מאחור. מי שימשיך להזרים שאלות אנליטיות ל-RAG יקבל תשובות יפות מדי ושגויות מדי. מי שיבנה הפרדה נכונה בין שליפה לחישוב יקבל מערכת שאפשר באמת לסמוך עליה.