Evoke Use Cases

Evoke is a first-stage retriever for English text in PostgreSQL, whose scores feed a reranker, an agent, or a human reviewer. The six patterns below are grounded in what the architecture actually delivers — one inverted index, CPU-only shared workers, async writes, no text egress, plain SQL — each with its "don't use it here" boundary.

1. Agent memory / multi-hop search over a repo of internal docs

The flagship use case. Agents search often: look something up, read the result, sharpen the question, search again — several times per task. First-stage recall is the ceiling, because a reranker can only reorder what it receives. Evoke gives an agent ii42_query() over docs/policies/runbooks right next to the tables it already reads: one SQL round-trip instead of search-and-merge, on a modest VPS with no GPU.

Fit: question-answering over hundreds to thousands of internal documents ("what's our policy on X for customer Y?").

Not fit: retrieval over non-English corpora, or over media where text encoding isn't the bottleneck.

2. "Exact code OR plain words" lookups

Support and incident tooling lives or dies on hybrid queries: a literal error string or "users can't log in after the login rename." In conventional stacks you run BM25 and vector search side by side, then fuse two score scales with no principled answer — most teams ship keyword-only and silently lose paraphrase matches. In Evoke, keyword evidence is never given up: when an exact match exists it keeps leading, and meaning terms add the paraphrases keyword-only search would have missed.

Fit: incident consoles, support triage, compliance lookups where a case number and a natural-language description can both arrive in the same box.

Not fit: pure faceted/structured filtering where no text relevance ranking is needed at all.

3. Air-gapped and regulated deployments

The model runs inside the database, no text leaves the server, and the release ships a checksummed offline Docker archive. For teams under legal, medical, or defense constraints, today's alternative is often no semantic search at all, because a hosted embedding API is forbidden.

Fit: clinical guidelines, case law, regulatory rulebooks, SOC policies in environments with strict egress rules.

Notes: verify checksums at load time; treat unsigned model binaries as supply-chain risk. English-only remains the operative constraint here — see getting started.

4. Recall-first retrieval that feeds a reranker

The docs scope Evoke as the candidate generator: Evoke for recall@1000, a cheap cross-encoder reranker for the top ~20 a user actually sees. You get dense-model-quality first-stage recall — matched within 0.004 of a 0.6B dense encoder on BEIR15, ahead of it in top-1,000 coverage — without running an embedding pipeline that can drift out of sync with the rows.

Fit: docs-site or product search for a team of 2–5 people who can't police a vector pipeline.

Not fit: final ordering — a reranker stays on the hook for ranking quality; Evoke raises the recall ceiling, it doesn't place the top-3.

5. Async encoding for high-ingest event logs

Encoding happens in shared CPU background workers after commit, so high-ingest tables — support tickets, agent session transcripts, chat exports — never stall on the model. Later queries can find conversations where the user meant a thing without using the word.

Fit: "find every conversation where the user said the feature was too slow, even if they never said 'slow'" — months of transcripts, recall-weighted review.

Notes: the queue is background work; freshly inserted rows are not immediately semantically searchable. If you need read-your-write semantics for meaning queries, that's the one behavior to check early.

6. MCP server backend / self-hosted agent knowledge retrieval

Since everything is ordinary SQL, any agent that can run a query (Claude Code, Cursor, OpenCode through an MCP server) gets semantic memory retrieval with zero client-side machinery: a thin MCP tool over Postgres exposes "search my knowledge base" backed by ii42_query. The knowledge base lives inside a database that follows Postgres's own crash-recovery and replication rules.

Fit: self-hosted setups, small teams, anything already running Postgres — no new infrastructure, no new trust boundary.

Not fit: if your MCP clients can't issue SQL, you're building an app-specific API anyway; at that point Evoke is "only" the retrieval engine inside it.

---

Honest limitations (read before deploying)

• English only for now. Non-English corpora should be tested on your own data first; pgvector remains the safer multilingual bet.
• First-stage only. Expect to add a reranker for user-facing ranking.
• Eval-suite numbers ≠ your corpus. The 0.004-of-dense headline is measured on BEIR15/MTEB10; run recall@k on a held-out slice of your own data before trusting it.
• Index growth vs plain BM25 is an open question — expansion terms are extra postings, and no published ratio exists yet (this question was asked on X at launch and left unanswered). Measure on your own corpus.
• Model swaps need care. Keep re-encoding off the write path (Evoke already does), and after any model change measure recall@k on a held-out set before trusting the new postings — the guidance one commenter offered at launch, and good ops hygiene regardless.

Related

• Evoke overview
• Getting Started
• Exact vs Paraphrase Pattern
• Jev use cases — the decisions after retrieval: routing, gating, verification