מעבר לצ'אטבוט: איפה מודלי שפה באמת חוסכים עבודה

הבעיה היא לא שאין מידע, אלא שאי אפשר למצוא אותו

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

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

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

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

ממסמכים לתוך מערכות, בלי הקלדה

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

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

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

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

סוכן שמכין, אדם שמאשר

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

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

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

איפה הנתונים באמת יושבים

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

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

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

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

איך יודעים שזה עובד, וכמה זה עולה

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

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

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