RAG הוא תהליך שבו מערכת מחפשת מידע רלוונטי לפני שהיא מבקשת מהמודל לנסח תשובה. במקום לצפות שהמודל יכיר את הנהלים של העסק, מעבירים לו קטעים שנמצאו במאגר. כדי שהמענה יהיה שימושי, צריך גם לבחור גרסה נוכחית, לסנן מידע לפי הרשאות ולהציג מקור שאפשר לבדוק.
RAG אינו מבטל טעויות. הוא מאפשר לבנות תהליך שניתן לבדוק: מה חיפשנו, אילו מסמכים נשלפו, מה הועבר למודל והאם התשובה נתמכת בהם. המדריך כולל מאגר בדיוני וקבצי תרגול, כדי להמחיש את ההפרדה בין השלבים.
מה קורה מרגע שהעובד שואל שאלה
נניח שעובדת שואלת: ״תוך כמה זמן צריך לענות לפנייה חדשה?״ המערכת מזהה את החשבון ואת תפקיד העובדת, מחפשת רק במסמכים שהיא רשאית לראות, בוחרת את נוהל המענה הנוכחי ומעבירה למודל את הקטע המתאים עם מזהה וגרסה. בתשובה מופיעים זמן המענה והמקור.
החיפוש יכול לשלב התאמה מילולית וחיפוש סמנטי, שמנסה לאתר משמעות גם כאשר הניסוח שונה. בחירת שיטת חיפוש היא החלטת פיתוח, ולא תנאי יחיד לאיכות. לדוגמה, תיעוד האחזור של OpenAI מתאר חיפוש סמנטי וסינון לפי מאפייני קובץ לפני החיפוש.
גם מנוע חיפוש טוב לא יתקן מאגר שבו נוהל ישן מסומן כעדכני. לכן העבודה מתחילה במידע עצמו: מזהה קבוע למסמך, בעלים, גרסה, סטטוס ותפקידי גישה. מסמך סרוק באיכות נמוכה עשוי לדרוש תיקון לפני שאפשר להסתמך על התוכן שחולץ ממנו.
המאגר שבנינו לתרגול
יצרנו שישה מסמכים קצרים עבור ״סטודיו תרגול״ הבדיוני: שירותים, נוהל מענה ישן, נוהל מענה נוכחי, העברה לאדם, תקציב פנימי למנהלת ומסמך של חברה אחרת. נוהל המענה הישן אומר שלושה ימי עבודה; הנוכחי אומר שניים. השינוי מכוון, כדי לבדוק איזו גרסה מגיעה לתשובה.
אפשר להוריד את המסמכים והשאלות הצפויות. הנתונים כוללים שדות tenant, audience, status ו־version. אלה שמות השדות בדוגמה שלנו; במערכת אחרת הם יכולים להיראות אחרת.
ערכת הקוד המצורפת מדגימה חיפוש מילולי. הסינון לפי ארגון, תפקיד וסטטוס מתבצע לפני דירוג התוצאות. זהו מימוש מקומי של בחירת המקור; הוא אינו מדידת איכות של מודל או השוואה בין מנועי חיפוש סמנטי.
ארבעה מקרים והתוצאה הנדרשת
| בקשה של משתמש staff | המקור המותר | התשובה הנדרשת |
|---|---|---|
| מענה לפנייה | נוהל response-v2 הנוכחי | שני ימי עבודה, עם הפניה לגרסה 2 |
| תקציב פנימי | רשימה ריקה | ציון שאין מידע במקורות |
| מידע מחברה אחרת | רשימה ריקה | ציון שלא סופקו מקורות |
| סניפים באוסטרליה | רשימה ריקה | הימנעות מהמצאת מספר או מיקום |
אלה התוצאות הנדרשות בתרגיל. מסמכים חסויים או לא־תקפים צריכים להיפסל לפני שליחת חומר למודל. אין להסתפק בשליחת מסמך חסוי עם הוראה להתעלם ממנו. בערכת הקוד מופיעות בדיקות לוגיקת הסינון המקומית.
בדיקות הסינון אינן מוכיחות את איכות התשובה של מודל. במאגר אמיתי יש להביא בחשבון ניסוחים חלופיים, קבצים ארוכים, כותרות דומות, גרסאות סותרות ושאלות המחברות מסמכים. חיפוש מילולי עלול לפספס מקור שהעובד תיאר במילים אחרות.
מדריכים ועדכונים לעבודה עם AI
מדריכים בעברית, עדכוני כלים ודוגמאות לעבודה עם בינה מלאכותית.
הרשאה נקבעת בשרת
המשתמש אינו אמור לבחור לעצמו תפקיד או ארגון בתוך הפרומפט. את הזהות לוקחים ממנגנון ההתחברות, ואת כללי הגישה מחילים לפני החיפוש והעברת המידע למודל. גם קישור המקור צריך לכבד הרשאות: אין תועלת בהסתרת הטקסט אם הקישור מאפשר לפתוח קובץ שהעובד אינו רשאי לראות.
הוראה שמופיעה בתוך מסמך אינה אישור לשינוי התנהגות. מסמך יכול לכלול טקסט לא תקין או הוראות שנשתלו בו. על הסוכן להתייחס אליו כחומר לבדיקה, ולהישאר בתוך הפעולות שהמערכת מאפשרת. כאשר נדרשים גם עדכונים במערכות, מדריך MCP עוסק בהפרדה בין קריאה, הצעת שינוי ואישור ביצוע.
מקור ליד התשובה, לא רק רשימת קישורים
כדאי להצמיד לכל טענה את המסמך והגרסה שתומכים בה. אם התשובה אומרת ״שני ימי עבודה״, המשתמש צריך לדעת באיזה נוהל זה מופיע. כשאין מקור מתאים, התשובה צריכה לציין מה חסר ולהפנות להשלמת מידע לפי תהליך שהוגדר.
במערכת גדולה אפשר לתעד גם את הקטע שנשלף, מועד האחזור וזהות הגרסה. כך ניתן לחקור תלונה על תשובה שגויה בלי לנחש אילו מסמכים היו זמינים בזמן השיחה. אין צורך להציג למשתמש כל פרט טכני; לצוות האחראי כן נדרש תיעוד שמאפשר בדיקה.
למה החלוקה לקטעים משנה את התשובה
מסמך ארוך מחולק בדרך כלל לקטעים שניתן לאחזר. אם כלל השירות נמצא בפסקה אחת והחריג נמצא בפסקה שאחריה, חלוקה לא מוצלחת עלולה להחזיר רק את הכלל. למשל, נוהל יכול לומר שהחזר מאושר בתנאי מסוים, ובהמשך להחריג שירות שכבר בוצע. החזרת המשפט הראשון בלבד יוצרת חומר מקור חלקי, גם אם מנוע החיפוש פעל בדיוק לפי הבקשה. לכן צריך לבדוק את הקטעים שנכנסים למודל, ולא רק את הקובץ המקורי.
כותרות ברורות, טבלאות שנקראות היטב והצמדה של תנאים לחריגים עוזרות לבנות מאגר שימושי. אין גודל קטע אחד שמתאים לכל סוגי המסמכים. מפרט טכני, נוהל שירות ורשימת שאלות עשויים לדרוש טיפול שונה. התחילו מכמה שאלות מוכרות ובדקו אם הקטע שהוחזר מספיק כדי לענות עליהן. כאשר התשובה דורשת שני מקורות, ודאו ששניהם זמינים ושאין ביניהם סתירה שלא הוכרעה.
תרגיל: השאלה נכונה, המילים שונות
בנוהל התרגול כתוב ״זמן מענה לפנייה״, והעובדת שואלת ״מתי צריך לחזור ללקוח שהשאיר פרטים?״ חיפוש שמסתמך רק על מילים זהות עשוי לפספס את הקשר. חיפוש סמנטי נועד לעזור במקרים כאלה, אך עדיין צריך לבחון את התוצאה. ייתכן שהוחזר דווקא נוהל של לקוח קיים משום שגם בו מופיעה שיחה חוזרת. המילה ״לקוח״ לבדה אינה מספיקה כדי להבחין בין התהליכים.
בודקים קודם את האחזור
הריצו את שלב החיפוש בסביבת בדיקה והסתכלו על המקורות שחזרו. האם נמצא response-v2? האם מופיעה הגרסה הישנה? האם הקטע כולל את הביטוי ״ימי עבודה״? בשלב הזה אין צורך לבקש מהמודל לנסח תשובה. אתם בודקים אם חומר הגלם נכון. אם המסמך הרלוונטי לא הגיע, ניסוח פרומפט משכנע יותר לא יוסיף למודל מידע שמעולם לא קיבל.
בודקים את הניסוח רק לאחר בחירת המקור
כשהמקור הנכון זמין, בקשו תשובה קצרה עם ההפניה אליו. בדוגמה שלנו יש הבדל בין ״נחזור בתוך שני ימי עבודה״ לבין ״נפתור את הפנייה בתוך שני ימי עבודה״. השני מוסיף התחייבות שאינה בנוהל. בדיקת איכות המענה צריכה לזהות את השינוי במשמעות, גם כאשר המספר עצמו נשמר. כך מפרידים בין כשל בחיפוש לבין כשל בשימוש במקור שנמצא.
תוצאה שאין לה מקור מספק
אם לא נמצא נוהל תקף, הציגו למשתמש שהמידע אינו זמין במאגר והציעו את מסלול הבירור המתאים. הימנעו ממשפט שמרמז שאין בעסק נוהל כלל: ייתכן שהוא קיים אך לא הועלה, או שהמשתמש אינו רשאי לראותו. הניסוח צריך לתאר את גבול המידע שהמערכת קיבלה, בלי לחשוף מסמכים חסויים ובלי להפוך חוסר באחזור לקביעה עובדתית על העסק.
עדכון מאגר בלי להשאיר תשובות ישנות
בדקו גם כיצד מוצג המקור לעובד. כותרת כמו ״נוהל מענה, גרסה 2״ שימושית יותר משם קובץ אקראי, אבל הקישור חייב לפתוח את המקום הנכון. כאשר המסמך ארוך, הפניה לפרק או לעמוד מקצרת את הבדיקה. אם הקישור אינו זמין למשתמש, התשובה צריכה להסביר איך לקבל גישה בהתאם לנהלי העסק. אחרת נוצרת תחושת אמינות בזכות הפניה שהקורא אינו יכול לבדוק בפועל, והיתרון המרכזי של שימוש במקורות הולך לאיבוד.
נוהל חדש צריך לעבור את אותו מסלול שבו המסמך הישן נכנס למערכת: קליטה, חילוץ, חלוקה ואינדוקס. החלפת הקובץ בתיקייה אינה מוכיחה שכל השכבות עודכנו. בתכנון המערכת הגדירו איך מזהים עותק ישן, איך מסמנים את החדש כפעיל ואיך מונעים הצגת תוצאה שנשמרה במטמון לפני השינוי. המנגנון המדויק תלוי בתשתית; בדיקת הקבלה היא שהשאלה מחזירה את הגרסה המאושרת לאחר העדכון.
שמרו גם דרך לבדוק תלונה היסטורית. אם עובד קיבל תשובה אתמול והנוהל השתנה היום, צריך לדעת מה היה המקור בזמן המענה. תיעוד מזהי המקורות ומועד האחזור יכול להסביר את ההבדל בלי לשמור כל פרט אישי מהשיחה. בחרו את היקף התיעוד לפי הצורך התפעולי ומדיניות המידע של העסק, והגדירו מי רשאי לגשת אליו.
הצלחה של סוכן ידע נבחנת ביכולת של העובד לקבל תשובה ולהבין על מה היא מבוססת. יותר קבצים או תשובות ארוכות יותר אינם הישג בפני עצמם. הרחיבו את המאגר כאשר מתגלה צורך מוגדר, ושמרו על בעלות ברורה למקורות. כך אפשר לבנות בהדרגה ספריית ידע שמשרתת תהליכי עבודה, במקום אוסף קבצים שהמודל מתקשה להבחין בין הגרסאות שלהם.
שאלות נפוצות
במה זה שונה מ־Claude Projects?
Claude Projects הוא מוצר מוכן לארגון שיחות, הוראות וחומרי ידע. מערכת RAG מותאמת יכולה להשתלב בהרשאות, במאגרים ובתהליכים של עסק מסוים. יש חפיפה ברעיון של שימוש במקורות, אך היקף השליטה והאחריות שונה. למי שמתחיל, מדריך קלוד בעברית מציג עבודה בסיסית עם מסמך.
האם צריך להעלות את כל החומר של העסק?
לא. התחילו באוסף קטן, עדכני ומורשה שנותן מענה לתהליך אחד. קבצים כפולים, לא ברורים או שאיש אינו אחראי לעדכנם עלולים להקשות על המענה. הרחיבו לאחר בדיקת השאלות והתשובות.
מה צריך כדי לתכנן סוכן ידע לצוות?
דוגמאות לשאלות, מקורות אפשריים, סוגי משתמשים וכללי גישה. מדריך סוכן AI לעסק יעזור לבחור את התהליך. אם הידע אצלכם מפוזר בין מסמכים ומערכות, אפשר לאפיין מערכת שתמצא תשובות מתוך החומר של העסק.