Grounding ו-RAG ב-Agentforce: איך מחברים סוכן לידע אמין

התשובה הקצרה

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

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

הקשר הרחב לבחירת Use Case מופיע בAgentforce לארגונים.

ארבע השכבות של Grounding

שכבה 1: הכרזה על מקורות אמת

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

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

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

היסודות של ניקוי והכשרת מאגר הידע מפורטים במוכנות Knowledge ל-Agentforce.

שכבה 2: Chunking, Metadata ורלוונטיות

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

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

בדיקת הרלוונטיות היא כמותית ולא תחושתית: בונים סט של 50 עד 100 שאלות אמיתיות עם התשובה הנכונה והמקור הנכון, ומודדים בכמה מהמקרים הקטע הנכון הופיע בשליפה. ציון Recall נמוך מצביע על בעיית ייצוג, וטיפול בו זול בהרבה מהחלפת מודל או שכתוב Instructions.

שכבה 3: הרשאות ברגע האחזור

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

בפועל נדרשות שלוש בדיקות. ראשית, מיפוי בין רמות הסיווג במקור החיצוני לבין Profiles ו-Permission Sets ב-Salesforce. שנית, בדיקת Persona: מריצים את אותן עשר שאלות בזהות של נציג, מנהל ולקוח חיצוני ומשווים תשובות. שלישית, טיפול בתוכן מעורב - מסמך שרובו ציבורי ופסקה אחת בו רגישה חייב להיחתך או לא להיכנס.

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

מודל האחריות בין הארגון, Salesforce וספק המודל מפורט באבטחת Agentforce ואחריות משותפת.

שכבה 4: Citations, Freshness ו-Fallback

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

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

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

תרחיש: חברת ביטוח עם 900 מאמרי Knowledge

חברת ביטוח רצתה סוכן שיענה לנציגי מוקד על תנאי פוליסה. הפיילוט הראשון נכשל: 40% מהתשובות היו שגויות או חלקיות. הניתוח הראה שהבעיה כולה בשכבת המקורות - מתוך 900 מאמרים, 380 לא עודכנו מעל שלוש שנים, ו-60 מהם סתרו מאמרים חדשים יותר על אותו נושא.

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

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

סיכונים ופעולות מניעה

מדדים לשכבת ה-Grounding

שיעור Fallback גבוה אינו כישלון - הוא מפה של פערי תוכן. הרשימה של השאלות שהובילו ל-Fallback היא הסדר עדיפויות הטוב ביותר לכתיבת מאמרים חדשים.

כאשר חסרה קיבולת פנימית להקמת שכבת Grounding מבוקרת, שירות Agentforce ו-AI הוא המסלול המעשי להמשך.

Checklist לפני חיבור סוכן למקורות

• ☐ עשרים השאלות הנפוצות מופו למקור התשובה הנוכחי
• ☐ לכל מקור באינדקס יש בעלים בשם ותדירות עדכון
• ☐ מקורות סותרים אותרו וארכובו
• ☐ קיים תיוג של מוצר, שוק, שפה, קהל ותאריך תוקף
• ☐ Chunking שומר על טבלאות ורשימות שלבים
• ☐ האחזור רץ בהקשר ההרשאות של המשתמש
• ☐ בוצעה בדיקת Persona לכל רמת הרשאה רלוונטית
• ☐ קיים סט בדיקה של 50 שאלות עם תשובה ומקור נכונים
• ☐ Citations מפנים לקטע שנשלף בפועל
• ☐ מסלול Fallback מנוסח ונבדק בערוץ הלקוח