Ricerca per immagini: come funziona, e che cosa fanno davvero i motori
Due implementazioni a confronto, Meilisearch e Algolia: la prima fa entrare la fotografia dentro il motore, la seconda la traduce in parole prima di cercarla.
In un catalogo informatico il problema si presenta cosi'. Un cliente ha in mano un alimentatore, un adattatore, una staffa di montaggio. Non ne conosce il nome commerciale, non ha il codice, e la fiancata riporta soltanto una sigla. Nella vostra scheda quella sigla c'e', ma il cliente non la sa leggere, e quello che vede - la forma del connettore, il numero di viti, l'attacco - nella scheda non e' scritto da nessuna parte. La ricerca testuale, per quanto ben configurata, qui non ha materia su cui lavorare. La domanda non e' fatta di parole.
COME UN'IMMAGINE DIVENTA UN NUMERO
Il meccanismo e' lo stesso della ricerca per significato, applicato a un contenuto diverso.
Un modello addestrato riceve una fotografia e restituisce una lista di numeri, tipicamente qualche centinaio o qualche migliaio. Quella lista non descrive i pixel: descrive il contenuto, nel senso che due immagini che rappresentano oggetti simili producono liste vicine fra loro, anche se le fotografie sono state scattate con luce, sfondo e inquadratura diversi. Vicine, qui, ha un significato geometrico preciso: si misura la distanza fra le due liste come si misurerebbe fra due punti.
Il passaggio che rende utile tutto questo e' un altro, ed e' il punto in cui conviene fermarsi. Alcuni modelli vengono addestrati a produrre liste confrontabili fra tipi di contenuto diversi: la fotografia di un adattatore e la frase "adattatore da USB-C a HDMI" finiscono vicine nello stesso spazio. Sono questi i modelli che vengono chiamati multimodali, dove modalita' sta per il tipo di contenuto, testo o immagine.
E' una condizione, non un dettaglio. Se le fotografie vengono vettorizzate da un modello e i testi da un altro, le due liste appartengono a spazi diversi e confrontarle non produce alcuna informazione: i numeri si possono sottrarre, ma il risultato non significa niente. Ogni impianto di ricerca per immagini funziona o non funziona in base a questo.
DUE DOMANDE DIVERSE, CHE VENGONO SEMPRE CONFUSE
Sotto l'espressione ricerca per immagini si nascondono due esigenze distinte, e quasi tutta la confusione commerciale nasce dal non separarle.
La prima e' prodotti simili a questo. Il punto di partenza e' un articolo che sta gia' nel vostro catalogo, con la sua fotografia gia' caricata, e il risultato atteso sono altri articoli visivamente affini. E' il blocco che compare sotto la scheda. Tutto il lavoro avviene all'interno del catalogo, in un momento qualsiasi, e nulla arriva dall'esterno.
La seconda e' il cliente fotografa e cerca. Il punto di partenza e' un'immagine che non avete mai visto, scattata in condizioni che non controllate, e che deve essere confrontata con il catalogo nel tempo di una richiesta.
Sono due problemi di difficolta' molto diversa, e i due motori che seguono ne risolvono uno ciascuno per intero e uno solo in parte.
LA STRADA DI MEILISEARCH
Meilisearch ha introdotto la ricerca multimodale nella versione 1.16 e la dichiara tuttora sperimentale, il che significa che va abilitata esplicitamente e che la sua interfaccia puo' cambiare fra una versione e l'altra.
In fase di indicizzazione si configurano dei frammenti: si indica al motore quale campo del documento contiene l'indirizzo dell'immagine, accanto ai campi testuali che gia' venivano vettorizzati. Il motore si occupa di inviare l'uno e gli altri al modello.
In fase di interrogazione la fotografia viaggia dentro la richiesta, nel parametro `media`, convertita in base64 dal vostro lato. Il motore la vettorizza e la confronta con l'indice esattamente come farebbe con una frase.
I vincoli dichiarati sono tre. Il parametro `media` non si combina con il passaggio diretto di vettori. Deve corrispondere a un solo frammento di ricerca, altrimenti la richiesta viene rifiutata. E le immagini vanno ridimensionate a un massimo di 1024 pixel di lato, perche' oltre quella soglia crescono peso della richiesta e tempo di risposta senza guadagno di qualita'.
Resta un requisito che pesa sul progetto piu' di tutti i precedenti: il modello multimodale non e' incluso. Va preso da un fornitore esterno, con il suo contratto e il suo listino - la documentazione indica voyage-multimodal-3 di Voyage AI e Marengo di TwelveLabs - e i modelli testuali di uso comune non sono adatti, perche' leggono solo testo.
LA STRADA DI ALGOLIA
Algolia affronta le due domande separatamente, e con due prodotti che hanno maturita' diversa.
Alla prima risponde Looking Similar, dentro Algolia Recommend, che non e' sperimentale. Si indica quale campo contiene le immagini, fino a tre, e il servizio le vettorizza per conto proprio: nessun modello da procurare, nessun fornitore aggiuntivo, nessun evento da tracciare prima di poterlo usare. Il limite dichiarato e' di 500.000 immagini per addestramento, che per la maggior parte dei cataloghi non e' un limite. Da quel momento il sistema sa dire quali prodotti si assomigliano.
Alla seconda domanda Algolia non risponde con un endpoint a cui inviare una fotografia. Il percorso documentato prevede che l'immagine del cliente venga inviata a un servizio di riconoscimento esterno, tipicamente Google Cloud Vision, che restituisce delle etichette testuali; quelle etichette diventano poi una normale interrogazione testuale. Dentro Algolia l'immagine, come immagine, non entra mai.
CHE COSA CAMBIA IN PRATICA
La differenza si misura in quello che sopravvive al passaggio.
Quando una fotografia viene tradotta in parole, sopravvive cio' che il servizio di riconoscimento ha un'etichetta per nominare. Un adattatore diventa "adapter, cable, electronics": tre parole corrette e insufficienti, che nel vostro catalogo corrispondono a qualche migliaio di articoli. La forma del connettore, che era l'unica informazione discriminante dell'immagine, non ha un'etichetta e quindi non esiste piu'. Il vantaggio e' che il risultato e' leggibile, verificabile e correggibile: potete vedere quali parole sono state estratte e intervenire.
Quando la fotografia resta numeri fino al confronto, quelle caratteristiche sopravvivono, perche' non sono mai state ridotte a un vocabolario. Il costo e' che il percorso diventa opaco: un risultato sbagliato non ha una parola da correggere, ha una distanza da rimisurare, e la diagnosi richiede strumenti diversi.
C'e' poi una voce di costo che non compare nelle presentazioni e che va messa a bilancio in fase di progetto. Introdurre la ricerca per immagini su un catalogo esistente significa vettorizzare tutte le fotografie, non solo quelle dei prodotti nuovi, e rifarlo da capo ogni volta che si cambia modello, perche' liste prodotte da modelli diversi non sono confrontabili fra loro. Su un catalogo di media dimensione e' un'operazione di ore e un costo una tantum contenuto; su un catalogo con dieci fotografie per articolo diventa una voce che conviene stimare prima di firmare.
A questo si aggiunge il conto delle parti. La prima strada richiede un fornitore in piu' e una funzione che il progetto stesso dichiara ancora instabile. La seconda richiede un fornitore in piu' soltanto per la ricerca a partire da fotografia, mentre per i prodotti simili e' inclusa e immediata.
La domanda da porsi prima di scegliere non riguarda il motore. Riguarda quale delle due esigenze il vostro catalogo deve soddisfare davvero, e se le vostre fotografie siano in condizione di sostenerla: scatti coerenti, soggetto isolato, una sola inquadratura per articolo. Un impianto di ricerca per immagini costruito su un archivio fotografico disomogeneo restituisce risultati disomogenei, e nessuna delle due strade lo corregge.