מה על אדם לאשר בהזמנה קולית מבוססת בינה מלאכותית?
בדוגמה סינתטית של הזמנה קולית, אסימון דיבור חוזר הופך לשלושה המבורגרים. המערכת מציעה תיקון סביר: לשנות את הכמות לאחד. עבור צוות מוצר, השאלה הקשה היא מה מתרחש בין אותה הצעה לבין ההרשאה לשלוח את ההזמנה. החלפה שנראית מועילה עדיין לא ביססה את מה שהלקוח רצה.
גילוי נאות: הדוגמאות שלהלן הן הזמנות סינתטיות ב-Drive-Thru Order Firewall של Veriprajna, המאמת פלט ספקים מובנה לפני תצוגת מטבח מדומה. הוא אינו מזהה אודיו אמיתי ואינו שולח הזמנות למערכת נקודת המכירה (POS) של מסעדה.
אני מעוניין שאישור אנושי יפתור אי-ודאות ספציפית. לשם כך נדרשת הפרדה בין שלושה שיקולים: למה התכוון הלקוח, האם הזמנה זו מותרת על פי מדיניות המסעדה, והאם ההזמנה המוצעת המדויקת עומדת בבדיקות. שילוב שיקולים אלה בלחצן אישור יחיד מקשה על ההבנה מה המשמעות של אישור.
תיקון הוא השערה לגבי כוונה
מתקן הבדיקה עבור אסימון חוזר מכיל תמלול מקוטע, שלושה אסימונים גולמיים זהים וכמות של שלושה המבורגרים. ציון המהימנות שסופק עבורו הוא 0.71, מתחת לסף הבדיקה שהוגדר שהוא 0.85. לכן כללי החזרתיות ומהימנות נמוכה מעבירים את ההזמנה למצב HOLD. כלל החזרתיות מציע המבורגר אחד.
אחד הוא מועמד סביר להצגה בפני מפעיל. אין בו הוכחה לכמות המיועדת. האסימון החוזר עשוי להסביר את הפלט המובנה, אך כלל המזהה חזרתיות אינו יכול לשאול את הלקוח לכוונתו. החלפה אוטומטית של שלושה באחד תחליף פרשנות מפוקפקת בפרשנות בלתי מאומתת.
דחיית ההזמנה כרוכה בעלות שונה. היא מתייחסת לפרשנות הדורשת הבהרה כאילו לא ניתן לשחזר שום הזמנה מקובלת. אני מעדיף השהיה (hold) בשלב זה מכיוון שהיא שומרת על הראיות המקוריות ומשאירה את הכמות המיועדת פתוחה. בתכנון סביבת ייצור, על האישור להתייחס לכמות עצמה, ולא לדרוש ממפעיל לתת תוקף למהימנות הכללית של המערכת.
זוהי עמדה תכנונית, ולא תהליך עבודה שלם באפליקציה זו. לחצני Approve Correction ו-Escalate בהדגמה משנים את התוויות שלהם ומשביתים את עצמם. הם אינם מגישים מחדש, אינם משחררים, אינם מתעדים פעולה אנושית ואינם משנים את הקבלה. צוות ייצור עדיין יצטרך לבנות את השיחה ואת שינוי המצב שמעניק לתשובה זו השפעה ממשית.
בקשה חריגה עשויה להיות מובנת במדויק
פרשנות היא רק סיבה אחת להשהיה. מתקן סינתטי נוסף מכיל 18,000 כוסות מים עם ציון מהימנות שסופק של 0.97 ומחיר תפריט אפס ללקוח. הכמות חורגת ממגבלת המים המוגדרת של שמונה, ולכן השער עוצר אותה. לא ציון הקלט הגבוה ולא מחיר האפס עונים על השאלה האם כמות זו רשאית להמשיך. הציון הוא קלט מהמתקן, ולא הסתברות מכוילת להרשאה.
כמות קיצונית מקלה על הבחנה זו. החלטת המוצר הקשה יותר נוגעת לכמות בלתי שגרתית שהלקוח באמת מעוניין בה. שקלו הזמנה קבוצתית היפותטית החורגת מהמגבלה האוטומטית הרגילה של מסעדה. אם הלקוח מאשר את המספר, ייתכן שהפרשנות תיושב בעוד שההרשאה תישאר פתוחה. צמצומה למגבלה הרגילה ישנה את הבקשה. דחייתה על הסף עלולה להשליך ביקוש לגיטימי.
אני מעדיף להשתמש בסף חריגה כדי להפעיל בדיקה כאשר המדיניות מתירה חריגה. לאחר מכן על המפעיל להחליט האם המסעדה יכולה לקבל את ההזמנה המאושרת, ייתכן שבאמצעות נתיב מורשה בנפרד. סף שנועד להגביל הגשה אוטומטית אינו אמור להפוך בשקט לכלל המשכתב את כוונת הלקוח.
הדבר גובה תשומת לב. סף אוטומטי רופף יותר מאפשר ליותר הזמנות חריגות לעבור; סף מחמיר יותר מייצר יותר עבודת בדיקה. ההדגמה אינה יכולה לבחור את האיזון הזה עבור מסעדה. המגבלות שלה נובעות מהיסטוריית הזמנות סינתטית התחלתית, והתפלגות מתארת את מה שהופיע בהיסטוריה זו. היא אינה קובעת את הקיבולת האמיתית של מיקום מסוים או את התדירות שבה תתרחש הזמנה קבוצתית לגיטימית. לפני אימוץ מדיניות כזו, צוות יזדקק לראיות לגבי חריגות מקובלות ולנטל המעשי של אישורן.
האישור חייב לחול במדויק על ההזמנה הבאה הספציפית
אפילו תיקון מאושר יכול להישאר לא תקף. מתקן הבדיקה בנפח גבוה מתחיל ב-40 מנות צ'יפס ו-40 משקאות מוגזים. כלל הכמות מציע להפחית את הצ'יפס לארבע, אך משאיר 40 משקאות מוגזים ללא שינוי. מגבלת המשקאות המוגזים היא שישה. לפיכך, הסכמה שארבע מנות צ'יפס היא ההחלפה הנכונה תשאיר הפרת כמות נוספת בהזמנה המוצעת.
זו הסיבה שאני שומר על הפרדה בין אישור לאימות. אישור הלקוח מתייחס לכוונה. החלטת החריגה של מפעיל מורשה מתייחסת למדיניות. בדיקת ההזמנה המוצעת השלמה בודקת האם העסקה הבאה עומדת בכללים החלים. לא ניתן להסיק בבטחה אף אחת מהתשובות הללו מהאחרות.
עבור תהליך עבודה בייצור, הייתי דורש שהצעה מאושרת תעבור אימות מחדש לפני ההגשה. אם מפעיל יכול לעקוף מדיניות, סמכות זו צריכה להיות מפורשת ומקושרת לכלל ולהזמנה המסוימים המתקבלים. אישור כללי אינו אמור למחוק כשלים שאינם קשורים. אלו דרישות ליישום עתידי, ולא יכולות המודגמות על ידי בקרי התיקון הנוכחיים.
ייעוץ יכול לסייע מבלי להעניק הרשאה
להערת המודל ההסברתית יש תפקיד שימושי אך צר יותר: היא יכולה להקל על קריאת הסיבה להשהיה. בהקלטת המייסד המצורפת, הערה זו משתמשת בתגובות ייעוץ אמיתיות שנשמרו במטמון. אין מדובר בהיסק חדש בכל השמעה. המנוע מחליט תחילה באמצעות כללים דטרמיניסטיים; טקסט הייעוץ שלאחר מכן אינו יכול לשנות את ההחלטה. קריאת הייעוץ היא סינכרונית במהלך העיבוד, כך שהפרדת סמכויות זו אינה מוכיחה שעבודת המודל אינה מוסיפה השהיית בקשה.
ניתוח פירוט אימות ההזמנות המלא מציג גבול זה ואת הדוגמאות הסינתטיות. הם תומכים בטיעון תכנוני הניתן לבדיקה, ולא בראיות לכך שהמדיניות שהוזנה או תהליך העבודה הלא-גמור של המפעיל מוכנים לפריסה.
להלן הקלטת המייסד של דוגמת בדיקת ההזמנה.
מבחינתי, בדיקת המוצר המכרעת היא לעקוב אחר ההזמנה המוצעת עד לפעולה המותרת הבאה שלה. מי אישר את משמעותה? מי רשאי לקבל חריגה? מה בדק את התוצאה המלאה? עד שתשובות אלו יתייחסו בדיוק לאותה הזמנה, תיקון מרגיע ותווית אישור משאירים את העסקה בלתי גמורה.
