v2.44.4: Log recall lane repaired

marm_smart_recall answers from two lanes and returns the union: a semantic lane over stored memories, and a log lane over session log entries. The log lane had never worked.

It substring-matched the entire query against each entry's topic and summary, so a question like "When did Caroline go to the support group?" only matched if that exact sentence appeared verbatim in stored text. It never did. Measured against LoCoMo, the lane scored 0.0% on all 1,977 questions in every category, while being offered to every connected agent.

The same defect was found and fixed in the semantic lane in v2.31.0. The log lane was missed at the time.

Fixed: The Log Lane Now Matches Something

• The lane tokenizes the query, drops stopwords using the set the semantic lane already uses, matches any term, and ranks entries by how many distinct terms each one matched.
• Both transports share one query builder. The HTTP handler and the STDIO service each carried their own copy of this SQL, and the first version of this fix repaired only the HTTP copy, which would have shipped a fix that STDIO users never received. The query now lives in one place so the two cannot drift apart again.
• Response shape is unchanged. The match count used for ranking stays in SQL and never enters the payload, so HTTP and STDIO return identical results. Verified across 1,982 LoCoMo questions: identical log_results id lists in identical order, no mismatches.

Added: Index Behind the Log Lane

• Tokenizing took the lane from two SQL predicates to as many as 24, against a table whose only index was its primary key, costing roughly 12ms per recall. A composite index on log_entries(session_name, entry_date) brings the session-scoped path to 1.45ms, about 3x faster than the broken lane it replaced.
• The index is created in init_db() as an additive CREATE INDEX IF NOT EXISTS, verified against an already-populated database. Existing installs pick it up on next start with no migration step.
• Retrieval results are identical with and without it in all five categories, which is what an index that only changes lookup speed should do.

Benchmark

Controlled comparison holding build, database, ingest and questions fixed, with the log lane as the only variable. LoCoMo, all 10 conversations, 5,882 turns ingested, 1,977 evidence-annotated questions, top-5 recall. No LLM judge is involved, so this measures retrieval rather than answer quality.

Metric	Before	After
Overall any-evidence-hit	63.5%	69.1 - 69.6%
Mean evidence recall	57.9%	63.0 - 63.5%
Log lane alone	0.0%	53.3%

Every category gained between 5.7 and 6.8 points. Ranges rather than single figures because the semantic lane varied about half a point across three runs with nothing in its path changed, so a sub-point difference is not a result here.

Two things the table does not say. Of the log lane's 1,053 hits, 937 are also found by the semantic lane, so the whole improvement rests on 116 questions where the log lane found evidence the semantic lane missed. It wins those by searching different text, topic and summary rather than memory content. And multi-hop is still the weakest category at 44.9%, which is why the README no longer claims these gains ensure high multi-hop recall accuracy.

Reproduce with scripts/benchmarking/accuracy/locomo/run_eval.py. Raise MARM_RATE_LIMIT_RPM before ingesting, or the run takes an hour instead of two minutes.

Upgrade Note

No user action required. The index is additive and existing installs pick it up on next start.