 张胜宇
|
94ce44a851
|
feat(W24): docs/43 场内基金手册入库 + B-02 展示候选集收口
补历史欠账：D3.4 B-02（决 12）与 D4.1 §B-02 早已承诺把 docs/43 纳入 SOURCES，
从未执行；W21 首次把它暴露成实测缺口（702 块里「科创债」0 处）。
语料与切片
- docs/43-场内基金产品手册（知识库入库版）.md 纳入 SOURCES：20 只场内基金
（13 ETF + 7 LOF），fin_product_collection / public / prefix=ETF；切片件 702 -> 755 块
- 新增三个「按源开启」的切片开关（默认关，其它 8 个源零字节变化）：
strip_editorial_marks / qualify_table_rows / exclude_sections
- 费率表表头补单位（%/年）；docs/43 与 knowledge 镜像逐字一致
- docs/45 裁定不入库（与 FAQ-0018 / POL-AST-011/012 重复，会抢 top1）
修复两个真实缺陷
- W24-A 切片器行标签取错列：多列表格第 0 列是代码（159700[:2]='15'），
上游 _prefer_section 判不出重合 => 每一问都被换成整节块
（实测「科创债ETF南方怎么样」返回 20 只产品的整张表）；改取表头「名称」列
- W24-B text-embedding-v3 单请求上限 10 条：load_knowledge_milvus.embed()
只在灌库路径分批，自检路径超 10 条即在数据写完后崩；分批下沉进 embed()
- B-02 的 M-4 回归：_exit_partial 两条调用路径候选集不同（主路径 TopK 全量 vs
证据路径被 E4_MAX_EVIDENCE 截断）=> 同一句问句的答复质量取决于 E4 有没有
调用模型；_answer_from_evidence 新增 display_hits，展示候选一律用 TopK 全量，
送模型的证据包保持 6 块不变
产品名识别
- _PRODUCT_NAME_SHAPE 后缀集补 定期开放混合 / 股票(LOF)A / (LOF) / 原油A
- 新增 _BRANDLESS_PRODUCT_NAMES（沪深300ETF，唯一无厂商字样的产品，只能枚举）
- _strip_product_name_lead 增「先切掉前一只基金」
验收
- 金标 46 条 M-1 46/46、M-4 46/46、M-6 5/46、M-7/8/9/10 = 0、
M-2 28/31、M-2b 15/18、M-3 4/4（与 w23 基线逐项一致）
- 两次独立复跑 result_w24d / result_w24e 指标完全相同
- Milvus 自检 15/15；全量回归 1996 passed / 3 skipped；ruff 零新增
- 真 HTTP 11 条全绿
判据变更（必须知情，不适用「零回归」表述）
- B-01（访客）expected_evidence 补 ETF
- B-05（客户，同一句问句）expected_exits [E3] -> [E3, E4]
- load_knowledge_milvus 自检 BAS-CON-006 -> ETF-005
文档
- 客服agent/D2.1 升 v6.39；D2.4 升 v1.8（语料 755 块、手册切片实测 53）；
D2.8 新增 §3.6 与 §11 复测；D2.9 升 v1.3
- 开发文档/D1.1 升 v1.15（新增 §31）；D1.6 升 v1.2（新增 §11、§10.4 销账）；
D4.8 升 v1.2（新增 §10）
诚实留痕
- _exit_partial 仍按分数挑块（不接收问句），本轮只统一候选集口径
- E5b 展示层净化仍不覆盖「收益 + 数字%」形态，继续挂账
- 语料里 2 个零容忍地雷块（POL-SPM-016 / POL-SPM-022-01）是禁令条款，故意保留
|
2026-09-21 12:26:42 +08:00 |
|
|
张胜宇
|
5d0becb67d
|
客服 Agent 重构收口：五出口决策链 + 知识库档位隔离 + 前端入参边界（答辩演示版本）
一、客服 Agent 智能增强（正面回应"不智能、动不动就转人工"）
- 决策链由 2 个出口扩到 5 个：E1 澄清 / E2 计算型 / E3 知识直返 / E4 证据约束生成 / E5 分级回退
- 转人工从"默认动作"降为最后一档 E5c，只保留 4 类白名单：
P0 反诈 / P1 账户与个人数据 / P2 写操作与争议 / 用户明确要求人工
- 46 条金标实测（修复前 → 修复后）：
转人工率 43.5% → 10.9%；出口准确率 45.7% → 100%；事实正确率 69.6% → 100%
禁忌违反 1 → 0；档位越权 / 无出处数字 / 误拒 四项零容忍全 0
- 安全不变量 INV-1~INV-5；零容忍规则未删，改的是挂载点
（输出侧字面黑名单 → 检索层档位隔离 + 判定层合规词表 + 输出守护）
二、知识库：档位单点化与物理隔离
- 新增 app/core/knowledge_tier.py 作为档位规则唯一落点（G-03），
knowledge_contracts.py 原定义块改为显式再导出（X as X，非副本）
- 档位过滤由 bool 默认值（fail-open）改为 tiers 必填集合（缺参即 TypeError）
- Milvus 侧四集合按 visibility 分区键物理隔离；双 schema 收敛为一套
- 新增 app/core/actor.py：访客三元组与匿名判定的唯一构造/判定点（G-01/G-01b）
- 新增 app/core/fund_fee_rules.py：费率计算纯函数
三、前端入参边界对齐（本轮 W11 新修，4 处"校验宽于存储"）
- message 加 max_length=8000（与浮窗 widget.js 的 maxlength 一致）
- session_id 加 1—64；idempotency_key 上限 128 → 64（对齐列宽 String(64)）
- feedback_type 加 max_length=32（对齐列宽 String(32)）
- 8 条路径参数补 min_length=1 + max_length=64 + 字符集正则
（{session_id} / {run_id} / {handover_id}）
- 改前超限值会落到 MySQL 才失败（500）；改后一律 422 AGENT_INPUT_INVALID + 字段级定位
- 新增 tests/unit/api/test_frontend_boundaries.py（33 例），含"端点表 ↔ OpenAPI 全量对照"
四、投顾模块整体清除（D4.4 / D4.5）
- 删除投顾相关 controller / schema / model / repository / service 及门户页面
- tools/portal_api_check.py 同步作废 AD003/AD005/AD011/A047 四条用例与 advisor_t 登录
（端点与账号均已不存在，此前稳定报 3 条假红）
五、验证（提交前实测）
- pytest -q：1856 passed / 2 skipped / 0 failed
- ruff check app tools tests：19（= 基线）；mypy app：2（= 基线）
- 前端接口契约体检 portal_api_check.py：38 项，通过 34，失败 0，跳过 4
- 全链路冒烟 e2e_smoke_test.py --read-only：31/31
- HTTP 全链路探针 http_probe.py：11/11 succeeded
- 跨文档一致性 _consistency.py：GATE PASS
- 真机边界复验 12 条：12/12 符合预期
六、纪律与文档
- 可改文件白名单 A-09（docs/46）与底座会签申请单 A-10（docs/47，组 1—组 4 全部受理）
- 零 DDL：未新增/修改任何表结构，89 张业务表与基线一致
- 证据留痕：docs/evidence/**（含 46 条金标 score、快照、清除与重建记录）
- 未提交（刻意排除，见提交说明）：仓库内 客服agent/ 与 开发文档/ 是 2026-09-16 前的
过期副本（Todolist 440 行 vs 权威 D2.1 1167 行），权威正本在仓库外；
_chunks_report.txt 是 tools/build_knowledge_chunks.py 生成的本地产物
|
2026-09-20 14:33:30 +08:00 |
|
 lzf_0626
|
7b3a72860c
|
feat(knowledge): 为 C1-C5 各补一条「能买什么产品」的问答
客户实测反馈：「C1 客户能买什么」被引导到人工客服，而知识库里其实有答案。
实测分数：这条问句 top1 只有 0.5633、与次优差 0.0236（低于 0.07 门槛）→ 转人工；
而「C1 保守型客户可以买哪些风险等级的产品」是 0.7794，过了 0.75 硬门槛、能答。
根因是客户与知识库的用词鸿沟：客户说「C1 客户」，知识块标题写的是「C1 保守型」。
短问法少了"保守型"这个锚点就差 0.19 分——而客户不知道 C1 就等于保守型，这正是他要问的。
按 A 方案（数据问题用数据解决）为 C1-C5 各补一条 FAQ，答案全部取自
《个人投资者适当性管理指南》原文，不自行编写：
- 第十二条投资者与产品匹配矩阵（各级别可购买的产品风险等级）
- 第十四条硬匹配规则的跨级禁止要求
- 第十五条豁免规则（C3 买 R4、C4 买 R5 的签署揭示书与持仓上限）
知识块 631 → 636。同时修正 load 脚本自检里过时的期望：这句话现在命中 FAQ 而非
POL-AST（两者是同一份内容，只是 FAQ 的问句措辞更接近客户口语）。
验证：C1-C5 六个等级的「能买什么」问法全部直接回答、无一转人工；
ruff / mypy / 468 unit+contract 全绿。
|
2026-09-10 22:34:20 +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 |
|