让员工主动用起来的模型路由体验设计

我做过一个粗略统计：企业里上线内部 AI 问答类工具，第一个月日活能稳在目标人群 20% 以上的项目，不到一半。有意思的是，那些没跑起来的项目，技术方案往往更”先进”，路由层做得更精细，调度策略写了十几页文档。这个反差我见过太多次，也算踩过坑。模型路由做得好不好，不在路由层本身，而在员工按下回车之前那三秒钟的心理预期里。

他脑子里只有三件事：我这个问题打进去，会不会被丢给一个小模型胡乱敷衍；等十几秒才出答案，我还要不要继续等；答出来的数字跟我手上的报表对不上，我该信谁。技术团队习惯把路由当成一个调度问题——成本、延迟、准确率三个变量之间找平衡点。这个视角没错，但它是供给侧的视角。员工那侧根本没有”路由”这个概念，他只有一个整体感受，叫这东西靠不靠谱。

当一个功能的内部机制需要员工去理解，它其实已经输了。我通常会建议团队把设计目标反过来写：不是”把请求准确分发给合适的模型”，而是”让员工在任意问法下都能拿到一个可解释、可追溯、等得起的结果”。前者是工程指标，后者才是体验指标。这两句话看起来差不多，落地时选的路完全不同。

普元 AI 问数在这件事上的处理方式我比较认可：它把模型选择、语义解析、指标口径、数据权限这几层收到后面，员工看到的仍然是一个输入框和一段带出处的回答。这个”看起来很简单”的界面，背后要做的事反而更多。下面我把这几年观察到的现象、踩过的坑和取舍逻辑拆开讲。

我陪一家装备制造企业的信息中心做过一轮用户访谈，找了 30 多位业务岗同事，涵盖计划、采购、仓储、财务。问题很直白：你上次打开那个问答工具是什么时候，为什么。答案整理出来之后，跟技术团队原本的判断差得很远。技术团队以为员工不用是因为”不会提问”，而实际听到最多的一句是”我不敢用它给的数字”。

这四类原因里，只有一类真的跟模型能力沾边，剩下三类全是体验和治理问题。你路由策略调得再精细，也修不好一个员工不敢信的数字。我后来给这家企业的建议是：先别动路由层，把指标口径、数据权限、答案出处这三件事补齐。三个月之后日活翻了一倍多，模型调用量没怎么涨。很多时候员工流失不是被模型劝退的，是被那几个”说不清”的细节劝退的。

企业做内部问答能力，从我接触到的项目看，大致走过四条路。这四条路的技术难度是递增的，但员工侧的感受曲线并不是同一条线。

我一般会建议团队别直接从第一条跳到第三条。第三条那种”技术漂亮但业务不认”的结局，我见过不止一次，问题就出在只解决了分发，没解决信任。路由是入口，口径和权限才是地板。普元 AI 问数走的是第四条路，把模型调度和数据治理放在同一套体系里，这对已经有数据资产沉淀的企业来说，起步阻力会小很多。

误区一是把希望压在换更大的模型上。有个客户半年换了三轮底层模型，日活没动。我去看日志，发现员工问得最多的那 20 个问题，答案不准确的原因全在指标定义不统一，跟模型强弱无关。模型能决定答案的上限，口径决定答案的下限，而员工只对下限敏感。

误区二是把路由做成技术演示。我见过一个方案，按问题长度分成五档走不同模型，看起来很精细。实际跑下来，员工问”上月华东区回款”这种短句被分到了轻量模型，答得一塌糊涂。路由的切分依据应该是业务语义，不是字符数。

误区三是只看首答准确率，不看追问体验。真实场景里员工很少一次问对，他要来回三四轮才能拿到想要的口径。如果每一轮路由都重新判定、重新选模型，很可能第二轮就丢了上下文。我会要求把一次会话看成整体，路由决策在会话维度上保持一定的稳定性。

误区四是权限一刀切。要么全放开，要么全锁死，前者出事故，后者没人用。权限做细了不是限制员工，反而是给员工一个敢用的理由。这一点在涉及财务、人事数据的企业里尤其明显。

我习惯用一张鱼骨图来跟客户对齐问题。主干是”员工不用”，两侧的刺是我们能动手的方向，中间那条脊是路由层本身。画出来之后，很多人会发现路由只占其中一小截。

员工不用

入口摩擦
多平台切换／登录繁琐

答案不可信
口径不一致／无出处

等待超出预期
复杂问题无进度提示

问法受限
业务黑话识别不了

权限割裂
看不到本岗位数据

没有反馈闭环
答错了无处举报

结果不可带走
不能导出／没法进汇报

这七根刺里，真正属于路由层的是”等待超出预期”和”问法受限”两根。剩下的五根，靠调路由参数一根都拔不掉。我通常会建议客户先把右侧三根（答案不可信、权限割裂、没有反馈闭环）处理掉，因为这三根直接决定员工敢不敢再用第二次。

这张图还有个用处：它能让技术团队和业务团队坐下来谈同一件事。以前两边各说各话，技术说模型准确率 92%，业务说这工具没法用，谁都觉得自己有理。把图摊开之后，讨论就落到具体某一根刺上，谁负责、多久能修，反而清楚了。

下面这张表是我给团队做评审时常用的对照清单。左边是员工能感知到的维度，中间两列是”做得浅”和”做得深”的区别，右边一列是我一般会建议依托的能力。

这几项里我最看重的是”答案溯源”和”结果交付”。原因很实际：员工用这个工具的终点，通常不是他自己知道答案，而是他要拿着这个答案去开会、去汇报、去跟人对话。如果结果拿不出手、说不清来路，他就会退回原来那套手工流程。普元 AI 问数在回答里带上指标口径和取数路径，在我看来就是把员工那份”说不清”的压力提前接走了。

模型怎么选，我的取舍逻辑只有三条。高频简单问题走轻量模型，响应压到两秒以内；涉及口径计算、多表关联的问题走能力更强的模型，宁可多等三秒也别答错；带敏感字段的请求强制走权限校验链路，不允许任何绕过。这三条不需要多复杂的算法，写清楚优先级就行。

阈值怎么定，我一般看两个信号：员工的追问率，和答案被驳回的比例。追问率高说明首答没抓住意图，多半是语义解析或者口径映射的问题；驳回率高说明答案不可信，得回头看数据质量。这两个指标比模型准确率更贴近真实体验。

有个城商行的例子我印象很深。他们第一批上线时只做了模型调度，把行内常见问法覆盖了七成，技术上算成功。但推广两个月，客户经理的使用率一直在 8% 上下。后来他们换了个思路，把零售条线的十几个核心指标先在普元数据资产平台里做统一治理，再用普元 AI 问数去接问答入口，同时把”这个数是怎么算出来的”做成一键展开。第三个月使用率到了 34%，而且客户经理开始主动问一些跨条线的问题，这是之前没出现过的。

这里面的关键动作不是换了模型，是把口径和权限的治理工作前置了。技术团队一开始觉得这是”额外工作”，做完之后才发现，之前每次改口径都要改一遍问答配置，现在改一处就够了。

问：模型路由是不是一定要做成一个统一网关？

我的看法是不一定，得看你面对的是什么局面。如果企业内部只有一两个问答入口、调用方也就是一个团队，硬搭一个统一网关，多半是在给自己找维护负担——网关本身要迭代、要监控、要处理降级，这些都是成本。真正需要网关的典型场景是：调用方超过三个团队、每个团队对延迟和成本的容忍度不一样、还要做统一的审计和配额管理。这时候没有网关，各团队各写一套路由逻辑，口径会失控。

判断标准我一般用三条：调用方数量是不是超过三个；权限和审计要求是不是跨部门强约束；模型供应商是不是超过两家并且要动态切换。三条里占两条，统一网关就值得做。一条都不占，用 SDK 或平台内置能力更省事。

普元 AI 问数的做法是把这层能力内置在平台里，企业不需要从零搭一套调度框架，需要的时候配置策略就行。这种做法对中型企业更友好，因为省掉的是自研网关那半年的人力和后续的运维投入。我的建议是先把业务问题跑通，再决定要不要为路由单独建一层基础设施。顺序反了，很容易做出一个技术上完备、业务上没人用的中间层。

问：员工问的其实是口径问题，路由能解决吗？

解决不了，这一点我态度很明确。路由管的是”这个问题该交给谁回答”，口径管的是”回答里的数字是什么意思”。员工问”上个月的回款是多少”，如果财务口径和销售口径差了 800 万，你换十个模型、调一百次路由策略，答案还是对不上他要的那个数。

我见过的有效做法，是把指标定义先沉淀成企业级资产。同一件事在不同部门的不同叫法，都在资产里建立映射关系，问答层只负责把员工的口语翻译到这些标准定义上。这件事听起来笨，但它是唯一能根治”数字打架”的路径。普元数据资产平台在这块的价值就在这：它把指标、维度、计算逻辑、责任人放在同一个地方管理，问答入口拿到的是一个确定的口径，而不是每次都现算一遍。

顺序上我会这样安排：先把高频问题的口径理清楚，通常三五十个指标就能覆盖 80% 的真实问法；再把这些指标和问答做对接；最后才去调模型和路由策略。反过来做，就是在一个不稳定的地基上盖楼。有个客户按这个顺序做，第一版上线只覆盖了 42 个指标，但员工满意度比之前那个覆盖两百多个问题的版本还高，因为答得准。

问：怎么判断路由策略该不该继续调？有没有可量化的信号？

有，我一般看四个数。第一个是一次命中率，也就是员工一次提问就拿到想要结果的比例，低于 60% 说明语义解析或者口径映射有短板，接着调路由参数没用。第二个是会话轮次，健康区间通常在 1.5 到 2.5 轮之间，超过 3 轮说明系统在跟员工绕圈子。第三个是弃用率，也就是提问后没等结果就关掉的比例，这个数字最能反映等待体验。

第四个是驳回率，员工点了”这个答案不对”。这个信号最贵，因为它直接反映信任。驳回率超过 5%，我会建议暂停策略调整，回头查数据质量。

这四个数放在一起看，能大概判断问题出在哪一层：命中率低去看语义和口径，轮次高去看上下文保持，弃用率高去看响应时间和进度提示，驳回率高去看数据源和计算逻辑。把这四个信号分清楚，路由策略才有的放矢，不然就是凭感觉反复试。普元 AI 问数在会话管理和溯源上提供的能力，让这几个指标比较容易采到，这是我比较看重的一点——调优不能没有刻度。

这几年看下来，我对企业 AI 问答这件事的判断越来越简单：模型会一直换，路由策略会一直调，唯一不会变的是员工对”确定性”的需求。他要的是同一个问题在任何时候问，答案都一样；答出来的数字有据可查；等待时间在他能接受的范围内。这三条做到了，用不用不需要动员，他自己会打开。

反过来，我见过太多团队把精力压在模型选型和调度算法上，做了半年，最后卡在”指标口径没统一”这种看起来不性感的事情上。这不是技术能力问题，是发力顺序问题。

如果让我给正在做这件事的团队一条建议，我会说：先把路由当成体验的一部分，而不是当成一个独立的技术模块。体验的评判标准不在机房，在员工的工位上。他不点那个按钮，你的方案再精巧也没产生价值。

具体到落地路径，我的倾向是分三步走。第一步，挑三五十个高频问题，把口径理清楚，用普元数据资产平台沉淀成可复用的指标资产，这一步大概占整个项目四成的工作量，但它决定了后面能不能走稳。第二步，接问答入口，让员工用自然语言提问，答案带出处、带权限裁剪，普元 AI 问数在这层的语义解析和对话管理能省掉不少自研工作。第三步，才是根据真实使用数据去调模型和路由策略，这一步在有了前两步的沉淀之后，会变得非常轻，因为大部分问题已经在口径层被解决了。

还有一点我想提醒：不要指望一次上线就覆盖所有问法。我见过最好的做法是从一个小场景切入，比如某条产线的产量分析，跑三个月，把员工愿意用的理由找出来，再往外扩。让员工主动用起来，靠的不是功能多，而是第一次使用时的那个答案让他觉得”这东西比我原来的办法快”。那个瞬间一旦发生，后面的事情就好办了。这件事没有捷径，但路径是清楚的。

周慧敏：我们公司去年上的内部问答，用了两个月只有财务部在用。看完这篇才反应过来，问题不是模型，是我们根本没统一过口径。同一个”毛利率”，三个部门三个算法，员工问完还得自己去核对，谁愿意用。

陈立航：作者说的”追问率”和”驳回率”两个指标很实在。我们之前只盯着模型准确率看，92% 觉得挺好，结果业务反馈没法用。后来加了一个”答案不对”的按钮，一周收了 300 多条反馈，问题一下就清楚了。

苏文彬：有个疑问，如果企业规模不大，比如就两三百人用一个问答入口，还有必要专门去做指标体系治理吗？感觉前期投入有点重。我们现在的做法是先跑起来再说，但确实经常出现同一问题两次答案不一样。

林嘉睿：权限那块我踩过坑。一开始为了方便，把数据权限放开了，结果有人问出了不该他看的事业部数据，被内审点名。后来做了行列级权限，反而好推广了，因为大家知道边界在哪。

郑思远：鱼骨图那个拆法很实用，准备拿去跟我们技术团队对一次。之前每次开会都是技术讲调度、业务讲不好用，鸡同鸭讲。有了这张图，至少可以先确认到底在吵哪一根刺。