Por que os LLMs usam Markdown por padrão
Peça ao ChatGPT, ao Claude ou a quase qualquer outro modelo conversacional uma resposta estruturada, e ele vai formatá-la em Markdown por padrão — títulos, texto em negrito, passos numerados, blocos de código. Isso não é acidente. O Markdown sinaliza estrutura com pouquíssimos caracteres extras: um título custa uma # e um espaço; um item de lista custa um - e um espaço. O equivalente em HTML —<h2>, </h2>, <li>, </li>— gasta muito mais tokens para dizer a mesma coisa, e em escala cada token extra representa custo e latência.
O Markdown também está extremamente bem representado no texto usado para treinar esses modelos. READMEs do GitHub, respostas do Stack Overflow, documentação técnica e inúmeros posts de fórum o utilizam, então os modelos já viram um número enorme de exemplos de como títulos, listas e blocos de código correspondem a uma estrutura real. Essa familiaridade torna o Markdown uma sintaxe que os modelos conseguem tanto gerar de forma confiável quanto interpretar sem ambiguidade a partir do próprio texto (ou do texto de um usuário).
Markdown em prompts
Essa mesma clareza estrutural ajuda também na entrada, não só na saída. Um prompt dividido em seções claramente identificadas — digamos um título ## Context e um título ## Task e um título ## Constraints — dá ao modelo um mapa explícito do propósito de cada parte do prompt, em vez de deixá-lo inferir isso a partir de um único parágrafo indiferenciado.
- Use uma lista com marcadores ou numerada para instruções que você quer que sejam seguidas ponto a ponto — os modelos tendem a tratar os itens da lista individualmente em vez de misturá-los.
- Envolva qualquer código, saída de log ou texto que o modelo deva tratar como literal (sem reescrever ou resumir) em um bloco de código. A cerca de três crases é um limite inequívoco que a maioria dos modelos respeita.
- Use uma tabela quando estiver dando ao modelo vários exemplos com a mesma estrutura — ela é lida como dados estruturados, não como texto a ser resumido.
Convertendo documentos para RAG
Equipes que constroem pipelines de geração aumentada por recuperação (RAG) costumam converter documentos de origem — arquivos do Word, páginas do Confluence ou Google Docs, HTML obtido por scraping — para Markdown antes de dividi-los em blocos e gerar embeddings. Duas coisas tornam essa conversão vantajosa. Primeiro, o Markdown preserva o sinal estrutural (títulos, listas, tabelas) que produz limites de bloco bons e coerentes — um título é um lugar natural para começar um novo bloco. Segundo, ele elimina o ruído visual: estilos inline, nomes de classe, atributos de rastreamento e marcação de layout que inflam a contagem de tokens sem acrescentar nenhum significado que um sistema de recuperação ou um modelo possam usar.
Se você está construindo um pipeline assim, HTML para Markdown e Word para Markdown cuidam exatamente dessa primeira etapa de conversão, inteiramente no seu navegador — útil quando os documentos de origem não devem sair da sua máquina antes de serem indexados.
O que é o llms.txt?
llms.txt é uma convenção proposta — inspirada no já consolidado robots.txt— para um arquivo Markdown simples publicado na raiz de um site, que lista suas páginas e documentos mais importantes em um formato curto e estruturado. Enquanto o robots.txt diz aos rastreadores o que eles podem indexar, o llms.txt é voltado a modelos de linguagem e agentes de IA que fazem recuperação em tempo de inferência: é um mapa curado do conteúdo de um site, escrito no formato que esses modelos já interpretam melhor.
O MarkdownLab publica seu próprio llms.txt exatamente por esse motivo — um índice em texto simples das ferramentas e páginas de referência deste site, mantido atualizado à medida que o conjunto de ferramentas cresce.
Padrões práticos
- Use títulos para estabelecer hierarquia tanto em prompts quanto em documentos que você quer que um modelo analise seção por seção.
- Prefira uma tabela Markdown de verdade a arte ASCII alinhada manualmente para dados tabulares — ela é interpretada de forma limpa e usa menos tokens.
- Sempre marque blocos de código com uma linguagem (
```python,```json) — isso não custa nada extra e dá ao modelo uma dica explícita sobre a sintaxe do conteúdo. - Evite listas profundamente aninhadas sempre que possível; alguns analisadores e pipelines de processamento de prompts achatam o aninhamento além de um ou dois níveis.
- Use sintaxe de link explícita (
[text](url)) em vez de uma URL solta quando o próprio texto do link carregar um significado que você queira preservar.
Para onde ir a seguir
Novo na sintaxe em si? Comece pelo O que é Markdown ou pelo Cheat Sheet de Markdowncompleto. Pronto para escrever? Abra o editor e experimente ao vivo.