תשובות LLM בזרם: התקדמות, ביטול ושגיאות ברורות

מה משתנה

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

גבול השרת

בתכנון עם מפתח API קבוע, המפתח נשאר בשרת. הדפדפן פונה לשרת שלכם, שבודק משתמש ומגבלות ופונה לספק. לא שמים סוד בקוד ציבורי. ReadableStream ו-getReader קוראים חלקים מגוף fetch. TextDecoder צריך לשמור על UTF-8 גם כשאות נחלקת בין מקטעים. באירועי SSE אוספים אירוע שלם לפי הפרוטוקול; כל read אינו הודעה עצמאית. ייתכנו כמה אירועים במקטע אחד או אירוע בכמה מקטעים.

ביטול אינו הוכחת עצירת חיוב

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

שמירה ובדיקה

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

מקורות

• https://wurk.fun/blog/stream-llm-responses-so-your-app-doesn-t-look-frozen
• https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
• https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams
• https://developer.mozilla.org/en-US/docs/Web/API/AbortController
• https://wurk.fun/blog/get-json-you-can-trust-from-an-llm-schema-validate-retry