422 lines
15 KiB
Markdown
422 lines
15 KiB
Markdown
# 知识库检索架构（L0 + L1）
|
||
|
||
**更新日期**: 2026-06-25
|
||
|
||
---
|
||
|
||
## 一、概述
|
||
|
||
`LookupKnowledgeTool` 实现两阶段混合检索：
|
||
|
||
- **L0 精确匹配**：基于内存索引的关键词匹配（< 10ms），索引从数据库加载
|
||
- **L1 语义检索**：基于 Milvus 向量数据库的相似度搜索（200-500ms）
|
||
|
||
---
|
||
|
||
## 二、完整流程
|
||
|
||
```
|
||
用户查询
|
||
│
|
||
▼
|
||
┌─────────────────────────────┐
|
||
│ L0: 关键词精确匹配 │ (< 10ms)
|
||
│ • 从内存索引做关键词匹配 │
|
||
│ • 索引来源: ApiDocument DB│
|
||
└──────────┬──────────────────┘
|
||
│
|
||
▼
|
||
┌──────┴──────┐
|
||
│ matches=1 │ ← 唯一匹配（高置信度）
|
||
└──────┬──────┘
|
||
│
|
||
▼
|
||
┌──────────────┐ ┌──────────────────┐
|
||
│ 跳过 L1 │ │ L0 返回正文摘要 │
|
||
│ 置信度: high │ │ buildCompactSummary│
|
||
└──────────────┘ └──────────────────┘
|
||
|
||
|
||
┌──────┴──────┐
|
||
│ matches=0 │ ← 无匹配
|
||
└──────┬──────┘
|
||
│
|
||
▼
|
||
┌──────────────┐ ┌──────────────────┐
|
||
│ 触发 L1 │ │ L0 无结果 │
|
||
│ L1 语义检索 │ │ 仅有 L1 补充结果 │
|
||
└──────────────┘ └──────────────────┘
|
||
|
||
|
||
┌──────┴──────┐
|
||
│ matches>=2 │ ← 多匹配
|
||
└──────┬──────┘
|
||
│
|
||
▼
|
||
┌──────────────┐
|
||
│ 触发 L1 │
|
||
│ L1 语义检索 │
|
||
└──────┬──────┘
|
||
│
|
||
┌─────┴─────┐
|
||
│ ║ │
|
||
▼ ▼
|
||
L1 有结果 L1 无结果
|
||
│ │
|
||
▼ ▼
|
||
元数据摘要 正文摘要
|
||
(不读文件) (读文件)
|
||
```
|
||
|
||
---
|
||
|
||
## 三、L0 返回内容策略
|
||
|
||
根据匹配场景决定 L0 返回给 LLM 的上下文内容量。
|
||
|
||
### 3.1 唯一匹配（高置信度，matches=1）
|
||
|
||
**策略**: `buildCompactSummary()`
|
||
|
||
L1 被跳过，LLM 只有 L0 信息来源，需要提供足够的正文内容。
|
||
|
||
```
|
||
文档: 支付网关错误码定义
|
||
摘要: 记录了支付网关所有核心错误码的含义及排查方向
|
||
章节:
|
||
- 超时类错误
|
||
- 业务类错误
|
||
- 签名类错误
|
||
---
|
||
**含义**：支付网关请求超时
|
||
**常见原因**：网络延迟、第三方服务响应慢
|
||
...
|
||
```
|
||
|
||
| 组成部分 | 说明 | 大小 |
|
||
|---------|------|------|
|
||
| title + summary | 从内存索引获取 | ~50-100 字符 |
|
||
| 章节标题列表 | 从文件解析 `##` 标题 | ~50-200 字符 |
|
||
| 正文片段 | 去 frontmatter/标题行/空行，短文档 800/长文档 500 字符截断 | ~300-800 字符 |
|
||
| **总计** | | **~400-1000 字符** |
|
||
|
||
### 3.2 多匹配 + L1 有结果
|
||
|
||
**策略**: `buildMetadataOnlySummary()`
|
||
|
||
L1 已有语义内容片段，L0 仅需告知 LLM 命中了哪些文档。**不读文件**，仅用内存索引。
|
||
|
||
```
|
||
文档: 支付网关错误码定义
|
||
摘要: 记录了支付网关所有核心错误码的含义及排查方向
|
||
关键词: ERR_TIMEOUT, 超时, 支付网关
|
||
来源: api/payment-errors.md
|
||
```
|
||
|
||
| 组成部分 | 说明 | 大小 |
|
||
|---------|------|------|
|
||
| title + summary + keywords | 全部从内存索引获取 | ~100-200 字符 |
|
||
| **总计** | | **~100-200 字符** |
|
||
|
||
### 3.3 多匹配 + L1 无结果
|
||
|
||
**策略**: `buildCompactSummary()`（同 3.1）
|
||
|
||
L1 未返回结果， L0 作为兜底提供正文内容。
|
||
|
||
---
|
||
|
||
## 四、决策矩阵
|
||
|
||
```
|
||
needFullContent = highConfidence || !hasL1
|
||
```
|
||
|
||
| 场景 | matches | L1 结果 | needFullContent | L0 策略 | 是否读文件 | 上下文大小 |
|
||
|------|:-------:|:--------:|:---------------:|---------|:---------:|:--------:|
|
||
| 唯一匹配 | 1 | 未执行 | true | `buildCompactSummary` | 是 | ~600 字符 |
|
||
| 多匹配 + L1 有结果 | 2+ | 有 | false | `buildMetadataOnlySummary` | **否** | ~150 字符 |
|
||
| 多匹配 + L1 无结果 | 2+ | 无 | true | `buildCompactSummary` | 是 | ~600 字符 |
|
||
| 无匹配 | 0 | 有 | — | 无 L0，仅 L1 | 否 | 0 |
|
||
|
||
---
|
||
|
||
## 五、代码结构
|
||
|
||
```
|
||
LookupKnowledgeTool
|
||
├── lookupKnowledge(query) # 入口：编排 L0 + L1
|
||
├── buildResult(l0, l1, confidence) # 组装结果，选择摘要策略
|
||
├── buildCompactSummary(entry) # 元数据 + 章节 + 正文片段（读文件）
|
||
├── buildMetadataOnlySummary(entry) # 仅元数据（不读文件）
|
||
├── countMdHeadings(content) # 统计章节数（日志用）
|
||
└── extractFirstMeaningfulLine(...) # 提取首个有意义文本行（日志用）
|
||
```
|
||
|
||
### 关键逻辑（buildResult）
|
||
|
||
```java
|
||
boolean needFullContent = highConfidence || !hasL1;
|
||
String content = needFullContent
|
||
? buildCompactSummary(first)
|
||
: buildMetadataOnlySummary(first);
|
||
```
|
||
|
||
---
|
||
|
||
## 六、日志输出示例
|
||
|
||
### 多匹配场景（matches=2, L1 有结果）
|
||
|
||
```
|
||
[L0 精确匹配] 完成: matches=2, time=3ms
|
||
[置信度判断] highConfidence=false, reason=多个或零个匹配
|
||
[L1 语义检索] L0非唯一匹配，触发L1语义检索...
|
||
[L1 语义检索] 完成: matches=1, time=245ms
|
||
----------------------------------------
|
||
<<< [工具返回] lookup_knowledge
|
||
<<< [L0 主结果] 标题: 支付网关错误码定义
|
||
<<< [L0 主结果] 摘要: 记录了支付网关所有核心错误码的含义及排查方向 ← 仅元数据
|
||
<<< [L0 主结果] 内容: 126 字符, 0 个章节 ← 约150字符
|
||
<<< [L1 补充] 相似度: 0.8234
|
||
<<< [L1 补充] 内容片段: 支付网关请求超时... ← L1 提供具体内容
|
||
```
|
||
|
||
### 唯一匹配场景（matches=1, 跳过 L1）
|
||
|
||
```
|
||
[L0 精确匹配] 完成: matches=1, time=2ms
|
||
[置信度判断] highConfidence=true, reason=唯一匹配
|
||
[L1 语义检索] L0唯一匹配，跳过L1检索
|
||
----------------------------------------
|
||
<<< [工具返回] lookup_knowledge
|
||
<<< [L0 主结果] 标题: 支付网关错误码定义
|
||
<<< [L0 主结果] 摘要: 记录了支付网关所有核心错误码的含义及排查方向
|
||
<<< [L0 主结果] 内容: 725 字符, 3 个章节 ← 约700字符
|
||
```
|
||
|
||
---
|
||
|
||
## 七、MVP 效率评估 & 改进方向
|
||
|
||
### 7.1 当前效率评估
|
||
|
||
| 维度 | 评分 | 说明 |
|
||
|------|:----:|------|
|
||
| L0 匹配速度 | ★★★★★ | 内存索引，< 10ms，几乎没有优化空间 |
|
||
| L1 检索速度 | ★★★★☆ | Milvus 向量检索，200-500ms，取决于数据量 |
|
||
| L0 匹配准确率 | ★★☆☆☆ | 子串匹配，无排序无评分，匹配即返回 |
|
||
| L1 检索准确率 | ★★★☆☆ | 语义相似度，但分块缺少上下文信息 |
|
||
| 召回率（查全） | ★★★☆☆ | L0+L1 两阶段覆盖大多数场景，但缺乏融合重排 |
|
||
| 上下文利用率 | ★★★★☆ | 根据场景动态控制 L0 内容量，已优化 |
|
||
| **综合** | **★★★☆☆** | **MVP 可用，但检索质量有提升空间** |
|
||
|
||
### 7.2 关键瓶颈
|
||
|
||
#### 瓶颈 1：分块丢失上下文（✅ 已修复—见下方 7.5）
|
||
|
||
当前每个 Chunk 只记录最近的 `##` 标题：
|
||
|
||
```json
|
||
{
|
||
"content": "**含义**：支付网关请求超时\n**常见原因**：网络延迟",
|
||
"title": "超时类错误",
|
||
"chunkIndex": 2
|
||
}
|
||
```
|
||
|
||
LLM 收到这个片段时**不知道**它属于"支付网关错误码定义"这个文档，也不知道具体错误码名称是 ERR_TIMEOUT。如果同时检索了多个文档的片段，LLM 容易混淆。
|
||
|
||
#### 瓶颈 2：L0 关键词匹配过于简单
|
||
|
||
当前 `KnowledgeIndexService.matchesKeywords()` 只做子串包含匹配，没有：
|
||
- 排序/评分（多个匹配时按什么顺序？）
|
||
- 权重（标题匹配 > 正文匹配）
|
||
- 部分匹配（"timeout" 匹配 "ERR_TIMEOUT"）
|
||
|
||
#### 瓶颈 3：L0 和 L1 无交叉融合
|
||
|
||
两阶段检索结果只是简单的"1位L0 + 1位L1"拼接，没有：
|
||
- RRF 或加权融合重排
|
||
- 重复内容去重
|
||
- 根据相关性选择 top-K
|
||
|
||
---
|
||
|
||
### 7.3 改进方向分析
|
||
|
||
#### 方向 A：面包屑导航（Chunk 携带层级上下文）
|
||
|
||
**做法**：分块时记录完整的标题层级路径作为 `breadcrumb`。
|
||
|
||
当前分块 metadata:
|
||
```json
|
||
{ "title": "超时类错误" }
|
||
```
|
||
|
||
改进后:
|
||
```json
|
||
{
|
||
"title": "超时类错误",
|
||
"breadcrumb": "支付网关错误码定义 > 超时类错误 > ERR_TIMEOUT",
|
||
"heading_h1": "支付网关错误码定义",
|
||
"heading_h2": "超时类错误",
|
||
"heading_h3": "ERR_TIMEOUT"
|
||
}
|
||
```
|
||
|
||
**收益评估**：
|
||
|
||
| 场景 | 无面包屑的问题 | 有面包屑的改善 | 提升幅度 |
|
||
|------|---------------|---------------|:--------:|
|
||
| 单文档多分块 | LLM 知道标题但不知道层级关系 | 清楚"文档>章节>条目"归属 | 中等 |
|
||
| 跨文档混合结果 | 分块看不出源文档 | breadcrumb 第一段就是文档标题 | 大 |
|
||
| 深层嵌套文档（3+ 级） | 分块内容难以定位 | 完整路径一目了然 | 显著 |
|
||
| 向量检索相关性 | 只对 chunk content 做 embedding | breadcrumb 可拼入 content 做 embedding 或单独索引 | 中等 |
|
||
|
||
**MVP 阶段价值**：当前文档结构较浅（2-3级），breadcrumb 对 LLM 理解帮助中等。但如果后续文档层级加深（像你提到的"排障指南 > 支付网关 > 502错误处理"），价值会显著提升。
|
||
|
||
**实现成本**：低。修改 `DocumentChunkService` 的分块逻辑，积累当前标题栈，写入 `DocumentChunk` 和 Milvus metadata。
|
||
|
||
#### 方向 B：混合检索 + RRF 重排
|
||
|
||
**做法**：L0 关键词和 L1 向量检索并行执行 → 结果用 Reciprocal Rank Fusion 统一排序 → 取 top-K。
|
||
|
||
```
|
||
用户查询 → 并行的:
|
||
├── L0 关键词匹配 → 得分向量 S₀
|
||
└── L1 向量检索 → 得分向量 S₁
|
||
↓
|
||
RRF 融合重排
|
||
↓
|
||
top-K 统一结果
|
||
```
|
||
|
||
RRF 公式：对每个文档 d，`score(d) = Σ 1/(k + rank_r(d))`，其中 k=60（常数）。
|
||
|
||
**收益评估**：
|
||
|
||
| 场景 | 当前的问题 | 混合 + RRF | 提升幅度 |
|
||
|------|-----------|-----------|:--------:|
|
||
| 精确关键词（"ERR_TIMEOUT"） | L0 匹配但不排序，L1 可能不匹配 | L0 高排名 → RRF 拉到顶部 | 大 |
|
||
| 语义查询（"支付超时如何处理"） | L0 可能不匹配，全靠 L1 | L1 兜底不受影响 | 无变化 |
|
||
| 混合查询（"ERR_TIMEOUT 支付网关超时"） | L0 匹配一个、L1 匹配一个，无融合 | RRF 统一排序，更合理 | 中等 |
|
||
| 多文档匹配 | L0 返回无序列表 + L1 独立结果 | 统一排序、去重 | 大 |
|
||
|
||
**MVP 阶段价值**：RRF 的实现成本和维护成本较高，而当前 MVP 数据量小（6 个文档），人工检查即可确定哪些匹配是好的。**建议数据量 > 50 个文档时引入**。
|
||
|
||
#### 方向 C：Breadcrumb + Embedding 增强
|
||
|
||
**做法**：将 breadcrumb 拼入 chunk content 后再做 embedding，让向量包含层级语义。
|
||
|
||
```java
|
||
// 当前
|
||
embeddingService.generateEmbedding(chunk.getContent())
|
||
|
||
// 改进
|
||
String augmentedContent = chunk.getBreadcrumb() + "\n" + chunk.getContent();
|
||
embeddingService.generateEmbedding(augmentedContent);
|
||
```
|
||
|
||
这样搜索"ERR_TIMEOUT"时，"支付网关错误码定义 > 超时类错误 > ERR_TIMEOUT" 也会匹配到，而不只是 chunk 正文。
|
||
|
||
| 场景 | 当前 | Breadcrumb + Embedding | 提升 |
|
||
|------|------|------------------------|:----:|
|
||
| 搜索"支付网关超时" | 匹配到正文含"超时"和"支付网关"的 chunk | breadcrumb 直接含"支付网关"，匹配更准 | 中等 |
|
||
| 搜索"错误码定义" | 可能匹配不到具体错误内容的 chunk | breadcrumb 含"错误码定义"，相关性更高 | 大 |
|
||
|
||
---
|
||
|
||
### 7.4 实施优先级建议
|
||
|
||
| 优先级 | 改进项 | 复杂度 | 收益 | 状态 |
|
||
|:------:|--------|:------:|:----:|:----:|
|
||
| P0 | **Breadcrumb 上下文**（方向 A） | 低 | 中 | **✅ 已实现 (2026-06-26)** |
|
||
| P1 | 下个版本 | 低 | 中-大 | 待定 |
|
||
| P1 | L0 排序（匹配评分 + 排序） | 低 | 中 | 待定 |
|
||
| P2 | 混合检索 + RRF 重排 | 高 | 大 | 数据量 > 50 文档时引入 |
|
||
|
||
### 7.5 Breadcrumb 实现说明
|
||
|
||
已于 2026-06-26 实现。改动范围：
|
||
|
||
| 文件 | 改动 |
|
||
|------|------|
|
||
| `DocumentChunk.java` | 新增 `breadcrumb` 字段 |
|
||
| `DocumentChunkService.java` | `splitByHeadings()` 维护标题层级栈，`Section` 新增 `level`/`breadcrumb`，`chunkSection()` 和 `saveChunkAndGetNextStart()` 透传 Breadcrumb |
|
||
| `VectorIndexService.java` | `buildMetadata()` 和 `buildDocumentMetadata()` 将 breadcrumb 写入 Milvus metadata |
|
||
|
||
#### 层级栈算法
|
||
|
||
```java
|
||
// 在 splitByHeadings() 中，每次匹配到标题时：
|
||
while (!headingStack.isEmpty() && headingStack.size() >= level) {
|
||
headingStack.remove(headingStack.size() - 1); // 弹出同级或更高级
|
||
}
|
||
headingStack.add(title); // 追加当前标题
|
||
currentBreadcrumb = String.join(" > ", headingStack);
|
||
```
|
||
|
||
示例：处理 `fault-diagnosis-process.md` 的完整面包屑路径──
|
||
|
||
```json
|
||
// 分块 "应急响应流程 > 1. 初步评估"
|
||
{ "breadcrumb": "故障诊断流程规范 > 应急响应流程 > 1. 初步评估" }
|
||
|
||
// 分块 "根因分析方法 > 5-Why 分析法"
|
||
{ "breadcrumb": "故障诊断流程规范 > 根因分析方法 > 5-Why 分析法" }
|
||
```
|
||
|
||
#### 当前 metadata 结构（Milvus）
|
||
|
||
```json
|
||
{
|
||
"_source": "knowledge_base/api/payment-errors.md",
|
||
"_file_name": "payment-errors.md",
|
||
"category": "api",
|
||
"chunkIndex": 2,
|
||
"totalChunks": 5,
|
||
"title": "超时类错误",
|
||
"breadcrumb": "支付网关错误码定义 > 超时类错误 > ERR_TIMEOUT"
|
||
}
|
||
```
|
||
|
||
以 `fault-diagnosis-process.md` 为例：
|
||
|
||
```markdown
|
||
# 故障诊断流程规范 ← heading_h1
|
||
|
||
## 应急响应流程 ← heading_h2
|
||
|
||
### 1. 初步评估 ← heading_h3（分块1）
|
||
内容...
|
||
|
||
### 2. 快速止血 ← heading_h3（分块2）
|
||
内容...
|
||
|
||
## 根因分析方法 ← heading_h2
|
||
|
||
### 5-Why 分析法 ← heading_h3（分块3）
|
||
内容...
|
||
```
|
||
|
||
改造后每个分块的 metadata：
|
||
|
||
```
|
||
分块1: breadcrumb = "故障诊断流程规范 > 应急响应流程 > 1. 初步评估"
|
||
分块2: breadcrumb = "故障诊断流程规范 > 应急响应流程 > 2. 快速止血"
|
||
分块3: breadcrumb = "故障诊断流程规范 > 根因分析方法 > 5-Why 分析法"
|
||
```
|
||
|
||
LLM 视角受益：当检索到 "2. 快速止血" 时，LLM 立刻知道它属于"故障诊断流程规范 > 应急响应流程"体系，不需要额外读取其他分块来推断上下文。
|
||
|
||
| 文件 | 说明 |
|
||
|------|------|
|
||
| `LookupKnowledgeTool.java` | 检索工具入口 |
|
||
| `KnowledgeIndexService.java` | L0 内存索引管理 |
|
||
| `VectorSearchService.java` | L1 向量检索（Milvus） |
|
||
| `KnowledgeEntry.java` | 索引条目 DTO（含 title, summary, keywords） |
|
||
| `LookupResult.java` | 查询结果 DTO |
|
||
| `PrimaryResult.java` | L0 结果 DTO |
|
||
| `SupplementResult.java` | L1 结果 DTO |
|