Adjudicator: תיקון תוויות רועשות באמצעות מועצת סוכני LLM המונחית על ידי גרף ידע (KG)

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

מבוא

המאמר עוסק בבעיה בסיסית בלמידת מכונה מונחית – רגישות חזקה לאיכות התוויות. במערכות ייצור ותעשייה (high-stakes industrial applications), תוויות רועשות עלולות לגרום לתוצאות מסוכנות או יקרות. בעידן שבו נעשה שימוש גובר ב־LLM ובתיוג אוטומטי בקנה מידה גדול, הבעיה רק מחריפה. המחברים טוענים שמערכות קיימות לתיקון רעש בתוויות תלויות לרוב במודלים סטטיסטיים או ברוב קולות פשוט, ואינן מנצלות ידע סמנטי עמוק או יכולת נימוק של מודלים גדולים.

Adjudicator מוצע כמערכת "שופט-על" (adjudication system) שמטרתה: (1) לזהות ולתקן תוויות שגויות, (2) לנמק את ההחלטות באופן מפורש, ו-(3) לפעול כמודול עצמאי שניתן לחבר לכל צינור נתונים.

עבודות קשורות

המחברים סוקרים שלושה קווי מחקר עיקריים:

1. למידה עם תוויות רועשות – גישות סטטיסטיות קלאסיות כמו reweighting, חסינות לאאוטליירים, מודלים גנרטיביים לרעש ועוד. אלה לרוב מניחים מודל ספציפי לרעש ואינם נותנים הסבירוּת אנושית.
2. שימוש ב־LLM לאיכות נתונים – לדוגמה מודלים שבודקים עקביות טקסטואלית או מייצרים תוויות ראשוניות, אך בדרך כלל מודל יחיד ולא מועצה רב־סוכנית, וללא שימוש מפורש בגרף ידע.
3. גרפי ידע (KG) ולמידה סמנטית – שימוש ב־KG לשיפור הבנה סמנטית (למשל ב־NLP ורפואה), אך לא כחלק אינטגרלי מתהליך תיקון תוויות באמצעות LLM.

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

הגדרת הבעיה

ניתן מערך נתונים מסומן ( D = {(x_i, y_i)} ) שבו (x_i) הוא פריט (למשל טקסט תעשייתי, תיאור תקלה, מדדים) ו-(y_i) תווית שמייצגת קטגוריית אירוע, כשל, סטטוס וכו'. חלק מהתוויות רועשות: שגויות לחלוטין, לא עקביות עם ההקשר, או חסרות חלק ממידע התווית (למשל בחסר רכיבי מבנה היררכי).

המערכת אמורה, עבור כל פריט, להחזיר (\hat{y}_i) – תווית מתוקנת – יחד עם נימוק טקסטואלי והערכה על סוג השגיאה המקורית (אין טעות / טעות סמנטית / טעות מבנית / Complete Recall וכו').

ארכיטקטורה כללית של Adjudicator

Adjudicator בנוי מארבעה רכיבים מרכזיים:

1. Knowledge Graph (KG) – גרף דינמי המייצג ישויות, יחסים, היררכיות קטגוריות, תתי־סוגים ומטא־נתונים על הדומיין ועל הנתונים.
2. Council of LLM Agents – קבוצת סוכנים (agents) מבוססי מודלי שפה גדולים, שכל אחד קיבל פרומפט ותפקיד ייעודיים (למשל: "מומחה דומיין", "בקר עקביות", "מבקר מבנה", "בודק ריקול מלא").
3. Adjudication Logic – לוגיקה שמרכזת את חוות הדעת מהסוכנים, מזהה סוגי טעויות, מחליטה על התווית הסופית, ויוצרת הסבר.
4. Interface לצינור נתונים – ממשק API או רכיב תשתיתי שמאפשר להפעיל את Adjudicator על זרם נתונים, ולשמור את התוויות המתוקנות.

גרף הידע (Knowledge Graph)

המחברים בונים KG דינמי מדומיין Allenoise (מערך נתונים תקני לנויז בתוויות). בגרף זה:

• צמתים מייצגים קטגוריות אירועים, תתי־קטגוריות, תהליכים תעשייתיים, סיבות ותוצאות, וגם דוגמאות טיפוסיות.
• קשתות מייצגות יחסים כמו "תת-סוג של", "קשור ל", "גורם ל", "חלק מ" ועוד.
• צמתים נוספים מייצגים חוקים סמנטיים (constraints) כגון: "אם תקלה מסוג X, אז חייב להופיע תת־סוג Y".

ה-KG משמש את הסוכנים ב:

• בדיקת עקביות בין התווית לבין התיאור.
• זיהוי קטגוריות קרובות (Neighbourhood Search) כדי להציע תיקון מינימלי.
• איתור חלקים חסרים במבנה תווית היררכי.

מועצת סוכני ה־LLM

במערכת מוגדרים מספר סוכנים, כאשר כל אחד:

• מקבל בהקשר (context) את הדוגמה (טקסט, מדדים וכו'), התווית הנוכחית ואת המידע הרלוונטי מה-KG.
• פועל תחת פרומפט ייעודי שמגדיר תפקיד (role) וכללי החלטה.
• מחזיר תווית מוצעת, סוג טעות (אם יש), והסבר קצר.

דוגמאות לתפקידים:

1. Domain Expert Agent – ממפה את תיאור האירוע לקטגוריית ה־KG המתאימה ביותר.
2. Structure Validator Agent – בודק שהמבנה ההיררכי של התווית תואם את החוקים ב-KG.
3. Semantic Consistency Agent – בוחן האם מילים ומושגים בתיאור מתאימים לקטגוריה (למשל, אזכור של כשל חשמלי בתווית מכנית בלבד).
4. Complete Recall Agent – מזהה האם חסרים רכיבי מידע שמוגדרים כנדרשים ב-KG עבור אותה קטגוריה (סוג טעות המכונה Complete Recall ב-Allenoise).

כל הסוכנים משתמשים ב-LLM (כגון GPT/An LLM מודרני) עם prompt engineering מדויק, כך שהתגובות יהיו גם מובְנות וגם מועילות ללוגיקת האיחוד.

לוגיקת האיחוד (Adjudication Logic)

לאחר שכל סוכן מחזיר את פלטו, Adjudicator מפעיל לוגיקה רבת שלבים:

1. זיהוי טעות / ללא טעות – אם רוב הסוכנים מסכימים שהתווית עקבית עם ה-KG ואין סתירות, היא נשמרת.
2. סיווג סוג הטעות – אם יש אי־התאמות, המערכת מסווגת את הטעות לאחת מהקטגוריות (למשל semantic mismatch, structural error, missing sub-type, complete recall וכו'), לפי אותות מהסוכנים.
3. בחירת תווית חדשה – חיפוש ב-KG אחר קטגוריות קרובות; שקלול הצעות הסוכנים; בחירה בתווית שממזערת "מרחק" בגרף ונתמכת על ידי ההסברים.
4. יצירת נימוק – ה־LLM משמש גם ליצירת הסבר סדור: מה הייתה התווית המקורית, מה הסתירה, כיצד ה-KG מורה על תיקון אחר, ומה התווית הסופית.

מערך הנתונים וניסוי

הערכת המערכת מתבצעת על תת־קבוצה בת 1,000 דוגמאות מאוזנות מתוך מערך Allenoise benchmark:

• כל דוגמה כוללת טקסט אירוע תעשייתי ותווית (לעתים שגויה) מתוך סט של קטגוריות.
• התת־קבוצה בנויה כך שיש ייצוג לארבע העמודות המרכזיות של סוגי טעות ב-Allenoise (לפי הגדרת המחברים, כולל Complete Recall וקטגוריות נוספות).

שלושה קווי־בסיס מושווים:

1. Single-LLM Baseline – מודל שפה גדול אחד שמקבל את הטקסט והתווית הנוכחית ומחליט אם לשנות אותה, ללא KG וללא מועצה רב־סוכנית.
2. Non-KG Council – מועצת LLM-ים בדומה ל-Adjudicator, אך ללא שימוש מפורש בגרף הידע (כלומר, רק הקשר טקסטואלי).
3. Adjudicator (KG-informed Council) – הגרסה המלאה: מועצה רב־סוכנית עם KG ו-Adjudication Logic.

מדדי הערכה

הערכת המודלים נעשית באמצעות F1-score על משימת תיקון תוויות:

• תווית נכונה – אם המערכת מחזירה את התווית האמתית של הדוגמה ב-Allenoise.
• F1 כולל – ממוצע מאוזן בין Precision ל-Recall על פני כל הקטגוריות.

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

תוצאות אמפיריות

התוצאות המרכזיות המופיעות במאמר:

• Adjudicator (KG Council) השיג F1 כולל של 0.99.
• Non-KG Council השיג F1 של 0.59.
• Single-LLM Baseline השיג F1 של 0.48.

כלומר, השימוש במועצה רב־סוכנית ללא KG מוסיף שיפור ניכר לעומת מודל יחיד (0.48 → 0.59), אך הוספת KG ועוד לוגיקת איחוד מעלה את הדיוק כמעט למושלם (0.99).

בניתוח לפי סוגי טעויות המחברים מדווחים על:

• שיפור דרמטי בקטגוריית Complete Recall – Adjudicator מצליח לזהות מצבים שבהם חלק מן המידע ההכרחי לפי KG חסר בתווית, ולהוסיף את תת־הקטגוריות המתאימות.
• הקטנת שגיאות מבניות (למשל, אי־התאמה בין סוג־על לתת־סוג) הודות לחוקי ההיררכיה ב-KG.
• הפחתת טעויות סמנטיות, שבהן LLM יחיד נוטה לבחור קטגוריה קרובה אך שגויה; השימוש בשכני־גרף (neighbourhood) ובקונסנזוס בין סוכנים מצמצם את הבעיה.

ניתוח ושיח

המחברים דנים בסיבות ליתרון של Adjudicator:

• הפרדת תפקידים בסוכנים – כל סוכן מתמקד בזווית אחרת של הבעיה (הקשר, מבנה, שלמות מידע), מה שמקטין את הנטייה של מודל יחיד "להחליט מהר".
• ידע סמנטי עשיר מה-KG – הגרף מצמצם מרחב חיפוש קטגוריות סביר, ולכן מונע מה-LLM לסטות לקטגוריות לא רלוונטיות.
• Adjudication Logic – המכאניזם לוקח ברצינות אי־הסכמות בין סוכנים ומשתמש בהן כסימן לבעיה, במקום להסתמך רק על אמת מידה סטטיסטית.

עם זאת, המחברים מציינים מגבלות:

• בניית KG איכותי דורשת מומחי דומיין ועבודה ידנית/חצי־אוטומטית.
• המערכת נבחנה על דומיין אחד (Allenoise); יש לבחון כללות (generalization) לדומיינים אחרים.
• עלות חישובית: מועצה רב־סוכנית עם LLM גדולים אינה זולה, ולכן נדרשת אופטימיזציה בפרודקשן (דגימה, קאשינג, או שימוש ב-LLM זולים יותר בשלבים מסוימים).

מסקנות והמלצות להמשך

Adjudicator מציע מסגרת חדשה ומוסברת לתיקון רעש בתוויות, המשלבת:

• ידע מבני (KG),
• קבוצה של LLM-ים בעלי תפקידים שונים,
• וכן מנגנון איחוד שמגדיר ומזהה סוגי שגיאות ספציפיים.

הממצאים מראים שניתן להגיע לשיפור עצום בדיוק התוויות (F1=0.99) בהשוואה לגישות מבוססות LLM ללא KG או מודל יחיד. המחברים מציעים מספר כיוונים להמשך:

• אוטומציה מתקדמת יותר של בניית KG מדומיינים חדשים.
• הרחבת המערכת לדאטה מולטי־מודלי (טקסט + תמונה/סיגנלים).
• שילוב Adjudicator כשלב קבוע ב־MLOps pipelines, למשל כ"גייט" לפני אימון מודלים או לפני פריסה (deployment) של מודלים חדשים.

הם טוענים כי מסגרת זו יכולה לשמש כ-proof-of-concept לשימוש ב-LLM + KG לצורך אימות נתונים בסביבות תעשייתיות ממשיות, תוך שמירה על שקיפות ונימוק אנושי.