Como escolher o modelo de embeddings do seu RAG testando com as perguntas reais do seu produto

Fala aí, beleza? Pra escolher o modelo de embeddings do seu RAG, o caminho mais confiável é montar de 20 a 30 perguntas reais do seu produto com o trecho correto já marcado, definir ANTES o critério de acerto (o trecho certo aparece entre os primeiros resultados?) e rodar os mesmos dados em cada modelo, lado a lado, junto com o custo de indexar o acervo

Se liga num detalhe: aqui a gente está mexendo na etapa de recuperação do RAG, não na geração da resposta

É outra métrica e outra decisão de compra, então o ranking do modelo que escreve bonito não te diz nada sobre qual modelo encontra o trecho certo 😉

E já deixo claro: esse método não promete ganho de precisão nenhum

Ele só mostra qual modelo funciona melhor NO SEU acervo, com as SUAS perguntas

O que você precisa antes de comparar modelos de embeddings

Você precisa de três coisas: o acervo já dividido em trechos, acesso às APIs que vai comparar e um lugar pra anotar os resultados

• Acervo em trechos (chunks): documentação, base de suporte, FAQ, o que for, já quebrado em pedaços com um ID cada
• Acesso à API de embeddings da OpenAI e à Gemini API: são os dois fornecedores comparados aqui
• Um script próprio ou uma planilha: pra guardar, pergunta por pergunta, em que posição o trecho certo apareceu em cada modelo

Que chunk? É só o pedaço de texto que vira um vetor e que a busca devolve como resultado

Se tu ainda não decidiu como cortar o acervo, decide antes do teste, porque esse corte precisa ser o mesmo pra todos os modelos (já já explico o porquê)

Tome cuidado com um atalho que parece óbvio: a plataforma de Evals hospedada da OpenAI não serve pra montar um teste novo agora

Segundo a página de deprecações da OpenAI, o aviso saiu em 3 de junho de 2026, a plataforma ficou somente leitura para quem já usava em 31 de outubro de 2026 e o painel e a API devem ser desligados em 30 de novembro de 2026

Ou seja, o teste vive no seu script ou na sua planilha, e isso é até bom: o gabarito fica com você, não preso numa plataforma

Quais modelos de embeddings entram no teste: dimensões, limite e preço

Os candidatos aqui são os modelos listados nas documentações oficiais da OpenAI e da Gemini API, com preço das páginas oficiais de cada fornecedor

Todos os valores estão em dólar, igual às páginas oficiais, sem conversão pra reais

Modelo	Dimensões padrão	Ajuste de dimensões	Entrada máxima	Entrada aceita	Preço por 1 milhão de tokens
text-embedding-3-small	1.536	parâmetro dimensions	8.192 tokens	texto	US$ 0,02
text-embedding-3-large	3.072	parâmetro dimensions	consulte a página do modelo	texto	US$ 0,13
gemini-embedding-2	3.072	output_dimensionality de 128 a 3.072 (recomendadas 1.536 ou 768)	8.192 tokens	texto, imagem, vídeo, áudio e PDF	US$ 0,20 (padrão) ou US$ 0,10 (Batch API)
gemini-embedding-001	3.072	recomendadas 1.536 ou 768	2.048 tokens	somente texto	US$ 0,15 (padrão) ou US$ 0,075 (Batch API)

Alguns pontos que a tabela não conta sozinha:

• A OpenAI descreve o text-embedding-3-large como o modelo de embeddings mais capaz dela para tarefas em inglês e em outros idiomas
• O gemini-embedding-2 é o primeiro modelo de embeddings multimodal do Google: texto, imagem, vídeo, áudio e PDF caem no mesmo espaço vetorial
• Ele entrou em prévia pública em março de 2026 e a versão estável está em disponibilidade geral desde 22 de abril de 2026
• O text-embedding-ada-002 ainda aparece na doc da OpenAI, mas como legado, então nem entra na comparação

Repara que "mais capaz" é a descrição do fornecedor, não um resultado no seu acervo em português

É justamente isso que o teste vai responder 🙂

Passo a passo para testar modelos de embeddings com as perguntas do seu produto

O roteiro é: gabarito, critério, chunking fixo, embeddings, busca lado a lado e custo

Os exemplos abaixo são didáticos, pra tu adaptar ao teu projeto, não resultados medidos

1. Monte o gabarito com perguntas reais

Separe de 20 a 30 perguntas que pessoas de verdade fizeram ao seu produto: tickets de suporte, buscas internas, dúvidas frequentes e por aí vai

Pra cada pergunta, marque à mão o ID do trecho que responde ela

pergunta,trecho_certo
"como cancelo minha assinatura?",faq-031
"o app funciona offline?",doc-112
"posso trocar o email da conta?",suporte-007

Resultado esperado: uma lista fechada de perguntas, cada uma com exatamente o trecho que deveria aparecer

O erro comum deste passo: inventar perguntas que copiam as palavras do trecho

Aí qualquer busca acerta, até a mais boba, e o teste para de separar um modelo do outro

Pergunta real costuma ser torta, curta, com outro vocabulário, e é isso que tu quer medir

2. Defina o critério de acerto antes de rodar

Escolha agora: o trecho certo precisa aparecer entre os primeiros k resultados, por exemplo top 3 ou top 5

A nota de cada modelo é a fração de perguntas que acertaram

# gabarito: pergunta -> id do trecho certo
# resultados_modelo: pergunta -> lista de ids na ordem devolvida pela busca

def acerto_top_k(gabarito, resultados_modelo, k):
    acertos = 0
    for pergunta, trecho_certo in gabarito.items():
        ids_devolvidos = resultados_modelo.get(pergunta, [])
        if trecho_certo in ids_devolvidos[:k]:
            acertos += 1
    return acertos / len(gabarito)

Resultado esperado: um k escrito no seu doc de teste antes de qualquer chamada de API

O erro comum deste passo: escolher o k depois de ver qual modelo ganha

Se no top 3 deu um e no top 5 deu outro, e você fica com o que te agrada, o teste virou torcida haha

3. Fixe o mesmo chunking para todos os modelos

Use exatamente os mesmos trechos, com os mesmos IDs, em todos os modelos

Se o corte muda, tu não sabe mais se a diferença veio do modelo ou do chunk

Resultado esperado: um único arquivo de trechos alimentando todos os modelos

O erro comum deste passo: trechos maiores que o limite de entrada do modelo

Isso pesa no gemini-embedding-001, que aceita até 2.048 tokens por entrada, e não nos modelos de 8.192 tokens (text-embedding-3-small e gemini-embedding-2)

Se o seu chunk passa disso, o 001 vai ficar em desvantagem por um motivo que não tem nada a ver com qualidade de busca

4. Gere os embeddings decidindo as dimensões

Gere os vetores dos trechos e das perguntas em cada modelo, usando os parâmetros oficiais de dimensão

• Nos text-embedding-3, o parâmetro é dimensions: o exemplo oficial do anúncio da OpenAI reduz o text-embedding-3-large de 3.072 para 1.024 dimensões
• No gemini-embedding-2, o parâmetro é output_dimensionality, com qualquer valor entre 128 e 3.072 (as opções recomendadas são 1.536 ou 768)

E por que mexer em dimensão? Porque vetor menor ocupa menos espaço no banco vetorial

Se tu quer saber se vale a pena encolher, inclua a versão reduzida como mais um candidato no teste, tipo "large com 1.024" lado a lado com "large com 3.072"

Resultado esperado: um conjunto de vetores por candidato (modelo + dimensão), todos gerados a partir dos mesmos trechos

O erro comum deste passo: enviar task_type para o gemini-embedding-2

Esse campo não pode ser usado com ele, mesmo que o gemini-embedding-001 aceitasse

Já vi muito código migrado copiando a chamada antiga, então caso tu esteja reaproveitando um script do 001, remove esse campo

5. Rode a busca e registre lado a lado

Pra cada pergunta do gabarito, faça a busca em cada candidato e anote em que posição o trecho certo apareceu (ou "não apareceu")

pergunta,trecho_certo,3-small,3-large,gemini-2,gemini-001
"como cancelo minha assinatura?",faq-031,2,1,1,4
"o app funciona offline?",doc-112,não apareceu,3,2,não apareceu

Os números dessa planilha são só pra mostrar o formato, beleza?

Com a posição registrada, tu calcula o acerto no top k que definiu no passo 2 sem precisar rodar nada de novo

Checagem: toda pergunta tem resultado registrado para todos os modelos

Se uma linha ficou em branco, a nota daquele modelo está sendo calculada sobre menos perguntas que a dos outros, e a comparação fica injusta

6. Calcule o custo de indexar o acervo

A conta é simples: total de tokens do acervo vezes o preço por 1 milhão de tokens de cada modelo

A conta por modelo fica assim, com N sendo o total de tokens do acervo em milhões:

text-embedding-3-small: N x US$ 0,02
text-embedding-3-large: N x US$ 0,13
gemini-embedding-2:     N x US$ 0,20 (padrão) ou N x US$ 0,10 (Batch API)
gemini-embedding-001:   N x US$ 0,15 (padrão) ou N x US$ 0,075 (Batch API)

O desconto da Gemini vem da Batch API, que processa os pedidos de forma assíncrona pela metade do preço padrão, com prazo-alvo de entrega de 24 horas, e aceita os modelos de embeddings

Isso casa MUITO bem com indexação, que pode esperar

Já a consulta do usuário, que precisa de resposta na hora, não tem como ficar esperando um lote

Resultado esperado: uma coluna de custo ao lado da coluna de acerto, pra cada candidato

O erro comum deste passo: olhar só a nota de acerto e ignorar o custo de reindexar

O acervo cresce, o chunking muda, um modelo novo sai… e a cada vez a conta de indexar volta

Como decidir qual modelo de embeddings usar depois do teste

A decisão depende do que o seu gabarito mostrou, não de qual fornecedor tem o nome mais bonito

• Empatou no critério definido? O mais barato ou o de menos dimensões tende a ser a escolha sensata, porque vetor menor ocupa menos espaço no banco
• Um acertou claramente mais perguntas? Compare essa diferença com o custo de indexar, porque acertar mais perguntas do gabarito pode ou não valer a diferença de preço no seu volume
• O acervo tem PDF, imagem, áudio ou vídeo? O gemini-embedding-2 é o único candidato da lista que coloca tudo isso no mesmo espaço vetorial

E tem um detalhe que pega muita gente: trocar de modelo exige reindexar o acervo INTEIRO

Vetores de modelos diferentes não se misturam, é como tentar comparar endereço de um mapa com coordenada de outro, cada um tem seu próprio sistema

Por isso a decisão de embeddings é mais "casamento" do que a do modelo de geração, que tu troca numa linha de config

Pra parte da geração, vale passar pelo checklist de escolha de LLM, que olha outros critérios

Antes de culpar o modelo, olhe o sistema inteiro

Esse teste tem tudo a ver com uma ideia que aparece bastante aqui no canal: muitas vezes o problema não é o modelo, é o que está em volta dele

No vídeo abaixo, o assunto é o Better Harness e como enxergar onde um agente falha de verdade, um conteúdo complementar pra quem curte esse jeito de investigar antes de trocar de ferramenta

Próximo passo: monte o gabarito antes de abrir qualquer API

Separa hoje as 20 a 30 perguntas reais com o trecho correto marcado, mesmo que tu ainda nem tenha chave de API configurada

Esse gabarito é o ativo que fica: sempre que sair um modelo de embeddings novo, tu roda ele contra as mesmas perguntas e compara com o que já tem na planilha

E quando a recuperação estiver resolvida, dá pra levar o mesmo método pra etapa de geração do RAG, com as mesmas perguntas reais 😀

Até o próximo post!

Perguntas frequentes

O custo da busca em produção (query) é calculado do mesmo jeito que o custo de indexar?

O preço por token é o mesmo, mas o volume é bem menor: você paga pra indexar o acervo inteiro (e de novo a cada reindexação), enquanto cada busca do usuário gera só os tokens daquela pergunta. Por isso a conta de custo do teste foca na indexação, que é o gasto que pesa de verdade no orçamento.

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.