Embeddings em português: como escolher e testar um modelo

Embeddings em português: como escolher e testar um modelo

Para escolher embeddings em português, não parta de um ranking público. Monte um conjunto de consultas reais da sua empresa, marque a resposta certa para cada uma e compare os modelos pelo acerto de recuperação nos seus próprios documentos. O melhor modelo é o que encontra o trecho correto para as perguntas dos seus clientes e da sua equipe, mesmo que não lidere nenhuma tabela.

Principais pontos

• Ranking público mede tarefas e textos genéricos. Seus documentos, seu vocabulário e suas siglas internas é que decidem o resultado na prática.
• O ativo mais valioso do teste é o conjunto de consultas reais, com a fonte correta marcada por quem conhece o negócio.
• Compare modelos por métricas de recuperação simples (o trecho certo aparece entre os primeiros resultados?) antes de olhar a resposta final de qualquer IA.
• Custo, latência, local de processamento dos dados e implicações da LGPD entram na decisão junto com o acerto.
• Trate a escolha como reversível: guarde o conjunto de teste e repita a comparação quando trocar de modelo ou de base de documentos.

Por que um ranking público não decide por você?

Um modelo de embeddings transforma um texto em uma lista de números que representa o seu significado. Textos com sentido parecido ficam próximos nesse espaço, e é isso que permite que uma busca encontre "segunda via do boleto" quando o documento fala em "reemissão de cobrança". Esse mecanismo é a base da etapa de recuperação em sistemas de geração aumentada por recuperação (RAG), descritos na documentação da AWS sobre RAG e na arquitetura de referência do Google Cloud.

O problema de escolher só pelo ranking é que ele responde a outra pergunta. Benchmarks públicos reúnem tarefas diversas, em geral com textos de domínio aberto, e muitos têm cobertura limitada de português brasileiro. Mesmo quando cobrem, o seu caso tem particularidades que nenhuma tabela captura:

• Vocabulário próprio: códigos de produto, siglas, nomes de planos, termos técnicos do setor.
• Registro informal: mensagens de WhatsApp com abreviações, erros de digitação e áudio transcrito.
• Variação regional e jargão: o mesmo item tem nomes diferentes conforme a região ou a equipe.
• Formato dos documentos: tabelas, PDFs mal extraídos, contratos longos, manuais com numeração.

Um modelo pode ir muito bem em um ranking e tropeçar justamente nas siglas do seu catálogo. Outro, menos cotado, pode se sair melhor porque seus documentos são curtos e diretos. Só medir com os seus dados responde isso.

Isso é uma hipótese de trabalho, não uma regra: rankings continuam úteis para montar uma lista inicial de candidatos. O erro é usá-los como decisão final.

Como montar o conjunto de consultas reais?

O conjunto de consultas é uma lista de perguntas que as pessoas de fato fazem, cada uma ligada ao documento ou trecho que deveria ser encontrado. Ele é o ativo central do teste, e vale mais que qualquer modelo individual. Siga este passo a passo:

• Defina o fluxo. Escolha um uso concreto, como dúvidas de clientes no atendimento, consulta de políticas internas ou busca em contratos. Um conjunto por fluxo, porque misturar usos esconde diferenças.
• Colete consultas de fontes reais. Use histórico de atendimento, perguntas repetidas da equipe, e-mails e mensagens, sempre com autorização e dentro da finalidade original dos dados.
• Anonimize. Remova nomes, CPF, telefones, endereços e qualquer dado pessoal que não seja necessário para o teste. Se não for possível, rode a comparação em ambiente controlado.
• Inclua a bagunça. Mantenha abreviações, erros de grafia, frases incompletas e perguntas vagas. É assim que elas chegam na prática.
• Marque a resposta certa. Para cada consulta, uma pessoa que conhece o negócio indica qual documento ou trecho responde. Algumas consultas podem ter mais de um trecho válido.
• Inclua perguntas sem resposta. Separe consultas cuja informação não existe na base. Um bom sistema precisa saber que não encontrou nada relevante.
• Congele uma parte. Reserve consultas que ninguém usa para ajustar parâmetros, para evitar que você otimize o teste em vez do sistema.

O tamanho certo é o suficiente para que a equipe consiga revisar tudo com cuidado. Algumas dezenas de consultas bem rotuladas já mostram diferenças relevantes entre modelos. Se a diferença entre dois candidatos aparecer em poucos casos, é sinal de que eles são equivalentes para o seu uso, e a decisão deve passar a depender de custo e operação.

Um detalhe que costuma ser esquecido: a rotulagem deve ser feita por quem responde essas perguntas no dia a dia, não por quem constrói o sistema. Quem constrói tende a marcar o que o sistema já acerta.

Quais métricas usar e como rodar a comparação?

Meça a recuperação separadamente da resposta final. Se você avalia só o texto que a IA gera, não sabe se o erro veio da busca ou da geração. Três medidas simples resolvem a maior parte dos casos:

• Acerto nos primeiros k resultados: em que proporção das consultas o trecho correto aparece entre os k primeiros retornados. Escolha k conforme quantos trechos o seu sistema realmente envia ao modelo de linguagem.
• Posição do primeiro acerto: o trecho certo vem em primeiro lugar ou escondido lá embaixo? Isso importa quando o contexto enviado é pequeno.
• Taxa de falso encontro: nas consultas sem resposta na base, com que frequência o sistema devolve algo que parece relevante, mas não é.

A mecânica da comparação é direta. Indexe exatamente os mesmos documentos com cada modelo candidato, usando o mesmo tamanho de trecho e a mesma estratégia de divisão. Rode todas as consultas, registre os resultados e calcule as medidas. Mude uma variável por vez: se você troca o modelo e o tamanho dos trechos ao mesmo tempo, não sabe o que causou a diferença.

Depois olhe os erros um a um. Planilhas com médias escondem padrões que a leitura revela: o modelo falha em siglas, em perguntas negativas ("quando não posso trocar"), em números, em consultas muito curtas. Essas falhas dizem se o problema se resolve com outra estratégia de busca, por exemplo combinar busca por palavras-chave com busca semântica, ou se exige trocar o modelo.

Para estruturar a avaliação como rotina, os guias de evals da OpenAI e o texto da Anthropic sobre avaliações para agentes de IA ajudam a pensar em casos de teste, critérios claros e repetição. Eles não tratam especificamente de embeddings, mas a lógica de conjunto fixo, métrica definida e revisão de falhas se aplica.

Cenário ilustrativo: busca de políticas em uma empresa de serviços

Cenário ilustrativo: uma empresa de serviços com atendimento por WhatsApp quer que um agente consulte a base de políticas (trocas, prazos, garantias, regras de reagendamento) para apoiar os atendentes. Três modelos de embeddings entram na comparação: um multilíngue amplamente usado, um modelo de um provedor em nuvem e um modelo aberto que poderia rodar na infraestrutura própria.

A equipe de operações reúne perguntas reais do histórico de atendimento, já sem dados pessoais. Entram frases como "posso remarcar de última hora?", "qual o prazo pra reembolso" e "cobrança duplicada". A líder do atendimento marca, para cada pergunta, o trecho da política que responde. Ela também separa algumas perguntas que a base não cobre.

Os três modelos indexam a mesma base. Na leitura dos erros, a equipe percebe que um deles confunde "reembolso" com "estorno", dois termos que a empresa trata como processos diferentes, enquanto outro erra perguntas muito curtas. O terceiro tem desempenho parecido com o primeiro, mas exige operar a própria infraestrutura.

A decisão, nesse cenário, não sai de uma tabela: sai de uma combinação de acerto nas consultas mais frequentes, comportamento nas perguntas sem resposta e esforço de operação. Se os dois melhores empatarem no acerto, o critério de desempate passa a ser custo, latência e onde os dados são processados.

Que critérios além do acerto entram na decisão?

Depois do acerto de recuperação, vários fatores práticos definem qual modelo vai para o piloto. Use esta lista como guia de decisão:

• Onde os dados são processados. Enviar textos a uma API externa significa transferir conteúdo da empresa, às vezes com dados pessoais, a um terceiro. Verifique os termos do provedor sobre retenção e uso dos dados, e compare com a alternativa de rodar um modelo aberto internamente. O texto sobre LLM local ou API tem um raciocínio parecido.
• Papéis na LGPD. Se o provedor processa dados pessoais em nome da empresa, o contrato precisa refletir isso. Vale revisar quem é operador e quem é controlador e avaliar se o projeto pede um RIPD. Dúvidas regulatórias específicas devem passar pelo jurídico, e a ANPD é a referência oficial.
• Custo de indexar e de consultar. Considere o volume de documentos, a frequência de atualização e quantas consultas por dia o sistema receberá. Reindexar toda a base ao trocar de modelo também tem custo de tempo.
• Latência. Em atendimento ao vivo, a busca precisa ser rápida o bastante para não atrasar a resposta.
• Tamanho máximo de texto. Modelos aceitam entradas de tamanhos diferentes, o que afeta como você divide documentos longos.
• Dependência e continuidade. Se o provedor descontinuar o modelo, você precisará reindexar. Guardar o conjunto de teste torna essa troca uma comparação, não um susto.

Nenhum desses itens aparece em ranking público, e todos podem inverter a escolha entre dois modelos com acerto parecido.

Como aplicar isso com método e manter a escolha?

O raciocínio segue as quatro etapas do método que usamos em projetos de IA: mapear, limitar, pilotar e transferir.

• Mapear: descreva o fluxo atual, quem pergunta o quê, onde a resposta está hoje e como o erro acontece. Esse mapa gera o conjunto de consultas e o ponto de partida para comparar depois.
• Limitar: restrinja os dados que entram no teste e na base indexada. Comece por documentos que não contenham dados pessoais e amplie só se houver necessidade e base legal.
• Pilotar: coloque o modelo escolhido em um fluxo real, com registro das consultas e dos trechos recuperados, e uma métrica de sucesso combinada antes. O artigo sobre como medir um piloto de automação com IA detalha critérios de decisão para continuar, ajustar ou parar.
• Transferir: entregue o conjunto de teste, o procedimento de comparação e o critério de troca à equipe responsável, para que a empresa não dependa de quem montou.

Depois do piloto, trate o conjunto de consultas como um teste de regressão. Sempre que mudar o modelo, o tamanho dos trechos ou a base de documentos, rode de novo e compare. A lógica é a mesma descrita em testes de regressão de prompts no CI: sem um conjunto fixo, a piora passa despercebida. Aproveite também as consultas que falharam em produção, com revisão humana, para ampliar o conjunto ao longo do tempo.

Perguntas frequentes

Qual é o melhor modelo de embeddings para português? Não existe um melhor em geral. Modelos multilíngues costumam ser um bom ponto de partida, mas o desempenho depende do seu vocabulário, do formato dos documentos e do tipo de pergunta. A forma confiável de saber é comparar candidatos com consultas reais da sua empresa.

Preciso de um modelo treinado especificamente em português? Nem sempre. Um modelo multilíngue pode atender bem se o teste com as suas consultas mostrar bom acerto, e um modelo específico para português pode não compensar se for pior nos seus documentos. Inclua os dois tipos entre os candidatos e deixe o resultado do teste decidir.

Quantas consultas preciso para o teste ser confiável? Não há número mágico, e depende da variedade do seu uso. Comece com o que a equipe consegue rotular com cuidado, cobrindo os assuntos mais frequentes e alguns casos difíceis, e amplie com o tempo. Se dois modelos ficarem próximos, aumentar o conjunto nos assuntos críticos ajuda a separar os candidatos.

Embeddings substituem a busca por palavras-chave? Nem sempre. A busca semântica ajuda quando as palavras da pergunta diferem das do documento, mas códigos, siglas e nomes exatos costumam ser mais bem atendidos por busca textual. Muitas vezes a melhor solução combina as duas, e o seu conjunto de consultas mostra se essa combinação melhora o acerto.

Fontes

• AWS: What is retrieval-augmented generation
• Google Cloud: retrieval-augmented generation architecture
• OpenAI: evals guide
• Anthropic: Demystifying evals for AI agents