Añadir bangla, swahili y hausa a un asistente humanitario soberano

Nuestro asistente humanitario responde preguntas sobre el canon normativo del sector —el Manual Esfera, los Convenios de Ginebra, la Convención sobre el Estatuto de los Refugiados de 1951 y sus afines— a partir de un corpus que ingerimos y sobre el que generamos los embeddings nosotros mismos, tras un perímetro de salida (egress) donde cada llamada al modelo queda registrada, redactada y resulta atribuible. El corpus está en inglés. Las personas que lo necesitan a menudo no hablan inglés.

Así que decidimos añadir tres idiomas: bangla, swahili y hausa. Juntos cubren contextos humanitarios desde Cox's Bazar hasta el Sahel. Por separado, son tres problemas de ingeniería muy distintos —y solo lo sabemos porque medimos cada uno antes de construir nada.

Esta es la historia de esas mediciones: lo que costaron (un puñado de euros), lo que encontraron, y el método de trabajo que hizo que la arquitectura emergiera de los datos en lugar de una opinión preconcebida.

Cuatro capas, cuatro maneras de fallar

Un idioma no está «soportado» porque la ficha del modelo lo diga. Para un usuario que escribe en bangla, tienen que funcionar cuatro capas independientes:

1. Detectar — saber en qué idioma está el mensaje. Nuestra heurística existente, construida para un mundo ucraniano/ruso/inglés, clasificaba los tres idiomas nuevos como inglés.
2. Recuperar — encontrar los pasajes correctos en inglés a partir de una consulta escrita en otro idioma. La recuperación interlingüe es tarea del modelo de embeddings.
3. Generar — responder en el idioma del usuario, anclado en evidencia en inglés, sin recurrir a un proveedor que rompa la postura de soberanía.
4. Redactar — detectar nombres, números de teléfono e identificaciones nacionales antes de que nada cruce el perímetro. Fallar cerrado (fail closed), idioma por idioma.

Cada capa puede fallar por su cuenta, pero resulta que fallan de forma distinta según el idioma.

Medir primero, alquilar nada

Antes de comprometernos con ninguna arquitectura (ni ninguna GPU), ejecutamos dos sondas sobre un nivel de inferencia serverless de la UE, facturado por token. Cerca de 2900 llamadas al modelo, menos de cinco euros, ninguna instancia llegó a aprovisionarse.

Las sondas heredaron la disciplina de evaluación que ya habíamos pagado en matrícula sobre la pila en inglés:

• Repetir todo. Nuestra evaluación tiene un suelo de ruido conocido (~4 puntos en una escala de 100 entre ejecuciones idénticas). Cualquier comparación de una sola ejecución por debajo de ese margen está midiendo el estado de ánimo del generador. Cada cifra de más abajo es la media de tres ejecuciones, con la dispersión indicada.
• Puntuar la recuperación por separado de la generación. Hacerlo junto impide la observabilidad.
• Verificar las traducciones. Las preguntas de evaluación se tradujeron automáticamente y luego se comprobaron mediante retrotraducción (round-trip) con un modelo independiente, con un tercer modelo evaluando la equivalencia semántica. Tasas de supervivencia: bangla 32/40, swahili 25/40, hausa 22/40 —y una de las incidencias señaladas en bangla era una sustitución silenciosa de sarampión por cólera. Eso ya es un hallazgo en sí mismo: el contenido traducido automáticamente necesita revisión, se haga lo que se haga con la conversación.
• Desconfiar del juez. Los resultados de hausa se reevaluaron por completo con un segundo modelo de una familia distinta. La clasificación se mantuvo; las cifras absolutas cambiaron. Informar de ambas.

Hallazgo 1 — Generación: un modelo es uniforme entre idiomas

Dimos a tres modelos candidatos la evidencia en inglés correcta y la pregunta en cada idioma, exigiendo la respuesta en ese mismo idioma. Esto aísla por completo la generación interlingüe de la recuperación.

Un modelo —Gemma— sitúa sus tres puntuaciones en los otros idiomas alrededor de su propia puntuación en inglés. Un modelo falla estrepitosamente en hausa. Y el fallo más instructivo no estaba siquiera en las puntuaciones: mistral-small respondió preguntas en bangla usando inglés el 32% de las veces, pese a las instrucciones explícitas. Su contenido estaba bien; su cumplimiento del idioma, no. Un juez LLM pasó esto por alto de forma sistemática —un script de cinco líneas que comprobaba el sistema de escritura Unicode de la respuesta lo detectó siempre. Las comprobaciones deterministas baratas superan a los jueces basados en modelos allí donde se pueda escribir una.

Hallazgo 2 — Recuperación: la imagen especular

A continuación, las mismas preguntas se lanzaron contra el corpus en vivo como consultas, para comprobar si nuestro modelo de embeddings (bge-m3) puede recuperar pasajes en inglés a partir de texto en otro idioma. El control en inglés reprodujo con exactitud nuestra línea base de producción —siempre hay que validar el arnés de prueba (harness) antes de creérselo.

El bangla recupera con paridad respecto al inglés. El hausa se desploma —y se descartó el ruido de la traducción automática repuntuando solo sobre las traducciones verificadas como limpias (mismo resultado). El modelo de embeddings, sencillamente, no ha visto suficiente hausa, lo cual coincide con lo que la literatura de recuperación en idiomas africanos (AfriMTEB) reporta para esta clase de modelos.

Al poner los dos hallazgos uno junto al otro, la arquitectura se diseña sola:

Medimos ese giro esa misma tarde: traducir las consultas en hausa al inglés con NLLB-200 (el modelo destilado de 1300 millones de parámetros, en CPU, segundos por consulta) elevó la recuperación de 0.37 MRR a 0.70 —por encima del swahili nativo— y redujo las preguntas nunca recuperadas de 15 a 2. Un idioma que por la mañana habríamos calificado de inviable tenía por la tarde una arquitectura extremo a extremo demostrada, y la solución cuesta un paso de traducción de segundos de CPU sobre las consultas de un único idioma.

Hallazgo 3 — Redacción: las trampas son todas silenciosas

La capa de privacidad era la brecha más grande: el framework estándar del sector para PII no tiene ningún modelo para estos idiomas. Añadimos un segundo servicio analizador —modelos NER basados en transformers entrenados con corpus de idiomas africanos y bangla— dejando intacto el analizador existente, ya medido. Dos servicios, para que ampliar la cobertura nunca pueda hacer retroceder en silencio algo que ya se había medido.

Medir el recall antes del despliegue detectó tres defectos, cada uno de los cuales habría sido invisible en una revisión de código:

1. El redactor enmascaraba la palabra «beneficiario» y dejaba escapar el nombre real. El tokenizador del modelo en bangla elimina las marcas vocálicas; con la agregación de spans por defecto, los fragmentos del nombre se perdían al alinearlos. Un único valor de configuración (aggregation: max) lo arregló —pero solo una medición de recall lo habría revelado.
2. El potenciador de contexto del framework nunca se activaba. Los patrones de identificación puntuaban justo por debajo del umbral de redacción pese a estar junto a una palabra de contexto perfecta («NID», «kitambulisho»), porque el tokenizador multilingüe no proporciona lemas con los que el potenciador pueda emparejar. Las cifras parecían plausibles; estaban sistemáticamente un escalón por debajo de lo debido.
3. «Common Article 3» se convirtió en <PERSON_1>. En hausa, el modelo NER etiquetó como persona el inicio de una cita de una pregunta sobre los Convenios de Ginebra —lo que habría destruido silenciosamente una de las consultas más importantes del corpus. Las listas blancas de vocabulario de dominio existen exactamente para esto.

El sistema desplegado mide ahora un recall de 120/120 sobre nuestro corpus etiquetado —y publicamos esa cifra con su salvedad correspondiente: el corpus se construye a partir de las mismas reglas de formato que codifican los reconocedores, así que parte de esa puntuación es tautológica. Cuando nuestra redacción de ucraniano/ruso se enfrentó a un conjunto de prueba genuinamente reservado (held-out), el ~100% se convirtió en 84.2%. Esa es la cifra que citamos para esos idiomas, y los tres idiomas nuevos no tendrán una cifra pública hasta que existan sus propios conjuntos reservados. Una cifra de recall sin su procedencia es marketing, no evidencia.

Hallazgo 4 — La medición se paga sola en errores que no estabas buscando

Al hacer que la capa de búsqueda léxica fuera consciente de Unicode (antes descartaba todos los caracteres bengalíes), descubrimos que el tokenizador nunca había reconocido la letra ucraniana «ї» —un hueco de un solo carácter en una expresión regular que llevaba fragmentando en silencio la mayoría de las palabras ucranianas en la búsqueda por palabras clave desde que se lanzó la funcionalidad. Nadie lo notó, porque la recuperación híbrida se degradaba con elegancia en lugar de fallar. Ese error no se encontró por un reporte de bug, sino porque una sonda se negó a producir un número sensato.

El mismo patrón se repitió todo el día. El control de calidad por retrotraducción señaló 32 de 40 traducciones al hausa como rotas —hasta que revisamos al verificador y descubrimos que era el propio modelo de retrotraducción el que leía mal el hausa («baño» se convertía en «distancia desde casa»). Al cambiar el lector, sobreviven 22 de 40. Todo instrumento de medición es, a su vez, algo que hay que medir.

La cuestión del autoalojamiento, por fin con una cifra

El último experimento de la sesión abordó una cuestión pendiente distinta: ¿cuánto cuesta realmente en calidad autoalojar el modelo de producción? Servimos el mismo modelo de las dos formas —la API alojada a precisión completa, y una copia cuantizada a 4 bits en nuestra propia GPU— y ejecutamos la evaluación idéntica, tres veces por cada rama.

La cuantización a int4 cuesta unos 6 puntos, por encima del ruido de ambas ramas. Eso convierte un debate arquitectónico difuso en una regla de decisión: no enrutar tráfico sensible a la calidad hacia una rama int4 en paridad de precio. La ruta autoalojada se vende por lo que realmente es —un requisito de soberanía que un cliente paga— con su coste de calidad medido declarado por adelantado, y FP8 sobre hardware de clase producción en cola como la prueba de paridad.

Una lección más de instrumentación: la primera ejecución de esta comparación informó de que la diferencia estaba dentro del suelo de ruido. Doce respuestas habían puntuado cero porque a la API del juez se le aplicó un límite de tasa (rate limit) a mitad de la ejecución —un fallo de infraestructura disfrazado de señal de calidad. Solo el registro de fallos por cada elemento lo hizo visible. Al reevaluar esas doce, el veredicto se invierte. Si tu evaluación no puede decirte por qué un elemento puntuó cero, tarde o temprano te mentirá.

Lo que costó, y lo que todavía no sabemos

La investigación completa —dos sondas en cuatro idiomas y tres modelos, un experimento de giro en la recuperación, una expansión de la redacción desplegada y verificada, y una decisión de autoalojamiento cuantificada— costó un puñado de euros en tokens de API y cero horas de GPU alquiladas. La pregunta de aspecto caro («¿necesitamos una GPU de 1000 €/mes?») se respondió por el precio de un café, y la respuesta fue «todavía no, y aquí está la cifra que nos dirá cuándo».

Igual de importante es lo que la evidencia todavía no respalda, porque publicar esa lista es lo que hace creíble el resto:

• El recall de redacción de 120/120 es una prueba de cableado, no una afirmación de producción —los conjuntos reservados por idioma van primero.
• Las puntuaciones de las sondas no son puntuaciones de producción; la evidencia dorada hace la generación más fácil que el bucle de recuperación en vivo.
• Las traducciones solo pasaron el control de calidad automático; la revisión por hablantes nativos está pendiente para todo lo orientado al usuario.
• La detección se mide sobre nuestro registro de evaluación, no sobre chat coloquial, alternancia de código (code-switching) o bangla romanizado.
• Cada cifra anterior es una media sobre ejecuciones repetidas con su dispersión —y las cifras de generación en hausa cargan con más incertidumbre que las demás, porque incluso dos jueces siguen siendo solo dos jueces.

El método es la conclusión. Nada de esto requirió infraestructura rara ni un presupuesto de investigación. Se basa en decisiones arquitectónicas tomadas a partir de mediciones —y en tratar cada cifra sorprendente como una pregunta sobre el instrumento antes de creérsela como un hecho sobre el mundo.

El paquete de evidencia completo detrás de este artículo —el libro de afirmaciones, los resultados en bruto y la lista de lo que cada afirmación demuestra y no demuestra— forma parte de nuestra arquitectura de referencia de agentes soberanos.

Como bonus, aplicamos ese mismo pipeline de medir-antes-que-construir sobre el propio sitio: baena.ai ya está traducido automáticamente al bangla, al swahili y al hausa —los mismos tres idiomas de los que trata este artículo— para que este texto, y el resto del sitio, sean más accesibles para quienes realmente los necesitan.