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.

No signup, no setup

No signup. No Docker. No OpenAI key. No 200 lines of Java. Click the button, push your data (or ours), and search it with hybrid BM25 + kNN — then open the actual Solr index and see the 1024-dimension vectors sitting in the documents.

Why meaning crosses languages

Both indexes above are configured for their own language on the keyword side — English and German. The multilingual model is what carries a query across that boundary, which is exactly why we fuse keyword and vector scoring instead of choosing one. Your sandbox index below behaves the same way: push documents in any language and query them in any other. The third search in the second row runs on 33 public-domain PDFs indexed page by page: how PDFs, scanned pages and pictures become searchable.

What actually happens under the hood

When you click the button below, a real Apache Solr 9.6 index is provisioned on our managed Solr cloud with the full web-crawler schema: dense vector field (1024-dim multilingual E5), {!hybrid} query parser fusing BM25 with kNN, autocomplete, spellcheck, sentiment, language detection. Every document you push through the Data Ingestion API is embedded server-side on our GPUs — you never generate a vector yourself. The search page you get includes AI Hints and the Document Reader: RAG answers with citations, generated from your own indexed content.

The exact same engine already powers our integrations — pick your stack and the setup is one install away:

Your sandbox index

Comes pre-loaded with 100 sample documents from five live indexes on completely different subjects, so it is searchable immediately · Limit: 2 indexes per hour per visitor · index lives 3 days, then deletes itself · powered by the account sandbox@opensolr.com

No setup at all: the second button opens an index that is already crawled and embedded, with example questions ready to run.

Clearing, credentials, vectors

Clearing empties the index but keeps it, along with its credentials and this link. Use it before crawling your own site or pasting your own JSON, so the 100 sample documents do not get mixed into your results and skew what you are testing.

The Solr Admin UI and raw index URL will ask for the username / password above — that is your own private HTTP auth on this index. After you ingest, look at any document: the embeddings field holds the real 1024-dimension vector.

What is already in your index

What is already in your index. It arrived with 100 documents, the 20 freshest from each of five live Opensolr Indexes that have nothing to do with each other: world news, technical articles from a test and measurement equipment maker, a jewellery shop, coffee and wine articles, and a fashion shop. The mix is on purpose: one pile, five unrelated subjects. Ask about any of them in your own words and watch hybrid retrieval pull the right documents out and leave the other four subjects alone. They go through the same ingestion queue as your own data, so for the first minute you can watch them get embedded below.

Pushing your own JSON

A JSON array of documents — uri, title, description, text required, up to 50 per batch. Any dynamic field welcome, and the index field reference lists every field this schema already carries.

A PDF instead of text: put the PDF's address in uri, leave out text and add "rtf": true. The PDF is fetched and indexed one document per page, scanned pages and pictures read with OCR in the language of the page, each page with its own vector. Try it with one of the 33 test PDFs:

[
  {
    "uri": "https://opensolr.com/ocr-test/wpa-dream-of-stars.pdf",
    "title": "Dream of Stars",
    "description": "A science book for children from the 1930s.",
    "rtf": true
  }
]

What actually becomes the vector: title + description + the first 2500 characters of text (cut on a sentence boundary, and text_t is preferred over text when you send both). That is one 1024-dimension embedding per document, not per chunk. Every other field you send stays keyword searchable, filterable and facetable, it just does not move the vector.

Crawling your site

Give us your website — a homepage or a sitemap.xml URL — and our Web Crawler registers it on this index, verifies it automatically and starts crawling right away. Same flow the Drupal and WordPress modules use. Sandbox limit: 100 pages, single thread, one-off run (no schedule).

PDFs too. Give it a page that links to PDF documents on the same site: every linked PDF is indexed one document per page, its scanned pages and pictures read with OCR, and you search it by keyword and by meaning on your hosted search page, under Documents. See it on 33 test PDFs.

The ingestion queue

Each batch is queued, then enriched: GPU embeddings, sentiment, language detection, autocomplete fields — all automatic. This table refreshes itself every few seconds — no page reload needed (and your sandbox survives a reload anyway: it is saved in this browser, and in the shareable link above).

Not sure what to ask?

Your sandbox was seeded with 100 live documents from five different subjects, and they are different every time one is created, so look at what is actually in yours before you search.

Wait for the ingestion queue to go quiet, then open the search page and hit search on an empty query: it lists everything in the index. Pick a document, then ask about it in your own words, words the article itself does not use. That is the whole trick.

Why three separate queries

A fused score can hide a leg that contributes nothing. So run the same query three ways against your index and compare the result sets, not the marketing: keyword only (BM25, no vectors), vector only (pure kNN, no keywords), and the hybrid we actually serve. These are three separate Solr queries — not the same query with the weights nudged — and the difference is the whole point. With per-document fusion, zeroing a weight does not remove a leg: it only changes how much that leg contributes to the score, while the other leg still decides which documents become candidates at all. You get the same list back with different numbers on it, and you conclude the fusion works when you have proven nothing. Isolation has to happen at retrieval, which is why each column below is its own query against your index.

Your hosted search page

This is your hosted search page, the same one every Opensolr index gets, with AI Hints and the Document Reader built in. Try searching by meaning: describe what a document is about without using its words.

What just happened behind the scenes

Every step you clicked through is a plain API call you could have made yourself — nothing here is a mock:

1. A real Apache Solr 9.6 index was created on our managed cloud — with the vector schema, the Opensolr {!hybrid} query parser (ours — it does not ship with Apache Solr) and its own HTTP auth, in seconds.
2. Your documents went through the Data Ingestion API: queued, validated, then enriched — GPU vector embeddings built from title + description + the first 2500 characters of the body, plus sentiment, language detection and autocomplete fields — automatically. Every field of the schema is listed in the index field reference.
3. A complete, responsive search UI appeared at search.opensolr.com/your_index — facets, autocomplete, AI Hints — zero front-end work.
4. Your questions ran hybrid retrieval (BM25 + kNN) and a streaming RAG answer with inline citations — the same APIs our LangChain, LlamaIndex and Haystack integrations use.

And this sandbox shows maybe a third of it. With a real account you also get search tuning (field weights, freshness boost, vector/lexical balance — from sliders), query elevation (pin or bury results per query), facet mapping, live query analytics, error audit, backups, teams, the web crawler — and of course the raw Solr index itself, to query directly from your own applications with any Solr client library, exactly like you just did with curl.