台账风险聚类
需要使用者提供
| 输入 | 说明 |
|---|---|
| 记录文件 | xlsx／csv／jsonl。每条记录需要一个编号，以及若干文本列（人审问题描述、问题类型、对话摘要等） |
| 列名 | 编号列、文本列、风险等级列（可选，用于过滤「无风险」行） |
| 业务背景 | 一句话说明 Agent 能做什么（有哪些工具和流程），供判断风险落在哪个环节 |
先用 scripts/prepare_records.py 把记录统一成 jsonl（id 加 text），并去掉测试会话、无风险行和重复会话：
python scripts/prepare_records.py 台账.xlsx --sheet 审核记录 --id-col 会话ID \
--text-cols 问题描述,问题类型 --level-col 风险等级 --drop-levels 无风险 --out records.jsonl
聚类流程
- 逐条抽风险事实：用一句话写清「谁（用户、Agent、系统）在哪一步做错了什么、后果是什么」。原文信息不足的，标「信息不足」，不要猜。
- 按风险形态聚类，而不是按产品或话题。 每个簇名要能直接搬到另一个行业：
- 好的簇名：「声称已办理但未执行」「转人工诉求未兑现」「编造不存在的功能」。
- 不合格的簇名：「翻译机问题」「录音笔绑定」。
- 检验方法：能写出该形态在银行、政务里的对应说法，才算合格。 - 允许多标签：一条记录同时有两种形态时，两个簇都计入。汇总时注明「多标签，簇条数之和大于记录数」。
- 审核系统自身的问题单列：审核侧只收三类，不是 Agent 的风险形态，单列为「审核侧问题」，不进入风险清单：
- 安审误拦：审核把正常内容拦了。
- 安审漏检：审核放过了违规内容。
- 标注剔除：测试会话、无效记录、重复记录。
以下几类不属于审核侧，必须作为风险形态进入清单：
- 系统对接故障：Agent 平台与外部系统（呼叫中心、工单、CRM）之间状态不一致、会话日志对不上、转接状态丢失。
- 链路或渲染故障：Agent 没有回复用户末轮提问、回复为空或乱码、卡片没弹出、消息没送达。
这两类风险即使只体现为「取证时日志对不上」，用户侧也可能已经受影响（例如转人工没接通、问题没人答），所以按风险计入，并在定义中注明「后果待现网取证」。
5. 小簇处理：1 条的簇如果与已有簇是同一形态，就合并；不能合并的列入「长尾」，保留原话，不丢弃。
6. 逐簇定档：按 risk-source-classify 的六问流程判定 A～F 档，并写明链路环节（输入、路由、检索、委派、工具、输出、卡片、转人工）。系统和链路类故障按下表定档：
| 情形 | 判据档 | 理由 |
|---|---|---|
| Agent 未回复末轮、回复为空或乱码、卡片未弹出、消息未送达 | F | 没有文本可判，问题出在通道或链路，只能事后归因 |
| 平台与外部系统状态不一致、日志对不上、转接状态在两系统间丢失 | F | 判据在系统对接层，不在本会话文本或 Agent 的工具轨迹里 |
| Agent 声称已转人工、已建单，但轨迹显示没有调用对应工具或调用失败 | E | 判据是 Agent 自己的执行轨迹 |
| 用户多次要求转人工，Agent 未执行转接动作 | E | 判据是转人工计数和工具调用 |
区分 E 与 F 的关键：错在 Agent 自己做没做（看它的 trace）→ E；错在 Agent 之外的通道或系统 → F。
7. 用脚本计数：把逐条归簇结果写成 assign.jsonl（每行 {"id":…, "clusters":[簇名…]}），簇定义写成 clusters.json（{簇名: {"grade":…, "scene":…, "link":…, "definition":…}}），然后运行：
python scripts/tabulate.py assign.jsonl clusters.json > 风险清单.md
脚本只负责计数，不改动归簇结果。它输出：每簇条数（带分母）、六档汇总，以及「业务场景 × 判据档」矩阵。
输出
| 簇（风险形态） | 定义 | 真实条数 | 代表原话（2 条） | 业务场景 | 判据档 | 链路环节 | 能否泛化（他行业对应形态） |
|---|---|---|---|---|---|---|---|
另附：
- 审核侧问题清单（误拦和漏检的条数）
- 长尾清单
- 信息不足的记录数
写作约束
- 条数只计台账里真实存在的记录，不得加入构造或推测的条数。分母写「有效风险记录 N 条」。
- 一个簇的定义说不清能否泛化的，标「不可泛化」，不要硬套。
- 人审标注的类型只作参考：类型与原文矛盾时以原文为准，并在簇定义中注明。
