למה מודלי LLM זקוקים למאגר ידע
RAG ב-AI קולי — מודלי שפה גדולים מסוגלים באופן יוצא דופן להבין וליצור שפה אנושית, אך יש להם מגבלה מהותית שהופכת אותם לבלתי מספיקים בפני עצמם עבור AI קולי עסקי: הם לא יודעים שום דבר ספציפי על העסק שלכם. GPT-4 יודע מהו ביטוח באופן כללי, אך הוא אינו מכיר את התנאים הספציפיים של הפוליסות שלכם. Claude מבין את המושג של הזמנת מקומות במסעדה, אך אינו יכול לבדוק אם במסעדה שלכם יש שולחן פנוי בשבת בשבע בערב. Gemini יכול לדון בקביעת תורים רפואיים באופן מופשט, אך אין לו מושג אילו רופאים עובדים במרפאה שלכם או איך נראית הזמינות שלהם השבוע. כדי שנציג AI קולי יהיה שימושי בהקשר עסקי, הוא צריך גישה למידע עסקי עדכני וספציפי – וכאן בדיוק RAG, יצירה מועשרת באחזור, הופך צ’אטבוט חכם לכלי עסקי פונקציונלי.
RAG פועל על ידי הוספת שלב אחזור לפני שמודל השפה מייצר את תגובתו. כאשר מתקשר שואל שאלה, המערכת תחילה מחפשת במאגר ידע של מידע עסקי ספציפי כדי למצוא תוכן רלוונטי לשאלה. תוכן זה שאוחזר נכלל לאחר מכן בהנחיה שנשלחת ל-LLM, לצד היסטוריית השיחה והוראות המערכת. ה-LLM מייצר את תגובתו על בסיס הקשר מועשר זה, תוך הסתמכות על המידע העסקי שאוחזר במקום נתוני האימון הכלליים שלו. התוצאה היא תגובה המשלבת את שטף השפה הטבעית של ה-LLM עם המידע הספציפי והעדכני של העסק – ה-AI מדבר בטבעיות אך אומר דברים שמדויקים עבור העסק שלכם.
כיצד חיפוש וקטורי מניע את ה-RAG
שלב האחזור ב-RAG מסתמך על טכנולוגיה שנקראת חיפוש וקטורי, שראויה להסבר משום שהיא שונה מהותית מחיפוש מילות מפתח מסורתי, והבנת ההבדל מאירה הן את הכוח והן את המגבלות של AI קולי מבוסס RAG. חיפוש מסורתי מתאים מילות מפתח – אם מחפשים “מדיניות החזרות”, הוא מוצא מסמכים שמכילים את המילים המדויקות הללו. חיפוש וקטורי מתאים משמעות – אם מחפשים “מדיניות החזרות”, הוא מוצא גם מסמכים על “תהליך החלפה”, “זכאות להחזר כספי” ו”החזרת פריטים” מכיוון שמושגים אלו קשורים סמנטית גם אם הם משתמשים במילים שונות. זה קריטי עבור AI קולי מכיוון שמתקשרים מביעים את אותה שאלה בדרכים אינספור: “אפשר להחזיר את זה?”, “מה חלון ההחזרה שלכם?”, “אני צריך להחליף משהו” ו”אפשר לקבל החזר על זה?” – כולן שואלות בעצם את אותו הדבר, וחיפוש וקטורי מזהה זאת.
חיפוש וקטורי פועל על ידי המרת טקסט לייצוגים מתמטיים הנקראים embeddings – מערכי מספרים שלוכדים את משמעות הטקסט במרחב רב-ממדי. משמעויות דומות מפיקות embeddings דומים, מה שאומר שמציאת רשומות רלוונטיות במאגר הידע היא עניין של חישוב אילו רשומות קרובות ביותר ל-embedding של השאלה. חישוב זה מתרחש באלפיות שנייה באמצעות מבני נתונים מתמחים (כמו גרפי HNSW) המאוחסנים במסדי נתונים וקטוריים כגון Qdrant, Pinecone או Weaviate. Kolivri משתמשת ב-Qdrant כמאגר הוקטורי שלה, עם שירות embedding שמעבד רשומות מאגר ידע ממקורות שונים – קבצים שהועלו, Google Drive, SharePoint, Salesforce ומערכות מחוברות אחרות – ומאחסן את הייצוגים הוקטוריים שלהם לאחזור מהיר. כאשר מתקשר שואל שאלה, המערכת ממירה את השאלה ל-embedding, מחפשת ב-Qdrant את רשומות הידע הדומות ביותר, ומעבירה רשומות אלו ל-LLM כדי לנסח תגובה.
לגרום ל-RAG לעבוד היטב בפרקטיקה
התאוריה של RAG ישירה, אך לגרום לו לעבוד היטב בפריסת AI קולי בסביבת ייצור דורש תשומת לב למספר אתגרים מעשיים. הראשון הוא גודל הפיסקה – כיצד מחלקים את מסמכי המקור לרשומות במאגר הידע. אם הפיסקאות גדולות מדי, התוכן שאוחזר עשוי להכיל הרבה מידע לא רלוונטי לצד החלק הרלוונטי, מה שמפזר את מיקוד ה-LLM ועלול לגרום לו לכלול פרטים שגויים בתגובתו. אם הפיסקאות קטנות מדי, הקשר חשוב עלול להתפצל בין רשומות מרובות ולא להיות מאוחזר יחד. גודל הפיסקה האופטימלי תלוי באופי התוכן שלכם, אך נקודת מוצא טובה היא פסקאות או חלקים לוגיים של 200-500 מילים כל אחד, עם חפיפה מסוימת בין פיסקאות סמוכות כדי לשמר הקשר בגבולות.
האתגר השני הוא שמירה על עדכניות מאגר הידע. RAG טוב רק כמו המידע שהוא מאחזר, ומידע מיושן מפיק תגובות מיושנות. אם שעות הפעילות שלכם משתנות לעונת החגים אך מאגר הידע עדיין מכיל את השעות הרגילות, ה-AI ימסור למתקשרים מידע שגוי בביטחון מלא. אם מוצר חדש נוסף לקטלוג שלכם אך לא למאגר הידע, ה-AI יכחיש את קיומו כשמתקשרים ישאלו עליו. הפתרון הוא לחבר את מאגר הידע ישירות למערכות מקור האמת שלכם במקום לתחזק אותו כמאגר נפרד שמעודכן ידנית. מערכת המחברים של Kolivri מסנכרנת ידע מ-Google Drive, OneDrive, SharePoint, Salesforce, Monday.com ו-SAP, ומעדכנת אוטומטית את מאגר הוקטורים כאשר מסמכי המקור משתנים. Retell AI מציעה סנכרון אוטומטי למאגר הידע שלה. ככל שהחיבור בין הנתונים העסקיים החיים לבין מאגר הידע של ה-AI הדוק יותר, כך תגובות ה-AI מדויקות ואמינות יותר.
האתגר השלישי הוא טיפול בשאלות שחורגות ממאגר הידע. ללא קשר למידת המקיפות של מאגר הידע שלכם, מתקשרים ישאלו מדי פעם שאלות שהוא אינו מכסה. התנהגות ה-AI במצבים אלו היא קריטית – עליו להודות שאין ברשותו את המידע הספציפי במקום לייצר תשובה מהזיה, ולהציע חלופה אלגנטית כמו העברה לנציג אנושי או הצעה לברר ולחזור עם תשובה. התנהגות “כישלון אלגנטי” זו חייבת להיות מוגדרת באופן מפורש, כי מודלי LLM נוטים מטבעם לייצר תגובה לכל שאלה, וללא הוראות מפורשות להפך, הם ייצרו תשובות שנשמעות סבירות אך עלולות להיות שגויות כאשר מאגר הידע ריק מתשובה. השילוב של RAG למידע ידוע וכישלון מבוקר למידע לא ידוע מייצר נציג AI שהוא גם מועיל וגם אמין – שתי תכונות שחייבות להתקיים יחד כדי ש-AI קולי יצליח בהקשר עסקי.
