 lzf_0626
|
a6c09fa3c4
|
fix(customer-service): 检索问句只在客户这一句说不清楚时才带上文
实测的答非所问：同一会话先问「季季盈90天的起投金额是多少」，再问「基金赎回几天到账」，
第二问答出的是季季盈的产品介绍。原因是 _search_query 无条件把上一轮客户问题拼进检索词，
客户换话题时旧话题的检索结果被带了回来。在金融场景里这比"引导转人工"糟得多：客户问 A
得到 B 的答案会直接失去对客服的信任，而"答不了"至少是诚实的。
改为只在两种真正需要上文的情况下拼接：句子里有明确指代词（"这个产品""该基金"），
或短到不构成完整意图（"那它风险高吗"只有 6 个字）。指代词刻意不收单字"它/他"——中文里
"其他产品"会被误判，而这类短句已经由长度规则覆盖。
验证：换话题场景第二问回到 FAQ-0016 的到账时间，指代追问仍命中季季盈产品块；
ruff / mypy(113 文件) / 457 unit+contract 全绿。
|
2026-09-10 22:17:34 +08:00 |
|
|
lzf_0626
|
dbe7285c1c
|
feat: 短期会话记忆（多轮指代可解析）
一、此前的缺口
方案 §2.2 要求会话短期记忆，但底座**没有任何加载历史消息的代码**：conversation_message
存了全部消息、svc_conversation_session 只在计数，而 run 执行时只拿到当前这一条消息。
后果是客户问"那它风险高吗"时"它"无从对应，向量检索落到无关内容、整条回答走兜底——
多轮对话事实上不可用。
二、实现
1. 契约：AgentRequest 新增 `history: tuple[ConversationTurn, ...] = ()`（默认空元组，
既有构造点无需改动）。ConversationTurn 只保留 role 与正文，不把意图/置信度等内部字段
喂给模型——既减少噪声，也收窄"模型看到不该看的东西"的面。
2. 加载：WorkerRuntime._execute_claimed 构造 AgentRequest 时加载本会话此前的对话
（上限 10 轮，按 id 正序）。`before_message_id` 排除本轮请求消息本身，否则模型会在
上下文里看到自己的问题被重复一遍。
3. 使用：客服 Agent 构造检索查询时，把最近两轮**客户**消息与当前问题拼接。只取客户的
话、不取 Agent 自己的回答——把后者拼进来会让检索偏向自己上一轮的说法，而客户的真实
意图可能已经在下一句里被修正。
三、两个刻意的取舍
· **不引入 Redis 双写**：方案 §2.2 设想用 Redis 列表，但消息在受理时已落库，再同步一份
只会带来不一致与 TTL 管理成本，换来的仅是一次索引查询的节省。这里取等价语义
（同样"最近若干轮、超出即截断"）而不复制存储。
· **按条数截断而非 token**：没有与模型一致的分词器，按 token 截断只能估算、边界会随实现
漂移；按条数是确定性的，宁可少给几轮，也不给一个不稳定的边界。
四、实测（同一会话两轮）
· 第 1 轮"南方季季盈90天的起投金额是多少" → 正确返回该产品表格（R2、起投 1 万元等）；
· 第 2 轮只说"那它风险高吗"（不含任何产品名）→ 仍正确检索到同一产品并答出风险等级 R2、
业绩比较基准与投资范围；此前这类提问必然走兜底；
· ruff 通过、mypy 113 文件无错、unit+contract 447 passed。
|
2026-09-10 22:01:43 +08:00 |
|
|
lzf_0626
|
1fa5fc7d03
|
refactor: 客服回答正文只保留固定免责声明
业务方要求客户侧只看到一句固定话术（不构成投资建议），因此从回答正文移除：
1. 中置信的「（以上信息可能不完整，具体以产品说明书与公司制度为准）」提示；
2. 「（依据：…）」出处行——原先它显示的是知识块标题，FAQ 的标题就是问题本身，
展示为「（依据：公司什么时候成立的?）」并没有可读价值。
可追溯性不受影响：本次命中哪个知识块仍由审计（agent.tool_executed 的工具调用记录）
与消息表留痕，source_references（tool 类型）也照常返回，只是不再面向客户展示。
取舍已在代码注释中标明：中置信回答此后不再向客户标注不确定性。
若将来要把出处展示给客户，应当走 source_references 的 knowledge 类型
（前提是让 ToolExecutor 把工具返回的 doc_id 登记为本次可引用来源），
而不是继续往正文里拼字符串。
同时移除因此不再使用的 INCOMPLETE_NOTICE 常量、_source_note 方法，
以及提问工具里那句"正文没有依据行"的提示。
验证：ruff 通过、mypy 107 文件无错；customer_service_check 9/9 通过；
ask_customer_service 实测回答正文为「答案 + 免责声明」两行。
|
2026-09-10 20:33:13 +08:00 |
|
|
lzf_0626
|
66595ce080
|
fix: 客服置信判定改为「绝对阈值 + 相对间隙」混合判定
问题（业务方实测发现）：问「我们公司叫什么名字」被引导人工，但公司名称就在知识库里
——FAQ-0001「公司全称是什么?」与 COMP-001 都稳定命中 top1。所以根因不是检索不准，
而是判定规则不完整：客服方案 §2.3 要求的是「绝对阈值 AND（相对间隙 OR 分布优势）」，
实现里只做了绝对阈值 0.60。
实测校准（qwen3.7-text-embedding-flash，COSINE）：
库内问法 top1 top1-top2
我们公司叫什么名字 0.592 0.100
你们公司名称是什么 0.579 0.090
公司全称是什么 0.671 0.098
你们公司总部在哪 0.764 0.245
南方科技的全称 0.855 —
库外 / 越界 top1 top1-top2
你们公司什么时候上市 0.500 0.046
推荐明天肯定涨的基金 0.488 0.023
我要投诉 0.492 0.025
今天天气怎么样 0.416 0.035
量子计算机退相干 0.416 0.044
两条结论：一是同为正确命中，口语问法的相似度天然偏低（0.592 vs 0.855），单用绝对阈值
必然误判；二是库内命中的 top1 领先幅度（≥0.09）显著大于库外（≤0.046），间隙是有效判别信号。
新规则：≥0.75 直接答（不再要求间隙）；≥0.55 且间隙 ≥0.07 则回答并附「信息可能不完整」
提示；其余一律引导客户致电人工客服。两侧余量：库内最低 0.579、库外最高 0.500。
验证：ruff 通过、mypy 107 文件无错；ask_customer_service 对「我们公司叫什么名字」
正确返回南方科技有限公司；customer_service_check 由 8 项扩为 9 项，全部通过，
其中「推荐明天肯定涨的基金 / 我要投诉 / 量子计算机退相干」三条必须引导人工的用例
未被放宽后的阈值误答。
|
2026-09-10 20:29:12 +08:00 |
|
|
lzf_0626
|
13bab7c3d0
|
feat: 客服 Agent 端到端跑通（知识直返 + 答不了引导人工客服）
按业务方确定的取向实现：金融场景确定性优先，能溯源到公司资料的才答，答不了就
引导客户拨打客服热线，绝不用模型猜答案。端到端验收 8/8 通过。
新增：
- app/service/knowledge_search_service.py：知识检索。未复用记忆的 VectorMemoryAdapter
是因为它只返回 (memory_uuid, score)，会丢掉知识块的标题与正文，而客服回答必须能把
原文与出处一起交付。检索失败一律返回 degraded 而不抛异常，由 Agent 走兜底。
- app/service/knowledge_tool.py + app/core/knowledge_contracts.py：只读工具 search_knowledge。
走 ToolExecutor 而不是让 Agent 直接持有检索服务，是为了让白名单、权限、审计、超时
都归基座统一管理；工具只读也符合 ToolRegistry 的硬约束。复用既有权限码
knowledge:reference:read（customer 角色已具备），不新增权限点。
- app/service/agent/implementations/customer_service.py：Agent 本体，刻意保持薄——
意图分发 + 四条出口（faq/产品/政策直返、闲聊走模型、其余与异常引导人工）。
直接返回知识原文而不经模型改写，答案的字面内容全部来自公司已发布资料。
- tools/publish_customer_service_config.py：发布意图工具白名单。
- tools/customer_service_check.py：端到端验收（8 个用例，含越界请求与知识库外问题）。
装配：
- bootstrap 新增 get_knowledge_search_service 工厂，注册 search_knowledge 工具与
customer_service Agent。
- runtime_config_service 新增 load_active_prompt：提示词绑定 release_id，按当前生效
版本读取，未发布时回落代码默认值。闲聊话术因此可审核、可回滚，不必改代码发版。
过程中发现并处理的三个问题：
1. 自造 source_references 被基座合规闸门拒绝。governance.review_output 只接受
「本次召回的记忆」与「本次成功调用的工具」两类引用（用于防止伪造来源），
knowledge 类型会被判非法并使整个 run 失败。处理方式是**不放开那道校验**，
而把知识出处（文件标题与内部编号）写进正文，source_references 交给基座自动附加。
2. 发布配置是整版本替换语义：新版本会清空旧版本的全部配置项。若只发客服白名单，
示例 Agent 的 fund_query_demo:fund_quote 会被静默清空。故发布脚本先读取当前生效
版本的全部配置项并原样继承，再追加新增项。
3. 验收脚本自身两处自伤：打印 emoji 触发 GBK UnicodeEncodeError、以及读错结果字段
（RunQueryService 返回的答案键是 content 不是 text）。
已知缺口（未修，已记录）：
- CoreResult.transfer_required 未持久化：conversation_message 不存该标记，
API 读不到"本次是否引导了人工"。当前靠正文里的固定话术判断。
- 知识块引用（source_type=knowledge）尚未启用，需先让 ToolExecutor 把工具返回的
doc_id 登记为本次可引用来源。
验证：ruff 通过、mypy 107 文件无错、unit+contract 447 passed；
tools/customer_service_check.py 8/8 通过（含越界请求、投诉、知识库外问题三类
必须引导人工的场景，以及 7 个零容忍负面词零命中）。
|
2026-09-10 20:22:42 +08:00 |
|