Los modelos inventan sintaxis para tu DSL: la salida pasa por el sistema de tipos

Un modelo de lenguaje al que le pides Python devuelve Python. Al que le pides la notación de modelado que tu equipo diseñó en casa devuelve algo que se le parece: palabras clave inventadas, nombres de parámetros adivinados, construcciones que nunca estuvieron en la especificación. Y lo entrega con la misma seguridad que el código correcto. Un artículo técnico reciente sostiene que eso no es un problema de conocimiento del modelo, sino de frecuencia en sus datos de entrenamiento, y que el arreglo se toma antes de que el modelo vea el lenguaje: no dejar que la sintaxis viva fuera del sistema de tipos.

Frecuencia y lenidad

La competencia sintáctica de un modelo es, en primera aproximación, una función de cuántas veces aparece un lenguaje en su corpus. Por eso escribe Kotlin, TypeScript, SQL o Python sin despeinarse, y por eso se degrada con lenguajes de bajos recursos. Ante una gramática que no ha visto, el modelo no falla en alto: interpola. Cuela sintaxis de flechas copiada de Mermaid o PlantUML, inventa un addRelation o un withLabel que tu API no tiene y pasa tres argumentos a una construcción que admite dos porque un primo sintáctico suyo admite tres. El resultado está bien indentado y es incorrecto.

Aquí juega en contra una virtud clásica de los DSL: la indulgencia. Los parsers de configuración y las herramientas de diagramas están hechos para perdonar, para saltarse la línea que no entienden y dibujar una aproximación. Con un humano eso es cortesía. Con un modelo es una trampa: produce un diagrama de diez clases con una relación inventada, el parser se salta esa línea y lo que llega al documento es un plano impecable al que le falta exactamente una asociación. Nadie sospecha, porque las otras nueve están bien.

Anclar la notación, no solo los hechos

En la ingeniería habitual de modelos, anclar significa recuperación aumentada: traer los documentos relevantes al contexto y sujetar ahí las afirmaciones. Eso disciplina el contenido, pero no toca la notación. Un modelo puede tener el hecho correcto en contexto y expresarlo con una gramática que se ha inventado. Los dos ejes son ortogonales y se combinan: los hechos se recuperan por un lado y se expresan en un DSL tipado que el compilador revisa por el otro.

La propuesta del autor es el anclaje tipado de dominio: incrustar el dominio como un DSL interno tipado dentro de un lenguaje anfitrión con mucha presencia en el corpus, y moldear su API para que los errores de dominio salgan como errores de tipo del compilador en lugar de fallos silenciosos. En un banco de cincuenta tareas con Claude Sonnet 5, ese enfoque dio más fidelidad estructural y menos alucinación que dos DSL externos indulgentes, aunque con una tasa de compilación al primer intento más baja. Con GPT-4o se repite; con todos los modelos probados, no.

El autor reconoce los límites: cierra huecos de sintaxis, no de comprensión, y obliga a renunciar a libertad notacional y a comprometerse con un lenguaje anfitrión. Su recomendación es tenerlo en cuenta por defecto al diseñar un DSL nuevo, no reescribir los que ya funcionan. Y el dato incómodo que deja es que un validador estricto que rechaza puede converger a una salida más fiable que uno permisivo, aunque no siempre lo haga. La cifra del banco de pruebas es suya, de un experimento propio, no de un tercero.