475900e103
- RAG数据流程.md: 更新模型配置为 deepseek-v4-flash，补充 v7.1 变更 - 新增十二~十六章节：缓存系统、图片选择管线、VLM 懒加载、 文档解析与切片、性能插桩 - 待解决风险项.md: 记录 7 个已识别但未实施的风险项
126 lines
4.4 KiB
Markdown
126 lines
4.4 KiB
Markdown
# 待解决风险项
|
||
|
||
> 本文档记录已识别但尚未实施修复的风险项，供后续迭代参考。
|
||
> 更新日期：2026-06-21
|
||
|
||
---
|
||
|
||
## P1: SemanticCache 满容量全清空
|
||
|
||
**文件**：`core/semantic_cache.py:161-164`
|
||
|
||
**现状**：当 FAISS 索引达到 `max_size`（默认 10000）时，执行 `self.clear()` 全清空，而非 LRU 淘汰最旧条目。
|
||
|
||
**影响**：高使用量下缓存命中率周期性断崖式下降，下一波请求全部 miss。
|
||
|
||
**建议方案**：
|
||
- 短期：可接受，断崖后缓存会重新积累
|
||
- 长期：改为分批淘汰（每次淘汰最旧 N 条），或引入 TTL 自动过期
|
||
|
||
**风险等级**：中（性能波动，不影响正确性）
|
||
|
||
---
|
||
|
||
## P2: _exact_cache 满后永久拒绝新条目
|
||
|
||
**文件**：`core/intent_analyzer.py:412-413`
|
||
|
||
**现状**：
|
||
|
||
```python
|
||
if len(self._exact_cache) < self._exact_cache_max: # 500
|
||
self._exact_cache[exact_key] = analysis
|
||
```
|
||
|
||
500 条满后不再接受新条目，且无淘汰机制。服务运行一段时间后，精确缓存变为固定快照。
|
||
|
||
**影响**：后续查询的精确缓存命中率逐渐归零，退化为每次都走语义缓存或 LLM 调用。
|
||
|
||
**建议方案**：改用 `OrderedDict` + 淘汰最旧条目，与 `LRUCache` 保持一致。
|
||
|
||
**风险等级**：低（性能退化，不影响正确性）
|
||
|
||
---
|
||
|
||
## P3: Jaccard 字符级阈值偏松
|
||
|
||
**文件**：`core/intent_analyzer.py:450-473`
|
||
|
||
**现状**：语义缓存二次验证使用字符级 Jaccard 相似度，阈值 0.5。中文短句共享大量单字（如"如何申请" vs "如何拒绝"），Jaccard = 2/4 = 0.5 刚好过线。
|
||
|
||
**影响**：语义相似但意图不同的查询可能误命中缓存。
|
||
|
||
**建议方案**：
|
||
- 方案 A：提升阈值到 0.6
|
||
- 方案 B：改用 bigram Jaccard（相邻字对作为集合元素）
|
||
|
||
**风险等级**：低（误命中概率不高，且有 embedding 0.92 阈值前置过滤）
|
||
|
||
---
|
||
|
||
## P4: /cache/clear 无 DEV_MODE 守卫
|
||
|
||
**文件**：`api/sync_routes.py:322`
|
||
|
||
**现状**：`POST /cache/clear` 端点仅使用 `@require_gateway_auth`，没有 `DEV_MODE` 检查。生产环境任何认证用户都能清缓存。其他 dev-only 端点（如 `document_routes.py` 的预览接口）有 `DEV_MODE` 守卫。
|
||
|
||
**影响**：生产环境缓存被误清，导致短暂的性能下降。
|
||
|
||
**建议方案**：添加 `DEV_MODE` 检查，或限制为 admin 角色。
|
||
|
||
**风险等级**：中（生产环境影响）
|
||
|
||
---
|
||
|
||
## P5: PDF TOC 目录数据未单独处理
|
||
|
||
**文件**：`parsers/mineru_parser.py`
|
||
|
||
**现状**：PDF 文档的目录页（TOC）被 MinerU 解析为多个 text_level=1 的标题切片，内容包含 `....1` 等页码标记。这些目录切片入库后污染 section 元数据，干扰章节过滤和上下文扩展。
|
||
|
||
**影响**：RAG 检索时目录切片可能被误判为相关章节，干扰上下文扩展的 section 精确匹配。
|
||
|
||
**建议方案**：
|
||
- 解析阶段检测 TOC 模式（连续短标题 + 页码标记）
|
||
- 标记 `chunk_type: 'toc'` 或直接跳过不入库
|
||
|
||
**风险等级**：中（影响检索质量）
|
||
|
||
---
|
||
|
||
## P6: PDF chart VLM 描述缺失
|
||
|
||
**文件**：`knowledge/lazy_enhance.py`、`parsers/mineru_parser.py`
|
||
|
||
**现状**：部分 PDF 图表切片的 VLM 描述为空。原因可能是：
|
||
1. MinerU VLM API 对部分图表返回空 content（上游问题）
|
||
2. 解析阶段的提取条件过严（如要求 `'|' in markdown` 才提取 chart_markdown）
|
||
|
||
**影响**：无 VLM 描述的图表切片退化为纯关键词匹配，图片选择准确率下降。
|
||
|
||
**建议方案**：
|
||
- 上游：跟进 MinerU API 的空 content 问题
|
||
- 本地兜底：用 `caption + section + 上下文文本` 拼接作为 fallback 描述
|
||
- 定期重算：用 `sync_vlm_cache.py --re-embed` 批量重算
|
||
|
||
**风险等级**：低（有 lazy_enhance 兜底，首次查询后补生成）
|
||
|
||
---
|
||
|
||
## P7: 图片选择负面用例误召回
|
||
|
||
**文件**：`api/chat_routes.py`
|
||
|
||
**现状**：定义/原则类查询（如"五化终端定义"、"防洪调度原则"）不应返回图片，但 `select_images` 仍返回了 2-3 张。根因：
|
||
1. `_filter_images_by_answer` 的关键词重叠阈值对长回答偏宽松
|
||
2. 兜底逻辑：过滤后为空时保留分数最高的 1 张
|
||
|
||
**影响**：用户看到不相关的图片，降低信任度。
|
||
|
||
**建议方案**：
|
||
- 增加查询意图判断：纯定义/原则类查询不应触发图片返回
|
||
- 移除兜底逻辑或提高兜底阈值
|
||
- 增加"不应返回图片"的负面评测用例
|
||
|
||
**风险等级**：中（影响用户体验）
|