Come abbiamo usato la ricerca semantica per rendere la nostra ricerca 10 volte più intelligente
In Tokopedia, comprendiamo che il valore del nostro corpus di prodotti si sblocca solo quando i nostri acquirenti riescono a trovare prodotti pertinenti per loro, quindi ci impegniamo a migliorare la pertinenza dei risultati di ricerca.
Per portare avanti questo impegno, stiamo introducendo la ricerca per similarità su Tokopedia. Se vai alla pagina dei risultati di ricerca su dispositivi mobili, troverai un pulsante “…” che apre un menu che ti dà l’opzione di cercare prodotti simili al prodotto.
Ricerca basata su parole chiave
Tokopedia Search utilizza Elasticsearch per la ricerca e il ranking dei prodotti. Per ogni richiesta di ricerca, interroghiamo prima Elasticsearch, che classifica i prodotti in base alla query di ricerca. ElasticSearch memorizza ogni parola come una sequenza di numeri che rappresentano i codici ASCII (o UTF) per ogni lettera. Costruisce un indice invertito per scoprire rapidamente quali documenti contengono parole della query dell’utente, e poi trova la migliore corrispondenza tra essi usando vari algoritmi di scoring. Questi algoritmi di scoring prestano poca attenzione a ciò che significano le parole, ma piuttosto a quanto frequentemente compaiono nel documento, quanto sono vicine tra loro, ecc. La rappresentazione ASCII contiene ovviamente abbastanza informazioni per trasmettere la semantica (dopotutto noi, esseri umani, possiamo comprenderla). Sfortunatamente, non esiste un buon algoritmo che permetta al computer di confrontare le parole codificate in ASCII in base al loro significato.
Rappresentazione vettoriale
Una soluzione a questo sarebbe ideare una rappresentazione alternativa, che ci dica non solo quali lettere sono contenute nella parola ma anche qualcosa sul suo significato. Per esempio, potremmo codificare con quali altre parole la nostra parola viene frequentemente usata insieme (rappresentandola tramite il contesto probabile). Assumeremmo quindi che contesti simili rappresentino cose simili, e proveremmo a confrontarli usando metodi matematici. Potremmo persino trovare un modo per codificare intere frasi in base al loro significato.
La rappresentazione vettoriale rivela anche il significato delle parole rispetto alla rappresentazione ASCII.
Selezionare un motore di ricerca di similarità degli embedding
Ora che abbiamo i vettori di feature, il problema rimanente è come recuperare dal grande volume di vettori quelli che sono simili al vettore target. Per quanto riguarda il motore di ricerca degli embedding, abbiamo provato una POC su diversi motori disponibili su Github, alcuni dei quali sono FAISS, Vearch, Milvus.
Preferiamo Milvus ad altri motori in base ai risultati dei test di carico. Da un lato, avevamo già usato FAISS in altri team e quindi volevamo provare qualcosa di nuovo. Rispetto a Milvus, FAISS è più una libreria di basso livello, quindi non particolarmente comoda da usare. Man mano che abbiamo approfondito Milvus, alla fine abbiamo deciso di adottare Milvus per le sue due caratteristiche principali:
Milvus è molto facile da usare. Tutto ciò che devi fare è scaricare la sua immagine Docker e aggiornare i parametri in base al tuo scenario.
Supporta più indici e dispone di documentazione di supporto dettagliata.
In sintesi, Milvus è molto user-friendly e la documentazione è piuttosto dettagliata. Se incontri un problema, di solito puoi trovare soluzioni nella documentazione; altrimenti, puoi sempre ottenere supporto dalla community di Milvus.
Servizio cluster Milvus
Dopo aver deciso di usare Milvus come motore di ricerca di vettori di feature, abbiamo deciso di usare Milvus per uno dei casi d’uso del nostro servizio Ads, in cui volevamo abbinare parole chiave a basso fill rate con parole chiave ad alto fill rate. Abbiamo configurato un nodo standalone in un ambiente di sviluppo (DEV) e avviato il servizio; aveva funzionato bene per alcuni giorni, fornendoci metriche CTR/CVR migliorate. Se un nodo standalone si arrestasse in produzione, l’intero servizio diventerebbe non disponibile. Pertanto, dobbiamo distribuire un servizio di ricerca ad alta disponibilità.
Milvus fornisce sia Mishards, un middleware di sharding per cluster, sia Milvus-Helm per la configurazione. In Tokopedia utilizziamo playbook Ansible per la configurazione dell’infrastruttura, quindi abbiamo creato un playbook per l’orchestrazione dell’infrastruttura. Il diagramma seguente, tratto dalla documentazione di Milvus, mostra come funziona Mishards:
Come funziona Mishards.
Mishards trasmette una richiesta dall’upstream verso i suoi sotto-moduli suddividendo la richiesta upstream, quindi raccoglie e restituisce all’upstream i risultati dei sotto-servizi. L’architettura complessiva della soluzione cluster basata su Mishards è mostrata di seguito:
Architettura complessiva di Mishards.
La documentazione ufficiale fornisce una chiara introduzione a Mishards. Puoi consultare Mishards se sei interessato.
Nel nostro servizio keyword-to-keyword, abbiamo distribuito un nodo scrivibile, due nodi di sola lettura e un’istanza middleware Mishards in GCP, utilizzando Milvus ansible. Finora è stato stabile. Un componente fondamentale che rende possibile interrogare in modo efficiente i dataset di milioni, miliardi o persino trilioni di vettori su cui si basano i motori di ricerca per similarità è l’indicizzazione, un processo di organizzazione dei dati che accelera drasticamente la ricerca su big data.
In che modo l’indicizzazione vettoriale accelera la ricerca per similarità?
I motori di ricerca per similarità funzionano confrontando l’input con un database per trovare gli oggetti più simili all’input. L’indicizzazione è il processo di organizzazione efficiente dei dati e svolge un ruolo fondamentale nel rendere utile la ricerca per similarità accelerando drasticamente le query dispendiose in termini di tempo su grandi dataset. Dopo che un enorme dataset vettoriale è stato indicizzato, le query possono essere instradate verso cluster, o sottoinsiemi di dati, che hanno maggiori probabilità di contenere vettori simili a una query di input. In pratica, questo significa che si sacrifica un certo grado di accuratezza per velocizzare le query su dati vettoriali davvero grandi.
Si può fare un’analogia con un dizionario, in cui le parole sono ordinate alfabeticamente. Quando si cerca una parola, è possibile navigare rapidamente verso una sezione che contiene solo parole con la stessa iniziale — accelerando drasticamente la ricerca della definizione della parola di input.
E poi, vi chiederete?
Blog_How we used semantic search to make our search 10x smarter_5.jpeg
Come mostrato sopra, non esiste una soluzione adatta a tutto: vogliamo sempre migliorare le prestazioni del modello utilizzato per ottenere gli embedding.
Inoltre, da un punto di vista tecnico, vogliamo eseguire più modelli di apprendimento contemporaneamente e confrontare i risultati dei vari esperimenti. Seguite questo spazio per maggiori informazioni sui nostri esperimenti, come la ricerca di immagini e la ricerca di video.
Riferimenti:
- Mishards Docs：https://milvus.io/docs/v0.10.2/mishards.md
- Mishards: https://github.com/milvus-io/milvus/tree/master/shards
- Milvus-Helm: https://github.com/milvus-io/milvus-helm/tree/master/charts/milvus
Questo articolo del blog è ripubblicato da: https://medium.com/tokopedia-engineering/how-we-used-semantic-search-to-make-our-search-10x-smarter-bd9c7f601821
Leggi altre storie di utenti per saperne di più su come creare soluzioni con Milvus.
Continua a leggere
How to Choose the Best Embedding Model for RAG in 2026: 10 Models Benchmarked
We benchmarked 10 embedding models on cross-modal, cross-lingual, long-document, and dimension compression tasks. See which one fits your RAG pipeline.
Why AI Databases Don't Need SQL
Whether you like it or not, here's the truth: SQL is destined for decline in the era of AI.
What Exactly Are AI Agents? Why OpenAI and LangChain Are Fighting Over Their Definition?
AI agents are software programs powered by AI that can perceive their environment, make decisions, and take actions to achieve a goal—often autonomously.