הצ׳אטבוט שלכם ממציא כי הוא לא מחובר לעסק.
זו נקודת ההתחלה הכי חשובה להבנת RAG. לא כי AI “לא טוב”, ולא כי צריך מודל יקר יותר. ברוב המקרים הבעיה פשוטה יותר: המודל יודע לענות לפי מה שלמד בעבר, אבל הוא לא מכיר את הנהלים שלכם, המחירונים שלכם, חוזי השירות שלכם, מסמכי המכירות שלכם, או הדרך שבה העסק שלכם באמת עובד.
RAG, קיצור של Retrieval-Augmented Generation, היא שיטה שמחברת מודלי שפה כמו ChatGPT או Gemini למקורות ידע חיצוניים. לפי מקור 1, השיטה מאפשרת למודל לשלוף מידע ממסמכים, מאגרי נתונים, מסמכים שהועלו, או מקורות רשת, ורק אחר כך לנסח תשובה. במקום לבקש מהמודל “לזכור” את העסק, נותנים לו לחפש קודם במסמכים הנכונים.
למנהל או יזם ישראלי זה משנה מאוד. כי ברגע שעוזר AI עונה מתוך הידע הפנימי של החברה, הוא יכול להיות שימושי יותר בעבודה יומיומית: לענות לעובדים על נהלים, לעזור לאנשי מכירות למצוא תשובות מדויקות, לסכם מסמכים פנימיים, או להפנות לקוח למדיניות קיימת. אבל יש כאן תנאי אחד: RAG לא מסדר ידע מבולגן. הוא רק מחבר את ה-AI לידע שהכנתם מספיק טוב.
למה הצ׳אטבוט ממציא תשובות?
מודלי שפה גדולים עובדים על בסיס מידע שכבר נמצא באימון שלהם. לפי מקור 1, בלי RAG הם נשענים על נתוני אימון סטטיים. זה אומר שהם יכולים לנסח תשובה שנשמעת בטוחה, גם כשאין להם גישה למידע העדכני או הספציפי של העסק שלכם.
כאן מתחילות הבעיות. עובד שואל: “מה מדיניות ההחזרות שלנו ללקוח עסקי?” הצ׳אטבוט עונה משהו שנשמע הגיוני. אולי הוא אפילו משתמש בשפה יפה ומסודרת. אבל אם הוא לא מחובר למסמך מדיניות ההחזרות שלכם, הוא בעצם מנחש לפי דפוסים כלליים. בעסק, ניחוש כזה יכול להפוך מהר מאוד לטעות מול לקוח, עובד, ספק או עורך דין.
מקור 1 מציין ש-RAG עוזר להפחית הזיות AI, כלומר מצבים שבהם הצ׳אטבוטים מייצרים מידע לא נכון, כמו מדיניות שלא קיימת או תקדימים משפטיים שלא קיימים. אבל חשוב לשים לב לניסוח: להפחית, לא להעלים לגמרי. גם מערכת עם RAG יכולה לטעות אם המסמכים לא ברורים, אם היא שולפת קטע לא מתאים, או אם המודל מפרש לא נכון את ההקשר.
דוגמה עסקית פשוטה: יש לכם שני מסמכים. אחד ישן אומר שזמן אספקה הוא חמישה ימי עסקים. מסמך חדש אומר שזמן אספקה תלוי באזור ובסוג המוצר. אם שני המסמכים נמצאים במאגר, והישן לא מסומן כלא רלוונטי, ה-AI עלול לשלוף את המידע הלא נכון. הבעיה אינה רק ב-AI. הבעיה היא בניהול הידע.
אז מה RAG עושה בפועל?
אפשר לחשוב על RAG כעל שלושה שלבים פשוטים.
בשלב הראשון, המשתמש שואל שאלה. למשל: “מה מותר לנציג שירות להבטיח ללקוח לגבי החזר כספי?”
בשלב השני, המערכת מחפשת במסמכים שהוגדרו מראש. לפי מקור 1, RAG גורם למודל לפנות קודם לסט מסמכים מוגדר, ולשלוף ממנו טקסט רלוונטי. המסמכים האלה משלימים את מה שהמודל כבר למד באימון שלו.
בשלב השלישי, המודל מקבל את השאלה יחד עם הקטעים שנשלפו, ואז מנסח תשובה. מקור 1 מתאר זאת כך: בשלב היצירה, המודל משתמש גם בהנחיה המורחבת וגם בייצוג הפנימי של נתוני האימון שלו כדי לסנתז תשובה.
במילים פשוטות: RAG לא “מלמד” מחדש את המודל את כל העסק. הוא שם לפניו חומר רלוונטי בזמן השאלה. לכן מקור 1 מציין ש-RAG יכול לצמצם את הצורך באימון מחדש של מודלים עם מידע חדש, וכך לחסוך עלויות חישוב ועלויות כספיות.
דמיינו מנהלת תפעול ששואלת: “איך מטפלים בבקשת זיכוי מעל סכום חריג?” מערכת RAG טובה לא אמורה לענות מהזיכרון הכללי של המודל. היא אמורה למצוא את נוהל הזיכויים, את ההרשאות לפי תפקיד, ואולי גם את תבנית האישור. אחר כך היא תנסח תשובה קצרה, עם הפניה למקור.
זה ההבדל בין צ׳אט נחמד לבין עוזר עבודה אמין.
למה זה חשוב דווקא במסמכים פנימיים?
רוב הידע החשוב בעסק לא נמצא במאמרים ציבוריים. הוא נמצא במסמכים שלא תמיד נראים מרשימים: מצגות מכירה, נהלי שירות, קובצי שאלות ותשובות, תיעוד מוצר, סיכומי ישיבות, מסמכי הדרכה, טפסים, חוזים, ומיילים ישנים שהפכו בפועל למדיניות.
לפי מקור 1, RAG מאפשר למודלים להשתמש במידע תחומי או מעודכן שאינו נמצא בנתוני האימון. זה בדיוק הסיפור של ידע פנימי. המודל אולי יודע להסביר מהי חשבונית, מהו SLA, או מהו תהליך אונבורדינג. אבל הוא לא יודע איך החברה שלכם מגדירה SLA, מה כתוב בחוזה שלכם, או מה ההבדל בין לקוח רגיל ללקוח אסטרטגי אצלכם.
כאן RAG נותן ערך עסקי. הוא לא הופך את ה-AI ליודע כול. הוא נותן לו גישה לחומר שאתם בוחרים. זה גם אומר שהבחירה שלכם קריטית. אם מחברים את ה-AI לכל תיקיית החברה בלי סדר, מקבלים תשובות עם הרבה רעש. אם מחברים אותו למסמכים נקיים, מעודכנים ומסומנים היטב, הסיכוי לתשובה טובה עולה.
דוגמה: צוות מכירות רוצה עוזר שיענה על שאלות לגבי מוצר. במקום לחבר אותו לכל המצגות משנים קודמות, עדיף להתחיל ממסמך אחד: “תיאור מוצר עדכני לאנשי מכירות”. במסמך הזה יהיו יכולות, מגבלות, שאלות נפוצות, ניסוחים שאסור להבטיח, והפניות למסמכים תומכים. כך ה-AI לא צריך לנחש מתוך עשרים גרסאות של אותה מצגת.
מה צריך להכין לפני שמחברים AI למסמכים?
הטעות הנפוצה היא להתחיל בכלי. “איזה כלי RAG לבחור?” זו שאלה מפתה, אבל היא לא השאלה הראשונה.
השאלה הראשונה היא: איזה ידע אתם רוצים שהעוזר יכיר, ולאיזו עבודה?
לפני חיבור כלי AI למסמכי החברה, כדאי להכין ארבעה דברים.
ראשית, הגדירו שימוש אחד ברור. לא “עוזר לכל העסק”. למשל: עוזר לנציגי שירות שמסביר נהלי החזרות. או עוזר לאנשי מכירות שמוצא תשובות מתוך חומרי מוצר. שימוש צר מקל מאוד לבדוק אם המערכת באמת עובדת.
שנית, בחרו את המסמכים המוסמכים. מקור 1 מציין ש-RAG יכול ליצור תשובות על בסיס מקורות סמכותיים. המילה “סמכותיים” חשובה. בעסק, לא כל מסמך הוא מקור סמכותי. מצגת ישנה של סמנכ״ל מכירות לא בהכרח גוברת על נוהל תפעול מעודכן. סיכום ישיבה לא בהכרח גובר על חוזה חתום.
שלישית, נקו כפילויות וגרסאות ישנות. אם יש שלושה מסמכים עם שלוש תשובות שונות לאותה שאלה, ה-AI לא יפתור את הסתירה בשבילכם בצורה אמינה. הוא עשוי לבחור קטע אחד ולהישמע בטוח. אתם צריכים להחליט מראש מה נכון.
רביעית, כתבו ידע בצורה שאפשר לשלוף. RAG מחפש קטעים רלוונטיים. לכן מסמך טוב לעבודה עם AI צריך כותרות ברורות, ניסוחים ישירים, תשובות מפורשות, והקשר מספיק. אם נוהל כתוב בשפה פנימית עמומה, גם AI יתקשה להסביר אותו.
איך נראה מסמך טוב ל-RAG?
מסמך טוב ל-RAG לא חייב להיות ארוך. הוא צריך להיות ברור.
נניח שאתם רוצים עוזר לשאלות של אנשי שירות. במקום מסמך כללי בשם “נהלים”, כתבו מסמך עם כותרות כמו: “מתי מאשרים החזר כספי”, “מי מוסמך לאשר חריגה”, “מה אומרים ללקוח כשהבקשה נדחית”, “איזה מידע חייבים לתעד”.
בכל סעיף, התחילו מהכלל. אחר כך הוסיפו דוגמה. בסוף הוסיפו מה אסור להבטיח. זו כתיבה שעוזרת גם לבני אדם וגם ל-AI.
למשל:
“נציג שירות רשאי להציע זיכוי רק במקרים שמוגדרים במדיניות ההחזרות. בקשה חריגה עוברת לאישור מנהל צוות. אין להבטיח החזר לפני קבלת אישור.”
זה הרבה יותר טוב ממשפט כמו: “במקרים מסוימים יש לשקול החזר בהתאם לנסיבות ולמדיניות החברה.” המשפט השני נשמע מקצועי, אבל הוא לא עוזר למערכת לענות.
עוד נקודה חשובה היא שמות. אם בארגון קוראים לאותו דבר בשלושה שמות, כתבו זאת במסמך. למשל: “לקוח עסקי נקרא גם B2B או לקוח חברה.” זה עוזר למערכת להבין ששאלה במונח אחד יכולה להתאים למסמך במונח אחר.
ככל שהמסמך ברור יותר, כך RAG צריך פחות “לנחש” את ההקשר.
האם RAG מונע טעויות לגמרי?
לא. וחשוב להגיד את זה בצורה נקייה.
מקור 1 מדגיש ש-RAG משמש למניעת טעויות, אבל אינו פותר את כל הבעיות. גם כאשר המודל שולף ממקורות נכונים עובדתית, הוא יכול לייצר מידע שגוי אם הוא מפרש לא נכון את ההקשר.
הדוגמה שמופיעה במקור 1 מגיעה מ-MIT Technology Review: מערכת AI יצרה תשובה שגויה על נשיא מוסלמי בארצות הברית, לאחר ששלפה כותרת רטורית של ספר אקדמי ולא הבינה את ההקשר. הבעיה לא הייתה שהמקור בהכרח שקרי. הבעיה הייתה שהמודל לא הבין נכון את השימוש בכותרת.
בעסק, זה יכול לקרות גם אצלכם. מסמך הדרכה יכול לכלול דוגמה של “מה לא לומר ללקוח”, וה-AI עלול לשלוף אותה כתשובה מומלצת אם המסמך לא מסומן היטב. מסמך ישן יכול להיות חלק מתהליך שעבר שינוי. חוזה יכול לכלול תנאי ספציפי ללקוח אחד, והמערכת עלולה לענות כאילו זה כלל לכל הלקוחות.
לכן RAG צריך בקרות. לא רק חיבור למסמכים.
בקרה אחת היא הצגת מקורות. לפי מקור 1, RAG מאפשר למודלים לכלול מקורות בתשובות, כך שמשתמשים יכולים לבדוק את המקורות שצוטטו. זה נותן שקיפות ומאפשר לבחון אם התוכן שנשלף באמת מתאים.
בקרה שנייה היא ניסוח מדיניות תשובה. למשל: אם אין מקור ברור, המערכת צריכה לומר שאין לה תשובה מבוססת, במקום להשלים לבד. זה כלל עסקי חשוב מאוד.
בקרה שלישית היא בדיקות עם שאלות אמיתיות. קחו שאלות שעובדים שואלים בפועל, הריצו אותן מול המערכת, ובדקו לא רק אם התשובה נשמעת טוב, אלא אם היא נשענת על המקור הנכון.
מה ההבדל בין RAG לבין אימון מודל?
הרבה מנהלים שומעים “לחבר AI לידע של החברה” וחושבים מיד על אימון מודל. אבל RAG ואימון הם דברים שונים.
באימון, משנים את המודל או מכוונים אותו על מידע מסוים. ב-RAG, לפי מקור 1, המודל שולף מידע ממאגר חיצוני בזמן השאלה. המידע הזה נוסף להנחיה שמגיעה למודל, כך שהוא יכול לענות על בסיסו.
המשמעות העסקית פשוטה: אם יש לכם נוהל שהתעדכן, ב-RAG אתם מעדכנים את מאגר הידע החיצוני. מקור 1 מביא את Ars Technica, שמסביר שכאשר מידע חדש נעשה זמין, במקום לאמן מחדש את המודל, אפשר להוסיף את המידע למאגר הידע החיצוני.
זה מתאים מאוד לעסקים שבהם ידע משתנה: מחירים, נהלים, מדיניות שירות, תיאורי מוצר, תהליכי עבודה, שאלות מכירה. אתם לא רוצים לאמן מודל מחדש בכל פעם שהמסמך משתנה. אתם רוצים שהמערכת תשלוף את הגרסה הנכונה.
אבל זה גם אומר שהמאגר החיצוני הופך לנכס תפעולי. צריך לדעת מי מעדכן אותו, מי מאשר מסמכים, איך מסמנים תוקף, ואיך מוציאים מסמך שכבר לא נכון.
RAG לא מחליף ניהול ידע. הוא חושף מהר מאוד איפה ניהול הידע שלכם טוב, ואיפה הוא לא קיים.
איך מתחילים בלי להסתבך?
התחילו קטן. שימוש ראשון טוב ל-RAG הוא מקום שבו יש הרבה שאלות חוזרות, ויש מסמכים יחסית ברורים.
שירות לקוחות הוא דוגמה טובה. גם מכירות. גם משאבי אנוש. אבל אל תחברו את הכול ביום אחד. בחרו תחום אחד ושאלו: אילו עשרים שאלות חוזרות אנחנו רוצים שה-AI יענה עליהן מתוך מסמכים?
אחר כך הכינו תיקיית ידע קטנה. לא מאות קבצים. כמה מסמכים מוסמכים, מעודכנים וברורים. תנו להם שמות פשוטים. הוסיפו בראש כל מסמך תיאור קצר: למי המסמך מיועד, מתי הוא עודכן, ומה הוא מכסה.
בשלב הבא, בדקו שאלות. אל תסתפקו בהתרשמות. שאלו שאלות קלות, שאלות עמומות, ושאלות שאין עליהן תשובה. השאלה שאין עליה תשובה חשובה במיוחד. מערכת טובה צריכה לדעת להגיד: “לא נמצא מקור מתאים במסמכים שסופקו.”
זה רגע קריטי. אם המערכת עונה גם כשאין מקור, אתם מקבלים ביטחון מזויף. וזה בדיוק מה ש-RAG אמור לצמצם.
איפה RAG נותן ערך למנהלים?
RAG נותן ערך כאשר יש פער בין מה שאנשים צריכים לדעת לבין כמה מהר הם מצליחים למצוא את זה.
מנהלים מרגישים את הפער הזה כל הזמן. עובד חדש שואל את אותה שאלה בפעם הרביעית. נציג שירות מחפש נוהל באמצע שיחה. איש מכירות לא בטוח מה מותר להבטיח. יועץ רוצה להבין מהר מסמך ארוך. צוות הנהלה רוצה לקבל תשובה מתוך חומר פנימי בלי לחפש ידנית.
RAG יכול לקצר את החיפוש ולהפוך ידע מפוזר לשיחה. אבל השיחה צריכה להישען על מקורות. לכן אל תמדדו רק “כמה יפה התשובה”. מדדו אם התשובה עוזרת לבצע פעולה נכונה.
דוגמה: מנהל מכירות שואל “איך להסביר ללקוח את מגבלות המוצר?” תשובה יפה מדי עלולה להיות מסוכנת. תשובה טובה תשלוף את מסמך המוצר, תציין את המגבלות שאושרו, ותנסח נוסח שאפשר להשתמש בו בשיחה. אם יש מקור, המשתמש יכול לבדוק אותו. אם אין מקור, המערכת לא צריכה להמציא.
זה שימוש עסקי חזק: לא להחליף שיקול דעת, אלא להנגיש ידע מוסמך בזמן העבודה.
מה יכול להשתבש בפרויקט RAG?
הדבר הראשון שיכול להשתבש הוא חיבור למידע לא מסודר. אם המסמכים סותרים זה את זה, המערכת תתקשה. אם אין בעלים לידע, אף אחד לא יעדכן. אם אין הגדרה של מקור מוסמך, כל מסמך ישן יכול להפוך לתשובה.
הדבר השני הוא אמון יתר. בגלל שהמערכת מציגה תשובה בשפה בטוחה, אנשים עלולים להפסיק לבדוק. לכן חשוב להציג מקורות, במיוחד בתחומים שבהם טעות יכולה לעלות ביוקר.
הדבר השלישי הוא שאלה רחבה מדי. “מה המדיניות שלנו?” היא שאלה פחות טובה מ-“מה נציג שירות רשאי לומר ללקוח לגבי החזר כספי?” ככל שהשאלה מדויקת יותר, כך קל יותר לשלוף קטע מתאים.
הדבר הרביעי הוא מסמכים שלא נכתבו לשימוש. הרבה מסמכים פנימיים כתובים כדי לסמן וי, לא כדי להסביר. RAG יצליח יותר כשהידע כתוב בשפה שמישהו באמת יכול להבין.
הדבר החמישי הוא ציפייה ש-RAG יפתור הכול. לפי מקור 1, RAG משלב שליפה עם יצירת תשובה, ועוזר למודלים להיצמד לעובדות. אבל הוא עדיין משתמש במודל שפה. המודל עדיין יכול לפרש לא נכון, לחבר דברים לא נכון, או לענות מעבר למה שהמקורות מאפשרים.
מה כדאי לעשות עם זה השבוע
1. בחרו תהליך אחד עם הרבה שאלות חוזרות בחרו תחום קטן: שירות, מכירות, משאבי אנוש, תפעול או תמיכת לקוחות. כתבו רשימה של עשר שאלות שעובדים שואלים שוב ושוב. אל תתחילו מכל החברה. התחילו ממקום שבו תשובה טובה תחסוך זמן כבר עכשיו.
2. הכינו תיקיית ידע מוסמכת אספו רק מסמכים שאתם מוכנים שה-AI יתבסס עליהם. מחקו או הוציאו גרסאות ישנות. סמנו מהו המסמך הקובע. כתבו לכל מסמך כותרות ברורות, ותוסיפו דוגמאות קצרות. אם יש סתירה בין מסמכים, פתרו אותה לפני החיבור ל-AI.
3. בדקו את המערכת עם שאלות אמיתיות הריצו שאלות של עובדים. בדקו האם התשובה נשענת על מקור נכון. הוסיפו גם שאלות שאין עליהן תשובה במסמכים. אם המערכת ממציאה במקום להגיד שאין מקור מתאים, אל תעלו אותה לשימוש רחב לפני שמתקנים את זה.
השורה התחתונה של תכלס AI
RAG הוא לא קסם. הוא דרך מעשית לחבר מודל שפה לידע שהעסק שלכם כבר מחזיק: מסמכים, נהלים, מאגרי נתונים ומקורות מוסמכים.
לפי מקור 1, RAG מאפשר למודלים לשלוף מידע חיצוני ורלוונטי לפני יצירת תשובה, להשתמש במידע תחומי או מעודכן שאינו נמצא באימון, להפחית הזיות, ולעזור למשתמשים לבדוק מקורות. אבל הוא לא מבטל טעויות, ולא מחליף סדר בידע.
המסר למנהלים פשוט: לפני שאתם מחברים AI למסמכי החברה, סדרו את הידע. הגדירו מה מוסמך, מה עדכני, מי אחראי, ואיך נראית תשובה טובה. צ׳אטבוט שמחובר למסמכים מבולגנים יענה בביטחון על בלגן. עוזר AI שמחובר לידע נקי וברור יכול להפוך את הידע הפנימי של העסק לכלי עבודה יומיומי.