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

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

Απομόνωση δεδομένων: όρισε την ανάκτηση, όχι το μοντέλο

Ο πραγματικός κίνδυνος διαρροής σε μια εφαρμογή RAG ή agent δεν είναι τα βάρη, είναι το context που βάζεις μπροστά τους. Αν η ερώτηση του πελάτη A ανακτά έγγραφα του πελάτη B, έχεις μια παραβίαση δεδομένων ντυμένη σαν χρήσιμη απάντηση. Άρα το επίπεδο ανάκτησης είναι εκεί που ζει ο διαχωρισμός πελατών.

Δύο εφικτά σχήματα, ανάλογα με το πόσο αυστηρό πρέπει να είναι το όριο:

  • Knowledge Base ανά πελάτη. Το σκληρό όριο. Κάθε πελάτης παίρνει τη δική του Bedrock Knowledge Base, οπότε ένα query μπορεί να ανακτήσει μόνο από το corpus αυτού του πελάτη. Πιο καθαρό στη σκέψη, περισσότερα κινούμενα μέρη να διαχειρίζεσαι όσο αυξάνεται ο αριθμός πελατών.
  • Κοινή αποθήκη, φιλτραρισμένη ανά πελάτη. Ένα vector store με υποχρεωτικό φίλτρο tenant-ID σε κάθε query, ώστε τα αποτελέσματα να οριοθετούνται με metadata. Φθηνότερο στη λειτουργία, αλλά το φίλτρο είναι πλέον κρίσιμο στοιχείο ασφάλειας. Πρέπει να εφαρμόζεται server-side από μια πιστοποιημένη ταυτότητα, ποτέ από μια τιμή που μπορεί να ορίσει ο client.

Η αποτυχία που πρέπει να αποφύγεις είναι το φιλτράρισμα σε ένα tenant ID που έφτασε στο σώμα του request. Αν ο client μπορεί να ονομάσει τον δικό του πελάτη, ο client μπορεί να ονομάσει κάποιου άλλου. Προέκυψε τον πελάτη από τον πιστοποιημένο principal και εφάρμοσε το όριο εκεί που ο client δεν μπορεί να φτάσει.

Ο θορυβώδης γείτονας: μια κοινή ποσόστωση είναι μια κοινή αποτυχία

Το Bedrock κάνει throttle σε tokens ανά λεπτό σε επίπεδο λογαριασμού και μοντέλου. Αυτός ο αριθμός είναι κοινός για κάθε πελάτη που χτυπά αυτό το μοντέλο στον λογαριασμό σου. Άρα ένας πελάτης που τρέχει μια βαριά batch εργασία ξοδεύει τον κοινό προϋπολογισμό tokens, και κάθε άλλος πελάτης αρχίζει να συλλέγει σφάλματα throttling για φορτίο που δεν δημιούργησε ο ίδιος. Το μοντέλο είναι απομονωμένο λογικά και συζευγμένο λειτουργικά.

Η απομόνωση εδώ σημαίνει μέτρηση και οριοθέτηση ανά πελάτη πριν το κοινό ταβάνι το κάνει για σένα:

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

Ταυτότητα: το όριο πελάτη πρέπει να φτάνει μέχρι τα εργαλεία

Η απομόνωση δεν μπορεί να σταματήσει στην ανάκτηση. Τη στιγμή που ένας agent καλεί ένα εργαλείο, διαβάζει από μια βάση δεδομένων, ή γράφει σε αποθήκευση, το όριο πελάτη πρέπει να ταξιδεύει με το request. Αυτό σημαίνει ότι το request τρέχει με μια ταυτότητα οριοθετημένη στον πελάτη, ώστε ακόμα κι αν το μοντέλο πειστεί να ζητήσει λάθος δεδομένα, τα διαπιστευτήρια πίσω από το εργαλείο να μην μπορούν να τα φέρουν. Το επίπεδο μοντέλου δεν εμπιστεύεται τίποτα· το επίπεδο IAM επιβάλλει τα πάντα. Αυτό είναι least privilege εφαρμοσμένο ανά πελάτη, και είναι αυτό που εμποδίζει μια απόπειρα prompt injection να μετατραπεί σε ανάγνωση μεταξύ πελατών.

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

Ένα κοινό μοντέλο δεν είναι μια εφαρμογή με τα-πάντα-κοινά. Το μοντέλο είναι stateless, άρα δεν παρέχει καμία απομόνωση και δεν χρειάζεται καμία δική του να προστατευτεί. Η δουλειά σου είναι τα τρία όρια γύρω του: όρισε την ανάκτηση ώστε ένας πελάτης να βλέπει μόνο τα δικά του δεδομένα, μέτρησε και οριοθέτησε τη χωρητικότητα ώστε κανένας πελάτης να μη λιμοκτονεί τους άλλους στην κοινή ποσόστωση tokens, και μετέφερε μια ταυτότητα ανά πελάτη μέχρι τα εργαλεία ώστε ένα οριοθετημένο διαπιστευτήριο να είναι η τελευταία γραμμή άμυνας όταν το επίπεδο prompt ξεγελαστεί. Χτίσε αυτά τα τρία και ένα μοντέλο εξυπηρετεί πολλούς πελάτες με ασφάλεια. Παράλειψε οποιοδήποτε από αυτά και το μοντέλο θα εξυπηρετήσει ευχαρίστως τα δεδομένα του λάθος πελάτη στον λάθος πελάτη.

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

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