Steve Yegge habló en "Software Survival 3.0" sobre la "compresión de insights (Insight Compression)": la idea de que en Git o Kubernetes están comprimidas décadas de prueba y error, por lo que un LLM no puede reproducirlas fácilmente. Partí de pensar que con el saju myeongri pasa algo parecido.
Qué pasa cuando le encargas el saju a un LLM
Como mucha gente hace hoy, si metes datos de saju en un LLM obtienes resultados bastante convincentes. El problema es la brecha entre lo "convincente" y lo "correcto".
Probé varios modelos, como GPT-5, GPT-4o, Claude y DeepSeek V3, combinando structured output y few-shot. Aparecieron puntos de error sistemáticos. Por ejemplo, aplicar solo la lógica de control y apoyo a un saju de tipo jongganggyeok (從強格) y terminar deduciendo fuego (火) como yongsin. No pude evitar por completo mediante prompts evaluaciones que violaban el principio clásico de "choknogangsin daehyung (觸怒強神 大凶)".
Además, había una tendencia a quedar anclado en la interpretación de una escuela específica y distorsionar el texto original, a embellecer en exceso lecturas negativas o, por el contrario, a amplificar la ansiedad. Dejar la evaluación de reglas al pattern matching de un LLM era un problema del mismo tipo que pedirle aritmética a un modelo de lenguaje.
Hojak Engine: reglas en código, explicaciones solo con LLM
Por eso diseñé una estructura en capas.
Ho (虎) — motor de reglas. Implementa en código la lógica de cálculo del myeongri. Después de establecer por áreas cuál interpretación tomar como referencia entre las divergencias de los cinco textos clásicos principales (Jeokcheonsu, Japyeongjinjeon, Gungtongbogam, Sammyeongtonghoe y Yeonhaejapyeong), fijé esos criterios en el código.
Jak (鵲) — capa explicativa con LLM. Al LLM solo le dejo la parte de convertir en lenguaje natural los datos estructurados calculados por el motor.
Lo que el LLM tenía dificultades para reproducir no era el código, sino los criterios de evaluación refinados durante miles de años.
El punto donde llegaron los límites del vibe coding
Al principio todo iba bien. El LLM ayudó rápido con el análisis de textos clásicos en chino, la organización de escuelas y hasta con borradores de código para cálculos astronómicos. El límite apareció en los puntos donde las reglas de distintas escuelas entraban en conflicto.
Por ejemplo, en la evaluación de gyeokguk (格局), Jeokcheonsu prioriza primero la fortaleza o debilidad del ilgan, mientras que Japyeongjinjeon prioriza primero la aparición del wolryeong. Hubo casos en que, con el mismo saju, el resultado se invertía según qué texto clásico se siguiera, y esa prioridad no era algo que un LLM pudiera decidir.
Al final tuve que conseguir directamente los cinco textos fuente y compararlos. Como había partes faltantes o ilegibles, hice un proceso de validación cruzada entre varias ediciones. Resultó que existía un esfuerzo considerable de preservación de clásicos como proyecto estatal, pero sin ayuda de LLM habría sido un trabajo difícil de asumir para una sola persona. Usé prácticamente al límite Claude Max x20 durante casi tres meses.
Lo interesante es que, en la mayoría de los casos donde el texto original se había trasladado mal, el error estaba del lado humano (de los estudiosos). Según cómo se lea "旺者宜泄, 唯有情有力者可克" de Jeokcheonsu, cambia incluso la bifurcación del algoritmo; en cambio, el LLM fue útil para contrastar entre sí las traducciones de varios académicos y las anotaciones al texto original.
Precisión temporal: 1 minuto cambia la evaluación
En el myeongri, una diferencia de 1 minuto en la hora puede cambiar una evaluación clave. Si en el límite entre jasi (子時) y chuksi (丑時) cambia el pilar horario, cambia incluso la evaluación misma del gyeokguk.
Hojak Engine combina la ecuación del tiempo por series de Fourier basada en NASA/JPL (precisión de ±13 segundos), la evaluación global de DST basada en IANA tzdata y una base de datos de longitudes de más de 163,400 ciudades. En el caso de Corea, refleja cuatro cambios de meridiano estándar desde 1908 y un historial de 12 años de horario de verano.
Descubrir en los registros oficiales del Gwansanggam de Joseon (Seoungwanji) la misma fórmula de corrección por longitud que usa el código actual fue, personalmente, una experiencia impactante.
Estado de la validación
El cálculo de términos solares coincide al 100% con los datos oficiales del Korea Astronomy and Space Science Institute (KASI) en el rango 2000–2050. La ecuación del tiempo asegura una precisión de ±13 segundos basada en NASA/JPL Horizons. Para sinsal, fijé el sistema ortodoxo de las doce divinidades sinsal (basado en Sammyeongtonghoe) y lo contrasté con calendarios manseryeok, con coincidencia del 100%; para gwiinsal y sales especiales, tras validación cruzada con los textos fuente, los apliqué clasificados en tres niveles: orthodox / disputed / reference.
Stack tecnológico
El motor usa Python FastAPI + PostgreSQL + SQLAlchemy 2.0(async), y el frontend es Next.js 15 + React 19 + TypeScript + Tailwind CSS. Para AI uso un enfoque multimodelo vía OpenRouter (GPT-4o, Claude, DeepSeek V3) solo en la capa explicativa. El despliegue es con Fly.io (Blue-Green) + Vercel, y los pagos con Toss Payments + PayPal.
Actualmente genera reportes estructurados del orden de 30,000+ caracteres para análisis de saju palja y 20,000+ caracteres para análisis anuales, y los datos de nacimiento se almacenan cifrados.
Cierre
Existen distintas posturas sobre la validez predictiva del myeongri. Más que en ese debate, este proyecto se centró en el reto de ingeniería de "si se va a usar este sistema, entonces calculemos de forma consistente y con criterios correctos según su intención".
Comenzó de forma ligera con vibe coding, pero al final terminé analizando los cinco textos clásicos y hasta revisando código de la ecuación del tiempo de NASA/JPL. Tomando prestada la expresión de Yegge, la densidad del insight comprimido en este dominio era mucho mayor de lo que esperaba.
Se agradecen preguntas técnicas o feedback.
3 comentarios
Es un poco triste porque parece que mi gran ciclo de suerte no viene muy bien... pero normalmente las columnas del destino se ordenan como hora, día, mes y año, y en este servicio está al revés, así que fue un poquito confuso. Si no hay una intención particular detrás, ¿qué tal si lo cambian al orden habitual?
Lo cambié de inmediato al orden correcto de hora, día, mes y año apenas me lo comentaste. Estaba ocupado con otro trabajo, así que recién ahora pude agrupar todo para el despliegue. Gracias.
Al analizarlo, vi que en la práctica quienes ya tenían interés en el saju conectaban mucho más profundamente con el contenido y además usaban el servicio durante más tiempo. Al principio, por querer que "incluso quienes no conocen el saju lo tuvieran fácil", cambié el orden, pero fue un error de juicio. Gracias a tus comentarios pude corregir el rumbo. Nuevamente, muchas gracias.
Tiene razón sobre el orden del arreglo. Al principio lo organicé en orden cronológico (año-mes-día-hora) para que quienes no están familiarizados con el saju pudieran revisar de forma intuitiva su fecha y hora de nacimiento, pero parece que más personas de las que esperaba ya están acostumbradas al orden del saju y eso terminó generando confusión.
Como incluso en los textos clásicos el orden correcto es hora-día-mes-año, voy a considerar seriamente hacer ese cambio. Fue un comentario realmente necesario.
Gracias por la retroalimentación.
Y sobre lo que comentó de que está pasando por una etapa difícil en el daewoon, en Myeongri el daewoon es la gran corriente, y dentro de ella están los cambios del sewun (歲運). Incluso dentro de un daewoon complicado, sin falta llega el momento de encontrarse con el yongsin, así que espero que pueda aprovechar bien esa oportunidad cuando llegue.