DocumentaciónPreciosInvestigaciónEnterpriseEmpleo
Estamos contratando
Iniciar sesiónRegistrarseReservar una demo
Todas las publicaciones

Todas las canalizaciones de localización basadas en RAG tienen el mismo punto ciego

Si una canalización de localización utiliza generación aumentada por recuperación para inyectar términos de glosario en la ventana de contexto del modelo, tiene un problema de exhaustividad de recuperación que nunca se ha medido.

El patrón es universal: se vectoriza el texto de entrada, se busca por similitud de coseno en un banco terminológico y se inyectan 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.

Nosotros también construimos primero esta versión ingenua. Luego medimos la exhaustividad de recuperación frente a 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écnicaLocalización aumentada por recuperación (RAL): enriquecimiento del contexto en tiempo de inferencia
Solución principalDescomposición en n-gramas antes de generar embeddings, no embeddings a nivel de oración
Modos de recuperación3 (omitir / precargar / búsqueda vectorial), seleccionados por solicitud según la cardinalidad del glosario
Calibración de umbralesContinua, semanal, frente a puntuaciones de calidad por par de idiomas
Reducción de errores terminológicos17–45 % en cinco proveedores de LLM (estudio controlado, más de 42.000 evaluaciones de calidad)
PuntuaciónEvaluación independiente entre modelos, asíncrona, por solicitud

¿Por qué los embeddings de oración no detectan los términos del glosario?#

Un término de glosario tiene entre 1 y 3 palabras. "Localization engine." "Access token." "Deployment pipeline."

El texto de entrada es un objeto JSON con valores que van desde dos palabras (la etiqueta de un botón) hasta doscientas palabras (la descripción de un producto). Cuando se vectoriza la cadena completa "Configure the localization engine for production deployment", el vector resultante captura el significado semántico de la oración: algo relacionado con la configuración y los 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 de 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 está en la entrada. El sistema de recuperación no lo detecta.

El problema es de granularidad: representaciones a nivel de oración consultando objetivos a nivel de frase. El modelo de embeddings representa fielmente el significado de la oración en su conjunto. La terminología que la compone no ocupa ninguna región independiente en el espacio vectorial.

Lo descubrimos por las malas. En cargas de producción —objetos JSON anidados con entre 20 y 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 de glosario aplicables. La solicitud de localización se completaba sin problemas. La salida sonaba fluida. Pero "localization engine" se estaba convirtiendo en "translation tool": gramaticalmente válido, semánticamente cercano, terminológicamente incorrecto. Y la canalización informaba de éxito.

¿Cómo corrige la descomposición en n-gramas la recuperación de términos del glosario?#

La solución resultó ser descomponer la entrada en unidades a nivel de frase antes de generar los embeddings. Cada valor de texto se convierte en un conjunto de ventanas n-grama superpuestas:

text
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 autónoma y encuentra su coincidencia con una similitud alta.

La canalización de descomposición:

  1. Extraer de forma recursiva todos los valores de texto de estructuras JSON anidadas
  2. Dividir en oraciones, eliminar HTML y anotaciones de marcado
  3. Normalizar espacios en blanco, eliminar comillas envolventes y desescapar el formato
  4. Generar frases superpuestas de 1, 2 y 3 gramas 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 produce entre 1.000 y 3.000 frases consultables. Cada frase se vectoriza 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 destaparon el problema original. Ahora los términos del glosario se recuperan independientemente del 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 la misma exhaustividad que una etiqueta independiente.

¿Cómo funciona la recuperación adaptativa para glosarios de distinto tamaño?#

La descomposición en n-gramas y la vectorización 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, determinista, por debajo del 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 pérdida de relevancia hacen imposible la inyección completa.

Hay tres modos de recuperación por solicitud, seleccionados en función de la cardinalidad del glosario para el par de idiomas:

ModoCondiciónComportamiento
OmitirCero elementos coincidentesSin embeddings, sin búsqueda, sin inyección
PrecargarPor debajo del umbral de cardinalidadUna sola consulta a la base de datos carga todos los elementos coincidentes; inyección directa
BuscarPor encima del umbral de cardinalidadDescomposición completa en n-gramas → vectorización 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 embeddings, 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 cambiar. Desde entonces se ha ajustado varias veces: descubrimos que el umbral óptimo deriva a medida que los motores acumulan términos de glosario y evolucionan las características del modelo de embeddings entre actualizaciones del proveedor.

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 unos pocos milisegundos, independientemente de la longitud de la entrada. Un motor de localización con 500 términos utiliza toda la canalización de descomposición, pero sigue resolviéndose 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 simultáneamente la precisión y la exhaustividad de la recuperación:

  • Demasiado permisivo: se cuelan en el prompt términos no relacionados. El modelo ve contexto de glosario que no se aplica a la entrada y, en ocasiones, lo sigue, produciendo una salida que usa terminología de un dominio ajeno.
  • Demasiado estricto: se excluyen variantes de redacción legítimas y formas morfológicas. "Deploying" no coincide con la entrada de glosario "deploy". La exhaustividad cae.

Descubrimos que el umbral adecuado 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 una exhaustividad inconsistente entre los pares de idiomas que medimos.

Ahora el umbral se calibra de forma continua frente a puntuaciones de calidad por par de idiomas procedentes de una canalización de puntuación independiente. Cuando el sistema de puntuación detecta un aumento del incumplimiento del glosario (términos presentes en la entrada pero ausentes en la salida), la exhaustividad de recuperación se ha degradado y el umbral se relaja. Cuando la puntuación detecta que el modelo aplica terminología irrelevante, ha aumentado la inyección de falsos positivos y el umbral se endurece.

Esta calibración se ejecuta semanalmente. Y tiene que ser así: el comportamiento del modelo de embeddings cambia entre actualizaciones del proveedor, la distribución del glosario evoluciona a medida que los equipos añaden términos y las características del texto de entrada cambian a medida que crecen los productos.

¿Cómo se inyectan en el modelo de localización los términos recuperados del glosario?#

Los elementos recuperados del glosario se dividen en dos clases de restricciones con distinto comportamiento de aplicación en el prompt de 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 – correspondencias origen→destino que prevalecen sobre el propio criterio del modelo. "Localization engine" debe convertirse en "moteur de localisation". El modelo las trata como restricciones léxicas no negociables.

Ambas clases se inyectan en el prompt de 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 en el momento de la puntuación: el modelo de puntuación independiente comprueba si los términos 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 pronto que fusionarlos en una sola categoría de "glosario" hacía que la puntuación fuera poco fiable: un término conservado literalmente cuando debía traducirse (o viceversa) puntuaría como correcto con una comprobación unificada.

¿Cómo validas la calidad de la localización en idiomas que no hablas?#

Toda la canalización de recuperación y localización puede ejecutarse sin errores y producir una salida terminológicamente incorrecta. Un término de glosario omitido no genera ninguna señal de error. Una traducción personalizada mal aplicada devuelve un 200. La canalización tiene éxito. La salida está mal.

Esta es la brecha de observabilidad de la localización que la mayoría de los equipos nunca llega a cerrar.

La recuperación está acoplada a una puntuación asíncrona independiente. Después de que se complete una solicitud de localización, modelos de puntuación separados evalúan la salida frente a 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 de la del modelo de localización. Funcionan de forma asíncrona en flujos de trabajo en segundo plano, que se activan después de cada solicitud que pasa por un motor de localización con la puntuación habilitada. Un modelo localiza; otro, distinto, 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:

  1. La puntuación detecta una tendencia al alza en el incumplimiento del glosario para un par de idiomas
  2. La investigación revela que el recall de recuperación ha caído: el umbral se ha desviado con respecto a la distribución actual del glosario
  3. Se ajusta el umbral; el recall se recupera; las puntuaciones de adherencia se estabilizan

Este bucle es lo que hace que el sistema se autocorrija. La puntuación aporta la observabilidad de la que carece la recuperación por sí sola. Sin ella, los equipos lanzan contenido localizado en idiomas que no hablan, sin ninguna señal de si el glosario que han creado se está aplicando realmente.

¿Por qué el recall de recuperación se acumula con el tiempo?#

Cada solicitud de localización que aplica correctamente los términos del glosario refuerza la coherencia terminológica en todo el producto. Cada solicitud que omite un término introduce deriva: 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 incoherencias se acumulan.

La diferencia entre un recall de recuperación alto y uno bajo no es una variación de calidad por solicitud. Es un mecanismo de coherencia acumulativa. Un recall alto significa que el glosario se aplica de forma uniforme en cada superficie, cada idioma y cada lanzamiento. Un recall bajo significa que el glosario se activa solo a veces, 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 descrito aquí no es exclusivo de una implementación concreta. Es estructural en cualquier sistema que intente hacer localización consciente del 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, de la base de datos vectorial o del LLM que genere la salida.

Los equipos que desarrollan automatización de la localización se enfrentan a una elección: aceptar la recuperación a nivel de oración con su brecha invisible de recall, o construir la infraestructura de descomposición y calibración que la cierre. La segunda vía requiere tres sistemas: descomposición en n-gramas, recuperación adaptativa y un bucle de puntuación que retroalimente la gestión de umbrales. Cada sistema tiene su propio ritmo operativo: la lógica de descomposición evoluciona a medida que cambian los formatos de entrada, los umbrales de recuperación se desplazan a medida que crecen los glosarios y los criterios de puntuación se afinan a medida que los equipos de localización aprenden qué dimensiones importan para su contenido.

La localización aumentada con 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 constante. La disciplina de ingeniería de localización que está surgiendo en torno a este trabajo refleja la realidad operativa: la infraestructura de localización requiere la misma atención continua que exigen los servicios backend, las canalizaciones de CI/CD y las pilas de observabilidad.


Siguientes pasos#

Investigación sobre RAL
Estudio controlado: más de 42.000 evaluaciones de calidad, reducción del 17–45 % de los errores terminológicos
Motores de localización
Configura glosario, voz de marca, cadenas de modelos y evaluadores de IA
La API de localización
La API asíncrona que ejecuta este pipeline detrás de un único POST

Preguntas frecuentes#

¿Qué es la localización aumentada con recuperación (RAL)? La localización aumentada con 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 que hay 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 % en comparación con los mismos modelos sin enriquecimiento de contexto.

¿Por qué el embedding a nivel de oración no detecta los 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 en el 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 del 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 el recall de 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 incrustarlas. Cada frase se convierte en una consulta de recuperación independiente. Un término de glosario de 2 palabras enterrado en un párrafo de 200 palabras obtiene el mismo recall que una etiqueta independiente, porque se consulta de forma independiente de su contexto circundante.

¿Cuántos modos de recuperación utiliza el sistema? Tres. Omitir (cero elementos de glosario; no hace falta recuperación), precarga (por debajo de un umbral de cardinalidad; se cargan directamente todos los elementos) y búsqueda vectorial (por encima del umbral; descomposición completa en n-gramas e embedding). El modo se selecciona para cada solicitud en función de la cardinalidad del glosario para el par de idiomas específico.

¿Cómo se mantiene el umbral de similitud? El umbral se calibra semanalmente frente a puntuaciones de calidad por par de idiomas procedentes de un pipeline de puntuación independiente. Cuando el incumplimiento del glosario muestra una tendencia al alza, el umbral se relaja para mejorar el recall. Cuando se cuelan términos irrelevantes en los prompts, el umbral se endurece. Los distintos pares de idiomas requieren umbrales diferentes debido a las distintas distancias morfológicas.

¿Cómo funciona la puntuación entre modelos para la calidad de la localización? Después de que se complete cada solicitud de localización, un modelo aparte, que se ejecuta sobre una infraestructura distinta, evalúa si los términos del glosario se han aplicado correctamente, si se han seguido las instrucciones específicas del idioma y si se han cumplido los criterios de calidad personalizados. Un modelo localiza; otro, distinto, puntúa. Esto elimina el sesgo de autoevaluación y aporta la observabilidad de la que carece la recuperación por sí sola.

¿Qué ocurre cuando el recall de recuperación del glosario es bajo? Un recall de recuperación bajo significa que el glosario se activa de forma incoherente: una superficie obtiene el término correcto y otra no. En más de 30 idiomas y con lanzamientos semanales, estas incoherencias se acumulan y se convierten en deriva terminológica. El glosario existe, pero no se aplica. 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 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 ha ejecutado correctamente" y "la terminología es correcta". Una puntuación independiente cierra esta brecha al medir la adherencia al glosario en cada solicitud.

Plataforma

API de localizaciónAPI de trabajos asíncronosMotores de localizaciónDetección de idiomaLingo.dev Platform MCPPrecios

Herramientas para desarrolladores

Lingo React MCPLingo CLILingo GitHub ActionLingo React Compiler
Alpha

Recursos

DocumentaciónLabsGuíasRegistro de cambiosIdiomasModelos LLM

Empresa

BlogInvestigaciónReservar una demoClientesEmpleo
Estamos contratando
humans.txt

Comunidad

GitHubDiscordTwitterLinkedIn
Con sede en San Francisco + por todo el mundo
SOC 2 Type II·CCPA·GDPR
Con el respaldo de Y Combinator
Combinator
& Initialized Capital
Initialized Capital
& nuestros clientes
Privacidad·Términos·Cookies·security.txt

© 2026 Lingo.dev (Replexica, Inc).

Todos los sistemas funcionan con normalidad
Iniciar sesiónRegistrarseReservar una demo
Veronica PrilutskayaVeronica Prilutskaya, CPO y cofundador·Publicado hace alrededor de 1 mes·13 min de lectura