Por qué los LLM usan Markdown por defecto
Pídele a ChatGPT, Claude o casi cualquier otro modelo conversacional una respuesta estructurada, y por defecto la dará en Markdown —encabezados, texto en negrita, pasos numerados, bloques de código. Eso no es casualidad. Markdown señala la estructura con muy pocos caracteres adicionales: un encabezado cuesta un # y un espacio; un elemento de lista cuesta un - y un espacio. El equivalente en HTML —<h2>, </h2>, <li>, </li>— gasta muchos más tokens para decir lo mismo, y a gran escala cada token adicional supone dinero y latencia.
Markdown también está representado de forma extremadamente amplia en el texto con el que se entrenaron estos modelos. Los README de GitHub, las respuestas de Stack Overflow, la documentación técnica y un sinfín de publicaciones en foros lo usan, así que los modelos han visto un número enorme de ejemplos de cómo los encabezados, las listas y los bloques de código se corresponden con una estructura real. Esa familiaridad hace de Markdown una sintaxis que los modelos pueden tanto generar de forma fiable como interpretar sin ambigüedad en su propio texto (o en el de un usuario).
Markdown en los prompts
Esa misma claridad estructural ayuda también en la entrada, no solo en la salida. Un prompt dividido en secciones claramente etiquetadas —digamos un encabezado ## Context y un encabezado ## Task y un encabezado ## Constraints — le da al modelo un mapa explícito de para qué sirve cada parte del prompt, en lugar de dejar que lo infiera de un único párrafo indiferenciado.
- Usa una lista con viñetas o numerada para instrucciones que quieras que se sigan punto por punto —los modelos tienden a abordar los elementos de la lista de forma individual en lugar de mezclarlos.
- Envuelve cualquier código, salida de registro o texto que el modelo deba tratar como literal (sin reescribir ni resumir) en un bloque de código. La valla de triple comilla invertida es un límite inequívoco que la mayoría de los modelos respeta.
- Usa una tabla cuando le des al modelo varios ejemplos con la misma forma —se lee como datos estructurados en lugar de prosa que resumir.
Convertir documentos para RAG
Los equipos que construyen pipelines de generación aumentada por recuperación (RAG) convierten habitualmente documentos fuente —archivos Word, páginas de Confluence o Google Docs, HTML extraído mediante scraping— a Markdown antes de fragmentarlos y generar sus embeddings. Esa conversión merece la pena por dos motivos. Primero, Markdown conserva la señal estructural (encabezados, listas, tablas) que produce límites de fragmento buenos y coherentes —un encabezado es un lugar natural para empezar un nuevo fragmento. Segundo, elimina el ruido visual: estilos en línea, nombres de clase, atributos de seguimiento y marcado de maquetación que inflan el número de tokens sin añadir ningún significado que un sistema de recuperación o un modelo puedan aprovechar.
Si estás construyendo un pipeline como este, HTML a Markdown y Word a Markdown se encargan exactamente de ese primer paso de conversión, totalmente en tu navegador —útil cuando los documentos fuente no deberían salir de tu equipo antes de indexarlos.
¿Qué es llms.txt?
llms.txt es una convención propuesta —inspirada en el ya consolidado robots.txt— para un archivo Markdown plano publicado en la raíz de un sitio que enumera sus páginas y documentos más importantes en un formato breve y estructurado. Mientras que robots.txt le indica a los rastreadores qué pueden indexar, llms.txt está pensado para los modelos de lenguaje y los agentes de IA que hacen recuperación en el momento de la inferencia: es un mapa curado del contenido de un sitio, escrito en el formato que esos modelos ya interpretan mejor.
MarkdownLab publica su propio llms.txt precisamente por este motivo —un índice en texto plano de las herramientas y páginas de referencia de este sitio, actualizado a medida que crece el conjunto de herramientas.
Patrones prácticos
- Usa encabezados para establecer jerarquía tanto en prompts como en documentos que quieras que un modelo razone sección por sección.
- Prefiere una tabla Markdown real en lugar de arte ASCII alineado a mano para datos tabulares —se analiza limpiamente y ocupa menos tokens.
- Etiqueta siempre los bloques de código con un lenguaje (
```python,```json) —no cuesta nada extra y le da al modelo una pista explícita sobre la sintaxis del contenido. - Evita las listas muy anidadas en la medida de lo posible; algunos analizadores y pipelines de procesamiento de prompts aplanan la anidación más allá de uno o dos niveles.
- Usa sintaxis de enlace explícita (
[text](url)) en lugar de una URL suelta cuando el propio texto del enlace tenga un significado que quieras conservar.
Hacia dónde ir ahora
¿Eres nuevo en la sintaxis? Empieza por Qué es Markdown o la hoja de referencia de Markdowncompleta. ¿Listo para escribir? Abre el editor y pruébalo en vivo.