Three-minute technical walkthrough · No backend required
What does the graph actually add to RAG?
This project studies one precise question: when a retrieval pipeline already finds a relevant fragment of a biomedical paper, does following a graph link to the complete abstract improve the answer? Follow the example below, then inspect the measured evidence and source.
1. Watch parent expansion work
Click through a synthetic retrieval example. It runs entirely in your browser, even when the free-tier chat backend is sleeping.
1. Find a matching section
Shared vector search returns short chunks, not full papers.
Retrieved context
Results · section 2
The observed difference is reported with its uncertainty.
Plain RAG would pass just this matching section to the language model. The graph-enabled arm begins with the same retrieval pool as its reranked baseline.
Synthetic illustration only: these sentences are invented, not retrieved from PubMed, not a saved benchmark prediction, and not a live LLM response. This walkthrough makes no API calls.
2. Inspect the historical experiment
The published study compared 4 retrieval setups on 200 seeded PubMedQA questions. Each step in the main ladder adds a component: plain RAG → reranking → full parent abstract → related-paper concept hop.
Parent expansion
+22.5pp
Historical accuracy change vs reranked chunk RAG · McNemar p<0.0001
Related-paper expansion
−2.0pp
Historical accuracy change vs parent expansion alone · McNemar p=0.6889
This is a comparison of retrieval configurations, not proof that graph edges themselves are better than a non-graph parent-document lookup. An equally budgeted flat parent-document baseline is a planned follow-up.
Full metrics, sample size, and tests →3. Review the engineering decisions
Shared retrieval pipeline
src/kgqa/retrieval/base.py
Embeddings, reranking, and candidate selection are reused across arms.
ArangoDB graph expansion
src/kgqa/retrieval/graph.py
Actual AQL traversal from a retrieved chunk to its parent abstract.
Benchmark runner
scripts/run_benchmark.py
Sampling, checkpoints, per-question evaluation, and run metadata.
Statistics and comparisons
scripts/compare.py
Paired McNemar tests, confidence intervals, and generated result tables.
The live product also includes a FastAPI REST/MCP backend, a graph-path visualization, graceful fallbacks, and a memory-optimized ONNX encoder. The case study explains the deployment tradeoffs.
4. Understand the limits before the demo
- Different runtime: the historical benchmark used a large ArangoDB corpus and local Ollama model. The hosted demo uses only the 1,000-paper labeled split in Neo4j, a cloud LLM, and no reranker. Its output is not a reproduction of the numbers above.
- Preliminary evidence: the historical graph may have contained duplicate context edges. The benchmark needs a clean rerun, and raw per-question outputs were not committed.
- Modest absolute accuracy: the historical majority-yes baseline scored 56.5%; the best reported graph score is only narrowly above it.
- Hosted availability: the free-tier backend can sleep and take minutes to wake up. This walkthrough and the benchmark page still work without it.
Try the real system
The chat demo retrieves from the hosted knowledge graph and links to source PubMed papers. For a concise explanation of the architecture, evidence, and remaining work, see the reviewer guide.