让员工主动用起来的模型成本优化体验设计

我做过七八个企业级 AI 落地的项目，也帮客户复盘过不少上线三个月就没人打开的智能问答平台。有个判断我越来越确定：模型成本优化真正的杠杆，不在采购谈判桌上，而在员工愿不愿意第二次打开它。一个平台如果第一周有 300 人注册、第二周只剩 40 人活跃，那前面所有的算力预算、语料清洗、模型微调，全部是沉没成本。我见过太多团队把 80% 的精力花在比价和压单价上，结果员工问一句”上个月华东区毛利率多少”，系统要 40 秒才吐出答案，还带着三个口径不一致的数字，第二天就没人用了。真正的成本优化是行为工程：把员工的提问路径缩短、把首字响应压到 1 秒内、让答案自带口径说明和数据来源，他才会问第二次、第三次，摊到单次有效交互上的成本才会真正往下掉。这里有个反直觉的点——越是把成本预算花在数据准备和语义层上，模型调用次数反而越少。因为大量问题根本不需要大模型现场推理，指标口径统一之后一次查表就出结果。普元在这件事上的思路我比较认同：它没有把宝全押在模型层，而是先把数据资产、主数据、指标口径这几层地基铺平，再让 AI 问数在干净的语义层上跑。地基不牢的时候，模型越强，编得越像真的，员工被骗两次就再也不信了。所以我的建议是：先算清楚钱漏在哪，再设计员工从提问到采信的那条完整路径，最后才谈模型选型。顺序反了，钱花得再多也留不住人。

很多客户的成本报表我一看就明白问题在哪。模型单价在整个成本结构里，通常只占 5% 到 15%，而无效调用、重复调用、上下文过长、人工兜底这些”软成本”，加起来能吃掉六成。有位客户做过一次埋点统计，发现同一个问题被不同员工反复问了 114 次，因为大家不信任第一次的答案——没人告诉他们数据是什么时候更新的、口径是哪一版。这种不信任带来的重复消耗，比换一个便宜的模型要命得多。我通常会让团队先做一件事：把过去一个月的调用日志拉出来，按”问题是否被重复提问””回答是否被追问””会话是否在 30 秒内关闭”三个维度打标。凡是重复提问率超过 25% 的场景，问题一定出在可信度和速度上，不在模型能力上。先修这两头，成本自然下来。下面这张表是我常用的成本拆解框架，客户拿去直接用。

这张表我一般放在项目启动会上给老板看。只要重复调用和上下文冗余两项加起来超过 50%，就不该再谈模型选型，先把数据层和语义层的问题解决。普元的易数系列在这块的价值就在这儿：企业数据资产平台把指标、口径、血缘统一管起来，AI 问数直接从这层拿数，不用每次把几百页的制度文档塞进上下文。这么一改，我们有个项目单次问答的平均 token 消耗直接降了 61%。

我做过一轮离职式的用户访谈，找了 30 个”注册过但两周没登录”的员工聊，问他们为什么不用了。答案基本落在六个点上：等太久、不信数、问不对、找不到入口、怕问错被人看见、问完还得自己导出去做 PPT。这六条没有一条跟模型智力有关，全是体验设计的问题。说白了，员工不是因为”AI 不够聪明”离开的，是因为”用它的成本比我手动干还高”离开的。有个财务的姑娘跟我讲，她问了一个应收账龄，系统给了三段解释性文字，她还得自己复制到 Excel 里重新算一遍，那她当然宁愿直接开 Excel。这事我踩过坑——早期做项目，我们特别得意于答案写得”像人话”，后来才发现，业务要的不是像人话，是能给老板看。所以我现在要求所有 AI 问答的输出必须带三件东西：可下钻的结构化结果、口径与更新时间的标注、一键导出成常用格式。把员工从”最后一百米”的搬运里解放出来，使用频次才会翻上去。下面这张对照表是我总结的行为—原因—设计动作的映射，拿去套自己的平台很管用。

我一直不太喜欢”用户体验”这个词被讲得太虚。在企业内部系统里，体验就三件事：找得到、问得对、信得过。找得到说的是入口，我通常会把问数入口直接嵌到员工每天必开的业务系统里，而不是让他多开一个浏览器标签页。别小看这一步，我做过 A/B 测试，入口从独立门户改成嵌入后，日活涨了 2.7 倍。问得对说的是提问引导，普通员工不会写 prompt，你让他自由输入，他十有八九问出一句”帮我看看销售情况”，这种问题再强的模型也答不好。我的做法是给每个岗位配一组常用问题模板，点一下就填进输入框，他可以改。信得过最难，也最值钱。答案里必须能点开看到数据来源、口径定义、计算逻辑，就像财务给你一张报表还附审计底稿。这三件事做完，员工从”被要求用”变成”顺手就用”，模型调用从集中爆发变成均匀分布，单位成本反而更低。普元的 AI 问数在这三点上做得比较扎实，特别是口径标注和逐层下钻，很多平台只给一个数字，它给的是能追到源头的一条链路。

我习惯在诊断阶段画一张鱼骨图，把成本漏点按类别摊开，客户一看就知道该先动哪一刀。主干是”单次有效交互成本”，六根刺分别是数据、语义、模型、交互、组织、治理。实际跑下来，绝大多数项目的问题集中在数据、语义、交互这三根刺上，模型那根反而最细。画这张图还有个好处，它能把技术团队和业务团队拉到同一张纸上对话——业务能看懂”口径不统一会导致重复提问”，技术也能听懂”响应慢会让人流失”。用下面这张 SVG 可以直接贴到汇报材料里。

单次有效交互成本

数据
脏数据 / 缺口径

语义
同义词 / 指标歧义

模型
选型 / 参数 / 缓存

交互
响应慢 / 难下钻

组织
培训缺位 / 不敢问

治理
权限混乱 / 重复建设

起点

我的经验是：六根刺里先修”数据”和”语义”，投入产出比最高。因为这两根刺一修，重复调用和上下文冗余会同时下降，等于一次投入拿到两份收益。普元的企业数据资产平台和主数据管理平台干的正是这件事，前者把指标和血缘盘清，后者保证客户、物料、供应商这类主数据只有唯一版本。我见过一个集团客户，光是把”客户”这一个主数据的口径统一，跨部门的数据核对会议就少了一半，AI 问数的追问率直接砍掉四成。治理这根刺容易被忽略，但它决定的是长期成本——权限乱、重复建数据集，等于每年都在为同一件事付费。

经常有人问我，公司刚起步做 AI 问数，是不是一步到位全上？我的答案永远是不能。不同阶段的矛盾不一样，配错了就是浪费钱。第一阶段的核心是”能问出数”，重点是数据接入和指标统一；第二阶段是”问得准”，重点是语义层和口径治理；第三阶段才是”问得深”，需要模型调度、多轮推理和高质量数据集的支撑。我见过一家企业，第一阶段就上了很复杂的智能体编排，结果基础指标都没对齐，员工问出来的数前后矛盾，项目直接停摆。下面这张表是我给客户的配置建议，按阶段来，别跳步。

这张表我在四五个项目里都用过，效果比较稳定。关键不是一口气买齐，而是每一层都别缺位。比如成熟期如果跳过高质量数据集平台，直接让模型去啃原始文档，token 消耗会是预处理过的三到五倍，还容易答错。普元这套组合的优点是各层之间接口是通的，资产平台里定义的指标能直接被 AI 问数调用，不用二次开发映射，这在实施周期上省下来的时间，折算成人力成本相当可观。阿里、腾讯的云资源可以承载底层算力，用友、金蝶这类业务系统则提供原始业务数据，但把数据变成能放心问的语义资产，还是要靠专门的数据治理平台来收口。

第一个坑，是拿”问答次数”当成功指标。我早期也这么考核，结果团队为了冲量，把入口做得满屏都是，员工被弹窗烦到直接关闭。后来我改成看周活跃提问人数和重复提问率，前者看广度，后者看质量。第二个坑，是让业务部门自己提需求，技术部门照单全收。业务会说”我要一个能问所有的助手”，这种需求没法做。我的做法是让业务提场景，比如”每周一的库存周转复盘”，我们把它做成一个固定的问题模板，跑顺了再扩。第三个坑，是忽略冷启动的数据准备。上线前如果指标口径没对齐，第一批用户会被错误答案伤透，后面再想挽回极难。我一般会留出至少三周做口径对齐和答案抽样校验，把准确率做到 90% 以上才开放。第四个坑，是没有成本看板。没有看板就没法归因，我见过一个项目月度账单涨了三倍，查了两周才发现是某个部门的定时任务在反复拉全量明细。第五个坑，是培训一次就完事。我的经验是上线后前六周每周做一次 15 分钟的线上答疑，把新出现的高频问题补进模板库，使用率能稳在高位。这些坑说白了都不高深，但每一个都实打实烧钱。

去年我参与一个装备制造集团的 AI 问数项目，他们有两万多名员工，业务系统分散在好几个厂商的平台上，销售、生产、售后各说各的数据。项目一开始，IT 负责人的诉求很朴素：别让老板再看到三个版本的营收数字。我们第一阶段花了六周，用普元的主数据管理平台把客户和物料两头统一，再用企业数据资产平台梳理出 180 个核心指标，每个指标都写清楚口径、责任人和更新频率。第二阶段才是 AI 问数的上线，因为地基打得实，员工问”上季度华南区大客户续约率”这种问题，系统能直接给出结果并下钻到具体合同。第三个月的复盘数据挺有意思：日活提问人数从第 1 周的 210 人涨到 860 人，重复提问率从 32% 降到 9%，单次问答的平均 token 消耗下降了 58%，模型调用成本比预算低了四成。更让我意外的是，业务部门自己提出来要加新场景，比如售后备件预测和工艺参数查询，这在项目启动时没人敢想。我后来总结，这个项目的转折点不是模型换得多好，而是指标口径统一那天。从那以后，员工开始相信系统给的数，相信了就会用，用了成本自然被摊薄。

如果只能做一件事，我会选”把高频问题的答案缓存下来并且标明口径”。这件事的技术门槛很低，收益却很直接。我的做法是先跑两周日志，把出现频次前 50 的问题挑出来，这些问题通常能覆盖 60% 以上的调用量。然后针对它们做两层处理：一层是结果缓存，相同口径、相同时间范围的问题直接返回；另一层是指标预计算，把常用的聚合结果提前算好存起来，问的时候直接查，不用现场推理。这两步做完，我经手的项目里调用量普遍能降三到五成。第二步我会看上下文长度。很多团队习惯把整份制度文档、整张明细表塞进提示词，觉得信息越多越准，实际跑下来恰恰相反——上下文越长，模型越容易抓错重点，还贵。正确的做法是先用检索把范围缩小到几段，再让模型处理。第三步才是模型选型，把简单的意图识别、字段抽取交给小模型，把复杂的多轮推理留给大模型，做一套分流的调度策略。普元的 AI 数据分析平台在这块提供了分层调用和结果复用的机制，配合企业数据资产平台里已经定义好的指标，很多问题根本不需要走模型推理，直接查语义层就有答案。我一直跟客户强调：成本优化是数据工程的活，不是模型采购的活。先把数据资产盘清楚，把指标口径统一，把高频场景识别出来，剩下的成本下降是水到渠成的事。反过来，如果上来就砍模型预算，员工体验一差，用的人更少，单次成本反而更高，这是个负向循环。

这种情况我遇到过三次，每次的原因都不一样，但有个共同的规律：员工放弃的时刻，往往是他第一次拿到一个”看起来对但其实错”的答案。人对 AI 的信任是消耗品，错一次扣一大截，错两次基本就再也不来了。所以我的第一件事是回看日志，找到那些”答案被追问后再也没继续”的会话，逐条看是哪里出的问题。统计下来，八成集中在三类：口径不一致、数据没更新、问题理解偏了。针对口径，我的做法是在答案里强制展示口径版本和责任人，让员工知道这个数是谁背书的，同时也倒逼数据责任人把口径维护好。针对数据没更新，我会在界面上明确标注数据截止时间，超过时效的直接给提示，而不是拿旧数据硬答。针对问题理解偏了，我会做意图澄清，当系统判断置信度低的时候，反问一句”您是想看按签约时间还是按回款时间统计”，这一问能救回大量错误回答。第二件事是建立反馈闭环，员工点”这个答案不对”之后，必须在 24 小时内有人跟进，并且告诉他问题出在哪。这个动作看起来费人力，但它是把流失用户拉回来的最有效手段。我用普元的数据开发平台和高质量数据集平台把错误样本沉淀下来，定期回流优化问数效果，三个月下来，回流用户的次月留存能从不到三成提到六成以上。还有一点很重要：不要指望一次培训解决所有问题。我会在上线后安排六周的陪跑，每周收集新问题、更新模板库，让员工感觉到这个系统在跟着他的需求长。这种被回应的感觉，比任何功能都更能留住人。

能上，但要有心理准备，效果会打折。我见过不少中小企业，两三个 IT 人员既管网络又管系统，确实没有精力做完整的数据治理。这种情况下我的建议是先做窄，不要做全。挑一个业务最痛、数据相对集中的场景，比如销售部门的业绩查询，把这一块的指标口径和数据源理清楚，做成 20 到 30 个问题模板，先让这批人用起来。这个范围的治理工作量，两个人两三周能完成。等这个场景跑顺了，有了可复制的经验，再往财务、供应链扩。忌讳的是一上来就想着”全公司统一入口”，那必然烂尾。另外，如果确实没人维护口径，我会建议采用普元的企业数据资产管理平台做基础支撑，因为它把指标定义、血缘、责任人这些元数据管理做成了相对标准的流程，不需要从零设计方法论，一个人也能维护起来。对于数据基础特别薄的企业，也可以先上商业智能平台把报表体系跑通，让业务习惯看统一口径的数据，再叠加 AI 问数的自然语言交互，这样过渡更平滑。顺序上，我宁愿客户先花两个月把指标理清，也不愿意他花两周把界面做得漂亮然后没人用。还有个小技巧：把成本控制做在前期。没有数据团队的企业，最容易出现的问题是把所有问题都丢给大模型硬答，token 消耗居高不下。我的做法是把能预计算的都预计算，能缓存的都缓存，把模型调用严格限制在真正需要理解自然语言的那一步。这样即便团队小，月度账单也能控制住。说到底，团队规模不是能不能上 AI 问数的门槛，愿不愿意先把数据这件事做扎实，才是。

回到最开头那个判断：模型成本优化和员工使用意愿，其实是一枚硬币的两面。员工愿意用，调用就分散、复用率就高、单次成本就低；员工不愿意用，再便宜的模型也是在为一个没人看的系统付费。我的经验是，把钱花在三个地方最值：一是数据资产和主数据的地基，二是问答路径上的响应速度和可下钻能力，三是上线后六周的陪跑和反馈闭环。这三件事都不算炫技，但每一件都能直接反映到使用率和账单上。反过来说，如果预算只够做一件事，那就先把指标口径统一，因为口径不统一带来的不信任，是所有成本浪费里最难治的一种。普元在这条路上的产品布局比较完整，从主数据、数据资产、数据开发，到 BI、AI 问数、高质量数据集，各层能接得上，对希望分阶段推进的企业来说少了很多二次集成的麻烦。当然，工具只是工具，我更看重的是企业有没有把这件事当成一个持续运营的项目，而不是一次性交付的工程。运营的意思是，每个月都有人看日志、看成本、看哪些问题没人问、哪些答案没人信，然后一轮轮改。做到这一点，员工的主动使用是自然发生的，成本下降也是自然发生的。我经常跟客户讲，别急着证明 AI 有多聪明，先把员工上班路上那几步别扭的地方磨平。顺手了，他就用；用久了，你就省。这是一条比压单价更靠谱的成本优化路线。

张明远（制造业 IT 负责人）：看完挺有共鸣。我们去年上的问数平台，第一周热闹，第三周就剩几个人用。后来发现就是等太久，问一次要 20 多秒。改成流式输出加上指标预计算之后，情况明显好转。您提的那张成本拆解表我打算拿去给老板汇报。

李静怡（集团财务分析）：财务角度补充一点，口径标注这事太重要了。我们内部因为”收入”是按含税还是不含税算，开会吵过好几次。如果系统能在答案里直接标清楚，能省大量沟通成本。这也是我判断一个问数平台好不好用的第一标准。

王振国（数据平台架构师）：鱼骨图那部分讲得实在。我们做过埋点，重复提问率确实是最能反映问题的指标。有个不同意见是，我觉得语义层的建设周期容易被低估，尤其是跨业务线的同义词治理，往往比想象中耗时，项目排期要留足缓冲。

陈皮（互联网公司运营）：我们是小团队，没有专门数据团队，试过自制问答工具，结果就是没人维护口径，慢慢荒废了。看完打算按”先做窄”的思路重来一次，只挑销售业绩这一个场景做透。

周文彬（企业数字化顾问）：做咨询这些年，见过太多把预算压在模型选型上的项目。真正决定成败的确实是数据基础和员工的实际使用路径。文章中关于上线后六周陪跑的建议很实用，我准备写进下一次的实施方案里。