Markdown como formato de salida estructurado en LLMs

Cuándo conviene pedir a un modelo de lenguaje que responda en Markdown frente a JSON, YAML o XML, con ejemplos prácticos y limitaciones.

Publicado el 12 de mayo de 2026

Cuando integras un modelo de lenguaje en una aplicación, antes o después te toca decidir qué formato debe devolver. Las opciones por defecto son JSON, YAML o XML, pero hay un cuarto candidato que muchas veces gana en la práctica: Markdown. No siempre es la mejor opción, pero hay tantos casos en los que sí lo es que conviene tenerlo siempre en la baraja.

Este post repasa cuándo elegir Markdown como formato de salida de un LLM, cuándo no, y cómo combinarlo con otros formatos en flujos reales.

Cuándo Markdown gana a JSON

Hay tres situaciones en las que Markdown encaja mejor que JSON.

El resultado se va a renderizar para humanos: si la respuesta del modelo va a verse en una interfaz de chat, en una página web, en un email o en un PDF, Markdown se renderiza directamente con encabezados, listas y tablas. JSON necesitaría una capa de transformación a HTML o a la interfaz final.

La estructura es flexible o desigual: cuando los resultados pueden tener subsecciones distintas según el caso (un análisis técnico unas veces necesita una tabla, otras una lista de pros y contras), Markdown permite esa variabilidad de forma natural. JSON exige un schema definido de antemano.

El contenido es mayormente prosa: si la respuesta es básicamente texto explicativo con algo de estructura ligera, meterlo en JSON convierte cada párrafo en un string escapado horrible de leer y de depurar. Markdown deja el texto legible directamente.

Cuándo JSON sigue siendo mejor

Hay casos en los que JSON (o YAML, o cualquier formato estructurado estricto) es la elección obvia y no merece la pena complicarse:

  • Pipelines automatizados donde otro programa consume la salida sin intervención humana.
  • Datos que se van a procesar campo a campo (insertar en base de datos, alimentar un dashboard).
  • Validación estricta con un schema: si la salida no cumple, el flujo falla.
  • Anidamiento profundo: estructuras de varios niveles con relaciones complejas se modelan mejor en JSON.

En estos casos, los modelos modernos admiten el parámetro response_format por API para forzar JSON válido, y conviene usarlo en lugar de pedir el formato por prompt.

Markdown estructurado: lo mejor de ambos mundos

El patrón que mejor funciona en muchas aplicaciones es Markdown con secciones predecibles. Le das al modelo un esqueleto con encabezados fijos y un formato consistente, y obtienes una salida que es a la vez legible para humanos y parseable de forma sencilla.

Un ejemplo concreto: un asistente que analiza un código y devuelve un informe. La salida esperada sería:

## Resumen
[1-2 frases con la conclusión principal]

## Hallazgos
- [Problema 1]: [descripción]
- [Problema 2]: [descripción]

## Sugerencias
1. [Sugerencia 1]
2. [Sugerencia 2]
3. [Sugerencia 3]

## Severidad global
[Alta / Media / Baja]

Si quieres extraer programáticamente los hallazgos o la severidad, basta con un regex sencillo que busque las secciones por su encabezado. No necesitas un parser JSON ni un schema. Y si un usuario quiere leer el informe, ya está formateado para mostrarse en pantalla.

Tablas Markdown como alternativa a arrays de objetos

Cuando la salida del modelo es una lista de elementos con propiedades, las tablas Markdown son una alternativa muy razonable a un array de objetos JSON. Compara estas dos opciones:

JSON:

[
  {"producto": "A", "precio": 29.99, "stock": 12, "rating": 4.2},
  {"producto": "B", "precio": 49.99, "stock": 5, "rating": 4.5},
  {"producto": "C", "precio": 19.99, "stock": 0, "rating": 3.8}
]

Markdown:

| Producto | Precio | Stock | Rating |
|----------|--------|-------|--------|
| A | 29,99 | 12 | 4,2 |
| B | 49,99 | 5 | 4,5 |
| C | 19,99 | 0 | 3,8 |

Las dos contienen la misma información. La diferencia es que la tabla Markdown se renderiza en pantalla sin transformación adicional y es más fácil de revisar visualmente. Si necesitas procesarla luego, las tablas Markdown son lo bastante regulares como para parsearlas con poco código.

Ejemplos por caso de uso

Asistente conversacional: Markdown casi siempre. El usuario ve la respuesta directamente.

Generador de informes: Markdown estructurado. Combinas legibilidad con procesabilidad parcial.

API que devuelve datos a otra API: JSON con response_format estricto. Sin Markdown.

Generador de plantillas de email: Markdown que después se convierte a HTML antes de enviar.

Extractor de campos de un documento: JSON, porque cada campo se va a usar individualmente.

Editor de código asistido: Markdown con bloques de código en su interior. Los bloques se aíslan con triple backtick y el resto del texto explica.

Análisis de sentimiento masivo: JSON, idealmente con solo el campo "sentimiento" y nada más.

Pedirle al modelo el formato Markdown

La sintaxis Markdown es la lengua materna de los LLMs (más sobre esto en Markdown y la IA), así que pedírselo es trivial. Tres reglas para que el resultado sea consistente:

Especifica el esqueleto: dale un ejemplo concreto del formato esperado, no descripciones genéricas. "Devuelve un informe con secciones Resumen, Hallazgos y Sugerencias" funciona mejor si lo acompañas con el esqueleto exacto.

Marca los puntos variables: usa placeholders como [...] o {{...}} para indicar dónde va contenido específico.

Restringe el formato libre: si el modelo a veces inserta saludos o conclusiones extra, añade "no añadas texto antes ni después del informe" al final del prompt.

Si vienes de un flujo en JSON donde usabas response_format, perderás la garantía absoluta de validez, pero ganarás flexibilidad y legibilidad. Es un trade-off, no un upgrade universal.

Markdown ejecutable y estructurado

Hay un patrón emergente que mezcla Markdown con estructuras semi-formales. Un ejemplo es responder con un bloque de código que contiene JSON o YAML dentro de la respuesta Markdown:

## Análisis
[Texto explicativo]

## Datos extraídos

```json
{
  "campos": [
    {"nombre": "...", "valor": "..."}
  ]
}
```

## Recomendación
[Texto]

Así obtienes una salida que es Markdown para humanos pero contiene un bloque JSON aislado y fácil de extraer programáticamente. Es ideal cuando una parte de la respuesta debe ser exacta y otra parte se beneficia de la naturalidad del texto.

Limitaciones de Markdown como formato de salida

Markdown no es la panacea. Conviene tener presentes sus limitaciones:

  • No hay un parser estándar: distintos renderizadores interpretan Markdown ligeramente distinto. Si dos sistemas consumen tu salida, comprueba que ambos la entienden igual.
  • Carece de tipos: en JSON 42 es número y "42" es texto. En Markdown todo es texto. Si necesitas distinción de tipos, JSON gana.
  • No valida: si el modelo se equivoca y se salta una sección, no hay error automático. Tu código debe lidiar con campos ausentes.
  • Es ambiguo en anidamientos profundos: listas dentro de listas dentro de tablas se vuelve confuso rápido.

Estas limitaciones se gestionan, no se evitan. Pero conviene saberlas para no descubrirlas tarde.

Para terminar

La pregunta "Markdown o JSON" no tiene una respuesta universal. Depende de qué hace con la salida tu aplicación y de quién la consume. La regla práctica: si una persona va a leerla, empieza por Markdown; si solo la consume otro programa, ve directo a JSON con response_format estricto. Y en muchos casos, la mejor combinación es Markdown con bloques de JSON aislados dentro.

Recursos relacionados

Esto ha sido todo.

👋 Hola! Soy Edu, me encanta crear cosas y he redactado este tutorial. Si te ha resultado útil, el mayor favor que me podrías hacer es el de compatirlo en Twitter.

para estar al día con mi contenido. 😊