RAG: איך מחברים בינה מלאכותית למסמכי העסק ובודקים את התשובות

מה זה rag ואיזו בעיה הוא פותר בעסק

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

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

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

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

איך המסמכים הופכים לתשובה שאפשר לבדוק

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

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

לפי ההנחיות לחלוקת מסמכים של Microsoft, החלוקה צריכה לשמור על ההקשר והמשמעות. בחלוקה לגודל קבוע, Microsoft ממליצה להתחיל במקטעים של 512 טוקנים (כ־2,000 תווים) עם חפיפה של 25% בין מקטעים. נניח שסעיף מתאר זכאות והפסקה הבאה מגבילה אותה: כדאי לבדוק ששניהם זמינים יחד כשנדרשת תשובה על הזכאות.

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

מתי לבחור בשליפה, בהנחיה או באימון נוסף

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

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

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

לאילו משימות עסקיות כדאי לבחון חיבור למאגר ידע

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

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

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

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

איך מכינים מסמכים בעברית ושומרים על עדכניות

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

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

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

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

מה לבדוק בהרשאות ובטיפול במסמכים רגישים

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

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

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

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

מה מרכיב את העלות ומה לבקש בהצעת עבודה

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

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

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

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

איך לבצע ניסוי קבלה לפני שמרחיבים את השימוש

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

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

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

שאלות נפוצות

האם rag דורש אימון מחדש של מודל הבינה המלאכותית?

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

האם חייבים מסד נתונים וקטורי כדי לבנות מערכת rag?

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

האם rag מונע הזיות ותשובות שגויות?

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

איך יודעים שמערכת rag עובדת היטב בעברית?

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