A maioria das equipes ainda monta seu primeiro pipeline de recuperação da mesma maneira. Elas escolhem um limite fixo de tokens, talvez 512, dividem os documentos em blocos uniformes e alimentam esses blocos em um banco de dados vetorial. Em um conjunto de dados pequeno com perguntas simples, isso parece mágico. Em produção, tudo desmorona.
Contratos jurídicos se despedaçam em fragmentos sem sentido quando uma cláusula é cortada no meio de uma frase. A documentação de API se transforma em uma "sopa" de ruído se um único chunk engolir três funções não relacionadas. Tickets de suporte ao cliente perdem todo o fio narrativo sem sobreposição entre os segmentos. O resultado é previsível: latência inflada, recall fraco e respostas que forçam o gerador a alucinar.
Nós destruímos nossa camada de recuperação e a reconstruímos. O resultado foi um salto no recall de 78% para 95%, um corte de 62% na latência e um pipeline que finalmente se comporta como uma infraestrutura real, em vez de um "hack" de fim de semana. Aqui está o que realmente funcionou.
Chunking Inteligente: Estrutura sobre Tokens
O primeiro erro é assumir que cada documento fala a mesma língua. Um chunk de 512 tokens faz sentido para prosa narrativa e quase em nenhum outro lugar. Mudamos para uma estratégia que respeita a anatomia da fonte.
Para documentos jurídicos, usamos chunking recursivo. O algoritmo primeiro tenta dividir em fronteiras de alto nível, como seções e artigos. Se uma seção ainda for muito longa, ele procura por subseções, depois parágrafos e, então, frases. Isso preserva o aninhamento lógico das cláusulas. Um acordo de não concorrência permanece intacto. Definições não se misturam com termos de indenização.
A documentação de API exige um chunking consciente da estrutura. Uma assinatura de função, sua tabela de parâmetros e sua requisição de exemplo pertencem ao mesmo conjunto. Dividir após uma contagem fixa de tokens geralmente deixa os parâmetros em um chunk e os exemplos em outro. Em vez disso, fazemos o chunking por objeto de documento. Um chunk contém um endpoint completo ou uma única função. O recuperador pode, então, retornar uma referência autocontida que realmente responde à pergunta.
Tickets de suporte se adaptam naturalmente ao chunking semântico. Em vez de cortar em um limite de tokens, detectamos onde o tópico muda. Um ticket que começa com uma reclamação de login e muda para uma questão de faturamento é dividido em duas partes coerentes. Cada parte carrega os metadados de que precisa, e o modelo não precisa mais adivinhar qual problema o usuário realmente deseja resolver.
Wikis internas são mais bagunçadas. Elas misturam prosa, tabelas, diagramas e threads incorporadas. Para estas, usamos chunking agêntico. Um modelo de linguagem pequeno lê antecipadamente e decide onde termina uma unidade tematicamente completa. Custa um pouco mais no tempo de ingestão, mas elimina o trabalho manual de ajustar regras para cada novo formato de página.
Recuperação Híbrida: Cubra Todas as Bases
A busca vetorial é excelente para capturar significados imprecisos. Pergunte sobre uploads lentos e ela retornará alegremente parágrafos sobre latência e largura de banda. Mas ela é notória por estragar correspondências exatas. Se um desenvolvedor pesquisar pelo código de erro ERR_CONNECTION_REFUSED, os embeddings densos muitas vezes o tratarão como ruído genérico.
O BM25, o clássico algoritmo de palavras-chave, faz o oposto. Ele acerta strings precisas e termos raros, mas perde a nuance semântica. Uma consulta sobre assinar o acordo pode nunca trazer à tona conteúdo marcado com a execução do contrato.