Glosarios para traductores con IA: cola asíncrona, map-reduce y un agente que se autocritica

Cuando un traductor profesional recibe un manual técnico o un contrato de decenas de páginas, el primer trabajo —el que el cliente no ve— es construir el glosario: identificar los tecnicismos, siglas y expresiones que deben traducirse exactamente igual a lo largo de todo el documento. Si "API Gateway" se traduce de tres formas distintas en tres capítulos, la traducción pierde calidad y consistencia. Hacer ese glosario a mano lleva horas. Esta herramienta lo automatiza conservando algo que las soluciones simples pierden: el contexto en el que aparece cada término.

El problema real no es el prompt, es la arquitectura

Es fácil escribir un prompt que extraiga terminología de un párrafo. Lo difícil es hacerlo con un documento pesado sin que se rompa nada: los límites de tokens del LLM, los rate limits de la API y la experiencia de usuario (nadie quiere una petición HTTP colgada dos minutos). Por eso el núcleo del proyecto es un flujo asíncrono desacoplado.

Al subir el documento, FastAPI lo almacena, crea una tarea en estado PENDING en SQLite e inyecta su ID en una cola Redis. Un consumidor recoge la tarea, la procesa por fases y va actualizando el progreso, mientras el frontend hace polling y muestra una barra real (fragmento 3 de 12…). El detalle de ingeniería que me gusta: ese consumidor no es un daemon aparte, sino una tarea asyncio dentro del propio servicio FastAPI. Un solo proceso, cero RAM residente de más, y compatible con el sistema de arranque bajo demanda del portfolio.

Map → Reduce → Reflect

La extracción no es un único prompt, sino un pipeline de tres fases:

• Map: el texto se divide en fragmentos de ~1.800 palabras (respetando los límites de párrafo) y cada fragmento se envía a Groq (Llama 3.3 70B) con un prompt especializado en localización que devuelve JSON estricto: término, contexto exacto, traducción propuesta y justificación.
• Reduce: se deduplican los términos que aparecen repetidos en páginas distintas.
• Reflect: aquí está la diferencia. Un segundo paso agéntico recibe el glosario consolidado y se autocritica: elimina falsos positivos (palabras comunes que se colaron), fusiona variantes del mismo concepto ("API Gateway" y "gateway de API") y unifica traducciones inconsistentes.

Esa fase de reflexión es lo que convierte un extractor mecánico en algo que se acerca al criterio de un lingüista jefe revisando el trabajo. No es marketing: es una segunda llamada con un rol y una tarea de control de calidad distintos.

Respetar los rate limits es parte del diseño

Procesar 25 fragmentos en paralelo es la forma rápida de comerse el rate limit y recibir 429. La herramienta usa concurrencia acotada (dos llamadas simultáneas), backoff exponencial cuando aparece un 429 y una cadena de modelos (70B → 8B) como red de seguridad. Es más lento que disparar todo a la vez, pero es lo que hace que la demo no se caiga bajo carga.

Export en formatos que el sector usa de verdad

Un glosario que no se puede importar no sirve. La herramienta exporta en CSV (universal) y en TBX — TermBase eXchange, ISO 30042 —, el estándar de intercambio de bases terminológicas que importan SDL Trados, memoQ y el resto de herramientas CAT. Generar TBX-Basic válido (con su langSet por idioma de origen y destino) es lo que separa un juguete de una herramienta que un traductor puede meter en su flujo de trabajo real.

Honestidad sobre los límites

La extracción la hace un LLM: el resultado es un punto de partida de alta calidad, no una verdad absoluta. El profesional debe revisarlo antes de usarlo en producción. Y en la demo se procesan solo los primeros fragmentos de documentos muy largos, para mantener el coste y los tiempos acotados. Pero la arquitectura —cola, fases, reflexión, export estándar— es exactamente la que usarías en producción.