מה זה RAG ואיך בונים עוזר ידע ארגוני על מסמכי החברה?

RAG מה זה, ואיך השיטה עובדת?

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

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

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

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

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

ממה מורכב עוזר ידע ארגוני מבוסס RAG?

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

1. מקורות מידע: מסמכי Word, קובצי PDF, נהלים, מאגרי ידע, מערכות CRM ומערכות פנימיות. אנחנו מגדירים אילו מקורות נכללים במערכת, מי אחראי עליהם ואיך הם מתעדכנים.
2. הכנת המידע: המערכת מחלצת טקסט מהמסמכים, מסדרת אותו ומחלקת אותו לקטעים שמתאימים לחיפוש. בשלב הזה חשוב לשמור גם פרטים כמו שם המסמך, תאריך העדכון והשיוך למחלקה.
3. מנגנון חיפוש: כאשר מתקבלת שאלה, המערכת מחפשת קטעי מידע רלוונטיים. אפשר לשלב חיפוש לפי מילים עם חיפוש סמנטי, שמזהה משמעות גם כאשר השאלה מנוסחת אחרת מהטקסט המקורי.
4. מודל שפה: ה-LLM מקבל את השאלה ואת קטעי המידע שנמצאו ומנסח תשובה ברורה. אנחנו מגדירים לו כיצד לענות, מתי לציין שחסר מידע ואיך להתייחס למקורות סותרים.
5. ממשק והרשאות: העובדים שואלים שאלות בממשק ייעודי, והמערכת מגבילה את הגישה למידע בהתאם להרשאות שלהם.
6. ניטור ובקרה: אנחנו בודקים אילו שאלות נענו היטב, היכן המערכת התקשתה, אילו מסמכים חסרים ומתי נדרש עדכון.

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

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

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

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

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

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

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

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

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

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

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

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

טעויות נפוצות בהטמעת RAG בארגון

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

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

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

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

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

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

איך מתחילים לבנות מערכת RAG על מסמכי החברה?

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

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

כך אפשר לחלק את הפיילוט לשלבים:

1. בחירת התהליך: מגדירים אילו שאלות המערכת אמורה לענות עליהן ומי ישתמש בה.
2. בחירת המקורות: מרכזים את המסמכים הרלוונטיים, מסירים כפילויות ומזהים מי אחראי לעדכון כל מסמך.
3. תכנון הרשאות: מגדירים איזה מידע גלוי לכל קבוצת משתמשים ומוודאים שההגבלות נאכפות בזמן החיפוש.
4. בניית העוזר: מחברים את המידע, מגדירים את מנגנון האחזור ואת מודל השפה ומוסיפים קישורים למקורות.
5. בדיקת תשובות: מכינים שאלות אמיתיות מתוך העבודה היומיומית, כולל שאלות שאין להן תשובה ושאלות שנוגעות למידע חסוי.
6. שיפור והרחבה: מתקנים בעיות שאותרו, מודדים שימושיות ורק לאחר מכן מחליטים אם לחבר מחלקות ומקורות נוספים.

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

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

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

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