הערכת מערכת AI

מתקדמים בסדרת הפוסטים של המקרים הנפוצים בקרב צוותים שמממשים מערכות AI בארגונים, לוקאלית ללא שירותי SaaS ו-APIים חיצוניים באמצעות Open Source והכול On Premises, בין אם על הברזלים של הארגון או בענן של הארגון. הבעיות נפוצות והפתרונות? פתרונות בית ספר... והפעם... אחרי שהכוכבים בארגון פיתחו ולדעתם הכול בסדר ואין שום בעיות (גם אם אין סקייל, גם אם אין משמעות לעלויות, גם אם אין שום מתודולוגיה להערכת התוצאות ואפילו אין הגדרה לאיכות התוצאות) כי "לי זה נראה בסדר ואנשים אומרים לי שזה נראה טוב...", אז אחרי השלב הזה מגיעה ההתפכחות ומבינים שצריכים למפות משאבים, לנטר ניצול משאבים, צריכים לנטר פעילות המערכת על חלקיה וצינורותיה, לנטר בקשות ולנטר תשובות ולנטר את התהליכים שקורים בין לבין ולהשוות הכול אל מול ציפיות:

ציפיות לאיכות, ציפיות לעמידה בזמנים, ציפיה לזמינות משאבים, ציפייה ל-up time, ציפייה ליכולת התאוששות, ציפייה ל-ROI, ... והיד עוד נטויה.

במהלך שיחות העבודה, הודגש כי האתגר התובעני ביותר שמולו ניצבים מפתחי המערכת הוא הצורך הנואש במדדים ברורים ושיטות לבחינת איכות המערכת. המשתתפים הדגישו שללא יצירת סט מדדים ברור, אי אפשר באמת לדעת האם שינויים שבוצעו בתהליך הצ'אנקינג, בסכימת הפרסינג או בפרמטרים של חיפוש הוקטורים אכן קידמו את המערכת או שמא הרעו אותה. הקבוצה מחפשת אוטומציה של QA שניתן להטמיע תוך דגש על הערכת מערכות מורכבות בסקאלות ארגוניות. אז לפעמים זאת הבנה מאוחרת של המפתחים ולפעמים זאת דרישה מההנהלה שרוצה להבין מה קורה ואיך מגיעים ליציבות ואיך אחרי שברור אובייקטיבית (אבל איך?) שהמערכת עובדת ועובדת נכון אפשר לגרום לה גם לעבוד יעיל ולתת ROI, כי בלי שתתן ערך... אין משמעות ובלי שהערך מצדיק את עצמו ב-ROI אז זה אינו בר קיימא...

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

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

1. הערכה אובייקטיבית וכמותית באמצעות RAGAS (Retrieval Augmented Generation Assessment): מסגרת זו מהווה כיום את הסטנדרט דה-פקטו להערכת מערכות RAG. במקום להזדקק למתייגים אנושיים יקרים, RAGAS פועלת בשיטת LLM-as-a-Judge. היא סוקרת מגוון פרמטרים מרכזיים ומעניקה לכל תהליך ציון מספרי מנותק מהקשר. המדדים המרכזיים הם:

• נאמנות והלימה (Faithfulness / Groundedness): מודדת את עקרון חוסר-ההזיות. המסגרת לוקחת את התשובה הסופית, מפרקת אותה להצהרות לוגיות נפרדות, ומוודאת שכל טענה שמודל השפה טען נגזרת בצורה ישירה ובלעדית מקבוצת הצ'אנקים שהוחזרו בחיפוש. ציון חסר מעיד על נטיית המודל להזות ולדמיין פרטים.

• רלוונטיות התשובה (Answer Relevance): בוחנת עד כמה התשובה קוהרנטית לשאלה המקורית של המשתמש, מבלי להכיל תוספות טקסט לא קשורות או פירוט יתר סתמי.

• דיוק ההקשר (Context Precision): מודד את איכות מערכת השליפה הווקטורית. מדד זה בודק האם הצ'אנקים הרלוונטיים באמת לפתרון התשובה דורגו ברמה הגבוהה ביותר מתוך כל הרשימה שהוחזרה.

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

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

סוגיה מרכזית אחת שעשויה למנוע את הצלחת המהלך היא מחסום השפה. מסגרת RAGAS מכוילת באנגלית, והפרומפטים הפנימיים שבהם שופט ה-LLM מודד את ההצלחות מוטמעים באנגלית ומצפים למבנה טקסטואלי אנגלי. הרצת בדיקה על צ'אנקים ופלט של טקסטים בעברית בסביבת הארגון תוביל לשגיאות תרגום ולהורדת ציונים שגויה. חובה להשתמש ביכולות ההתאמה לשפות אחרות. באמצעות שימוש בפונקציה ragas.adapt וציון שפת היעד, המערכת תבצע תרגום אוטומטי של הוראות ההפעלה וההדגמות, Few-shot Demonstrations, שיושבות בתוך ליבת הפרומפטים, ובכך תתאים ותכייל את סולם המדדים לניתוח טקסט עברי מדויק.

2. עקיבה ותצפית עמוקה (Tracing & Observability) באמצעות Phoenix: בעוד ש-RAGAS מספק ציון מאקרו לתוצאה, ספריות ניטור מסוג Arize Phoenix, או Langfuse, משמשות כמערכת רנטגן שמציגה את התהליך שעברו הנתונים בשלבי השאילתה. Phoenix מנצלת את העובדה שהארכיטקטורה באה במבנה של שרשראות עיבוד, והיא אוספת שכבות של לוגים מכל תחנה ותחנה. במערך זה ניתן לראות בדיוק כמה מילי-שניות צרך סוכן ה-Search, איזו פקודה נמסרה למסד הנתונים, מהו תוכן המטא-דאטה המדויק שנשמר בזמן הפעולה, וכמה עלתה פעולת השאיבה במכסת הטוקנים. מעבר לתיעוד השקוף, המערכת מאפשרת להציג את התהליכים במפות פיזור של מרחב הוקטורים, לחשוף אשכולות ספציפיים שסובלים מביצועים ירודים ולהצביע באופן נקודתי על המקור שבו צ'אנקינג מתחיל להיכשל.

יש לבנות מנגנון תהליכי שמריץ את כלי ה-RAGAS בכל פעם שמתבצע שינוי קוד ורצוי גם לבצע A/B Testing.

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

הערכת מערכת AI

צריכים עזרה עם AI/GenAI/AgenticAI/AI Platform ועם מעבר מהוכחת יכולת לעבודה בסקייל מלא באנטרפרייז? 

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

רוצים מחקר אלגוריתמי יישומי?  

הבה נדבר!

שלמה יונה,

מייסד ומדען ראשי, 

מתמטיקאי מחקר ופיתוח בע"מ

053-7326360

shlomo.yona@mathematic.ai

https://mathematic.ai

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

A technical deep dive about Mathematic.ai