Latency-Budgeted Adaptive Hybrid Retrieval over Text, Vectors, and Graphs

[Leomrlin]

Background

Retrieval-Augmented Generation (RAG) is widely used in knowledge question answering, intelligent search, and enterprise knowledge assistants. Most existing systems retrieve text chunks with BM25 or vector similarity. BM25 is effective for keyword and rare-entity matching, while vector retrieval is effective for semantic similarity. However, neither method alone can reliably cover semantic similarity, entity grounding, multi-hop relations, and evidence distributed across multiple documents. Simply retrieving more text increases latency and context-token cost without guaranteeing that the missing intermediate evidence will be found.

Graph retrieval can start from entity anchors and follow relations to discover multi-hop evidence that text retrieval may miss. It can also expand the candidate set rapidly and introduce irrelevant neighbors. Different queries need different retrieval paths: queries with explicit entities and dense relations may benefit from graph expansion, semantically rich queries may depend more on vector retrieval, and queries containing rare terms may favor BM25. A fixed hybrid strategy applies the same topK, maxHop, and fusion weights to every query, which can waste resources on simple queries and under-allocate resources to difficult ones.

GeaFlow already provides graph modeling, storage, query, and computation capabilities. The geaflow-ai module also contains basic graph-entity, indexing, and subgraph-search capabilities. These foundations make GeaFlow a suitable platform for hybrid retrieval over text, vectors, and graphs. What is still missing is a unified Evidence mapping, budget-constrained multi-channel retrieval, comparable fusion protocols, low-cost query features, adaptive routing, complete execution traces, and standardized evaluation.

This project will design and implement an explainable, configurable, and reproducible adaptive hybrid retrieval engine. Under a fixed latency, candidate-count, or context-token budget, the engine will use query features and online retrieval statistics to choose among BM25, Vector, Graph, and Hybrid paths and adjust topK, maxHop, and fusion weights, balancing evidence quality against execution cost.

Hybrid retrieval combines information retrieval, graph search, budget scheduling, and experimental evaluation. Students are encouraged to study BM25, vector retrieval, graph traversal, rank fusion, reranking, and multi-hop question-answering evaluation, and may refer to published RAG and GraphRAG designs. Direct copying of existing implementations is not allowed.

Target

Design and implement a hybrid retrieval engine over text, vectors, and graphs on GeaFlow. The project must deliver a reproducible end-to-end pipeline covering data ingestion, index construction, candidate retrieval, graph expansion, fusion and deduplication, budget control, Evidence organization, and extractive-answer evaluation.

The engine must support five retrieval modes: BM25-only, Vector-only, Graph-only, Fixed Hybrid, and Adaptive Hybrid. It must also support sequential, parallel, and cascaded retrieval. The system will extract low-cost features such as query length, average IDF, first-stage score gap, average candidate degree, and graph-expansion growth rate. It will use these features to choose a retrieval mode and its parameters under a latency, candidate-count, or token budget, and return a complete query -> selected mode -> seed -> edge/path -> evidence -> source trace.

The project must also establish a versioned benchmark that compares BM25, Vector RAG, Graph-only, Fixed Hybrid, Adaptive Hybrid, and equal-budget overfetch under the same resource constraints. The evaluation should identify the benefits, costs, and applicability boundaries of adaptive retrieval across query categories and budget levels.

Difficulty

Hard

Output Requirements

1. Define a unified mapping among source documents, text chunks, Evidence, entities, graph vertices, and graph edges.
2. Provide reproducible data ingestion, cleaning, index construction, and dataset-versioning workflows.
3. Integrate fixed versions of at least two datasets from HotpotQA, MuSiQue, and 2WikiMultiHopQA.
4. Implement BM25 and vector retrieval; mandatory experiments may use precomputed vectors or TF-IDF/SVD.
5. Implement entity anchoring and budget-constrained one-hop to two-hop graph expansion.
6. Support BM25-only, Vector-only, Graph-only, Fixed Hybrid, and Adaptive Hybrid modes.
7. Support sequential, parallel, and cascaded retrieval and record latency and candidate counts by stage.
8. Implement candidate-text and candidate-subgraph fusion, deduplication, budget truncation, and a pluggable reranking interface.
9. Extract low-cost features including query length, average IDF, first-stage score gap, average candidate degree, and graph-expansion growth rate.
10. Adaptively select the retrieval mode, topK, maxHop, and fusion weights under a latency, candidate-count, or token budget.
11. Implement at least one deterministic and reproducible adaptive policy; a lightweight learned policy is optional.
12. Return Evidence text, relation paths, original sources, stage scores, budget usage, and execution decisions.
13. Provide a stable and configurable Java API with examples; a standalone REST/MCP adapter is optional.
14. Deliver Evidence organization and extractive-answer evaluation without requiring an online generative model.
15. Build a fixed benchmark comparing BM25, Vector RAG, Graph-only, equal-budget overfetch, and Hybrid approaches.
16. Report Evidence Recall@K, MRR/NDCG, Answer EM/F1 or Accuracy, path hit rate, P50/P95 latency, candidate count, and token cost.
17. Evaluate Adaptive Hybrid against Vector-only and equal-budget overfetch on a preregistered multi-hop subset under the same latency, candidate-count, or token budget.
18. Emit a complete query -> selected mode -> seed -> edge/path -> evidence/source trace for every graph hit.
19. Provide unit tests, end-to-end integration tests, an English design document, usage documentation, examples, and an experimental report.
20. Fix dataset versions, splits, random seeds, budget configurations, and major parameters, and retain raw results and execution scripts.

Acceptance Criteria

1. All mandatory experiments can run offline without paid model APIs, live online data, or GPUs.
2. A single reproducible command can execute data ingestion, indexing, retrieval, Evidence organization, and extractive-answer evaluation.
3. All five retrieval modes use the same data splits, budget definitions, result protocol, and evaluation scripts.
4. Complete the main experiments on at least two fixed public datasets and provide ablations across budget levels and query categories.
5. On the preregistered multi-hop subset and under an equal budget, Adaptive Hybrid should outperform Vector-only and equal-budget overfetch on the primary evidence or answer metric. If the expected improvement is not achieved, the submission must include complete negative results, ablations, and an applicability-boundary analysis.
6. Every graph retrieval result is traceable to the query, selected mode, entity seed, relation path, Evidence, and original source.
7. Budget truncation, retrieval fallback, empty results, and missing indexes have explicit, testable behavior and structured logs.

Scope Control

1. Graph expansion is limited to budget-constrained one-hop to two-hop traversal; unbounded-depth or unbounded-candidate search is out of scope.
2. Autonomous multi-turn agent search is out of scope.
3. Open-domain knowledge-graph construction, automatic ontology construction, and complex community summarization are out of scope.
4. Training embedding models or cross-encoders is not required; pretrained models and precomputed vectors may be used as replaceable inputs.
5. The project must not require changes to the GeaFlow Planner, graph-computation runtime, or public state interfaces.
6. Answer evaluation uses extractive answers and Gold Evidence by default; generative models are optional extensions only.
7. MCP integration, visualization, additional datasets, and learned routing policies are bonus features and are not required for core acceptance.
8. Datasets, models, code, and new dependencies must be license-compatible. Secrets, personal data, internal addresses, and restricted data must not be committed.

Technical Requirements

1. Familiar with Java, including collections, generics, interface design, and Maven.
2. Able to use Python for data processing, experiment execution, and evaluation scripts.
3. Understand the fundamentals of inverted indexes, BM25, TF-IDF, vector retrieval, and reranking.
4. Understand graph vertices, edges, paths, BFS, and constrained multi-hop traversal.
5. Understand the basic workflows of RAG, GraphRAG, Evidence organization, and multi-hop question answering.
6. Able to design candidate deduplication, rank fusion, budget truncation, and retrieval fallback strategies.
7. Understand latency, throughput, P50/P95, token cost, and performance-measurement methods.
8. Able to read and extend existing GeaFlow Java modules and design stable data models and retrieval APIs.
9. Able to write unit and integration tests with JUnit or TestNG.
10. Able to design fair and reproducible baselines, ablation studies, and error analyses.
11. Familiar with Git and Markdown and able to follow Apache community coding, documentation, and licensing practices.

---

背景

检索增强生成（Retrieval-Augmented Generation，RAG）已经广泛应用于知识问答、智能搜索和企业知识助手等场景。现有系统通常采用 BM25 或向量相似度检索文本片段：BM25 擅长匹配关键词和稀有实体，向量检索擅长召回语义相近的内容，但单一检索方式难以同时覆盖语义相似、实体锚定、多跳关系和分散证据。在复杂问答中，答案所需证据往往分布在多个文档中，并通过实体和关系连接；仅增加文本召回数量会带来更高的检索延迟和上下文 Token 成本，也不一定能够找回关键中间证据。

图检索能够从实体锚点出发，沿关系发现传统文本检索容易遗漏的多跳证据。然而，图扩展也可能快速放大候选规模，并引入与问题无关的邻居。不同查询适合的检索路径并不相同：实体明确、关系密集的查询可能更适合图扩展，语义表达丰富的查询可能更依赖向量检索，包含稀有关键词的查询则可能更适合 BM25。固定的 Hybrid 策略对所有查询使用相同的 topK、maxHop 和融合权重，容易在简单查询上浪费预算，也可能在复杂查询上分配不足。

GeaFlow 已具备图数据建模、图存储、图查询和图计算能力，geaflow-ai 模块也提供了图实体、索引和子图搜索等基础能力，为构建图、文本、向量混合检索引擎提供了良好基础。目前仍需要补充统一的 Evidence 映射、受预算约束的多路召回、可比较的融合协议、低成本查询特征、自适应决策、完整 Trace 以及标准化评测能力。

本项目拟研究并实现一个可解释、可配置、可复现的自适应混合召回引擎。在固定延迟、候选规模或上下文 Token 预算下，引擎根据查询特征和召回过程中的在线统计，自适应选择 BM25、Vector、Graph 或 Hybrid 路径，并调整 topK、maxHop 和融合权重，在证据质量与执行成本之间取得平衡。

由于混合检索涉及信息检索、图搜索、预算调度和实验评测等多个方面，同学可以提前学习 BM25、向量检索、图遍历、Rank Fusion、Rerank 和多跳问答评测方法，并参考现有 RAG 与 GraphRAG 系统的公开设计，但不得直接照搬或抄袭已有实现。

目标

在 GeaFlow 上设计并实现一个图、文本、向量混合召回引擎，完成从数据导入、索引构建、候选召回、图扩展、融合去重、预算控制、Evidence 组织到抽取式回答评测的端到端链路。

引擎需要支持 BM25-only、Vector-only、Graph-only、固定 Hybrid 和 Adaptive Hybrid 五种检索模式，以及串行、并行和级联三类召回流程。系统应提取查询长度、平均 IDF、首轮得分差、候选平均度数和图扩展增长率等低成本特征，根据延迟、候选规模或 Token 预算选择检索模式及参数，并返回完整的 query -> selected mode -> seed -> edge/path -> evidence -> source 执行轨迹。

项目还需要建立固定版本的 Benchmark，在相同预算下比较 BM25、Vector RAG、Graph-only、固定 Hybrid、Adaptive Hybrid 和等量 Overfetch 等方法，分析自适应策略在不同查询类型和预算区间内的收益、开销与适用边界。

难度

困难

产出要求

1. 建立原始文档、文本块、Evidence、实体、图节点和图边之间的统一映射。
2. 提供可复现的数据导入、清洗、索引构建和版本固定流程。
3. 至少接入 HotpotQA、MuSiQue、2WikiMultiHopQA 中两个公开数据集的固定版本。
4. 实现 BM25 检索和向量检索；必选实验可使用预计算向量或 TF-IDF/SVD。
5. 实现实体锚点识别和受预算约束的 1～2 Hop 图扩展。
6. 支持 BM25-only、Vector-only、Graph-only、固定 Hybrid 和 Adaptive Hybrid 模式。
7. 支持串行、并行和级联召回，并记录各阶段的延迟与候选规模。
8. 实现候选文本与候选子图的合并、去重、预算截断和可插拔 Rerank 接口。
9. 提取查询长度、平均 IDF、首轮得分差、候选平均度数和图扩展增长率等低成本特征。
10. 根据延迟、候选规模或 Token 预算，自适应选择检索模式、topK、maxHop 和融合权重。
11. 至少实现一种确定性、可复现的自适应策略；轻量学习式策略可作为扩展。
12. 返回 Evidence 正文、关系路径、原始来源、分阶段得分、预算消耗和执行决策。
13. 提供稳定、可配置的 Java API 和示例程序；独立 REST/MCP Adapter 作为可选扩展。
14. 完成 Evidence 组织和抽取式回答链路，不将在线生成式模型作为必选依赖。
15. 建立固定 Benchmark，对比 BM25、Vector RAG、Graph-only、等量 Overfetch 和 Hybrid 方法。
16. 报告 Evidence Recall@K、MRR/NDCG、Answer EM/F1 或 Accuracy、路径命中率、P50/P95 延迟、候选规模和 Token 成本。
17. 在预注册的 Multi-hop 子集上，验证 Adaptive Hybrid 在相同延迟、候选数或 Token 预算下相对 Vector-only 和等量 Overfetch 的效果。
18. 为每个 Graph 命中输出完整的 query -> selected mode -> seed -> edge/path -> evidence/source Trace。
19. 提供关键模块的单元测试、端到端集成测试、英文设计文档、使用文档和实验报告。
20. 固定数据版本、数据划分、随机种子、预算配置和主要参数，保留原始实验结果及运行脚本。

验收建议

1. 关闭网络后能够运行必选实验，不依赖付费模型 API、在线实时数据或 GPU。
2. 能够通过一条可复现命令完成数据导入、索引、检索、Evidence 组织和抽取式回答评测。
3. 五种检索模式使用统一的数据划分、预算定义、结果协议和评测脚本。
4. 至少在两个固定公开数据集上完成全量主实验，并提供不同预算和查询类型下的消融实验。
5. 在预注册的 Multi-hop 子集和相同预算下，Adaptive Hybrid 应在主要证据或答案指标上超过 Vector-only 与等量 Overfetch；若未达到预期，应提交完整的负向结果、消融实验和适用边界分析。
6. 所有图召回结果均可追溯到查询、模式选择、实体种子、关系路径、Evidence 和原始来源。
7. 预算截断、检索降级、空结果和索引缺失等情况具有明确、可测试的行为和结构化日志。

范围控制

1. 图扩展限定为受预算约束的 1～2 Hop，不实现无限深度或无限候选搜索。
2. 不实现自主规划的多轮 Agent 搜索。
3. 不把开放域知识图谱构建、自动本体构建或复杂社区摘要作为项目目标。
4. 不要求训练 Embedding 模型或 CrossEncoder；预训练模型和预计算向量仅作为可替换输入。
5. 不改造 GeaFlow Planner、图计算运行时或公共状态接口。
6. 回答评价默认采用抽取式答案和 Gold Evidence；生成式模型仅作为非必选扩展。
7. MCP、可视化界面、额外数据集和学习式路由策略属于加分项，不影响核心功能验收。
8. 数据集、模型、代码和新增依赖必须满足许可证要求，不得提交密钥、个人隐私、内部地址或受限数据。

能力要求

1. 熟悉 Java 编程语言，掌握集合、泛型、接口设计和 Maven。
2. 了解 Python，能够编写数据处理、实验运行和评测脚本。
3. 理解倒排索引、BM25、TF-IDF、向量检索和 Rerank 的基本原理。
4. 理解图的节点、边、路径、BFS 和受限多跳遍历等基本算法。
5. 了解 RAG、GraphRAG、Evidence 组织和多跳问答的基本流程。
6. 能够设计候选去重、Rank Fusion、预算截断和检索降级策略。
7. 了解延迟、吞吐、P50/P95、Token 成本等性能指标及其测量方法。
8. 能够阅读并扩展 GeaFlow 现有 Java 模块，设计稳定的数据模型和检索 API。
9. 能够使用 JUnit 或 TestNG 编写单元测试和集成测试。
10. 能够设计公平、可复现的对照实验、消融实验和误差分析。
11. 熟悉 Git 和 Markdown，能够遵守 Apache 社区代码、文档和许可证规范。