New information should be useful now—and smarter later.
A user should not wait for an expensive graph-building job before asking questions about a document or webpage.
The system uses two paths. A fast path cleans and chunks the source, then makes it searchable within seconds. A background path extracts concepts, claims, and relationships and adds them to a long-lived knowledge graph.
Hybrid search is fast and precise for local questions. A graph is better when the answer depends on connections across many chunks or sources.
Hybrid RAG combines meaning, exact words, and filters.
Documents are split using token limits, with overlap to protect ideas that cross a boundary. Headings, paragraphs, tables, and lists should remain intact where possible; fixed-size chunks alone can break useful structure.
Vector search alone can miss exact identifiers. Keyword search can miss paraphrases. Metadata filters reduce noise before ranking. Neo4j supports vector and full-text indexes together, and its GraphRAG library includes hybrid retrievers. Neo4j semantic indexes ↗
This path can have strong recall for facts contained in individual chunks. Its harder cases are implicit relationships, multi-hop questions, and questions about the corpus as a whole.
GraphRAG stores connections, not just similar text.
The background job extracts concepts, entities, claims, and relationships from each source. Text-bearing objects receive embeddings. Neo4j stores the explicit connections as a property graph that can be traversed with Cypher.
Graph traversal makes multi-hop questions possible: find a concept, follow its relationships, inspect supporting claims, and return to the original chunks. Hierarchical communities add a wider view for questions about themes across the full collection. Microsoft's GraphRAG indexing pipeline extracts entities, relationships, and claims, then builds community hierarchies and summaries. GraphRAG indexing overview ↗
Use the smallest search path that can answer the question.
The agent first understands the question, available sources, user scope, and freshness needs. It then chooses one retrieval plan.
All paths can produce more candidates than the model should read. A reranker scores those candidates against the exact question, reducing the final context to the strongest evidence. Graph expansion happens before reranking so connected evidence competes on relevance, not merely proximity.
Microsoft GraphRAG similarly separates basic vector, local entity, global community, and DRIFT search modes. GraphRAG query modes ↗
Keep one concept—not endless copies of the same idea.
Every new source may mention concepts already in the graph. Entity resolution maps those mentions to a canonical concept. New claims remain separate because they may come from different sources, dates, or viewpoints.
Reclustering does not need to run after every document. It can run after meaningful graph changes or on a schedule. Pruning should remove or archive low-confidence, stale, isolated derived data—not the original source record. Provenance must remain available for citations and conflict review.
Conflicting claims should coexist with source, date, confidence, and validity information. The agent can then explain the disagreement instead of silently replacing one claim with another.
The graph can grow with the user—but the user controls it.
Each user's graph needs its own access boundary or namespace. Shared public knowledge can be referenced, but private sources must never cross users or projects.
Use Wikipedia history to test whether knowledge grows correctly.
Wikipedia provides page histories with revision metadata and page content. That makes it useful for a time-based evaluation: give the system only what existed at one date, then compare its later research with revisions that appeared afterward. Wikimedia's pages-meta-history dumps contain the revision history needed for this setup.
This tests more than question answering. It shows how a topic expands, which new concepts matter, what relationships should be created, and whether the agent ignores unrelated material.
A clean benchmark needs a strict timeline
Models, prompts, and retrieval indexes must not see revisions or sources published after T₀. Topics should be split by time—and preferably by page or topic family—to reduce memorization and leakage. The same frozen inputs must be used when comparing two systems.
Revision history is a reference signal, not perfect truth
Wikipedia edits include corrections, reverts, style changes, vandalism, and community judgment. The benchmark should focus on stable content changes, use later accepted revisions rather than every edit, and send unclear cases for human review. Evaluation data must also keep Wikimedia attribution and license information with each example.
The system discovers the useful knowledge that appeared later, connects it to the right concepts, stays within scope, preserves conflicts over time, and cites the sources that support each change.
Citations are part of the graph, not decoration added later.
Every claim keeps a link to its source chunk and original document. A final verification step checks that the cited passage supports the sentence and that the user has permission to access it.
The graph also makes reports easier to edit. A section can be connected to the claims and concepts it uses. When a claim changes, the system can identify affected sections, retrieve new evidence, and suggest focused edits without rewriting the whole report.
Search chunks for speed. Traverse relationships for depth. Rerank for relevance. Preserve sources for trust.