As large language models are increasingly adopted in knowledge question answering, intelligent search, enterprise knowledge assistants, and related scenarios, Retrieval-Augmented Generation (RAG) has become an important technique for reducing hallucinations, incorporating external knowledge, and providing source citations.
Existing RAG systems typically retrieve text chunks using vector similarity or keyword matching. While these approaches work well for local semantic matching, they often struggle with complex questions involving multiple entities, multi-hop relations, and distributed evidence. They may miss critical intermediate entities or retrieve many semantically similar passages that cannot jointly support the answer.
GraphRAG organizes entities, relationships, and source documents into a graph structure and supplements traditional text retrieval with graph-based associations. GeaFlow already provides capabilities for graph data modeling, graph storage, graph queries, and graph computation. The geaflow-ai module also includes foundational support for graph entities, embedding indexes, subgraph search, and semantic processing. These capabilities provide a solid foundation for implementing structure-aware GraphRAG retrieval.
However, the current system still lacks the following capabilities for complex question answering:
- A unified mapping among source documents, text chunks, entities, graph nodes, and graph edges
- Budget-constrained multi-channel retrieval
- Controlled graph expansion
- Evidence organization
- Path tracing and explainability
- Standardized and reproducible evaluation
Project Goal
This project aims to design and implement an explainable, configurable, and reproducible structure-aware GraphRAG retrieval engine on top of GeaFlow.
The project should first establish a unified mapping among source documents, text chunks, entities, graph nodes, and graph edges, allowing every retrieval result to be traced back to its original evidence.
The retrieval engine should then implement:
- Vector retrieval
- BM25 retrieval
- Entity anchor identification
- Budget-constrained 1–2 hop graph expansion starting from identified anchors
- Candidate merging and deduplication across retrieval channels
- Retrieval and context budget control
- Pluggable reranking
- Structured output containing:
- Evidence text
- Graph paths
- Source citations
- Stage-level scores
Retrieval Modes
The engine must support the following three retrieval modes:
1. Vector-only
Serves as the traditional RAG baseline.
2. Graph-only
Used to evaluate the retrieval capability of graph structure independently.
3. Hybrid
Combines text relevance with graph-structural information.
All retrieval modes should reuse a unified data model, budget configuration, and result protocol wherever possible so that experimental results remain directly comparable.
Benchmark and End-to-End Evaluation
The project should establish a versioned and reproducible benchmark and integrate at least the following public multi-hop question-answering datasets:
The project should implement the complete end-to-end workflow, including:
- Dataset import
- Index construction
- Retrieval
- Evidence organization
- Answer generation
- Evaluation
The evaluation must compare the following approaches:
- Vector-only
- Budget-matched Vector Overfetch
- Graph-only
- Hybrid GraphRAG
The following metrics must be reported:
- Evidence Recall@K
- Answer Exact Match (EM)
- Answer F1
- Path Hit Rate
- Retrieval latency
- Context token cost
For every graph-based retrieval hit, the system must provide a complete traceability chain:
query -> seed -> edge/path -> evidence -> source
Expected Outcome
The final deliverable should provide a reusable GraphRAG retrieval capability for complex question answering and serve as a foundational component for applying GeaFlow to:
- Knowledge question answering
- Intelligent search
- Enterprise knowledge assistants
- LLM knowledge augmentation
- Other graph-enhanced retrieval scenarios
Scope and Constraints
-
The mandatory scope is limited to budget-constrained 1–2 hop graph expansion. Unlimited-depth graph search is out of scope.
-
The project is not required to automatically construct a general-purpose ontology. Open-domain knowledge graph construction is not a project objective.
-
Autonomous multi-round agent-based search is not required. The retrieval pipeline must remain configurable and reproducible.
-
Answer generation is not the sole objective. Evidence retrieval quality, path explainability, and experimental reproducibility are core acceptance criteria.
-
MCP integration, retrieval-process visualization, and support for additional datasets are optional enhancements and do not affect acceptance of the core functionality.
-
All datasets, models, and dependencies must comply with their applicable licenses. Model credentials, API keys, and restricted datasets must not be committed to the repository.
-
Experiments must use fixed dataset versions, data splits, random seeds, and primary retrieval parameters.
-
Performance improvement is an expected goal. If the expected improvement is not achieved, the project must provide complete ablation studies and an analysis of failure cases and root causes. Modifying or selectively adjusting the test set to avoid unfavorable results is not acceptable.
As large language models are increasingly adopted in knowledge question answering, intelligent search, enterprise knowledge assistants, and related scenarios, Retrieval-Augmented Generation (RAG) has become an important technique for reducing hallucinations, incorporating external knowledge, and providing source citations.
Existing RAG systems typically retrieve text chunks using vector similarity or keyword matching. While these approaches work well for local semantic matching, they often struggle with complex questions involving multiple entities, multi-hop relations, and distributed evidence. They may miss critical intermediate entities or retrieve many semantically similar passages that cannot jointly support the answer.
GraphRAG organizes entities, relationships, and source documents into a graph structure and supplements traditional text retrieval with graph-based associations. GeaFlow already provides capabilities for graph data modeling, graph storage, graph queries, and graph computation. The
geaflow-aimodule also includes foundational support for graph entities, embedding indexes, subgraph search, and semantic processing. These capabilities provide a solid foundation for implementing structure-aware GraphRAG retrieval.However, the current system still lacks the following capabilities for complex question answering:
Project Goal
This project aims to design and implement an explainable, configurable, and reproducible structure-aware GraphRAG retrieval engine on top of GeaFlow.
The project should first establish a unified mapping among source documents, text chunks, entities, graph nodes, and graph edges, allowing every retrieval result to be traced back to its original evidence.
The retrieval engine should then implement:
Retrieval Modes
The engine must support the following three retrieval modes:
1. Vector-only
Serves as the traditional RAG baseline.
2. Graph-only
Used to evaluate the retrieval capability of graph structure independently.
3. Hybrid
Combines text relevance with graph-structural information.
All retrieval modes should reuse a unified data model, budget configuration, and result protocol wherever possible so that experimental results remain directly comparable.
Benchmark and End-to-End Evaluation
The project should establish a versioned and reproducible benchmark and integrate at least the following public multi-hop question-answering datasets:
The project should implement the complete end-to-end workflow, including:
The evaluation must compare the following approaches:
The following metrics must be reported:
For every graph-based retrieval hit, the system must provide a complete traceability chain:
Expected Outcome
The final deliverable should provide a reusable GraphRAG retrieval capability for complex question answering and serve as a foundational component for applying GeaFlow to:
Scope and Constraints
The mandatory scope is limited to budget-constrained 1–2 hop graph expansion. Unlimited-depth graph search is out of scope.
The project is not required to automatically construct a general-purpose ontology. Open-domain knowledge graph construction is not a project objective.
Autonomous multi-round agent-based search is not required. The retrieval pipeline must remain configurable and reproducible.
Answer generation is not the sole objective. Evidence retrieval quality, path explainability, and experimental reproducibility are core acceptance criteria.
MCP integration, retrieval-process visualization, and support for additional datasets are optional enhancements and do not affect acceptance of the core functionality.
All datasets, models, and dependencies must comply with their applicable licenses. Model credentials, API keys, and restricted datasets must not be committed to the repository.
Experiments must use fixed dataset versions, data splits, random seeds, and primary retrieval parameters.
Performance improvement is an expected goal. If the expected improvement is not achieved, the project must provide complete ablation studies and an analysis of failure cases and root causes. Modifying or selectively adjusting the test set to avoid unfavorable results is not acceptable.