Πώς να διατηρείτε ενημερωμένη μια βάση γνώσεων φωνητικού AI όταν η πηγή αλήθειάς σας βρίσκεται στο SharePoint, στο Azure ή σε ιδιωτικά έγγραφα
Ναι, και η αρχιτεκτονική είναι απλή μόλις σταματήσετε να προσπαθείτε να το κάνει αυτό το Copilot Studio. Δημιουργείτε ένα κατοπτρικό αντίγραφο των αυθεντικών εγγράφων από το SharePoint, το OneDrive ή το Azure Blob σε ένα διανυσματικό ευρετήριο που ανήκει στον πράκτορα, και έπειτα αφήνετε τα webhooks του Microsoft Graph και τις ειδοποιήσεις του Event Grid να καθοδηγούν τις σταδιακές ενημερώσεις. Οι επεξεργασίες στην πηγή διαδίδονται στον πράκτορα μέσα σε λίγα λεπτά. Χωρίς νέα ανεβάσματα.
Οι περισσότερες ομάδες αντιμετωπίζουν αυτό το πρόβλημα αφού έχουν ήδη δοκιμάσει τις προφανείς διαδρομές. Ο connector του SharePoint στο Copilot Studio εξακολουθεί να μην ανανεώνεται αυτόματα όταν αλλάζουν τα αρχεία, ένας περιορισμός που η Microsoft επιβεβαίωσε τον Ιούλιο του 2025 και ο οποίος δεν έχει διορθωθεί τη στιγμή της συγγραφής. Το Azure AI Search μπορεί να προσεγγίσει το SharePoint μέσω ενός indexer, αλλά ο indexer δεν μπορεί να βρίσκεται πίσω από Conditional Access, έχει μόνο βασική υποστήριξη ACL σε preview, και απαιτεί να δημιουργήσετε μόνοι σας το επίπεδο του πράκτορα. Το μοτίβο που περιγράφει αυτός ο οδηγός χρησιμοποιεί την Retell AI ως φωνητικό επίπεδο επειδή το API της βάσης γνώσεων δέχεται πιστοποιημένες προωθήσεις από τον δικό σας sync worker, κάτι που παρακάμπτει κάθε περιορισμό που επιβάλλει η first-party διαδρομή της Microsoft.
Έναν φωνητικό πράκτορα που απαντά από ένα επιμελημένο κατοπτρικό αντίγραφο του ιδιωτικού σας σώματος εγγράφων, με τις επεξεργασίες να διαδίδονται από άκρο σε άκρο σε πέντε έως δεκαπέντε λεπτά και μια καθημερινή διαδικασία συμφωνίας που εντοπίζει οτιδήποτε χάνει η ροή συμβάντων.
Στο τέλος, το stack σας θα:
Πριν ξεκινήσετε, θα χρειαστείτε:
Sites.Selected προτιμάται, το Sites.Read.All είναι η ευρύτερη εναλλακτική)Επειδή τα εργαλεία σχεδιάστηκαν για διαφορετική δουλειά. Το Copilot Studio κατασκευάστηκε για να συνοψίζει περιεχόμενο για έναν άνθρωπο που διαβάζει μια οθόνη, όχι για να τροφοδοτεί έναν φωνητικό πράκτορα που έχει κάτω από ένα δευτερόλεπτο για να συνθέσει μια προφορική απάντηση. Ο indexer του SharePoint στο Azure AI Search κατασκευάστηκε για επιχειρησιακή αναζήτηση, όπου ένα παράθυρο ανανέωσης τεσσάρων έως έξι ωρών είναι εντάξει. Κανένα από τα δύο προϊόντα δεν σχεδιάστηκε με την παραδοχή ότι μια πολιτική τιμολόγησης που επεξεργάστηκε στις 9 π.μ. πρέπει να είναι η απάντηση που ακούει ένας καλών στις 9:08 π.μ.
Τρεις περιορισμοί διαχωρίζουν τη φωνή από το κείμενο. Ο πρώτος είναι ο προϋπολογισμός καθυστέρησης (latency). Μια κλήση ανάκτησης πρέπει να επιστρέφει σε λιγότερο από 100 χιλιοστά του δευτερολέπτου κατά τη διάρκεια μιας ζωντανής συνομιλίας, οπότε το ευρετήριο πρέπει να βρίσκεται στο ίδιο δίκτυο με τον πράκτορα, και τα chunks πρέπει να είναι αρκετά μικρά ώστε να ενσωματώνονται inline χωρίς να ανατινάζουν το context window του LLM. Ο δεύτερος είναι η ανοχή σε σφάλματα. Όταν ένα chatbot επιστρέφει τον λάθος σύνδεσμο, ο χρήστης κάνει ξανά κλικ. Όταν ένας φωνητικός πράκτορας παραθέτει μια αποσυρμένη πολιτική σε μια ηχογραφημένη κλήση συμμόρφωσης, έχετε ένα πρόβλημα με συνημμένα αρχεία καταγραφής ελέγχου. Ο τρίτος είναι η προσδοκία φρεσκάδας. Οι ομάδες πωλήσεων προσαρμόζουν την τιμολόγηση κάθε Τρίτη. Οι ομάδες υποστήριξης δημοσιεύουν ενημερώσεις πολιτικής μετά από μια επισκόπηση περιστατικού την Παρασκευή. Ο πράκτορας που παραθέτει τον αριθμό της περασμένης εβδομάδας είναι χειρότερος από κανέναν πράκτορα.
Γι' αυτό η αρχιτεκτονική διαχωρίζει την πηγή αλήθειας από το επίπεδο ανάκτησης. Το SharePoint παραμένει το κανονικό. Το διανυσματικό ευρετήριο είναι ένα παράγωγο αντικείμενο που το sync pipeline διατηρεί ενημερωμένο. Οι τρόποι αποτυχίας γίνονται παρατηρήσιμοι αντί για σιωπηλοί.
Επιλέξτε με βάση το πού συντάσσεται το έγγραφο, όχι με βάση το πού είναι ευκολότερο να το συνδέσετε. Κάθε πηγή δείχνει κάτι διαφορετικό σχετικά με το πώς συντηρείται το περιεχόμενο.
Οι βιβλιοθήκες εγγράφων του SharePoint είναι η σωστή κύρια πηγή όταν η ιδιοκτησία είναι συνεργατική και το περιεχόμενο εξελίσσεται μέσα από επισκόπηση επιτροπής. Κατάλογοι υπηρεσιών, εγχειρίδια πολιτικών, εσωτερικά wikis και playbooks πωλήσεων τείνουν να βρίσκονται εδώ, με ιστορικό εκδόσεων, σχόλια και ροές έγκρισης συνημμένα. Το κόστος είναι η διασπορά μεταδεδομένων: ένα τυπικό site περιέχει τέσσερις εκδόσεις της ίδιας πολιτικής, δύο αποσυρμένα προσχέδια και τον φάκελο στιγμιότυπων οθόνης κάποιου.
Το OneDrive σπάνια είναι η σωστή κύρια πηγή για έναν φωνητικό πράκτορα. Το περιεχόμενο που συνδέεται με τον λογαριασμό ενός ατόμου φεύγει από την πόρτα όταν αυτό το άτομο αποχωρεί. Χρησιμοποιήστε το OneDrive μόνο ως χώρο σταδιοποίησης όπου μεμονωμένοι συνεργάτες συντάσσουν προσχέδια που προωθούνται σε μια βιβλιοθήκη SharePoint μετά από επισκόπηση.
Τα containers του Azure Blob είναι η σωστή πηγή όταν τα έγγραφα παράγονται από upstream συστήματα. Παραγόμενα PDF από ένα pipeline τιμολόγησης, συμβόλαια που αποθέτονται από ένα εργαλείο CLM, καταστάσεις από μια εργασία εξαγωγής, και μεταγραφές από ένα σύστημα ηχογράφησης ανήκουν όλα στο Blob. Ο όγκος είναι μεγαλύτερος, η φρεσκάδα δυσκολότερο να πλαστογραφηθεί, και η ονοματοδοσία των αρχείων ακολουθεί όποια σύμβαση επιβάλλει το παράγον σύστημα, κάτι που κάνει το mirror-and-sync απλούστερο από την ελεύθερης μορφής δομή του SharePoint.
Οι περισσότερες επιχειρησιακές ομάδες συγχρονίζουν και τα δύο. Το SharePoint τροφοδοτεί την πλευρά πολιτικής και προϊόντος, το Blob τροφοδοτεί τη λειτουργική και μηχανικά παραγόμενη πλευρά, και η βάση γνώσεων του φωνητικού πράκτορα συγχωνεύει και τα δύο πίσω από ένα ενιαίο API ανάκτησης.
Καταχωρίστε μια εφαρμογή στο Microsoft Entra ID, ζητήστε δικαιώματα εφαρμογής, και ζητήστε από έναν διαχειριστή tenant να δώσει συναίνεση.
Τα δικαιώματα εφαρμογής εκτελούνται κάτω από ένα service principal. Ο worker συνεχίζει να λειτουργεί όλη τη νύχτα χωρίς συνδεδεμένο χρήστη, και το token είναι συνεπές μεταξύ κλήσεων. Τα εκχωρημένα (delegated) δικαιώματα, αντιθέτως, συνδέουν την πρόσβαση με έναν πραγματικό λογαριασμό χρήστη και επιβάλλουν επανα-πιστοποίηση περίπου κάθε 75 λεπτά σύμφωνα με τις βιβλιοθήκες ασφαλείας που χρησιμοποιεί πλέον η Microsoft. Τα εκχωρημένα δικαιώματα επίσης δεν μπορούν να διατηρήσουν τα ACLs σε επίπεδο εγγράφου, όπως σημειώνει η ίδια η τεκμηρίωση του indexer του SharePoint της Microsoft, κάτι που γίνεται πρόβλημα τη στιγμή που η συμμόρφωση ρωτά ποιος μπορεί να ακούσει τι.
Το scope είναι εκεί όπου οι περισσότερες ομάδες μοιράζονται υπερβολικά. Η παραχώρηση του Sites.Read.All επιτρέπει στην εφαρμογή να διαβάζει κάθε site στο tenant. Είναι γρήγορο στη ρύθμιση και μη υπερασπίσιμο σε έναν έλεγχο. Η αυστηρότερη εναλλακτική είναι το Sites.Selected, όπου ένας διαχειριστής tenant προεξουσιοδοτεί την εφαρμογή έναντι συγκεκριμένων IDs site μόνο. Ο worker βλέπει τις βιβλιοθήκες που χρειάζεται ο πράκτορας και τίποτα άλλο. Χρησιμοποιήστε το Sites.Selected από την πρώτη μέρα. Η αναδρομική προσθήκη scoping σε επίπεδο site εκ των υστέρων απαιτεί επανα-συναίνεση και συνήθως μια επισκόπηση ασφαλείας που δεν προϋπολογίσατε.
Για το Azure Blob, εκχωρήστε στο ίδιο service principal τον ρόλο Storage Blob Data Reader στο συγκεκριμένο container. Το scope σε επίπεδο container υπερτερεί του scope σε επίπεδο λογαριασμού για τον ίδιο λόγο.
Συνδυάστε δύο primitives του Microsoft Graph. Τα webhooks σας λένε πότε συνέβη κάτι. Τα delta queries σας λένε ακριβώς τι άλλαξε.
Μια συνδρομή webhook είναι ένα POST στο /subscriptions με μια διαδρομή πόρου που δείχνει στο drive (για παράδειγμα, /sites/{site-id}/drive/root), ένα changeType τύπου updated, και ένα notificationUrl που στοχεύει στο HTTPS endpoint του worker σας. Το σώμα της ειδοποίησης είναι σκόπιμα λιτό. Μεταφέρει το ID του πόρου και τον τύπο αλλαγής, τίποτα περισσότερο. Αυτό είναι εκ σχεδιασμού. Ο worker χρησιμοποιεί την ειδοποίηση ως σήμα για να καλέσει το delta endpoint, όπου βρίσκεται το πραγματικό payload.
Το delta query είναι το /sites/{site-id}/drive/root/delta. Στην πρώτη εκτέλεση, χωρίς token, λαμβάνετε μια πλήρη απαρίθμηση συν ένα αδιαφανές @odata.deltaLink. Διατηρήστε αυτόν τον σύνδεσμο αυτολεξεί. Σε κάθε επόμενη εκτέλεση, τον επαναλαμβάνετε και το Graph επιστρέφει μόνο τα στοιχεία που προστέθηκαν, τροποποιήθηκαν, μετονομάστηκαν ή διαγράφηκαν από την τελευταία κλήση. Η καθοδήγηση σάρωσης της Microsoft είναι σαφής: webhooks συν delta είναι το συνιστώμενο μοτίβο για μεγάλες βιβλιοθήκες, επειδή το καθαρό polling θα σας οδηγήσει σε throttling, και τα καθαρά webhooks θα χάσουν δεδομένα αν το endpoint είναι αργό.
Δύο κομμάτια λαογραφίας που αξίζει να γνωρίζετε. Το ίδιο στοιχείο μπορεί να εμφανιστεί περισσότερες από μία φορές σε μια σελίδα delta, εκ σχεδιασμού, επειδή το Graph επεκτείνει ιεραρχίες φακέλων και συγχωνεύει ταυτόχρονες αλλαγές. Όταν εμφανίζονται διπλότυπα, πάρτε την τελευταία εμφάνιση. Οι συνδρομές επίσης λήγουν. Ανανεώστε στο 75% της μέγιστης διάρκειας ζωής, όχι στην προθεσμία. Μια εργασία ανανέωσης που αποτυγχάνει σιωπηλά είναι ο μοναδικός πιο συνηθισμένος λόγος για τον οποίο ένα προηγουμένως λειτουργικό sync αρχίζει να αποκλίνει σε ξεπερασμένο περιεχόμενο, και το ανακαλύπτετε όταν παραπονεθεί ένας πελάτης.
Χρησιμοποιήστε το Event Grid για ειδοποιήσεις σε πραγματικό χρόνο και το change feed για συμφωνία σε παρτίδες. Λύνουν διαφορετικά προβλήματα και η απάντηση για την παραγωγή είναι να εκτελείτε και τα δύο.
Το Event Grid προωθεί συμβάντα τη στιγμή που ένα blob δημιουργείται, αντικαθίσταται ή διαγράφεται. Κάντε συνδρομή στον λογαριασμό αποθήκευσης, φιλτράρετε στο eventType για Microsoft.Storage.BlobCreated και Microsoft.Storage.BlobDeleted, και δρομολογήστε στον worker σας. Για το Azure Data Lake Storage Gen2, προσθέστε ένα φίλτρο στην κλήση API FlushWithClose. Αυτό διασφαλίζει ότι το συμβάν ενεργοποιείται μόνο αφού το blob δεσμευτεί πλήρως. Παραλείψτε το αυτό και θα επεξεργαστείτε μερικά ανεβάσματα, κάτι που παράγει σφάλματα απορρόφησης που μοιάζουν με καταστροφή αρχείου αλλά δεν είναι.
Το change feed είναι το διατεταγμένο, ανθεκτικό αρχείο καταγραφής πίσω από τα συμβάντα. Σύμφωνα με την τεκμηρίωση της Microsoft, παρέχει ένα εγγυημένο αρχείο καταγραφής συναλλαγών που διατηρείται ως αρχεία Avro στο $blobchangefeed/log/, γραμμένο μέσα σε λίγα λεπτά από κάθε αλλαγή. Το Event Grid είναι best-effort και μπορεί να απορρίψει ειδοποιήσεις υπό φορτίο. Το change feed δεν μπορεί. Εκτελέστε μια καθημερινή εργασία που διατρέχει το change feed και συμφωνεί έναντι του manifest της βάσης γνώσεων σας, και έχετε ένα δίχτυ ασφαλείας κάτω από τη διαδρομή πραγματικού χρόνου.
Ο συνδυασμός έχει σημασία. Το Event Grid μόνο του είναι γρήγορο αλλά απωλεστικό. Το change feed μόνο του είναι αξιόπιστο αλλά αργό. Μαζί σας δίνουν φρεσκάδα κλίμακας λεπτών στην ευτυχή διαδρομή και πλήρη συνέπεια μέχρι το πρωί στη δυστυχή διαδρομή.
Ο worker κατεβάζει το αρχείο, το κανονικοποιεί, και το προωθεί στο API της πλατφόρμας. Τρεις λειτουργίες: δημιουργία, ενημέρωση, διαγραφή. Η μετονομασία καταρρέει σε διαγραφή-συν-δημιουργία.
Η βάση γνώσεων της Retell AI δέχεται μια μακρά λίστα μορφών εγγράφων συμπεριλαμβανομένων PDF, DOCX, PPTX, XLSX, CSV, TSV, TXT, MD, HTML, RTF, ODT, EPUB, συν μορφές μηνυμάτων και αρκετούς τύπους εικόνας. Οι περιορισμοί που αξίζει να γνωρίζετε: 50MB ανά αρχείο, 25 αρχεία ανά βάση, και 1.000 γραμμές επί 50 στήλες για υπολογιστικά φύλλα. Το Markdown απορροφάται με τον καθαρότερο τρόπο όταν ελέγχετε τη μορφή της πηγής, γι' αυτό οι ομάδες συχνά εκτελούν ένα βήμα κανονικοποίησης που μετατρέπει συντεταγμένα έγγραφα Word σε Markdown πριν την προώθηση.
Όταν ο αριθμός αρχείων αυξάνεται πέρα από 25, χωρίστε τις βάσεις κατά τομέα αντί κατά τμήμα. Ένας πράκτορας τιμολόγησης συνδεδεμένος με τα "billing-policies-en", "service-catalog-2026" και "exception-cases" ανακτά καθαρά και στα τρία επειδή η ομοιότητα ανάκτησης υπολογίζεται ανά chunk, όχι ανά βάση. Ο χωρισμός κατά τμήμα, από την άλλη, δημιουργεί τα λάθος όρια. Η ίδια ερώτηση καλούντος συχνά εκτείνεται σε δύο τμήματα, και ο πράκτορας θα ανακτήσει μόνο από ένα από αυτά.
Για τη λειτουργική πλευρά, το idempotency είναι αυτό που σας σώζει όταν η ίδια ειδοποίηση φτάνει δύο φορές. Κάντε hash το περιεχόμενο κάθε αρχείου και χρησιμοποιήστε το hash ως αναγνωριστικό εγγράφου. Μια διπλότυπη ειδοποίηση για ένα αμετάβλητο αρχείο παράγει ένα no-op αντί για μια διπλότυπη καταχώριση ευρετηρίου.
Ένας καθαρός εξαγωγέας κειμένου θα χάσει σιωπηλά 30 έως 40 τοις εκατό του νοήματος σε ένα πραγματικό PowerPoint ή σε ένα οικονομικό workbook. Ο πράκτορας θα παραθέσει έπειτα με αυτοπεποίθηση το 60 τοις εκατό που επιβίωσε, συμπεριλαμβανομένων των τμημάτων που δεν βγάζουν πλέον νόημα χωρίς τον πίνακα από τον οποίο προήλθαν.
Τα PowerPoints κωδικοποιούν πληροφορίες στη διάταξη διαφανειών, στα κελιά πινάκων, στα callouts βασισμένα σε εικόνες, και στις σημειώσεις ομιλητή. Το Excel κωδικοποιεί νόημα σε επικεφαλίδες στηλών που εκτείνονται σε συγχωνευμένα κελιά, σε τύπους που αναφέρονται σε άλλες καρτέλες, και στη σειρά καρτελών. Η αφελής εξαγωγή κειμένου επιστρέφει μια επίπεδη συμβολοσειρά λέξεων με τη δομή αφαιρεμένη. Δύο διαδρομές επιβιώνουν στην παραγωγή.
Η πρώτη είναι η ανάλυση με επίγνωση διάταξης (layout-aware). Εργαλεία όπως το Unstructured, το Azure Document Intelligence ή το LlamaParse διατηρούν τα κελιά πινάκων και τη δομή διαφανειών ως Markdown. Είναι φθηνότερα ανά έγγραφο και προβλέψιμα στην έξοδο. Το μειονέκτημα είναι ότι διαχειρίζονται καλά τους πίνακες αλλά τα γραφήματα άσχημα.
Η δεύτερη, η οποία έχει κερδίσει έδαφος από τα μέσα του 2025, είναι η εξαγωγή βασισμένη σε εικόνα. Αποδώστε κάθε διαφάνεια ή φύλλο ως εικόνα και περάστε την μέσα από ένα LLM με δυνατότητα όρασης που επιστρέφει Markdown. Η έξοδος ανακτά πίνακες, γραφήματα και οπτικά callouts που χάνουν οι εξαγωγείς κειμένου. Το κόστος είναι υψηλότερο ανά έγγραφο και πιο αργό, κάτι που κάνει αυτήν τη σωστή διαδρομή για τα έγγραφα που πραγματικά έχουν σημασία και τη λάθος διαδρομή για μαζική απορρόφηση όλων όσων υπάρχουν σε ένα site του SharePoint.
Ο κανόνας απόφασης που αντέχει: δρομολογήστε τα έγγραφα πολιτικής μέσα από τη φθηνή διαδρομή με επίγνωση διάταξης, δρομολογήστε ένα μικρό σύνολο υψηλής αξίας οπτικών εγγράφων (μονοσέλιδα, decks διαφανειών που αναφέρουν στελέχη, τους πίνακες τιμών που πραγματικά χρησιμοποιεί η ομάδα πωλήσεών σας) μέσα από τη διαδρομή βασισμένη σε εικόνα. Μην προσπαθήσετε να χρησιμοποιήσετε μία προσέγγιση για τα πάντα.
Αναδρομικός διαχωρισμός χαρακτήρων στα 512 tokens με 10 έως 20 τοις εκατό επικάλυψη, τρία chunks που ανακτώνται στην προεπιλεγμένη ομοιότητα. Ρυθμίστε από εκεί με βάση τα δικά σας δεδομένα κλήσεων.
Αυτή δεν είναι η δημοφιλής απάντηση. Η δημοφιλής απάντηση είναι το σημασιολογικό chunking, το οποίο ακούγεται εξυπνότερο και επιδίδεται χειρότερα στα benchmarks. Το benchmark της Vecta που δημοσιεύτηκε στις αρχές του 2026 έθεσε τον αναδρομικό διαχωρισμό 512 tokens στο 69 τοις εκατό ακρίβειας ανάκτησης και το σημασιολογικό chunking στο 54 τοις εκατό στο ίδιο σώμα 50 εγγράφων. Η έρευνα της NVIDIA καταλήγει στο ίδιο σημείο: τα factoid queries (το είδος που λαμβάνει ένας φωνητικός πράκτορας) επιδίδονται καλύτερα στα 256 έως 512 tokens, με 10 έως 20 τοις εκατό επικάλυψη για τη διατήρηση του πλαισίου προτάσεων στα όρια.
Η πρακτική συνέπεια για τον συγχρονισμό: η αλλαγή του μεγέθους chunk ή του μοντέλου embedding ακυρώνει κάθε υπάρχον chunk στη βάση. Αν η ανάκτηση ξαφνικά επιδίδεται χειρότερα μετά από ένα πέρασμα ρύθμισης, μην κάνετε σταδιακή επιδιόρθωση. Ρίξτε τη βάση, επαναπορροφήστε την πηγή, και αποδεχθείτε το κόστος επανεπεξεργασίας λίγων ωρών. Η σαφήνεια που αποκτάτε σε κάθε μελλοντική απάντηση αξίζει την επανάληψη.
Η ρύθμιση κατωφλίου ανάκτησης συμβαίνει αφού έχετε δεδομένα κλήσεων, όχι πριν. Τραβήξτε 50 έως 100 κλήσεις από την ανάλυση μετά την κλήση, επισημάνετε τις αποτυχίες λάθος-chunk, και προσαρμόστε είτε το chunking της προβληματικής πηγής είτε το κατώφλι ομοιότητας. Οι περισσότερες ομάδες υπερρυθμίζουν στην αρχή. Οι προεπιλεγμένες ρυθμίσεις είναι σωστές για το 80 τοις εκατό των περιπτώσεων χρήσης.
Δημιουργήστε έναν κλειστό βρόχο δοκιμής που ιχνηλατεί από την επεξεργασία μέχρι την προφορική απάντηση με μια μοναδική δοκιμάσιμη φράση. Αυτός είναι ο πιο χρήσιμος πεντάλεπτος έλεγχος σε ολόκληρο το pipeline.
Επιλέξτε ένα έγγραφο και επεξεργαστείτε μια μοναδική αριθμητική τιμή σε αυτό. Το "Premium tier discount: 12,5%" γίνεται "Premium tier discount: 14,0%". Αποθηκεύστε στο SharePoint. Μέσα σε πέντε έως δεκαπέντε λεπτά (ειδοποίηση Graph, επεξεργασία delta, embedding), η αλλαγή θα πρέπει να είναι ζωντανή στο ευρετήριο. Πραγματοποιήστε μια δοκιμαστική κλήση θέτοντας την ερώτηση. Αν ο πράκτορας πει 14,0%, ο βρόχος λειτουργεί.
Όταν δεν λειτουργεί, η αποτυχία απομονώνεται καθαρά. Έλαβε ο worker το webhook; Ελέγξτε τα αρχεία καταγραφής του endpoint σας. Επέστρεψε το delta query το αρχείο; Ελέγξτε τα αρχεία καταγραφής του worker. Πέτυχε το ανέβασμα; Ελέγξτε την απάντηση του API. Έφτασε το chunk στην ανάκτηση; Ελέγξτε το αρχείο καταγραφής ανάκτησης της κλήσης στην ανάλυση μετά την κλήση. Κάθε επίπεδο απαντά σε μια ερώτηση ναι/όχι, και βρίσκετε το χαλασμένο επίπεδο σε λιγότερο από δέκα λεπτά.
Εκτελέστε αυτόν τον βρόχο μετά από κάθε ουσιαστική αλλαγή pipeline. Νέα στρατηγική chunking, νέο μοντέλο embedding, νέα πηγή, νέα έκδοση sync worker. Αν ο βρόχος κλείνει, η αλλαγή είναι ασφαλής να δημοσιευτεί. Αν δεν κλείνει, έχετε μια ακριβή αναπαραγωγή του bug.
Τρία επίπεδα, εφαρμοσμένα με αυτή τη σειρά. Κλαδέψτε στην πηγή. Περιορίστε στο prompt. Παρατηρήστε στην κλήση.
Το κλάδεμα στην πηγή είναι το επίπεδο που οι περισσότερες ομάδες παραλείπουν και πληρώνουν αργότερα. Όταν μια πολιτική αποσύρεται, μετακινήστε το αρχείο έξω από τον συγχρονισμένο φάκελο. Το καθαρότερο μοτίβο είναι ένας διαχωρισμός καταλόγων synced/ και archive/ μέσα στην ίδια βιβλιοθήκη SharePoint, με τον worker να παρακολουθεί μόνο το synced/. Δύο ευρετηριασμένες εκδόσεις της ίδιας πολιτικής είναι συνταγή για αυτόπεποίθες αντιφάσεις, και δεν μπορείτε να ξεφύγετε με debugging από αντικρουόμενα έγγραφα πηγής.
Ο περιορισμός στο prompt είναι το επίπεδο δύο. Δώστε εντολή στον πράκτορα να απαντά μόνο από το ανακτημένο πλαίσιο της βάσης γνώσεων και να κλιμακώνει όταν κανένα δεν είναι διαθέσιμο. Δημόσια benchmarks δείχνουν ότι το θεμελιωμένο RAG μειώνει τα ποσοστά παραισθήσεων κατά 26 έως 43 τοις εκατό έναντι μη θεμελιωμένων LLMs. Η βελτίωση ισχύει μόνο όταν η ανάκτηση αναδεικνύει το σωστό έγγραφο. Μια απάντηση "δεν βρέθηκε απάντηση, σας μεταβιβάζω" είναι σχεδόν πάντα καλύτερη από μια αυτόπεποίθη λανθασμένη, και ένας κανόνας κλιμάκωσης που ενεργοποιείται σε ανάκτηση χαμηλής ομοιότητας είναι μία από τις ρυθμίσεις με τη μεγαλύτερη μόχλευση στον πράκτορα.
Η παρατήρηση στην κλήση είναι το επίπεδο τρία και εκεί που κλείνει ο βρόχος. Επισημάνετε κάθε αστοχία με μια κατηγορία: ελλείπουσα πηγή, ανάκτηση λάθος chunk, ξεπερασμένο περιεχόμενο, παρανόηση μοντέλου. Κάθε κατηγορία έχει διαφορετική διόρθωση. Οι ελλείπουσες πηγές μπαίνουν στο επόμενο πέρασμα απορρόφησης. Τα λάθος chunks συνήθως σημαίνουν ότι δύο έγγραφα συζητούν παρόμοια θέματα με διαφορετικό λεξιλόγιο, κάτι που διορθώνεται με ετικέτες μεταδεδομένων ή με τον διαχωρισμό της πηγής. Το ξεπερασμένο περιεχόμενο ανάγεται πίσω σε ένα κενό webhook που η καθημερινή συμφωνία θα έπρεπε να είχε εντοπίσει, και δεν το έκανε, κάτι που είναι bug στην εργασία συμφωνίας σας.
Για μια ομάδα που διαχειρίζεται 5.000 κλήσεις τον μήνα των τριών λεπτών η καθεμία, η χρήση της βάσης γνώσεων είναι το μικρότερο στοιχείο κόστους κατά μία τάξη μεγέθους.
Η Retell AI χρεώνει $0.07 ανά λεπτό για το βασικό κόστος κλήσης, με τη χρήση της βάσης γνώσεων στα $0.005 ανά λεπτό επιπλέον. Κάθε χώρος εργασίας περιλαμβάνει 10 δωρεάν βάσεις γνώσεων. Οι επιπλέον βάσεις κοστίζουν $8 τον μήνα. Για 15.000 λεπτά μηνιαίου χρόνου κλήσης, η χρήση της βάσης γνώσεων προσθέτει $75. Το βασικό κόστος κλήσης είναι $1.050. Συγκρίνετε και τα δύο με τον μισθό SDR ή υποδοχής που ο πράκτορας αντισταθμίζει και τα μαθηματικά γίνονται προφανή. Η τιμολόγηση είναι συνεπής είτε χρησιμοποιείτε μία βάση είτε επτά, και δεν υπάρχει χρέωση πλατφόρμας από πάνω.
Τα κρυφά κόστη βρίσκονται στην πλευρά της Microsoft, και είναι συνήθως μικρά αλλά εύκολο να παραμετροποιηθούν λανθασμένα. Το Microsoft Graph χρεώνει ανά κλήση. Το Azure Event Grid χρεώνει ανά εκατομμύριο λειτουργιών. Και τα δύο είναι πένες σε τυπικό όγκο συγχρονισμού. Ο τρόπος που το μετατρέπετε σε πραγματικό λογαριασμό είναι με το να κάνετε polling στο SharePoint κάθε 30 δευτερόλεπτα αντί να κάνετε συνδρομή σε webhooks. Ένα τέτοιο bug έχει εκτινάξει τις χρεώσεις κατανάλωσης Azure κατά έναν παράγοντα πενήντα για τουλάχιστον μία ομάδα που έχω δει. Το webhook συν delta κρατά τον λογαριασμό σταθερό ανεξάρτητα από το πόσο συχνά αλλάζει η πηγή.
Αυτοί επαναλαμβάνονται αρκετά συχνά σε όλες τις αναπτύξεις ώστε να αξίζουν μια λίστα ελέγχου.
Λήξη συνδρομής webhook. Οι συνδρομές δεν ανανεώνονται μόνες τους. Προσθέστε τη λήξη στις ειδοποιήσεις σας και ανανεώστε στο 75 τοις εκατό της μέγιστης διάρκειας ζωής. Η σιωπηλή λήξη είναι η πιο συνηθισμένη αιτία απόκλισης.
Διαχείριση διαγραφών. Οι περισσότερες ομάδες δημοσιεύουν sync που διαχειρίζεται δημιουργημένα και ενημερωμένα αρχεία και ξεχνά τα αφαιρεμένα. Ο πράκτορας τότε παραθέτει μια πολιτική που αποσύρθηκε πριν από τρεις μήνες. Συνδέστε τον τύπο αλλαγής deleted ως περίπτωση πρώτης τάξης, όχι ως ακραία περίπτωση.
Scope ανάγνωσης σε επίπεδο tenant. Η παραχώρηση του Sites.Read.All στη ρύθμιση είναι γρήγορη. Έξι μήνες αργότερα όταν ένας ελεγκτής ρωτά ποια sites μπορεί να δει το service principal της φωνητικής υπηρεσίας, το "όλα τους" είναι η λάθος απάντηση. Χρησιμοποιήστε το Sites.Selected από την αρχή.
Έγγραφα πάνω από το όριο των 50MB. Τα μεγάλα εγχειρίδια αποτυγχάνουν σιωπηλά στο ανέβασμα όταν υπερβαίνουν το όριο ανά αρχείο. Προεπεξεργαστείτε τα υπερμεγέθη έγγραφα διαχωρίζοντάς τα σε λογικά όρια (κεφάλαιο, ενότητα, γραμμή προϊόντος) και ανεβάζοντας κάθε κομμάτι ως δικό του έγγραφο. Διατηρήστε μεταδεδομένα γονέα-παιδιού ώστε η ανάκτηση να μπορεί να τα ενώσει ξανά αν χρειαστεί.
Απόκλιση μεταξύ βάσεων γνώσεων staging και παραγωγής. Οι ομάδες κατασκευάζουν ένα sync pipeline έναντι μιας βάσης staging, αντιγράφουν τη διαμόρφωση του πράκτορα στην παραγωγή, και ξεχνούν ότι ο πράκτορας παραγωγής εξακολουθεί να δείχνει στα χειροκίνητα ανεβασμένα αρχεία του περασμένου τριμήνου. Κάντε το ID της βάσης γνώσεων ρητό στη διαμόρφωση ανάπτυξής σας και επαληθεύστε το μετά από κάθε έκδοση.
Ναι. Η αρχιτεκτονική είναι πιστοποίηση service-principal μέσω Microsoft Entra ID, αρχεία που τραβιούνται μέσω ενός πιστοποιημένου καναλιού Graph, και ανεβάσματα που προωθούνται στο API της βάσης γνώσεων μέσω HTTPS. Τα έγγραφα πηγής παραμένουν στο SharePoint με τα υπάρχοντα ACLs τους. Η βάση γνώσεων κρατά ένα ευρετηριασμένο αντίγραφο που χρησιμοποιείται μόνο για ανάκτηση κατά τη διάρκεια κλήσεων, και μπορείτε να περιορίσετε το scope του service principal σε ένα μόνο site αν το απαιτεί η συμμόρφωση.
Πέντε έως δεκαπέντε λεπτά από άκρο σε άκρο στην ευτυχή διαδρομή. Η ανάλυση: παράδοση webhook Graph μέσα σε λίγα λεπτά, delta query και λήψη σε λιγότερο από ένα λεπτό, ανάλυση και embedding σε ένα έως τρία λεπτά ανάλογα με το μέγεθος του εγγράφου. Μόλις ευρετηριαστεί, η ανάκτηση προσθέτει κάτω από 100 χιλιοστά του δευτερολέπτου κατά τη διάρκεια της ίδιας της κλήσης, οπότε οι καλούντες δεν αντιλαμβάνονται παύση.
Μια καθημερινή εργασία συμφωνίας επαναλαμβάνει το delta query και συγκρίνει τα αποτελέσματα έναντι του manifest της βάσης γνώσεων, εντοπίζοντας οτιδήποτε έχασε το Event Grid ή το Graph. Ο συνδυασμός webhooks πραγματικού χρόνου και μιας καθημερινής σάρωσης delta είναι το τυπικό μοτίβο, που συνιστάται στα ίδια τα κείμενα μηχανικής της Microsoft ακριβώς επειδή οι ειδοποιήσεις είναι best-effort.
Ναι. Το ίδιο μοτίβο worker εφαρμόζεται στο Google Drive (μέσω του Drive Activity API), στο Amazon S3 (μέσω S3 Event Notifications), στο Confluence, στο Notion, και σε οποιαδήποτε πηγή εκπέμπει συμβάντα αλλαγής. Το API της βάσης γνώσεων είναι αγνωστικό ως προς την πηγή. Το μόνο κομμάτι που αλλάζει είναι ο κώδικας auth και ακρόασης συμβάντων.
Ο connector του SharePoint στο Copilot Studio δεν ανανεώνεται αυτόματα όταν αλλάζουν τα αρχεία, ένας περιορισμός που η Microsoft επιβεβαίωσε στα μέσα του 2025 και για τον οποίο δεν έχει κυκλοφορήσει διόρθωση τη στιγμή της συγγραφής. Οι λύσεις παράκαμψης περιλαμβάνουν ροές Power Automate που ενεργοποιούν χειροκίνητες ανανεώσεις. Πέρα από το πρόβλημα συγχρονισμού, το Copilot Studio είναι κατασκευασμένο για επιφάνειες chat και δεν παράγει φωνητική καθυστέρηση κάτω του δευτερολέπτου. Για τηλεφωνικούς πράκτορες, η αρχιτεκτονική σε αυτόν τον οδηγό είναι η διαδρομή.
Η Retell AI παρέχεται με SOC 2 Type II, HIPAA με self-service BAA, και GDPR, συν παραμετροποιήσιμη διατήρηση δεδομένων και απόκρυψη PII. Για φόρτους εργασίας υγειονομικής περίθαλψης, το τυπικό μοτίβο είναι να θέσετε ως προϋπόθεση το BAA πριν αγγίξει το ευρετήριο οποιοδήποτε PHI. Η στάση συμμόρφωσης έναντι του συγκεκριμένου ρυθμιστικού σας καθεστώτος είναι δική σας ευθύνη να την επικυρώσετε. Οι πιστοποιήσεις σε επίπεδο υποδομής καλύπτουν την πλατφόρμα, όχι την πολιτική ταξινόμησης του περιεχομένου σας.
Ναι. Ένας πράκτορας μπορεί να έχει πολλαπλές βάσεις γνώσεων συνδεδεμένες, και κάθε βάση μπορεί να αντλεί από ένα διαφορετικό pipeline πηγής. Ένα κοινό μοτίβο είναι μία βάση ανά λογικό τομέα (τιμολόγηση, υποστήριξη, προδιαγραφές προϊόντος) με τις πηγές καθαρά διαχωρισμένες. Οι κόμβοι ροής συνομιλίας μπορούν επίσης να δεσμεύσουν μια διαφορετική βάση σε έναν συγκεκριμένο κόμβο όταν οι διαδρομές πωλήσεων και υποστήριξης χρειάζονται διακριτό πλαίσιο.
Έναν μηχανικό που νιώθει άνετα με OAuth και webhooks για το επίπεδο συγχρονισμού, έναν υπεύθυνο ops για την κατασκευή του πράκτορα και τη ρύθμιση prompt, και έναν υπεύθυνο περιεχομένου που αποφασίζει τι ανήκει στον συγχρονισμένο φάκελο. Ο διαχωρισμός που λειτουργεί στην πράξη: το IT κατέχει τον worker και το auth· τα ops κατέχουν τον πράκτορα· η ομάδα περιεχομένου κατέχει το τι είναι εντός scope. Η αρχιτεκτονική υποστηρίζει μια ρύθμιση ενός ατόμου για proof of concept και κλιμακώνεται χωρίς επανασχεδιασμό αρχιτεκτονικής.
Ο indexer του SharePoint στο Azure AI Search διαχειρίζεται καλά την απορρόφηση αλλά έχει σκληρά όρια που αξίζει να γνωρίζετε. Δεν υποστηρίζει tenants με ενεργοποιημένο Conditional Access. Η διατήρηση ACL είναι σε public preview, όχι GA. Η καθυστέρηση ανανέωσης τρέχει σε ώρες, όχι λεπτά. Και εξακολουθείτε να χρειάζεται να χτίσετε το επίπεδο φωνητικού πράκτορα από πάνω. Για καθαρή επιχειρησιακή αναζήτηση, το AI Search είναι εντάξει. Για φωνή, το μοτίβο sync-into-Retell-AI είναι λειτουργικά απλούστερο και ταχύτερο στην ανάπτυξη.
Αναδρομικός διαχωρισμός 512 tokens με 10 έως 20 τοις εκατό επικάλυψη. Αυτή είναι η επικυρωμένη από benchmark προεπιλογή στις αξιολογήσεις του 2026 και υπερτερεί του σημασιολογικού chunking κατά περίπου 15 μονάδες σε πραγματικά σώματα εγγράφων. Τρία chunks που ανακτώνται στην προεπιλεγμένη ομοιότητα. Ρυθμίστε μόνο αφού έχετε 50 έως 100 πραγματικές μεταγραφές κλήσεων για να ενημερώσετε την αλλαγή.
Το sync pipeline είναι το άχαρο μισό του φωνητικού AI, και είναι επίσης το μισό που αποφασίζει αν η ανάπτυξη θα δημοσιευτεί ή θα κολλήσει. Ένα pilot που "λειτουργεί σε δεδομένα demo" και καταρρέει τη στιγμή που αλλάζει μια πολιτική είναι ο χαρακτηριστικός τρόπος αποτυχίας σε αυτόν τον χώρο, και η παραπάνω αρχιτεκτονική είναι η λύση.
Μόλις η βάση γνώσεων είναι σταθερή, ο ίδιος πράκτορας επεκτείνεται σε παρακείμενες ροές εργασίας πάνω στα ίδια δεδομένα. Υποστήριξη πελατών με AI για εισερχόμενες ερωτήσεις, αξιολόγηση leads για εξερχόμενες, ένας ρεσεψιονίστ που δρομολογεί σε οποιοδήποτε από τα δύο. Το σώμα εγγράφων που έχετε επιμεληθεί για ένα γίνεται η πηγή αλήθειας για όλα τους.
Ξεκινήστε δωρεάν με $10 σε πίστωση στο retellai.com.
See how much your business could save by switching to AI-powered voice agents.
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Ένας αριθμός τηλεφώνου Demo από το Retell Clinic Office
Start building smarter conversations today.
.avif)
.avif)
