Por que o chunk decide a citação no lugar da página
Relevance engineering é a prática de escrever e estruturar cada passagem de uma página para que ela seja recuperada, reordenada e citada por motores de resposta como ChatGPT, Gemini e o AI Mode do Google. O termo foi definido pela iPullRank, de Michael King, em 8 de maio de 2025, como a interseção entre recuperação de informação, experiência do usuário, inteligência artificial, estratégia de conteúdo e relações públicas digitais. A unidade de trabalho é o chunk, a passagem que o motor lê isolada do resto da página.
Em setembro de 2026, o documento oficial do Google Search Central sobre recursos de IA afirma que quebrar o conteúdo em pedaços pequenos não é requisito e que reescrever texto só para a IA não traz ganho. No mesmo mês, o pipeline que monta uma resposta de IA continua lendo passagens, e o modelo que reordena essas passagens dá a nota mais alta para a que responde sozinha à pergunta. As duas afirmações convivem.
A minha tese é que o SEO técnico que escolhe um lado perde. Quem fragmenta a página de forma artificial entra no radar do detector de sobre-otimização publicado em agosto. Quem trata a página inteira como unidade tende a cair no recall ou no rerank, antes de o modelo gerador ler uma linha. Em pipelines de recuperação por passagem, o trecho autocontido sobrevive melhor do que o trecho que depende do resto da página. Essa é uma hipótese de engenharia, e o tutorial dá a régua para você medi-la no seu corpus.
Este tutorial mostra como escrever passagens que passam pelo rerank, com um chunk de documentação antes e depois, como medir o funil de quatro métricas no próprio corpus e onde fica o limite que o GEO-Flag detecta. O esforço de reescrita é de uma tarde por página; a medição, de uma semana por corpus de até 200 páginas. O caso condutor é hipotético e vem rotulado em cada número: a simulação ensina o método de medição, e o ganho em produção só aparece quando você mede o seu corpus. Trata-se da documentação de um SaaS fictício de emissão de boletos, a Cobrafácil, cuja página sobre prazo de compensação aparece na primeira página do Google e desaparece quando um desenvolvedor pergunta ao ChatGPT em quantos dias um boleto pago cai na conta. Descrevi o mecanismo geral desse sumiço em por que seu conteúdo ranqueia no Google e some no ChatGPT; aqui o foco é a passagem, com régua e método.
Como o motor de resposta decide em quatro estágios
Um motor de resposta processa uma pergunta em quatro estágios: indexação híbrida (léxica e vetorial), recall com query fan-out, rerank por cross-encoder e geração com atribuição. Um chunk eliminado em qualquer estágio nunca chega ao modelo que escreve a resposta, e por isso nenhuma técnica de citação compensa uma falha de recuperação.
Dois termos precisam de glosa antes do passo a passo. Embedding é o vetor numérico que representa o significado de um trecho, comparado por similaridade de cosseno com o vetor da pergunta. Cross-encoder é o modelo que lê pergunta e passagem juntas e devolve uma nota de relevância; ele age como a segunda entrevista de um processo seletivo, em que a triagem por currículo já passou e só a resposta direta conta. No estágio de recall, o índice combina busca léxica (BM25, que exige o termo literal) e busca vetorial (que aceita paráfrase).
- Indexação híbrida: a página é dividida em passagens, cada uma com um vetor e um índice léxico. O que mata o chunk: página bloqueada para o crawler, conteúdo montado só no cliente, passagem tão longa que o vetor vira uma média de vários assuntos.
- Recall com fan-out: o modelo desdobra a pergunta em várias consultas e escolhe domínios candidatos antes de buscar. Desde 8 de agosto de 2026, entre 16% e 17% das consultas de fan-out do ChatGPT Search observadas no navegador levam o operador site:, contra 0,3% a 0,5% antes do GPT-5.6 (medição da Promptwatch, relatada por Simon Willison em 20 de agosto de 2026). A OpenAI não publicou o critério de escolha do domínio. A leitura que faço dos dados é que o modelo escolhe o domínio a partir do que já associa ao tema: entidade consistente entre páginas, site focado num assunto e menções de terceiros. O que mata o chunk: vocabulário fora do que a sub-consulta usa, entidade sem consistência entre páginas. Detalhei o desdobramento em RAG e query fan-out.
- Rerank por cross-encoder: dos candidatos, sobrevive quem responde à pergunta de forma autocontida. O que mata o chunk: pronome sem antecedente, remissão a outra seção, resposta que começa pelo contexto e termina sem número.
- Geração com atribuição: o modelo escreve a resposta com as passagens sobreviventes e escolhe quais citar. O que mata o chunk: densidade factual baixa, ausência de data, afirmação sem condição que o modelo consiga reproduzir.
No caso hipotético da Cobrafácil, a página inteira passa pelo estágio um, porque o Googlebot a lê e ela ranqueia. O chunk sobre prazo de compensação cai no estágio três, porque a passagem diz que o prazo "depende do banco emissor" e remete à seção anterior. O cross-encoder recebe uma passagem que fala do assunto sem responder à pergunta.
Que número olhar em cada estágio: o funil de quatro métricas
O funil de relevance engineering tem quatro métricas encadeadas: similarity, hit rate@k, rerank survival e citation share. A cadeia causal é uma síntese minha, feita no levantamento interno da Brasil GEO em julho de 2026, e vale como hipótese de engenharia que o funil mede. Similaridade maior eleva a chance de entrar no top-k; entrar no top-k eleva a chance de sobreviver ao rerank; sobreviver ao rerank eleva a chance de citação. Um gargalo em qualquer estágio anula o ganho dos anteriores.
| Métrica | Pergunta que responde | Como medir no próprio corpus | O que derruba o chunk |
|---|---|---|---|
| Similarity | O vetor do chunk fica perto do vetor das perguntas-alvo? | Embedar as 20 perguntas e cada chunk; registrar o cosseno médio por chunk | Passagem longa demais (vetor vira média), vocabulário distinto do da pergunta |
| Hit rate@k | O chunk entra no top-k dos candidatos? | Índice espelho BM25 + vetorial; fração das 20 perguntas em que o chunk aparece no top-10 | Entidade ausente, termo canônico substituído por sinônimo, página sem crawl |
| Rerank survival | Entre os que entraram, o chunk fica no top-n depois do cross-encoder? | Aplicar um cross-encoder aberto aos candidatos; fração dos hits que permanecem no top-3 | Anáfora externa, resposta sem número, contexto antes da resposta |
| Citation share | Nas respostas geradas, o chunk aparece citado? | Painel de 20 perguntas por motor, cinco execuções cada, média de citações com link para a URL | Densidade factual baixa, data ausente, falta de corroboração em outras páginas |
A tabela fixa uma escolha de método. Para rerank survival, no levantamento que fiz em 3 de setembro de 2026 encontrei definições de vendor e nenhum padrão industrial com denominador fixo. Todo relatório que use a métrica precisa declarar k, n, o cross-encoder e o painel de perguntas; sem esses quatro dados, dois números de survival deixam de ser comparáveis. O mesmo vale para citation share, que já discuti como sintoma em citabilidade: como a IA decide qual marca citar.
A régua de decisão que uso é regra da casa, sem limiar público que a sustente. Hit rate@10 abaixo de 30% no painel manda reescrever heading e entidade. Survival abaixo de 50% dos hits manda revisar a autocontenção da passagem. Citation share que sobe em duas medições consecutivas autoriza levar o método ao resto do corpus. Chunk que responde a nenhuma pergunta do painel fica como está. Ajuste os limiares ao seu corpus depois da primeira medição.
Medição do caso hipotético antes da reescrita, num painel de 20 perguntas que o suporte da Cobrafácil recebe sobre compensação. O chunk aparecia no top-10 do índice espelho em três das 20 perguntas (hit rate@10 hipotético). Dessas três, sobrevivia ao cross-encoder em uma. Nas cinco execuções por motor, foi citado em zero das 20 (citation share hipotético). O diagnóstico aponta para o estágio dois como primeiro gargalo e para o três como segundo, e a reescrita ataca os dois na mesma passagem.
Passo a passo: reescrever um chunk para sobreviver ao rerank
Um chunk que sobrevive ao rerank tem seis propriedades verificáveis: heading escrito como a pergunta real, entidade nomeada na primeira frase, resposta com número e condição antes do contexto, duas a quatro frases com uma ideia, evidência datada na passagem e vocabulário canônico sem sinônimo. Cada passo abaixo instala uma dessas propriedades e explica o mecanismo que ela destrava.
- Escreva o heading como a pergunta que o leitor faz. Como: pegue a formulação literal das dez dúvidas mais frequentes do suporte e use uma delas. Por quê: muitos pipelines prependem o heading ao chunk antes de embedar, e a pergunta literal aproxima o vetor da passagem do vetor da sub-consulta do fan-out.
- Nomeie a entidade na primeira frase. Como: substitua "ele", "o sistema", "a plataforma" pelo nome do produto e do objeto. Por quê: o chunk será lido fora da página; um pronome sem antecedente reduz a similaridade e faz o cross-encoder pontuar uma frase que fala de ninguém.
- Responda na primeira frase, com número e condição. Como: valor, unidade, prazo e a condição que altera o valor, tudo antes de qualquer explicação. Por quê: o cross-encoder recompensa a passagem que responde de forma autocontida, e o gerador ancora a citação em números e datas.
- Corte para duas a quatro frases com uma ideia só. Como: o corte segue a fronteira da ideia, e a contagem de frases é consequência; o que responde a outra pergunta vira outro chunk com outro heading. Por quê: uma passagem com três assuntos produz um vetor médio, distante de qualquer uma das três perguntas. A fronteira com a fragmentação artificial que o GEO-Flag classifica como intervenção é esta: cada chunk responde sozinho a uma pergunta do painel. Picar o texto em frases de uma linha que respondem a nada, ou abrir uma página por variação de pergunta, fica do lado detectável.
- Ancore a evidência dentro da passagem. Como: fonte, data e escopo na mesma passagem, em uma frase curta. Por quê: o estágio de geração escolhe citar o que consegue reproduzir com atribuição; a evidência fora da passagem se perde no recorte.
- Repita o termo canônico. Como: escolha um nome para cada conceito (compensação, arquivo de retorno, banco emissor) e use só ele. Por quê: a busca léxica exige o termo literal, e a variação estilística que agrada ao redator dispersa o sinal entre sinônimos.
O chunk da Cobrafácil, antes e depois. Os prazos são ilustrativos, escolhidos para o exemplo, e o produto é fictício.
Antes (heading: "Prazos")
Como mencionado na seção anterior, ele depende do banco emissor. Em geral, isso leva alguns dias úteis, mas pode variar conforme a configuração da sua conta e o tipo de arquivo de remessa. Consulte nosso suporte em caso de dúvida.
Depois (heading: "Em quantos dias úteis um boleto pago pela Cobrafácil cai na conta?")
Um boleto pago pela Cobrafácil é compensado em um dia útil em banco participante da compensação eletrônica e em até dois dias úteis nos demais bancos, conforme o contrato com o banco emissor. O prazo conta a partir da data de pagamento registrada no arquivo de retorno CNAB 240. O valor compensado aparece no extrato da Cobrafácil com o status Liquidado e a data de crédito. Prazos conforme a tabela de compensação vigente em setembro de 2026; confira o contrato do seu banco emissor.
O que mudou na passagem: a entidade aparece pelo nome, a resposta abre com número e condição, a remissão à seção anterior sumiu, os termos compensação, arquivo de retorno e banco emissor se repetem sem sinônimo, e a data de vigência entrou no chunk. A passagem tem quatro frases e uma ideia. A pergunta sobre o tipo de arquivo de remessa, escondida no texto antigo, virou outro chunk com outro heading. A primeira frase segue a receita que descrevi em answer capsules.
Diversidade de evidência vence repetição: como distribuir o mesmo fato
Documentos diversos melhoram a resposta do gerador; duplicatas e paráfrases do mesmo documento melhoram quase nada. O experimento controlado de 14 de agosto de 2026 (arXiv 2608.13956) usou o conjunto FictionalQA, em que o modelo desconhece a resposta de antemão, e mediu ganho de correção entre 17% e 47% quando os documentos recuperados carregavam a informação em formas diferentes, contra ganho sem significância para cópias e paráfrases geradas por LLM.
A consequência para documentação técnica é direta. Para o mesmo fato-chave, o prazo de compensação no caso hipotético, cinco páginas com o mesmo parágrafo produzem cinco chunks quase idênticos que competem no rerank e não acrescentam nada ao gerador. O fato em formas distintas (passagem definitória, tabela com prazo por tipo de banco, exemplo com data, pergunta de FAQ, figura com legenda) dá ao recall cinco candidatos para sub-consultas diferentes e ao gerador cinco evidências que se corroboram. O ganho de informação de cada forma é o critério que desenvolvi em information gain para LLM.
Dois estudos de 2026 dizem o que pesa na escolha do gerador. O testbed de 25 de maio de 2026 (arXiv 2605.25517) rodou 252.000 comparações pareadas entre dois documentos, em seis LLMs e 18 fatores de conteúdo, com marcas anonimizadas. Relevância tópica e posição na lista foram os maiores preditores da primeira citação; preço e timestamp recente ajudaram; mudanças só de formatação tiveram efeito pequeno. O estudo GEO-SFE de 31 de março de 2026 (arXiv 2603.29979) mediu, em 200 artigos avaliados em versão original e reestruturada, em seis motores generativos, taxa de citação subindo de 45,0% para 52,8% com a reorganização da estrutura macro, meso e micro do documento (n de 200, teste t pareado, p menor que 0,001). Estrutura importa quando carrega relevância e evidência; formatação sozinha importa pouco.
Sobre o tamanho do chunk, no levantamento que fiz em 3 de setembro de 2026 não encontrei estudo controlado que fixe duas a quatro frases como ótimo universal. O que existe é evidência de que a fronteira do chunk pesa: em 31 de agosto de 2026, um estudo de chunking semântico em textos biomédicos (arXiv 2608.31139) mediu F1 de 82,6% contra 74,2% do corte de tamanho fixo no benchmark GM-CIHT. A regra de duas a quatro frases fica como técnica de clareza para o leitor e para o recuperador, sem promessa de citação.
Onde fica o limite: GEO-Flag e a política do Google
No benchmark do estudo GEO-Flag, um detector ModernBERT separou conteúdo com intervenção GEO de conteúdo de controle com F1 de 0,944; o número mostra que a sobre-otimização é detectável em laboratório, e nenhum buscador declarou usar esse detector. O estudo, de 17 de agosto de 2026 (arXiv 2608.16824, v2 em 20 de agosto), construiu um benchmark de 3.200 instâncias sobre 400 consultas em quatro domínios e oito famílias de otimizador, e treinou o detector com pares de intervenção. Aplicado a 10.095 páginas recuperadas por Google e Gemini para 1.000 consultas reais, o detector estimou prevalência de 8,90% de conteúdo GEO-otimizado, subindo para 16,36% entre as páginas modificadas em 2026.
O detector separa polimento de prosa, que ele ignora, de intervenção que planta sinal: citação inventada, estatística decorativa, autoridade fabricada, palavras-chave empilhadas. Do lado do Google, o guia oficial sobre recursos de IA diz que criar conteúdo separado para cada variação de consulta do fan-out com o objetivo principal de manipular rankings ou respostas generativas viola a política de scaled content abuse. E o survey crítico de 15 de julho de 2026 (arXiv 2607.14035), sobre 45 estudos, conclui que conteúdo já recuperado pode ter sua citação alterada de forma causal, mas que nenhuma técnica revisada mostrou efeito causal estável, longitudinal e entre plataformas sobre descobribilidade orgânica.
O passo a passo da seção anterior fica inteiro do lado permitido, e o checklist abaixo é o que uso para conferir antes de publicar. Cada item indica de qual lado vem o risco, porque são riscos distintos: o que o detector GEO-Flag classifica como intervenção no benchmark e o que o guia oficial do Google enquadra na própria política. Depois vem a forma defensável.
- Estatística sem fonte, data e denominador na passagem (risco GEO-Flag): retirar o número ou reduzir a afirmação ao que se sabe. Forma defensável: número com origem na mesma frase, como nos chunks deste tutorial.
- Citação a autoridade que a URL citada desconhece (risco GEO-Flag): cortar. Forma defensável: só fonte aberta e lida, com a data de acesso.
- Uma página por variação de pergunta do fan-out com o mesmo miolo (risco de política do Google, scaled content abuse): consolidar. Forma defensável: uma página com chunks distintos por sub-pergunta e formas diversas de evidência.
- Termo-alvo empilhado fora do heading (risco GEO-Flag): podar. A regra da casa que aplico é revisar toda repetição mecânica acima de duas ocorrências por 500 palavras; o limiar é heurística editorial minha, sem estudo público que fixe um número. Forma defensável: termo canônico onde ele carrega sentido, sinônimo em lugar nenhum.
- Passagem fragmentada em frases de uma linha sem resposta própria (risco GEO-Flag): reunir. Forma defensável: duas a quatro frases que respondem sozinhas.
- Reescrita da página inteira só para a IA, sem mudança de substância (sem ganho, pelo guia do Google): desfazer. O Google afirma que reescrever para a IA não traz ganho, e John Mueller resumiu em 24 de agosto de 2026 que, do ponto de vista do Google, não há nada de especial a fazer para respostas generativas na busca.
O guardrail decide também o tamanho do trabalho: no caso hipotético da Cobrafácil, a reescrita mudou 12 chunks de 200 páginas, porque só 12 passagens respondiam a perguntas do painel, e as outras seguiram como estavam.
Como medir o funil no seu corpus em uma semana
Medir o funil de quatro métricas num corpus de até 200 páginas leva cinco dias úteis com ferramentas abertas: crawler próprio, chunker controlado, índice BM25, modelo de embedding, cross-encoder aberto e painel de 20 perguntas por motor. O resultado é uma tabela por chunk com similarity, hit rate@10, rerank survival e citation share, que aponta o estágio do gargalo antes de qualquer reescrita. A divisão de trabalho é simples. O redator de documentação faz os dias um e cinco (painel de perguntas e reescrita); o SEO técnico faz os dias dois a quatro (índice espelho, rerank e painel de motores). Nenhum dos dois precisa de um engenheiro de dados, porque chunker, BM25, embedding e cross-encoder abertos rodam em bibliotecas Python de uso comum.
- Dia um, painel. Liste as 20 perguntas reais do suporte, do chat de vendas e do Search Console, escritas como o usuário escreveria, sem termo interno.
- Dia dois, índice espelho. Rastreie as páginas, divida por heading, embede cada chunk e monte o índice léxico; registre modelo e versão do embedding, porque a troca muda a similaridade.
- Dia três, recall e rerank. Para cada pergunta, recupere o top-10 híbrido e aplique o cross-encoder; anote, por chunk, em quantas perguntas entrou e em quantas ficou no top-3.
- Dia quatro, citação. Rode as 20 perguntas cinco vezes em cada motor (ChatGPT, Gemini, Perplexity, AI Mode) e registre URL citada, modelo, data e execução; separe menção de citação com link.
- Dia cinco, diagnóstico. Ordene os chunks pelo primeiro estágio em que caem e reescreva só os que respondem a perguntas do painel, na ordem do passo a passo.
Escreva para /contato com a URL de uma página de documentação e as dez perguntas que o suporte mais recebe sobre ela. Em cinco dias úteis devolvo o funil das quatro métricas medido para essa página, com k, n e cross-encoder declarados, e você decide com o número na mão se o método vale para o resto do corpus.
O caso hipotético da Cobrafácil, medido de novo 14 dias depois da reescrita, no mesmo painel de 20 perguntas e cinco execuções por motor. O chunk sobre prazo de compensação entrou no top-10 do índice espelho em 14 das 20 perguntas (hit rate@10 hipotético, contra três antes). Sobreviveu ao cross-encoder em 11 dessas 14 (contra uma de três) e foi citado com link em seis das 20 perguntas (contra zero). A página continua na primeira página do Google, como no início, e o desenvolvedor que pergunta ao ChatGPT em quantos dias o boleto cai na conta agora lê um dia útil, com a condição, a data e o nome da Cobrafácil ao lado. Os números são do exemplo; o método, o k e o painel são os que você pode repetir amanhã.
Referências
- Optimizing your website for generative AI features on Google Search, Google Search Central, vigente em setembro de 2026 (publicação entre maio e julho de 2026)
- Google answers if some sites can ignore GEO and just focus on SEO, Search Engine Journal, 24 de agosto de 2026 (declaração de John Mueller)
- An introduction to the Relevance Engineering framework, iPullRank, 8 de maio de 2025
- What Gets Cited: Competitive GEO in AI Answer Engines, arXiv 2605.25517, 25 de maio de 2026
- How retriever redundancy and diversity impact RAG effectiveness, arXiv 2608.13956, 14 de agosto de 2026
- GEO-Flag: Detecting and Measuring GEO-Optimized Web Content, arXiv 2608.16824, 17 de agosto de 2026 (v2 em 20 de agosto)
- Structural Feature Engineering for Generative Engine Optimization: How Content Structure Shapes Citation Behavior (GEO-SFE), arXiv 2603.29979, 31 de março de 2026
- Optimizing Visibility in Generative Engines: A Critical Survey of GEO (2023-2026), arXiv 2607.14035, 15 de julho de 2026
- Configurable Semantic Chunking for Biomedical text, arXiv 2608.31139, 31 de agosto de 2026
- ChatGPT Search now uses the site: operator at scale, Simon Willison, 20 de agosto de 2026 (medição da Promptwatch sobre o fan-out do ChatGPT Search)
- Síntese técnica própria do funil similarity, hit rate@k, rerank survival e citation share, levantamento interno da Brasil GEO, julho de 2026 (curadoria do autor, sem publicação externa)