GPT-Live יכול לפעול באמצע משפט — ההחלטה עדיין אינה הפעולה

יומן השינויים של OpenAI מציין כי ב־15 באוקטובר 2026 נוסף ל־GPT-Live חיבור מובנה ל־Decisions: שיחת הקול פועלת עם gpt-live-1, ההחלטות מתקבלות ב־gpt-6-luna, ו־Decisions עדיין בבטא. החיבור מאפשר לקבל תשובה מובנית בזמן שהמשתמש מדבר, אם Live מאציל אליו בקשה או אם מקטעי תמלול מפעילים החלטה.

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

מה מתקבל עוד לפני שהבקשה הושלמה

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

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

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

שני מסלולים להפעלת Decisions

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

במסלול התמלול מגדירים ב־session.triggers טריגר על session.input_transcript.delta, שמתקבל מדברי המשתמש, או על session.output_transcript.delta, שמתקבל מן הדברים ש־Live אומר. הראשון מתאים לתגובה לבקשה בזמן שהיא נאמרת; השני מאפשר, למשל, לשנות תגובה חזותית בזמן שהסוכן מדבר. הטריגרים פועלים בנפרד מההאצלה, ולכן אפשר לתכנן לשניהם תפקידים שונים באותה שיחה.

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

הגבול שבין תשובה מובנית לבין פעולה

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

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

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

מה מצטבר בחיוב ומה קורה בכשל

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

מבחינת היישום, ארבע בדיקות קובעות אם התוצאה המוקדמת תהפוך לפעולה בטוחה:

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

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

קראו גם:

• ה־AI מאיץ מנהלים — אבל האחריות על ההחלטה נשארת מעורפלת
• המדינה בחרה שתי קרנות דיפנס־טק — הכסף הפרטי עדיין צריך להגיע
• GitHub Actions או GitLab CI: דקת build אינה אותה יחידת חיוב