Skip to content
Interactive sandboxIndex built 15 Aug 2026

Ask my
writing

This runs the pipeline described in ADR-001 against 179 passages indexed from this site — case studies, decision records, and a profile feed (education, certifications, LinkedIn history, public GitHub). Two retrieval paths, combined by rank, with a trace panel beside the answer so you can see which passages it used and how long each step took.

Ask the site

179 passages

Answers come only from the 179 indexed passages of this site. If the corpus doesn't cover it, the model is instructed to say so rather than improvise.

Try asking

Live trace

idle
Index179 chunksvoyage-3.5-lite

Ask something to see the retrieval trace: per-stage timings, which path found each passage, and the fused ranking that decided what the model was shown.

Hybrid BM25 + denseRRF k=60SSE
01What you're looking at

The pipeline, drawn

Two paths run against the same chunks. The dense path handles paraphrase; the lexical path handles the rare, specific terms embeddings smooth away. Rank-based fusion combines them without needing the two score scales to be calibrated against each other.

Hybrid retrieval and generation pipelineAt deploy time the MDX corpus is chunked, each chunk is embedded with Voyage, and the result is written to a static index that ships with the build and is loaded into memory on cold start. Per request, a visitor query splits into two parallel retrieval paths that read that same index. The dense path embeds the query and scores it by cosine similarity; the lexical path tokenises the query and scores it with BM25 over the same chunks. The two ranked lists are combined with reciprocal rank fusion, the top passages are selected, and the first available model provider in an ordered chain generates an answer, streamed to the browser over server-sent events. A dashed edge shows the degraded path: if the query embedding fails, the BM25 ranking alone feeds fusion. A telemetry channel on the same stream reports the timing of each stage and which provider served the answer.BUILD TIME — runs on deployMDXcorpusChunk~215 tokEmbedcorpusStatic vector indexREQUEST PATH — runs per queryloaded on cold startQueryvisitorEmbedquery · 1024dCosine top-kdenseTokenisestem · stopBM25 top-ksame chunksRRF fusionrank-basedTop passageswith citationsGenerationfirst of chainfallback: BM25-only if the query embedding failsSSE streamanswer + telemetry
Fig. 1 — The index is built on deploy and read on every request. Two retrieval paths score against it — teal is dense, yellow is lexical — and are fused by rank rather than score. The dashed edge is the degraded mode: the BM25 ranking alone answers if the query embedding fails.
02Scope

What it is built for

The size this is designed against, and the point at which each choice would have to change. These are the first things I would ask about if someone showed me this.

  • Sized for this corpus

    Scoring is brute-force over every chunk, which is the right answer at this size and the wrong one past a few thousand. The threshold is enforced: the build fails rather than silently shipping a slow index.

  • Spend is capped

    Per-IP and global limits run through a shared store, so the ceiling holds across serverless instances rather than resetting per cold start. The cap exists to bound token spend, and it is set low on purpose.

  • Measured single-user

    The latencies in the trace are real, and they are from one user at a time. Concurrent behaviour is not something I have measured, so I do not quote a number for it.

Sandbox179 passages indexed