← Todos os posts
ProdutoDayanne Fernandes

Projetos de embeddings: um RAG melhor a partir das suas próprias buscas

Dayanne ao lado de documentos fluindo para a gema da ReOpenly: "RAG ainda ruim? Ajuste seus embeddings"

Os projetos de embeddings chegaram à ReOpenly: faça o fine-tuning de um modelo de embeddings com os seus dados, e nós hospedamos para você chamar com o SDK da OpenAI. Ajustar ajuda a busca a achar o trecho certo: o Google Cloud mediu até 41% de melhora na busca (12% em média) em testes públicos, e a NVIDIA achou 10% mais trechos certos entre os 10 primeiros na própria documentação. No RAG, buscar melhor é responder melhor, porque o modelo só vê o que a busca encontra.

  • O que faz: transforma as buscas que o seu app já faz em dados de treino para o seu próprio modelo de embeddings.
  • Como: reporte uma busca, fique com os resultados que ajudaram, treine, hospede e chame com o SDK da OpenAI.
  • Quanto custa: reportar uma busca é grátis. Você paga só o tempo de GPU do treino.

O seu app faz busca numa base grande, ou usa RAG, e os resultados ainda são ruins? O seu modelo de embeddings pode ser genérico demais: ele encontra trechos parecidos com a pergunta, não os que a respondem. As suas próprias buscas sabem a diferença, e um projeto de embeddings transforma essas buscas em dados de treino.

Comece por aqui

Contas novas começam com créditos grátis. Antes de treinar qualquer coisa:

  1. Similarity. No Playground do projeto, digite uma pergunta da sua central de ajuda e três trechos. Em um minuto, o modelo base dá a cada trecho uma nota de quão perto ele está da pergunta.
  2. Vector. Cole seis textos curtos sobre três assuntos. O gráfico mostra quais textos o modelo coloca perto uns dos outros.
  3. Search feedback. Envie 20 buscas reais do seu servidor, com os resultados que você mostrou. Reportar é grátis. Revise algumas: esses são os seus primeiros dados de treino.

Treine só depois de revisar algumas buscas. Antes de trocar, compare o modelo ajustado com o modelo base em buscas que você separou para teste.

Os mesmos três passos, e essa comparação, rodam em código no cookbook da ReOpenly (em inglês): um script Python e um comando para cada um, e um notebook com os quatro. Ele usa o modelo base público, as requisições de embeddings gastam créditos, e nada ali inicia um treino.

O que é um projeto de embeddings

Você escolhe o tipo ao criar o projeto, e ele nunca muda. Um projeto de embeddings tem:

  • Dois modelos base que você já pode chamar antes de qualquer fine-tuning: ReOpenly/Qwen3-Embedding-0.6B (vetores de 1.024 números) e ReOpenly/Qwen3-Embedding-4B. Abra Hosted models, clique em Use model e copie o exemplo em Python, cURL ou JavaScript com a URL do seu projeto.
  • Exemplos de treino: uma pergunta, um trecho que a responde e, se quiser, um trecho que parece relacionado mas não responde. É com esse quase acerto que o modelo mais aprende. Até 20 datasets por projeto, com tags para escolher com o que cada treino aprende.
  • Treinos, modelos hospedados e um Playground, os mesmos passos de um projeto de texto.

Como se compara com os modelos em que o RAG costuma rodar

A maioria dos RAGs começa num modelo genérico: o text-embedding-3-small ou -large da OpenAI por uma API, ou um modelo aberto como o all-MiniLM-L6-v2 (207 milhões de downloads no Hugging Face nos últimos 30 dias), o bge-m3 ou o nomic-embed-text. Duas coisas diferenciam um projeto de embeddings:

  • Dá para ajustar. A OpenAI não lista nenhum modelo de embeddings entre os que aceitam fine-tuning, e a plataforma de fine-tuning dela está fechando: "a plataforma não está mais acessível a novos usuários" (OpenAI). Dá para ajustar um modelo aberto se você mesmo rodar o treino e hospedar o modelo. Um projeto de embeddings faz os dois por você.
  • Começa de uma base forte. Nas tarefas de busca (recuperação) do benchmark multilíngue do MTEB, um teste público de modelos de embeddings, o Qwen3-Embedding-4B tem 69,60 e o 0.6B tem 64,65, contra 59,32 do text-embedding-3-large e 54,59 do BGE-M3. A ordem é a mesma no benchmark em inglês do MTEB, no BEIR e nas tarefas públicas do RTEB, o benchmark de busca mais novo do MTEB.

Modelo

MTEB multilíngue, busca (18 tarefas)

Ajustar com os seus dados

Qwen3-Embedding-4B (base de um projeto de embeddings)

69,60

sim, no projeto

Qwen3-Embedding-0.6B (base de um projeto de embeddings)

64,65

sim, no projeto

OpenAI text-embedding-3-large

59,32

não

BGE-M3

54,59

se você rodar o treino

São os resultados públicos dos modelos base no MTEB, rodados pelos próprios autores com o código aberto do benchmark; nós recalculamos a partir dos resultados públicos em 19/10/2026. Não são medidas nossas. Servimos as duas bases Qwen3 com até 512 tokens por entrada, e quanto um modelo ajustado ganha nos seus dados é você quem mede.

Três jeitos de conseguir pares de treino

Importe. Envie um arquivo CSV ou JSONL com as colunas anchor (a pergunta), positive (um trecho que a responde) e, se quiser, negative (um quase acerto). Confira como as colunas foram ligadas e confirme. As linhas entram em segundo plano.

Salve enquanto testa. No Search do Playground, monte um índice a partir de um dataset, faça uma busca e salve como par de treino um resultado que você marcar.

Colete das buscas reais. Depois que o seu app ordena os resultados, o seu servidor envia a busca e os resultados que ela mostrou (até 20, em ordem) para o endpoint de Search feedback do dataset. A ReOpenly guarda esse texto, sem vetores. Ela nunca se conecta ao seu índice e nunca cobra para reportar. Cada busca espera numa caixa de entrada. Marque como Positive os resultados que respondem à busca, e o resultado mais bem colocado que você não manteve vira o negativo difícil: o quase acerto. Um clique adiciona esse exemplo de treino ao seu dataset, com a tag retrieval_feedback. Nada vira dado de treino sem a sua revisão, e nenhuma nota escolhe um rótulo.

Por que as suas buscas? Uma chamada de embeddings só tem texto, não qual resultado respondeu à busca. As buscas dos seus usuários, e os resultados que ajudaram de verdade, são os melhores dados de treino para um modelo de busca.

Treine com o que você manteve

Comece um treino com um dataset, ou com uma tag como retrieval_feedback. Cerca de um décimo dos exemplos fica separado para conferir o treino, em grupos inteiros que não dividem texto com o resto, então o modelo nunca treina com eles. Você escolhe as configurações dentro dos limites que o projeto mostra: o tamanho do lote (o resto do lote conta como respostas erradas, então um lote maior é uma lição mais difícil), a taxa de aprendizado, uma instrução colocada antes de cada pergunta, o tamanho do vetor, a maior entrada e mais.

Antes de começar, você vê a divisão e o máximo que o treino pode custar. Você paga só o tempo de GPU do treino, então um treino que não chega a treinar é grátis. O treino guarda a versão do modelo (um checkpoint) que foi melhor nos exemplos separados. Essa nota escolhe a versão; ela não mede quão bem o modelo busca, então compare modelos no Playground antes de trocar.

Hospede e chame

Quando o treino termina com sucesso, hospede o modelo com um nome à sua escolha. Ele responde à API de embeddings da OpenAI na URL base do seu projeto, então para trocar você muda o base_url e o nome do model:

from openai import OpenAI

client = OpenAI(base_url="https://reopenly.com/api/projects/<owner>/<project>/openai/v1", api_key="<sua chave>")
vectors = client.embeddings.create(
model="docs-retriever",
input=["Quanto tempo leva para o reembolso chegar?"],
extra_body={"input_type": "query"},
)

Envie input_type query para perguntas e document para trechos. Depois, gere de novo os vetores dos seus documentos com o novo modelo, porque vetores de modelos diferentes não se comparam. Você também pode baixar o adaptador treinado (o pequeno complemento que o treino gerou), com um checksum de cada arquivo.

O que outros mediram

São resultados de outras equipes com os próprios dados, não da ReOpenly. Cada uma ajustou um modelo de embeddings com exemplos da sua área e mediu a qualidade da busca antes e depois.

Quem

O que ajustou

Qualidade da busca antes → depois

Google Cloud

modelos de embeddings de texto, benchmarks públicos de busca

até +41% de qualidade, 12% em média

NVIDIA

um modelo de embeddings de 1B na própria documentação

Recall@10 0,630 → 0,693 (+10,0%); NDCG@10 +10,9%

NVIDIA, no mesmo post: Atlassian

a mesma receita nos dados do Jira

Recall@60 0,751 → 0,951 (+26,6%)

Databricks

gte-large no FinanceBench, treinado com perguntas que um LLM escreveu a partir dos documentos

Recall@10 0,293 → 0,552

Recall@10: a parte dos trechos certos que aparece entre os 10 primeiros (Recall@60: os 60 primeiros). O NDCG@10 também conta a posição dela.

O seu ganho vai depender dos seus dados, das suas buscas e do modelo base. A própria Databricks diz isso: em outros dois datasets os ganhos foram pequenos ou nulos, porque o fine-tuning funciona melhor "quando a recuperação é claramente o gargalo".

Limites e custos

Reportar uma busca

grátis; até 20 resultados por busca, 60 requisições por minuto por dataset

Similarity e Vector no Playground

cobrados como requisições de embeddings, como na API

Treino

você paga só o tempo de GPU do treino; você vê o máximo antes de começar

Requisições de embeddings

até 512 tokens por entrada (um modelo treinado com entradas maiores aceita até o tamanho do treino, no máximo 2.048); até 64 entradas e 32.768 tokens por requisição

Seus dados

as buscas reportadas ficam guardadas até você pedir para apagar; você pode editar ou apagar os seus pares de treino

Um modelo ajustado nem sempre é melhor em toda busca. Comece pelo modelo base, colete buscas reais e compare os dois em buscas que você separou antes de trocar.

Comece com créditos grátis

Crie uma conta: contas novas começam com créditos grátis. O guia rápido de embeddings mostra um projeto inteiro pela API. O Search feedback lista cada campo e limite, e as importações de dataset listam os formatos de arquivo.

Qual busca do seu produto você treinaria primeiro?

Fontes