מודיעין מסמכים ארגוני: למה RAG ארגוני צריך יותר הנדסה ופחות קסם

ארגונים רבים כבר עברו את שלב ההתלהבות ממענה אוטומטי על מסמכים, אבל דווקא עכשיו מתברר שהפער האמיתי אינו עוד מודל חזק יותר. הבעיה המרכזית היא שמערכות RAG רבות נבנות כמו הדגמת מעבדה: חותכים קבצי PDF למקטעים, מכניסים למסד וקטורי, שולפים כמה קטעים לפי דמיון סמנטי ומקווים שהמודל יחבר תשובה נכונה. בארגון מפוקח, תקווה אינה ארכיטקטורה.
למה RAG ארגוני מתחיל בהנדסת מסמכים
הדיון המקצועי סביב מודיעין מסמכים ארגוני מסמן שינוי חשוב: RAG עסקי לא אמור להיראות כמו חיפוש פתוח באינטרנט. בארגונים יש תבניות חוזים, דוחות רגולטוריים, פוליסות, מפרטים, נהלים ושפה פנימית. לכן השלב הראשון הוא לא בחירת מסד וקטורי, אלא פירוק המסמך למבנה שניתן לשליטה: עמודים, סעיפים, טבלאות, שדות, מזהי מקור וציטוטים ברמת שורה. רק כך אפשר לשחזר תשובה, להבין מדוע מקור מסוים נשלף ולבדוק אם המודל נשען על עובדה או משלים מידע מזיכרון פנימי.
ההבחנה הזו קריטית כי RAG האקדמי נולד כדי להעשיר ידע של מודל ולהפחית הזיות. במערכות ארגוניות הרף גבוה יותר: כל טענה עובדתית צריכה להיות קשורה למסמך, לעמוד, לסעיף ולציטוט. המודל רשאי לעזור בניסוח, חילוץ שדות, סיווג והסקה מוגבלת, אבל הוא לא אמור להיות מקור הסמכות. מקור הסמכות הוא המסמך העסקי והיכולת להוכיח איך הגענו לתשובה.
איך מצמצמים הזיות באמצעות ציטוטים ועקיבות
מסדי וקטורים הם כלי חשוב, אבל הם אינם נקודת פתיחה אוטומטית. חיפוש סמנטי מצוין כאשר הניסוח עקיף, כאשר יש מילים נרדפות או כאשר השאלה חוצה שפות. לעומת זאת, הוא חלש יותר בשלילה, בערכים מספריים, בראשי תיבות פנימיים ובשאלות שבהן סדר הסעיפים משנה. שאלה כמו האם החרגה מסוימת חלה רק מעל סכום מסוים יכולה ליפול בין מקטעים, גם אם הדמיון הקוסיני נראה גבוה.
כאשר אנו מלווים חברות בתהליכים דומים, המדד הראשון שאנו בודקים אינו דיוק לשוני אלא עקיבות. מערכת טובה צריכה להחזיר תשובה, מקורות, רמת ביטחון וסיבה לשליפה. בשלב התכנון כדאי להגדיר סט שאלות זהב של לפחות מאה תרחישים עסקיים, למדוד שיעור תשובות עם ציטוט תקין, שיעור תשובות ללא מקור ושיעור סירוב מוצדק. במערכות ביטוח, משפטים ופיננסים, תשובה לא מבוססת אחת יכולה לייצר חשיפה רגולטורית או מחלוקת חוזית, ולכן עדיף מנגנון שמסרב לענות על פני מנגנון שמנסח היטב טעות.
איזו תשתית AI נדרשת לפני סוכנים ומסדי וקטורים
המשמעות הניהולית ברורה: AI ארגוני הוא לא פרויקט טכני בלבד. הוא דורש הבנת תהליך עסקי, מומחי תחום, הנדסת נתונים, בקרות ואדם בלולאה. אבל אדם בלולאה אינו אמור לבדוק כל תשובה ידנית. תכנון נכון מאפשר למומחה שהיה מטפל במקרה אחד לפקח על מאות תהליכים, באמצעות חריגים, דגימות, ציוני אמון ותורים לבקרה. זו הדרך להפוך AI להתייעלות תפעולית אמיתית ולא לעוד שכבת עבודה.
לפני שמוסיפים סוכנים, rerankers או מודלים יקרים יותר, צריך לבדוק ארבע שאלות פשוטות: האם המסמך פורק נכון, האם השאלה תורגמה למונחי התחום, האם השליפה ניתנת להסבר, והאם התשובה מחויבת לסכמה עם ציטוטים. רק לאחר מכן נכון לשלב Embeddings, מודלים מתקדמים או אוטומציות. ארגונים שיבנו יכולת פנימית כזו ירוויחו לא רק מערכת שאלות ותשובות, אלא שכבת מודיעין מסמכים שניתן להרחיב לחוזים, שירות, ציות, תפעול ומכירות. כאן ההייפ מסתיים, וכאן מתחילה ההנדסה שמייצרת אמון.


