RAG Chunking para Chatbots de IA: Dividir Conteúdo com Critério

Um chatbot para websites só consegue responder de forma fiável se encontrar o conteúdo certo no momento certo. É exatamente aqui que o RAG chunking faz a diferença: páginas longas, manuais e textos de ajuda são divididos em unidades mais pequenas que uma componente de pesquisa consegue recuperar com precisão. Blocos demasiado grandes contêm muito ruído. Blocos demasiado pequenos perdem o contexto. Por isso, uma boa divisão não segue cegamente um número, mas sim a estrutura, o significado e a utilização futura do conteúdo.

Este guia destina-se a equipas de website, suporte e conteúdo. Explica como dividir conteúdos semanticamente, preservar metadados, reduzir duplicados e testar, com perguntas de pesquisa reais, se a estratégia escolhida funciona. A abordagem é independente de fornecedores e pode ser aplicada tanto à pesquisa vetorial clássica como a métodos de recuperação híbridos.

Por que razão o RAG chunking molda a qualidade das respostas

No Retrieval-Augmented Generation (RAG), o sistema procura primeiro os blocos de conhecimento relevantes e depois passa-os ao modelo de linguagem. Assim, os limites dos chunks determinam o que pode ser encontrado e utilizado conjuntamente como contexto. Se uma condição de preço for separada da sua exceção, uma pesquisa formalmente correta pode ainda assim fornecer uma base incompleta. Se, por outro lado, um chunk contiver uma página inteira de produto com navegação, variantes e rodapé, a passagem crucial competirá com muito ruído.

O chunking afeta simultaneamente várias dimensões de qualidade:

• Capacidade de recuperação: A afirmação procurada cabe claramente numa unidade compacta?
• Contexto: O título, a explicação, a restrição e o exemplo permanecem juntos?
• Precisão: O resultado obtido contém o mínimo possível de conteúdo irrelevante?
• Rastreabilidade: É possível associar o excerto a uma fonte, idioma e versão válidos?

A Microsoft descreve métodos fixos, variáveis e semânticos, destacando que os títulos e outros sinais de esquema estrutural podem ser utilizados para criar limites com significado. A AWS também distingue estratégias fixas, hierárquicas e semânticas. A lição prática comum: a divisão técnica deve seguir a estrutura de conteúdo sempre que esta existir de forma fiável.

Começar com secções semânticas em vez de cortes arbitrários

Um bom ponto de partida é a estrutura existente da página. Os títulos H2 e H3, parágrafos, listas, perguntas de FAQ, tabelas e avisos claramente delimitados já transportam significado. Uma secção sobre prazos de devolução não deve terminar a meio de uma frase ou entre a regra e a exceção. Uma pergunta de FAQ deve estar no mesmo chunk que a respetiva resposta. No caso de um tutorial ou guia, o passo de ação, os pré-requisitos e os avisos devem permanecer juntos sempre que possível.

Uma lógica prática de delimitação

1. Divida primeiro pelos títulos do documento, da página e das secções principais.
2. Verifique se uma secção aborda exatamente um tópico principal compreensível.
3. Divida apenas as secções que sejam demasiado grandes para a recuperação ou para o contexto do modelo.
4. Combine fragmentos muito curtos com uma secção vizinha adequada.
5. Anexe o título e a estrutura de tópicos como contexto a cada parte.

Com HTML ou Markdown limpo, este método é facilmente automatizável. PDFs não estruturados, exportações inconsistentes e documentos digitalizados necessitam frequentemente de um reconhecimento prévio de esquema ou texto. Ao fazer isto, preste especial atenção a tabelas, colunas, cabeçalhos e quebras de página: o que está visualmente lado a lado pode acabar na ordem errada ao ser extraído.

Tratar o tamanho do chunk como um valor de teste, não como um dogma

Não existe um tamanho ideal universal para os chunks. A Microsoft menciona 512 tokens com 25% de sobreposição como um ponto de partida possível para certos cenários, mas salienta que a configuração ideal depende do conteúdo e do modelo. A AWS também documenta tamanhos e sobreposições configuráveis. Tais valores são hipóteses iniciais úteis – e não uma garantia de qualidade.

Respostas curtas a FAQs funcionam frequentemente como unidades autónomas. Instruções de procedimentos detalhadas requerem mais contexto. Textos legais ou contratuais não devem separar a regra, o âmbito de aplicação e as exceções. Por outro lado, as comparações de produtos podem fazer sentido por linha ou por secção, desde que os cabeçalhos das colunas e a referência aos produtos sejam incluídos.

Como identificar chunks demasiado grandes ou demasiado pequenos

Um chunk é tipicamente demasiado grande quando mistura várias intenções de pesquisa, quando a frase relevante se perde entre elementos de navegação e informações secundárias, ou quando muitos resultados devolvem o mesmo bloco volumoso. É demasiado pequeno quando os pronomes perdem a referência, faltam títulos, as condições são separadas das afirmações ou são necessários múltiplos fragmentos para compreender uma pergunta simples.

Por isso, compare pelo menos duas ou três variantes utilizando o mesmo conjunto de perguntas. Altere apenas um parâmetro de cada vez, como o tamanho-alvo ou a lógica de delimitação. Desta forma, fica claro o que realmente melhora a qualidade dos resultados e as evidências das respostas.

A sobreposição protege o contexto – mas também cria duplicados

Uma pequena sobreposição pode evitar que uma frase crucial se perca na fronteira de um chunk. É especialmente útil quando uma divisão técnica baseada no comprimento é inevitável. No entanto, o excesso de sobreposição tem efeitos secundários: resultados quase idênticos ocupam vários lugares na pesquisa, aumentam a quantidade de contexto e podem dominar artificialmente uma afirmação.

Portanto, utilize a sobreposição de forma estratégica. Em secções baseadas na estrutura, costuma ser suficiente incluir o título, o caminho da estrutura e uma breve transição. Em textos corridos mais longos, pode fazer sentido incluir uma pequena parte da secção anterior. Em seguida, meça se diferentes fontes relevantes permanecem nos primeiros resultados ou se são afastadas por duplicados.

Os metadados garantem a fiabilidade operacional do chunk

O texto simples raramente é suficiente para uma base de conhecimento em produção. Cada chunk deve manter a sua origem e o seu âmbito de aplicação. A AWS descreve os metadados como a base para filtros durante a consulta. Numa base de conhecimento para websites, os seguintes campos são particularmente úteis:

• URL de origem canónica e título da página;
• Caminho dos títulos dentro da página;
• Idioma ou locale;
• Tipo de conteúdo, como FAQ, tutorial, política ou detalhes do produto;
• Data de publicação ou de alteração;
• Produto, região ou público-alvo, se relevante para o negócio;
• Estado de acesso e de aprovação para conteúdos não públicos.

Isto permite, por exemplo, pesquisar apenas conteúdos de suporte em português e atualmente aprovados. A fonte também pode ser associada a um link na resposta e reprocessada especificamente durante uma atualização futura. Para saber como garantir a atualização de forma sistemática, consulte o guia Manter a Base de Conhecimento do Chatbot de IA Atualizada.

Remover conteúdos repetitivos (boilerplate) e duplicados antes de indexar

Elementos de navegação, avisos de cookies, blocos de contacto repetidos e rodapés globais não devem estar presente em todos os chunks. Caso contrário, surgem centenas de entradas quase idênticas que podem afastar o conteúdo real. Remova os elementos recorrentes da página antes de fazer a divisão e normalize espaços desnecessários, caracteres decorativos e fragmentos técnicos.

Os duplicados de conteúdo também exigem atenção. Se a mesma regra de devolução estiver formulada de forma diferente nas páginas de ajuda, de produto e de envio, deve ser definida uma fonte primária responsável. Cópias desatualizadas devem ser removidas, redirecionadas ou claramente despriorizadas. O processo de chunking não consegue transformar fontes contraditórias em conhecimento fiável.

Lidar conscientemente com casos especiais

Conteúdos de FAQ

Guarde a pergunta e a resposta juntas. No caso de respostas muito curtas, adicione o tópico geral a que pertencem. As variações da mesma pergunta podem ser úteis para a pesquisa, mas não devem ser indexadas como texto de resposta duplicado.

Tabelas e listas

Uma linha de tabela sem cabeçalhos de coluna é, na maioria dos casos, incompreensível. Por isso, repita ou referencie os termos dos cabeçalhos relevantes dentro do chunk. Em listas longas, cada parte deve manter o título da lista e a introdução comum. Após a extração, verifique se os valores continuam associados ao atributo correto.

Páginas multilíngues

Separe o conteúdo por locale e guarde o idioma como metadado. Uma consulta em português não deve devolver acidentalmente uma secção desatualizada em inglês só porque surgem termos semelhantes. Identificadores comuns de tradução ou de página ajudam a relacionar variantes sem as misturar no mesmo bloco de texto.

Realizar testes de recuperação antes dos testes de resposta

Avalie primeiro se a pesquisa devolve a passagem correta. Só depois avalie a formulação do modelo de linguagem. Um pequeno Golden Set com perguntas reais dos utilizadores deve conter perguntas diretas, sinónimos, pedidos com múltiplas partes, casos limite e perguntas sem resposta documentada. Para cada pergunta, defina previamente qual a fonte ou secção esperada.

Verifique, no mínimo:

• se a secção esperada aparece entre os primeiros resultados;
• se resultados irrelevantes ou duplicados estão a afastar fontes importantes;
• se todas as condições e exceções necessárias estão presentes no contexto fornecido;
• se a fonte e o seu estado de atualização permanecem rastreáveis;
• se o sistema evita com segurança inventar uma resposta quando falta informação.

O artigo Medir a Qualidade das Respostas do Chatbot de IA com Golden Set e Testes RAG descreve o processo de verificação adequado. Para evidências visíveis, o guia Fundamentar Respostas do Chatbot com Fontes complementa a perspetiva sobre a verificação de links e incerteza.

Lista de verificação para a implementação

1. Inventariar conteúdos: Mapear tipos de página, idiomas, formatos e fontes responsáveis.
2. Verificar a extração: Controlar títulos, tabelas e a ordem de leitura em exemplos representativos.
3. Definir limites: Dar prioridade a secções semânticas e usar tamanhos fixos apenas como alternativa secundária.
4. Preservar o contexto: Incluir título da página, caminho dos títulos e transições necessárias.
5. Planear metadados: Guardar de forma estruturada URL, locale, data de atualização, tipo de conteúdo e estado de aprovação.
6. Remover duplicados: Limpar elementos repetitivos (boilerplate) e cópias contraditórias antes de indexar.
7. Testar variantes: Comparar tamanhos e sobreposições utilizando o mesmo Golden Set.
8. Monitorizar a operação: Avaliar regularmente pesquisas sem resultado, fontes desatualizadas e o feedback dos utilizadores.

Conclusão: BONS chunks são unidades de conhecimento compreensíveis

O RAG chunking não é uma configuração técnica pontual, mas sim a arquitetura de conteúdo para a recuperação automatizada. Bons chunks respondem a um tópico específico e bem delimitado, mantêm o contexto necessário e podem ser associados a uma fonte válida. Títulos, metadados e uma sobreposição controlada são tão importantes quanto o comprimento do texto em si.

Comece com alguns tipos de conteúdo representativos, meça a recuperação antes do estilo de resposta e documente cada alteração. Se pretender criar um chatbot para websites com base numa estrutura de conhecimento organizada, encontrará o ponto de partida ideal na visão geral de funcionalidades do ChatReact.

Fontes

• Microsoft Learn: Chunk large documents for vector search solutions in Azure AI Search
• Microsoft Learn: Chunk and vectorize by document layout
• AWS Bedrock: How content chunking works for knowledge bases
• AWS Bedrock: Include metadata in a data source