Guia prático de chunking, embeddings e retrieval

Nem toda resposta ruim em uma aplicação com RAG é culpa do modelo. Muitas vezes, o problema começa antes: documentos mal preparados, chunks que quebram o sentido, embeddings pouco úteis, filtros ausentes ou retrieval que traz contexto parecido, mas insuficiente.

Contexto

No primeiro guia da série, a ideia era organizar o modelo mental de RAG: recuperar contexto externo, entregar esse contexto ao modelo e validar se a resposta ficou melhor.

Esse fluxo parece simples quando desenhado em uma linha, mas na prática boa parte da qualidade de um sistema com RAG é decidida antes do modelo escrever qualquer resposta.

1pergunta -> busca -> contexto -> resposta -> validação

Se o conteúdo foi mal dividido, se os embeddings não ajudam a encontrar os trechos certos, se a busca retorna material parecido mas não suficiente, ou se os metadados são ignorados, o modelo recebe um contexto fraco.

E um modelo forte com contexto fraco ainda pode gerar uma resposta ruim. Às vezes, pior: uma resposta ruim com aparência de confiança.

O problema

A pergunta central deste guia é: por que uma aplicação com RAG pode responder mal mesmo usando bons documentos e um bom modelo?

Uma resposta comum é trocar o modelo, ajustar o prompt ou aumentar a quantidade de contexto enviada. Essas mudanças podem ajudar em alguns casos, mas não atacam necessariamente a origem do problema.

• O conteúdo foi dividido de uma forma que preserva sentido?
• Os chunks estão grandes demais ou pequenos demais?
• A busca encontra trechos realmente úteis ou só semanticamente parecidos?
• Existem metadados para filtrar por versão, seção, data ou tipo de documento?
• O ranking coloca o melhor contexto no topo?
• Alguém valida se esses trechos sustentam a resposta final?

Modelo mental

1documentos2  -> chunks3  -> embeddings4  -> busca5  -> filtros e ranking6  -> contexto recuperado7  -> resposta do modelo

Chunking é a forma como o conteúdo é dividido. Embeddings são representações numéricas que ajudam a comparar significado. Retrieval é o processo de recuperar os trechos mais úteis para uma pergunta.

Essas três partes aparecem juntas em muitos exemplos de RAG, mas não são a mesma coisa. Tratar tudo como busca semântica simplifica demais o problema.

Chunking: dividir não é só cortar

Chunking é o processo de quebrar documentos em pedaços menores antes de indexar o conteúdo. Isso é necessário porque documentos inteiros costumam ser grandes demais, misturam assuntos diferentes e dificultam a busca por uma informação específica.

Mas dividir conteúdo não é só cortar por tamanho. Um chunk precisa carregar uma unidade mínima de sentido.

• Chunks grandes demais podem misturar assuntos, trazer ruído e ocupar contexto com informação desnecessária.
• Chunks pequenos demais podem quebrar uma explicação no meio, remover exemplos e deixar a resposta sem base suficiente.
• O tamanho importa, mas o sentido importa mais.

Embeddings: similaridade não é resposta

Embeddings ajudam a representar textos de uma forma que permite comparar proximidade semântica. Em termos práticos, eles ajudam a responder quais trechos parecem mais relacionados a uma pergunta.

Isso é muito útil, mas tem limite. Um trecho semanticamente próximo pode não responder à pergunta. Ele pode falar do mesmo tema, usar palavras parecidas ou pertencer à seção correta, mas ainda não trazer a instrução necessária.

Parecido não quer dizer suficiente. Em RAG, o contexto precisa sustentar a resposta, não apenas parecer relacionado.

Retrieval: recuperar contexto útil

Retrieval não deveria ser entendido apenas como pegar os cinco chunks mais parecidos. Esse pode ser um começo, mas aplicações mais cuidadosas normalmente precisam pensar em filtros, metadados, ranking, diversidade, remoção de duplicidade e limite de contexto.

• Se a documentação tem versões, o sistema pode filtrar pela versão correta.
• Se existem documentos públicos e internos, o sistema precisa respeitar escopo e permissão.
• Se uma pergunta fala de configuração, talvez faça sentido priorizar guias e tutoriais, não notas soltas.

Retrieval é menos sobre encontrar qualquer coisa parecida e mais sobre escolher o contexto que dá ao modelo uma base melhor para responder.

Exemplo prático

Imagine uma base fictícia de documentação de produto com páginas sobre criar usuário, convidar usuário externo, alterar perfil de acesso, remover acesso e resolver problemas de login.

A pergunta é: "Como altero o perfil de acesso de um usuário externo?". Um fluxo frágil poderia recuperar uma explicação geral sobre usuários externos, um trecho sobre criar convite e uma página antiga sobre permissões.

Um fluxo melhor recuperaria a seção atual sobre alteração de perfil, a regra específica para usuários externos e a observação sobre permissões necessárias para executar a ação.

A diferença não está só no modelo. Está no preparo da base, na divisão do conteúdo, nos metadados de versão, no filtro correto e no ranking do que realmente importa para a pergunta.

Erros comuns

Dividir tudo por tamanho fixo

Dividir por tamanho fixo é simples e pode ser útil como ponto de partida. Mas, se essa regra quebra seções, listas, exemplos ou pré-requisitos, o retrieval pode perder sentido.

Ignorar metadados

Metadados parecem detalhe, mas muitas vezes são o que separa uma busca genérica de uma busca útil: versão do documento, data de atualização, tipo de conteúdo, seção, produto, idioma, nível de acesso e fonte original.

Aumentar o top-k sem critério

Quando a resposta vem ruim, uma reação comum é aumentar a quantidade de chunks recuperados. Às vezes ajuda. Às vezes só manda mais ruído para o modelo.

Não olhar os trechos recuperados

Se ninguém inspeciona o que o retrieval trouxe, fica difícil saber se o problema está no prompt, no modelo, no chunking, nos dados ou na busca.

Como validar se está funcionando

Um começo prático é montar uma pequena tabela de perguntas conhecidas. Para cada pergunta, registre a pergunta do usuário, os trechos esperados, os trechos recuperados, a resposta gerada, uma avaliação humana simples e uma observação sobre falha ou acerto.

1Pergunta: Como altero o perfil de acesso de um usuário externo?2Contexto esperado: seção atual de alteração de perfil + regra para usuários externos3Contexto recuperado: criar convite + usuários externos + permissões antigas4Diagnóstico: retrieval trouxe tema parecido, mas contexto insuficiente5Próximo ajuste: revisar metadados de versão e divisão da seção de permissões

Esse tipo de validação ainda não é um sistema completo de evals, mas já ajuda a sair do "parece bom". Em vez de dizer "o modelo respondeu mal", você começa a enxergar onde o fluxo quebrou.

Quando manter simples

Nem todo caso precisa de embeddings, banco vetorial e busca semântica. Às vezes, uma solução mais simples funciona melhor.

• Busca por palavra-chave.
• Filtros tradicionais.
• FAQ bem organizada.
• Prompt com contexto pequeno e fixo.
• Tela de documentação mais clara.
• Regra de negócio no código.

Aprendizados

• Chunking não é só cortar texto; é preservar unidades de sentido.
• Chunks grandes demais podem misturar assuntos e trazer ruído.
• Chunks pequenos demais podem perder contexto.
• Embeddings ajudam a encontrar similaridade, mas similaridade não garante resposta.
• Retrieval pode envolver filtros, metadados, ranking e regras simples.
• Mais chunks não significam necessariamente melhor contexto.
• Antes de trocar de modelo, vale olhar o que está sendo entregue para ele.

Limites e ressalvas

Este guia não tenta definir um tamanho ideal de chunk, escolher banco vetorial ou comparar frameworks. Essas decisões dependem do tipo de conteúdo, volume de dados, idioma, frequência de atualização, custo, latência, permissões e experiência esperada.

Também não entra em detalhes matemáticos sobre embeddings. Para usar bem no produto, o primeiro passo não precisa ser dominar toda a teoria. Mas precisa entender o suficiente para não tratar similaridade como verdade.

Conclusão

Melhorar RAG não começa apenas no prompt. Começa antes: no conteúdo que entra na base, na forma como ele é dividido, nos metadados disponíveis, na busca que recupera os trechos e no critério usado para validar o contexto.

Um bom modelo ajuda. Mas ele não compensa automaticamente contexto ruim.

Para desenvolvedores, a pergunta prática é: o que exatamente estou entregando para o modelo responder? Se a resposta for "não sei", o próximo passo não é trocar de modelo. É abrir o retrieval, olhar os chunks e entender se o contexto recuperado realmente sustenta a resposta.