Como fazer chunking do conteúdo para que agentes de IA o leiam melhor
Aprofundamento CEVIU
Aprofundamento
O texto de Tom Johnson, publicado em 31 de outubro de 2026, parte de uma distinção prática. Há duas formas de um agente ler a sua documentação. Em tempo de execução, ele busca a página e lê o conteúdo inteiro (até um limite de truncamento). Já num servidor MCP ou outro sistema de retrieval, ele costuma ver só os chunks, trechos que um chunker separou quando o índice foi montado. O MCP em si não ingere nada: é um protocolo, e o parsing e o chunking acontecem na construção ou atualização do índice.
No exemplo do Agent Search, do Google Cloud, o limite é medido em tokens, com padrão e máximo de 500. O Google estima que 100 tokens equivalem a 60 a 80 palavras em inglês, ou seja, cerca de 300 a 400 palavras de prosa por chunk. Código, URLs e tabelas gastam mais tokens por palavra. Os títulos de ancestrais só entram no chunk se a configuração for ligada, e só o layout parser detecta headings. A recomendação é manter seções abaixo do limite, usar headings específicos ("Limitações conhecidas do cache offline" em vez de "Limitações conhecidas"), usar tags reais de heading e evitar h4 a h6. Tabelas longas perdem o cabeçalho se o chunker não o repetir, então o autor sugere quebrá-las em tabelas menores sob h3 específicos. No caso do Google Maps Platform Capabilities Explorer, a página com 345 capacidades tem cerca de 111 mil caracteres em Markdown, mais que o dobro do limite de 50 mil da Agent-Friendly Documentation Spec. O autor criou cinco páginas por categoria e manteve a página longa com um aviso no topo.
O que mudou
O CEVIU já vinha tratando do tema por outros ângulos. Em 13 de abril de 2026, publicou "Agentic Engine Optimization (AEO): Otimizando a Documentação para Agentes de IA", que alertava para sites com muitos tokens e mal estruturados. Em 28 de abril de 2026, "As 7 melhores práticas de AEO usadas na HubSpot" defendia conteúdo mais específico e estruturado, com a resposta primeiro. Em 6 de maio de 2026, "Construa Sites Amigáveis para Agentes de IA: As Diretrizes do Google" falava de HTML semântico, e em 27 de maio de 2026, "Como Preparar Seu Site para Agentes de IA" tratava da camada da página. A novidade agora é descer ao nível do trecho: o que acontece com uma seção quando o índice a corta em pedaços de 500 tokens.
Por que isso importa
Para quem produz conteúdo de marca, documentação ou páginas de produto que serão lidas por agentes, a unidade de otimização deixa de ser a página e passa a ser a seção. Isso significa revisar headings genéricos, evitar parágrafos que dependem do anterior para fazer sentido e checar como o seu sistema de retrieval realmente divide o texto. É uma leitura editorial, mas o ganho é mensurável: dá para testar os chunks resultantes antes de publicar.
Linha do tempo
CEVIU publica o texto sobre Agentic Engine Optimization (AEO) e documentação para agentes de IA.
CEVIU publica as 7 melhores práticas de AEO usadas na HubSpot.
CEVIU cobre as diretrizes do Google para sites amigáveis a agentes de IA.
CEVIU publica o guia sobre como preparar o site para agentes de IA.
CEVIU explica como fazer chunking do conteúdo para agentes de IA lerem melhor.
Perguntas frequentes
O que é chunking de conteúdo?
É a divisão de uma página em trechos menores, chamados chunks, quando o índice de um sistema de retrieval é montado. O agente costuma ver esses trechos, e não a página inteira. Por isso, cada seção precisa fazer sentido sozinha.
Qual o tamanho ideal de uma seção?
Depende do seu sistema. No Agent Search, do Google, o padrão e o máximo são 500 tokens, algo como 300 a 400 palavras em inglês. Seções com muito código ou tabela comportam menos palavras, e convém deixar folga caso o pipeline acrescente título e headings ao chunk.
Por que headings específicos ajudam os agentes?
Um chunk pode chegar ao agente só com o título da página e a URL como contexto. "Limitações conhecidas" serviria para qualquer página, enquanto "Limitações conhecidas do cache offline" diz o que o trecho é. Também é preciso usar tags reais de heading, pois estilos CSS somem na conversão para Markdown.
Como lidar com tabelas longas?
Se o chunker não repetir a linha de cabeçalho, os chunks seguintes trazem valores sem nome de coluna e o agente pode errar. A sugestão é dividir a tabela em tabelas menores sob h3 específicos, cada uma com seu cabeçalho. Em casos extremos, cada item pode ganhar uma seção própria.
Fontes
- idratherbewriting.comfonte original
- Categoria
- CEVIU Marketing
- Publicado
- 02 de novembro de 2026
- Editoria
- CEVIU Marketing

