Unlisted · noindex · design plan

Roxy — Smarter Retrieval Plan

Hybrid search & chunking · plan only, not a build commitment · August 13, 2026

This page details the "Smarter retrieval" tentative card on Roxy's status page. It explains why plain word search will eventually fail Bob quietly, and the three small upgrades — all inside Bob's existing Supabase — that fix it.

Status: plan only. Nothing on this page is built or scheduled. It becomes a build decision only after cited answers from the live library prove useful to Bob. It requires no new database, no new service, and no new monthly cost beyond pennies of embedding usage.

The problem, in plain English

Today, when Bob asks Roxy a question, Roxy finds documents by matching the words in the question against the words in the library (full-text search). This works well when the words line up — a ticker, a company name, an author's phrase.

It fails silently when they don't. If Bob asks about "datacenter power constraints" and the newsletter said "grid interconnect queues," word search finds nothing. Roxy then honestly reports a miss — on material the library actually contains. The answer looks trustworthy and is wrong about coverage. That is the most dangerous failure a research librarian can have, because nobody notices it happening.

Two smaller problems ride along: a search hit today returns a whole newsletter (thousands of words) instead of the paragraph that matters, and there is no clean way to ask time-and-author questions like "what was this writer saying in June versus now?"

The fix: three small parts

1. Search by meaning (hybrid search)

Alongside the existing word search, store an embedding for each passage — a numeric "fingerprint" of what the passage is about. Two passages about the same idea get similar fingerprints even when they use different words. At question time, Roxy runs both searches:

Word search (FTS) — stays, and stays primary for exact things: tickers, names, quoted phrases.
Meaning search (vector) — catches documents that say the same thing in different words.
Results are merged (reciprocal-rank fusion or similar) so neither side dominates.

Supabase supports this natively via the pgvector extension — one column and one index on the existing tables. No second database, no external search service.

2. Split documents into passages (chunking)

Store each document's text as ordered passages (roughly paragraph-sized) that point back to their parent document. Benefits:

Better citations. An answer cites the paragraph that supports it — verbatim claim, who said it, when, link — not "somewhere in this 4,000-word post."
Better answers. Multi-document questions fit in the model's working context because Roxy retrieves six relevant paragraphs, not six full newsletters.
Better embeddings. A fingerprint of one paragraph is sharper than a fingerprint of a whole mixed-topic post.

The schema already anticipates this (documents → document_chunks); this fills that layer in for the Substack corpus. Chunks carry an ordinal and parent-document reference so full context is always one join away.

3. Author and date as first-class filters

Investment research is dated claims by named people. Publisher, author, published date, title, and source URL should be queryable columns (most already arrive free in the mail headers), so that questions like these are real database queries, not text-matching luck:

"What was Doomberg saying about natural gas in June, versus this month?"
"Show me everything from this publisher since the last earnings call."
"Who else wrote about this topic in the same week?"

What each part costs

Part	Change	Cost
Author/date metadata	Ensure existing columns are populated and used as retrieval filters	Mostly free — data already arrives in mail headers
Chunking	Small migration filling the existing `document_chunks` layer; re-chunk current corpus	One-time script; cheapest now while the corpus is small
Hybrid search	`pgvector` column + index; embed passages at ingest; merge FTS + vector results at query time	Pennies to embed the current corpus; negligible ongoing

What this deliberately does not include

No knowledge graph. Relationship mapping was considered and abandoned as a planned item (August 13, 2026) — hybrid search plus author/date filters covers the practical need at far lower complexity. The design notes are archived if real use ever demands a revisit.
No summarization at ingest. Summaries drift from sources; Roxy cites originals.
No reranker service, no external vector database, no new store. Everything lives in the Supabase Bob already owns.
No change to the product. Ask/pull, cited answers, honest misses — retrieval gets smarter underneath; the promise to Bob stays identical.

Acceptance proof (when built)

A vocabulary-mismatch question — phrased differently from the source document — retrieves the right passage and cites it. This is the test plain FTS fails.
An exact-term question (ticker or name) still resolves correctly — hybrid must not regress what word search already does well.
A cited answer points at a passage, and the citation carries author, date, and link that match the source.
An author + date-window query returns only that author's documents in that window.
An honest miss stays honest — a question genuinely outside the corpus still returns "not in the library," with no near-miss passage dressed up as an answer.
Re-ingest stays a no-op — dedupe holds at both document and chunk level.

When to do it

Not now. At 28 documents, word search plus a capable model is genuinely good enough, and the current priority is proving cited answers Bob relies on. The right trigger is either of:

the corpus approaching a few hundred documents, or
observed vocabulary-mismatch misses — Bob asks about something the library covers and Roxy can't find it.

Chunking is cheapest done early (fewer documents to migrate), so if a build decision comes, chunking and metadata go first, embeddings second.