Το Azure AI Search δεν διαστασιολογείται από το πόσα vectors έχεις. Διαστασιολογείται ανά tier: το vector index οριοθετείται από τη μνήμη που δεσμεύεται για vector search στο SKU σου, και στο Serverless μοντέλο από ένα σκληρό όριο 300 MB ανά index που ρίχνει το indexing job εντελώς όταν ξεπεραστεί. Αυτή η μία ιδιότητα, όχι μια σύγκριση features, κρίνει αν το retrieval layer της εταιρείας ανήκει στο Azure AI Search ή σε μια αποκλειστική vector database. Το Μέρος 6 έκανε τις επαναλαμβανόμενες ερωτήσεις φθηνές. Αυτό το μέρος χειρίζεται την πολύ πιο συνηθισμένη περίπτωση, όπου το μοντέλο χρειάζεται γεγονότα που δεν είδε ποτέ, και η αναζήτηση γνώσης λιανικής από το Μέρος 1 χτίζεται επιτέλους.

Πού κάθεται το retrieval σε σχέση με το gateway

Ένα σημείο που αξίζει να ξεκαθαριστεί πριν από κάθε σύγκριση, επειδή είναι αυτό που κρατά ακέραιη την παραδοχή της σειράς: το retrieval δεν είναι κίνηση του gateway. Η εφαρμογή κάνει query στο search index απευθείας, συναρμολογεί ένα prompt από όσα επιστρέφουν, και στέλνει αυτό το prompt μέσα από το gateway όπως κάθε άλλο completion. Το gateway μετρά τα tokens που προσθέτει το ανακτημένο context, που είναι ακριβώς η ορατότητα που θέλεις, αφού το retrieval είναι συνήθως το σημείο όπου το μέγεθος του prompt τριπλασιάζεται αθόρυβα.

Το ένα κομμάτι που όντως αγγίζει το gateway είναι το embedding. Η παραγωγή embeddings για queries και έγγραφα είναι κλήση μοντέλου, οπότε περνά από την ίδια πόρτα με όλα τα υπόλοιπα, με το ίδιο quota και την ίδια απόδοση. Αυτό σημαίνει επίσης ότι το embeddings deployment που δημιούργησε το Μέρος 6 για το semantic caching είναι πιθανότατα το ίδιο deployment που θέλει το retrieval, και η χωρητικότητά του εξυπηρετεί πλέον δύο αφεντικά.

Τα όρια που πραγματικά το κρίνουν

Οι λίστες features κάνουν το Azure AI Search και ένα αποκλειστικό vector store να μοιάζουν εναλλάξιμα. Τα service limits όχι.

  • Το μέγεθος του vector index είναι συνάρτηση του SKU, όχι των δεδομένων σου. Στο Dedicated μοντέλο τιμολόγησης οριοθετείται από τη μνήμη που δεσμεύεται για vector search στο tier· στο Serverless είναι 300 MB ανά index, περίπου 30 τοις εκατό του συνολικού index storage, και ένα σκληρό όριο που κάνει το indexing να αποτυγχάνει αντί να υποβαθμίζεται.
  • Τα vector limits εξαρτώνται από το πότε δημιουργήθηκε το service. Υψηλότερα vector quotas ισχύουν για services που δημιουργήθηκαν από τον Απρίλιο του 2024 και μετά, σε regions με την επιπλέον χωρητικότητα. Ένα παλαιότερο service σε υποστηριζόμενο region μπορεί να χρειάζεται ρητό upgrade για να τα αποκτήσει, που είναι ζήτημα migration και όχι config toggle.
  • Η χωρητικότητα είναι replicas επί partitions. Το Basic υποστηρίζει τρία partitions και τρία replicas, εννέα search units, σε services που δημιουργήθηκαν μετά τις 3 Απριλίου 2024· τα παλαιότερα Basic services περιορίζονται σε ένα partition. Τα S1 έως S3 φτάνουν στα δώδεκα από το καθένα.
  • Το SLA είναι ένας αριθμός replicas. Δύο ή περισσότερα replicas για query workloads, τρία ή περισσότερα για query και indexing. Ο αριθμός των partitions δεν είναι καθόλου παράμετρος του SLA, κάτι που εκπλήσσει όσους κλιμάκωσαν για storage και υπέθεσαν ότι η διαθεσιμότητα ερχόταν μαζί.
  • Ο αριθμός των indexes έχει ταβάνι ανά tier. Πέντε ή δεκαπέντε στο Basic, πενήντα στο S1, διακόσια στα S2 και S3. Μια πλατφόρμα που δίνει σε κάθε tenant το δικό του index χτυπά αυτό το ταβάνι πολύ πριν χτυπήσει το storage, και το index-per-tenant είναι το ενστικτώδες default.
  • Μέγιστο 4096 dimensions ανά vector field, σε κάθε tier, που είναι γενναιόδωρο αλλά αξίζει να το ξέρεις πριν κάποιος τυποποιήσει ένα μεγαλύτερο embedding model.

Διαβασμένα μαζί, αυτά λένε κάτι συγκεκριμένο: το Azure AI Search τιμολογείται και κλιμακώνεται ως search service που κάνει και vectors. Αν το vector corpus είναι ο κυρίαρχος οδηγός κόστους και μεγαλώνει ανεξάρτητα από τον όγκο των queries, πληρώνεις search units για να κρατούν μνήμη. Αυτή είναι η συνθήκη κάτω από την οποία κερδίζει μια αποκλειστική vector database, και είναι ποσοτική συνθήκη που μπορείς να ελέγξεις, όχι αρχιτεκτονική προτίμηση.

Τι σου δίνει το Azure AI Search που δεν δίνει ένα vector store

Το αντίβαρο είναι πραγματικό και συχνά καθοριστικό για μια εταιρική βάση γνώσης.

Hybrid search σε ένα request. Ένα μόνο query κουβαλά και παράμετρο search και vectorQueries, τρέχει full-text και vector retrieval παράλληλα, και τα συγχωνεύει με Reciprocal Rank Fusion σε ένα ενιαίο ταξινομημένο result set. Η κατάταξη κειμένου χρησιμοποιεί BM25· η κατάταξη vectors χρησιμοποιεί HNSW ή exhaustive KNN. Αυτό μετράει επειδή η τεκμηρίωση προϊόντων είναι γεμάτη ακριβή tokens, κωδικούς μοντέλων, κωδικούς σφαλμάτων, κωδικούς εξαρτημάτων, που η λεξιλογική αναζήτηση βρίσκει αξιόπιστα και τα embeddings θολώνουν.

{
  "search": "device not connecting after the firmware update",
  "vectorQueries": [
    { "kind": "vector", "vector": [ ... ], "k": 50,
      "fields": "contentVector", "exhaustive": false, "oversampling": 10 }
  ],
  "queryType": "semantic",
  "semanticConfiguration": "kb-semantic",
  "top": 10
}

Filtering, faceting, sorting, και scoring profiles εφαρμόζονται στο ίδιο request, οπότε η εξουσιοδότηση σε επίπεδο εγγράφου (αυτός ο tenant, αυτή η γραμμή προϊόντων, αυτή η γλώσσα) είναι ένα filter και όχι ξεχωριστό index. Το integrated vectorization μέσω indexers τραβά από Blob Storage, Cosmos DB, Azure SQL, ή OneLake και κάνει embed κατά το ingest, κάτι που αφαιρεί ένα ολόκληρο pipeline που αλλιώς θα το συντηρούσε η ομάδα πλατφόρμας. Και το index μπορεί να συνδεθεί ως knowledge source για σενάρια agents στο Microsoft Foundry.

Μια λεπτομέρεια χωρητικότητας κρύβεται μέσα στην ιστορία της ποιότητας κατάταξης. Το semantic ranker περιορίζεται από μια ουρά, με μέγιστο αριθμό ταυτόχρονων requests ανά search unit που είναι 2 στο Basic, 3 στο S1, και 4 στο S2 και πάνω, συν μια πεπερασμένη ουρά από πίσω. Αν ξεπεραστεί η ουρά, τα requests απορρίπτονται και πρέπει να ξαναδοκιμαστούν. Ο τρόπος να ανέβει το όριο είναι περισσότερα search units, ή ένα support request. Ένα retrieval layer που ενεργοποιεί το semantic ranking για κάθε query έχει επομένως μόλις κάνει το ταβάνι ταυτοχρονισμού του συνάρτηση του search tier, και αυτό το ταβάνι είναι μικρό στο Basic.

Η απόφαση, διατυπωμένη ως τεστ

Όχι προτίμηση. Τρεις έλεγχοι, με τη σειρά:

  • Χρειάζεται το corpus λεξιλογικό και vector retrieval μαζί; Αν τα ακριβή αναγνωριστικά μετράνε, και για τεκμηρίωση προϊόντων μετράνε πάντα, το hybrid συν semantic ranking σε ένα service αξίζει πολλά, και το να το ξαναϋλοποιήσεις πάνω από ένα καθαρό vector store σημαίνει να τρέχεις κι ένα inverted index.
  • Μεγαλώνει το vector footprint ανεξάρτητα από τον όγκο των queries; Αν ναι, μοντελοποίησε τα search units που χρειάζονται για να το κρατήσουν και σύγκρινε με μια vector database διαστασιολογημένη στο storage. Αυτό είναι αριθμητική, και συνήθως εκεί γυρίζει η απάντηση.
  • Πόσα λογικά corpora υπάρχουν; Το index-per-tenant χτυπά γρήγορα το ταβάνι των indexes ανά tier. Η εναλλακτική είναι ένα index με tenant filter, που είναι έλεγχος ασφάλειας ο οποίος πρέπει να επιβάλλεται στο query layer, όχι στον client.

Για αυτή την πλατφόρμα η απάντηση είναι το Azure AI Search, επειδή η βάση γνώσης λιανικής είναι μερικές δεκάδες gigabytes τεκμηρίωσης προϊόντων όπου οι ακριβείς κωδικοί μοντέλων μετράνε, και επειδή το λειτουργικό κόστος ενός ακόμη managed service είναι χαμηλότερο από το κόστος ενός self-run vector store στο ίδιο AKS cluster. Η απάντηση για ένα agent memory store με εκατοντάδες εκατομμύρια vectors και καμία λεξιλογική απαίτηση θα ήταν η αντίθετη, και η σειρά θα έκανε λάθος αν προσποιούνταν το αντίθετο.

Tenancy, και το filter που είναι έλεγχος ασφάλειας

Ένα index με tenant filter είναι το σωστό default κάτω από το ταβάνι του αριθμού indexes, και τοποθετεί μια απόφαση εξουσιοδότησης μέσα στο query. Ο κανόνας είναι ο ίδιος με το vary-by στο Μέρος 6: η τιμή του filter προέρχεται από το επικυρωμένο token, ποτέ από παράμετρο του request. Μια εφαρμογή που περνά το δικό της tenant ID απέχει ένα bug από το να περάσει κάποιου άλλου.

Επειδή το retrieval δεν περνά από το API Management, το σημείο επιβολής είναι η εφαρμογή ή το control plane, όχι μια πολιτική του gateway. Αυτό είναι ένα γνήσιο κενό στο μοντέλο της μίας πόρτας, και είναι καλύτερο να ονομαστεί παρά να καλυφθεί: το gateway διέπει την πρόσβαση στα μοντέλα, το search service διέπει την πρόσβαση στα έγγραφα, και είναι δύο διαφορετικά control planes που πρέπει να συμφωνούν στο ποιος είναι ο tenant. Το να προκύπτουν και τα δύο από το ίδιο Entra ID claim είναι αυτό που τα κρατά από το να αποκλίνουν.

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

  • Indexing που αποτυγχάνει σε όριο μεγέθους αντί να υποβαθμίζεται. Η υπέρβαση του ορίου του vector index ανά index στο Serverless ρίχνει την ενέργεια. Η χωρητικότητα για το vector index είναι είσοδος σχεδιασμού, όχι κάτι που ανακαλύπτεις στη μέση ενός bulk load.
  • Ένα παλιό search service με παλιά vector quotas. Δημιουργημένο πριν από τον Απρίλιο του 2024, σε region που τώρα προσφέρει περισσότερα, και σιωπηλά περιορισμένο μέχρι κάποιος να το αναβαθμίσει.
  • Κλιμάκωση partitions με προσδοκία διαθεσιμότητας. Τα partitions είναι storage. Το SLA μετρά replicas, δύο για queries και τρία όταν το indexing τρέχει παράλληλα.
  • Throttling του semantic ranker υπό φορτίο. Ο ταυτοχρονισμός είναι ανά search unit και μικρός στα χαμηλότερα tiers. Το σύμπτωμα είναι απορριφθέντα queries στην αιχμή, όχι αργά queries.
  • Index-per-tenant απέναντι σε ταβάνι του tier. Δουλεύει υπέροχα για τους πρώτους δώδεκα tenants και μετά σταματά, και τότε η μετάβαση σε ένα filtered index είναι ολόκληρο data project.
  • Ανακτημένο context που εκτοξεύει το μέγεθος του prompt. Το gateway το μετρά, οπότε εμφανίζεται στους αριθμούς του Μέρους 5 ως αύξηση tokens χωρίς καμία αλλαγή κώδικα να την εξηγεί. Βάλε alert στα tokens ανά request ανά tenant, όχι μόνο στη συνολική δαπάνη.

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

Ένα retrieval layer που οι εφαρμογές καλούν απευθείας, ένα embeddings deployment μοιρασμένο με το cache, και prompts που είναι πλέον αισθητά μεγαλύτερα από πριν. Που φέρνει το ερώτημα του επόμενου μέρους: όταν μια εφαρμογή χρειάζεται retrieval, tool calling, και πολλαπλά model hops, ανήκει ένα orchestration framework πάνω από αυτό το gateway, ή αρχίζει το framework να το πολεμά.

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

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

Αναφορές