关掉大模型，我的AI助手反而给出了正确答案

客服业务主管抛出了一个常见问题：上个月导致负面情绪的核心问题是什么？

最省事的架构设计，莫过于将所有对话记录统统塞给大语言模型（LLM），然后直接输出结果。这种回答读起来通常行文流畅、无懈可击。但它很可能是错的——直到某天汇报 PPT 里的虚假数据被领导当场戳穿，团队才会意识到问题严重性。

上线过足够多数据产品的人都会达成一个共识：看板里给出一个错误数字，比根本没有看板更危险，因为业务人员会据此做出真实决策。

因此，我构建了一个完全反向运作的系统。

这套面向客服对话的智能分析助手基于 LangGraph 编排分析流程，在包含 4.1 万条消息的 3000 场对话上执行预注册的 DuckDB 分析查询，召回支撑结论的真实对话切片，做出解释，并在呈现前对自身答案进行严苛审计。

大模型在整套链路中完全是可选的。产品核心的四个业务问题，实现了 0 次模型调用，在普通笔记本 CPU 上的中位数响应时间仅为 125 毫秒。

• 4 / 4 个核心业务问题均能零模型调用输出，并能通过独立校验脚本重新计算
• 针对 73 个保留测试问题，意图分流准确率达 95.9%
• 确定性路径下响应中位数 125 毫秒（P95 为 540 毫秒）
• 运行成本 0 美元，包含本地离线模型

一条立下所有取舍的铁律

在敲下第一行代码前，我立下了一条原则，由它来决定后续所有的工程妥协：

数字必须由程序计算得出，绝不可由模型生成。

写下这条规则，是因为我知道自己之后一定会动摇。很多时候模型“差不多能数对”，直接让它生成往往能省下大量联调规则的精力。

• 每一项数据都源自确定性计算。 所有的总数、比率和排序，全部来自 15 个预先注册、参数化的 DuckDB 算子。
• 大模型永远不能自己写 SQL。
• 严查文字解释。 如果大模型生成的归因解释中包含任何未经数据层验证的数字，整段解释直接作废，系统自动回退至确定性模板。

立下铁律后，核心问题变成了：如果大模型连基础事实都不能提供，那到底什么时候才值得调用它？ 我在这个问题上耗费的时间，超过了任何单个具体功能。

架构概览

• 流程编排： LangGraph，基于 SQLite 维护状态检查点。
• 数据分析： DuckDB、pandas 与 SciPy。纯确定性计算，内置威尔逊置信区间（Wilson intervals）与卡方检验（χ² tests）。
• 检索层： FAISS，结合 MiniLM 句向量与 LSA 潜在语义分析，通过倒数排名融合（RRF）混合排序。
• 记忆与遥测： SQLite 嵌入式存储。
• API 与界面： FastAPI（支持 SSE 流式传输）+ React 18 / TypeScript / Recharts / React Flow。
• 可选本地模型： Qwen2.5-1.5B-Instruct，基于 llama.cpp 在 CPU 上纯离线运行，无需任何 API Key。

整个工作流分为四个阶段，系统界面的“决策回放”（Decision Replay）面板允许逐节点回溯：

架构中有三项核心选型至关重要：

1. 主控 Agent 只负责规划，不负责计算。 它解析时间窗口和历史对话指引，选择注册算子。数据分析层拒绝接收任何非结构化计算请求。
2. 检索只用于印证佐证，并行运行。 混合检索负责找出排名前列指标背后的真实对话原文，绝不从检索内容中汇总任何数字。
3. 结果验证是必经流水线，不是事后修饰。 质检 Agent 与“证据挑战器”（Evidence Challenger）对每一次输出做强制合规校验。

零 LLM 参与的置信度路由分流

在触发模型前，一套低成本、高精度的级联检查机制会先行判断问题类型：

• 事实类问题直接拦截。 规则识别到意图后，直接调度 DuckDB 完成全量计算，此时引入模型只会凭空增加延迟和调用账单。
• 模型仅在两种情况下介入： 规则置信度不足时，或者用户明确要求主观归因推理（“为什么”、“如何改善”、“给出建议”）。即便介入，模型也只能在封闭枚举中选择分类，或基于已算出的固定指标组织语言。
• 数据边界与政策检查拥有绝对优先级。 凡是涉及未采集维度（如营收变动、客单价、客服坐席处理时长），或要求系统直接给出人事解聘建议的，全部由确定性逻辑直接驳回，不需要耗费 Token 来“礼貌拒绝”。

部分典型问题的分流策略：

• “上个月导致负面情绪的前 5 大问题？” → 仅走分析层，0 次模型调用。
• “为什么重复扣费引发的负向情绪这么严重？” → 混合模式：DuckDB 算清数据分布，模型生成文字推演，消耗 1 次模型调用。
• “优惠券故障让我们损失了多少 GMV？” → 直接拦截拒答，因数据集无金额字段，0 次模型调用。
• “有什么值得关注的异常吗？” → 反问引导，要求提供具体范围，0 次模型调用。

核心问题推演

回到最开始的问题：上个月导致负面情绪的前 5 大原因是什么？

“上个月”本身就是个常见的时区陷阱。测试数据集跨越 2025 年 8 月至 12 月初，因此“上个月”必须动态锚定为数据集覆盖的最近完整自然月（11月），而非当前系统日历时间。

2025 年 11 月，682 场对话中有 240 场 被划分为负向情绪。

1. 常规咨询求助： 49 / 156 (31.4%)
2. 重复扣费： 42 / 87 (48.3%)
3. 已扣款但权益未到账： 30 / 75 (40.0%)
4. 功能故障无法使用： 28 / 76 (36.8%)
5. 登录失败 / 账号被锁： 24 / 58 (41.4%)，与“优惠券核销失败”（24 / 84）并列

• 按绝对量看，常规求助最高，其总基数是其他分类的两倍。
• 按负向转化率看，重复扣费排在首位。
• 差异在统计学上并不显著。 各类别的置信区间高度重叠，全量卡方检验得出的 p 值为 0.07。

一个合格的数据分析师在出具汇报时会把这些统计学限制交代得一清二楚。现在的 Copilot 同样会主动讲明这些盲区。

踩坑实录与工程迭代

这些意外挑战并没写在初始需求文档里，却占用了绝大部分开发精力。

1. 浮点数计算导致的 -0.25 假象

业务定义：当客户发言的平均情绪分值 ≤ -0.25 时，判定为负向对话。对话 C0010797 包含 8 轮客户发言：
-0.6, -0.6, -0.6, -0.6, +0.8, -0.6, +0.8, -0.6

纸面算术上，平均值恰好是 -0.25。但在计算机浮点数累加时：

let sum = 0;  
for (const s of [-0.6, -0.6, -0.6, -0.6, 0.8, -0.6, 0.8, -0.6]) sum += s;  
sum / 8; // 结果为 -0.24999999999999994  
sum / 8 <= -0.25; // 返回 false：被错误标记为“非负向”

我在手工做校验对比时发现了一个 0.5 的分值偏差。修复方案是比较前统一做 9 位精度四舍五入。这个改动立刻让业务优先级分值从 52.9 变动至 53.4，11 月的负向会话总数从 239 纠正回 240。

更讽刺的是，我最初写的校验脚本也是用浮点数算的，因而完全复现了同一个 Bug。两个共享了底层假设的校验器，本质上是一个校验器。 最终真相验证器改用了分数精准运算。

2. 时间戳与对话顺序脱节

在现成的 3000 场对话数据里，消息的时间戳字段与真实的交谈先后顺序完全对不上。按时间戳排序会得到“先发感谢再做提问”的荒谬对话。最终系统确立以 Turn Index（轮次递增序号）为唯一绝对依据，并明确向使用者披露时间戳失真。

3. 客服样本不足时的归因陷阱

第二个问题是识别“哪些客服人员需要接受业务辅导培训”。但整个数据集包含 3000 场对话，却有多达 2987 个不同的客服工号，平均每个客服只有 1 到 2 场会话记录。

基于一两通对话就对一线员工的业务水平盖棺定论，在管理上是不负责任的。 系统选择拒绝直接输出坐席淘汰排名，而是提供更有建设性的聚合大盘：

• 大盘质检暴露的共性缺陷： 仅有 29.3% 的客户负向情绪发言获得了客服的正面安抚，57.3% 的质检收尾动作与客户核心诉求不符。
• 输出重点待复核会话队列供质检员人工研判。
• 强制给所有管理建议打上“需人工介入复核”标签。

4. 4.1 万条消息背后的模板压缩

原始数据是一套合成对话集，每条消息末尾附带了混淆字符。在剥离这些干扰字符后，全量 41,965 条记录其实是由 426 种 固定文本模板排列组合而成的。

与其花大笔 Token 让大模型给四万多条消息分别打标，我直接用确定性规则对这 426 个模板进行了清晰的手工映射。同时在前端暴露标注纠偏入口，并明确提示该判定规则尚未经受大规模双盲测试。

5. API Key 被封禁反向倒逼架构轻量化

开发中途，云端商业模型的 Key 突然提示 401 API_KEY_SERVICE_BLOCKED。这反而成为了整个项目最好的架构催化剂——它逼我思考：这套系统到底哪一步是非要 LLM 不可的？

我彻底把模型做成了可选插拔组件，引入约 1.1GB 体积的开源小模型 Qwen2.5-1.5B-Instruct，借助 llama.cpp 直接在本地 CPU 上运行。常驻预热状态下处理一次简单意图识别仅需 1 秒左右，彻底摆脱对外网 API 的依赖。

6. 小模型在意图分类上的调优极限

最初我让 1.5B 参数小模型执行意图归类，在固定的保留验证集上准确率仅有惨淡的 19.2%。通过将 Prompt 改写为基于闭合枚举集合，并挂载 JSON Schema 强约束语法树后，准确率拉升至 58.9%。

但在小模型上死磕 Prompt 收益极低。最终的破局点是让模型退出主干流程，改用级联置信度机制：

• 本地 Qwen 初始 Prompt：19.2%
• 约束 Schema 后的 Prompt：58.9%
• 先行执行硬编码规则过滤：61.6%
• 纯规则与置信度级联（不调用任何模型）：90.4%
• 置信度级联 + 本地小模型补位：95.9%

小模型最终只承担了 6.9% 的边缘长尾意图解析。其余超过九成的问题，纯代码规则跑得又快又准。

7. 证据挑战器：审查大模型的生成妄想

“证据挑战器”作为一个对抗性节点，在每次生成解释文本后强行介入：

• 逐字核对引用的对话原句是否存在于底层数据库；
• 强制暴露少于 30 个样本的极低统计量；
• 主动提供反事实证据（如“在未收到货品的用户投诉中，有 61% 的会话全流程并没有产生负向情绪”）；
• 强行将因果关联话术降级改写为统计相关性。

在我人工为报表编写的注释中，曾顺手写过某类目排名垫底是“因为平局决胜规则”。挑战器直接将“因为”（because of）暴力替换成“与…相关”（associated with），让句子变得生硬。但这证明它切实发挥了作用——在数据分析里，不能把主观因果推断当作事实交付。

8. 演示测试数据的污染问题

在做前端可视化联调时，我注入了 120 场带特殊标签的测试对话。结果它们被默认加载到了分析集中，导致原本 3000 场的全量数据变成了 3120 场。将测试数据改为手动显式加载后，底层倒排词典发生了变动，直接影响了召回率指标。在报告中必须如实呈现变动后的指标波动，而不是为了数据好看强行保留旧指标。

9. 面对检索收益保持诚实

系统对 18,639 个文本分块同时建立了 MiniLM 语义向量与 LSA 关键词索引，并通过倒数排名融合（RRF）进行加权合并。

从测试表现看，混合检索确实优于纯向量或纯文本匹配，但收益幅度并不夸张。向业务方坦承“混合检索仅带来了微弱但可靠的边际收益”，远比用挑选过的数据吹嘘大幅提升更有价值。

10. 不讲假话的 Token 统计

所有返回的答案都会在界面右上角标出路由决策流、命中的意图类型以及实际 Token 消耗：

• 纯代码计算路径统一标识为“0 Token（未调用模型）”；
• 本地或流式供应商未返回 usage 字段时，界面标明“未提供”，严禁伪造展示为 0；
• 流式传输时的 Token 计数取整个生命周期的最大累计值，修复之前按 Chunk 粗暴累加导致的翻倍虚高。

系统不做的事

评估一个分析型系统时，同样要看它拒绝做什么：

• 不直接推导因果关系。 根因分析模块只输出伴随区间检验的相关性结论，明确区分“伴生表象”与“候选诱因”。
• 不凭单薄数据给人定性排序。
• 不过度承诺泛化能力。 95.9% 的分流准确率是在特定 73 道基准题目上取得的，未经过多轮大规模盲测。
• 未做重型企业级加固。 当前架构为本地单节点，未设计多租户 RBAC 权限与分布式高并发支持。

沉淀出的三项工程习惯

如果推倒重来，有三件事是一定要保留的：

1. 编码前先立铁律。 “数字必须由程序计算得出，绝不可由模型生成”这条戒律，提前帮我否定了无数华而不实的设计。
2. 让大模型证明自己的调用价值。 构建一个能随时理直气壮说出“这题不需要模型参与”的路由器，能让系统变得极快、极稳且易于调试。这也反衬出了模型真正的增量贡献——无模型 90.4%，加上模型 95.9%。
3. 永远怀疑校验脚本。 如果业务逻辑和测试验证共用了同样的代码算子或数学假设，测试就失去了纠错能力。在关键验证层采用绝对精确的分数类型与确定性断言，是发现深水区 Bug 的唯一手段。