group_fqcd_jr

414 Commits 12 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
张胜宇	2762b05203	docs(W24): 交付件口径纠错 —— D2.4 自相矛盾 / D2.5 过期块数 / D4.8 墓碑行误标 / D2.6 补 W24 状态复核时发现四处「交付件里的事实错误」，逐条修： - D2.4 §AC-04/AC-05 段：正文写「本仓库 _chunks.jsonl 当前 617 块全部为 public」，与本文档自己的 v1.6/v1.8 版本行（public 730 / registered 25）自相矛盾。改为标「设计当时」+ 补 v1.8 现状（755 块），并写明 AC-04/AC-05 现已可证伪、不再需要「造一条测试块」（双向验证已于 2026-09-18 实测通过）。 - D2.5 演示脚本：「族判定（family_id 628 块全覆盖）」→ 755 块（W24 复测）。这是答辩当天要照着念的稿子，块数必须与实库一致。 - D4.8 §9.2：把「新集合条数 basic 105 / product 398 / faq 300 / policy 576」当成真实条数引用 —— 那组数字是 upsert 留下的墓碑行被计入 get_collection_stats().row_count 的结果（同 D2.1 v6.9：298/576/382 = 存活行 149/288/191 的两倍）。已补口径更正段，写明本轮复测的存活行数 251/154/288/62 = 755，并定下「引用块数一律用 _chunks.jsonl，不用 row_count」。 - D2.6 答辩报告：补一条 2026-09-21 W24 状态更新 —— ① docs/43 场内基金手册已入库（20 只场内基金，702 → 755 块），「问在库产品却答另一只」的根因已根除； ② 出口经 E2c-my 细分后共六个（E1/E2/E2c-my/E3/E4/E5），转人工只在 E5c。已复核：Milvus 四集合存活行数与 knowledge/_chunks.jsonl 逐集合一致（288/251/154/62 = 755），无墓碑行残留；recalls_customer_memory 仍为 False，与 D2.7 记载一致。 D2.4 HTML 结构自检通过（table/tr/td 标签配平）。	2026-09-21 14:36:08 +08:00
张胜宇	eb1822d802	docs(W18): D2.4 索引口径更正为 AUTOINDEX（v1.6）+ D2.9 手动对话测试用例成文 + 空白消息 500 修复 - D2.4 v1.3 -> v1.6：索引统一 AUTOINDEX（设计初稿 HNSW/IVF_FLAT 未落地，实库直查为据）更正 9 处 + 新增 §4.1 索引口径落地注；语料 628 -> 675 块并补 fin_basic_collection 说明（三集合仍是唯一默认检索面，basic 并入会使 M-1 100% -> 91.3%） - 新增客服agent/D2.9-客服Agent手动对话测试用例-2026-09-20.md： 46 条金标逐条可问 + 11 条边界 Z 组 + 判分四问 + M-1~M-10 手动汇总 + 真 HTTP 核验配方实测登记 3 项缺口：空白消息 500（已修）/ 语料档位口径矛盾（待裁定）/ 重复问句漂移（待裁定） - 修修复：message 纯空白 500 -> 422 AGENT_INPUT_INVALID（入口补判据 + 回归测试） - tools/chat_console.py 提示语去掉已下线产品名（季季盈） - 落档：D1.1 §27（60 -> 61 份 / 客服agent 8 -> 9 份 / 注入校验 56 -> 57）、D2.1 v6.33、D1.6 §4.46 - 门禁：check_authoritative_docs 通过、_consistency.py GATE PASS、pytest 1915 passed / 0 failed	2026-09-20 17:31:40 +08:00
lzf_0626	927a6fecc0	评审 NL_develop 交付说明：三个环境前提必须先对齐产出 docs/NL_develop交付说明-评审意见.md（可直接转给组员），以及一个只读探查工具 tools/probe_knowledge_collections.py（Milvus 集合 schema 与行数）。核查中发现的硬矛盾，都有可复核的证据： 1. 配置库不是同一个。对方说 active=216、合并前生效版本是 186；我这边实测 active=201，最近 5 条 id 就是 201/198/197/196/195 —— release.id 自增，同库不可能一边 216 一边 201。所以他以为已发布的 customer_service:faq=[search_knowledge, query_customer_profile] 在这边并不存在，而他的画像出口复用的正是这个 key ⇒ 合并后被 ToolExecutor 失败关闭。同理他说的 fund_query_demo:fund_quote 缺失，我这边是存在的。 2. Milvus 也不是同一个。对方说现库字段是 knowledge_id/snippet、无 visibility、行数 106/177/73；我这边实测是 doc_id/content/chapter/section/.../visibility 共 15 个字段、行数 125/297/214，且与 knowledge_search_service.py 的 OUTPUT_FIELDS 逐字一致。他这次的字段映射改动（doc_id→knowledge_id）在这边会直接报 field knowledge_id not exist，把客服知识检索整条打挂 —— 比他自述的"关闭 visibility 隔离"严重得多。建议不是 A/B/C 三选一，而是第四种：运行时探测字段名，两套 schema 都能跑。 3. 解释器不同。他用 .venv（项目里不存在，那是他机器上的 gitignore 目录），约定是 D:\conda\envs\jr_py313。所以"mypy 151→181"跑不到本基线 —— 这边是 138 文件 0 错。另指出：docs/26-JWT密钥管理与轮换.md 会与已存在的 docs/21-JWT密钥管理与轮换.md 重复，建议并入 21；驳回删除 docs/04/06/10/13/99。四项待裁决的答复：同意 agent_type 方案（要求补审计）；字段映射改为运行时探测；驳回删除编号文档；26 并入 21。	2026-09-11 16:51:52 +08:00

Author

SHA1

Message

Date

张胜宇

2762b05203

docs(W24): 交付件口径纠错 —— D2.4 自相矛盾 / D2.5 过期块数 / D4.8 墓碑行误标 / D2.6 补 W24 状态

复核时发现四处「交付件里的事实错误」，逐条修：

- D2.4 §AC-04/AC-05 段：正文写「本仓库 _chunks.jsonl 当前 617 块全部为 public」，
  与本文档自己的 v1.6/v1.8 版本行（public 730 / registered 25）自相矛盾。
  改为标「设计当时」+ 补 v1.8 现状（755 块），并写明 AC-04/AC-05 现已可证伪、
  不再需要「造一条测试块」（双向验证已于 2026-09-18 实测通过）。

- D2.5 演示脚本：「族判定（family_id 628 块全覆盖）」→ 755 块（W24 复测）。
  这是答辩当天要照着念的稿子，块数必须与实库一致。

- D4.8 §9.2：把「新集合条数 basic 105 / product 398 / faq 300 / policy 576」
  当成真实条数引用 —— 那组数字是 upsert 留下的墓碑行被计入
  get_collection_stats().row_count 的结果（同 D2.1 v6.9：298/576/382 = 存活行
  149/288/191 的两倍）。已补口径更正段，写明本轮复测的存活行数
  251/154/288/62 = 755，并定下「引用块数一律用 _chunks.jsonl，不用 row_count」。

- D2.6 答辩报告：补一条 2026-09-21 W24 状态更新 —— ① docs/43 场内基金手册已入库
  （20 只场内基金，702 → 755 块），「问在库产品却答另一只」的根因已根除；
  ② 出口经 E2c-my 细分后共六个（E1/E2/E2c-my/E3/E4/E5），转人工只在 E5c。

已复核：Milvus 四集合存活行数与 knowledge/_chunks.jsonl 逐集合一致（288/251/154/62 = 755），
无墓碑行残留；recalls_customer_memory 仍为 False，与 D2.7 记载一致。
D2.4 HTML 结构自检通过（table/tr/td 标签配平）。

2026-09-21 14:36:08 +08:00

张胜宇

eb1822d802

docs(W18): D2.4 索引口径更正为 AUTOINDEX（v1.6）+ D2.9 手动对话测试用例成文 + 空白消息 500 修复

- D2.4 v1.3 -> v1.6：索引统一 AUTOINDEX（设计初稿 HNSW/IVF_FLAT 未落地，实库直查为据）
  更正 9 处 + 新增 §4.1 索引口径落地注；语料 628 -> 675 块并补 fin_basic_collection 说明
  （三集合仍是唯一默认检索面，basic 并入会使 M-1 100% -> 91.3%）
- 新增 客服agent/D2.9-客服Agent手动对话测试用例-2026-09-20.md：
  46 条金标逐条可问 + 11 条边界 Z 组 + 判分四问 + M-1~M-10 手动汇总 + 真 HTTP 核验配方
  实测登记 3 项缺口：空白消息 500（已修）/ 语料档位口径矛盾（待裁定）/ 重复问句漂移（待裁定）
- 修修复：message 纯空白 500 -> 422 AGENT_INPUT_INVALID（入口补判据 + 回归测试）
- tools/chat_console.py 提示语去掉已下线产品名（季季盈）
- 落档：D1.1 §27（60 -> 61 份 / 客服agent 8 -> 9 份 / 注入校验 56 -> 57）、D2.1 v6.33、D1.6 §4.46
- 门禁：check_authoritative_docs 通过、_consistency.py GATE PASS、pytest 1915 passed / 0 failed

2026-09-20 17:31:40 +08:00

lzf_0626

927a6fecc0

评审 NL_develop 交付说明：三个环境前提必须先对齐

产出 docs/NL_develop交付说明-评审意见.md（可直接转给组员），以及一个只读探查工具
tools/probe_knowledge_collections.py（Milvus 集合 schema 与行数）。

核查中发现的硬矛盾，都有可复核的证据：

1. 配置库不是同一个。对方说 active=216、合并前生效版本是 186；我这边实测 active=201，
   最近 5 条 id 就是 201/198/197/196/195 —— release.id 自增，同库不可能一边 216 一边 201。
   所以他以为已发布的 customer_service:faq=[search_knowledge, query_customer_profile]
   在这边并不存在，而他的画像出口复用的正是这个 key ⇒ 合并后被 ToolExecutor 失败关闭。
   同理他说的 fund_query_demo:fund_quote 缺失，我这边是存在的。

2. Milvus 也不是同一个。对方说现库字段是 knowledge_id/snippet、无 visibility、行数
   106/177/73；我这边实测是 doc_id/content/chapter/section/.../visibility 共 15 个字段、
   行数 125/297/214，且与 knowledge_search_service.py 的 OUTPUT_FIELDS 逐字一致。
   他这次的字段映射改动（doc_id→knowledge_id）在这边会直接报 field knowledge_id not
   exist，把客服知识检索整条打挂 —— 比他自述的"关闭 visibility 隔离"严重得多。
   建议不是 A/B/C 三选一，而是第四种：运行时探测字段名，两套 schema 都能跑。

3. 解释器不同。他用 .venv（项目里不存在，那是他机器上的 gitignore 目录），约定是
   D:\conda\envs\jr_py313。所以"mypy 151→181"跑不到本基线 —— 这边是 138 文件 0 错。

另指出：docs/26-JWT密钥管理与轮换.md 会与已存在的 docs/21-JWT密钥管理与轮换.md 重复，
建议并入 21；驳回删除 docs/04/06/10/13/99。

四项待裁决的答复：同意 agent_type 方案（要求补审计）；字段映射改为运行时探测；
驳回删除编号文档；26 并入 21。

2026-09-11 16:51:52 +08:00