 lzf_0626
|
06d0f9f231
|
知识库检索质量修复：「风险评估问卷怎么评分」从必然转人工 → 直接答
## 根因（两个问题叠加）
1. 灌库脚本 tools/build_knowledge_chunks.py 的 expand_table_rows() 用「第一个非分隔行」
当表头且 header 从不重置 → 同一节里第 2 张表格起**表头被当成数据行**。
《个人投资者适当性管理指南》第九条下有 16 张问卷表格 → 15 条正文逐字相同的
19 字零信息量碎片；同类共 19 条。
2. 检索层去重只按 doc_id，接不住「同一父块的兄弟子块」（POL-AST-009-07 与 -12 是
不同 doc_id、同一父块）→ 15 条碎片全留在候选里互相打平，把 top1/次优差压到 0.002，
而客服判定要求中置信必须领先 ≥0.07（MIN_GAP）→ 恒判并列转人工。
## 为什么没有重灌知识库
用 Milvus 现成向量离线复算四种做法（同一问句、同一批向量）：
现状 gap 0.002 转人工
只修 bug（=重灌全部收益） gap 0.001 仍转人工，且更糟
只加父块归并 gap 0.093 可答，但答案是 19 字碎片
两处都改 gap 0.076 可答且有内容
原因：第九条被切成 94 块，删掉 15 条表头碎片后，剩下 79 条数据行碎片依然互相打平。
重灌解决不了，却要停机 3–10 分钟并丢掉上传路径的内容（含 R1–R5 那条）。
## 改了什么
① app/service/knowledge_search_service.py：新增 _merge_sibling_subblocks()
同一父块的兄弟子块只保留最高分那条；父块自身与 FAQ/政策这类本身就是细粒度答案
的块一律不合并（它们之间打平是真的多个候选）。6 个单测守着。
被丢掉的只是同节其它细节，本节完整内容由 _parent_hits 带回的父块兜底。
② tools/build_knowledge_chunks.py：修表头识别（markdown 表格只有紧邻 |---| 之前的
那一行才是表头）+ 新增 assert_no_duplicate_contents() 自带守卫 ——
正文完全相同的块必须为 0，否则中止且不写 jsonl。该脚本是一次性灌库脚本、
原来没有单测覆盖，这正是该 bug 活下来的原因，所以守卫放在它自己的执行路径上。
块数 636 → 617；正文完全相同的组 1 组 15 块 → 0 组。
负向验证：换回旧逻辑跑，退出码 1 并报出那 15 份碎片，且未覆盖 jsonl。
③ tools/drop_table_header_vectors.py：清掉已灌进 Milvus 的 19 条历史碎片。
判定可复现：语义 id（非纯数字）且正文不在修正后产物里。只动语义 id 是因为
纯数字 id 来自上传路径、本来就不在 jsonl 里（实测冒烟 A 线的 top1 就是数字 id 179）；
不按长度判是因为短块本身是设计的一部分（「评审标准：管理人资质 15%」13 字是有效答案）。
实删 policy 16 + product 3，faq 0；dry-run 逐条核对过，全部是「标签 + 表头词」形态。
这是唯一一次绕过 Outbox 的删除：事件消费侧要回读 MySQL 行，而这批是无元数据种子向量。
## 验证
真实链路 10 问句回归 10/10 与预期一致，0 个变坏：
风险评估问卷怎么评分 0.7156 gap 0.1473 → 答（原 0.002 转人工），top1 变成真实答案行
场内基金的管理费率 0.8114 gap 0.0977 → 直接答（冒烟 A 线）
南方季季盈90天起投金额 0.8631 gap 0.3387 → 直接答（行级子块精确命中能力未受影响）
今天天气怎么样 仍正确转人工
端到端：ask_customer_service.py「风险评估问卷怎么评分」→ 直接答，返回完整评分标准；
e2e_smoke_test.py 44/44（含 A4 知识库覆盖未转人工）；
pytest tests/unit tests/contract 1506 passed / 0 failed；
对账 重复正文 15 → 0，孤儿/死向量/缺向量仍全为 0。
（冒烟首跑 42/43 的唯一失败 B6 买入下单 503 是行情过期，补刷后 44/44，与本次无关。）
## 顺带查明
Milvus 的 delete() 是标记删除，约 1 秒后才在 query/search 中不可见（隔离临时集合实测：
删完立即查仍看得到，+1s 起消失）。清理工具第一版"删完立刻复核"因此谎报 19 条残留，
已改为轮询复核并把文案改成实测依据。get_collection_stats().row_count 在删除后仍显示旧值，
这也是对账工具坚持用 query 实际行数的原因。
## 文档
新增 docs/演示用/知识库检索质量修复-2026-09-15.md（根因、四方案对比、改动、全部证据）；
并对 docs/演示用/知识库向量对账与清理-2026-09-15.md 做更正 —— 451 条短块里 429 条是
设计内的有效数据行、只有 19 条是 bug 产物；"按长度合并短块 + 重建重灌"的建议已被实测否决。
## 仍未解决（记录在案）
「高净值客户有什么权益」gap 0.0075 仍转人工：根因是不同父块之间同族内容打平
（金卡 vs 白金权益），父块归并救不了也不该救，要从内容侧或业务口径入手。
knowledge/_chunks.jsonl（新 617 块、编号连续）与 Milvus（旧编号、含 19 个空洞）目前不一致；
不重灌无影响，但下次重灌必须 drop 集合重建而不是 upsert，否则两套编号会共存。
|
2026-09-15 09:31:57 +08:00 |
|
|
lzf_0626
|
4c2b147793
|
feat(knowledge): 产品知识拆到表格行级，并按问句选粒度
问题（客户实测反馈）：同一会话里问「季季盈90天起投多少」和「那它风险高吗」，两次回答
**一模一样**——都是整个产品小节的表格。客户问的是风险，收到的是整张说明书，看起来像
客服没听懂问题。
根因是切分粒度：原来"一个叶子标题 = 一块"，产品手册里就是整个产品小节（表格 + 说明）
成一块。这既让两个不同的问题命中同一块，也让整节几百字的向量成了"整节的混合语义"，
与"起投多少"这种具体小问题相似度天然偏低（实测该问句向量 top1 仅 0.6291，够不到 0.75
硬门槛，只能靠与次优的差值勉强通过）。
改动三处：
1. 切分：Markdown 表格的每一行额外生成一个**自解释**的小块（"南方季季盈90天：起投金额
1万元"），挂在父块 doc_id 下（PROD-007-04），父块照旧保留。知识块 160 → 631。
效果：该问句的命中分从 0.6291 升到 0.869，命中的正是"起投金额"那一行。
2. 检索：命中行级子块时把它的整节父块一并带回（分数按 0.9 折算），供调用方按问句选粒度。
整节块保底占最后一个名额，且不参与 top1/top2 判定——实测它挤到第 2 位会把 gap 从
0.090 压到 0.076，几乎跌破 0.07 的转人工门槛。
3. 客服：命中的是行级子块时，看问句与子块标签是否真的对得上——「起投多少」对「起投金额」
对得上，用那一行；「介绍一下」对不上，换成整节。
过程中两次判据写错并已修正（都固化进了测试）：用"含连字符"认子块时，整节块自己的编号
PROD-901 被误判成子块；用"不含两位数字后缀"认整节块时，FAQ 块全被误判成整节块排到后面，
把正确答案挤出 top1、害得「基金赎回几天到账」转人工。
验证：起投/管理费等字段问法给出聚焦的单行答案；"介绍一下"给出整节；FAQ 与政策问法不受
影响（换话题、指代追问等此前修好的场景复测通过）；
ruff / mypy(113 文件) / 468 unit+contract / 29 integration 全绿。
|
2026-09-10 22:29:23 +08:00 |
|
|
lzf_0626
|
d2aff7c129
|
feat: 建客服知识库（Milvus 三集合）并修复模型端点筛选缺陷
一、知识库建设
- 新增 tools/build_knowledge_chunks.py：把 knowledge/ 下文档切成可检索知识块。
采用「叶子标题」策略（其后没有更深标题的标题即切分点），同时覆盖三种真实结构：
带子条款的按子条款切、无子条款的条款单独成块、无小节的章整章成块。
第一版按固定标题级别切是失败的——适当性指南的条款是 ### 而没有 ####，产品手册的
### 1.1 又不匹配「第X条」，两条规则互相打架，导致 4 个文件一块都没切出来。
- 新增 tools/load_knowledge_milvus.py：向量化并写入 Milvus，用 upsert 保证幂等。
schema 按方案 §4.2 统一字段，另加 chapter/section/source_file/doc_no/visibility 五个
检索与合规必需字段；索引 IVF_FLAT + COSINE + nlist=128；向量输入取「标题+正文」，
标题含条款号与章节名，是比正文更干净的检索信号。
- 知识内容按业务范围裁剪：反洗钱合规操作手册不入客服知识库（业务只做公募基金、
不涉及资金划付，且该手册标注内部机密、禁止向客户透露可疑交易信息），留给后续风控；
高净值客户服务规范只保留「客户分层标准」与「各层级专属权益」两章，
家族信托、资产配置流程、客户经理考核、隐私应急预案等内部管理章节不入库。
- 入库现状：fin_faq_collection 61 块、fin_product_collection 26 块、
fin_policy_collection 73 块，合计 160 块。检索自检 5/6——未命中的一条分数 0.660
落在中置信区间，按三档兜底策略本应提示信息可能不完整，属于预期行为。
二、embedding 端点
- 新增 tools/configure_embedding_endpoint.py：走管理 API（draft→approved→active）
配置并激活 qwen-embedding 端点，而不是直接写库。理由是状态机与审计都要留痕，
且 DatabaseModelGateway 只认 status='active'，手工写错状态会报成与病因无关的
「模型端点未注册或未激活」。脚本先查 endpoint_code 是否已存在，幂等可重跑。
三、修复模型端点筛选缺陷（app/service/model_gateway.py）
- 原 DatabaseModelEndpointResolver 忽略 agent_type 与 task_type、直接返回全部 active
端点，而 ModelDispatchService 只按顺序尝试前 max_attempts（默认 2）个。两者叠加使
「能否选到支持该任务的端点」取决于端点表顺序：实测每次 embedding 都先拿文本生成
端点失败一次再落到向量端点（0.61s，修复后 0.42s）。
- 新增 TASK_CAPABILITY 显式映射后按能力筛选。用映射而不是同名筛选是必需的：
memory_extraction 并不是任何端点的能力名（deepseek 声明的是 text_generation 等），
按同名筛会得到空集、把记忆抽取打成失败关闭——这是本次修复最容易引入的回归。
- 保守兜底：未映射的 task_type、以及没有任何端点声明该能力时，都退回全部端点，
让配置缺口表现为调用失败，而不是让上层收到「解析为空」这种与病因无关的报错。
- 验证结果：embedding→[qwen-embedding]、intent_classification→[deepseek-flash]、
memory_extraction→[deepseek-flash]、未映射 task_type→全部；ruff 通过、
mypy 103 文件无错、unit+contract 447 passed。
四、需求文档提取物
- 新增 _flows/：三份流程文档（智能客服 Agent 专项设计方案、投资顾问流程、基金运营流程）
的纯文本提取，供开发期对照。原始 .docx/.html 保留在业务方目录侧。
说明：本次仅本地提交，未推送远程仓库。knowledge/ 内含公司内部制度与产品资料，
是否入远程库待确认。
|
2026-09-10 20:15:09 +08:00 |
|