sundynix-agentix

sundynix/sundynix-agentix

Fork 0

Commit Graph

Author	SHA1	Message	Date
Blizzard	b26fe21408	fix(rag): 检索三路不再静默吞错 —— 逐路诊断 + 一路挂不拖垮全部排查"向量路为什么是空的"花了半小时，因为空就是空，没有任何线索。这次把整条检索链上的静默降级一次清掉。真 bug（不只是可观测性）： - kb_search 与 Search() 都拿 rag.Ready() 当总闸，而 Ready() 只代表"向量路可用"（embedding + Milvus）。全文(bleve)与图谱(Neo4j)根本不依赖它们，却被一并毙掉 → "模型配置没下发"表现为"整个知识库什么都搜不到"，还不报错。改为逐路判定，任一路可用就仍有召回。不再吞错： - milvus.search 原先把 error 转成 nil,nil —— 检索失败与无召回彻底无法区分； - bleve.search / graph.search 出错直接回 nil，连日志都没有； - searchPaths 丢掉 embedding 的 error。三处改为如实返回，错误统一打日志。逐路诊断（RouteDiag）：每路上报 ok/empty/disabled/error + 耗时 + 原因，经 kb_search 的 diag 参数（仅试验台传，生产调用返回值不变）→ gateway → 检索试验台。界面上现在能直接看出"这一路没配置/报错了/确实没匹配"，不必翻日志。内存兜底索引也会在 note 里点明"重启即清零"。测试：3 组，覆盖"无 embedding 时全文仍可召回"、三种空的区分、内存索引提示。把总闸加回去验证过第一条确实会红——测试能抓到这个回归，不是摆设。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 15:10:03 +08:00
Blizzard	79e834e8e9	feat(rag): 大文件 RAG 做深 —— 并发入库/图谱窗口化 + Bleve落盘 + file_id治理几十万字文件从"广而浅"到准生产级： - 向量化串行→并发分批保序(embedAll)；几十万字上千块快数倍 - 图谱整篇喂LLM(爆上下文只抽开头)→窗口化并发抽(extractGraphWindowed)，全覆盖；窗口/封顶/并发 env 可配；图谱可单配便宜模型(GRAPH_CHAT_*，未配回退主chat) - Bleve 内存索引(重启即丢、三路退两路)→落盘 scorch(env BLEVE_PATH，失败退内存兜底) - 下游键改稳定 file_id：Neo4j 关系打 file_id(实体仍 kb+name 共享)；新增 kb_delete 工具 + Engine.DeleteDoc 级联删 Milvus/Bleve/Neo4j - 单测：窗口化/去重/env可配/落盘持久/图谱模型回退 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-30 13:37:45 +08:00
Blizzard	a4852c3aef	fix(rag): T2.2 把"三路混合"做实 —— 中文全文/图谱两路从 0 贡献修活基建拉起后实测发现"三路混合检索"对中文其实只有向量路在干活： `hybrid: 向量=1 全文=0 图谱=0` —— 全文、图谱两路恒 0 贡献（典型"广而浅"）。两个真因： 1. Bleve 全文：默认标准分词器不切中文 → 整段当一个 token → 中文查询永远 0 命中。修：text 字段用 cjk 分词器（bigram），kb/doc 用 keyword（保 TermQuery 精确过滤）。 2. 图谱检索：`$q CONTAINS a.name` 要求实体名是查询子串，而 LLM 把实体抽成"星云一号卫星" （带后缀），查询说"星云一号"→ CONTAINS 失败 → 0 命中。修：加查询字符 n-gram（2..8）双向子串匹配，`星云一号` 即可命中 `星云一号卫星`。 live 验证（同一查询）：修复前 `向量=1 全文=0 图谱=0` → 修复后 `向量=1 全文=1 图谱=9`，三路全贡献。中文混合检索从 1/3 变真 3/3。测试：Bleve 中文检索命中 + queryNgrams 子串/长度边界（CI 安全，无需基建）。 DEPTH_ROADMAP T2.2：三路做实✅；检索质量度量(离线评测集 recall@k/MRR)待补。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-30 10:00:25 +08:00

Author

SHA1

Message

Date

Blizzard

b26fe21408

fix(rag): 检索三路不再静默吞错 —— 逐路诊断 + 一路挂不拖垮全部

排查"向量路为什么是空的"花了半小时，因为空就是空，没有任何线索。这次把
整条检索链上的静默降级一次清掉。

真 bug（不只是可观测性）：
  - kb_search 与 Search() 都拿 rag.Ready() 当总闸，而 Ready() 只代表"向量路
    可用"（embedding + Milvus）。全文(bleve)与图谱(Neo4j)根本不依赖它们，却
    被一并毙掉 → "模型配置没下发"表现为"整个知识库什么都搜不到"，还不报错。
    改为逐路判定，任一路可用就仍有召回。

不再吞错：
  - milvus.search 原先把 error 转成 nil,nil —— 检索失败与无召回彻底无法区分；
  - bleve.search / graph.search 出错直接回 nil，连日志都没有；
  - searchPaths 丢掉 embedding 的 error。
    三处改为如实返回，错误统一打日志。

逐路诊断（RouteDiag）：每路上报 ok/empty/disabled/error + 耗时 + 原因，经
kb_search 的 diag 参数（仅试验台传，生产调用返回值不变）→ gateway → 检索
试验台。界面上现在能直接看出"这一路没配置/报错了/确实没匹配"，不必翻日志。
内存兜底索引也会在 note 里点明"重启即清零"。

测试：3 组，覆盖"无 embedding 时全文仍可召回"、三种空的区分、内存索引提示。
把总闸加回去验证过第一条确实会红——测试能抓到这个回归，不是摆设。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-20 15:10:03 +08:00

Blizzard

79e834e8e9

feat(rag): 大文件 RAG 做深 —— 并发入库/图谱窗口化 + Bleve落盘 + file_id治理

几十万字文件从"广而浅"到准生产级：
- 向量化串行→并发分批保序(embedAll)；几十万字上千块快数倍
- 图谱整篇喂LLM(爆上下文只抽开头)→窗口化并发抽(extractGraphWindowed)，
  全覆盖；窗口/封顶/并发 env 可配；图谱可单配便宜模型(GRAPH_CHAT_*，未配回退主chat)
- Bleve 内存索引(重启即丢、三路退两路)→落盘 scorch(env BLEVE_PATH，失败退内存兜底)
- 下游键改稳定 file_id：Neo4j 关系打 file_id(实体仍 kb+name 共享)；
  新增 kb_delete 工具 + Engine.DeleteDoc 级联删 Milvus/Bleve/Neo4j
- 单测：窗口化/去重/env可配/落盘持久/图谱模型回退

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-30 13:37:45 +08:00

Blizzard

a4852c3aef

fix(rag): T2.2 把"三路混合"做实 —— 中文全文/图谱两路从 0 贡献修活

基建拉起后实测发现"三路混合检索"对中文其实只有向量路在干活：
`hybrid: 向量=1 全文=0 图谱=0` —— 全文、图谱两路恒 0 贡献（典型"广而浅"）。两个真因：

1. Bleve 全文：默认标准分词器不切中文 → 整段当一个 token → 中文查询永远 0 命中。
   修：text 字段用 cjk 分词器（bigram），kb/doc 用 keyword（保 TermQuery 精确过滤）。
2. 图谱检索：`$q CONTAINS a.name` 要求实体名是查询子串，而 LLM 把实体抽成"星云一号卫星"
   （带后缀），查询说"星云一号"→ CONTAINS 失败 → 0 命中。
   修：加查询字符 n-gram（2..8）双向子串匹配，`星云一号` 即可命中 `星云一号卫星`。

live 验证（同一查询）：修复前 `向量=1 全文=0 图谱=0` → 修复后 `向量=1 全文=1 图谱=9`，
三路全贡献。中文混合检索从 1/3 变真 3/3。
测试：Bleve 中文检索命中 + queryNgrams 子串/长度边界（CI 安全，无需基建）。

DEPTH_ROADMAP T2.2：三路做实✅；检索质量度量(离线评测集 recall@k/MRR)待补。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-30 10:00:25 +08:00

3 Commits