Il vecchio BM25 non arretra nemmeno davanti al Khmer. Nel lavoro KSE-Web, un gruppo di ricerca ha messo a confronto il recupero lessicale basato su n-grammi di carattere, il retrieval denso multilingue, una combinazione ibrida e l'espansione delle query assistita da modelli Qwen2.5. Su un dataset costruito partendo da circa 17.000 titoli candidati e filtrato fino a 3.000 documenti khmer full-text, con 300 query in stile utente revisionate a mano ed etichette di rilevanza silver parzialmente verificate, il risultato è netto: BM25 ottiene 0,943 di Recall e 0,876 di nDCG. L'approccio ibrido si avvicina (0,929 Recall e 0,871 nDCG), mentre il solo retrieval denso resta indietro.

Il dato più interessante arriva dall'espansione con LLM. Non solo non supera il recupero senza espansione, ma introduce derive tematiche, termini generici e riformulazioni rumorose. C'è però una differenza rilevante tra i due modelli usati: Qwen2.5-3B produce espansioni sostanzialmente migliori rispetto a Qwen2.5-0.5B. Questo suggerisce che per una lingua a basse risorse come il Khmer la dimensione del modello e la qualità dell'espansione contano, ma non bastano a ribaltare il ranking finale. Lo studio osserva anche che un filtraggio semplice delle espansioni può rimuovere segnali semantici utili. In lingue a basse risorse, pulire troppo il testo generato rischia di cancellare sinonimi o varianti ortografiche preziose, mentre non pulire abbastanza lascia passare rumore.

Dietro il confronto tecnico c'è una lezione strutturale per chi progetta stack di ricerca locale. Il Khmer ha confini di parola ambigui, pochi dati annotati, scarso supporto nei modelli di embedding multilingue e una frequente commistione con l'inglese. In questo contesto, la robustezza degli n-grammi di carattere si comporta come un'ancora: non richiede GPU, non dipende da un servizio cloud e mantiene costi operativi bassi. L'ibrido con il retrieval denso aggiunge poco in termini di nDCG e introduce complessità. Per un deployment on-premise, il punto non è che l'LLM sia inutile, ma che va posizionato in modo mirato: se l'espansione non migliora il recupero, aggiungere un modello anche piccolo rischia di consumare risorse senza benefici misurabili.

C'è anche un problema di qualità dei dati. Le etichette silver con verifica solo parziale rendono il benchmark meno solido di quanto i numeri lascino intendere. Chi vorrà usare questo lavoro come base dovrà investire in annotazioni umane più estese, perché i modelli Khmer-aware non nascono da soli: nascono da dataset verificati. Lo studio lo riconosce esplicitamente e indica proprio lì la direzione per il futuro.

Per i vendor e i team che lavorano su lingue a basse risorse, il risultato è un promemoria: i modelli di embedding multilingue non sono una scorciatoia universale. E per chi valuta pipeline di ricerca self-hosted, la questione non è solo quale LLM eseguire in locale, ma se l'LLM abbia un ruolo reale nella fase di recupero. In questo caso, il carattere n-gram di BM25 continua a fare il lavoro pesante, mentre l'intelligenza artificiale generativa mostra limiti chiari quando la lingua non è ben rappresentata nel pre-training. Il repository promesso su GitHub è un primo passo; la solidità delle conclusioni dipenderà da quanto la comunità riuscirà a rafforzare la verifica umana.