Si una pipeline de localización usa generación aumentada por recuperación para inyectar términos del glosario en la ventana de contexto del modelo, tiene un problema de recall de recuperación que nunca se ha medido.
El patrón es universal: incrustar el texto de entrada, hacer una búsqueda por similitud coseno en un banco terminológico, inyectar los resultados top-k en el prompt. La salida es gramaticalmente correcta. La terminología está mal. El error es invisible, a menos que alguien hable ambos idiomas y conozca el glosario.
Primero construimos esta versión ingenua. Luego medimos el recall de recuperación contra glosarios de producción, y resultó que el sistema estaba pasando por alto la mayoría de los términos aplicables en cargas reales.
| Técnica | Localización aumentada por recuperación (RAL): enriquecimiento de contexto en tiempo de inferencia |
| Corrección principal | Descomposición en n-gramas antes del embedding, no embedding a nivel de oración |
| Modos de recuperación | 3 (omitir / precargar / búsqueda vectorial), seleccionados por solicitud según la cardinalidad del glosario |
| Calibración de umbral | Continua, semanal, contra puntuaciones de calidad por par de idiomas |
| Reducción de errores terminológicos | 17–45% en cinco proveedores de LLM (estudio controlado, más de 42,000 evaluaciones de calidad) |
| Puntuación | Evaluación independiente entre modelos, asíncrona, por solicitud |
¿Por qué los embeddings a nivel de oración pasan por alto términos del glosario?#
Un término de glosario tiene de 1 a 3 palabras. "motor de localización". "Token de acceso". "Pipeline de despliegue".
El texto de entrada es un objeto JSON con valores que van desde dos palabras (la etiqueta de un botón) hasta doscientas palabras (una descripción de producto). Cuando se incrusta la cadena completa "Configure the localization engine for production deployment", el vector resultante captura el significado semántico de la oración: algo sobre configuración y sistemas de producción. La frase relevante para el glosario, "localization engine", se diluye dentro de la representación a nivel de oración.
La similitud coseno entre ese vector de oración y la entrada de glosario "localization engine" cae en el rango de 0.6–0.7. Por debajo del umbral de recuperación. El término existe en la entrada. El sistema de recuperación no lo encuentra.
El problema es de granularidad: representaciones a nivel de oración consultando objetivos a nivel de frase. El modelo de embedding representa fielmente el significado de la oración como un todo. La terminología que la compone no ocupa una región independiente en el espacio vectorial.
Lo descubrimos por las malas. En cargas de producción —objetos JSON anidados con 20–50 claves y valores de distinta longitud— la recuperación a nivel de oración estaba pasando por alto la mayoría de los términos aplicables del glosario. La solicitud de localización se completaba sin problema. La salida se leía con fluidez. Pero "localization engine" se estaba convirtiendo en "translation tool": gramaticalmente válido, semánticamente cercano, terminológicamente incorrecto. Y la pipeline reportaba éxito.
¿Cómo corrige la descomposición en n-gramas la recuperación del glosario?#
La solución resultó ser descomponer la entrada en unidades a nivel de frase antes del embedding. Cada valor de cadena se convierte en un conjunto de ventanas de n-gramas superpuestas:
Input: "Configure the localization engine for production"
1-grams: [configure, the, localization, engine, for, production]
2-grams: [configure the, the localization, localization engine,
engine for, for production]
3-grams: [configure the localization, the localization engine,
localization engine for, engine for production]Cada n-grama se convierte en una consulta de recuperación independiente. "Localization engine" consulta el glosario como una frase independiente y encuentra su coincidencia con alta similitud.
La pipeline de descomposición:
- Extraer de forma recursiva todos los valores de cadena de estructuras JSON anidadas
- Dividir en oraciones, eliminar HTML y anotaciones de marcado
- Normalizar espacios en blanco, quitar comillas envolventes y desescapar formato
- Generar frases superpuestas de 1, 2 y 3 gramos a partir de cada oración
Un párrafo de 50 palabras genera aproximadamente 150 n-gramas. Una carga típica de API con 20 claves genera entre 1,000 y 3,000 frases consultables. Cada frase se incrusta de forma independiente, y cada embedding ejecuta una consulta de vecino más cercano contra el índice vectorial del glosario.
Medimos la diferencia en las mismas cargas de producción que expusieron el problema original. Ahora los términos del glosario coinciden sin importar el contexto de la oración que los rodea: un término de 2 palabras enterrado en una descripción de producto de 200 palabras se recupera con el mismo recall que una etiqueta independiente.
¿Cómo funciona la recuperación adaptativa para distintos tamaños de glosario?#
La descomposición en n-gramas y el embedding por lotes son el enfoque correcto para glosarios grandes. Para los pequeños, resultó ser un desperdicio computacional.
Un motor de localización configurado con 8 términos de glosario se resuelve más rápido con inyección directa: una consulta a la base de datos, determinística, de menos de un milisegundo. Un motor de localización con 2,000 términos requiere búsqueda vectorial: los límites de la ventana de contexto y la dilución de relevancia hacen imposible la inyección completa.
Hay tres modos de recuperación por solicitud, seleccionados según la cardinalidad del glosario para el par de idiomas:
| Modo | Condición | Comportamiento |
|---|---|---|
| Omitir | Cero elementos coincidentes | Sin embedding, sin búsqueda, sin inyección |
| Precargar | Por debajo del umbral de cardinalidad | Una sola consulta a la base de datos carga todos los elementos coincidentes; inyección directa |
| Buscar | Por encima del umbral de cardinalidad | Descomposición completa en n-gramas → embedding por lotes → búsqueda vectorial de vecinos más cercanos |
El umbral de cardinalidad que separa la precarga de la búsqueda se deriva del perfilado de latencia sobre tráfico de producción y se ajusta a medida que cambian el rendimiento del modelo de embedding, la distribución de tamaños del glosario y las características de la infraestructura. El valor inicial que lanzamos duró aproximadamente tres semanas antes de que la telemetría indicara que debía ajustarse. Desde entonces se ha ajustado varias veces: descubrimos que el umbral óptimo se desplaza a medida que los motores acumulan términos de glosario y las características de los modelos de embedding evolucionan entre actualizaciones de los proveedores.
La latencia de recuperación escala con la complejidad del glosario, no con el tamaño de la carga. Un motor de localización con 10 términos se resuelve en milisegundos de un solo dígito sin importar la longitud de la entrada. Un motor de localización con 500 términos usa toda la pipeline de descomposición, pero se resuelve dentro del presupuesto de latencia de un paso duradero de flujo de trabajo en segundo plano.
¿Cómo se calibra el umbral de similitud para la recuperación del glosario?#
Cada embedding de n-grama consulta el índice vectorial en busca de vecinos más cercanos por encima de un umbral de similitud. Las coincidencias por debajo del umbral se descartan como ruido.
El umbral determina al mismo tiempo la precisión y el recall de la recuperación:
- Demasiado permisivo: términos no relacionados se filtran al prompt. El modelo ve contexto de glosario que no aplica a la entrada y, a veces, lo sigue, produciendo una salida que usa terminología de un dominio no relacionado.
- Demasiado estricto: quedan fuera variantes legítimas de redacción y formas morfológicas. "Deploying" no logra coincidir con la entrada de glosario para "deploy". El recall cae.
Descubrimos que el umbral correcto varía según el par de idiomas. La recuperación de inglés→alemán tiene distribuciones de similitud distintas a las de inglés→japonés, donde la distancia morfológica entre los n-gramas de origen y las entradas del glosario difiere estructuralmente. Un único umbral global estaba produciendo un recall inconsistente en los pares de idiomas que medimos.
Ahora el umbral se calibra de forma continua contra puntuaciones de calidad por par de idiomas provenientes de una pipeline de puntuación independiente. Cuando el sistema de puntuación detecta un aumento en el incumplimiento del glosario (términos presentes en la entrada pero ausentes en la salida), el recall de recuperación se ha degradado y el umbral se flexibiliza. Cuando la puntuación detecta que el modelo aplica terminología irrelevante, la inyección de falsos positivos ha aumentado y el umbral se endurece.
Esta calibración se ejecuta semanalmente. Tiene que ser así: el comportamiento de los modelos de embedding cambia entre actualizaciones de los proveedores, las distribuciones del glosario cambian a medida que los equipos agregan términos y las características del texto de entrada evolucionan a medida que los productos crecen.
¿Cómo se inyectan los términos recuperados del glosario en el modelo de localización?#
Los elementos de glosario recuperados se dividen en dos clases de restricciones, con distinto comportamiento de aplicación en el prompt del sistema del modelo:
Términos no traducibles – cadenas en el idioma de origen que deben aparecer sin cambios en la salida de destino. Nombres de marca, identificadores técnicos, nombres de producto. El modelo los conserva literalmente.
Traducciones personalizadas – asignaciones origen→destino que reemplazan el propio criterio del modelo. "Localization engine" debe convertirse en "motor de localización". El modelo trata estas asignaciones como restricciones léxicas no negociables.
Ambas clases se inyectan en el prompt del sistema como reglas con precedencia explícita sobre el comportamiento predeterminado del modelo. La jerarquía del prompt impone el cumplimiento del glosario por encima de las preferencias lingüísticas del modelo.
La distinción importa al momento de puntuar: el modelo de puntuación independiente verifica si los no traducibles se conservaron sin cambios y si las traducciones personalizadas se aplicaron exactamente. Dos criterios de verificación para dos tipos de restricción. Descubrimos desde el principio que fusionarlos en una sola categoría de "glosario" hacía que la puntuación fuera poco confiable: un término conservado literalmente cuando debía traducirse (o viceversa) obtendría una puntuación correcta bajo una verificación unificada.
¿Cómo validas la calidad de la localización en idiomas que no hablas?#
Toda la pipeline de recuperación y localización puede ejecutarse sin errores y producir una salida terminológicamente incorrecta. Un término del glosario omitido no produce ninguna señal de error. Una traducción personalizada mal aplicada devuelve un 200. La pipeline tiene éxito. La salida está mal.
Esta es la brecha de observabilidad en localización que la mayoría de los equipos nunca cierra.
La recuperación está acoplada con una puntuación independiente y asíncrona. Después de que se completa una solicitud de localización, modelos de puntuación separados evalúan la salida contra la configuración del motor de localización:
- Cumplimiento del glosario – ¿se conservaron los términos no traducibles? ¿Se aplicaron exactamente las traducciones personalizadas?
- Cumplimiento de instrucciones – ¿se siguieron las reglas específicas del idioma?
- Criterios de puntuación personalizados – dimensiones de calidad por motor definidas por el equipo de localización
Los modelos de puntuación se ejecutan sobre una infraestructura distinta a la del modelo de localización. Funcionan de forma asíncrona en flujos de trabajo en segundo plano, y se activan después de cada solicitud que pasa por un motor de localización con la puntuación habilitada. Un modelo localiza; otro puntúa. La evaluación entre modelos elimina el problema de la autoevaluación.
Los resultados de la puntuación retroalimentan la calibración de la recuperación:
- La puntuación detecta una tendencia al alza en el incumplimiento del glosario para un par de idiomas
- La investigación revela que la exhaustividad de la recuperación ha caído: el umbral se desalineó con la distribución actual del glosario
- Se ajusta el umbral; la exhaustividad se recupera; las puntuaciones de cumplimiento se estabilizan
Ese ciclo es lo que hace que el sistema se autocorrija. La puntuación aporta la observabilidad que la recuperación, por sí sola, no tiene. Sin ella, los equipos entregan contenido localizado en idiomas que no hablan, sin ninguna señal de si el glosario que crearon realmente se está aplicando.
¿Por qué la exhaustividad de la recuperación se acumula con el tiempo?#
Cada solicitud de localización que aplica correctamente los términos del glosario refuerza la consistencia terminológica en todo el producto. Cada solicitud que omite un término introduce desvío: una superficie dice "motor de localización", otra dice "herramienta de localización" y una tercera dice "módulo de localización". En 30 idiomas y con lanzamientos semanales, estas inconsistencias se acumulan.
La diferencia entre una exhaustividad de recuperación alta y una baja no es una variación de calidad por solicitud. Es un mecanismo de consistencia acumulativa. Una exhaustividad alta significa que el glosario se aplica de forma uniforme en cada superficie, cada idioma y cada lanzamiento. Una exhaustividad baja significa que el glosario solo se activa de vez en cuando: algo estructuralmente equivalente a no tener glosario, solo que tarda más en degradarse.
Qué significa esto para la ingeniería de localización#
El problema de recuperación que se describe aquí no es propio de una sola implementación. Es estructural en cualquier sistema que intente hacer localización con reconocimiento de glosario mediante búsqueda basada en embeddings. El desajuste de granularidad entre las representaciones de entrada a nivel de oración y los objetivos del glosario a nivel de frase existe independientemente del modelo de embeddings, la base de datos vectorial o el LLM que genere la salida.
Los equipos que desarrollan automatización de localización enfrentan una elección: aceptar la recuperación a nivel de oración con su brecha invisible de exhaustividad, o construir la infraestructura de descomposición y calibración que la cierre. El segundo camino requiere tres sistemas: descomposición en n-gramas, recuperación adaptativa y un ciclo de puntuación que retroalimente la gestión de umbrales. Cada sistema tiene su propia cadencia operativa: la lógica de descomposición evoluciona a medida que cambian los formatos de entrada, los umbrales de recuperación se ajustan conforme crecen los glosarios y los criterios de puntuación se refinan a medida que los equipos de localización aprenden qué dimensiones importan para su contenido.
La localización aumentada por recuperación con calidad de producción es una práctica de ingeniería continua: un sistema que se construye, se instrumenta, se observa y se ajusta de forma permanente. La disciplina de ingeniería de localización que está surgiendo alrededor de este trabajo refleja una realidad operativa clara: la infraestructura de localización requiere la misma atención continua que los servicios backend, los pipelines de CI/CD y los stacks de observabilidad.
Próximos pasos#
Preguntas frecuentes#
¿Qué es la localización aumentada por recuperación (RAL)? La localización aumentada por recuperación enriquece cada solicitud de localización con términos del glosario, reglas de voz de marca e instrucciones específicas del idioma en tiempo de inferencia: el mismo patrón de recuperar e inyectar detrás de RAG, aplicado a la localización. En un estudio controlado con cinco proveedores de LLM y cinco idiomas europeos, RAL redujo los errores terminológicos entre un 17% y un 45% frente a los mismos modelos sin enriquecimiento de contexto.
¿Por qué el embedding a nivel de oración omite términos del glosario? Los términos del glosario suelen tener entre 1 y 3 palabras. Cuando se incrustan como parte de una oración completa, se diluyen dentro del vector semántico de la oración. El embedding capta el significado de la oración en su conjunto: "motor de localización" dentro de "Configura el motor de localización para producción" no se registra de forma independiente. La similitud coseno entre el vector de la oración y la entrada del glosario cae por debajo del umbral de recuperación.
¿Cómo mejora la descomposición en n-gramas la exhaustividad de la recuperación? En lugar de incrustar cadenas de entrada completas, el sistema descompone el texto en frases superpuestas de 1 grama, 2 gramas y 3 gramas antes de incrustarlo. Cada frase se convierte en una consulta de recuperación independiente. Un término de glosario de 2 palabras oculto dentro de un párrafo de 200 palabras alcanza la misma exhaustividad que una etiqueta independiente, porque se consulta por separado de su contexto circundante.
¿Cuántos modos de recuperación usa el sistema? Tres. Omitir (cero elementos del glosario: no se necesita recuperación), precarga (por debajo de un umbral de cardinalidad: se cargan todos los elementos directamente) y búsqueda vectorial (por encima del umbral: descomposición completa en n-gramas e embeddings). El modo se selecciona para cada solicitud según la cardinalidad del glosario para el par de idiomas específico.
¿Cómo se mantiene el umbral de similitud? El umbral se calibra semanalmente con base en las puntuaciones de calidad por par de idiomas provenientes de un pipeline de puntuación independiente. Cuando el incumplimiento del glosario muestra una tendencia al alza, el umbral se flexibiliza para mejorar la exhaustividad. Cuando términos irrelevantes se filtran en los prompts, el umbral se vuelve más estricto. Distintos pares de idiomas requieren distintos umbrales debido a las variaciones en la distancia morfológica.
¿Cómo funciona la puntuación entre modelos para la calidad de localización? Una vez completada cada solicitud de localización, un modelo independiente —ejecutándose sobre una infraestructura distinta— evalúa si los términos del glosario se aplicaron correctamente, si se siguieron las instrucciones específicas del idioma y si se cumplieron los criterios de calidad personalizados. Un modelo localiza; otro puntúa. Esto elimina el sesgo de autoevaluación y aporta la observabilidad que la recuperación, por sí sola, no ofrece.
¿Qué pasa cuando la exhaustividad de recuperación del glosario es baja? Una exhaustividad de recuperación baja significa que el glosario se activa de forma inconsistente: una superficie recibe el término correcto y otra no. En más de 30 idiomas y con lanzamientos semanales, estas inconsistencias se acumulan hasta convertirse en desvío terminológico. El glosario existe, pero no se aplica de forma consistente. Con el paso de los meses, esto es estructuralmente equivalente a no tener glosario.
¿Qué es la brecha de observabilidad de la localización? Un pipeline de localización puede ejecutarse sin errores y aun así producir una salida terminológicamente incorrecta. Los términos del glosario omitidos no generan ninguna señal de error: la API devuelve 200 y la traducción es gramaticalmente válida. La brecha de observabilidad es el espacio entre "el pipeline se ejecutó correctamente" y "la terminología es correcta". La puntuación independiente cierra esta brecha al medir el cumplimiento del glosario en cada solicitud.
