Παρατηρησιμότητα LLM σε πύλη API πολλαπλών μοντέλων: Traces, Token Ledgers, Tenant Analytics και Safe Prompt Logging

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

Αυτό το άρθρο περιγράφει έναν πρακτικό σχεδιασμό για Αναλυτικά στοιχεία χρήσης AI και παρατηρησιμότητα LLM σε μια πύλη που απευθύνεται σε πολλούς παρόχους μέσω ενός API συμβατό με OpenAI. Το μοτίβο είναι χρήσιμο ακόμα κι αν δεν χρησιμοποιείτε συγκεκριμένο προμηθευτή: όργανο μία φορά στην πύλη, κανονικοποίηση της τηλεμετρίας του μοντέλου, διατήρηση της απόδοσης χρέωσης και λήψη περιεχομένου προτρεπτικού μόνο βάσει ρητής πολιτικής.

Το πρόβλημα του αναγνώστη: "Ποιος μισθωτής, μοντέλο, προτροπή ή διαδρομή ανάκτησης προκάλεσε την αλλαγή;"

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

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

• Ποιος μισθωτής ή κλειδί API προκάλεσε αύξηση δαπανών;
• Αυξήθηκε η καθυστέρηση μετά την αλλαγή ενός ψευδωνύμου μοντέλου;
• Οι επαναλήψεις ή οι εναλλακτικές μετράνε διπλό κόστος;
• Ποια έκδοση προτροπής καίει τον περισσότερο προϋπολογισμό σφαλμάτων;
• Η ροή εργασίας RAG έγινε ακριβή επειδή η ανάκτηση πρόσθεσε πάρα πολλά διακριτικά περιβάλλοντος;
• Μπορεί να υποστηριχθεί ο εντοπισμός σφαλμάτων ενός περιστατικού χωρίς την ανάγνωση των μηνυμάτων ιδιωτών χρηστών;

Γεγονότα, προτάσεις και προβλέψεις

Γεγονότα: Το OpenTelemetry τεκμηριώνει Δημιουργικές σημασιολογικές συμβάσεις και χαρακτηριστικά τεχνητής νοημοσύνης για λειτουργίες μοντέλων, συμπεριλαμβανομένων ονομάτων λειτουργιών όπως chat, generate_content και text_completion. Η ίδια τεκμηρίωση προειδοποιεί ότι τα χαρακτηριστικά μηνυμάτων εισόδου και εξόδου GenAI ενδέχεται να περιέχουν ευαίσθητες πληροφορίες ή PII και μπορεί να απαιτούν φιλτράρισμα ή περικοπή. Οι μεγάλοι πάροχοι μοντέλων εκθέτουν επίσης πίνακες εργαλείων χρήσης, API ή εξαγωγές που μπορούν να υποστηρίξουν τη συμφωνία από την πλευρά του παρόχου, αν και οι λεπτομέρειες διαφέρουν ανά πάροχο.

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

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

Αρχιτεκτονική αναφοράς: παρατηρήστε ολόκληρη τη διαδρομή αιτήματος

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

Προτεινόμενη δομή εύρους

• Εύρος αιτήματος πύλης: το αίτημα έγινε αποδεκτό, επαληθεύτηκε, εξουσιοδοτήθηκε, περιορίστηκε με ρυθμό και δρομολογήθηκε.
• Μοντέλο εύρος κλήσης: πάροχος, μοντέλο, λειτουργία, χρήση διακριτικού, κατάσταση απόκρισης και καθυστέρηση.
• Διάρκεια ανάκτησης: ερώτημα ευρετηρίου, αναγνωριστικά εγγράφων ή κατακερματισμένα αναγνωριστικά, πλήθος τμημάτων, λανθάνουσα κατάσταση ανάκτησης και μερίδιο διακριτικού περιβάλλοντος.
• Εύρος κλήσης εργαλείου: όνομα εργαλείου, κατάσταση, καθυστέρηση, κατηγορία σφάλματος και ταξινόμηση παρενεργειών.
• Διάρκεια επανάληψης: επαναλάβετε την αιτία, τον αριθμό προσπάθειας, την κατάσταση του παρόχου και το αυξητικό κόστος.
• Επικουρικό διάστημα: αρχικό μοντέλο, εναλλακτικό μοντέλο, έναυσμα, πολιτική συμβατότητας και τελικό αποτέλεσμα.
• Περιοχή προστασίας ή εποπτείας: επίκληση πολιτικής, απόφαση, ετικέτες και εάν η έξοδος αποκλείστηκε ή μετασχηματίστηκε.
• Περιοχή μετά την επεξεργασία: Επικύρωση JSON, επιδιόρθωση σχήματος, έλεγχοι παραπομπών ή τελική μορφοποίηση.

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

Κανονοποίηση των μεταδεδομένων που καταγράφονται σε κάθε κλήση LLM

Κάθε αίτημα μοντέλου θα πρέπει να παράγει μια σταθερή εγγραφή, ανεξάρτητα από τον πάροχο. Το ακριβές σχήμα θα ποικίλλει, αλλά ένα πρακτικό ελάχιστο μοιάζει με αυτό:

{
  "request_id": "req_01J...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "tenant_id": "tenant_123",
  "team_id": "team_456",
  "app_id": "support_bot",
  "gateway_key_id": "key_789",
  "λειτουργία": "συνομιλία",
  "πάροχος": "όνομα_παροχέα",
  "model": "provider-model-id",
  "model_alias": "fast-support-chat",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "ολοκληρώθηκε",
  "error_class": null,
  "latency_ms": 1842,
  "input_tokens": 2110,
  "output_tokens": 384,
  "cached_input_tokens": 1200,
  "estimated_cost_usd": "0.00492",
  "final_billed_cost_usd": null,
  "finish_reason": "stop",
  "retry_count": 0,
  "fallback_used": ψευδής,
  "content_capture_policy": "μεταδεδομένα_μόνο"
}

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

Δημιουργήστε ένα διακριτικό και ένα βιβλίο κόστους, όχι μόνο μετρητές

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

Χρήσιμες καταστάσεις βιβλίου

• έγιναν αποδεκτές: Ο έλεγχος ταυτότητας και οι έλεγχοι πολιτικής πέρασαν.
• προώθησε: το αίτημα στάλθηκε σε έναν πάροχο.
• Ροή: ο πάροχος άρχισε να επιστρέφει διακριτικά.
• ολοκληρώθηκε: η απάντηση ολοκληρώθηκε με επιτυχία.
• user_aborted: ο πελάτης αποσυνδέθηκε πριν από την ολοκλήρωση.
• δοκιμάστηκε ξανά: έγινε μια επιπλέον προσπάθεια παρόχου.
• fallback_used: επιλέχθηκε διαφορετικό μοντέλο ή πάροχος μετά από αποτυχία ή αντιστοίχιση πολιτικής.
• απέτυχε: το αίτημα έληξε χωρίς απάντηση που μπορεί να χρησιμοποιηθεί.
• συμφωνήθηκε: συγκρίθηκαν και εφαρμόστηκαν δεδομένα χρήσης ή κόστους από την πλευρά του παρόχου.

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

Χρησιμοποιήστε τις συμβάσεις OpenTelemetry GenAI και, στη συνέχεια, επεκτείνετε προσεκτικά

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

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

• αναγνωριστικό μισθωτή, αναγνωριστικό ομάδας, αναγνωριστικό πελάτη μεταπωλητή και αναγνωριστικό εφαρμογής,
• Αναγνωριστικό κλειδιού API πύλης και εύρος κλειδιού;
• πρόγραμμα χρέωσης, όριο δαπανών και πολιτική προϋπολογισμού.
• ψευδώνυμο μοντέλου και έκδοση πολιτικής δρομολόγησης;
• αναγνωριστικό προτύπου προτροπής και έκδοση προτροπής;
• όνομα ροής εργασίας και βήμα ροής εργασίας;
• εκτιμώμενο κόστος, τελικό κόστος και κατάσταση συμφωνίας.

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

Σχεδιάστε ασφαλή ειδοποίηση και καταγραφή εξόδου

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

Προεπιλογή: μόνο μεταδεδομένα

Για την περισσότερη επισκεψιμότητα παραγωγής, αποθηκεύστε:

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

Opt-in: ελεγχόμενη λήψη περιεχομένου

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

Μην αντιμετωπίζετε την έκδοση ως τέλεια. Μειώνει τον κίνδυνο. δεν το εξαφανίζει. Για ρυθμιζόμενους ή υψηλής ευαισθησίας φόρτους εργασίας, σκεφτείτε να αποθηκεύσετε μόνο τα hashes και να αναπαράγετε προβλήματα σε μια συνθετική ζώνη με εγκεκριμένα δεδομένα δοκιμής.

Προσθέστε παρατηρησιμότητα RAG ως ξεχωριστό επίπεδο

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

Για κάθε βήμα ανάκτησης, καταγράψτε:

• όνομα ευρετηρίου ή συλλογής;
• στρατηγική ανάκτησης και μοντέλο ενσωμάτωσης,
• αναγνωριστικά εγγράφων ή κατακερματισμένα αναγνωριστικά,
• πλήθος κομματιών και συνολικά διακριτικά περιβάλλοντος;
• λανθάνουσα κατάσταση ανάκτησης;
• διανομή κορυφαίας βαθμολογίας, εάν είναι διαθέσιμη;
• κάλυψη παραπομπών;
• αν χρησιμοποιήθηκε το ανακτηθέν πλαίσιο στην τελική απάντηση.

Αυτό σας επιτρέπει να διακρίνετε το "το μοντέλο χειροτέρεψε" από το "το retriever άρχισε να στέλνει περιεχόμενο χαμηλής ποιότητας ή υπερβολικό". Βοηθά επίσης στον εντοπισμό ροών εργασίας όπου τα διακριτικά περιβάλλοντος κυριαρχούν στο συνολικό κόστος.

Συμφωνία χρήσης πύλης με χρέωση παρόχου

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

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

Κοινές διαφορές συμφιλίωσης

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

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

Πίνακες ελέγχου που απαντούν σε λειτουργικές ερωτήσεις

Ξεκινήστε τους πίνακες εργαλείων από προβλήματα αναγνωστών και όχι από μετρήσεις ματαιοδοξίας. Οι χρήσιμες προβολές περιλαμβάνουν:

• κόστος ανά μισθωτή, ομάδα, εφαρμογή και ροή εργασίας,
• κόστος ανά επιτυχημένη εργασία, όχι μόνο κόστος ανά αίτημα.
• λανθάνουσα κατάσταση p50, p95 και p99 ανά πάροχο, μοντέλο και ψευδώνυμο μοντέλου.
• ποσοστό επιστροφής και ρυθμός επανάληψης κατά διαδρομή;
• ποσοστό χρονικού ορίου λήξης και τάσεις κατηγορίας σφαλμάτων παρόχου,
• αναλογία επίσκεψης στην κρυφή μνήμη και εκτίμηση εξοικονόμησης κρυφής μνήμης,
• ποσοστό αποτυχίας επικύρωσης δομημένης παραγωγής,
• κορυφαίες εκδόσεις μέσω σφάλματος εγγραφής προϋπολογισμού;
• Κοινή χρήση διακριτικού περιβάλλοντος RAG ανά ροή εργασίας.
• μπλοκ προστατευτικών κιγκλιδωμάτων και χτυπήματα ταξινομητή προτροπής έγχυσης.

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

Ελάχιστη ροή υλοποίησης για διακομιστή μεσολάβησης συμβατό με OpenAI

Για έναν διακομιστή μεσολάβησης /chat/completions, η ροή μπορεί να είναι απλή:

1. Λάβετε το αίτημα και αντιστοιχίστε request_id και ανιχνεύστε το πλαίσιο.
2. Επαληθεύστε το κλειδί πύλης και επιλύστε το πεδίο εφαρμογής μισθωτή, ομάδα, εφαρμογή και πολιτική.
3. Δημιουργήστε το εύρος της γονικής πύλης.
4. Δημιουργήστε μια σειρά καθολικού με κατάσταση αποδεκτό.
5. Επιλύστε το ψευδώνυμο μοντέλου σε μοντέλο παρόχου και έκδοση πολιτικής δρομολόγησης.
6. Εγγραφή μεταδεδομένων: λειτουργία, αναγνωριστικό προτύπου προτροπής, όνομα σχήματος, κατακερματισμός προτροπής και πολιτική καταγραφής περιεχομένου.
7. Ξεκινήστε το εύρος κλήσης μοντέλου χρησιμοποιώντας σημασιολογικά χαρακτηριστικά GenAI, όπου ισχύει.
8. Προωθήστε το αίτημα στον επιλεγμένο πάροχο.
9. Για ροή, ενημερώστε την κατάσταση όταν φτάσει το πρώτο κομμάτι και μετρήστε τη χρήση με την ακρίβεια που επιτρέπει η απάντηση του παρόχου.
10. Μετά την ολοκλήρωση, αναλύστε τη χρήση του παρόχου, την αιτία λήξης, την κατάσταση και την κατηγορία σφάλματος.
11. Ενημερώστε το καθολικό με διακριτικά, εκτιμώμενο κόστος, λεπτομέρειες επανάληψης/εναλλακτικής δοκιμής και τελική κατάσταση αιτήματος.
12. Εκπέμψτε μετρήσεις από το καθολικό και δεδομένα εμβέλειας.
13. Εκτέλεση ημερήσιας συμφωνίας και κόστος επιβεβαιωμένου από τον πάροχο καταστήματος ξεχωριστά από την αρχική εκτίμηση.

Λίστα ελέγχου διάθεσης

• Καθορίστε κανονικά αναγνωριστικά αιτημάτων και αναγνωριστικά ίχνους.
• Υιοθετήστε τα χαρακτηριστικά OpenTelemetry GenAI για την τηλεμετρία κοινού μοντέλου.
• Δημιουργήστε ένα καθολικό χρήσης πύλης με μεταβάσεις κατάστασης αιτήματος.
• Κανονισμός διαστάσεων παρόχου, μοντέλου, ψευδωνύμου μοντέλου, μισθωτής, εφαρμογής και ροής εργασίας.
• Διατηρήστε τα δεδομένα έρευνας υψηλής συσχέτισης μακριά από ετικέτες μετρήσεων.
• Απενεργοποιήστε την ακατέργαστη ερώτηση και τη λήψη εξόδου από προεπιλογή.
• Προσθέστε ρητές πολιτικές για δειγματοληψία, επεξεργασία, διατήρηση και έλεγχο πρόσβασης.
• Λήψη μεταδεδομένων ανάκτησης για ροές εργασίας RAG.
• Δημιουργήστε πίνακες ελέγχου για το κόστος, τον λανθάνοντα χρόνο, την αξιοπιστία, την επικύρωση και τη συμπεριφορά του μισθωτή.
• Συμφωνήστε τις εκτιμήσεις πύλης με τη χρήση παρόχου και τις εξαγωγές κόστους.
• Ειδοποίηση για αυξήσεις δαπανών, παλινδρομήσεις λανθάνοντος χρόνου, εναλλακτικά άλματα, αποτυχίες επικύρωσης και συμβάντα που σχετίζονται με την ασφάλεια.

Συμπέρασμα

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

Ξεκινήστε με μεταδεδομένα, μεταβάσεις καταστάσεων και συμφωνία. Προσθέστε λήψη περιεχομένου μόνο όταν η πολιτική, η διατήρηση και τα στοιχεία ελέγχου πρόσβασης είναι έτοιμα. Αυτή η ακολουθία παρέχει στους προγραμματιστές τα στοιχεία που χρειάζονται για να διορθώσουν τον λανθάνοντα χρόνο, την ποιότητα και να δαπανήσουν χωρίς να μετατρέψουν την παρατηρησιμότητα σε νέο κίνδυνο έκθεσης δεδομένων.

Σχετική ανάγνωση

• Δρομολόγηση API LLM
• μοτίβα προσωρινής αποθήκευσης προτροπής και ελέγχου κόστους παρτίδας
• διαχείριση κλειδιών API ομάδας και όρια δαπανών