Phase 2 — Rekall: ranked memory retrieval
25 JUL AT 10:37 AM

Phase 2 — Rekall: ranked memory retrieval

0 LOVES 0 VIEWS
Where you go to get a memory back. Ranked, typo-tolerant full-text search over post content — trigram matching + relevance the raw-SQL and LIKE fallbacks can't give. It also un-broke a live FTS5 regression the mattn driver-swap had silently caused. Shipped 2026-07-09.

"Rekall — where you go to get a memory back." The read surface (Phase 1) lets an agent traverse the graph in one hop, but it can't find the right starting node from a fuzzy human phrase. Phase 2 is retrieval: a ranked, typo-tolerant full-text index over post content — title, excerpt, body, block text.

The honest frame: this is ease, not a new capability. Search already sort of worked two ways — entgql contains filters (SQL LIKE, unranked) and the raw-SQL MCP tool (arbitrary but agent-driven). What Phase 2 adds is quality of retrieval: trigram fuzzy matching, relevance ranking, and a trigger-fresh index — so "coktail" finds "cocktail" and the best hit comes first. Verdict pattern kept honest: necessary-but-not-sufficient — ranked FTS narrows the field, the graph traversal does the rest.

The perf finding — 1 round-trip, not 4 to 29

The MVP go/no-go, settled by a real benchmark (internal/khgraph/perf_test.go, prod DB read-only, 3 recipes): the GraphQL read is one round-trip; the equivalent raw SQL is 4 dependent round-trips for a schema-expert, up to 29 for a naive schema-discovery walk.

Path Agent round-trips Needs FK-column knowledge?
GraphQL over MCP 1 No
Expert hand-written SQL 4 Yes — every join column
Naive schema-discovery SQL 20–29 Yes — discovered the hard way

Raw server latency actually favors SQL by ~3ms (the GraphQL parse/plan/marshal layer). The win is not throughput — it is collapsing 4–29 agent round-trips to 1, with zero FK-column knowledge and zero client-side stitching. Each round-trip is an MCP tool-call — seconds and tokens of agent wall-clock — so 1-vs-many dominates the 3ms by three orders of magnitude in the metric that matters: fewer steps, fewer misses.

The regression it also fixed — FTS5, silently broken

A bonus the phase surfaced: fuzzy search had shipped and worked back on 2026-01-24 — under the pure-Go modernc SQLite driver, which compiles FTS5 in by default. Then a later driver-swap to mattn/go-sqlite3 quietly changed the rules: mattn gates FTS5 behind a build tag (sqlite_fts5) that was committed nowhere.

So on 2026-06-22 the FTS5 index silently regressed to the LIKE fallback — unnoticed, because nothing errored; results just quietly got worse. Phase 2's Step 1 is therefore both a prerequisite for post-search and a fix for a live regression: -tags sqlite_fts5 added to every FTS-touching build and run path, verified by a runtime probe (the boot log now reads "FTS search index rebuilt", not the warning) and a UI smoke (?q=coktail → the fuzzy hits). Maintenance is DB-level triggers — proven on media first, so post-writes stay fresh no matter which code path wrote them.

Total Recall — the AI Memory Layer (master)
Total Recall — the AI Memory Layer (master)
Jul 25, 2026 Total Recall
← Back to Total Recall