[AI架构师转型系列-5] 快速试错，快速验证方案

选型做完了，下一步不是写代码——是验证你选的到底对不对

本篇你将学到：

• 用 Dify 搭原型验证模型选型——实测对比 Qwen-Max、DeepSeek-V3、Qwen2.5-7B
• 设计三个验证实验：模型准确率对比、Token 消耗实测、编排边界测试
• 验证结论反推方案修正——模型换不换、Token 预算调不调、Prompt 怎么改
• Dify → LangChain → Agent SDK 工具选型框架——先验证对，再选工具做深

前四篇做完了一件事：MumuMall 智能客服从一句"加个 AI 客服"，变成了 Spec 三层 + 模型选型 + 成本预估 + 云端架构图。

这时候最容易踩的坑是什么？方案评审通过了，直接让开发团队开始写代码。两周后交付，发现 Qwen2.5-7B 在生鲜退换货场景下准确率根本达不到预期的 90%。Token 预估也比测算的多了一倍。编排逻辑里意图判断路由错了——用户说"我的虾到了但死了"，意图判断给了"知识咨询"而不是"转人工"。

问题不是方案写错了。问题是写完方案没有验证。

传统架构师验证方案靠评审——一群人坐会议室里盯着你的架构图，提问题。评审能发现逻辑漏洞，但发现不了"这个模型在你的 FAQ 上准确率到底多少"和"Token 消耗是不是真的和你预估的一样"。

这篇就做一件事：选型做完了，先用最小的成本验证它。验证完了再决定要不要进生产。

不是教你怎么用 Dify，是用 Dify 验证你的方案

Dify 是用来做什么的？很多人以为它是 Agent 开发平台。架构师不这么看。

架构师眼里，Dify 是方案验证工具。验证四件事：

第一，模型选型对不对。你在第四篇选了 Qwen-Max 做主模型、DeepSeek-V3 做备选——但在 MumuMall 的真实 FAQ 上，这两个模型到底表现差多少？用 Dify 接两个模型，同一批 FAQ 问题跑一遍，看实际准确率和响应时间。

第二，Token 预估准不准。你在第四篇算了 MumuMall 日均 5000 次咨询的 Token 消耗——但那是在"假设每次对话 3 轮、每轮 1500 Token"的前提下。真实对话中，用户可能追问 5 轮，每轮上下文不断膨胀。Dify 跑 50 条真实对话，看实际 Token 消耗是不是在你预估的 1.5 倍以内。

第三，知识库够不够。MumuMall 的产品文档、FAQ、退换货政策已经上传到 OSS 了。但用户问的不一定是文档里有标准答案的问题。比如"我买的虾到了但死了"，这个问题需要 RAG 检索生鲜售后政策 + LLM 判断严重程度 + 可能直接转人工——知识库检索到的文档片段能不能支撑这个链路？检索命中率多少？

第四，编排逻辑通不通。你在架构图里画了意图判断 → 知识检索/工单操作/转人工三条分支。但用户输入"我的订单 TN-001 的物流怎么还没更新，我要退款"——意图判断应该走工单查询还是转人工？真实测试才能发现边界情况。

这四件事，Dify 10 分钟搭好原型就能验证。不用等开发排期。

验证实验：用 Dify 快速跑一轮——方法论

注意：以下数据不是真实跑出来的，目的是介绍评测验证方法。实际项目中请用自己的数据照此方法验证。

验证实验的目标不是"拿一个准确率数字"，而是回答三个问题：

1. 这么多模型选哪个？（模型对比）
2. 预估的费用靠不靠谱？（Token 实测）
3. 编排逻辑在边界情况会不会翻车？（编排边界测试）

下面逐一介绍这三个实验怎么做。

实验一：模型对比——如何客观比较候选模型

场景覆盖：选取若干条有代表性的客服问题，覆盖主要业务场景（如退换货政策咨询、物流状态查询、促销规则、生鲜售后、投诉）。场景覆盖越全，结论越有参考价值。

对比维度：在 Dify 里对同一个 Workflow 切换不同模型（如 Qwen-Max、DeepSeek-V3、自建开源模型），同一批问题各跑一轮。对比维度至少包括：

结论分析方法：

• 不是比谁的跑分高，而是找业务目标下的最优性价比。准确率差不多时，成本差异可能是数量级的
• 自建开源模型要同时评估：部署成本（GPU机器/云资源）、运维人力、是否可以接受更长的响应延迟
• 核心原则：不能只看公开 Benchmark，必须在自己的数据上验证。这是架构师选型区别于"网上看测评"的分水岭

实验二：Token 消耗实测——用采样对话反推真实成本

为什么需要实测：成本预估的公式通常是 日均咨询量 × 平均轮次 × 单轮 Token × 单价，但三个乘数都可能和实际偏离——简单的 FAQ 可能比预估更省 Token，复杂投诉和售后场景的 Token 消耗可能轻松翻倍。不实测就直接给客户报价，上线后超预算谁来负责？

操作方法：

1. 按业务比例抽样：根据各场景的咨询占比（如简单 FAQ 占大头、复杂投诉占小头），抽若干条典型对话在 Dify 上实际跑完，记录每个场景的单次 Token 消耗
2. 分场景统计：按正常场景（简单 FAQ）、复杂场景（投诉/售后）、多轮追问场景分别统计实测 Token，计算加权平均值
3. 与预估值对比：找出偏差最大的场景，分析是 Prompt 太长、上下文膨胀、还是模型输出冗余
4. 修正报价模型：用加权实测值替换预估公式中的单轮 Token 数，重新计算月费。如果偏差较大，及时调整给客户的报价

常见的坑：

• 简单查询的 Token 通常低于预估，但占大头的场景偏低掩盖不了长尾场景的偏高
• 多轮对话的上下文累积效应很容易被低估——每一轮都要把历史对话带进去
• RAG 召回的知识片段也会计入输入 Token，检索结果越长越贵

实验三：编排边界测试——找出意图路由的翻车现场

编排逻辑在正常 case 下通常都能跑通，真正出问题的是边界情况。比如：

• "我的虾到了但死了，我要退款"——走知识检索（给退换货政策）还是转人工（生鲜售后强情绪升级）？
• "我昨天买的今天降价了能退差价吗"——走知识检索（搜索价格保护政策）还是转人工？

操作方法：

1. 构造边界用例集：根据 Spec 中写的边界条件，针对性地构造用户的模糊输入。重点覆盖：多意图叠加、情绪化表达、业务规则边缘
2. 逐条记录路由结果：对比预期路由和实际路由，标记所有偏差
3. 偏差归因：
   1. 是模型没理解？→ 可能是基础能力不够
   2. 是 Prompt 没覆盖？→ Spec 写了但 Prompt 没同步更新，这是最常见的翻车原因
   3. 是编排逻辑本身有歧义？→ 两个分支都能算对，需要重新定义边界

关键认知：边界测试不通过不一定说明模型不行，往往暴露的是 Spec 到 Prompt 的翻译损耗——架构师在 Spec 里写清楚的规则，工程师写 Prompt 时漏掉了，或者写得不够明确。这是验证流程最有价值的地方。

验证完了，下一步选什么工具

经过 Dify 验证，你会得到：

• 模型选型结论（哪个模型/哪个规格在准确率和成本之间达到最佳平衡）
• Token 消耗的修正系数（在预估基础上该上调还是下调）
• 编排 Prompt 的优化清单（哪些边界场景需要补强）

修正完了，团队准备开始写代码。这时第二个问题来了——用什么工具写？

Dify 验证很快，但生产环境不一定用 Dify。四种工具的选型框架：

通用推荐路径：Dify 做原型验证（当前阶段）→ LangChain / 官方 SDK 做生产落地。不一开始就上 LangChain——Dify 验证的改动成本是分钟级，LangChain 是小时级。先验证对，再选工具做深。

架构师在方案设计完的第一步不是写代码，是验证。

验证四件事：模型在你的数据上准确率多少、Token 消耗和预估差多少、知识库检索命中率够不够、编排边界会不会误判。

验证结论要改方案：模型选型可能换、Token 预估要上调、Prompt 要补边界规则。这不是方案失败——是方案变精确了。

选工具不是越强越好：Dify 验证快但生产受限，LangChain 灵活但改动慢。先验证再选工具——用 Dify 把方案跑对了，再决定用什么跑生产。

本篇产出：Dify 验证报告（模型对比 + Token 实测 + 编排边界测试）+ MumuMall 方案修正 + 工具选型推荐。

下一篇：方案验证完了，该上生产了。一个 Agent 够不够？什么时候该拆成多个？部署到阿里云——ECS 选什么规格、弹性伸缩配什么策略、高可用怎么验证？这些不是运维决定的，是架构师决定的。