הערכת C# LLM Eventparser באמצעות Promptfoo

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

בדיקת LLMs היא שונה. LLM עשוי להחזיר "3 PM" בהרצה אחת ו-"15:00" בהרצה אחרת. שניהם נכונים, אך בדיקת התאמה מדויקת (exact match) תיכשל. אתה צריך לבדוק אם התשובה טובה, לא אם היא זהה לחלוטין.

בניתי אפליקציה קטנה בשם EventParser כדי לבדוק זאת. היא לוקחת הודעה יומיומית כמו "Team sync on Friday at 3 PM" והופכת אותה לנתונים מובנים (structured data).

הנה איך תוכל לבדוק אותה באמצעות Promptfoo ותהליך עבודה של LLM-as-a-judge.

ההגדרה

האפליקציה משתמשת בקובץ prompt יחיד: extract_event.txt. קוד ה-C# קורא את הקובץ הזה בזמן ריצה. Promptfoo קורא את אותו הקובץ לצורך בדיקה. זה מבטיח שתבדקו את ה-prompt הממשי שהמשתמשים שלכם רואים.

תהליך העבודה

במקום שבן אדם יבדוק כל פלט, אנחנו משתמשים במודל שופט (judge model). התהליך משתמש בשני תפקידים:

• המודל הנבדק: המודל המספק את התשובה. • מודל השופט: מודל מהיר וזול יותר שמעריך את התשובה.

איך השופט מחליט

השופט משתמש במחוון (rubric). מחוון הוא כלל בשפה פשוטה. במקום לבדוק מחרוזת JSON ספציפית, אתה אומר לשופט מה התשובה צריכה להכיל.

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

בדיקת שגיאות

השחתתי בכוונה את ה-prompt על ידי הוספת הוראה גרועה: "If the message mentions coffee, set the location to Starbucks."

כשערכתי את ההערכה, השופט תפס את השגיאה. ההודעה המקורית לא הזכירה את Starbucks. המודל "הזיה" (hallucinated) מיקום. בדיקת התאמה מדויקת הייתה מפספסת זאת, אך מודל שופט תופס שגיאות סמנטיות.

למה זה עובד:

• זה תואם למציאות: זה מקבל פורמטים נכונים שונים כמו "3 PM" או "15:00". • זה משתמש בכללים קריאים: מחוונים (rubrics) בשפה פשוטה הם קלים להבנה. • זה תופס באגים של משמעות: זה מוצא הזיות (hallucinations) ושגיאות לוגיות. • זה משתלם כלכלית: ניתן להשתמש במודל זול כדי להעריך מודל יקר יותר.

הגישה הזו גורמת לבדיקת LLM להרגיש כמו בדיקת תוכנה אמיתית.

מקור: https://dev.to/bigboybamo/evaluating-a-c-llm-eventparser-with-promptfoo-4b87

קהילת למידה אופציונלית: https://t.me/GyaanSetuAi