
La traducción es el problema más filosófico de la informática. Y casi nadie lo trata así.
Llevo meses construyendo agentes AI que trabajan en equipo para mi agencia. Pero cuando un cliente de traducción EN→DE me pidió un sistema que no sonara a Google Translate, supe que el problema era diferente a todo lo que había atacado antes. No era un problema de calidad de output ni de fluency ni de terminología. Era un problema epistemológico: ¿qué significa que una traducción sea “correcta”?
La respuesta corta: depende de a quién le preguntes. Y la respuesta larga es que tres filósofos del lenguaje pasaron décadas discutiendo exactamente eso sin ponerse de acuerdo. Así que decidí ponerlos a trabajar juntos.
Por qué la traducción AI sigue siendo mala
Los traductores AI traducen significado. Eso suena bien hasta que te das cuenta de que el significado es la parte fácil. Lo difícil es todo lo que rodea al significado: el uso, el tono, la ambigüedad intencional, el registro. Un email de un CEO a su board y un email del mismo CEO a su equipo pueden decir “lo mismo” con un tono completamente diferente. Ningún traductor AI que conozca preserva esa diferencia de forma consistente.
Un ejemplo. “We need to get our ducks in a row” no significa nada sobre patos. Un traductor AI competente lo sabe y produce algo como “Wir müssen alles in Ordnung bringen”. Técnicamente correcto. Pero el original tiene un registro informal, casi cómico, que la versión alemana pierde por completo. Un alemán nativo diría “Wir müssen unsere Schäfchen ins Trockene bringen” (meter las ovejitas a cubierto), que preserva la imagen animal y el tono coloquial.
La diferencia entre ambas traducciones no es de significado. Es de uso. Y eso es exactamente lo que Wittgenstein pasó la segunda mitad de su carrera tratando de explicar.
La idea: filósofos del lenguaje como revisores
Cuando diseñé el pipeline, necesitaba agentes que no solo revisaran si la traducción “dice lo mismo”. Necesitaba agentes que evaluaran dimensiones del lenguaje que la mayoría de los sistemas ignoran. Y resulta que tres filósofos del siglo XX ya habían mapeado esas dimensiones con precisión quirúrgica.
Wittgenstein, el del uso. Su tesis en las Investigaciones Filosóficas es que el significado de una palabra no es un objeto al que la palabra “apunta”. El significado es su uso en el lenguaje. “El significado de una palabra es su uso en el lenguaje.” Punto. Eso convierte a Wittgenstein en el revisor perfecto para validar que las expresiones idiomáticas se localicen al uso real del alemán, no a su traducción literal.
Quine, el de la ambigüedad. Su tesis de la indeterminación de la traducción en Word and Object dice literalmente que la traducción perfecta no existe. Que siempre hay puntos donde dos traducciones igualmente válidas divergen en formas que no se pueden resolver apelando al significado original. El agente Quine detecta esos puntos de ambigüedad y fuerza al traductor a hacer una elección consciente en lugar de dejarla implícita.
Frege, el del sentido. Su distinción Sinn/Bedeutung (sentido vs. referencia) en “Über Sinn und Bedeutung” es la herramienta perfecta para evaluar si el tono y la connotación emocional se preservaron. “The morning star” y “the evening star” tienen la misma referencia (Venus) pero diferente sentido. Una traducción que preserva la referencia pero pierde el sentido ha fallado, aunque técnicamente “diga lo mismo”.
7 agentes, 3 capas, un pipeline
El sistema corre sobre Hermes Agent v0.15+ de Nous Research y tiene 7 agentes organizados en 3 capas:
Capa Core: translator (Claude Opus 4)
Capa Filosófica: wittgenstein + quine + frege (Claude Sonnet 4)
Capa Científica: koehn + cho + vaswani (Claude Sonnet 4)
El pipeline completo:
Texto fuente → Traductor → Consenso Filosófico (2-de-3) → Git Commit → Auditoría Científica → Tagged Release
El consenso 2-de-3 es el corazón del sistema. Los tres filósofos evalúan la traducción de forma independiente. Wittgenstein revisa uso y localización. Quine busca ambigüedades no resueltas. Frege verifica sentido y tono. Si al menos dos de tres aprueban, la traducción pasa a commit. Si no hay consenso, vuelve al traductor con el feedback consolidado de los tres.
¿Por qué 2-de-3 y no unanimidad? Porque unanimidad en traducción no existe. Quine te lo habría dicho.
Los científicos: la capa que nadie espera
Después del consenso filosófico y el git commit, la traducción pasa por tres agentes científicos nombrados por investigadores reales de NLP y machine learning:
Koehn (por Philipp Koehn, Statistical Machine Translation) revisa los git diffs de cada traducción y audita regresiones. Si el traductor aprendió a manejar bien los sustantivos compuestos del alemán en la sesión anterior pero ahora los está resolviendo peor, Koehn lo detecta.
Cho (por Kyunghyun Cho, co-inventor de GRU y contribuidor clave de seq2seq) verifica la integridad del estado de memoria entre sesiones. Si el traductor “olvida” preferencias terminológicas que ya se habían establecido, Cho lo reporta.
Vaswani (por Ashish Vaswani, “Attention is All You Need”) optimiza el contexto y hace pruning. Si el prompt del traductor está acumulando contexto irrelevante que degrada la calidad, Vaswani lo limpia.
Los filósofos evalúan la traducción como texto. Los científicos evalúan al traductor como sistema.
Hermes Agent: aislamiento y kanban
Todo corre sobre Hermes Agent con un diseño que aprendí a fuerza de romper cosas: el HERMES_HOME está aislado por proyecto. No es ~/.hermes/. Es .hermes/ dentro del repo del cliente. Eso significa que puedo tener tres proyectos de traducción corriendo sin que los perfiles, la memoria ni el kanban se contaminen entre sí.
make bootstrap # Crea .hermes/ aislado, instala los 7 perfiles
make env-prod # Anthropic API (Claude Opus 4 para entregas)
make env-test # z.ai/GLM, gratis para iteración
El dual environment es clave para que la economía del proyecto funcione. Iterar con Claude Opus 4 mientras estás afinando prompts y reglas es quemar dinero. El env-test conecta con z.ai o GLM, que son gratuitos, para toda la fase de desarrollo. Cuando la traducción va a producción para el cliente, un make env-prod cambia a Anthropic y todo corre con Opus 4.
La orquestación entre agentes usa el kanban nativo de Hermes. Cada traducción es una tarjeta que se mueve por columnas: backlog, in-translation, philosophical-review, committed, scientific-audit, released. Los agentes toman tarjetas de sus columnas automáticamente. No hay un dispatcher central que decida quién trabaja en qué. La arquitectura es pull, no push.
El proyecto también tiene un A/B test corriendo: el traductor principal usa Claude Opus 4, pero mantenemos un branch paralelo con Claude Sonnet 4 para comparar calidad vs. costo. Los resultados hasta ahora son que Opus produce traducciones que requieren menos iteraciones de consenso, pero Sonnet es suficiente para textos técnicos con terminología establecida.
Un ejemplo concreto
Texto fuente (email corporativo en inglés):
“We’re confident this partnership will move the needle for both organizations.”
El traductor produce: “Wir sind zuversichtlich, dass diese Partnerschaft für beide Organisationen den Unterschied machen wird.”
Parece bien. Ahora veamos qué dicen los filósofos.
Wittgenstein rechaza. “Move the needle” es una metáfora de medición (la aguja de un indicador que se mueve). “Den Unterschied machen” (hacer la diferencia) pierde la imagen de medición cuantitativa que el original implica. En uso alemán corporativo, “die Nadel bewegen” no existe como metáfora. Propone: “spürbare Fortschritte bringen” (traer progreso perceptible), que preserva la idea de cambio medible sin forzar una metáfora que no funciona en alemán.
Quine aprueba con nota. Señala que “both organizations” es ambiguo sobre si incluye subsidiarias o solo las entidades firmantes, pero acepta que esa ambigüedad existe también en el original. No es un error de traducción.
Frege aprueba. El tono de confianza profesional (“zuversichtlich”) preserva el Sinn del original. No hay pérdida de connotación emocional.
Resultado: 2-de-3. Wittgenstein está en minoría pero su feedback llega al traductor. En la revisión, el traductor incorpora “spürbare Fortschritte” y la traducción pasa al commit con una nota de Wittgenstein.
Eso es lo que pasa cuando tres perspectivas filosóficas distintas evalúan la misma frase. La traducción final no es la que “suena bien”. Es la que sobrevivió el escrutinio.
Después del commit, la capa científica toma el relevo. Koehn compara el diff contra traducciones anteriores del mismo cliente y verifica que el traductor no haya regresado en patrones que ya dominaba (sustantivos compuestos, orden de verbos en subordinadas). Cho confirma que el glosario terminológico del proyecto se mantuvo intacto. Vaswani verifica que el contexto del prompt no esté acumulando basura de sesiones anteriores. Si todo pasa, la traducción recibe un tagged release y sale al cliente.
La documentación como infraestructura
El proyecto tiene 10 documentos wiki que cubren todo: overview, arquitectura, perfiles de agentes, workflow de kanban, protocolo de consenso, auditorías científicas, referencia de skills, edge cases, gobernanza del glosario y operaciones.
Eso puede sonar excesivo para un pipeline de traducción. No lo es. Cuando un agente empieza a comportarse de forma inesperada (y pasa), necesitas documentación que te diga exactamente qué debería estar haciendo y por qué. Los 10 docs son el equivalente de un manual de laboratorio: no los lees todos los días, pero cuando algo sale mal, te salvan.
Lo que aprendí
La traducción me enseñó algo que no había visto tan claramente en otros proyectos de agentes: el dominio define la arquitectura. No puedes tomar un patrón genérico de “agente productor + agente revisor” y esperar que funcione en cualquier campo. La naturaleza del problema determina qué tipo de revisión necesitas.
En copywriting, la tensión entre agentes es sobre fuerza vs. claridad vs. elegancia. En traducción, la tensión es epistemológica. No se trata de si la traducción “suena bien”. Se trata de si captura el uso, resuelve la ambigüedad y preserva el sentido. Son tres preguntas que tres filósofos del siglo XX pasaron décadas tratando de responder. Convertirlos en agentes no fue una ocurrencia creativa. Fue la decisión técnica más obvia del proyecto.
La segunda cosa: el consenso 2-de-3 es mejor que la unanimidad y mejor que la dictadura de un solo revisor. La unanimidad produce parálisis porque Quine siempre va a encontrar ambigüedad (es literalmente su tesis). Un solo revisor produce sesgo. El quorum de 2-de-3 produce traducciones que son lo suficientemente buenas en las tres dimensiones sin ser perfectas en ninguna. Y resulta que “suficientemente bueno en tres dimensiones” es mejor que “perfecto en una”.
La tercera cosa: la capa científica importa más de lo que esperaba. Los filósofos evalúan cada traducción como un evento aislado. Los científicos evalúan al sistema a lo largo del tiempo. Koehn detectando regresiones, Cho verificando memoria, Vaswani optimizando contexto. Sin esa capa, el sistema funciona bien el primer día y se degrada en silencio. Y la degradación silenciosa es el modo de falla más peligroso de un sistema de AI en producción, porque el cliente no se queja hasta que ya perdiste su confianza.
La cuarta: la barrera para construir esto no es técnica. Es cultural. La mayoría de la gente que trabaja con AI para traducción piensa en el problema como “traducir mejor”. No piensa en el problema como “evaluar mejor”. Y resulta que la evaluación es donde vive la mayor parte del valor. El traductor, con suficiente contexto, produce traducciones decentes el 85% del tiempo. Lo que separa un sistema profesional de un juguete es qué pasa con el otro 15%.
Para quién es esto
Si haces traducción profesional y piensas que el futuro es “GPT con un prompt largo”, te invito a considerar que la traducción ha sido un problema filosófico desde antes de que existieran las computadoras. Quine escribió Word and Object en 1960. Las preguntas que ese libro plantea siguen sin respuesta definitiva. Pretender que un LLM las resolvió porque produce texto fluido es confundir fluidez con fidelidad.
La Interpretation Cell no resuelve esas preguntas tampoco. Pero al menos las hace explícitas. Y un sistema que sabe dónde están sus límites es infinitamente más útil que uno que no sabe que los tiene.
Wittgenstein cerró su Tractatus con “De lo que no se puede hablar, hay que callar.” El Interpretation Cell hace algo parecido: cuando no puede traducir algo con confianza, te lo dice. Eso, en producción, vale más que mil traducciones fluidas que esconden sus dudas.