Τη στιγμή που το gateway καταγράφει prompts και completions, κρατά ό,τι πληκτρολόγησε ο χρήστης ενός customer-service agent σε ένα chat box, που μπορεί να περιλαμβάνει μια διεύθυνση, έναν αριθμό λογαριασμού, ή ένα παράπονο για την υγεία του. Κάθε άλλη απόφαση σε αυτή τη σειρά αντάλλασσε κόστος με latency ή έλεγχο με ευκολία. Αυτή ανταλλάσσει τη δυνατότητα debugging με μια υποχρέωση προστασίας δεδομένων, και είναι η τελευταία επειδή είναι αυτή που χρειάζεται όλα τα υπόλοιπα ήδη στη θέση τους. Το Μέρος 9 έβαλε την πλατφόρμα να παραδίδει. Αυτό το μέρος την κλείνει: τι να καταγράφεις, τι να παρακολουθείς, τι ζητά η ρύθμιση, και αν οι αριθμοί από το Μέρος 1 όντως κινήθηκαν.

Τρία layers, και αυτό που χτίζεις μόνος σου

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

  • Gateway telemetry. Token metrics στο Application Insights με τις διαστάσεις tenant, model alias, και environment από το Μέρος 5, συν request logs στο Azure Monitor. Αυτή είναι η αυθεντική εικόνα του ποιος κάλεσε τι και τι κόστισε, και είναι το μόνο layer που βλέπει κάθε σύγχρονο request.
  • Application telemetry. Τα traces του ίδιου του orchestration layer: ποια tools έτρεξαν, πόσες επαναλήψεις του loop, ποια ανακτημένα έγγραφα μπήκαν στο prompt. Εργαλεία ειδικά για LLM όπως το LangSmith ή το Openlayer ζουν εδώ, και μια ομάδα data science που ήδη χρησιμοποιεί Dataiku θα θέλει τη δική της εικόνα των ίδιων δεδομένων. Κανένα από αυτά δεν βλέπει κίνηση που δεν περνά από την εφαρμογή που τα εκπέμπει, κάτι που αξίζει να λέγεται δυνατά κάθε φορά που κάποιος προτείνει ένα από αυτά ως την πηγή αλήθειας της πλατφόρμας.
  • Σήματα μοντέλου και ασφάλειας. Content safety blocks, αρνήσεις, κατηγορίες φίλτρων που ενεργοποιήθηκαν. Αυτά έρχονται από την πολιτική του gateway και ανήκουν στο layer του gateway, όχι της εφαρμογής, γιατί όλο το νόημα είναι ότι ισχύουν ακόμα κι όταν η εφαρμογή συμπεριφέρεται λάθος.

Το layer που κατέχει η ομάδα πλατφόρμας και κανείς άλλος δεν θα χτίσει είναι το join: ένα correlation ID που ακολουθεί μια αλληλεπίδραση χρήστη και στα τρία, ώστε μια ερώτηση που πυροδότησε τέσσερα tool calls και ένα content safety block να είναι ένα πράγμα σε ένα query αντί για έξι άσχετες εγγραφές. Το Μέρος 8 έβαλε αυτό το ID στην εγγραφή του log. Γι' αυτό υπήρχε.

Τι να καταγράφεις, και τι όχι

Η καταγραφή prompts και completions είναι πραγματικά χρήσιμη: έτσι κάνεις debug μια κακή απάντηση, χτίζεις το golden set από πραγματική κίνηση, και αποδεικνύεις τι είπε το σύστημα όταν κάποιος το αμφισβητεί. Επίσης μετατρέπει το log store σε αποθήκη περιεχομένου χρηστών άγνωστης ευαισθησίας, αντιγραμμένη όπου κι αν πηγαίνουν αυτά τα logs.

Η βιώσιμη θέση είναι ανά προϊόν αντί για καθολική, και είναι απόφαση που παίρνει η ομάδα-καταναλωτής μαζί με την πλατφόρμα, όχι απόφαση που παίρνει η πλατφόρμα για όλους:

  • Κατέγραφε πάντα τα metadata: tenant, alias, επιλυμένο deployment και έκδοση, μετρήσεις tokens, latency, status, cache hit, αποτέλεσμα content safety, correlation ID. Τίποτα από αυτά δεν είναι περιεχόμενο χρήστη και όλα απαντούν στα λειτουργικά ερωτήματα.
  • Κατέγραφε περιεχόμενο κατ' εξαίρεση, με retention μικρότερο από αυτό των metadata, περιορισμένο στα προϊόντα που το επέλεξαν, και με το subscription key αφαιρεμένο από το request όπως απαιτούσε το Μέρος 5.
  • Κάνε sampling αντί να συλλαμβάνεις τα πάντα όπου η καταγραφή περιεχομένου είναι ενεργή. Ένα αντιπροσωπευτικό δείγμα κάνει debug εξίσου καλά με μια πλήρη σύλληψη για τους περισσότερους σκοπούς και μειώνει την έκθεση αναλογικά.

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

Evals στην παραγωγή, όχι μόνο στο pipeline

Το eval gate του Μέρους 9 απαντά στο «είναι ασφαλές να βγει αυτή η αλλαγή». Δεν απαντά στο «είναι ακόμα καλό το σύστημα», γιατί η κίνηση παραγωγής δεν είναι το golden set και απομακρύνεται από αυτό συνεχώς.

Δύο μηχανισμοί, και απαντούν σε διαφορετικά ερωτήματα. Τα προγραμματισμένα evals τρέχουν το golden set απέναντι στη ρύθμιση παραγωγής με χρονοδιακόπτη, που πιάνει drift σε πράγματα που κανείς δεν έκανε deploy: μια έκδοση μοντέλου που μετακινήθηκε παρά το κάρφωμα, ένα index που ξαναχτίστηκε διαφορετικά, μια διαδρομή retrieval που έγινε πιο αργή. Η δειγματοληπτική online αξιολόγηση βαθμολογεί ένα μικρό μερίδιο της πραγματικής κίνησης, συνήθως με model-as-judge, και είναι ο μόνος τρόπος να προσέξεις μια κατηγορία αποτυχίας που το golden set δεν περιείχε ποτέ, γιατί το golden set εξ ορισμού αποτελείται από αποτυχίες που ήδη ήξερες.

Και οι δύο χρειάζονται ένα μέρος για το αποτέλεσμα, και είναι το ίδιο μέρος με όλα τα άλλα: ένα σκορ με τις διαστάσεις tenant και alias, στο ίδιο dashboard με τη δαπάνη και το latency. Ένας αριθμός ποιότητας που ζει σε ξεχωριστό εργαλείο κοιτάζεται στα incidents και αγνοείται τον υπόλοιπο χρόνο.

Διακυβέρνηση, και τι πραγματικά ζητά η ρύθμιση

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

  • Ποια μοντέλα χρησιμοποιούνται, σε ποιες εφαρμογές, σε ποιες εκδόσεις; Το model catalog και ο χάρτης των aliases το απαντούν. Χωρίς αυτά είναι ένα ερωτηματολόγιο προς τις ομάδες.
  • Ποια δεδομένα πήγαν σε ποιον πάροχο, και πού έγινε η επεξεργασία; Η ρύθμιση του backend pool και τα request logs το απαντούν ανά request, που είναι και η απάντηση σε ένα ερώτημα data residency για μια συγκεκριμένη περιοχή.
  • Ποιοι έλεγχοι ασφάλειας ίσχυαν, και ενεργοποιήθηκαν; Η πολιτική content safety είναι versioned στο repository και τα αποτελέσματά της καταγράφονται ανά request.
  • Ποιος μπορούσε να καλέσει τι, και πότε άλλαξε αυτό; Η ρύθμιση των tenants είναι Terraform, οπότε η απάντηση είναι ένα git history και όχι μια ανάμνηση.
  • Μπορεί μια συγκεκριμένη αλληλεπίδραση να ανακατασκευαστεί; Μόνο αν η καταγραφή περιεχομένου ήταν ενεργή για εκείνο το προϊόν, που είναι ακριβώς ο λόγος που αυτή η απόφαση είναι ανά προϊόν και γραμμένη, όχι σιωπηρή.

Το σημείο που αξίζει να κρατήσεις: το gateway είναι αυτό που κάνει αυτά τα ερωτήματα καν απαντήσιμα. Πέντε εφαρμογές που καλούν πέντε model endpoints απευθείας μπορούν να παράγουν πέντε διαφορετικές απαντήσεις σε κάθε ερώτημα, και ο κόπος της συμφιλίωσής τους είναι το κόστος συμμόρφωσης που αφαίρεσε η επένδυση στην πλατφόρμα.

Το scorecard

Το Μέρος 1 έθεσε πέντε στόχους. Ειλικρινής βαθμολόγηση, μαζί με αυτόν που δεν προσγειώθηκε καθαρά.

  • Κάθε product owner βλέπει τη δική του δαπάνη σε tokens μέσα σε μια μέρα. Πιάστηκε, με τις κλάσεις ακρίβειας από το Μέρος 3 δηλωμένες πάνω στο report: ακριβής μέτρηση για non-streamed και batch, εκτίμηση για streamed, με δημοσιευμένο υπόλοιπο σφάλματος.
  • Καμία εφαρμογή δεν κρατά μακρόβιο credential μοντέλου. Πιάστηκε. Οι εφαρμογές κρατούν ένα Entra ID client credential και ένα subscription key προϊόντος· κανένα από τα δύο δεν φτάνει σε model endpoint, και η ανάκληση είναι μια αλλαγή ρύθμισης.
  • Μια ειδοποίηση απόσυρσης παράγει ένα query, όχι μια έρευνα. Πιάστηκε, και χρειάστηκε τρεις προηγούμενες αποφάσεις αντί για ένα εργαλείο: καρφωμένες εκδόσεις, aliases, και καταγραφή ανά request του επιλυμένου deployment.
  • Ένας tenant δεν μπορεί να εξαντλήσει το quota ενός άλλου. Πιάστηκε για τη σύγχρονη κίνηση μέσω counter keys ανά subscription. Το batch περιορίζεται από το ότι το control plane είναι ο μόνος υποβολέας, που είναι έλεγχος διαδικασίας και όχι επιβεβλημένος, και αυτό το κενό πρέπει να ονομάζεται αντί να στρώνεται.
  • Latency του gateway κάτω από 60 ms στο 95ο εκατοστημόριο για μη-cached κλήσεις. Αυτός είναι ο στόχος που μετράς αντί να υποθέτεις, και είναι ο αριθμός ο πιο ευαίσθητος σε επιλογές που έγιναν για άλλους λόγους: ο έλεγχος content safety προσθέτει μια κλήση πριν από το μοντέλο, το semantic cache lookup προσθέτει μια κλήση embedding, και τα δύο υιοθετήθηκαν για καλούς λόγους που κοστίζουν milliseconds. Μια πλατφόρμα που τα πρόσθεσε όλα χωρίς να ξαναμετρήσει έχει αλλάξει σιωπηλά το ίδιο της το SLO.

Τι κόστισε αυτό, και πότε δεν αξίζει

Η σειρά θα ήταν ανειλικρινής χωρίς αυτή την ενότητα. Ένα κεντρικό gateway είναι μια ομάδα πλατφόρμας, ένα API Management instance σε tier που επιλέχθηκε για ένα schema και όχι για το φορτίο, μια Redis cache με ένα module που δεν προστίθεται αργότερα, ένα deployment embeddings που εξυπηρετεί δύο σκοπούς, και ένα control plane που είναι πραγματική υπηρεσία με πραγματικό on-call. Αυτό είναι πάγιο κόστος, και αγοράζει attribution, διακυβέρνηση, και μια ιστορία κύκλου ζωής.

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

Διάβασε επίσης

Για την πλευρά υποδομής και πλατφόρμας της λειτουργίας κάτι τέτοιου σε κλίμακα, οι σημειώσεις πεδίου είναι στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.

Αναφορές