IA y LLMs

Los modelos de lenguaje generan Markdown con facilidad: es el formato más presente en sus datos de entrenamiento. Sin embargo, un Markdown "válido" no garantiza nada: cualquier salida pasa, incluidos campos inventados, secciones que faltan y metadatos incorrectos.

Por qué un LLM escribe bien STXT

STXT no aparece en los datos de entrenamiento de los modelos, pero con un ejemplo y una plantilla en el contexto, seguir un formato regular es una tarea que los modelos resuelven con fiabilidad.

STXT es más regular que Markdown:

• Cada línea es Nombre:, Nombre >> o texto indentado.
• No hay sintaxis alternativas para un mismo elemento.
• La estructura es lineal: se genera de arriba abajo, sin referencias hacia atrás.

Los errores posibles son pocos y conocidos:

• Deriva de indentación en documentos muy largos.
• Omitir la indentación de una línea dentro de un bloque >>.

Ambos se detectan al validar.

La diferencia: verificable

Cuando un LLM genera Markdown, no hay nada contra lo que comprobar el resultado. Cuando genera STXT con una plantilla:

• El parser valida la salida inmediatamente.
• El modelo de contenido cerrado rechaza los nombres de nodo no declarados.
• Los ENUM y las cardinalidades rechazan los valores inventados.
• Los tipos (DATE, EMAIL, NUMBER...) rechazan los formatos incorrectos.

Un documento STXT válido significa que la estructura es correcta. Un Markdown válido no significa nada.

El bucle: generar, validar, corregir

La validación convierte la generación en un proceso iterativo:

1. El LLM genera el documento STXT.
2. El parser lo valida contra la plantilla.
3. Si hay errores, se devuelven al modelo.
4. El modelo corrige y se repite.

Cada iteración reduce los errores a los que el validador señala; el proceso termina cuando el documento valida. Este bucle no existe para Markdown: no hay nada contra qué validar.

El paso 2 es stxt validate -: la CLI lee el documento por la entrada estándar, lo valida contra las gramáticas del directorio actual y emite cada hallazgo como <stdin>:línea: [CÓDIGO] mensaje, con código de salida 1 si hay errores. Está pensada para pipes y CI, de modo que la salida del modelo se valida sin pasar por un fichero. Ver La CLI.

Ejemplo de plantilla incluida en el prompt:

Template (@stxt.template): com.acme.informes
	Structure >>
		Informe (com.acme.informes):
			Título: (1)
			Fecha: (1) DATE
			Estado: (1) ENUM [Borrador, Final]
			Resumen: (1) TEXT
			Sección: (*)
				Título: (1) @Título
				Contenido: (1) TEXT

Salida generada con errores típicos de un LLM, todos detectados:

Informe (com.acme.informes):
	Título: Análisis de mercado
	# ERROR: DATE requiere YYYY-MM-DD
	Fecha: mañana
	# ERROR: no es un valor del ENUM
	Estado: Pendiente
	# ERROR: hijo no declarado (modelo cerrado)
	Subtítulo: Versión corta
	# ERROR: falta Resumen, que es obligatorio

Un ejemplo ejecutable

El bucle completo está en examples/llm/ del repositorio de la especificación: un programa de Node de unas ochenta líneas que convierte unas notas de reunión en texto libre en un Report (com.acme.reports) válido. Lo acompañan la plantilla en .stxt/, un documento de ejemplo correcto, el prompt con las reglas del formato y las notas de partida.

• Genera: el prompt lleva las reglas de STXT en diez líneas, la plantilla entera, el ejemplo válido y el texto a convertir; pide el documento y nada más.
• Valida: UnifiedSchemaProvider carga la plantilla y Parser con SchemaValidator devuelve los errores con línea y código, como haría stxt validate -.
• Corrige: los errores vuelven al modelo tal cual, a continuación de su propia respuesta, y se repite hasta que el documento valida o se agotan los intentos.

$ node generate.mjs > report.stxt
--- attempt 1: 3 error(s)
    line 3: [INVALID_VALUE] Date: Invalid date (12 March 2026) (schema)
    line 5: [INVALID_VALUE] The value 'draft' not allowed. Only: Draft, Final (schema)
    line 1: [TOO_FEW_CHILDREN] 0 nodes of 'com.acme.reports:summary' and min is 1 (schema)
--- attempt 2: valid

El documento sale por la salida estándar y el diálogo por la de error, con código de salida 0 solo si la última versión valida: es un paso de pipeline más. El ejemplo usa la API de Anthropic, pero nada del bucle depende del proveedor; la llamada al modelo es una función que devuelve texto. El README del directorio resume qué error del modelo produce qué código.

Sin escapado: prosa larga dentro de estructura

El punto débil de los LLMs al generar JSON es el escapado: comillas, \n, saltos de línea dentro de strings.

{"resumen": "Línea 1\nLínea 2 con \"comillas\" y más texto..."}

En STXT, los bloques >> son texto literal: el modelo solo tiene que indentar.

Resumen >>
	Línea 1
	Línea 2 con "comillas" y más texto...

Para documentos con texto libre extenso, STXT es una superficie de salida más fiable que JSON o YAML.

La normalización absorbe la varianza

El nombre canónico de los nodos absorbe las variaciones habituales de un LLM: TITLE:, Title: y title: son el mismo nodo. Donde otros formatos reportarían "campo desconocido", STXT identifica el mismo elemento.

La validación estricta se reserva para donde importa: los valores ENUM distinguen mayúsculas y son exactos.

Prácticas de prompting

• Incluir en el prompt la plantilla completa del namespace: es compacta y declara qué campos existen, sus cardinalidades y sus valores permitidos antes de generar.
• Añadir un documento de ejemplo completo y correcto.
• Pedir indentación consistente (tabuladores, o 4 espacios por nivel).
• Validar siempre la salida con el parser, no por inspección visual.
• Asegurar que los mensajes de error del validador incluyen línea, qué se esperaba y qué se encontró: es lo que el modelo necesita para corregir en la siguiente iteración.

Casos de uso

• CMS con contenido asistido por IA: el build rechaza las páginas generadas incompletas o incoherentes antes de publicarlas.
• Extracción de datos: convertir texto libre (emails, informes, actas) en documentos STXT validables contra una plantilla.
• Informes y documentación generada: estructura validada, prosa libre dentro de los bloques >>.
• Agentes y pipelines: STXT como formato de intercambio entre pasos, con validación en cada frontera.

Resumen

• Con plantilla y ejemplo en contexto, un LLM genera STXT con fiabilidad.
• La validación detecta campos no declarados, valores inventados y formatos incorrectos.
• El bucle generar → validar → corregir produce un resultado verificable, a diferencia de Markdown, que no tiene contra qué validarse.
• Los bloques literales eliminan el escapado, el punto débil de JSON.
• Estructura verificable y texto libre: los dos requisitos del contenido generado por IA.