Το φωνητικό σύστημα της Retell λειτουργεί σαν μια ζωντανή αλυσίδα με τρία βασικά βήματα. Και κάθε ένα εξαρτάται από το προηγούμενο βήμα.
ASR → LLM → TTS
ASR (αυτόματη αναγνώριση ομιλίας) ακούει τον καλούντα και μετατρέπει την ομιλία του σε κείμενο.
LLM (γλωσσικό μοντέλο) διαβάζει αυτό το κείμενο, κατανοεί τι ειπώθηκε και αποφασίζει τι θα απαντήσει.
TTS (μετατροπή κειμένου σε ομιλία) παίρνει αυτή την απάντηση και τη μετατρέπει σε ηχητική ομιλία που ακούει ο καλών.
Έτσι η ροή είναι βασικά: ο καλών μιλάει → το ASR το μεταγράφει → το LLM δημιουργεί μια απάντηση → το TTS την εκφωνεί ξανά.
Όταν κάποιος βρίσκεται σε μια κλήση, τόσο τα συστήματα ASR όσο και τα LLM είναι τα κρίσιμα συστήματα που λειτουργούν σε πραγματικό χρόνο. Και τα δύο μπορούν να αποτύχουν, να επιβραδυνθούν ή να συμπεριφερθούν απρόβλεπτα. Χρειάζεται να μπορούμε να βασιζόμαστε στη λειτουργία και των δύο συστημάτων, γι' αυτό έχουμε δημιουργήσει μια διάταξη που παρακολουθεί, δημιουργεί αντίγραφα ασφαλείας και εναλλάσσεται συνεχώς σε πραγματικό χρόνο. Και δείτε πώς λειτουργούν τα δύο μαζί και γιατί αυτές οι ενημερώσεις έχουν σημασία:
Πρώτα, παρακολουθούμε την καθυστέρηση (όχι την αποτυχία)
Θέτουμε συνεχώς μια απλή ερώτηση: "Το σύστημα συμβαδίζει με τη συνομιλία;" Κάθε 0,1 δευτερόλεπτα, συγκρίνουμε:
- Πόσο ήχο έχουμε στείλει
- Πόσος ήχος έχει πραγματικά επεξεργαστεί
Αν το κενό αυξηθεί πέρα από τα 5 δευτερόλεπτα, αυτό είναι το σήμα μας: Αυτός ο πάροχος μένει πίσω. Όχι νεκρός. Όχι χαλασμένος. Αλλά κατευθύνεται προς τα εκεί. Και τότε είναι που ενεργούμε.
Διατηρούμε ένα ζωντανό "δίχτυ ασφαλείας" του ήχου σας
Καθώς ο ήχος επεξεργάζεται, διατηρούμε ένα κυλιόμενο αντίγραφο ασφαλείας οτιδήποτε δεν έχει διαχειριστεί πλήρως ακόμη. Σκεφτείτε το ως εξής:
- Αν το σύστημα επιβεβαιώσει ότι επεξεργάστηκε κάτι → το απορρίπτουμε
- Αν δεν το έχει κάνει ακόμη → το κρατάμε
Έτσι, ανά πάσα στιγμή, έχουμε ένα τέλειο αντίγραφο του "ενδιάμεσου" ήχου, που είναι το τμήμα με τον μεγαλύτερο κίνδυνο να χαθεί. Χωρίς εικασίες. Χωρίς κενά.
Στη συνέχεια εναλλάσσουμε σε ένα εφεδρικό
Τη στιγμή που εντοπίζουμε την καθυστέρηση, δεν περιμένουμε. Εμείς:
- Ενεργοποιούμε έναν εφεδρικό πάροχο (υπάρχει σειρά προτεραιότητας: πρώτα ο πιο γρήγορος, ο πλησιέστερος, ο πιο αξιόπιστος)
- Στέλνουμε όλο αυτό τον ήχο "σε εκκρεμότητα" ώστε να προλάβει
- Τερματίζουμε τον πάροχο που δυσκολεύεται
Δίνουμε επίσης στον νέο πάροχο μια σύντομη περίοδο χάριτος (~20 δευτερόλεπτα) για να σταθεροποιηθεί προτού αρχίσουμε να αξιολογούμε την απόδοσή του.
Το αποτέλεσμα;
Η μεταγραφή απλώς… συνεχίζεται. Χωρίς άλμα. Χωρίς επαναφορά. Χωρίς περίεργα κενά. Από την οπτική γωνία του καλούντος, δεν συνέβη τίποτα.
Γιατί έχει σημασία
Τα περισσότερα συστήματα περιμένουν να καταρρεύσει πλήρως ένας πάροχος πριν κάνουν εναλλαγή.
Εμείς όχι. Πιάνουμε τη στιγμή που αρχίζει να δυσκολεύεται και τον αντικαθιστούμε προτού καν γίνει πρόβλημα.
Συμπέρασμα
- Δεν περιμένουμε την αποτυχία
- Εντοπίζουμε τις επιβραδύνσεις σε πραγματικό χρόνο
- Διατηρούμε κάθε δευτερόλεπτο του ήχου
- Εναλλάσσουμε παρόχους απρόσκοπτα
Έτσι η συνομιλία συνεχίζει να ρέει ακριβώς όπως θα έπρεπε.
LLM: από τη δρομολόγηση σε επίπεδο παρόχου σε επίπεδο ανάπτυξης
Πώς λειτουργούν τα fallbacks LLM μας
Τώρα στην πλευρά της απάντησης, η αποτυχία δεν είναι τόσο προφανής. Είναι πιο διακριτική. Για κάθε μοντέλο LLM (δηλαδή το GPT-4.1) έχουμε ένα σύνολο "deployments" που εξυπηρετούν αυτό το μοντέλο. Σκεφτείτε ένα deployment ως ένα φυσικό κέντρο δεδομένων. Όταν θέλουμε να δημιουργήσουμε μια απάντηση AI—ή να ανακτήσουμε τεκμηριωμένο πλαίσιο από ένα LLM Knowledge Graph για να βελτιώσουμε την ακρίβεια και να μειώσουμε τις παραισθήσεις—χρειάζεται να ορίσουμε ένα συγκεκριμένο deployment για την επεξεργασία αυτού του αιτήματος.
Στο παρασκήνιο, υπάρχουν μερικά κινούμενα μέρη και μπορεί να γίνει λίγο περίπλοκο, αλλά η βασική ιδέα είναι απλή:
Δρομολογούμε σε deployments που έχουν χαμηλότερη καθυστέρηση (latency)
Διασφαλίζει ότι οι απαντήσεις δημιουργούνται ταχύτερα και μειώνει την καθυστέρηση ώστε να διατηρούνται οι συνομιλίες συγχρονισμένες σε πραγματικό χρόνο.
Μετράμε & παρακολουθούμε συνεχώς το ποσοστό σφαλμάτων κάθε deployment
Και κόβουμε την κίνηση προς αυτά που έχουν υψηλά ποσοστά σφαλμάτων.
Έχουμε ανάγκη για ταχύτητα όταν στέλνουμε ένα αίτημα σε ένα deployment
Αν είναι αργό, δεν περιμένουμε. Στέλνουμε το αίτημα κάπου αλλού και συνεχίζουμε μέχρι να απαντήσει κάποιο.
Ας κερδίσει το καλύτερο μοντέλο AI
Αν ένα μοντέλο αποτύχει σε πολλαπλά deployments, δεν συνεχίζουμε να το δοκιμάζουμε. Εναλλασσόμαστε σε ένα άλλο και συνεχίζουμε.
Συμπέρασμα
Δεν βασιζόμαστε σε ένα μοντέλο ή έναν πάροχο.
Συνεχώς:
- δρομολογούμε στην καλύτερη επιλογή
- αποφεύγουμε ό,τι αποτυγχάνει
- ανταγωνιζόμαστε για ταχύτερες απαντήσεις
- και εναλλασσόμαστε όταν χρειάζεται
Έτσι, ακόμη και όταν τα συστήματα έχουν μια κακή μέρα, οι συνομιλίες σας δεν έχουν.
.avif)