Δεν μπορείς να κάνεις αποσφαλμάτωση σε μια εφαρμογή LLM χωρίς logging prompts, και δεν μπορείς να κρατάς αυτά τα prompts αν είναι γεμάτα ονόματα, emails και αριθμούς λογαριασμών. Οι χρήστες πληκτρολογούν προσωπικά αναγνωρίσιμες πληροφορίες κατευθείαν στο κουτί, οπότε το log που σε βοηθά να καταλάβεις μια κακή απόκριση είναι επίσης ένα αυξανόμενο απόθεμα ρυθμιζόμενων δεδομένων που κάθεται στο CloudWatch ή στο S3 με λάθος retention και λάθος ελέγχους πρόσβασης. Η λύση δεν είναι να σταματήσεις το logging. Είναι να κάνεις redact πριν την αποθήκευση και να βάλεις μια πολιτική retention σε ό,τι απομένει, ώστε η αξία αποσφαλμάτωσης να επιβιώνει και η ευθύνη να μην επιβιώνει.

Το reframing: ένα prompt log είναι μια επιφάνεια συλλογής δεδομένων, όχι μια βολικότητα αποσφαλμάτωσης. Τη στιγμή που γράφεις ένα ωμό prompt στον δίσκο έχεις συλλέξει ό,τι έβαλε ο χρήστης μέσα του, κάτω από όποιον κανονισμό καλύπτει αυτά τα δεδομένα. Αντιμετώπισε το pipeline logs ως ένα μέρος όπου το PII αφαιρείται στην είσοδο, όχι ένα μέρος που καθαρίζεις αργότερα αφού ένα audit το ζητήσει.

Redact στην είσοδο, όχι στην έξοδο

Το μόνο αξιόπιστο σημείο για να αφαιρέσεις PII είναι πριν γραφτεί. Το redaction μετά την αποθήκευση σημαίνει ότι τα ωμά δεδομένα υπήρχαν ήδη at rest, ήδη αναπαραγμένα, ήδη σε backups, και το "θα το διαγράψουμε αργότερα" δεν είναι έλεγχος που δέχεται ένας ελεγκτής. Βάλε το βήμα redaction ανάμεσα στο αίτημα και τον προορισμό log, ώστε η τιμή που καταλήγει στην αποθήκευση να μην ήταν ποτέ ευαίσθητη εξαρχής.

Το Amazon Comprehend σου δίνει το primitive ανίχνευσης. Το DetectPiiEntities επιθεωρεί κείμενο σε πραγματικό χρόνο και επιστρέφει κάθε οντότητα PII που βρίσκει, τον τύπο της, τις μετατοπίσεις χαρακτήρων της και ένα confidence score. Χρησιμοποιείς αυτές τις μετατοπίσεις για να αντικαταστήσεις τα τμήματα πριν κάνεις log. Το Comprehend υποστηρίζει δύο τρόπους masking: αντικατάσταση κάθε οντότητας με τον τύπο της, ώστε το "Γιάννης Παπαδόπουλος" να γίνει [NAME], που κρατά το log αναγνώσιμο, ή κάλυψη των χαρακτήρων με ένα σταθερό σύμβολο. Η αντικατάσταση με τον τύπο είναι συνήθως σωστή, γιατί διατηρεί το σχήμα του prompt για αποσφαλμάτωση ενώ αφαιρεί την ταυτότητα.

entities = comprehend.detect_pii_entities(Text=prompt, LanguageCode="en")
redacted = prompt
for e in sorted(entities["Entities"], key=lambda x: x["BeginOffset"], reverse=True):
    redacted = redacted[:e["BeginOffset"]] + f"[{e['Type']}]" + redacted[e["EndOffset"]:]
log.write(redacted)   # only the redacted form is ever persisted

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

Η ανίχνευση είναι πιθανοκρατική, οπότε σχεδίασε για παραλείψεις

Το Comprehend είναι ένας ανιχνευτής μηχανικής μάθησης, που σημαίνει ότι έχει recall κάτω από 100 τοις εκατό και ένα confidence score στο οποίο πρέπει να ορίσεις ένα κατώφλι. Ένα χαμηλό κατώφλι κάνει redact επιθετικά και μπορεί να παραμορφώσει νόμιμο κείμενο, ένα ψηλό αφήνει PII ακραίας περίπτωσης να περάσει. Δύο συνήθειες το κάνουν ασφαλές:

  • Πρόσθεσε ένα ντετερμινιστικό πέρασμα. Για δομημένους αναγνωριστές με σταθερές μορφές, αριθμούς πιστωτικών καρτών, εθνικά ID, ορισμένες μορφές λογαριασμών, ένα regex πιάνει ό,τι ένα πιθανοκρατικό μοντέλο μπορεί να χάσει, και το πιάνει με τον ίδιο τρόπο κάθε φορά. Τρέξε και τα δύο.
  • Κάνε redact προς τα ψευδώς θετικά. Σε ένα debug log, το υπερβολικό redaction σου κοστίζει λίγη αναγνωσιμότητα. Το ανεπαρκές redaction σου κοστίζει ένα περιστατικό προστασίας δεδομένων. Δώσε προκατάληψη στο κατώφλι προς την αφαίρεση παραπάνω.

Το Amazon Bedrock Guardrails μπορεί επίσης να φιλτράρει ευαίσθητες πληροφορίες στο όριο του μοντέλου, κάτι που είναι συμπληρωματικό: το Guardrails προστατεύει τη διαδρομή αιτήματος και απόκρισης, το Comprehend προστατεύει ό,τι γράφεις στα δικά σου logs. Χρησιμοποίησε αυτό που κάθεται εκεί που βρίσκεται ο κίνδυνός σου.

Η retention είναι το άλλο μισό του ελέγχου

Το redaction μειώνει τι περιέχει ένα log, η retention περιορίζει για πόσο ζει ακόμα και η redacted μορφή. Ένα redacted prompt έχει χαμηλότερο κίνδυνο, όχι μηδενικό κίνδυνο, και ένα debug log έχει μια φυσική χρήσιμη ζωή μετρημένη σε εβδομάδες, όχι χρόνια. Όρισε ρητά την retention στον προορισμό:

  • Λήξε σε πρόγραμμα. Μια ρύθμιση retention ομάδας log CloudWatch ή ένας κανόνας κύκλου ζωής S3 που διαγράφει μετά από ένα καθορισμένο παράθυρο σημαίνει ότι τα παλιά logs λήγουν χωρίς κανείς να θυμάται να τα καθαρίσει.
  • Ταίριαξε την retention με τον σκοπό. Η επιχειρησιακή αποσφαλμάτωση σπάνια χρειάζεται περισσότερο από 30 έως 90 μέρες. Αν χρειάζεται μεγαλύτερο παράθυρο για συγκεκριμένο λόγο, ονόμασε τον λόγο και περιόρισε αυτή τη retention στα logs που τη χρειάζονται.
  • Κλείδωσε την πρόσβαση. Ακόμα και τα redacted logs αξίζουν IAM με καθορισμένο εύρος. Το σύνολο ανθρώπων που μπορούν να διαβάσουν ωμά prompt logs πρέπει να είναι μικρό και κατονομασμένο.

Το συμπέρασμα

Το logging prompts και η προστασία PII δεν βρίσκονται σε σύγκρουση, είναι δύο βήματα του ίδιου pipeline. Κάνε redact πριν τη γραφή με το Comprehend, προσθέτοντας ένα ντετερμινιστικό πέρασμα για αναγνωριστές σταθερής μορφής και δίνοντας προκατάληψη στο κατώφλι προς το υπερβολικό redaction. Μετά βάλε πολιτική retention σε ό,τι απομένει ώστε τα redacted logs να λήγουν σε πρόγραμμα αντί να συσσωρεύονται για πάντα πίσω από χαλαρή πρόσβαση. Κάνε και τα δύο και κρατάς το σήμα αποσφαλμάτωσης που χρειάζεσαι ενώ τα ρυθμιζόμενα δεδομένα δεν προσγειώνονται ποτέ at rest. Το log που σε βοηθά να διορθώσεις την εφαρμογή δεν πρέπει να είναι αυτό που εμφανίζεται σε μια αναφορά παραβίασης.

Διάβασε αυτό στη συνέχεια

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