Structured Outputs: מאמתים נתונים לפני יצירת הזמנה

מה זה Structured Outputs?

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

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

JSON Schema הוא שער הבדיקה הראשון

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

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

בודקים את המשמעות העסקית לפני הכתיבה

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

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

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

בודקים גם הצעות שנדחות

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

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

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

משלבים חילוץ באמצעות AI בתחזוקת המערכת

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

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