Design-partner preview
Paradigm Bridge · geometric query routing for RAG

Stop searching your whole corpus on every query.

Caustic learns which region of your corpus a query belongs to and searches only that slice. On our first real-corpus pilot it removed ~75% of vector-search cost while keeping 95% of the documents a full scan would return — measured, not modeled.

Become a design partner See how it works — measured on a real corpus, not modeled
The problem

Every query pays to search documents it will never use.

Standard RAG embeds your query and scores it against the entire corpus, every time. But a billing question never needed the API reference; a code query never needed the legal docs. You pay to search all of it anyway. In retrieval-heavy and no-LLM pipelines that search is the dominant cost; behind an LLM it is a smaller slice, but one you pay on every single query.

~75%
— of vector-search cost removed at 95% recall, measured on a 12,500-problem corpus with BGE-large embeddings (PRM800K pilot, n=300 held-out queries). The figure is a share of the search step; how large that step is in your bill depends on your pipeline.
How it works

Organize once. Route every query to its slice.

A diagnostic and a lightweight router in front of your existing vector store. No re-embedding your corpus, no new model.

01 · DIAGNOSE

Is your corpus routable?

Before anything, Caustic reads your corpus geometry and tells you whether — and how — it separates into regions. If it can't be routed, it says so, instead of selling you savings that aren't there.

honest gate · names the structure
02 · ORGANIZE

Carve it into regions

It discovers the corpus's natural regions automatically, or routes on a feature you already know (doc type, source, format). Organize once; the map is your reusable reference.

discovered or declared
03 · ROUTE

Search the right slice

Each query is classified to its region and searched there. Uncertain queries route to their top few regions — never a full-corpus fallback — so ambiguity costs a little, not everything.

top-N coverage · tunable safety
The core finding

Every savings number comes with the recall it costs.

A savings number with no recall attached is meaningless — you can always "save" by searching less and finding less. So every figure here is paired with the recall it holds, measured against an exhaustive search on a real corpus. Pick the recall you need; read off the savings.

~75%
at 95% recall

Search a quarter of the corpus, recover 95% of what a full scan returns. The everyday operating point.

~81%
at 90% recall

Accept a little more miss rate and savings climb. You choose where on the curve to sit.

~80%
oracle ceiling @ 95%

The best any router could do on this corpus knowing the answer in advance. Caustic lands ~4 points under it, and ~6 points over a standard fixed-budget baseline — for free.

Measured on the PRM800K corpus (12,500 math problems, BGE-large embeddings, 300 held-out queries), recall scored against exhaustive search. These are this corpus's numbers; the curve on yours is what a design-partner pilot measures. We'd rather show you the curve on your data than quote you ours.
The difference

Most routing leans on a feature you hand it. Caustic finds the feature.

Naive routing needs you to already know what separates your corpus — and dumps every uncertain query into a full search. Caustic diagnoses what separates your corpus (embedding structure, format, metadata — or tells you nothing does), and routes ambiguous queries to their top few regions, not the whole thing.

Naive routingCaustic
You supply the splitIt finds the split
Uncertain → full searchUncertain → top-N regions
Fixed budget per queryAdaptive — confident queries search less
Assumes routabilityMeasures it first
Where it comes from

Measured on a real corpus.

We ran Caustic end to end on a real corpus and measured the full recall-vs-savings curve — recall scored against an exhaustive search, every savings figure paired with the recall it holds. No cost-accounting model, no projected numbers.

~75%
vector-search savings at 95% recall (PRM800K, BGE-large, n=300 held-out queries)
+6 pp
extra savings over a standard fixed-budget (IVF) baseline at the same recall — at no added inference cost
~80%
oracle ceiling at 95% recall; Caustic lands ~4 points under it
12,500
problems in the pilot corpus; recall scored against exhaustive search
Integration

A wrapper, not a re-index.

Caustic sits in front of your vector store. Diagnose, organize once, then route. Your store does the similarity search; Caustic picks which slice it runs on.

# pip install caustic-pt (design-partner preview)
from caustic import diagnose, organize, SunPositionClassifier, CausticRouter

report = diagnose(corpus_texts) # is it routable? how?
cmap   = organize(corpus_texts, strategy="auto")
clf   = SunPositionClassifier().train(corpus_texts, cmap.labels)
router = CausticRouter(cmap, clf, coverage=0.9) # safety dial

docs, decision = router.retrieve(query, your_search_fn, k=10)
# decision.regions_searched -> how the query routed
Try the live sandbox →explore the measured recall-vs-savings frontier

We're taking on a small number of design partners.

If you run a RAG pipeline with a real corpus and a real embedding bill, we'll diagnose its routability, show you the savings-vs-recall curve on your data, and you keep whatever we save. No "buy now" — this is early, and we'd rather earn the number than quote one.

Become a design partner
Honest status: the headline figures here are measured on the PRM800K corpus with real BGE-large embeddings, recall scored against exhaustive search — not a cost-accounting model. What we have not yet measured is your corpus: routability, the recall-vs-savings curve, and what share of your bill is search. That is exactly what the design-partner pilot establishes, on your stack. You'll know what's measured vs. estimated at every step.