RAG vs fine-tuning em modelos de linguagem: qual escolher para seu caso de uso e como medir resultados
Se você está cansado de resultados de busca que retornam “mais do mesmo” e não entendem a intenção real do usuário, implementar busca semântica com embeddings e vetores no seu produto é o atalho para relevância, retenção e conversão em 2026. Neste guia, você vai aprender, passo a passo, como usar PostgreSQL com pgvector e OpenAI para indexar, consultar e otimizar resultados que entendem contexto, sinônimos e relações conceituais — e não apenas palavras exatas.
O objetivo aqui é prático: do planejamento ao deploy, com decisões arquiteturais que evitam dores típicas de quem começa (dimensão errada do vetor, índices mal configurados, latência explosiva e custos imprevisíveis).
Embeddings são representações numéricas (vetores) de textos, códigos ou imagens em um espaço de alta dimensão. Dois textos “próximos” nesse espaço têm significados parecidos. Na prática, consultas como “como redefinir minha senha” podem recuperar conteúdos com “esqueci minha senha”, mesmo sem termos idênticos.
O mecanismo central é calcular a similaridade entre o vetor da consulta e os vetores dos documentos. Métricas comuns: cosine similarity e inner product. O que muda entre elas? A primeira olha o ângulo entre vetores (boa quando você normaliza os vetores), a segunda foca magnitude e direção (útil em alguns modelos).
Dica de ouro: se você quer consistência e evita surpresas, normalize embeddings em norma unitária e use similaridade do cosseno para ranqueamento. A padronização ajuda na estabilidade quando os dados crescem.
Para analogia rápida: pense num mapa 3D onde cada ponto é um documento. A busca semântica é “achar vizinhos mais próximos” do ponto da sua pergunta. O índice vetorial é a estrada mais curta até esses vizinhos.
Você pode construir uma pilha enxuta e robusta com três camadas:
Por que essa combinação? Postgres é maduro, transacional e fácil de operar. O pgvector traz o melhor dos mundos: índice vetorial na mesma base que guarda seus dados de domínio, simplificando consistência e deploy.
O erro mais comum é criar a coluna vetorial com dimensão diferente da dimensão emitida pelo modelo de embeddings. Defina a coluna vetorial como “vector(D)”, onde D é a dimensão real do modelo escolhido. Confirme essa dimensão antes da criação do schema.
Estrutura típica:
Busca exata (sem índice aproximado) é simples e precisa, porém lenta com muitos vetores. Para escalar, use aproximação com índices como HNSW ou IVFFlat disponibilizados pelo pgvector. Eles trocam um pouco de precisão por muita velocidade. Regra prática: se você tem poucos milhares de itens, o sequencial pode bastar; a partir de dezenas ou centenas de milhares, progrida para índice aproximado.
Parametrize o índice com testes controlados. Ajustes como número de vizinhos e profundidade de busca mudam latência e recall. Evite adivinhar: meça com seu dado real.
Embeddings funcionam melhor com chunks de tamanho consistente. Em documentos longos, divida em blocos por parágrafo, título ou limites de tokens. Guarde no metadado a posição do chunk e um identificador do documento original. Assim, você pode agrupar resultados e evitar fragmentos desconexos na resposta.
Boas práticas adicionais:
Implemente um pipeline idempotente: “extrair → limpar → chunkar → gerar embeddings → salvar”. Se a chamada aos embeddings falhar, retente com backoff e dead-letter queue simples (até uma tabela “failed_jobs” cumpre o papel). Ao salvar, prefira upsert para evitar duplicidades durante reprocessamentos.
Checklist essencial antes de persistir:
Modelos evoluem. Para não “quebrar” a busca, guarde um version_id do modelo. Ao trocar de modelo, processe em paralelo e promova a nova versão quando estiver satisfeito. Evite misturar dimensões diferentes na mesma coluna: migre com tabela ou coluna nova, e depois faça o switch.
O fluxo da busca é: gerar embedding da consulta, aplicar KNN search (“ORDER BY embedding <-> query_vector LIMIT k”) e retornar os candidatos. Ajuste k pensando no re-ranking: pegar 50 candidatos para reordenar e devolver 10 costuma oferecer bom balanço entre custo e qualidade.
Não jogue fora seus filtros relacionais. Aplique WHERE por idioma, categoria, visibilidade e datas antes (ou durante) o KNN, desde que seu índice e cardinalidade favoreçam o plano de execução. Em muitos casos, filtrar primeiro e depois ranquear reduz latência sem perder qualidade.
Combinar full-text search (BM25) com similaridade vetorial é uma forma pragmática de lidar com termos raros, códigos, siglas e nomes próprios. Estratégias comuns:
Insight prático: em bases técnicas com muito jargão, o híbrido corrige “pontos cegos” dos embeddings e reduz alucinações em fluxos de RAG.
MMR (Maximal Marginal Relevance) evita resultados redundantes. A cada item escolhido, penalize candidatos muito parecidos com os já selecionados. Isso melhora cobertura temática e enriquece respostas de RAG.
Crie um hash estável a partir do conteúdo normalizado do chunk. Antes de inserir, verifique se já existe. Isso evita reprocessar documentos apenas com pequenas variações cosméticas.
Para conteúdos longos, guarde também o título da seção e o título do documento junto ao chunk. Na apresentação, mostre o extrato com esses títulos. A percepção de qualidade sobe, mesmo quando a similaridade entre top-2 candidatos é parecida.
Latência vem de três fontes: geração da embedding da consulta, leitura no banco e re-ranking. Reduza picos com:
Os maiores vilões: reprocessamentos desnecessários e chunks mal dimensionados. Padronize o tamanho do chunk e faça debounce de atualizações de conteúdo (espere alguns minutos antes de re-embedar após edições frequentes). Monitore o custo por mil documentos e por mil consultas para enxergar tendências cedo.
Instrumente o pipeline de ingestão e as consultas com métricas e traces. Acompanhe P50/P95 de latência, taxa de acerto por categoria e erros por versão de embedding. Uma abordagem integrada de observabilidade full-stack com OpenTelemetry ajuda a localizar gargalos entre API de embeddings, banco e aplicação.
Evite enviar dados sensíveis para geração de embeddings. Aplique mascaramento e minimização. Armazene apenas o necessário para a busca e defina políticas de retenção e exclusão, especialmente em contas de usuários.
Guarde o texto do chunk, seu id, sua versão de embedding e o score final. Isso permite auditar por que um resultado apareceu e reproduzir investigações de qualidade quando algo foge do esperado.
Sinônimos muito raros: embeddings podem falhar em termos ultraespecíficos. Use híbrido com BM25 e dicionários de sinônimos do domínio.
Atualizações frequentes: em conteúdos que mudam o tempo todo, a defasagem entre alteração e re-embedding pode afetar a relevância. Mitigue com filas de alta prioridade e marcação de “conteúdo fresco”.
Entidades e números: datas, códigos e números de versão podem ser melhor tratados com campos estruturados e filtros, não apenas com semântica vetorial.
Portabilidade de modelo: trocar de modelo sem planejar pode exigir reprocessar toda a base. Antecipe com versionamento e migrações controladas.
Cosine similarity é uma escolha segura quando você normaliza os vetores em norma unitária. Inner product pode funcionar bem para alguns modelos, mas exige cuidado com magnitudes. Se a equipe não tem preferência, comece com cosseno.
O melhor tamanho depende do domínio, mas variações moderadas que retêm contexto (com título local e algumas frases) tendem a funcionar melhor do que trechos muito curtos ou muito longos. Padronize e meça impacto na precisão.
Não necessariamente. Se sua base é pequena e homogênea, o vetorial puro pode bastar. Em dados técnicos, com termos raros e siglas, o híbrido quase sempre melhora a cobertura.
Evite reprocessamentos, adote debounce em edições, aplique cache de consultas populares e monitore custo por mil documentos. Planeje migrações de modelo com provas de conceito pequenas antes de re-embedar tudo.
Sim. Guarde metadados suficientes para filtrar por público/nível de acesso e implemente re-ranking específico para cada caso de uso. Em RAG, priorize diversidade e cobertura; em busca do site, priorize precisão e frescor.
Pronto para dar o próximo passo? Aplique as práticas deste guia no seu projeto, deixe um comentário com os desafios que você encontrou e siga explorando outros materiais do appnoodles.com para evoluir sua stack de tecnologia com confiança.
