RAG ארגוני שבאמת עובד: הלקח מהמערכת הפנימית של Cerebras

מערכת ידע ארגונית שימושית צריכה לעזור לאנשים למצוא מידע מתוך הכלים שבהם הם כבר עובדים. לרקע על המערכת של Cerebras ראו את הפרסום המקורי How We Built Our Knowledge Base. ההסבר להלן מתמקד בעקרונות לבניית תהליך איסוף, אחזור ובקרת תשובות; הוא אינו מקרה לקוח של NexAi או הבטחה לדיוק מסוים.

מה RAG בעצם עושה

נניח ששואלים מודל שפה "כמה גבוה ניק?" - התשובה תהיה כללית וסתמית, כי יש בעולם מאות אנשים בשם ניק והמודל מנסה לנחש למי הכוונה. אבל אם לפני השאלה מוסיפים משפט קצר - "ניק גובהו 1.88" - ואז שואלים את אותה השאלה, המודל עונה מיד ובבטחון. זה, בעצם, כל מה ש-RAG (retrieval augmented generation) עושה: הוא מוצא את פיסת המידע הרלוונטית במאגר נתונים ומזריק אותה לפני השאלה, לפני שהמודל בכלל מנסה לענות. עבור עסק, זה אומר שבמקום לשאול "מה פיטר אמר בהרצאה שבוע שעבר?" ולקבל תשובה כללית וריקה, המערכת מוצאת קודם את התמלול הרלוונטי ומזינה אותו כהקשר - ואז המודל פשוט מדווח על מה שכתוב שם.

זה לא רק טקסט - זה טקסט עם metadata, כמו תמונה עם EXIF

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

שלוש שכבות של מערכת ידע ארגונית

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

איך בונים את זה בפועל

הבנייה בפועל דומה יותר להטמעת תהליך עבודה מאשר לפרויקט תוכנה מסובך. נותנים לסוכן קוד (Claude Code, Codex, או כל מודל שיודע לבצע פעולות במחשב) את המפרט הטכני, ומבקשים ממנו לבנות ingestion pipeline לכל מקור נתונים - Slack, מייל, GitHub, כל מה שרלוונטי לעסק. הסוכן מתחבר לחשבונות קיימים, ולכל מקור שעדיין אין לו גישה אליו הוא עצמו מסביר איך להקים אותו (למשל: פתיחת פרויקט ענני, אישור OAuth, טוקן ריענון) - זמן החיבור תלוי בהרשאות, באיכות המידע ובבדיקות הנדרשות לכל מקור. ברגע שהחיבורים במקום, הסוכן בונה שלב זיקוק: כל שרשור שיחה או מסמך עובר עיבוד שמפיק ממנו שאלה, תקציר, פתרון (אם רלוונטי), ורשימת מערכות מעורבות - וזה נשמר במסד נתונים עם שכבת אחזור שמשלבת חיפוש טקסט מדויק עם חיפוש embeddings.

איך בודקים שהאחזור משפר את התשובות

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

לסיכום

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

להמשך העבודה

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