Στα Azure Pipelines, ένα approval που δεν ολοκληρώνεται μέσα στο timeout του μαρκάρει το stage ως skipped, όχι failed. Ένα skipped stage είναι πράσινο στα περισσότερα dashboards και στα περισσότερα notification templates, οπότε ένα model promotion που δεν κοίταξε κανείς μπορεί να ολοκληρώσει ένα pipeline run που αναφέρει επιτυχία ενώ η αλλαγή δεν βγήκε ποτέ, ή χειρότερα, ενώ ένα προηγούμενο stage έκανε ήδη τη μισή δουλειά. Το Μέρος 8 έβαλε τις εφαρμογές πάνω από το gateway. Αυτό το μέρος βάζει το ίδιο το gateway στην παραγωγή με επαναλήψιμο τρόπο, και μετατρέπει το email απόσυρσης μοντέλου από το Μέρος 1 σε ένα database query.

Τι ακριβώς γίνεται deploy

Τέσσερα artifacts, που αλλάζουν με τρεις διαφορετικούς ρυθμούς, και γι' αυτό είναι τρία pipelines αντί για ένα.

  • Υποδομή πλατφόρμας από το Μέρος 2, το layer 10-platform: API Management, AKS, δίκτυο, observability. Αλλάζει λίγες φορές τον χρόνο, γίνεται deploy με ανθρώπινο approval, και κανείς δεν βιάζεται.
  • Model deployments και ρύθμιση του gateway, το layer 20-models μαζί με το policy XML και τον χάρτη των aliases. Αλλάζει κάθε εβδομάδα. Αυτό είναι το pipeline που χρειάζεται το eval gate.
  • Ρύθμιση tenants, το layer 30-tenants. Αλλάζει στο onboarding, και είναι το ένα σημείο όπου ένα self-service pull request από μια ομάδα-καταναλωτή έχει νόημα.
  • Το container του control plane στο AKS. Συνηθισμένο application CI/CD, και το λιγότερο ενδιαφέρον από τα τέσσερα ακριβώς επειδή είναι συνηθισμένο.

Το policy XML αξίζει δική του σημείωση. Εκτελείται σε κάθε request, άρα είναι κώδικας παραγωγής, και φτάνει στην παραγωγή μέσα από το ίδιο pipeline με το ίδιο review όπως το Terraform. Το portal είναι για διάβασμα, όχι για επεξεργασία, και ο τρόπος να ισχύσει αυτό στην πράξη είναι ένα drift check στο pipeline που αποτυγχάνει όταν η deployed policy διαφέρει από το repository.

Το service connection, και το χρονόμετρο που δεν ρυθμίζει κανείς

Τα pipelines αυθεντικοποιούνται στο Azure με ένα Azure Resource Manager service connection, και η προτεινόμενη ρύθμιση είναι το workload identity federation, είτε με app registration είτε με managed identity, που αφαιρεί εντελώς τα secrets και τη διαχείρισή τους από την εικόνα. Για μια πλατφόρμα της οποίας όλο το επιχείρημα του Μέρους 5 αφορούσε τον κύκλο ζωής των credentials, ένα αποθηκευμένο secret εδώ θα ήταν δύσκολο να δικαιολογηθεί.

Δύο λειτουργικές λεπτομέρειες αξίζει να μπουν στο runbook αντί να ανακαλυφθούν. Τα Azure Pipelines απενεργοποιούν αυτόματα service connections που δεν έχουν χρησιμοποιηθεί για 100 μέρες, και ένας administrator του service connection ή ένας Project Administrator πρέπει να τα ενεργοποιήσει ξανά. Ένα pipeline που τρέχει μόνο σε τριμηνιαίες αλλαγές υποδομής είναι ακριβώς το pipeline που σκοντάφτει εδώ, και η αποτυχία έρχεται τη χειρότερη στιγμή, όταν κάτι επείγον χρειάζεται deploy. Και ένα service connection που μετατράπηκε από secret σε federation μπορεί να αναιρεθεί για επτά μέρες· μετά, ένα νέο secret πρέπει να δημιουργηθεί χειροκίνητα, και connections που μετέτρεψες και μετά τροποποίησες χειροκίνητα δεν αναιρούνται καθόλου μέσα από το εργαλείο.

Το eval gate ανήκει στο environment, όχι στο job

Το ένστικτο λέει να προσθέσεις ένα βήμα eval στο τέλος του deploy job. Αυτό κάνει το eval κάτι που κάνει το pipeline, που σημαίνει ότι ο συγγραφέας του pipeline μπορεί να το αναδιατάξει, να το παρακάμψει με ένα condition, ή να το μετακινήσει μετά το deployment που υποτίθεται ότι φύλαγε.

Τα Azure Pipelines έχουν το σωστό primitive: checks πάνω στο environment ή στο service connection που καταναλώνει το stage. Πριν τρέξει ένα stage, όλα τα checks σε όλους τους πόρους που χρησιμοποιεί πρέπει να ικανοποιηθούν, και μία μόνο αρνητική απόφαση απορρίπτει το stage. Ρύθμισε το eval ως Invoke REST API check που καλεί το eval service του control plane, και το gate παύει να ανήκει στον ορισμό του pipeline και αρχίζει να ανήκει στο environment.

Οι κανόνες οριστικότητας μετράνε εδώ. Οι αποφάσεις από approvals και από τα περισσότερα checks είναι οριστικές. Τα checks Invoke Azure Function και Invoke REST API είναι η εξαίρεση, μπορούν να ξανατρέξουν, και αν ορίσεις μη μηδενικό time between evaluations, η απόφαση του check γίνεται μη οριστική και θα επαναξιολογείται. Για ένα eval gate, αυτό είναι σχεδιαστική επιλογή και όχι λεπτομέρεια: ένα μη οριστικό check που συνεχίζει να τρέχει είναι σωστό για το «το eval πρέπει να περνάει ακόμα όταν αυτό το stage επιτέλους ξεκινήσει», και ένα οριστικό είναι σωστό για το «αυτό το build πέρασε τα evals του, στείλ' το». Διάλεξε ένα από τα δύο, και να ξέρεις ότι η ασύγχρονη μορφή ρυθμισμένη με τον προτεινόμενο τρόπο είναι οριστική.

Πρόσθεσε ένα ανθρώπινο approval πάνω από το eval, στο environment της παραγωγής, με ενεργή την επιλογή που εμποδίζει τους approvers να εγκρίνουν τα δικά τους runs. Και όρισε το timeout συνειδητά, εξαιτίας της πρώτης πρότασης αυτού του post: ένα approval που λήγει μαρκάρει το stage ως skipped, και το skipped διαβάζεται πράσινο. Το αντίμετρο είναι ένα σύντομο timeout, ειδοποιήσεις ειδικά για skipped stages, και να μη θεωρείς ποτέ ένα πράσινο pipeline απόδειξη ότι έγινε deployment.

Τι ελέγχει στην πράξη το eval

Ένα golden set από περιπτώσεις που νοιάζουν τους καταναλωτές της πλατφόρμας, versioned στο repository δίπλα στο policy XML, που τρέχει απέναντι στην υποψήφια ρύθμιση μέσα από το gateway και όχι απέναντι σε ένα model endpoint. Το τελευταίο σημείο είναι αυτό που το κάνει platform eval και όχι model benchmark: ασκεί την επίλυση των aliases, τις πολιτικές, το content safety filter, και τη διαδρομή του retrieval, όλα από τα οποία μπορούν να χαλάσουν μια απάντηση χωρίς να αλλάξει καθόλου το μοντέλο.

Τρία κατώφλια, και το τρίτο είναι αυτό που παραλείπει ο κόσμος. Ένα συνολικό σκορ ποιότητας πάνω στο golden set. Ένα latency budget, γιατί ένα μοντέλο οριακά καλύτερο και αισθητά πιο αργό δεν είναι αναβάθμιση για έναν interactive assistant. Και μια λίστα regressions: συγκεκριμένες περιπτώσεις που δεν επιτρέπεται να χειροτερέψουν, ανεξάρτητα από τον μέσο όρο. Μια νέα έκδοση μοντέλου που βελτιώνει τον μέσο όρο ενώ σπάει τα τρία prompts από τα οποία εξαρτάται η ομάδα εξυπηρέτησης πελατών είναι το συνηθισμένο σχήμα μιας κακής προαγωγής, και μόνο η λίστα regressions την πιάνει.

Promotion, canary, και rollback είναι όλα ένας μηχανισμός

Επειδή το Μέρος 3 έβαλε ένα alias μπροστά από ένα backend pool, μια αλλαγή έκδοσης μοντέλου δεν αγγίζει καμία εφαρμογή. Είναι μια αλλαγή ρύθμισης με τρία σχήματα:

  • Canary: πρόσθεσε το νέο deployment στο pool του alias με χαμηλό βάρος στο ίδιο priority group. Ένα μικρό μερίδιο της κίνησης πάει σε αυτό, τα metrics του Μέρους 5 δείχνουν τις διαφορές σε latency και tokens ανά model alias, και τίποτα δεν χρειάστηκε redeploy.
  • Promotion: μετατόπισε τα βάρη, μετά αφαίρεσε το παλιό deployment από το pool.
  • Rollback: η αντίστροφη αλλαγή βαρών. Δευτερόλεπτα, όχι redeploy, που είναι όλο το επιχείρημα για την ύπαρξη του alias.

Το ένα πράγμα που αυτό δεν κάνει είναι να κρατά τις αποκρίσεις πανομοιότυπες εκατέρωθεν του ορίου του canary. Δύο εκδόσεις μοντέλου που σερβίρουν το ίδιο alias παράγουν διαφορετικές εξόδους για το ίδιο prompt, οπότε οτιδήποτε κάνει cache, συγκρίνει, ή αναπαράγει αποκρίσεις πρέπει να ξέρει ποια έκδοση απάντησε. Αυτό είναι ένα πεδίο στο log, που προστίθεται ταυτόχρονα με το canary, όχι εκ των υστέρων.

Η απόσυρση, που τώρα είναι ένα query

Το email απόσυρσης από το Μέρος 1 κόστισε δύο μέρες grep σε repositories. Τώρα πρέπει να κοστίζει ένα query, γιατί τρεις προηγούμενες αποφάσεις έκαναν την απάντηση δυνατή να βρεθεί. Το Μέρος 2 κάρφωσε τις εκδόσεις των μοντέλων και όρισε το version_upgrade_option συνειδητά, οπότε κανένα deployment δεν μετακινείται μόνο του. Το Μέρος 3 έβαλε κάθε εφαρμογή πίσω από ένα alias, οπότε η αντιστοίχιση από alias σε deployment είναι δεδομένα. Το Μέρος 5 κατέγραψε κάθε request με τον tenant του και το επιλυμένο μοντέλο του, οπότε το σύνολο των tenants που πραγματικά χρησιμοποίησαν ένα deployment τις τελευταίες 30 μέρες είναι ένα log query και όχι μια υπόθεση.

Το runbook της απόσυρσης είναι τότε τέσσερα βήματα που χωράνε σε ένα ticket: ρώτησε ποιοι tenants χρησιμοποίησαν πρόσφατα το deployment· στήσε το deployment αντικατάστασης και τρέξε το eval gate πάνω του· κάνε canary το alias και παρακολούθησε τη λίστα regressions· γύρισε τα βάρη και αφαίρεσε το παλιό. Οι εφαρμογές δεν μαθαίνουν ποτέ ότι έγινε οτιδήποτε από αυτά, που είναι το αποτέλεσμα για το οποίο έγινε όλη η σειρά.

Τρόποι αποτυχίας που αξίζει να προσέχεις

  • Το skipped που διαβάζεται ως succeeded. Ένα ληγμένο approval κάνει skip το stage. Βάλε alert ρητά στην κατάσταση skipped, στο notification του pipeline και σε όποιο dashboard κοιτάζει πραγματικά η ομάδα.
  • Το eval ως βήμα του job. Αν μπορεί να αναδιαταχθεί ή να παρακαμφθεί με ένα condition, είναι τεκμηρίωση. Ως environment check είναι gate.
  • Bypass χωρίς ορατότητα. Το bypass ενός check απαιτεί δικαιώματα administrator πάνω στον πόρο και καταγράφεται με το ποιος το έκανε, που είναι καλό, και αξίζει να εμφανίζεται σε ένα εβδομαδιαίο review αντί να μένει στο panel των checks.
  • Ένα service connection απενεργοποιημένο στις 100 μέρες. Το τριμηνιαίο pipeline υποδομής το ανακαλύπτει στη διάρκεια ενός incident.
  • Επεξεργασίες πολιτικής στο portal. Χωρίς drift check, ένα hotfix που έγινε στο portal επιβιώνει μέχρι το επόμενο deploy να το αναιρέσει σιωπηλά, που είναι ο χειρότερος δυνατός συγχρονισμός.
  • Ένα eval set που δεν ενημερώνει κανείς. Ένα golden set που δεν έχει αλλάξει εδώ και έναν χρόνο μετράει το περσινό προϊόν.

Τι κληρονομεί το Μέρος 10

Ένα gateway που φτάνει στην παραγωγή μέσα από pipelines, με evals ως gates και αλλαγές μοντέλων ως ρύθμιση. Κάθε μηχανισμός της σειράς είναι πλέον στη θέση του, και καθένας τους εκπέμπει κάτι. Το τελευταίο μέρος αφορά το τι να κάνεις με αυτό: traces, evals στην παραγωγή αντί για το pipeline, τα ερωτήματα διακυβέρνησης που θέτει το EU AI Act, και τους αριθμούς που υποσχέθηκε το Μέρος 1.

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

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

Αναφορές