Multi-vector embeddings: πώς το domain finetuning αλλάζει την εταιρική αναζήτηση

Η έκδοση 6.0 του Sentence Transformers πρόσθεσε το MultiVectorEncoder, μαζί με ολοκληρωμένη υποστήριξη για εκπαίδευση, αξιολόγηση και χρήση ColBERT-style late-interaction μοντέλων. Αντί να συμπιέζουν ολόκληρο query ή document σε ένα vector, τα μοντέλα αυτά διατηρούν μικρότερες αναπαραστάσεις ανά token και συγκρίνουν τις πιο σχετικές λεπτομέρειες με τον τελεστή MaxSim.

Ο Tom Aarsen της Hugging Face δοκίμασε τη διαδικασία σε ιατρική αναζήτηση με το MIRIAD. Το domain-finetuned μοντέλο του ξεπέρασε περισσότερες από 50 διαμορφώσεις dense, sparse, lexical και multi-vector retrieval στο συγκεκριμένο evaluation. Το εύρημα δεν είναι καθολική κατάταξη μοντέλων· είναι απόδειξη ότι η συνάφεια με το domain, το πραγματικό μήκος των εγγράφων και η αρχιτεκτονική του index μπορούν να επηρεάσουν την ποιότητα περισσότερο από το brand ή το πλήθος παραμέτρων.

Για μια επιχείρηση, το θέμα αφορά άμεσα RAG, εσωτερικά knowledge bases, product search, support search και AI assistants. Ένα σύστημα μπορεί να παράγει καλογραμμένη απάντηση και παρ’ όλα αυτά να αποτυγχάνει, επειδή ανέκτησε λάθος πολιτική επιστροφών, παλιά έκδοση συμβολαίου ή άσχετη τεχνική οδηγία. Η ποιότητα αρχίζει πριν από το generation, στο αν ο retriever βρίσκει το σωστό απόσπασμα.

Ένα vector ή πολλά vectors ανά έγγραφο;

Ένα dense embedding model επιστρέφει συνήθως μία συμπυκνωμένη αναπαράσταση για ολόκληρο το κείμενο. Query και document μπορούν έτσι να συγκριθούν πολύ γρήγορα με ένα dot product, ενώ ο index παραμένει σχετικά μικρός. Η συμπίεση όμως είναι απωλεστική: μια σπάνια ονομασία, ένας κωδικός προϊόντος ή μία κρίσιμη ρήτρα μέσα σε μεγάλο έγγραφο πρέπει να μοιραστούν τον ίδιο χώρο με όλο το υπόλοιπο περιεχόμενο.

Το multi-vector retrieval διατηρεί ένα μικρό vector ανά token. Κατά το scoring, κάθε query token βρίσκει το καλύτερο ταίριασμα μέσα στα document tokens και οι επιμέρους βαθμολογίες αθροίζονται μέσω MaxSim. Η αλληλεπίδραση γίνεται αργά — γι’ αυτό ονομάζεται late interaction — αλλά τα documents εξακολουθούν να κωδικοποιούνται εκ των προτέρων και να αποθηκεύονται σε index.

Η αρχιτεκτονική βρίσκεται ανάμεσα στον γρήγορο bi-encoder και στον ακριβότερο cross-encoder. Διατηρεί περισσότερη token-level πληροφορία χωρίς να απαιτεί να περάσει κάθε συνδυασμός query–document από το μοντέλο σε πραγματικό χρόνο. Το τίμημα είναι περισσότερα vectors, μεγαλύτερο index και πιο σύνθετο serving.

Αυτό εξηγεί γιατί η hybrid AI search παραμένει χρήσιμη: BM25, dense embeddings, multi-vector retrieval και reranking λύνουν διαφορετικά προβλήματα. Η σωστή στοίβα δεν προκύπτει από ιδεολογική επιλογή ενός μοντέλου, αλλά από τα queries, τα documents και το latency budget του προϊόντος.

Γιατί το domain finetuning αλλάζει τη συνάφεια

Η λέξη «σχετικό» δεν σημαίνει το ίδιο σε νομική έρευνα, τεχνική υποστήριξη, product discovery ή ιατρική βιβλιογραφία. Αλλάζει το λεξιλόγιο, το ύφος των queries και, κυρίως, το ποιο αποτέλεσμα θεωρεί ο χρήστης σωστό. Ένας γενικός retriever μπορεί να καταλαβαίνει το θέμα, αλλά να μην ξεχωρίζει την ισχύουσα διαδικασία από μια παλιά έκδοση ή έναν ακριβή κωδικό από ένα παρόμοιο προϊόν.

Το finetuning χρησιμοποιεί in-domain παραδείγματα query–relevant document για να μάθει αυτή τη λειτουργική έννοια της συνάφειας. Στο multi-vector μοντέλο, η προσαρμογή επηρεάζει τη λεπτομερή token-level αντιστοίχιση. Δεν αντικαθιστά όμως την ποιότητα των δεδομένων: αν τα θετικά pairs είναι εύκολα, λανθασμένα ή διαρρέουν από το train στο test, το μοντέλο μαθαίνει ένα τεχνητό shortcut.

Η πρακτική αξία φαίνεται σε ένα private chatbot με RAG. Ερωτήσεις χρηστών, tickets που λύθηκαν σωστά και εγκεκριμένα documents μπορούν να γίνουν training ή evaluation pairs. Πρέπει όμως να αφαιρεθούν προσωπικά δεδομένα, να διαχωριστούν οι χρονικές εκδόσεις και να οριστεί ποια απάντηση είναι έγκυρη σήμερα.

Το domain finetuning δεν διορθώνει από μόνο του ένα χαλασμένο corpus. Duplicate documents, αντικρουόμενες πολιτικές και ασαφές ownership δημιουργούν λάθος labels πριν ξεκινήσει η εκπαίδευση. Η δουλειά αρχίζει από data governance: ποιες πηγές είναι authoritative, πώς ενημερώνονται και ποιος εγκρίνει το relevance.

Το μη προφανές αποτέλεσμα στην επιλογή checkpoint

Το Sentence Transformers 6.0 επιτρέπει δύο βασικές αφετηρίες. Μια ομάδα μπορεί να συνεχίσει το finetuning υπάρχοντος multi-vector checkpoint ή να προσθέσει νέα multi-vector κεφαλή πάνω σε base transformer. Στη δεύτερη περίπτωση δημιουργείται, μεταξύ άλλων, τυχαία αρχικοποιημένο projection προς την κλασική διάσταση των 128, μαζί με masking και normalization. Το μοντέλο χρειάζεται training πριν γίνει χρήσιμο για retrieval.

Στο πείραμα της Hugging Face, έξι αφετηρίες εκπαιδεύτηκαν με την ίδια συνταγή πάνω σε 25.000 ιατρικά question–passage pairs και αξιολογήθηκαν σε 1.000 held-out queries με corpus 50.000 passages. Το mLateOn-unsupervised ανέβηκε από 0,9087 σε 0,9398 NDCG@10. Το finished mLateOn πήγε από 0,9277 σε 0,9319, ενώ άλλα finished checkpoints υποχώρησαν.

Η ερμηνεία του συγγραφέα είναι ότι τα pre-supervised checkpoints είχαν ήδη late-interaction structure, χωρίς να έχουν προσαρμοστεί τόσο έντονα σε general-purpose supervised relevance. Όταν τέτοιο checkpoint δεν υπάρχει, fresh projection πάνω σε retrieval-pretrained backbone μπορεί να είναι λογική εναλλακτική: το gte-modernbert-base έφτασε 0,9177 μετά τα ίδια 25.000 pairs.

Αυτό είναι υπόθεση προς έλεγχο, όχι μόνιμος κανόνας. Η ομάδα πρέπει να συγκρίνει τουλάχιστον ένα pre-supervised checkpoint, ένα finished checkpoint και ένα ισχυρό dense baseline με ακριβώς τα ίδια splits και metrics. Η επιλογή που φαίνεται πιο «ώριμη» από το όνομα μπορεί να προσαρμόζεται χειρότερα στο δικό σας domain.

Δεδομένα και loss function χωρίς λάθος αντιγραφή

Ο MultiVectorEncoderTrainer δέχεται datasets από το Hugging Face Hub ή τοπικά CSV, JSON, Parquet, Arrow και SQL. Η δοκιμή χρησιμοποίησε το MIRIAD, με περίπου 4,4 εκατομμύρια ιατρικές ερωτήσεις συνδεδεμένες με το passage που περιέχει την απάντηση. Για το πλήρες training επιλέχθηκαν ένα εκατομμύριο pairs.

Η απλή μορφή query–relevant document είναι συχνά αρκετή για ένα πρώτο εταιρικό pilot. Δεν απαιτεί υποχρεωτικά teacher scores ή mined negatives. Η σειρά των columns όμως έχει σημασία: η πρώτη αντιμετωπίζεται ως query και οι επόμενες ως documents, εκτός αν δοθεί διαφορετικό router mapping. Όταν η loss απαιτεί label, η στήλη πρέπει να ονομάζεται label ή score.

Για question–passage pairs, η MultiVectorMultipleNegativesRankingLoss χρησιμοποιεί τα υπόλοιπα documents του batch ως negatives για κάθε query. Μεγαλύτερο effective batch δίνει περισσότερα negatives, αλλά η κωδικοποίηση μεγάλων documents μπορεί να εξαντλήσει τη GPU. Η cached εκδοχή με GradCache χωρίζει την κωδικοποίηση σε mini-batches, ενώ το mini_batch_num_tokens επιτρέπει token budget όταν τα μήκη διαφέρουν έντονα.

Υπάρχει και μια συγκεκριμένη παγίδα μεταφοράς ρυθμίσεων. Το multi-vector contrastive loss έχει default scale=1.0, όχι 20.0. Η MaxSim βαθμολογία αθροίζει πολλά token matches και ήδη έχει μεγαλύτερο εύρος· η τυφλή αντιγραφή του 20.0 από dense cosine training μπορεί να κορέσει το softmax και να καταστρέψει τα gradients.

Το μήκος εγγράφων είναι μέρος του μοντέλου

Πολλά retrieval checkpoints έχουν εκπαιδευτεί με document caps 180, 256, 300 ή 512 tokens. Στο MIRIAD, τα passages είχαν μέσο μήκος περίπου 941 tokens. Η Hugging Face μέτρησε απώλεια από 0,08 έως 0,24 NDCG@10 σε multi-vector μοντέλα όταν εφαρμόζονταν length caps. Στη συγκεκριμένη δοκιμή, το truncation μπορούσε να επηρεάσει περισσότερο το αποτέλεσμα από τη διαφορά ανάμεσα σε αρχιτεκτονικές.

Στην εταιρική αναζήτηση, αυτό είναι εύκολο να περάσει απαρατήρητο. Η κρίσιμη εξαίρεση μπορεί να βρίσκεται στο τέλος μιας πολιτικής επιστροφών, το SLA στην τελευταία σελίδα μιας σύμβασης ή το βήμα αποκατάστασης βαθιά μέσα σε τεχνικό manual. Αν το retrieval layer δεν βλέπει το απόσπασμα, κανένα καλύτερο prompt στο generation layer δεν μπορεί να το ανακτήσει.

Το πλήρες run της μελέτης άφησε σκόπιμα κενό το training max_length, ώστε το μοντέλο να βλέπει το ίδιο μήκος που θα εξυπηρετούσε στο inference. Training στα 512 tokens ήταν περίπου δύο φορές γρηγορότερο, αλλά έχασε περίπου 0,015 NDCG@10 και η διαφορά δεν έκλεισε με περισσότερα δεδομένα. Το trade-off αφορά αυτό το corpus, όμως η αρχή είναι γενική: training και serving length πρέπει να σχεδιάζονται μαζί.

Πριν επιλεγεί νέο μοντέλο, αξίζει να μετρηθεί η κατανομή μήκους, το ποσοστό truncation και η θέση των σχετικών αποσπασμάτων. Η προσέγγιση των Semantic Compression Trees δείχνει μια διαφορετική στρατηγική μείωσης context, αλλά και εκεί η συμπίεση πρέπει να αξιολογείται ως πιθανή απώλεια πληροφορίας, όχι ως δωρεάν βελτιστοποίηση.

Ένα εύκολο evaluation κρύβει τις διαφορές

Ένα χαμηλό evaluation loss δεν απαντά αν ο χρήστης θα βρει το σωστό document. Το Sentence Transformers παρέχει evaluators για information retrieval, NanoBEIR, triplets, reranking και distillation. Για domain finetuning, η ουσιαστική μέτρηση είναι πάνω σε πραγματικά held-out queries, corpus και relevance mappings.

Οι ερωτήσεις του MIRIAD παράγονται από τα ίδια τα source passages, άρα έχουν ασυνήθιστα υψηλό lexical overlap. Με περίπου 10.000 gold passages, σχεδόν όλα τα μοντέλα ξεπερνούσαν το 0,97 NDCG@10 και το benchmark δεν μπορούσε να τα διαχωρίσει. Ο Aarsen πρόσθεσε deduplicated distractors έως corpus 200.000 passages, ώστε η ανάκτηση να γίνει αρκετά δύσκολη.

Ένα business evaluation χρειάζεται αμφίσημες διατυπώσεις, παρόμοια προϊόντα, παλιές εκδόσεις, near-duplicates, σύνθετα φίλτρα και queries όπου η απάντηση βρίσκεται βαθιά στο document. Το άρθρο για το Causal RAG και το reranking αναδεικνύει το ίδιο κενό από άλλη γωνία: η ομοιότητα δεν ταυτίζεται πάντα με τη σωστή αιτιώδη ή επιχειρησιακή απάντηση.

Τα metrics πρέπει να συνδέονται με το προϊόν. Το NDCG@10 μετρά την ποιότητα της κατάταξης, το accuracy@1 αν το σωστό document έρχεται πρώτο και το recall αν εμφανίζεται μέσα στο shortlist. Για παραγωγή χρειάζονται επιπλέον latency, index size, κόστος ανά query, freshness και ποσοστό queries όπου ο χρήστης συνεχίζει να ψάχνει ή ανοίγει λάθος αποτέλεσμα.

Τι έδειξαν οι 50+ retrieval διαμορφώσεις

Στο τελικό evaluation με 1.000 held-out ιατρικές ερωτήσεις και 200.000 μοναδικά passages, το finetuned mLateOn-medical πέτυχε 0,9139 NDCG@10. Το ισχυρότερο zero-shot multi-vector μοντέλο είχε 0,8520, το Qwen3-Embedding-4B 0,7817, το BM25 0,7501 και το SPLADE-v3 0,6853.

Η διαφορά από το ισχυρότερο zero-shot configuration ήταν +0,062 NDCG@10. Στο accuracy@1, το finetuned μοντέλο έφτασε 0,849 έναντι 0,758 του καλύτερου zero-shot. Οι αριθμοί δείχνουν ισχυρή προσαρμογή στο συγκεκριμένο medical retrieval task, όχι ότι το ίδιο checkpoint είναι γενικά καλύτερο σε κάθε γλώσσα, corpus ή τύπο query.

Το BM25 παρέμεινε ανταγωνιστικό επειδή οι ερωτήσεις είχαν υψηλό lexical overlap με τα gold passages και το lexical retrieval διάβαζε όλο το κείμενο. Αυτό δεν εγγυάται το ίδιο αποτέλεσμα αλλού, αλλά επιβεβαιώνει ότι ένα φθηνό baseline είναι απαραίτητο. Χωρίς BM25 και το υπάρχον dense retriever, η ομάδα δεν γνωρίζει αν η πολυπλοκότητα του multi-vector stack αγοράζει πραγματική βελτίωση.

Ο index καθορίζει το πραγματικό κόστος

Στο MIRIAD, κάθε passage παρήγαγε κατά μέσο όρο περίπου 878 vectors. Για 200.000 μεγάλα passages, τα raw FP16 embeddings χρειάστηκαν περίπου 45 GB, ενώ ένα dense index χρειαζόταν λιγότερο από 1 GB. Σε μικρότερα Natural Questions passages, ο μέσος όρος ήταν περίπου 125 vectors, επτά φορές χαμηλότερος. Το document length αλλάζει επομένως και την οικονομία της αρχιτεκτονικής.

Το token pooling μειώνει πόσα vectors αποθηκεύονται. Η διατήρηση των μισών κόστισε 0,0033 NDCG@10 χωρίς αλλαγή στο rank-1 accuracy, ενώ το ένα τέταρτο έδωσε index 11,2 GB και score 0,8991. Με 1-bit residual quantization μέσω fast-plaid, όλα τα vectors χώρεσαν σε 3,37 GB με 0,8984 NDCG@10.

Με πρόσθετο pruning στο 65% των vectors, ο index έπεσε στα 2,23 GB και 0,8830. Στο 42% έφτασε 1,45 GB και 0,8642. Η ίδια η πηγή χαρακτηρίζει το pruning απλό και διερευνητικό, άρα τα τελευταία σημεία δεν είναι τελικός βέλτιστος σχεδιασμός. Δείχνουν όμως ότι quantization, pooling και pruning είναι αποφάσεις προϊόντος, όχι δευτερεύουσες λεπτομέρειες υποδομής.

Η επιχείρηση πρέπει να συγκρίνει quality–cost curves, όχι ένα μόνο score. Ένα ασφαλές enterprise RAG μπορεί επίσης να χρειάζεται on-premises ή απομονωμένη υποδομή, όπως δείχνει η συζήτηση για enterprise RAG με ευαίσθητα δεδομένα. Storage, latency, πρόσβαση, observability και freshness πρέπει να μπουν στο ίδιο business case.

Πότε έχει νόημα για εταιρική αναζήτηση

Το πρώτο θετικό σήμα είναι το μήκος: policies, συμβάσεις, εγχειρίδια ή product catalogs όπου το χρήσιμο απόσπασμα χάνεται μετά από truncation. Το δεύτερο είναι η ορολογία: ονομασίες, εξαρτήματα, κωδικοί ή φράσεις που πρέπει να ταιριάξουν λεπτομερώς. Το τρίτο είναι η αξία του λάθους: όταν μια λανθασμένη ανάκτηση οδηγεί σε λάθος απάντηση πελάτη, επιστροφή προϊόντος ή τεχνική διακοπή.

Σε e-commerce, το use case μπορεί να είναι product discovery με πολλά ταυτόχρονα χαρακτηριστικά. Σε support, η σωστή λύση μπορεί να εξαρτάται από έκδοση, μοντέλο και συγκεκριμένο error condition. Σε compliance ή νομικά documents, μια εξαίρεση έχει μεγαλύτερη σημασία από τη γενική θεματική ομοιότητα. Η multimodal αναζήτηση εικόνων με embeddings υπενθυμίζει ότι η σωστή αναπαράσταση εξαρτάται και από το modality, όχι μόνο από τον αλγόριθμο κατάταξης.

Υπάρχουν και σαφή αρνητικά σήματα. Αν δεν υπάρχουν αξιόπιστα relevance labels, αν το corpus αλλάζει χωρίς versioning, αν δεν μπορεί να μετρηθεί latency ή αν η ομάδα δεν διαθέτει διαδικασία rebuild του index, το finetuning κινδυνεύει να βελτιστοποιήσει μια ασταθή βάση. Πρώτα διορθώνεται το information architecture και μετά αυξάνεται η πολυπλοκότητα.

Η δρομολόγηση δεδομένων έχει επίσης σημασία. Ένα σύστημα όπως το SchemaRouter για field-aware RAG αντιμετωπίζει το ερώτημα ποια πεδία και πηγές χρειάζονται πριν γεμίσει το context. Το multi-vector retrieval απαντά διαφορετικά: ποια λεπτομερή tokens μέσα στα υποψήφια documents ταιριάζουν καλύτερα. Οι δύο επιλογές μπορούν να συνεργαστούν, αλλά δεν είναι υποκατάστατα.

Επτά βήματα για ασφαλές pilot

Ένα pilot πρέπει να απομονώνει τις μεταβλητές και να αφήνει audit trail. Η ομάδα δεν χρειάζεται να ξεκινήσει με ένα εκατομμύριο pairs ή production traffic. Στα scaling experiments της Hugging Face, 100.000 pairs και 75 λεπτά training βρέθηκαν εντός 0,012 NDCG@10 από το πλήρες run· το αποτέλεσμα αφορά τη συγκεκριμένη GPU και dataset, αλλά δείχνει γιατί ένα μικρότερο πείραμα μπορεί να είναι πληροφοριακά χρήσιμο.

Η συνάφεια είναι προϊόν, όχι μόνο μοντέλο

Το Sentence Transformers 6.0 μειώνει την τεχνική τριβή για multi-vector training και retrieval. Η προσβασιμότητα του εργαλείου όμως δεν αφαιρεί την ευθύνη του σχεδιασμού. Η ομάδα πρέπει να ορίσει τι σημαίνει σωστή απάντηση, να επιλέξει αντιπροσωπευτικά δεδομένα, να διατηρήσει δύσκολο evaluation και να γνωρίζει πόσο κοστίζει ο index στην πραγματική υποδομή.

Η ίδια αρχή ισχύει σε όλο το RAG pipeline. Η ανάκτηση μπορεί να αποτύχει πριν καν ξεκινήσει όταν το σύστημα δεν ορίζει σωστά τι πρέπει να θυμάται, πού να ψάξει ή ποια έκδοση να εμπιστευτεί. Ένα καλύτερο retriever ενισχύει μια καθαρή αρχιτεκτονική γνώσης· δεν θεραπεύει ασυνέπεια που παραμένει μέσα στα δεδομένα.

Το ώριμο συμπέρασμα δεν είναι ότι κάθε επιχείρηση χρειάζεται multi-vector embeddings. Είναι ότι η εταιρική αναζήτηση πρέπει να αντιμετωπίζεται ως προϊόν με συγκεκριμένους χρήστες, relevance definition, baselines, SLOs και συνεχή αξιολόγηση. Όταν η λεπτομέρεια ενός token αλλάζει την απάντηση, το late interaction αξίζει να δοκιμαστεί. Όταν δεν αλλάζει, η απλούστερη λύση κερδίζει.