Embedding model migration σε RAG: reindex, dual index και αξιολόγηση χωρίς διακοπή
Ένα RAG σύστημα ξεκινά με συγκεκριμένο embedding model και vector dimension. Αργότερα η ομάδα θέλει καλύτερη multilingual retrieval, χαμηλότερο κόστος ή αντικατάσταση παλιού model. Η αλλαγή δεν είναι απλό configuration update. Τα υπάρχοντα document vectors και τα νέα query vectors πρέπει να βρίσκονται στον ίδιο συμβατό χώρο αναπαράστασης.
Αν αναμειχθούν embeddings από διαφορετικά models ή dimensions στο ίδιο πεδίο, η similarity χάνει το νόημά της ή το index απορρίπτει τα δεδομένα. Η ασφαλής migration δημιουργεί νέο versioned index, επανυπολογίζει vectors από την αρχική πηγή και κάνει ελεγχόμενο cutover μετά από evals.
Γιατί απαιτείται re-embedding
Κάθε embedding model μαθαίνει διαφορετικό vector space. Ακόμη και αν δύο models παράγουν τον ίδιο αριθμό dimensions, οι συντεταγμένες τους δεν είναι συγκρίσιμες. Δεν υπάρχει γενικός μετασχηματισμός που μετατρέπει παλιά vectors σε νέα χωρίς το αρχικό κείμενο.
Το vector field έχει συγκεκριμένο dimension count που πρέπει να ταιριάζει με το output του model. Η τεκμηρίωση Azure AI Search αναφέρει ρητά ότι dimension mismatch προκαλεί σφάλμα και ότι το field schema πρέπει να συμφωνεί με το embedding model.
Άρα source of truth παραμένουν τα αρχικά documents, chunks και metadata. Ο vector index είναι παράγωγο που μπορεί να ξαναχτιστεί. Αν η εφαρμογή έχει κρατήσει μόνο vectors και όχι καθαρό κείμενο με stable IDs, η migration γίνεται πολύ δυσκολότερη.
Versionάρουμε όλη την embedding pipeline
Δεν αλλάζει μόνο το model name. Η ποιότητα εξαρτάται από chunking, normalization, language handling, dimension setting και metadata. Κάθε indexed chunk χρειάζεται pipeline version που περιγράφει:
- embedding provider και ακριβές model
- output dimensions
- chunker version και overlap
- preprocessing και normalization
- source document version
- index schema και vector algorithm profile
Το query path χρησιμοποιεί την ίδια embedding version με το index. Δεν πρέπει feature flag να στείλει query embedding νέου model στον παλιό index.
Νέος index αντί για in-place ανάμειξη
Η ασφαλέστερη στρατηγική είναι blue-green: δημιουργούμε νέο index με νέο schema και αφήνουμε τον παλιό διαθέσιμο. Το νέο index μπορεί να έχει διαφορετικές dimensions, compression ή HNSW parameters.
Η τεκμηρίωση Azure περιγράφει vector fields με dimensions και profile. Σε μεγάλη αντικατάσταση embeddings, η αναδημιουργία index βοηθά η δομή ANN να αντανακλά τη νέα κατανομή αντί να έχει χτιστεί πάνω σε παλιά vectors.
Τα aliases ή application routing δείχνουν αρχικά στον παλιό index. Το cutover γίνεται όταν ο νέος έχει ολοκληρωθεί, ελεγχθεί και φτάσει το απαιτούμενο freshness watermark.
Inventory και stable IDs
Πριν το reindex, καταγράφουμε αριθμό documents, chunks, tenants, languages και permission records. Κάθε chunk έχει deterministic stable ID που προκύπτει από source ID, version και chunk position ή content hash.
Τα stable IDs επιτρέπουν reconciliation και incremental retry. Δεν βασιζόμαστε στη σειρά που επιστρέφει ο crawler. Αν αλλάξει chunking, τα IDs αλλάζουν versioned και το νέο index μπορεί να συγκριθεί με το παλιό χωρίς collisions.
Το migration manifest κρατά expected counts και failures. Ένα job δεν θεωρείται complete επειδή τελείωσε η queue. Πρέπει να συμφωνούν source inventory και successfully indexed records, με καταγεγραμμένες εξαιρέσεις.
Batch processing, rate limits και κόστος
Το re-embedding μεγάλου corpus καταναλώνει tokens και υπόκειται σε rate limits. Η διαδικασία χρησιμοποιεί bounded batches, retries με backoff, checkpoints και idempotent writes.
Δεν επαναλαμβάνει ολόκληρο corpus αν αποτύχει ένα batch. Αποθηκεύει status ανά source/chunk και μπορεί να συνεχίσει. Τα input hashes αποτρέπουν διπλό embedding αμετάβλητου κειμένου μέσα στην ίδια pipeline version.
Πριν ξεκινήσει, γίνεται cost estimate από πραγματικό sample tokenization. Υπάρχει budget cap και monitoring για tokens, throughput, failures και backlog. Το production query traffic έχει προτεραιότητα έναντι του migration job.
Dual write για αλλαγές κατά τη migration
Το corpus συνεχίζει να αλλάζει όσο χτίζεται ο νέος index. Υπάρχουν δύο βασικές στρατηγικές:
- snapshot και replay όλων των change events μετά το snapshot
- dual write κάθε νέα αλλαγή και στους δύο indexes
Το dual write πρέπει να είναι observable και idempotent. Αν αποτύχει ο νέος index, η primary παραγωγή δεν χάνει το update και η αποτυχία μπαίνει σε retry queue. Πριν το cutover, συγκρίνεται high-water mark ώστε ο νέος index να μην είναι πίσω.
Οι διαγραφές και permission changes είναι εξίσου σημαντικές με τα νέα documents. Ένα deleted confidential document δεν πρέπει να παραμείνει στον νέο index επειδή το migration επεξεργάστηκε παλιό snapshot.
Dual read και shadow evaluation
Πριν αλλάξει η απάντηση του χρήστη, η εφαρμογή μπορεί να στέλνει shadow queries και στον νέο index. Τα results δεν εμφανίζονται, αλλά συγκρίνονται offline: overlap, rank changes, latency, empty-result rate και permission correctness.
Ένα curated evaluation set περιλαμβάνει πραγματικές κατηγορίες ερωτήσεων, ελληνικά και αγγλικά, exact terms, semantic queries, rare entities και no-answer cases. Οι human reviewers ελέγχουν relevance και αν τα top chunks υποστηρίζουν σωστή απάντηση.
Δεν αρκεί υψηλό cosine score. Οι βαθμολογίες διαφορετικών models δεν είναι άμεσα συγκρίσιμες. Αξιολογούμε retrieval outcomes και downstream answer quality.
Hybrid search, filters και permissions
Η migration πρέπει να διατηρεί non-vector fields, analyzers, filters και ACL metadata. Ένα embedding model μπορεί να βελτιώσει semantic recall αλλά να χαλάσει αποτελέσματα αν λείπουν tenant filters ή language analyzers.
Τα permission-aware tests εκτελούνται ξανά. Ο νέος index πρέπει να επιστρέφει μόνο authorized documents και να έχει συγχρονισμένα ACL versions. Το quality gain δεν δικαιολογεί regression στην ασφάλεια.
Σε hybrid search, ελέγχουμε ξανά fusion weights και reranker behavior. Οι παλιές ρυθμίσεις μπορεί να μην είναι ιδανικές για τη νέα distribution.
Cutover και rollback
Το cutover γίνεται με versioned configuration ή alias, αρχικά σε μικρό ποσοστό traffic. Παρακολουθούνται latency, error rate, no-result rate, user feedback και answer eval signals.
Ο παλιός index παραμένει read-only για προκαθορισμένο rollback window. Αν εμφανιστεί πρόβλημα, το routing επιστρέφει στην προηγούμενη embedding pipeline χωρίς νέο reindex.
Μετά τη σταθεροποίηση, σταματά το dual write, διατηρείται audit manifest και διαγράφεται ο παλιός index σύμφωνα με retention policy. Δεν διαγράφεται αμέσως μόλις το πρώτο query πετύχει.
Dimension reduction και storage trade-offs
Ορισμένα models επιτρέπουν διαφορετικό output dimension ή τεχνικές truncation/compression. Μικρότερα vectors μειώνουν storage και μπορούν να βελτιώσουν query performance, αλλά η επίδραση στην ποιότητα πρέπει να μετρηθεί στο δικό μας corpus.
Η Azure τεκμηρίωση για vector dimensions και truncation δείχνει ότι model, field dimensions και compression configuration πρέπει να συμφωνούν. Δεν επιλέγουμε dimension μόνο από κόστος χωρίς retrieval eval.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry αντιμετωπίζουμε τον vector index ως versioned παράγωγο της γνώσης. Διατηρούμε source documents, deterministic chunks και pipeline metadata ώστε κάθε index να μπορεί να ξαναχτιστεί. Για migration δημιουργούμε νέο schema, batch re-embedding με checkpoints και reconciliation, χωρίς να αναμειγνύουμε vector spaces.
Στις RAG και agentic AI λύσεις μας, χρησιμοποιούμε shadow queries, curated eval sets και permission tests πριν το cutover. Συγχρονίζουμε αλλαγές με dual write ή event replay, ελέγχουμε freshness watermark και ενεργοποιούμε σταδιακά τη νέα έκδοση με άμεσο rollback. Έτσι η αναβάθμιση model γίνεται με μετρήσιμη βελτίωση και όχι με ελπίδα ότι το νεότερο όνομα θα δώσει αυτόματα καλύτερη αναζήτηση.
Checklist migration
- Υπάρχουν αρχικά documents και chunks ως source of truth;
- Versionάρονται model, dimensions, chunking και preprocessing;
- Δημιουργείται νέος index αντί για ανάμειξη vectors;
- Υπάρχουν stable IDs, manifest και reconciliation;
- Ελέγχονται rate limits, retries και budget;
- Συγχρονίζονται νέες αλλαγές και διαγραφές;
- Γίνονται shadow queries και human relevance evals;
- Επαναλαμβάνονται permission και cross-tenant tests;
- Υπάρχει σταδιακό cutover και rollback window;
Η αλλαγή embedding model είναι migration δεδομένων και συμπεριφοράς μαζί. Η επιτυχία δεν μετριέται από το ότι ο νέος index γέμισε, αλλά από το ότι ανακτά καλύτερα, παραμένει ασφαλής και μπορεί να αναστραφεί.