Ανθεκτικό streaming σε Chatbot ΤΝ: Reconnect, μερικές απαντήσεις και προσβάσιμες ενημερώσεις κατάστασης

Το streaming κάνει ένα chatbot ΤΝ να φαίνεται ταχύτερο, επειδή οι πρώτες λέξεις εμφανίζονται πριν υπολογιστεί η πλήρης απάντηση. Τεχνικά, όμως, αυτό δημιουργεί μια κατανεμημένη διαδικασία: ο διακομιστής, ο πάροχος του μοντέλου, ο proxy, ο περιηγητής και η διεπαφή χρήστη διατηρούν από κοινού την κατάσταση για δευτερόλεπτα ή λεπτά. Η κινητή τηλεφωνία αλλάζει δίκτυο, μια καρτέλα περνά στο παρασκήνιο, ένας proxy τερματίζει μια αδρανή σύνδεση ή ο χρήστης στέλνει κατά λάθος ξανά το αίτημα. Χωρίς σαφές πρωτόκολλο, τμήματα κειμένου εμφανίζονται εις διπλούν, μισές δηλώσεις επισημαίνονται ως πλήρεις ή η ίδια ενέργεια εργαλείου ενεργοποιείται δύο φορές.

Ένα ανθεκτικό chatbot ιστότοπου αντιμετωπίζει επομένως το streaming ως μηχανή καταστάσεων και όχι ως κίνηση γραφικών (animation). Αυτός ο οδηγός δείχνει πώς αλληλεπιδρούν τα αναγνωριστικά συμβάντων, η επανασύνδεση, η ατομική ολοκλήρωση και οι διακριτικές ειδοποιήσεις για screen readers.

Ένα μήνυμα χρειάζεται μια μόνιμη ταυτότητα

Εκχωρήστε ένα ID αιτήματος από την πλευρά του πελάτη κατά την υποβολή και ένα αμετάβλητο ID μηνύματος από την πλευρά του διακομιστή. Κάθε τμήμα ροής λαμβάνει επιπλέον έναν αύξοντα αριθμό αλληλουχίας. Εάν η ίδια εργασία φτάσει ξανά μετά από ένα σφάλμα σύνδεσης, ο διακομιστής δεν πρέπει να ξεκινήσει μια δεύτερη ανεξάρτητη εκτέλεση, αλλά να επιστρέψει την υπάρχουσα κατάσταση ή να τη συνεχίσει με ασφάλεια.

Οι ταυτότητες εξυπηρετούν διαφορετικούς σκοπούς: Το ID αιτήματος καθιστά τη διαδικασία εγγραφής αδρανοδύναμη, το ID μηνύματος προσδιορίζει το αποτέλεσμα και ο αριθμός αλληλουχίας ταξινομεί τα αποσπάσματα. Μια χρονική σήμανση από μόνη της δεν αρκεί, καθώς τα παράλληλα αιτήματα ενδέχεται να συγκρουστούν ή να φτάσουν καθυστερημένα.

Διαχωρισμός μεταφοράς και επιχειρησιακής κατάστασης

Το αν χρησιμοποιούνται Server-Sent Events, Fetch Streams ή WebSockets δεν αλλάζει τον επιχειρησιακό κύκλο ζωής. Μοντελοποιήστε τουλάχιστον τις καταστάσεις: ελήφθη, σε εξέλιξη, ολοκληρώθηκε, ακυρώθηκε και απέτυχε. Μόνο ένα ρητό συμβάν ολοκλήρωσης καθιστά μια απάντηση δεσμευτική. Αντίθετα, το τέλος μιας σύνδεσης TCP δεν σημαίνει αυτόματα επιτυχία.

Για τα Server-Sent Events, το πρότυπο HTML περιγράφει τις επανασυνδέσεις και τη διαβίβαση του τελευταίου ID συμβάντος. Αυτός ο μηχανισμός είναι χρήσιμος, αλλά δεν αντικαθιστά το ιστορικό στην πλευρά του διακομιστή. Ο διακομιστής πρέπει να γνωρίζει ποια αποσπάσματα ανήκουν σε ένα μήνυμα και αν μια νέα ανάκτηση επιτρέπεται να παραλείψει αλληλουχίες που έχουν ήδη αποσταλεί.

Επανασύνδεση χωρίς διπλό κείμενο

Αποθηκεύστε μια περιορισμένη ενδιάμεση μνήμη συμβάντων ανά τρέχον μήνυμα. Κατά την επανασύνδεση, ο πελάτης στέλνει την τελευταία επιβεβαιωμένη αλληλουχία. Ο διακομιστής παρέχει μόνο μεταγενέστερα συμβάντα. Εάν η ενδιάμεση μνήμη έχει λήξει, δεν απαντά με εικαζόμενα αποσπάσματα, αλλά με ένα στιγμιότυπο (snapshot) του τρέχοντος πλήρους κειμένου και μια νέα αλληλουχία βάσης.

Ο πελάτης επεξεργάζεται τα συμβάντα με αδρανοδύναμο τρόπο: Αλληλουχίες μικρότερες ή ίσες με την τελευταία τιμή που εφαρμόστηκε αγνοούνται. Μεγαλύτερα κενά ενεργοποιούν μια ανάκτηση στιγμιοτύπου. Έτσι, η οθόνη παραμένει σωστή, ακόμη και αν ένας proxy επαναλάβει δεδομένα ή ο περιηγητής επιστρέψει μετά από σύντομο χρονικό διάστημα εκτός σύνδεσης.

Οι μερικές απαντήσεις δεν πρέπει να ενεργοποιούν ενέργειες

Το ρέον κείμενο είναι προσωρινό. Οι σύνδεσμοι ενδέχεται να είναι ακόμα ημιτελείς, ένας περιορισμός μπορεί να εμφανιστεί μόνο στην επόμενη πρόταση και τα δομημένα επιχειρήματα εργαλείων είναι συντακτικά άκυρα μέχρι το τέλος. Προβάλλετε το κείμενο προοδευτικά, αλλά ενεργοποιήστε τις επικίνδυνες ενέργειες μόνο μετά την ολοκλήρωση και μετά από ξεχωριστή επαλήθευση.

Αυτό ισχύει ιδιαίτερα για παραγγελίες, κρατήσεις ραντεβού, αλλαγές σε δεδομένα πελατών ή αποστολή e-mail. Η εκτέλεση ενός εργαλείου απαιτεί δικό της αδρανοδύναμο ID ενέργειας, έλεγχο δικαιωμάτων και, εάν είναι απαραίτητο, ορατή επιβεβαίωση. Μια επανασύνδεση δεν πρέπει ποτέ να εκτελέσει ξανά το ίδιο αποτέλεσμα.

Αντιμετώπιση της ακύρωσης ως πραγματικό συμβάν πρωτοκόλλου

Ένα κουμπί διακοπής δεν πρέπει απλώς να παγώνει την προβολή. Ο πελάτης στέλνει ένα αίτημα ακύρωσης με το ID μηνύματος· ο διακομιστής επισημαίνει την εκτέλεση και, εάν είναι δυνατόν, τερματίζει τις εργασίες του μοντέλου και των εργαλείων. Τα αποσπάσματα που φτάνουν αργότερα απορρίπτονται. Στη διεπαφή χρήστη παραμένει σαφές ότι η απάντηση ακυρώθηκε.

Εάν η ακύρωση δεν φτάσει στον διακομιστή, η εργασία μπορεί να συνεχίσει να εκτελείται εκεί. Επομένως, ο διακομιστής ελέγχει επίσης τακτικά την κατάσταση. Οι μετρήσεις κόστους και λανθάνοντος χρόνου θα πρέπει να καταγράφουν τις ακυρωμένες εκτελέσεις ξεχωριστά, διαφορετικά εμφανίζονται ως κανονικά σφάλματα ή εξαφανίζονται εντελώς από την ανάλυση.

Καταστήστε τα σφάλματα κατανοητά και επαναλήψιμα

Διαχωρίστε τουλάχιστον τη διακοπή δικτύου, το χρονικό όριο (timeout), το σφάλμα παρόχου, τον αποκλεισμό ασφαλείας και την επιχειρησιακή επαλήθευση. Το μήνυμα προς τον χρήστη δεν χρειάζεται να αποκαλύπτει εσωτερικές τεχνικές λεπτομέρειες, αλλά θα πρέπει να υποδεικνύει το ασφαλές επόμενο βήμα. Το «Η σύνδεση διακόπηκε – Η απάντηση συνεχίζεται» είναι διαφορετικό από το «Αυτή η ενέργεια δεν εκτελέστηκε».

Ένα κουμπί επανάληψης χρησιμοποιεί το αρχικό ID αιτήματος μόνο εάν πρόκειται να συνεχιστεί η ίδια εκτέλεση. Για μια πραγματική νέα δημιουργία, δημιουργείται ένα νέο ID και η διεπαφή δεν εμφανίζει και τις δύο εκδόσεις ως ένα μοναδικό αποτέλεσμα.

Μην κατακλύζετε τους screen readers με κάθε token

Το δυναμικό περιεχόμενο πρέπει να είναι αντιληπτό από υποστηρικτικές τεχνολογίες. Το WAI-ARIA ορίζει Live Regions και διαφορετικά επίπεδα προτεραιότητας για αυτόν τον σκοπό. Μια περιοχή που ενημερώνεται ανά token με aria-live μπορεί ωστόσο να προκαλέσει εκατοντάδες διακοπές. Καλύτερη είναι μια οπτική ένδειξη streaming με ξεχωριστό, ήπιο κανάλι κατάστασης.

Αναφέρετε, για παράδειγμα, «Η απάντηση δημιουργείται», στη συνέχεια σε λογικά διαστήματα μια ολοκληρωμένη πρόταση ή ενότητα και στο τέλος «Η απάντηση ολοκληρώθηκε». Χρησιμοποιήστε aria-live="polite" για την κανονική πρόοδο· assertive είναι κατάλληλο μόνο για πραγματικά επείγοντα σφάλματα. Η εστίαση παραμένει στο πεδίο εισαγωγής ή στο σημείο που επιλέχθηκε από τον χρήστη και δεν μεταηδά με κάθε απόσπασμα.

Τοποθετήστε aria-busy="true" στην περιοχή απάντησης όσο το περιεχόμενο είναι ημιτελές και αφαιρέστε το κατά την ατομική ολοκλήρωση. Το κουμπί διακοπής χρειάζεται μια σαφή ονομασία και πρέπει να είναι προσβάσιμο μέσω πληκτρολογίου. Ελέγξτε επίσης τη μειωμένη κίνηση, την εστίαση (zoom) και τις μικρές προβολές σε κινητές συσκευές.

Στοχευμένος έλεγχος της μηχανής καταστάσεων

Mια δοκιμή ορθής λειτουργίας (happy path) δεν αρκεί. Αυτοματοποιήστε τουλάχιστον αυτές τις περιπτώσεις:

• Αποσύνδεση μετά από عدة αποσπάσματα και συνέχιση χωρίς διπλό κείμενο.
• Παράδοση του ίδιου συμβάντος δύο φορές και εφαρμογή του μόνο μία φορά.
• Παράλειψη μιας αλληλουχίας και αίτημα για στιγμιότυπο.
• Παύση καρτέλας, αλλαγή δικτύου και στη συνέχεια προβολή της σωστής ολοκλήρωσης.
• Ακύρωση κατά την προετοιμασία ενός εργαλείου χωρίς εκτέλεση καμίας ενέργειας.
• Επισήμανση ως ημιτελούς μετά από χρονικό όριο σε ορατή μερική απάντηση.
• Έλεγχος των εξόδων screen reader για εύλογη συχνότητα και συμπεριφορά εστίασης.

Καταγράψτε τον χρόνο μέχρι το πρώτο ορατό τμήμα, τον χρόνο μέχρι την πλήρη ολοκλήρωση, το ποσοστό επανασύνδεσης, τις διπλές ή απορριφθείσες αλληλουχίες και την επιτυχία ακύρωσης. Ο χρόνος μέχρι το πρώτο token από μόνος του μπορεί να φαίνεται καλός, παρόλο που πολλές απαντήσεις δεν ολοκληρώνονται ποτέ με αξιοπιστία.

Ένα σταδιακό σχέδιο εφαρμογής

1. Ορισμός καταστάσεων μηνυμάτων και συμβάντων στην πλευρά του διακομιστή.
2. Υλοποίηση αδρανοδύναμων IDs και αλληλουχιών πριν από τα γραφικά διεπαφής.
3. Προσθήκη επανασύνδεσης με ενδιάμεση μνήμη και εναλλακτική λύση στιγμιοτύπου.
4. Αστηρός διαχωρισμός ενεργειών εργαλείων από το προσωρινό κείμενο.
5. Έλεγχος ειδοποιήσεων κατάστασης με πληκτρολόγιο και screen reader.
6. Δοκιμή περιπτώσεων σφάλματος υπό περιορισμένο και μεταβαλλόμενο δίκτυο.
7. Μόνο στη συνέχεια σταδιακή ενεργοποίηση του streaming για την κυκλοφορία παραγωγής.

Συμπέρασμα: Γρήγορα ορατό, σαφώς ολοκληρωμένο

Το καλό streaming συνδυάζει την αντιληπτή ταχύτητα με ένα σαφές μοντέλο αλήθειας. Τα μόνιμα IDs, τα ταξινομημένα συμβάντα, η ατομική ολοκλήρωση και η ασφαλής επανασύνδεση αποτρέπουν τις διπλές ή μισές απαντήσεις. Μια διακριτική Live Region καθιστά τη διαδικασία προσβάσιμη, χωρίς να διακόπτει τους χρήστες screen reader με κάθε token.

Στη συνέχεια, δοκιμάστε μια πραγματική συνομιλία υπό ασταθές δίκτυο κινητής τηλεφωνίας. Εάν μετά την ακύρωση και την επανασύνδεση δεν είναι απολύτως σαφές ποιο μήνυμα είναι πλήρες και ποια ενέργεια εκτελέστηκε πράγματι, το πρωτόκολλο χρειάζεται πρώτα διόρθωση — όχι η κίνηση φορτώσεως.

Πηγές

• WHATWG HTML Standard: Server-Sent Events
• MDN Web Docs: Streams API
• W3C: WAI-ARIA 1.2
• W3C WAI: Ειδοποιήσεις κατάστασης με ARIA Live Regions