Chunking: segmentação de conteúdo em passagens

TL;DR — Chunking é a forma como mecanismos de busca com IA cortam sua página em partes menores antes de armazená-la e pesquisá-la. Eles não comparam uma consulta com a página inteira — comparam com a passagem única que melhor responde a ela. Portanto, ser indexado não basta; você precisa de uma seção que faça sentido por si só e responda claramente à pergunta.

O que é chunking

Chunking divide documentos em unidades menores para sistemas de embeddings e recuperação. Evidence for this claim Retrieval systems can split files into chunks that are embedded and indexed for later search. Scope: OpenAI's retrieval implementation; chunk sizes, overlap, and indexing behavior are implementation-dependent. Confidence: high · Verified: 2026-07-14 OpenAI: Retrieval guide O tamanho dos chunks e a sobreposição são escolhas de implementação cujos melhores valores dependem do conteúdo, do modelo e da tarefa de avaliação. Evidence for this claim Retrieval-augmented generation combines a generator with retrieved external passages or documents. Scope: The original RAG research architecture; it does not establish one optimal chunking strategy for every production system. Confidence: high · Verified: 2026-07-14 Lewis et al.: Retrieval-Augmented Generation

Quando você pesquisava no Google do jeito antigo, a unidade era a página: uma página ranqueava e você clicava nela. Os sistemas de IA funcionam de outra forma. Antes que ChatGPT, Perplexity ou AI Overviews do Google possam usar seu conteúdo, eles o dividem em segmentos menores — chamados chunks ou passagens — e armazenam cada um separadamente. Quando alguém faz uma pergunta, o sistema encontra os chunks que melhor correspondem a ela e então escreve uma resposta a partir deles.

Portanto, a unidade de recuperação não é sua página. É uma passagem da sua página.

Por que eles fazem isso

Por dois motivos:

1. Limites de tamanho. Os modelos que transformam texto em matemática pesquisável (veja embeddings) só conseguem receber uma quantidade limitada de texto por vez. Uma página de 5 000 palavras não cabe, então é dividida.
2. Precisão. Uma página inteira sobre “SEO técnico” é uma correspondência vaga para uma pergunta específica como “o que é crawl budget”. Uma seção focada de 400 palavras dedicada apenas a crawl budget é uma correspondência precisa. Partes menores permitem que o sistema encontre a agulha, em vez de entregar o palheiro inteiro.

O que isso significa para você

Você não controla como cada sistema de IA divide seu conteúdo — e não precisa controlar. O que pode fazer é escrever de forma que cada seção continue funcionando quando for extraída sozinha:

• Coloque a resposta primeiro. Comece uma seção com a definição ou a afirmação principal, não com três parágrafos de introdução.
• Mantenha as seções focadas. Um tópico ou uma pergunta por heading.
• Faça cada seção ser autossuficiente. Pergunte a si mesmo: se alguém lesse apenas este parágrafo, sem nada ao redor, ele ainda faria sentido?

Boa notícia: isto é apenas escrita clara. O Google afirma diretamente que você não precisa dividir seu conteúdo em partes minúsculas para a IA — os próprios sistemas fazem a divisão. A versão avançada aborda tamanho de chunk, sobreposição, a pesquisa e como tudo isso se conecta ao “passage ranking” do Google.

TL;DR — Chunking é a etapa de pré-processamento que divide um documento em passagens antes que elas sejam transformadas em embeddings, indexadas e recuperadas. Ele existe porque modelos de embeddings e janelas de contexto têm limites de tokens, e porque a recuperação no nível da passagem é mais precisa que no nível da página. O chunk, não a página, é a unidade de recuperação. O tamanho do chunk é uma troca (pequeno = preciso/sem contexto suficiente; grande = rico/ruidoso), e nenhum tamanho, valor de sobreposição ou divisor garante uma citação; a sobreposição protege as fronteiras, mas aumenta o índice e duplica conteúdo; chunking semântico não é confiavelmente melhor que tamanho fixo; prefixos contextuais podem desambiguar um chunk, mas induzem a recuperação ao erro quando estão desatualizados. “Lost in the Middle” — um efeito de posição documentado em modelos e tarefas específicos de 2023 — significa que um LLM costuma usar melhor o início e o fim do contexto. Você não pode otimizar para um tamanho específico de chunk — e o Google diz que não deve tentar —, mas seções autossuficientes, com a resposta primeiro e sob uma hierarquia clara de headings, são divididas e citadas com facilidade. É o mesmo princípio de subdocumento do passage ranking do Google, aplicado a RAG.

O que é chunking e por que ele existe

Os sistemas de recuperação operam sobre unidades indexadas, mas os mecanismos de busca públicos não expõem um tamanho universal de chunk controlado pelo editor. Evidence for this claim Retrieval systems can split files into chunks that are embedded and indexed for later search. Scope: OpenAI's retrieval implementation; chunk sizes, overlap, and indexing behavior are implementation-dependent. Confidence: high · Verified: 2026-07-14 OpenAI: Retrieval guide A pesquisa sobre RAG apoia padrões de recuperar e depois gerar sem provar que todo produto de busca com IA usa mecânicas idênticas. Evidence for this claim Retrieval-augmented generation combines a generator with retrieved external passages or documents. Scope: The original RAG research architecture; it does not establish one optimal chunking strategy for every production system. Confidence: high · Verified: 2026-07-14 Lewis et al.: Retrieval-Augmented Generation

Chunking é o processo de dividir um documento em segmentos menores e discretos — chunks ou passagens — antes que esses segmentos sejam transformados em embeddings, armazenados em um índice vetorial e recuperados para responder a consultas. É uma etapa fundamental em pipelines de RAG (Retrieval-Augmented Generation) e é a parte da busca com IA que profissionais de SEO mais subestimam, porque é invisível: acontece durante a ingestão, não no momento da consulta.

Dois problemas tornam essa etapa necessária:

• O problema do limite de tokens. Modelos de embeddings aceitam uma quantidade limitada de tokens por entrada — a Microsoft informa que o modelo text-embedding-3-small limita a entrada a 8 191 tokens, e outros modelos são muito menores. LLMs também têm janelas de contexto finitas. Uma página longa simplesmente não cabe como uma unidade única, então é dividida.
• O problema da precisão da recuperação. Uma página de 5 000 palavras sobre “SEO técnico” condensada em um vetor é um sinal difuso e médio. Uma seção de 400 palavras especificamente sobre crawl budget, incorporada como seu próprio vetor, é um sinal nítido. A granularidade de subdocumento permite que o sistema retire uma passagem relevante de uma página longa e com vários tópicos.

A consequência é a ideia mais importante daqui: o chunk, não a página, é a unidade de recuperação na busca com IA. Ser rastreado e indexado é necessário, mas não suficiente. Você precisa de um chunk que responda claramente a uma consulta específica por si só. Uma página que ranqueia organicamente em #15 pode ganhar uma citação de IA enquanto o resultado em #1 é ignorado — se a página em #15 tiver a passagem mais fácil de extrair.

Como o chunking funciona, do início ao fim

1. Ingestão + divisão. Um crawler de IA baixa a página; um algoritmo de chunking divide o texto em segmentos (geralmente sobrepostos).
2. Embedding. Cada chunk vira um vetor numérico e é armazenado em um índice vetorial. (Essa é a etapa de embeddings.)
3. Recuperação + geração. Uma consulta vira um embedding, os vetores de chunks mais próximos são obtidos por meio de busca vetorial e os chunks recuperados são enviados a um LLM que escreve a resposta com citações.

Essa arquitetura inteira remonta ao Dense Passage Retrieval (Karpukhin et al., 2020), que mostrou que recuperar por similaridade vetorial densa superou a abordagem antiga por palavras-chave (BM25) em 9–19% absolutos na precisão das 20 primeiras passagens — e que a recuperação no nível da passagem funciona melhor que no nível do documento para responder a perguntas específicas. O artigo de RAG (Lewis et al., 2020) deu nome ao padrão e usou passagens de 100 palavras da Wikipédia como chunks. Todo sistema de busca com IA que recupera conteúdo da web executa uma variante desse pipeline.

Estratégias de chunking

Não existe um único algoritmo — os sistemas escolhem em um menu e mudam essa escolha ao longo do tempo:

• Tamanho fixo — divide por uma contagem de tokens ou caracteres, com alguma sobreposição. É o mais comum. Exemplo da Microsoft: “a fixed size sufficient for semantically meaningful paragraphs (for example, 200 words or 600 characters)” com 10–15% de sobreposição.
• Sentença / parágrafo — divide em limites da linguagem natural, em vez de uma contagem arbitrária de tokens, preservando unidades semânticas.
• Semântico / orientado ao conteúdo — agrupa sentenças por similaridade de embeddings e divide onde o tópico muda, buscando manter cada chunk sobre uma única coisa.
• Hierárquico / recursivo (RAPTOR) — constrói uma árvore de resumos (documento → seção → parágrafo) para que uma consulta seja respondida no nível correto de abstração. O RAPTOR (Sarthi et al., 2024) relatou um ganho de 20% absolutos de precisão em um benchmark difícil de QA quando combinado com GPT-4.
• Janela deslizante com sobreposição — cada chunk compartilha alguns tokens com os vizinhos para que uma frase dividida na fronteira não se perca.
• Adaptativo / dependente da consulta (Mix-of-Granularity) — um roteador treinado escolhe o tamanho do chunk por consulta. É a abordagem mais sofisticada; ainda não é padrão nos sistemas comerciais.

Tamanho e sobreposição do chunk — a troca central

Esta é a alavanca sobre a qual todos perguntam, e a resposta honesta é depende:

• Chunks pequenos (128–256 tokens): recuperação mais precisa, mas podem perder o contexto ao redor de que a resposta precisa.
• Chunks grandes (512–1 024 tokens): preservam mais contexto, mas tornam a recuperação mais ruidosa — você traz material irrelevante junto do trecho relevante.

A pesquisa não coroa um vencedor. A avaliação da LlamaIndex encontrou 1 024 tokens como ótimo em sua configuração; os benchmarks da Chroma descobriram que um divisor recursivo de 200 tokens teve desempenho consistente entre as métricas. A conclusão de Ravi Theja é a mentalidade certa: “Identifying the best chunk size for a RAG system is as much about intuition as it is empirical evidence.” Esses números descrevem o vencedor em um benchmark de uma equipe, com um conjunto de documentos, um modelo de embeddings e uma tarefa de avaliação — não uma configuração universal. Nenhum tamanho de chunk, valor de sobreposição ou divisor garante recuperação, citação, ranking ou inclusão em uma resposta de um sistema de IA externo; cada provedor escolhe seus próprios padrões no pipeline e pode alterá-los sem aviso.

Sobreposição é a metade subestimada disso. Sem ela, o conteúdo próximo de uma fronteira é dividido e perdido. A Microsoft recomenda começar com 25% de sobreposição para obter “smoother transitions between chunks without excessive duplication”; outras fontes sugerem 10–15%. A sobreposição não é gratuita: os tokens sobrepostos são incorporados e armazenados duas vezes, o que aumenta o índice e pode fazer passagens quase duplicadas aparecerem lado a lado no conjunto recuperado — portanto é uma troca contra o tamanho do índice e a redundância, não uma rede de segurança sem custo. Pese-a conforme a frequência com que uma fronteira realmente faz você perder um fato, não por princípio. O ponto prático para o conteúdo: não presuma que o sistema manterá um fato importante intacto se você o esconder exatamente onde um chunk tende a se partir.

Então chunking semântico sempre vence? Não — esta é a conclusão inconveniente. O estudo de 2024 da Vectara descobriu que “performance differences are minimal” em documentos reais e — crucialmente — a qualidade do modelo de embeddings importou mais que a estratégia de chunking. Quando o GPT-4o gerou as respostas, as diferenças entre as estratégias foram “negligible.” Esse resultado é específico ao conjunto de documentos, aos modelos e ao método de avaliação da Vectara — é evidência de que chunking semântico não é uma vitória padrão confiável, não prova de que nunca ajuda em qualquer pipeline. Tradução para profissionais de SEO: preocupar-se obsessivamente com uma estrutura exata importa muito menos que qualidade de conteúdo e clareza semântica.

Contexto do chunk: o que prefixos podem (e não podem) corrigir

Um chunk que é claro para um humano ainda pode ser mal recuperado quando separado do documento ao redor — da seção sob a qual está, da entidade à qual realmente se refere ou de uma qualificação declarada dois headings acima. Uma mitigação documentada é acrescentar, antes do chunk ser incorporado, uma string curta de contexto específica para ele (o título do documento, a seção à qual pertence e o assunto real do chunk) — uma abordagem que a Anthropic chama de contextual retrieval. Título, ancestralidade da seção e um prefixo contextual podem desambiguar um chunk que de outra forma ficaria órfão e reduzir falhas de recuperação causadas pela falta de contexto.

Essa correção também tem seu próprio modo de falha: contexto antigo ou errado não apenas deixa de ajudar — ele induz ativamente o recuperador ao chunk errado. Um prefixo gerado a partir de um heading que deixou de corresponder à seção depois de uma reorganização da página, ou um resumo contextual que descreve incorretamente o que o chunk cobre, é pior que não ter prefixo. Preservar contexto é uma escolha de projeto do pipeline com seu próprio modo de erro, não uma melhoria unilateral que você instala e esquece.

Passage ranking do Google — o ancestral SEO do chunking

O Google trabalha com granularidade de subdocumento desde muito antes de “RAG” virar moda. No Search On 2020, Prabhakar Raghavan anunciou o passage ranking: “By better understanding the relevancy of specific passages, not just the overall page, we can find that needle-in-a-haystack information you’re looking for.” Ele entrou em produção em inglês dos EUA em 10 de fevereiro de 2021 e afeta aproximadamente 7% das consultas.

Duas coisas que as pessoas entendem errado:

• É “passage ranking”, não “passage indexing”. O primeiro anúncio do Google usou “indexing” e depois corrigiu rapidamente: “this change doesn’t mean we’re indexing individual passages independently of pages.” A página ainda é indexada como um todo; a passagem relevante é um sinal adicional de ranking.
• A página ranqueia, não a passagem. John Mueller: “Passage ranking is not about ranking a specific passage but understanding the content on a really long, not SEO optimized page, and ranking that page (not the passage) for a query where the passage is relevant.”

Portanto, passage ranking e chunking de RAG compartilham um princípio — um parágrafo, não uma página, costuma ser a unidade certa para comparar com uma consulta específica —, mas o resultado é diferente: passage ranking eleva o ranking da página; chunking de RAG recupera um chunk para alimentar uma resposta gerada. Mesma ideia, mecânica diferente. (A base técnica, segundo a reportagem de Dawn Anderson, é o DeepCT — pesos contextuais de termos derivados de BERT que substituem TF-IDF, de modo que frequência de termos não equivale mais a relevância.)

“Lost in the Middle” — a posição da resposta importa

Mesmo depois que seu chunk é recuperado, onde ele cai no contexto do LLM afeta se o modelo realmente o usa. O estudo “Lost in the Middle” de Stanford (Liu et al., 2023) descobriu que “performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts.”

Essa descoberta não se aplica universalmente por padrão — é um efeito de posição medido em tarefas nomeadas de QA com vários documentos e de recuperação de chave-valor, no conjunto específico de modelos que Liu et al. testaram em 2023. Não prova que todo modelo atual ignora evidências colocadas no centro do contexto; arquiteturas diferentes, janelas de contexto efetivas maiores e treinamento mais recente podem reduzir ou ampliar o efeito. Trate-o como um risco documentado para orientar o projeto, não como uma lei fixa de todo modelo no qual você algum dia será recuperado.

A implicação para o conteúdo continua concreta e de baixo risco: comece com sua resposta. Coloque a definição, a descoberta principal ou a resposta direta na primeira frase de cada seção — não escondida no quarto parágrafo. É a mesma disciplina answer-first (BLUF) que ajuda quem lê por varredura; por acaso, ela também reduz o risco de seu ponto cair no meio de uma janela de contexto em modelos nos quais o efeito existe.

As restrições práticas que você não consegue ver

• Limite de cerca de 30 passagens do Chrome. A pesquisa de Dan Petrovic sugere que o DocumentChunker do Chrome analisa o conteúdo em passagens de cerca de 200 palavras e “only ever considers the first 30 passages of a page.” Ele percorre o HTML semântico de cima para baixo. Implicação: seu conteúdo mais importante deve aparecer cedo — não no fim de uma página de 10 000 palavras.
• Você não controla o chunker. Despina Gavoyannis (Ahrefs) é direta: “You can’t control how Google, ChatGPT, or Perplexity chunk your content. Their pipelines change based on cost, model, and context.” E: “Manual ‘chunk optimization’ is impossible in practice.”

O que é “otimização de chunk” de verdade (e a ressalva do Google)

Aqui está a nuance que o hype deixa de fora. O guia de otimização para IA do Google de 2026 afirma claramente: “There’s no requirement to break your content into tiny pieces for AI to better understand it.” Seus sistemas “are able to understand the nuance of multiple topics on a page and show the relevant piece to users.” Portanto, não — não reescreva seu conteúdo em blocos rígidos de 300 palavras.

Mas isso não significa que a estrutura seja irrelevante. Como Gavoyannis diz, “Most SEOs using the term [chunk optimization] are just talking about good content structure.” O conselho por baixo do buzzword é sólido; o enquadramento apenas exagera sua novidade. A frase de Duane Forrester resume bem a mudança: “If traditional SEO optimized for clicks, GenAI systems optimize for chunks… Structure still wins.”

Então o que você realmente faz? Escreve conteúdo pronto para chunking:

• Um tópico por seção. Um H2/H3 focado mapeia de forma limpa para um chunk coerente.
• Resposta primeiro. Apresente a afirmação e depois dê suporte a ela.
• Seções autossuficientes. Teste: este parágrafo faria sentido se aparecesse isolado? Se não, não sobreviverá quando for extraído.
• Comprimento apropriado. 200–500 palavras por seção principal se alinham naturalmente a chunks de 256–512 tokens — completos o bastante para serem úteis, não artificialmente curtos.
• Formatos estruturados. Tabelas e listas dão aos sistemas limites explícitos para detectar. (A pesquisa da Onely: tabelas aumentam as taxas de citação em cerca de 2,5x.)

O enquadramento de Mike King é a tranquilização certa: “chunking and writing for users is not mutually exclusive.” A estrutura que ajuda o leitor a fazer uma leitura rápida é a estrutura que vira chunks de forma limpa. Você não está otimizando para um robô às custas de um humano — é o mesmo conteúdo.

Passage ranking versus chunking de RAG — lado a lado

Onde isso se encaixa no pipeline

Chunking é o primeiro movimento da recuperação com IA: chunk → embed → store → retrieve → generate. Ele alimenta embeddings (cada chunk vira um vetor), que alimentam a busca vetorial (a consulta encontra os chunks mais próximos), que alimenta o RAG (os chunks recuperados viram uma resposta). Acima disso, crawlers de IA são como seu conteúdo é ingerido em primeiro lugar. Para a versão desse pipeline na busca tradicional, consulte How Search Works.

Resumo de IA

Uma síntese da versão Advanced:

• Chunking = dividir um documento em passagens antes que elas sejam transformadas em embeddings, indexadas e recuperadas. É a primeira etapa de um pipeline RAG e ocorre na ingestão, não no momento da consulta.
• O chunk, não a página, é a unidade de recuperação. Ser indexado não basta; você precisa de uma passagem que responda por si só a uma consulta específica. Uma página em #15 pode ser citada no lugar de uma em #1 se sua passagem for mais fácil de extrair.
• Por que existe: modelos de embeddings e janelas de contexto têm limites de tokens, e a recuperação no nível da passagem é mais precisa que no nível da página.
• O tamanho do chunk é uma troca: pequeno (128–256 tokens) = preciso, mas com pouco contexto; grande (512–1 024) = rico, mas ruidoso. Não há um melhor universal — LlamaIndex encontrou 1 024 como ótimo e Chroma encontrou 200 —, e nenhum tamanho de chunk ou divisor garante uma citação. Sobreposição (10–25%) protege as fronteiras, mas duplica tokens e aumenta o índice; pese-a contra perdas reais nas fronteiras.
• Chunking semântico não é confiavelmente melhor que tamanho fixo (Vectara 2024, nos modelos/documentos daquele estudo) — a qualidade do modelo de embeddings importa mais que a estratégia de chunking.
• Prefixos contextuais (títulos, ancestralidade da seção — o “contextual retrieval” da Anthropic) podem desambiguar um chunk órfão, mas um prefixo antigo ou errado induz ativamente a recuperação ao erro; é uma escolha de projeto com seu próprio modo de falha.
• “Lost in the Middle” (Liu et al., 2023): um efeito de posição medido em tarefas nomeadas e modelos da era de 2023, não uma prova de que todo modelo atual ignora o contexto central — os LLMs daquele estudo usaram melhor o início e o fim do contexto, então comece cada seção com a resposta de qualquer forma.
• Passage ranking do Google (2020/2021, cerca de 7% das consultas) é o mesmo princípio de subdocumento — mas é um sinal que ranqueia a página, não uma indexação separada de passagens. Chunking de RAG recupera um chunk.
• Você não pode otimizar para um tamanho de chunk, e o Google diz que não é preciso cortar conteúdo em partes minúsculas. Você pode escrever seções focadas, autossuficientes e com a resposta primeiro, sob headings claros — o que é simplesmente boa estrutura.

Documentação oficial

Documentação de fonte primária sobre recuperação no nível da passagem e chunking.

Google

• A Guide to Google Search Ranking Systems — define passage ranking como “an AI system we use to identify individual sections or ‘passages’ of a web page.”
• Optimizing your website for generative AI features — a posição do Google de que não é preciso dividir o conteúdo em partes minúsculas (última atualização em 15 de junho de 2026).
• In-Depth Guide to How Google Search Works — o pipeline rastrear → indexar → exibir que esta versão de IA amplia.

Microsoft / Azure AI Search

• Chunk large documents for vector search — o guia oficial de chunking mais completo entre os grandes provedores: padrões de tamanho (512 tokens), sobreposição (ponto de partida de 25%) e a tabela de técnicas fixas/variáveis/semânticas (última atualização em 8 de junho de 2026).

OpenSearch

• Text chunking — chunking como recurso integrado do pipeline de ingestão de busca vetorial.

Referência prática (documentação de fornecedores)

• Pinecone — Chunking Strategies — a taxonomia canônica de estratégias, com o teste que ancora tudo: “If the chunk of text makes sense without the surrounding context to a human, it will make sense to the language model as well.”

Citações da fonte

Declarações registradas do Google. Cada link é um deep link que salta para a passagem citada na página de origem.

Google — o que o passage ranking é (e não é)

• “By better understanding the relevancy of specific passages, not just the overall page, we can find that needle-in-a-haystack information you’re looking for.” — Prabhakar Raghavan, vice-presidente sênior do Google, outubro de 2020 (via Search Engine Land). Ir para a citação
• “this change doesn’t mean we’re indexing individual passages independently of pages.” — Google, esclarecimento de 20 de outubro de 2020 (via Search Engine Land). Ir para a citação
• “passage ranking launched yesterday afternoon Pacific Time for queries in the US in English.” — @searchliaison, 11 de fevereiro de 2021 (via Search Engine Land). Ler a cobertura

Google — o passage ranking ranqueia a página, não a passagem

• “Passage ranking is not about ranking a specific passage but understanding the content on a really long, not SEO optimized page, and ranking that page (not the passage) for a query where the passage is relevant.” — John Mueller, Search Advocate do Google (via Search Engine Roundtable). Ler a cobertura

Google — sobre você dever dividir seu conteúdo em chunks

• “There’s no requirement to break your content into tiny pieces for AI to better understand it.” — Google Search Central, “Optimizing your website for generative AI features”. Ler o guia

Microsoft Azure AI Search — por que chunking é necessário

• “Partitioning large documents into smaller chunks can help you stay under the maximum token input limits of chat completion and embedding models.” — documentação do Microsoft Azure AI Search. Ler a documentação

Chunking — folha de consulta rápida

As estratégias de chunking, comparadas

Tamanho do chunk, de relance

Fatos rápidos

• O chunk, não a página, é a unidade de recuperação na busca com IA.
• Exemplo de limite de modelo de embeddings: text-embedding-3-small = 8 191 tokens.
• Nenhum tamanho de chunk, valor de sobreposição ou divisor garante recuperação, citação ou inclusão em uma resposta de IA — são padrões de pipeline, não configurações universais.
• Sobreposição não é gratuita: os tokens sobrepostos são armazenados duas vezes, aumentando o índice e criando risco de passagens recuperadas quase duplicadas.
• Prefixos contextuais (título, ancestralidade da seção) podem desambiguar um chunk — mas um prefixo antigo ou errado induz a recuperação ao erro em vez de ajudar.
• “Lost in the Middle”: nas tarefas e modelos do estudo de 2023, os LLMs usaram melhor o início e o fim do contexto → comece pela resposta independentemente do modelo.
• O DocumentChunker do Chrome supostamente considera apenas as primeiras cerca de 30 passagens (cerca de 200 palavras cada) → coloque o conteúdo principal cedo.
• Google: passage ranking ≠ passage indexing. A página ranqueia; a passagem é um sinal.
• Google: não é preciso cortar o conteúdo em partes minúsculas. Estruture, não fragmente.

Os modelos mentais

1. O pipeline de recuperação — chunk → embed → store → retrieve → generate. Chunking é o primeiro movimento. Se seu conteúdo não está sendo citado, percorra a cadeia: ele foi rastreado? um chunk coerente foi produzido? esse chunk correspondeu à consulta? ele caiu em uma posição na qual o LLM o usaria?

2. O chunk é a unidade, não a página. Pare de pensar “minha página está indexada?” e comece a pensar “minha página contém uma passagem que responde por si só a esta consulta específica?”. A indexação é necessária; a facilidade de extração é o que conquista a citação.

3. A troca de tamanho — precisão versus contexto. Chunks pequenos = nítidos, mas finos. Chunks grandes = ricos, mas ruidosos. Não existe uma resposta universal, e você também não define o tamanho — então otimize aquilo que controla: faça cada seção ser coerente o bastante para funcionar em qualquer granularidade.

4. Resposta primeiro vence o meio. “Lost in the Middle” diz que a posição dentro da janela de contexto importa. Comece cada seção com a definição ou a afirmação principal. A mesma disciplina que ajuda quem lê por varredura mantém seu ponto fora da zona morta.

5. Estruture, não fragmente. O Google diz para não cortar o conteúdo em partes minúsculas — portanto, a solução não é chunking artificial. É uma hierarquia clara de headings, um tópico por seção e parágrafos autossuficientes. “Otimização de chunk” é em grande parte boa estrutura usando um nome novo.

6. Passage ranking ≠ chunking de RAG. Mesmo princípio (granularidade de subdocumento), resultado diferente. Passage ranking é um sinal que ranqueia a página; chunking de RAG recupera um chunk para uma resposta. Não confunda o conceito da era do SEO com o da era da IA.

Checklist de conteúdo pronto para chunking

Uma rodada para fazer seu conteúdo sobreviver a ser dividido, recuperado e citado fora de contexto:

• Cada seção H2/H3 cobre um tópico ou uma pergunta — sem seções que misturam dois assuntos.
• Cada seção começa com a resposta (definição / afirmação principal primeiro, suporte depois) — não escondida no parágrafo 3 ou 4.
• Cada seção principal é autossuficiente: faria sentido isolada, sem nada ao redor.
• As seções têm um comprimento apropriado (cerca de 200–500 palavras) — completas, não cortadas artificialmente em blocos minúsculos.
• O conteúdo mais importante aparece cedo na página (o Chrome supostamente considera apenas as primeiras cerca de 30 passagens).
• A hierarquia de headings é limpa (H1 → H2 → H3 lógico) — ela faz parte do sinal estrutural percorrido pelo chunker.
• Os fatos que precisam permanecer juntos não estão separados em uma fronteira provável (por exemplo, uma afirmação em um parágrafo e sua evidência três parágrafos depois).
• Você usou tabelas / listas quando o conteúdo é genuinamente enumerável (limites explícitos que os chunkers detectam; taxas de citação maiores).
• Você não reescreveu tudo em blocos rígidos por contagem de palavras — o Google diz que isso não é necessário.

Escrever uma seção gigante para várias intenções

Um bloco longo sobre definições, implementação, exceções e medição pode ser útil como página, mas ruidoso como passagem recuperada. Separe perguntas distintas sob headings e dê a cada seção contexto local suficiente para se sustentar sozinha.

Fragmentar cada sentença em seu próprio heading

Chunks minúsculos podem perder qualificações e relações. Não otimize para um número de tokens imaginário. Mantenha uma ideia completa, suas restrições e as evidências de suporte juntas.

Começar com uma referência sem contexto

Passagens que começam com “isso”, “ele” ou “porém” podem ser separadas do texto que nomeia o assunto. Abra seções importantes com uma frase direta que identifique o tópico e a resposta.

Duplicar texto para forçar sobreposição

Parágrafos repetidos criam passagens quase duplicadas concorrentes e uma experiência de leitura pior. Sistemas de recuperação podem adicionar sobreposição internamente; autores devem usar transições claras e seções autossuficientes em vez de copiar prosa.

Prompt: auditar a independência das passagens

Review the article section by section as if each section could be retrieved without its
neighbors. For each heading, state the question it answers, whether the opening sentence
names the subject, what context is missing, whether unrelated intents are mixed, and the
smallest edit that makes the section self-contained. Preserve necessary qualifications
and evidence. Do not target an arbitrary token count or rewrite the author's voice.

Article:
[PASTE ARTICLE WITH HEADINGS]

Prompt: dividir uma seção sobrecarregada

This section covers several ideas. Propose a minimal heading structure that groups one
complete intent per section. For each proposed section, write only an answer-first
opening sentence and list which existing paragraphs belong under it. Do not add facts,
remove caveats, duplicate prose, or turn every sentence into a heading.

Section:
[PASTE HEADING AND CONTENT]

Console do DevTools: sinalizar seções longas renderizadas

Execute isto em uma página de artigo. O limite de caracteres é um auxílio de revisão, não uma fronteira de chunk de mecanismo de busca.

console.table([...document.querySelectorAll('main h2, main h3')].map((heading, i, all) => {
  let text = '';
  for (let node = heading.nextElementSibling; node && !all.includes(node); node = node.nextElementSibling) text += ` ${node.textContent}`;
  return { heading: heading.textContent.trim(), characters: text.trim().length };
}).filter(row => row.characters > 2000));

Regex: encontrar aberturas de seção sem contexto no Markdown

Este padrão multilinha sinaliza headings cuja primeira palavra em prosa é uma referência comum a algo anterior. Revise cada ocorrência manualmente.

^#{2,4}\s+.+\n+(?:\n|>.*\n|\s*)*(This|That|It|They|These|Those|However|Therefore|Also|And|But|So|Then)\b

Ferramentas para QA de passagens

• Um outline do navegador ou mapa do documento revela rapidamente headings que combinam perguntas sem relação ou deixam longos trechos sem subtítulos.
• Um banco de dados vetorial ou playground de embeddings pode demonstrar como o tamanho do chunk afeta um teste de recuperação controlado, mas não transforme o resultado de um modelo em uma prescrição universal de SEO.
• Search Console e acompanhamento de citações medem resultados da página. Eles não conseguem informar qual chunk proprietário exato uma plataforma de busca armazenou.

Valide uma reescrita orientada por chunking

Teste seus conhecimentos: Chunking

Recursos que valem seu tempo

Meu texto relacionado

• What We Actually Know About Optimizing for LLM Search — aborda a descoberta do DocumentChunker do Chrome / 30 passagens e como a recuperação de IA realmente trata seu conteúdo.

A pesquisa fundamental

• Dense Passage Retrieval (Karpukhin et al., 2020) — por que a recuperação de passagens densas supera a correspondência por palavras-chave; a arquitetura por trás do RAG moderno.
• Retrieval-Augmented Generation (Lewis et al., 2020) — o artigo que deu nome ao RAG; usou passagens de 100 palavras da Wikipédia.
• Lost in the Middle (Liu et al., 2023) — LLMs usam melhor o início e o fim do contexto; por que começar pela resposta importa.
• RAPTOR (Sarthi et al., 2024) — chunking hierárquico/recursivo por uma árvore de resumos.
• Is Semantic Chunking Worth the Cost? (Vectara, 2024) — o estudo que descobriu que chunking semântico não é confiavelmente melhor que tamanho fixo.

O contraponto de SEO (leia isto)

• SEO Chunk Optimization is Overrated (Despina Gavoyannis, Ahrefs) — o argumento de que “otimização de chunk” é em grande parte apenas boa estrutura de conteúdo e de que você não controla como os sistemas dividem seu conteúdo. É a nuance mais importante deste tema.

Guias práticos

• Pinecone — Chunking Strategies — a taxonomia canônica de estratégias.
• LlamaIndex — Evaluating the Ideal Chunk Size (Ravi Theja) — o teste de 128/256/512/1024/2048 que chegou a 1 024.
• Databricks — Chunking Strategies for RAG — seis estratégias com orientação específica por domínio.

Do setor

• Content Chunking Guide (Search Engine Land) — aborda definição, origens em UX, tipos de chunk macro/micro/atômico e a conexão entre chunking e recuperação de IA.
• Chunk, Cite, Clarify, Build (Benu Aggarwal, Search Engine Land) — framework de conteúdo em quatro partes para busca com IA; enquadra “content now competes in a probability-weighted lottery of answer generation.”
• Content Chunking: What Is It & Should You Care? (Semrush) — visão prática com a citação de Mike King (“chunking and writing for users is not mutually exclusive”) e testes em formato de perguntas e respostas.
• Chunked, Retrieved, Synthesized (Duane Forrester) — perspectiva do ex-Bing sobre por que a estrutura vence mesmo com janelas de contexto grandes; “If traditional SEO optimized for clicks, GenAI systems optimize for chunks.”
• LLM-Friendly Content (Onely / Bartosz Góralewicz) — fonte primária da descoberta de que tabelas aumentam as taxas de citação em 2,5x e de que listicles representam 50% das principais citações de IA.
• 2025 AI Citation & LLM Visibility Report (The Digital Bloom) — dados sobre o que prevê citações de LLM; volume de busca de marca, estatísticas e citações aparecem como fatores que aumentam a visibilidade.
• The Ultimate Guide for Chunking Strategies (Agenta.ai) — taxonomia abrangente e orientada a desenvolvedores, com dados de benchmark da Chroma entre métodos de chunking.

Estatísticas que vale citar

• 9–19% absolutos — quanto a recuperação de passagens densas (DPR) superou a correspondência por palavras-chave BM25 na precisão das 20 primeiras passagens. O argumento a favor de recuperar por significado, não por palavras-chave. Karpukhin et al., 2020
• Cerca de 7% das consultas — parcela das consultas de busca afetada pelo passage ranking do Google no lançamento completo (inglês dos EUA ao vivo em 10 de fevereiro de 2021). Cobertura
• +20% absolutos de precisão — ganho do chunking hierárquico do RAPTOR em um benchmark difícil de QA quando combinado com GPT-4. Sarthi et al., 2024
• Modelo de embeddings > estratégia de chunking — descoberta da Vectara em 2024 de que a qualidade do modelo afetou mais a recuperação do que chunking semântico ou de tamanho fixo; em documentos reais, as diferenças foram “minimal.” Estudo
• Primeiras cerca de 30 passagens — número que o DocumentChunker do Chrome supostamente considera por página (cerca de 200 palavras cada), segundo a pesquisa de Dan Petrovic — argumento para colocar o conteúdo principal no começo. Via Ahrefs
• Cerca de 2,5x na taxa de citação — descoberta da Onely de que tabelas aumentam as taxas de citação de IA, com listicles representando cerca de 50% das principais citações de IA. Estrutura ajuda. Onely
• 93,67% dos Google AI Overviews citam pelo menos um resultado orgânico do top 10 — correlação forte, mas não absoluta, entre rankings orgânicos e citação de IA; uma correspondência no nível da passagem pode superar a posição no ranking. The Digital Bloom, 2025 AI Citation Report

Registro de alterações