המערכת הישנה של החברה יודעת הכול. הבעיה היא שאף אחד לא יכול לשאול אותה

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

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

זה החור ש-RAG עוזר לסגור, ואפשר לעשות את זה בלי להחליף מערכת.

מערכת ישנה היא יותר מקוד

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

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

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

מה זה RAG, בלי מילים גבוהות

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

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

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

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

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

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

מה משתנה ביום-יום

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

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

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

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

איפה זה לא עוזר

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

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

הזהירות שאי אפשר לדלג עליה

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

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

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

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

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

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

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

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

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

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

איך אנחנו עושים את זה ב-360 Brave

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

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

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

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