Por Qué Retiré la Traducción Automática con Ollama

Durante una etapa inicial de este portfolio construí un traductor local con Ollama, Node.js y un modelo Llama 3 de 8B. El objetivo era atractivo: escribir en español, producir una versión inglesa sin enviar borradores a terceros y evitar costos por token.

El prototipo funcionó en el sentido más básico: generaba archivos, preservaba parte de la estructura y reducía el tiempo necesario para obtener una primera versión. Sin embargo, no resolvió el problema importante. Una traducción que parece correcta, pero altera una ruta, omite una idea o invierte un argumento, no es una mejora del flujo editorial.

Por esa razón retiré Ollama y la traducción automática del proceso activo. Esta nota conserva la arquitectura del experimento, los fallos observados y la decisión que surgió de ellos.

Qué Intentaba Resolver

Una API en la nube introduce conectividad, gestión de credenciales, costos por uso y una decisión sobre qué información se comparte. La inferencia local ofrecía privacidad operativa y libertad para iterar.

La hipótesis era que una automatización suficientemente cuidadosa podía generar las contrapartes inglesas de las notas y mantenerlas sincronizadas. Para probarla, el sistema combinó:

• separación de frontmatter mediante gray-matter;
• dos estrategias según las etiquetas de contenido;
• masking de imágenes;
• caché por hash MD5;
• un diccionario de traducciones fijas;
• integración experimental con hooks de Git.

Arquitectura del Prototipo

Estrategia Técnica

Las notas con la etiqueta technical se procesaban mediante un AST Markdown, temperatura 0.1 y caché por nodo. El objetivo era reducir variaciones y evitar que el modelo reescribiera código o estructura.

Estrategia Personal

Las notas con la etiqueta personal se dividían en fragmentos más amplios y utilizaban temperatura 0.7, sin caché. La intención era conservar mejor el ritmo de ensayos y poemas.

Masking

Las imágenes Markdown se reemplazaban temporalmente por tokens opacos:

![Diagrama](/images/arquitectura.png)
→ __IMG_0__

Después de la inferencia, el script restauraba el valor original. Esto reducía un tipo de error, pero no protegía todos los elementos sensibles de Markdown o MDX.

Caché y Overrides

Cada nodo técnico recibía un hash. Si no había cambiado, el sistema reutilizaba su traducción. Un archivo de overrides fijaba nombres como Dotfiles, Silakka54 o Loutaif Connect.

Estas capas hacían al prototipo más eficiente, pero también aumentaban su complejidad sin solucionar la calidad semántica de fondo.

Qué Falló

Fluidez sin Fidelidad

El riesgo más serio era una frase perfectamente legible que comunicaba otra cosa. En una nota personal, por ejemplo, el borrador inglés llegó a afirmar que dialogamos con una máquina para que piense por nosotros cuando la fuente española sostenía exactamente lo contrario.

Datos Literales Modificados

La revisión posterior encontró rutas sin guiones bajos, tokens de plantillas traducidos, nombres alterados y comentarios de código todavía en español. En documentación técnica, cualquiera de esos defectos puede convertir una guía en una instrucción inválida.

Omisiones

Algunas traducciones descartaban párrafos o bloques completos de resolución de problemas. El texto resultante parecía acabado porque no contenía marcas visibles de error, pero ya no representaba la fuente.

Automatización Dentro de Git

El hook experimental mezclaba traducción, staging y commit. Eso podía sobrescribir correcciones manuales o agregar archivos fuera del alcance previsto. Una operación de control de versiones no debe transformar contenido editorial.

Costo de Revisión

La promesa era ahorrar tiempo. En la práctica, revisar una traducción poco confiable exigía comparar cada frase, cada ruta y cada bloque de código. En notas extensas, corregir el borrador podía demandar más atención que producir una adaptación inglesa rigurosa desde el comienzo.

La Decisión Actual

El flujo vigente es deliberadamente editorial:

1. La nota española se escribe y aprueba como fuente autoral.
2. La versión inglesa se prepara manualmente o con asistencia de una IA capaz, utilizando la fuente completa.
3. Las notas técnicas priorizan precisión terminológica, código y reproducibilidad.
4. Las notas personales priorizan naturalidad sin perder voz, intención ni ambigüedad.
5. Ambas versiones se comparan antes de asignar translationStatus: reviewed.
6. El build sólo publica versiones aprobadas y nunca traduce contenido.

Los metadatos generated y reviewed continúan siendo útiles, pero ahora describen exclusivamente el estado editorial del archivo, no una etapa de un traductor automático.

Rendimiento: Una Optimización Secundaria

En mi Hackintosh, el modelo de 8B se ejecutó principalmente en CPU y alcanzó alrededor de 11 tokens por segundo. Esa medición era suficiente para experimentar, pero terminó siendo irrelevante para la decisión. Una salida rápida o privada no compensa una traducción mediocre que requiere reconstrucción manual.

Conclusión

Retirar una automatización también es una decisión de ingeniería. El prototipo permitió entender masking, AST, caché e inferencia local, pero su resultado no alcanzó el estándar de una carta de presentación profesional.

La lección no es que toda IA sea inútil para traducir. Es que la herramienta debe estar a la altura del contenido y permanecer subordinada al criterio editorial. En este portfolio, la precisión técnica y la naturalidad expresiva tienen más valor que el hecho de poder decir que el proceso está automatizado.