49 lines
1.6 KiB
Markdown
49 lines
1.6 KiB
Markdown
# RAG 缺少上下文打包和 Rerank
|
||
|
||
**状态**：待规划
|
||
**严重程度**：中
|
||
**发现时间**：2026-07-04
|
||
**范围**：检索后处理、证据排序、Agent 输入质量
|
||
|
||
---
|
||
|
||
## 现象
|
||
|
||
当前 RAG 检索主要依赖 L0/L1 的原始召回顺序，没有独立的 reranker、cross-encoder 或 LLM rerank 阶段。召回结果进入 Agent 前，也缺少统一的上下文打包策略。
|
||
|
||
这意味着“检索到”不等于“以最适合推理的形式喂给 Agent”。
|
||
|
||
---
|
||
|
||
## 当前实现
|
||
|
||
- L0 和 L1 结果由 `LookupKnowledgeTool` 拼装后返回。
|
||
- 没有候选级 rerank。
|
||
- 没有明确的 token budget 分配策略，例如每个文档最多占多少、命中片段和扩展片段如何排序。
|
||
- 没有把 `title`、`breadcrumb`、score、source 统一包装成证据块。
|
||
|
||
---
|
||
|
||
## 影响
|
||
|
||
- 相关结果可能被排在不理想的位置。
|
||
- 多个候选内容相近时，Agent 可能读到重复信息。
|
||
- 证据结构不清晰，后续 verifier 或 trace 解释成本较高。
|
||
|
||
---
|
||
|
||
## 建议修复
|
||
|
||
1. 引入 `RetrievedEvidence` 这样的内部结构，统一承载 source、title、breadcrumb、score、hitReason、content。
|
||
2. 做简单 rerank：关键词命中、向量分、breadcrumb 匹配、文档去重、相邻片段扩展一起排序。
|
||
3. 上下文打包时按证据块输出，明确来源和置信度。
|
||
4. 面试版可以先实现规则 rerank，后续再替换为 cross-encoder 或 LLM rerank。
|
||
|
||
---
|
||
|
||
## 相关文件
|
||
|
||
- `src/main/java/com/superbiz/agent/tool/LookupKnowledgeTool.java`
|
||
- `src/main/java/com/superbiz/agent/service/VectorSearchService.java`
|
||
- `src/main/java/com/superbiz/agent/service/KnowledgeIndexService.java`
|