Lei invia un chatbot per il suo team tedesco. L'interfaccia utente è tedesca. I documenti di origine sono in parte tedeschi e in parte inglesi. Gli strumenti dietro l'assistente si aspettano valori enum in inglese, descrizioni di funzioni in inglese, nomi di prodotti in inglese, tutto in inglese.
Poi qualcuno fa una domanda perfettamente normale in tedesco, il modello sceglie lo strumento giusto, passa un argomento in tedesco invece che in inglese e l'intera faccenda va tranquillamente in pezzi.
Ho visto versioni di questo tipo abbastanza volte da non considerarlo più un problema di traduzione. Si tratta di un problema di esecuzione.
La mia impostazione attuale è semplice: lasciare che gli utenti parlino la lingua che desiderano, ma lasciare che l'LLM svolga il suo lavoro di reperimento, ragionamento e strumento in inglese quando l'affidabilità è effettivamente importante. Poi localizzare la risposta al di fuori di questo ciclo.
All'inizio sembra un po' eretico. Ma è anche, a mio avviso, la cosa più pratica che si possa fare in questo momento.
La ricerca sta iniziando a dirlo ad alta voce
I numeri non sono più sottili.
Nel benchmark MASSIVE-Agents, i ricercatori hanno valutato la chiamata di funzioni multilingue in 52 lingue, 47.020 campioni e 21 modelli. Il miglior punteggio medio in tutte le lingue è stato solo del 34,05%. L'inglese ha raggiunto il 57,37%. L'amarico è sceso al 6,81%.
Non si tratta di una piccola oscillazione della qualità. Si tratta di un precipizio di affidabilità.
Poi c'è [Lost in Execution] (https://arxiv.org/abs/2601.05366), che si avvicina ancora di più al problema dei sistemi reali. L'articolo mostra che molti fallimenti nella chiamata di strumenti multilingue avvengono dopo che il modello aveva già compreso l'intento e selezionato lo strumento corretto. Il problema dominante era la mancata corrispondenza linguistica dei valori dei parametri. In parole povere, il modello sapeva cosa fare, ma esprimeva i bit eseguibili nella lingua dell'utente invece che nella lingua dell'interfaccia, quindi la chiamata falliva comunque.
E questo non si limita alle chiamate agli strumenti. In Do Multilingual Language Models Think Better in English?, Etxaniz e colleghi hanno scoperto che l'auto-traduzione in inglese batteva in modo consistente l'inferenza diretta non inglese in cinque compiti. La loro formulazione è sorprendentemente schietta: i modelli non sono "in grado di sfruttare il loro pieno potenziale multilingue quando vengono sollecitati in lingue diverse dall'inglese".
Quindi sì, i modelli multilingue sono impressionanti. Ma se la vostra barra non è "sembra abbastanza buono" e invece è "deve comportarsi correttamente in produzione", l'inglese sembra ancora la lingua operativa più sicura molto spesso.
Perché RAG si rompe sempre nello stesso punto
Di solito le persone sentono questo argomento e pensano prima agli agenti. Chiamate di funzioni, output strutturato, esecuzione di API, questo genere di cose.
RAG ha la stessa debolezza, solo un livello prima.
Se il suo livello di reperimento deve abbinare il fraseggio locale di un utente a contenuti scritti in lingue miste, con una terminologia incoerente, nomi di prodotti tradotti ed etichette di tassonomia semilocalizzate, si creano più possibilità che il sistema vada alla deriva prima ancora di iniziare la generazione. Onestamente, è da qui che provengono molte delle lamentele "il modello è inaffidabile". Il modello può andare bene. L'interfaccia dei contenuti non lo è.
Preferirei normalizzare in anticipo.
Tradurre la domanda in inglese. Recuperare rispetto a un corpus canonico inglese. Lasciare che il modello ragioni su un livello terminologico stabile. Generare una bozza di risposta in inglese, se necessario. Poi traduce o localizza la risposta finale per l'utente.
In questo modo si ottiene un luogo in cui la denominazione rimane stabile:
- un titolo di documento canonico
- un vocabolario di prodotto canonico
- uno schema di strumenti canonico
- un insieme canonico di etichette di reperimento
È ancora possibile supportare ogni lingua dell'utente all'esterno. Basta smettere di chiedere al percorso di esecuzione principale di essere perfettamente multilingue in ogni fase.
Questo non è anti-localizzazione
Al contrario.
Una cattiva architettura AI multilingue di solito danneggia prima gli utenti locali. Ricevono la bella interfaccia localizzata, poi il sistema nascosto anglo-centrico sottostante si comporta in modo incoerente e fa pagare loro il prezzo.
Una localizzazione corretta significa essere onesti su dove la lingua deve flettersi e dove no.
Per me, la divisione è la seguente:
- Localizzare l'interfaccia utente, i suggerimenti, il testo di aiuto, l'onboarding e le risposte finali.
- Localizzare i contenuti di partenza che le persone leggono direttamente quando questi contenuti devono esistere sul mercato.
- Mantenere le definizioni interne degli strumenti, gli identificatori canonici, le etichette di recupero e i perni di ragionamento in inglese, se questo è il livello più stabile.
- Aggiungere una post-elaborazione esplicita o una revisione umana quando un risultato localizzato ha un peso legale, normativo o contrattuale.
Quest'ultimo punto è più importante di quanto i team amino ammettere. Se il modello sta parlando con un essere umano, la localizzazione è una decisione legata all'esperienza dell'utente. Se il modello sta parlando con un altro sistema, la lingua è un contratto di interfaccia.
Non sono la stessa cosa.
L'architettura di cui mi fido di più in questo momento
Questa è la versione su cui punterei oggi per i prodotti AI multilingue:
- L'utente chiede nella sua lingua.
- Il sistema traduce o normalizza la richiesta in inglese.
- Il recupero, il ragionamento, la classificazione e le chiamate agli strumenti avvengono rispetto ai dati canonici inglesi.
- La risposta finale viene localizzata nella lingua dell'utente.
- I risultati ad alto rischio ricevono un'ulteriore fase di convalida prima di lasciare il sistema.
Non è filosoficamente puro. È sano dal punto di vista operativo.
L'aspetto positivo è che la ricerca recente punta nella stessa direzione. Lost in Execution ha scoperto che la pre-traduzione delle query degli utenti generalmente riduce gli errori di corrispondenza linguistica meglio delle correzioni post-hoc, anche se non recupera completamente le prestazioni a livello inglese. Questo corrisponde a ciò che molti costruttori già sospettano nella pratica. Se si aspetta fino alla fine per pulire l'incoerenza multilingue, di solito è troppo tardi.
E sì, ci sono delle eccezioni. Se si sta costruendo per lingue a bassa risorsa, per un linguaggio specifico del dominio o per un fraseggio culturalmente dipendente, tradurre tutto in inglese può introdurre una deriva. Il documento di cui sopra mette esplicitamente in guardia su questo aspetto. Quindi non trasformi questo in un dogma.
Ma come impostazione predefinita per i copiloti aziendali, gli assistenti interni, i RAG multilingue e gli agenti che utilizzano gli strumenti, credo che la regola sia sorprendentemente valida.
Cosa significa questo per Rasepi
Questo è esattamente il motivo per cui mi interessa tanto la struttura canonica dei contenuti.
Se la sua base di conoscenza ha un livello sorgente pulito, una terminologia stabile e una localizzazione controllata, l'AI diventa più facile da fidarsi. Se ogni versione linguistica va alla deriva in modo indipendente all'interno del percorso di esecuzione, si chiede al modello di improvvisare laddove il sistema dovrebbe essere preciso.
L'intero approccio di Rasepi si basa sulla separazione netta di queste preoccupazioni. Mantenere un nucleo canonico. Localizzare deliberatamente. Rintracciare dove esistono le varianti. Non pretenda che ogni livello dello stack sia ugualmente multilingue solo perché lo è l'interfaccia utente.
Un tempo pensavo che la migliore esperienza AI multilingue significasse "fare tutto nella lingua dell'utente". Non lo penso più. Non per i sistemi che devono recuperare il paragrafo giusto, scegliere lo strumento giusto e restituire qualcosa di cui ci si può fidare.
La regola pratica è semplice: gli utenti devono rimanere locali, ma il percorso di esecuzione dell'LLM deve rimanere stabile. Al momento, questo significa di solito l'inglese al centro e la localizzazione ai margini.
Questo cambierà nel tempo. Spero che cambi rapidamente. Ma se sta effettuando una spedizione oggi e l'affidabilità è più importante dell'estetica, lascerei che il modello pensi in inglese e che il suo prodotto parli la lingua dell'utente.