Turn any website into AI search with a RAG API in 60 seconds. Real Solr index, real vectors, real hybrid search — live, right now.

The three queries, exactly as they run

1. Keyword only — BM25, no vectors

A plain edismax query. Field boosts decide that a hit in the title counts more than one buried in the body.

GET /solr/<index>/select
  q   = {!edismax qf="title^3 description^2 text" v=$uq}
  uq  = your query text
  rows= 5
  fl  = title,uri,score

2. Vector only — pure kNN, no keywords

First the question becomes a vector, server side. Then that vector is the query. No word from your question is ever compared to any word in the documents.

POST /solr_manager/api/embed
  email, api_key, index_name, payload = your query text
  → 1024 floats

POST /solr/<index>/select        (POST, not GET)
  q  = {!knn f=embeddings topK=5}[0.0449,0.0160,-0.0324, ... ]
  fl = title,uri,score

3. Hybrid — what we actually serve

One query. The lexical side and the vector side are built as sub queries and fused per document inside our {!hybrid} parser, rather than being run twice and merged afterwards.

GET /solr/<index>/select
  lexicalRaw  = {!edismax qf="title^0.1 description^0.05 uri^0.01 text^0.01" mm="2<65% 4<50% 8<40%"}your query
  vectorQuery = {!knn f=embeddings topK=500}[ ... 1024 floats ... ]
  q           = {!hybrid lexical=$lexicalRaw vector=$vectorQuery mode=union alpha=0.8 topN=500}

alpha is the balance between the two legs, topN the candidate depth, mode whether a document needs both legs or either. All three are per index settings under Search Tuning, changeable without reindexing.

Why the columns are three queries and not one with the weights moved

Because fusion happens per document. Setting a weight to zero changes how much that leg contributes to the score, but the other leg still decides which documents became candidates in the first place, so you get the same list back with different numbers on it. Isolation has to happen at retrieval.

What happens when you press Ask

1. Retrieve — hybrid search over your index

The question runs through the same hybrid retrieval as the search page, and we keep the top four.

GET /solr_manager/api/embed_and_search
  email, api_key, index_name
  q     = the question
  rows  = 4
  fresh = no

2. Build the context

From the top three documents: title, description, and the first 50 sentences of the body, preferring text_t (the structured JSON-LD text) over raw text because it carries less navigation and boilerplate.

DOCUMENT 1: <title>
<description>
<first 50 sentences of text_t or text>

DOCUMENT 2: ...
DOCUMENT 3: ...

LINKS:
- [title](uri)
- [title](uri)

The links are appended in markdown so the model can cite them inline instead of inventing a reference.

3. Generate — streamed, grounded in that context

POST /solr_manager/api/ai_summary
  email, api_key, index_name
  query       = the question
  context     = the block above
  instruction = answer only from the context, cite the markdown links,
                say so plainly if the answer is not there
  stream      = true

Passing context explicitly is deliberate. Called without it, the endpoint answers from the model's own knowledge, which is exactly what grounding is supposed to prevent.

4. Stream back

The first line of the response is META:{"sources":[...]}, so the page can render the source pills immediately, then every byte after it is the answer as the model produces it.

Doing this yourself

Two HTTP calls against documented endpoints, with your own API key: API reference. The same pipeline is wrapped for you in the LangChain, LlamaIndex and Haystack packages.