Conclusions
Summary of the retrieval-quality work. Numbers are in results.md .
What works
- IBM Granite is a strong model, but not a universal winner. Against the MS MARCO DistilBERT baseline on the same 100-question runs, IBM improves all no-graph embedding metrics on all three datasets and all HotpotQA graph metrics. On 2Wiki and MuSiQue with graphs, it trades lower recall at some cutoffs for higher MRR; it does not consistently beat DistilBERT on graph recall. Choose based on whether first-relevant rank (MRR) or coverage of supporting paragraphs (recall@k) matters more.
- Embeddings + graph is the best configuration on all three benchmarks at the top ranks (recall@2/5, MRR). The lift comes from the graph: adding one beats every no-graph variant on every dataset.
- Without a graph, embeddings barely beat BM25.
msmarco-distilbertalone is roughly level with FTS5 (sometimes behind, e.g. 2Wiki recall@10), which is why semantic-only recall is not enough for multi-hop questions. - With a graph, embeddings clearly beat BM25, because PageRank reaches the second supporting paragraph through shared entities that lexical matching misses.
- Graph quality matters more than graph size. spaCy with no filtering hurt HotpotQA recall@5. Filtering the corpus graph — canonical titles, drop entities outside a document-frequency band, drop date/nationality labels — improved all three datasets.
- The ceiling is still higher. Feeding the datasets’ gold triples
(
oracle, which leaks the answer) reaches much higher recall, so the remaining gap is relation-extraction quality, not the scoring pipeline. spaCy yields under 1 relation per paragraph; paragraphs mostly connect via shared entities.
Which graph
mentions (title-mention edges) and spacy (SVO triples) trade blows by
dataset: mentions wins HotpotQA and 2Wiki at 100 questions, spacy wins
MuSiQue. A combined graph is the natural next step.
Other findings
- Lexical recall now ORs a plain query’s terms and ranks by BM25
(previously an implicit AND made full questions match nothing). Strict FTS5
syntax still triggers on uppercase
AND/OR/NOT/NEAR. - Backends produce identical recall. WGPU is ~3–4× faster than CPU on an iGPU; CUDA is comparable, and the cost scales with graph size. CPU defaults to batch 1 because padding costs more than batching saves there.
- Evaluation must use the shared corpus. With per-question paragraphs, recall@10 is ~1 and cannot separate approaches.
Pending
- More questions / full validation split to tighten confidence.
- Reuse memory vectors across graph runs (today each graph re-embeds).
- Tune
[retrieval]parameters side by side. - Better relation extraction (LLM OpenIE, richer spaCy patterns) or a
combined
mentions+spacygraph. - Measure
RUSTFLAGS="-C target-cpu=native"for CPU builds.