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

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

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

התקרה האמיתית

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

איך זה נראה

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

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

ה-SDK נותנים קיצור: אירוע ייעודי שמחזיר רק את דלתת הטקסט, בלי לסנן ידנית.

הטעות הנפוצה בסוף הזרם

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

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

סטרימינג עם כלים

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

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

מה עוד משתנה

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

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

מה כדאי במיוחד בממשק

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