Στη συγκεκριμένη δοκιμή, τα multimodal embeddings δεν κέρδισαν τα frontier LLMs στην ακρίβεια· κέρδισαν καθαρά στο online latency μετά το precomputation. Το Gemini Embedding 2, το GPT-4.1 και το Claude Sonnet 4.6 είχαν στατιστικά μη διακριτή επίδοση, αλλά το embedding ranking ολοκλήρωσε 1.000 queries σε λιγότερο από δύο δευτερόλεπτα, έναντι χιλιάδων δευτερολέπτων για τους LLM rankers.
Για e-commerce catalogs, media libraries και digital asset management, το πρακτικό ερώτημα δεν είναι «ποιο μοντέλο φαίνεται πιο έξυπνο;». Είναι ποια αρχιτεκτονική διατηρεί σχετική ακρίβεια, ενημερώνεται με ελεγχόμενο τρόπο και εξυπηρετεί πραγματικό όγκο αναζητήσεων μέσα στο αποδεκτό latency και κόστος. Η απάντηση συνήθως ξεκινά με embeddings και τεκμηριώνεται μόνο με δοκιμή πάνω στα δικά σας δεδομένα.
Δύο αρχιτεκτονικές για το ίδιο ζητούμενο
Στο text-to-image retrieval, ο χρήστης περιγράφει αυτό που θέλει και το σύστημα κατατάσσει εικόνες ως προς τη συνάφεια. Η οικογένεια dual encoders, με γνωστό παράδειγμα το CLIP, κωδικοποιεί εικόνες και κείμενο ανεξάρτητα και μαθαίνει να ευθυγραμμίζει τις αναπαραστάσεις τους. Τα νεότερα natively multimodal embedding models, όπως το Gemini Embedding 2 και το Amazon Nova Multimodal Embeddings, τοποθετούν διαφορετικά μέσα σε κοινό διανυσματικό χώρο.
Σε μια τέτοια αρχιτεκτονική, τα embeddings των εικόνων υπολογίζονται πριν από την αναζήτηση και αποθηκεύονται σε index. Το query μετατρέπεται επίσης σε vector και το online στάδιο αναζητά τους κοντινότερους υποψηφίους. Η επίσημη τεκμηρίωση της Google περιγράφει το Gemini Embedding 2 για cross-modal semantic search και scalable similarity calculations, ενώ η AWS τεκμηριώνει κοινό χώρο για κείμενο, εικόνα, έγγραφο, video και audio.
Η εναλλακτική του paper είναι ένας frontier LLM ranker. Το μοντέλο λαμβάνει μαζί το query και 25 υποψήφιες εικόνες και επιστρέφει πλήρη σειρά κατάταξης. Μπορεί να συγκρίνει σχετικές λεπτομέρειες ανάμεσα στους candidates, αλλά δεν δημιουργεί επαναχρησιμοποιήσιμο index: κάθε νέο query προκαλεί νέα end-to-end επεξεργασία. Η διαφορά είναι αρχιτεκτονική και επηρεάζει τόσο το serving όσο και το cost model ενός AI-ready e-commerce.
Embeddings και LLM ranking λύνουν διαφορετικά το online πρόβλημα
Γιατί το benchmark χρησιμοποιεί hard negatives
Οι ερευνητές Archan Dutta και Vyanktesh Kanungo χρησιμοποίησαν το Flickr30k, dataset με 31.000 εικόνες και πέντε ανεξάρτητες ανθρώπινες λεζάντες ανά εικόνα. Από το σύνολο δημιούργησαν pool 5.000 εικόνων. Για να περιορίσουν την επίδραση του ύφους κάθε annotator, χώρισαν το pool σε πέντε ομάδες των 1.000 και ανέθεσαν σε κάθε ομάδα διαφορετικό caption index.
Για κάθε query κατασκεύασαν candidate set 25 εικόνων: τη σωστή και 24 hard negatives. Οι distractors δεν ήταν τυχαίοι. Οι 5.000 αντιπροσωπευτικές λεζάντες ενσωματώθηκαν με το ανεξάρτητο all-mpnet-base-v2, υπολογίστηκε πίνακας cosine similarity 5.000 × 5.000 και επιλέχθηκαν οι 24 κοντινότερες λεζάντες μαζί με τις εικόνες τους. Έτσι το σύστημα έπρεπε να ξεχωρίσει σημασιολογικά συγγενείς σκηνές, όχι προφανώς άσχετα δείγματα.
Η κατασκευή αυτή είναι αυστηρότερη από μια τυχαία δοκιμή, αλλά δεν είναι ουδέτερη σε κάθε πιθανή έννοια δυσκολίας. Οι ίδιοι οι συγγραφείς αναγνωρίζουν ότι η επιλογή negatives στον χώρο των captions μπορεί να ευνοεί μεθόδους dense retrieval. Το benchmark πρέπει επομένως να διαβαστεί ως συγκεκριμένο πείραμα ranking και όχι ως καθολικό leaderboard οπτικής κατανόησης.
Τι ακριβώς μετρήθηκε
Η τελική αξιολόγηση έγινε σε 1.000 queries. Το Recall@1 μετρά πόσο συχνά η σωστή εικόνα βρέθηκε πρώτη. Το Recall@3 μετρά πόσο συχνά εμφανίστηκε στην πρώτη τριάδα. Το Mean Reciprocal Rank αποδίδει μεγαλύτερη αξία όσο ψηλότερα βρίσκεται η σωστή εικόνα σε ολόκληρη την κατάταξη.
Το paper δεν περιορίστηκε στη σύγκριση μέσων όρων. Υπολόγισε 95% bootstrap confidence intervals με 1.000 resamples. Για το Recall@1 χρησιμοποίησε McNemar test και για το MRR Wilcoxon signed-rank test, με α=0,05 και Bonferroni correction για τρεις ζεύγη συγκρίσεων. Αυτό προστατεύει την απόφαση από το συνηθισμένο λάθος «η μεγαλύτερη μπάρα είναι ο νικητής», όταν η διαφορά μπορεί να εξηγείται από τη μεταβλητότητα του δείγματος.
Για μια επιχείρηση, η ίδια αρχή πρέπει να επεκταθεί πέρα από τις offline μετρικές. Το evaluation χρειάζεται end-to-end latency, κόστος ανά query, ρυθμό ενημέρωσης index, failure categories και εμπορική επίπτωση. Η ανάλυση AI search έχει αξία όταν συνδέει τεχνικά signals με πραγματικές αποφάσεις προϊόντος και πωλήσεων.
Η ακρίβεια έφερε ισοπαλία στην κορυφή
Το Gemini Embedding 2 πέτυχε την υψηλότερη αριθμητική επίδοση στις τρεις μετρικές. Στο Recall@1 είχε 0,804, το Claude Sonnet 4.6 είχε 0,796 και το GPT-4.1 είχε 0,789. Ωστόσο, οι διαφορές ανάμεσα στα τρία συστήματα δεν ήταν στατιστικά σημαντικές: τα p-values του Recall@1 ήταν 0,2699, 0,5569 και 0,5854, ενώ για το MRR ήταν 0,1574, 0,0995 και 0,9354.
Recall@1 σε 1.000 queries με 25 hard-negative candidates
Οι τιμές είναι τα δημοσιευμένα αποτελέσματα του συγκεκριμένου benchmark. Δεν αποτελούν γενική πρόβλεψη απόδοσης σε product catalog ή άλλη παραγωγική συλλογή.
80,4%
Gemini Embedding 2
Υψηλότερη αριθμητική τιμή, χωρίς στατιστικά σημαντική διαφορά από τους δύο frontier LLM rankers.
79,6%
Claude Sonnet 4.6
Παρόμοια Recall@1 επίδοση όταν είδε μαζί query και 25 τυχαιοποιημένους candidates.
78,9%
GPT-4.1
Στατιστικά μη διακριτή επίδοση από Gemini Embedding 2 και Claude Sonnet 4.6.
67,3%
Amazon Nova 2
Χαμηλότερο αποτέλεσμα με τη ρύθμιση purpose που χρησιμοποίησε το πείραμα.
Το Amazon Nova 2 υστέρησε κατά 13,1 ποσοστιαίες μονάδες στο Recall@1 έναντι του Gemini Embedding 2 και διέφερε σημαντικά από όλα τα άλλα συστήματα με p<0,0001. Η σύγκριση χρειάζεται όμως το σωστό scope: οι συγγραφείς χρησιμοποίησαν `GENERIC_INDEX`, ενώ η επίσημη AWS τεκμηρίωση διαθέτει `IMAGE_RETRIEVAL` για query embeddings που αναζητούν σε repository εικόνων. Το αποτέλεσμα δεν αποδεικνύει την καλύτερη δυνατή επίδοση κάθε ρύθμισης Nova.
Η διαφορά μετά το precomputation
Τα embedding systems πληρώνουν αρχικό κόστος για τη δημιουργία representations. Στο πείραμα, το Gemini Embedding 2 χρειάστηκε περίπου 2.000 δευτερόλεπτα για query embeddings και 12.500 για image embeddings, συνολικά περίπου 14.500. Το Nova 2 χρειάστηκε περίπου 1.800 και 10.000 δευτερόλεπτα, συνολικά 11.800. Τα image embeddings αφορούσαν 5.000 μοναδικές εικόνες και μπορούσαν να επαναχρησιμοποιηθούν.
Με έτοιμα embeddings, το ranking των 1.000 queries πήρε 0,66 δευτερόλεπτα στο Gemini Embedding 2 και 1,16 στο Nova 2. Τα GPT-4.1 και Claude Sonnet 4.6 χρειάστηκαν 6.100 και 9.415 δευτερόλεπτα αντίστοιχα, επειδή λειτουργούσαν με end-to-end API calls ανά query. Οι αριθμοί αφορούν τις συγκεκριμένες πειραματικές συνθήκες και όχι εγγυημένο production SLA, αλλά δείχνουν γιατί το offline indexing αλλάζει ριζικά το online serving.
Το latency του paper δεν είναι έτοιμο business case. Για σωστό cost model, χωρίστε το offline indexing από το online query, προσθέστε updates νέων ή αλλαγμένων προϊόντων και μετρήστε cache, vector database, filters, reranking και network overhead. Μόνο το συνολικό μονοπάτι εξυπηρέτησης δείχνει την πραγματική εμπειρία πελάτη.
Τι σημαίνει για e-commerce και content platforms
Για έναν μεγάλο και σχετικά σταθερό κατάλογο προϊόντων, φωτογραφιών ή digital assets, τα precomputed embeddings είναι ισχυρή προεπιλογή που υποστηρίζεται από τη συγκεκριμένη μελέτη. Επιτρέπουν χαμηλό online latency και επαναχρησιμοποίηση της ακριβής προεργασίας. Ένα e-shop μπορεί έτσι να χειριστεί query όπως «μπεζ παπούτσι για καθημερινό επαγγελματικό ντύσιμο» χωρίς να στέλνει όλες τις εικόνες του catalog σε LLM σε κάθε αναζήτηση.
Αυτό είναι εφαρμοσμένη ερμηνεία της αρχιτεκτονικής, όχι αποτέλεσμα πραγματικού e-commerce πειράματος. Το benchmark περιλαμβάνει 25 candidates ανά query. Μια παραγωγική υποδομή embeddings και vector search συνήθως χρειάζεται retrieval από πολύ μεγαλύτερο index, product attributes, availability, τιμή, κατηγορία, δικαιώματα χρήσης assets και εμπορικό reranking.
Η ποιότητα των product data παραμένει κρίσιμη. Αν χρώμα, παραλλαγή, υλικό ή χρήση λείπουν από το catalog, το visual model ίσως ανακτήσει οπτικά συγγενή προϊόντα αλλά το σύστημα δεν θα μπορεί να εφαρμόσει σωστά φίλτρα ή κανόνες. Η καθαρή, συνεπής γνώση προϊόντων που απαιτεί ένα AI-readable e-commerce συμπληρώνει το image retrieval· δεν αντικαθίσταται από αυτό.
Πότε έχει νόημα ένας LLM ranker
Οι συγγραφείς θεωρούν πιθανό να είναι προτιμότερος ο LLM ranker όταν η gallery είναι μικρή ή αλλάζει τόσο συχνά ώστε το precomputation να μην αποσβένεται. Επιπλέον, επειδή βλέπει ταυτόχρονα και τις 25 εικόνες, μπορεί να αξιοποιήσει συγκριτικό reasoning ανάμεσα σε λεπτές διαφορές των υποψηφίων. Το embedding model βαθμολογεί κάθε query-image pair ανεξάρτητα.
Μια εύλογη παραγωγική αρχιτεκτονική είναι υβριδική: embeddings για γρήγορο retrieval μικρού candidate set και LLM reranking μόνο σε queries όπου η πρόσθετη διάκριση έχει αρκετή αξία. Το paper δεν αξιολόγησε αυτό το pipeline, άρα δεν πρέπει να παρουσιαστεί ως αποδεδειγμένα καλύτερο. Χρειάζεται A/B test με πραγματικά queries, guardrails και σαφές fallback όταν ο reranker αργεί ή αποτυγχάνει.
Rule of thumb: ξεκινήστε με embedding retrieval όταν έχετε μεγάλο corpus, επαναλαμβανόμενα queries και αυστηρό latency. Δοκιμάστε περιορισμένο LLM reranking όταν οι candidates είναι λίγοι, οι οπτικές διαφορές απαιτούν σχετική σύγκριση και το πιθανό εμπορικό όφελος καλύπτει το πρόσθετο κόστος. Για catalog με υψηλή μεταβλητότητα, μετρήστε πρώτα τον ρυθμό re-indexing.
Οι περιορισμοί του benchmark
Το ground truth του Flickr30k μπορεί να είναι αμφίσημο. Μία λεζάντα ενδέχεται να περιγράφει εύλογα περισσότερες από μία εικόνες, ειδικά όταν οι distractors επιλέγονται λόγω σημασιολογικής ομοιότητας. Οι ποιοτικές παρατηρήσεις του paper δείχνουν μάλιστα περιπτώσεις όπου ένα σύστημα ήταν τυπικά λάθος, αλλά επέλεξε εικόνα εύλογα σχετική για ανθρώπινο αξιολογητή.
Οι συνθήκες inference δεν ήταν ίδιες. Τα LLMs έβλεπαν όλους τους candidates μαζί και οι θέσεις τους τυχαιοποιούνταν ανά query, ενώ τα embeddings δούλευαν ανεξάρτητα. Και τα τέσσερα συστήματα ήταν διαθέσιμα μέσω πληρωμένων APIs, των οποίων τα weights ή serving stacks μπορεί να αλλάξουν μετά το πείραμα. Αλλαγές στο prompt ή σε batching μπορούν επίσης να μεταβάλουν χρόνο και απόδοση.
Τέλος, τα 25-image candidate sets μετρούν ranking και όχι full-gallery retrieval. Το αποτέλεσμα δεν καλύπτει ANN index quality, filters, deduplication, cold starts, updates, authorization, monitoring ή conversion impact. Για ένα πραγματικό product search project, αυτά τα layers είναι μέρος της λύσης και πρέπει να σχεδιαστούν μαζί με την ιστοσελίδα ή web εφαρμογή που τα καταναλώνει.
Πλαίσιο απόφασης για ομάδα προϊόντος
Η επιλογή δεν πρέπει να ξεκινά από vendor ή εντυπωσιακό demo. Ξεκινά από operating profile: μέγεθος και ρυθμός αλλαγής του corpus, όγκος queries, αποδεκτό latency, διαθέσιμο budget, ανάγκη συγκριτικού reasoning και πραγματικό κόστος ενός λάθους. Η ομάδα χρειάζεται επίσης owner για το relevance, όχι μόνο τεχνικό owner για το API.
Έξι βήματα για pilot multimodal αναζήτησης εικόνων
- Step 1Ορίστε το εμπορικό query set
Συλλέξτε πραγματικές αναζητήσεις πελατών και χωρίστε τις σε ανάγκη, χαρακτηριστικό προϊόντος, περίσταση χρήσης και οπτική λεπτομέρεια.
- Step 2Κατασκευάστε αξιόπιστο ground truth
Ζητήστε από ανθρώπους που γνωρίζουν τον κατάλογο να σημειώσουν σωστά και αποδεκτά αποτελέσματα, όχι μόνο ένα αυθαίρετο μοναδικό match.
- Step 3Μετρήστε embedding baseline
Δημιουργήστε index με σωστά task types και καταγράψτε Recall@k, MRR, offline indexing time και online retrieval latency.
- Step 4Προσθέστε τους κανόνες του catalog
Εφαρμόστε category, stock, price, variant και permission filters ώστε η οπτική συνάφεια να μην εμφανίζει μη διαθέσιμες ή λανθασμένες επιλογές.
- Step 5Δοκιμάστε reranking μόνο όπου χρειάζεται
Περιορίστε τον LLM σε μικρό candidate set και μετρήστε αν η βελτίωση σε δύσκολες κατηγορίες δικαιολογεί latency και κόστος.
- Step 6Παρακολουθήστε failures και αλλαγές
Κατηγοριοποιήστε λάθη, ορίστε re-indexing SLA και επαναλάβετε το evaluation όταν αλλάζουν μοντέλο, prompt, catalog ή business rules.
Αξιολόγηση με τα δικά σας δεδομένα
Πριν από αγορά ή αλλαγή αρχιτεκτονικής, δημιουργήστε αντιπροσωπευτικό test set από πραγματικά queries και εικόνες του δικού σας catalog. Κρατήστε σταθερό το candidate set για τη συγκριτική δοκιμή και μετρήστε όχι μόνο Recall@1 ή MRR, αλλά end-to-end latency, χρόνο ενημέρωσης index, κόστος ανά 1.000 queries και ποσοστό queries που χρειάζονται fallback ή ανθρώπινη παρέμβαση.
Η ποιοτική ανάλυση αποτυχιών είναι εξίσου σημαντική. Άλλο είναι να μπερδεύονται δύο σχεδόν ίδιες σκηνές και άλλο να αγνοείται ιδιότητα προϊόντος που καθορίζει την αγορά. Για fashion μπορεί να είναι χρώμα, ύφασμα και περίσταση· για περιφερειακά υπολογιστών, θύρες, form factor και συμβατότητα. Η σωστή βελτιστοποίηση για αναζήτηση με AI πρέπει να απαντά στις πραγματικές διακρίσεις που χρειάζεται ο χρήστης.
Το συμπέρασμα του benchmark είναι σαφές αλλά περιορισμένο: σε 1.000 Flickr30k queries με 25 hard negatives, ένα εξειδικευμένο multimodal embedding model έφτασε την ακρίβεια των δύο frontier LLM rankers και πρόσφερε δραματικά ταχύτερο ranking μετά το indexing. Δεν αποδεικνύει ότι τα embeddings κερδίζουν παντού. Δείχνει ότι για μεγάλα, σχετικά σταθερά catalogs, η πρώτη παραγωγική υπόθεση πρέπει να είναι retrieval με precomputation και όχι επαναλαμβανόμενο full-context LLM ranking.
Από το benchmark σε μετρήσιμο search pilot
Σχεδιάστε multimodal retrieval πάνω στα δικά σας προϊόντα και queries
Η TWO DOTS χαρτογραφεί catalog data, relevance criteria, embedding index, business filters, latency budgets και ελεγχόμενο reranking, ώστε η αναζήτηση εικόνων να αξιολογηθεί με πραγματική επιχειρηματική ροή και όχι με ένα απομονωμένο demo.
Frequently Asked Questions (FAQs)
Τι είναι multimodal embedding;
Είναι αριθμητική αναπαράσταση διαφορετικών μέσων, όπως κείμενο και εικόνα, σε κοινό χώρο ώστε η συνάφειά τους να υπολογίζεται με similarity.
Τα frontier LLMs ήταν λιγότερο ακριβή;
Όχι με στατιστικά τεκμηριωμένο τρόπο στο συγκεκριμένο benchmark. Οι διαφορές του GPT-4.1 και του Claude Sonnet 4.6 από το Gemini Embedding 2 δεν ήταν στατιστικά σημαντικές.
Γιατί τα embeddings έκαναν ταχύτερο ranking;
Επειδή οι αναπαραστάσεις των εικόνων και των queries είχαν ήδη υπολογιστεί. Το online στάδιο έκανε similarity ranking αντί να επεξεργάζεται ξανά όλες τις εικόνες με LLM.
Μπορεί το αποτέλεσμα να εφαρμοστεί απευθείας σε e-shop;
Όχι χωρίς δική του αξιολόγηση. Το paper χρησιμοποίησε Flickr30k και 25 candidates, όχι πραγματικό product catalog με stock, τιμές, φίλτρα, variants και εμπορικούς κανόνες.
Πότε έχει νόημα ένας LLM ranker;
Όταν η συλλογή είναι μικρή ή αλλάζει πολύ συχνά και όταν η συγκριτική εξέταση λίγων candidates προσφέρει αξία που δικαιολογεί το πρόσθετο latency και κόστος.
Τι είναι hard negative;
Είναι λανθασμένος candidate που μοιάζει σημασιολογικά ή οπτικά με το σωστό αποτέλεσμα, άρα κάνει τη δοκιμή δυσκολότερη και πιο χρήσιμη από μια τυχαία επιλογή.
Γιατί χρειάζεται προσοχή στο αποτέλεσμα του Amazon Nova 2;
Το πείραμα χρησιμοποίησε GENERIC_INDEX, ενώ η AWS τεκμηριώνει IMAGE_RETRIEVAL για query embeddings σε αναζήτηση εικόνων. Δεν δοκιμάστηκε κάθε δυνατή βελτιστοποιημένη ρύθμιση.
Είναι καλύτερη μια υβριδική αρχιτεκτονική;
Είναι λογική υπόθεση προς δοκιμή: embeddings για γρήγορο retrieval και LLM για περιορισμένο reranking. Η συγκεκριμένη μελέτη δεν την αξιολόγησε, επομένως χρειάζεται δικό της A/B test.