← All posts

Embedding projects: better RAG from your own searches

Dayanne beside documents streaming into the ReOpenly gem: "RAG still bad? Tune your embeddings"

Embedding projects are live on ReOpenly: fine-tune an embedding model on your own data, and we host it for you to call with the OpenAI SDK. Tuning helps search find the right passage: Google Cloud measured up to 41% better search results (12% on average) on public tests, and NVIDIA found 10% more right passages in the top 10 on its own docs. In RAG, better search means a better answer, because the model only sees what search finds.

  • What it does: turns the searches your app already runs into training data for your own embedding model.
  • How: report a search, keep the results that helped, train, host, and call it with the OpenAI SDK.
  • What it costs: reporting a search is free. You pay only for GPU training time.

Does your app search a big database, or run RAG, and the results are still bad? Your embedding model may be too generic: it finds passages that look similar to the question, not the ones that answer it. Your own searches know the difference, and an embedding project turns them into training data.

Try this first

New accounts start with free credits. Before you train anything:

  1. Similarity. In the project's Playground, type a question from your own help center and three passages. In a minute, the base model gives each passage a score for how close it is.
  2. Vector. Paste six short texts about three topics. The chart shows which ones the model puts close together.
  3. Search feedback. Send 20 real searches from your server, with the results you showed. Reporting is free. Review a few: that is your first training data.

Train only after you have reviewed some searches. Before you switch, compare the tuned model with the base model on searches you kept aside for testing.

The same three steps, and that comparison, run from code in the ReOpenly cookbook: one Python script and one command each, and a notebook with all four. It uses the public base model, embedding requests use credits, and nothing in it starts training.

What an embedding project is

You pick the type when you create the project, and it never changes. An embedding project has:

  • Two base models you can call before any fine-tune: ReOpenly/Qwen3-Embedding-0.6B (vectors of 1,024 numbers) and ReOpenly/Qwen3-Embedding-4B. Open Hosted models, press Use model, and copy the Python, cURL or JavaScript example with your project's URL.
  • Training examples: a question, a passage that answers it and, if you want, a passage that looks related but does not answer it. That near miss is what the model learns the most from. Up to 20 datasets per project, with tags to pick what a run trains on.
  • Training runs, hosted models and a Playground, the same steps as a text project.

How it compares with the models RAG usually runs on

Most RAG setups start on a general model: OpenAI's text-embedding-3-small or -large through an API, or an open model such as all-MiniLM-L6-v2 (207 million downloads on Hugging Face in the last 30 days), bge-m3 or nomic-embed-text. Two things set an embedding project apart:

  • You can tune it. OpenAI lists no embedding model among the models you can fine-tune, and its fine-tuning platform is closing: "The platform is no longer accessible to new users" (OpenAI). You can tune an open model if you run the training and the hosting yourself. An embedding project does both for you.
  • It starts from a strong base. On the retrieval (search) tasks of the multilingual benchmark of MTEB, a public test of embedding models, Qwen3-Embedding-4B scores 69.60 and the 0.6B scores 64.65, against 59.32 for text-embedding-3-large and 54.59 for BGE-M3. The order is the same on MTEB's English benchmark, on BEIR and on the public tasks of RTEB, MTEB's newer search benchmark.

Model

MTEB multilingual, retrieval (18 tasks)

Tune it on your data

Qwen3-Embedding-4B (an embedding project base)

69.60

yes, in the project

Qwen3-Embedding-0.6B (an embedding project base)

64.65

yes, in the project

OpenAI text-embedding-3-large

59.32

no

BGE-M3

54.59

if you run the training yourself

These are the base models' public MTEB results, run by their makers with the benchmark's open code; we recomputed them from its public results on October 19, 2026. They are not our measurement. We serve both Qwen3 bases with up to 512 tokens per input, and what a tuned model gains on your data is yours to measure.

Three ways to get training pairs

Import them. Upload a CSV or JSONL file with anchor (the question), positive (a passage that answers it) and optional negative (a near miss) columns. Check how the columns map, and confirm. The rows are added in the background.

Save them while you test. In the Playground's Search, build an index from a dataset, run a search, and save a result you mark as a training pair.

Collect them from real searches. After your app ranks its results, your server sends the query and the results it showed (up to 20, in order) to the dataset's Search feedback endpoint. ReOpenly stores that text, no vectors. It never connects to your index and never charges for reporting. Each search waits in an inbox. Mark the results that answer the query as Positive, and the highest-ranked result you did not keep becomes the hard negative: the near miss. One click adds that training example to your dataset, tagged retrieval_feedback. Nothing becomes training data until you review it, and a score never picks a label.

Why your own searches? An embedding call only holds text, not which result answered the query. Your users' searches, and the results that really helped, are the best training data for a search model.

Train on what you kept

Start a run on a dataset, or on a tag such as retrieval_feedback. About a tenth of the examples are kept aside to check the training, in whole groups that share no text with the rest, so the model never trains on them. You choose the settings within the limits the project shows: the batch size (the rest of a batch counts as wrong answers, so a bigger batch is a harder lesson), the learning rate, an instruction put before every query, the vector size, the longest input, and more.

Before you start, you see the split and the most the run can cost. You pay only for GPU training time, so a run that never starts training is free. The run keeps the version of the model (a checkpoint) that did best on the examples kept aside. That score picks the version; it does not measure how well the model searches, so compare models in the Playground before you switch.

Host it and call it

When the run succeeds, host the model under a name you choose. It answers the OpenAI embeddings API at your project's base URL, so to switch you change the base_url and the model name:

from openai import OpenAI

client = OpenAI(base_url="https://reopenly.com/api/projects/<owner>/<project>/openai/v1", api_key="<your key>")
vectors = client.embeddings.create(
model="docs-retriever",
input=["How long do refunds take to arrive?"],
extra_body={"input_type": "query"},
)

Send input_type query for questions and document for passages. Then embed your documents again with the new model, because vectors from different models cannot be compared. You can also download the trained adapter (the small add-on the training produced), with a checksum for every file.

What others measured

These are other teams' results on their own data, not ReOpenly's. Each tuned an embedding model on examples from its field and measured search quality before and after.

Who

What they tuned

Search quality before → after

Google Cloud

text embedding models, public retrieval benchmarks

up to +41% quality, 12% on average

NVIDIA

a 1B embedding model on its own documentation

Recall@10 0.630 → 0.693 (+10.0%); NDCG@10 +10.9%

NVIDIA, same post: Atlassian

the same recipe on its Jira data

Recall@60 0.751 → 0.951 (+26.6%)

Databricks

gte-large on FinanceBench, trained on queries an LLM wrote from the documents

Recall@10 0.293 → 0.552

Recall@10: the share of the right passages found in the top 10 (Recall@60: the top 60). NDCG@10 also counts its rank.

Your gain will depend on your data, your queries and your base model. Databricks says so too: on two other datasets its gains were small or none, because "finetuning works best when retrieval is a clear bottleneck".

Limits and costs

Reporting a search

free; up to 20 results per search, 60 requests a minute per dataset

Playground Similarity and Vector

billed as embedding requests, like the API

Training

you pay only for GPU training time; you see the most it can cost before you start

Embedding requests

up to 512 tokens per input (a model trained on longer inputs accepts up to its training length, at most 2,048); up to 64 inputs and 32,768 tokens per request

Your data

reported searches are kept until you ask us to erase them; you can edit or delete your training pairs

A fine-tuned model is not always better on every query. Start with the base model, collect real searches, and compare the two on searches you kept aside before you switch.

Start with free credits

Create an account: new accounts start with free credits. The quickstart for embeddings shows a whole project from the API. Search feedback lists every field and limit, and Dataset imports lists the file formats.

Which search in your product would you train first?

Sources