Most teams build their first retrieval system the same way: slice every document into fixed 512-token chunks, push them into a vector database, and hope the embedding model does the hard work. That hope gets you through a demo. It does not survive contact with real users.
In production, a legal contract falls apart when you sever a liability clause from its exceptions. API documentation turns useless when a code sample gets detached from its function signature. A customer support thread becomes noise when you rip a single complaint out of its conversational history. The problem is rarely the language model sitting at the end of the pipeline. The problem is what you feed it.
We learned this the hard way. Our initial retrieval layer looked standard but behaved inconsistently. So we rebuilt it around a simple idea: treat retrieval as measured infrastructure, not magic. Here is exactly what changed, and how we pushed recall to 95 percent while cutting the 95th-percentile latency from 850 ms to 320 ms.
The Fixed-Chunk Trap
Uniform token counts are easy to code and easy to explain. That convenience masks a basic truth: documents have structure. When you ignore that structure, you destroy signal.
Consider a ten-page master service agreement. A fixed 512-token slice will land mid-obligation, splitting a clause from the very cap table that limits it. The retrieval step then returns half a thought. The generator hallucinates the rest. In API documentation, a chunk that is too large dilutes the embedding with boilerplate headers, burying the specific method a developer needs. In support tickets, a fixed window treats a conversation as a bag of sentences, stripping away the back-and-forth that reveals what actually failed.
We stopped treating chunk size as a hyperparameter we guessed. We started treating it as a mapping exercise between the document type and the information architecture inside it.
Match Your Chunking to the Data
The fix is not one perfect chunk size. The fix is three distinct strategies tuned to three distinct data shapes.
Legal documents now go through recursive splitting. The algorithm first looks for the largest natural boundaries—sections, then subsections, then numbered clauses—and only falls back to smaller splits when necessary. This keeps a termination clause attached to its survival conditions. The retrieval step sees complete logical units, which sharply reduces the model’s temptation to invent missing exceptions.
API and code documentation get structure-aware chunking. Markdown headers, code fences, and parameter tables are parsed as atomic units. We do not split inside a code block. We keep docstrings adjacent to their signatures. The result is that a query for a specific class method retrieves the full context a developer needs: the description, the typed parameters, and the working example.
Support and conversational data use semantic chunking. Instead of counting tokens, we look for shifts in topic or intent. If a customer describes a bug in message three and pastes a stack trace in message seven, we chunk by meaning, not by message index. The retrieval layer then returns the full arc of the problem rather than a orphaned sentence.
Why Vector Search Alone Fails
Even perfect chunks die in a pure vector search. Dense embeddings excel at capturing meaning and synonymy, but they are notoriously fuzzy on exact strings. If an engineer searches for the precise error code ERR_CONNECTION_REFUSED, vector similarity might return a dozen conceptual neighbors and miss the exact match buried at rank fourteen.
Keyword search with BM25 has the opposite problem. It finds exact tokens but misses semantic intent. A user asking “why is my database down” will never match a document that says “troubleshooting connection timeouts.”
We now run both. Vector and keyword results are fed into Reciprocal Rank Fusion, which blends the two ranked lists without requiring calibrated scores. The fused list is then passed through a cross-encoder reranker. The reranker is slower than the initial retrieval, but it is far more precise because it judges query-document relevance directly rather than through compressed embeddings. That hybrid pipeline alone lifted our recall by 15 percent.
Fixing Bad Queries Before They Hit the Index
Os usuários não escrevem consultas de busca ideais. Eles colam linhas de log truncadas. Eles digitam “está quebrado”. Eles usam jargões que sua documentação nunca adotou. Se você confiar na consulta bruta, estará confiando no ruído.
Agora, expandimos cada consulta recebida em três a cinco variações antes de enviá-las para a camada de recuperação (retrieval). Uma variação pode ser um parafraseamento direto. Outra pode ser um título de documento hipotético e ideal. Uma terceira remove o preenchimento conversacional e isola palavras-chave técnicas. Cada variante é transformada em embedding e pesquisada. Em seguida, removemos as duplicatas e mesclamos os conjuntos de candidatos.
Isso não é de graça. Essas chamadas extras de embedding custam dinheiro e adicionam alguns milissegundos. Mas o efeito no recall foi dramático: passamos de 78 por cento para 96 por cento ao expandir as consultas antes da recuperação. Como uma melhor recuperação reduz a janela de geração e fundamenta o modelo no contexto correto, acabamos economizando dinheiro nas etapas posteriores. Uma etapa de recuperação ligeiramente mais cara é mais barata do que uma etapa de geração longa e alucinada.
Pare de Adivinhar. Comece a Pesquisar.
Uma vez que implementamos o chunking correto, a recuperação híbrida e a expansão de consultas, ainda enfrentamos uma bagunça combinatória. Tamanho do chunk, sobreposição de chunks, profundidade de recuperação top-k, limites do reranker e pesos de fusão interagem entre si. Uma busca em grade (grid search) manual teria levado semanas e ainda nos deixaria em um máximo local.
Mudamos para a otimização Bayesiana para explorar o espaço. Em vez de testar exaustivamente todas as combinações, o algoritmo de busca mantém uma crença sobre quais configurações têm probabilidade de ter um bom desempenho e afunila progressivamente em regiões promissoras.
O resultado não é uma única configuração perfeita. É uma fronteira de Pareto de escolhas. De um lado, temos uma configuração enxuta otimizada para nosso endpoint de suporte de API de alto rendimento: inferência rápida, recall moderado e a menor latência possível. Do outro lado, temos uma configuração agressiva para revisão jurídica: recuperação mais profunda, reranking mais pesado e sobreposição mais estreita, trocando milissegundos por minuciosidade. Como a fronteira é explícita, podemos escolher o ponto certo para o produto em vez de fingir que um tamanho serve para todos.
Como os Números Realmente Parecem
Essas mudanças moveram o sistema de um protótipo frágil para um pipeline de produção mensurável.
O recall em dez melhorou de 78 por cento para 95 por cento. Isso significa que, quando a resposta correta existe em nosso corpus, nós a encontramos dezenove em cada vinte vezes.
A latência no percentil 95 caiu de 850 ms para 320 ms. A stack híbrida parece mais pesada no papel, mas um indexamento mais inteligente, rerankers menores e a capacidade de servir chunks agressivos apenas quando necessário tornaram todo o sistema mais rápido.
A taxa de alucinação — monitorada por anotadores humanos em um golden dataset — caiu de 12 por cento para 3 por cento. Quando o modelo recebe um contexto completo e relevante, ele para de inventar fatos.
O custo por consulta caiu de $0,008 para $0,005. Uma melhor recuperação significa prompts de LLM mais curtos e focados e menos tentativas de recuperação. O gasto extra com embeddings na expansão de consultas é insignificante perto da economia na geração.
Construa um Golden Dataset e Trate a Recuperação como Código
Se você tirar uma coisa disso, deve ser a disciplina da medição. Construímos um pequeno golden dataset de perguntas reais e locais de respostas verificados. Antes que qualquer mudança chegue à produção, ela é testada contra esse conjunto de dados. O recall e a latência são monitorados em tempo real, não apenas observados visualmente em um notebook.
A recuperação não é uma demonstração de pesquisa. É infraestrutura. Ela merece testes unitários, benchmarks de regressão e otimização automatizada, assim como o resto da sua stack. Faça o chunking pela estrutura do documento, não por superstição de tokens. Combine busca vetorial e por palavra-chave com um reranker. Expanda as consultas que seus usuários realmente escrevem. Então, deixe um algoritmo de busca ajustar os controles em vez da sua intuição.
O pipeline que descrevemos não é teórico. Você pode ler o artigo original aqui e, se quiser discutir engenharia de recuperação com uma comunidade que se importa com esse assunto, o grupo GyaanSetu AI está aberto.