Cómo construir Google Translate: antes de los LLM y con la IA moderna

Al July 3, 2026, la historia de ingeniería interesante no es que «los LLM reemplazaron la traducción». Es que la traducción fue uno de los primeros productos de IA a gran escala, y cada generación resolvió un cuello de botella diferente:

1. Las reglas y los léxicos no podían escalar a cientos de idiomas.
2. La traducción automática estadística (SMT) escaló gracias a los datos, pero sonaba entrecortada y fallaba al reordenar palabras muy distantes.
3. La traducción automática neuronal (NMT) mejoró la fluidez sin recurrir a LLM de chat de frontera: primero con RNN de encoder-decoder y luego con Transformers.
4. Los modelos masivamente multilingües y la traducción automática zero-shot ampliaron la cobertura de idiomas cuando escaseaban los datos paralelos.
5. Los Translation LLM ahora manejan contextos largos, tono y traducciones difíciles de documentos, mientras que la NMT especializada todavía suele ganar en latencia, throughput y control de terminología, según las propias recomendaciones de producto de Google (Google Cloud, May 9, 2024).

TL;DR

• Google Translate se lanzó el April 28, 2006 con traducción automática estadística: tablas de frases y modelos de lenguaje entrenados con miles de millones de palabras de texto paralelo, no con reglas gramaticales escritas a mano (Google Research, 2006).
• En November 2016, Google implementó Neural Machine Translation (GNMT): modelos profundos de encoder-decoder con LSTM y atención, tokenización WordPiece e inferencia en TPU. Google informó que la actualización había mejorado la traducción más en un solo salto que en los diez años anteriores juntos (blog de Google, 2016).
• GNMT no era un LLM de chat. Era un modelo seq2seq diseñado específicamente para traducción. El artículo de Wu et al. reporta ~60% menos errores de traducción frente al sistema de producción basado en frases de Google, en pruebas humanas de comparación directa (arXiv:1609.08144).
• A partir de 2022, Google agregó idiomas con pocos recursos mediante traducción automática zero-shot y después amplió la cobertura usando PaLM 2 (May 2022, June 2024).
• Hoy, en producción, Google Cloud ofrece tanto NMT tradicional como un Translation LLM (TLLM) ajustado para mejorar la calidad de traducción de textos extensos (documentación de Google Cloud).
• Si estás construyendo una aplicación de traducción en 2026, usa un router: NMT o modelos abiertos destilados para textos cortos de alto volumen y baja latencia; Translation LLM o un LLM general con restricciones de glosario para documentos, tono y contextos complejos; y controles de evaluación antes del lanzamiento.

Este artículo recorre cómo se construyó Google Translate antes de los LLM de frontera modernos, qué cambió cuando llegaron los sistemas neuronales y cómo puedes construir hoy una aplicación similar con un stack híbrido, en lugar de apostarlo todo a un solo tipo de modelo.

Qué aprenderás aquí

• Cómo funcionaba Google Translate antes de los LLM de frontera: reglas, SMT, traducción automática basada en frases, idiomas pivote y extracción de datos.
• Qué cambió GNMT en 2016 y por qué fue importante para el despliegue en producción.
• Cómo la traducción automática multilingüe zero-shot y la posterior expansión asistida por LLM resolvieron problemas de cobertura que SMT no podía resolver.
• Una arquitectura de referencia para una aplicación de traducción moderna con enrutamiento, glosarios, caché y evaluación.
• Una implementación híbrida mínima que puedes adaptar.
• Una tabla de decisión para elegir entre NMT, modelos multilingües abiertos o LLM.

El viejo problema: traducir antes de «solo hazle un prompt a un LLM»

Como requisito de producto, la traducción automática parece engañosamente simple:

Input text in language A -> Output text in language B

Las dificultades están en todo lo que rodea esa flecha:

Google Translate es un caso de estudio útil porque enfrentó todos estos problemas a escala de un producto de consumo.

Era 1: reglas, SYSTRAN y el giro hacia los datos (2004–2006)

Antes del lanzamiento estadístico de Google en 2006, se ha reportado que las primeras versiones de Google Translate dependían de motores comerciales basados en reglas e híbridos, como SYSTRAN: un patrón común en los productos de traducción automática anteriores a los métodos estadísticos (resumen del lanzamiento en Wikipedia). Ese enfoque depende en gran medida de que los lingüistas codifiquen gramáticas, diccionarios y reglas de transferencia. Funciona en dominios acotados, pero no escala fácilmente a decenas de pares de idiomas ni a textos web que evolucionan rápidamente.

El April 28, 2006, Google lanzó su propio servicio de traducción automática estadística para árabe↔inglés (blog de Google Research). El equipo de Franz Och describió la idea central de forma sencilla:

Alimentamos la computadora con miles de millones de palabras de texto, tanto texto monolingüe en el idioma de destino como texto alineado que contiene ejemplos de traducciones humanas entre los idiomas. Luego aplicamos técnicas de aprendizaje estadístico para construir un modelo de traducción.

Ese es el cambio de filosofía: aprender de ejemplos, no de libros de gramática mantenidos manualmente.

Qué hacía realmente SMT

La traducción automática estadística basada en frases (PBMT), el motor principal de las primeras versiones de Google Translate, funcionaba aproximadamente así:

Source sentence
   |
   v
Segmentation into phrases
   |
   v
Phrase table lookup (source phrase -> target phrase candidates)
   |
   v
Language model scoring (which target string is most fluent?)
   |
   v
Decoder search (find best phrase sequence)
   |
   v
Target sentence

Detalles importantes de producción según los registros históricos:

• Los corpus paralelos, como los documentos de las Naciones Unidas y del Parlamento Europeo, se mencionan ampliamente como fuentes de entrenamiento iniciales de Google Translate (resumen del lanzamiento en Wikipedia). Toma ese detalle como contexto secundario, no como una declaración primaria de Google.
• Muchos pares de idiomas usaban el inglés como pivote en lugar de traducirse directamente.
• El sistema funcionaba bien con textos similares a noticias y peor con lenguaje literario, poético o muy idiomático: la propia publicación de Google de 2006 advertía contra la traducción de poesía.

SMT fue un triunfo de la ingeniería de datos y la búsqueda probabilística, no del chat generativo.

Era 2: traducción automática estadística a escala (2006–2016)

Durante aproximadamente una década, Google Translate mejoró al agregar idiomas, extraer más texto paralelo, ajustar las tablas de frases y perfeccionar la decodificación, todavía sin generación neuronal seq2seq en producción.

Componentes centrales de SMT

Si hubieras construido software «del nivel de Google Translate» en 2010, tu stack se habría visto así:

                 +----------------------+
                 | Web / doc ingestion  |
                 +----------+-----------+
                            |
                            v
                 +----------------------+
                 | Sentence alignment   |
                 | + tokenization       |
                 +----------+-----------+
                            |
              +-------------+-------------+
              |                           |
              v                           v
   +--------------------+      +--------------------+
   | Phrase extraction  |      | Monolingual corpus |
   | from parallel text |      | for target LM      |
   +---------+----------+      +---------+----------+
             |                           |
             v                           v
   +--------------------+      +--------------------+
   | Phrase table       |      | n-gram language    |
   | P(target|source)   |      | model P(target)    |
   +---------+----------+      +---------+----------+
             \                           /
              \                         /
               v                       v
            +-----------------------------+
            | Decoder (beam / stack search)|
            +-----------------------------+
                            |
                            v
                   Translated output

En qué acertó SMT

• Costos y latencia predecibles en comparación con los modelos autorregresivos grandes.
• Buen desempeño cuando abundaban los datos paralelos y los dominios coincidían con los corpus de entrenamiento (noticias, actas parlamentarias, documentación técnica).
• La consistencia terminológica podía controlarse parcialmente mediante restricciones de frases.

Dónde fallaba SMT

• Las traducciones a menudo parecían correctas a nivel local, pero forzadas en conjunto.
• El reordenamiento a larga distancia y el contexto a nivel de documento eran difíciles de manejar.
• Los idiomas con pocos recursos seguían desatendidos porque las tablas de frases necesitan ejemplos alineados.
• Las entidades con nombre poco frecuentes y la morfología eran fuentes recurrentes de errores: precisamente los problemas que abordarían después los sistemas neuronales.

Para November 2016, Google Translate admitía 103 idiomas en total, y la traducción automática estadística basada en frases seguía impulsando la mayoría de los pares mientras GNMT se implementaba primero en ocho pares de idiomas de alto tráfico (blog de Google, 2016). El siguiente salto vendría de ampliar ese stack neuronal.

Era 3: traducción automática neuronal sin LLM de frontera (2016–2022)

El November 15, 2016, Google anunció Neural Machine Translation en producción para ocho pares de idiomas de alto tráfico (blog de Google). La promesa del producto era específica:

Neural Machine Translation traduce oraciones completas a la vez, en lugar de hacerlo solo fragmento por fragmento.

Esa era la diferencia visible para el usuario. Bajo el capó, el sistema GNMT de Google (Wu et al., September 2016) era un modelo seq2seq diseñado para una tarea específica, no un LLM de chat de propósito general.

Arquitectura de GNMT (NMT en producción, antes de los LLM)

Según el artículo sobre GNMT (arXiv:1609.08144):

Flujo conceptual:

Source sentence
   |
   v
WordPiece tokenization
   |
   v
Encoder LSTM stack ---> context vectors
   |
   v
Attention <---- Decoder LSTM stack (autoregressive)
   |
   v
Target WordPiece tokens -> detokenized sentence

Google informó que GNMT redujo los errores de traducción en un promedio de 60% frente a su sistema de producción basado en frases, en una evaluación humana de comparación directa sobre oraciones simples aisladas (artículo sobre GNMT). Por eso la publicación del blog de 2016 lo describió como un salto mayor que el de los diez años anteriores juntos.

Entran los Transformers, pero todavía no son «LLM de chat»

La arquitectura Transformer de 2017 (Vaswani et al., «Attention Is All You Need») aceleró la investigación en NMT y, con el tiempo, reemplazó muchos stacks seq2seq basados en RNN en la industria. Pero incluso los modelos de traducción basados en Transformers seguían siendo sistemas seq2seq especializados entrenados con texto paralelo: más cercanos a una evolución de GNMT que a los modelos de chat actuales ajustados para seguir instrucciones.

El ecosistema open source siguió el mismo patrón:

• MarianMT / OPUS-MT: cientos de modelos bilingües de Helsinki-NLP, de ~298MB cada uno, prácticos para pares de idiomas específicos (documentación de MarianMT en Hugging Face).
• NLLB-200: modelo masivamente multilingüe de Meta que cubre 200 idiomas, orientado especialmente a la traducción de idiomas con pocos recursos (documentación de NLLB en Hugging Face, artículo de Meta).

Estos siguen siendo modelos de traducción, no agentes de razonamiento general.

Era 4: resolver la cobertura con traducción automática multilingüe y zero-shot (2022–2024)

Una vez que la NMT fluida funcionó para los idiomas principales, el siguiente problema conocido fue la cobertura de idiomas.

Traducción automática zero-shot (May 2022)

El May 11, 2022, Google agregó 24 idiomas a Translate mediante Zero-Shot Machine Translation, lo que significa que esos idiomas específicos no requerían ejemplos directos de traducción paralela durante el entrenamiento (blog de Google). Google Research describió el método en Building Machine Translation Systems for the Next Thousand Languages:

• Construir conjuntos de datos monolingües limpios para más de 1,000 idiomas.
• Entrenar modelos masivamente multilingües con pares supervisados de más de 100 idiomas con abundantes recursos.
• Agregar señales de aprendizaje autosupervisado para que el modelo pueda traducir a nuevos idiomas sin ejemplos paralelos directos para cada idioma que se incorpora al producto.

Un matiz importante: zero-shot aquí no significa que «no haya datos paralelos en ninguna parte». Significa que Google podía agregar un nuevo idioma sin recopilar primero un corpus alineado grande para ese par.

Esto resolvió un problema tradicional de SMT: ya no era necesario contar con un corpus alineado grande para cada idioma nuevo antes del lanzamiento.

Expansión de idiomas asistida por LLM (2024)

La expansión de Google del June 27, 2024 agregó 110 idiomas y fue descrita como la mayor expansión de Translate hasta ese momento (blog de Google). Google atribuyó a PaLM 2 la capacidad de ayudar a los modelos a aprender idiomas estrechamente relacionados de forma más eficiente; por ejemplo, awadhi y marwari, cercanos al hindi, o criollos franceses como el criollo seychelense.

Un matiz importante: esto es infraestructura de traducción multilingüe asistida por LLM, no «pegar texto en ChatGPT». El producto sigue dependiendo de entrenamiento especializado en traducción, evaluación y revisión por hablantes nativos antes del lanzamiento.

Era 5: Translation LLM y stacks híbridos en producción (2024–2026)

La pregunta actual en producción ya no es «¿SMT o NMT?». Es:

When do I use specialized NMT vs a Translation LLM vs a general LLM?

Las recomendaciones de Google Cloud del May 9, 2024 son explícitamente híbridas (blog de Translation AI):

Google documenta TLLM con el ID de modelo general/translation-llm, e incluye ejemplos de API tanto para clientes REST como Python (documentación de Translation LLM de Google Cloud).

Algunas líneas de investigación también dividen la traducción en pasos en lugar de usar un único prompt. El trabajo de Google para WMT 2024 sobre Translating Step-by-Step usó Gemini 1.5 Pro para traducir textos extensos por etapas (analizar -> traducir -> refinar), lo que mejoró la calidad a nivel de documento (PDF del artículo de WMT 2024). Eso se acerca más a cómo deberían abordar los sistemas de producción las traducciones difíciles: un pipeline, no un prompt mágico.

Arquitectura de referencia: construir una aplicación de traducción en 2026

Esta es la arquitectura que usaría hoy para un producto similar a Google Translate.

                         +----------------------+
                         | Client apps / APIs   |
                         +----------+-----------+
                                    |
                                    v
                         +----------------------+
                         | Translation gateway  |
                         | - auth / quotas      |
                         | - request validation |
                         +----------+-----------+
                                    |
                                    v
                         +----------------------+
                         | Routing policy       |
                         | length, domain, SLA  |
                         +--+--------+----------+
                            |        |
               short/low-latency      long-form / tone / glossary-heavy
                            |        |
                            v        v
                 +----------------+  +----------------------+
                 | NMT backend    |  | Translation LLM or |
                 | (managed API,  |  | agentic pipeline   |
                 | NLLB/Marian,   |  | (TLLM, Gemini,     |
                 | CTranslate2)   |  | step-by-step MT)   |
                 +--------+-------+  +----------+-----------+
                          |                     |
                          v                     v
                 +----------------------------------------+
                 | Post-processing                        |
                 | - glossary enforcement                 |
                 | - HTML/Markdown preservation           |
                 | - profanity / PII policy               |
                 +------------------+---------------------+
                                    |
                                    v
                 +----------------------------------------+
                 | Quality + observability                |
                 | - COMET/chrF/BLEU offline              |
                 | - human review queue for low confidence|
                 | - latency/cost metrics                 |
                 +------------------+---------------------+
                                    |
                                    v
                              Translated output

Reglas de enrutamiento que funcionan en la práctica

No envíes cada solicitud al LLM más grande. Google mantiene NMT en su portafolio porque el throughput y el control de terminología siguen importando (Google Cloud Translation AI, May 9, 2024).

Caché y deduplicación

Una vez que el enrutamiento es estable, las traducciones son ideales para almacenar en caché:

hash(source_lang, target_lang, normalized_text, model_id, glossary_version)
   -> cached translation

Usa caché en el gateway para textos de UI repetidos, catálogos de productos y respuestas predefinidas de soporte. Invalídala cuando cambie el glosario o la versión del modelo. Esta es una de las mejoras de latencia más económicas en un producto similar a Translate y cobra más importancia a medida que las rutas con LLM son más lentas.

Para conocer patrones de evaluación más detallados —comparaciones directas, suites de escenarios y controles de lanzamiento—, consulta Evaluación de trazas frente a pruebas de escenarios y Aplicaciones RAG en la práctica. El enfoque de calidad sigue siendo aplicable incluso cuando el backend usa traducción automática en lugar de recuperación de información.

Implementación: un servicio de traducción híbrido mínimo

Este ejemplo muestra el patrón central: enrutar según la longitud del texto, llamar a NMT para cadenas cortas, llamar a Translation LLM para cadenas largas y aplicar una revisión posterior del glosario.

Gateway en TypeScript (Cloud Translation API)

type TranslateRequest = {
  text: string;
  source: string;
  target: string;
  glossary?: Record<string, string>;
};

const TLLM_MODEL =
  "projects/PROJECT_ID/locations/us-central1/models/general/translation-llm";

function chooseModel(text: string): string | undefined {
  // Short UI strings -> default NMT (omit `model`).
  // Longer blocks -> Translation LLM.
  return text.length > 280 ? TLLM_MODEL : undefined;
}

async function translateWithGoogle(req: TranslateRequest): Promise<string> {
  const model = chooseModel(req.text);

  const response = await fetch(
    "https://translation.googleapis.com/v3/projects/PROJECT_ID:translateText",
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.GOOGLE_ACCESS_TOKEN}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        contents: [req.text],
        sourceLanguageCode: req.source,
        targetLanguageCode: req.target,
        mimeType: "text/plain",
        ...(model ? { model } : {}),
      }),
    }
  );

  if (!response.ok) {
    throw new Error(`Translate API failed: ${response.status}`);
  }

  const payload = await response.json();
  let translated = payload.translations?.[0]?.translatedText ?? "";

  if (req.glossary) {
    translated = enforceGlossary(translated, req.glossary);
  }

  return translated;
}

function enforceGlossary(
  text: string,
  glossary: Record<string, string>
): string {
  // Demo-only. Production systems should use Translation API glossaries
  // or token-safe term replacement, not naive string replace.
  let output = text;
  for (const [source, target] of Object.entries(glossary)) {
    output = output.replaceAll(source, target);
  }
  return output;
}

Los ID de modelo y los umbrales de enrutamiento son parámetros de despliegue configurables. El punto importante de ingeniería es que el enrutamiento es explícito y se puede probar. Para gestionar la terminología, prefiere los recursos de glosario de Cloud Translation al reemplazo de cadenas después de la traducción (documentación de Translation LLM).

Alternativa autohospedada con NLLB (Python)

Para cargas de trabajo sensibles a la privacidad o uso sin conexión, NLLB-200 es un backend open source práctico (documentación de NLLB en Hugging Face):

from transformers import AutoModelForSeq2SeqLM, AutoTokenizer

MODEL_NAME = "facebook/nllb-200-distilled-600M"
tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)
model = AutoModelForSeq2SeqLM.from_pretrained(MODEL_NAME)


def translate_nllb(text: str, src: str, tgt: str) -> str:
    tokenizer.src_lang = src
    inputs = tokenizer(text, return_tensors="pt")
    forced_bos = tokenizer.lang_code_to_id[tgt]
    outputs = model.generate(
        **inputs,
        forced_bos_token_id=forced_bos,
        max_length=512,
    )
    return tokenizer.batch_decode(outputs, skip_special_tokens=True)[0]


# Example: English -> French
print(translate_nllb("Hello from our translation service.", "eng_Latn", "fra_Latn"))

Para lograr throughput de producción, convierte el modelo con CTranslate2 y expónlo mediante FastAPI o un worker de cola. MarianMT sigue siendo útil cuando solo necesitas un par de alto tráfico y quieres un modelo que ocupe menos recursos (documentación de MarianMT).

Traducción agéntica de textos extensos (pipeline de LLM)

Para documentos largos, un único prompt suele dar peores resultados que un pipeline por etapas inspirado en investigaciones orientadas a producción (artículo paso a paso de WMT 2024):

1. Segment document by logical blocks (headings, paragraphs)
2. Extract terms / names / glossary candidates
3. Translate block with document-level context
4. Consistency pass across blocks
5. Optional back-translation check for critical content
6. Human review queue if confidence metrics fail

Así es como los LLM modernos resuelven problemas antiguos, como la coherencia del documento y la deriva terminológica: no ignorando la historia de la traducción automática, sino agregando orquestación a su alrededor.

Evaluación: no lances sin controles de calidad

Los sistemas de traducción automática anteriores dependían de BLEU y de conjuntos de evaluación humana. Ese sigue siendo el enfoque correcto.

Controles mínimos de lanzamiento para una aplicación de traducción. Los umbrales siguientes son valores editoriales predeterminados para un primer lanzamiento a producción: ajústalos a tu SLA, combinación de locales y nivel de riesgo.

La documentación de TLLM de Google menciona explícitamente mejores resultados en MetricX y COMET para cargas de trabajo difíciles (documentación de Translation LLM). Usa la misma familia de métricas para tus propias pruebas A/B.

Qué cambió y qué no

Problemas antiguos que la tecnología moderna realmente resuelve mejor

Lo que los LLM modernos no resuelven automáticamente

• Latencia a escala de chat: Google todavía recomienda NMT para textos cortos de alto volumen (Google Cloud Translation AI).
• Terminología determinista: los glosarios y el posprocesamiento siguen siendo importantes.
• Calidad de lanzamiento para nuevos idiomas: la traducción automática zero-shot ayuda, pero Google todavía recurre a la revisión de hablantes nativos antes del lanzamiento (blog de May 2022).
• Contenido alucinado: los LLM pueden parafrasear u omitir contenido; las penalizaciones por cobertura y las evaluaciones siguen siendo esenciales.

Stack recomendado según la etapa

Perspectiva editorial

Google Translate es la prueba más clara de que «la IA moderna resuelve problemas antiguos» suele significar una solución construida por capas, no una revolución de un solo golpe:

• SMT resolvió la escala.
• GNMT resolvió la fluidez sin LLM de chat.
• La traducción automática multilingüe y zero-shot resolvió la cobertura.
• Los Translation LLM resuelven el manejo de contextos difíciles y la calidad de textos extensos.

Si estás construyendo una aplicación de traducción hoy, considera los LLM como una nueva opción de backend dentro de una arquitectura de enrutamiento, no como un reemplazo de todas las lecciones sobre traducción aprendidas desde 2006.

Fuentes

Primero, las fuentes primarias y oficiales:

• Google Research — Lanzamiento de la traducción automática estadística (April 28, 2006)
• Google — Found in translation: Neural Machine Translation (November 15, 2016)
• Wu et al. — Sistema de traducción automática neuronal de Google (arXiv:1609.08144, 2016)
• Vaswani et al. — Attention Is All You Need (arXiv:1706.03762, 2017)
• Google — Traducciones neuronales de mayor calidad para más idiomas (March 6, 2017)
• Google — Translate agrega 24 idiomas con traducción automática zero-shot (May 11, 2022)
• Google Research — Habilitar la traducción automática sin recursos (May 11, 2022)
• Bapna et al. — Construcción de sistemas de traducción automática para los próximos mil idiomas (2022)
• Google — Translate agrega 110 idiomas (June 27, 2024)
• Google Cloud — Documentación de Translation LLM (TLLM)
• Google Cloud — Recomendaciones de producto de Translation AI (May 9, 2024)

Modelos abiertos y referencias de implementación:

• Hugging Face — Documentación del modelo MarianMT
• Hugging Face — Documentación del modelo NLLB
• Meta AI — No Language Left Behind (arXiv:2207.04672)

Investigación sobre workflows modernos de traducción con LLM:

• Caswell et al. — Traducción paso a paso (WMT 2024)

Antecedentes y contexto histórico (fuente secundaria):

• Google Translate — Resumen de Wikipedia sobre el lanzamiento y el método