תהליכי עבודה מרובי-סוכנים (multi-agent workflows) שולטים ב-GitHub כרגע. מפתחים מחברים יחד מודלי שפה גדולים, מקצים לכל סוכן התמחות צרה, ומנהלים (orchestrating) את הפלטים שלהם כדי לטפל במשימות שאף מודל בודד לא יכול היה לטפל בהן לבדו. התוצאות יכולות להיות מרשימות. סוכן אחד חוקר, אחר מנסח, שלישי בודק עובדות, ורביעי מעצב את הפלט הסופי. אך מתחת לכל התיאום הזה אורבת תלות שבירה. אם השלב הראשון ממש — הפיכת קלט אנושי להוראות שניתן לקרוא על ידי מכונה — איטי או לא מדויק, כל השרשרת קורסת. סוכן שנמצא בהמשך השרשרת (downstream) לא יכול לתקן "זבל". הוא יכול רק להפיץ אותו.

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

החוליה החלשה ביותר בשרשרת

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

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

domux תוכנן להיות השכבה הזו. הוא מקבל שפה אנושית מבולגנת והופך אותה לסכימה (schema) נקייה שסוכנים בהמשך השרשרת יכולים להתייחס אליה כאמת קרקעית (ground truth).

מהירות, מבנה ודיוק

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

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

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

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

כך נראה הפלט בפועל. כאשר המודל מעבד פקודה, הוא מחזיר רשומה מופרדת בתו '|' (pipe-delimited):

action|device|attribute|value|unit|room|floor
turnOn|light|brightness|80|percent|living room|ground floor

הפורמט הזה מכוון. טקסט מופרד ב-pipe הוא קל מאוד לניתוח בכל שפת תכנות ללא תלויות כבדות. הוא נמנע מניפוח של JSON ומשיהוי של סריאליזציה מקוננת. סוכן תאורה יכול לקרוא את עמודות ה-action וה-device ולפעול מיידית. סוכן רישום יכול לחלץ את ה-room וה-floor מבלי להריץ שלב הסקה (inference pass) נוסף. המבנה מסיר עמימות מראש.

התמודדות עם כוונות אנושיות מבולגנות

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