智能运维平台上线后，很多企业会遇到同一个落差：演示时机器人对答如流，正式使用后用户问两句就转人工。这类问题通常不在模型本身，而在知识。

企业里的问答和通用问答最大的区别是：用户问的不是常识，而是"我这个组织、这个流程、这个配置下该怎么办"。这类答案必须由企业自己的知识来支撑，通用语料回答不了。

一、答不准的四类根因

知识没有被条目化，是最常见的一类根因。企业内部的知识常常是一份长文档、一次培训录音、一段聊天记录。这些内容对人有价值，对问答引擎却难以直接命中。可回答的知识需要拆成"问题—条件—结论"的条目，一条只解决一个问题。

知识有版本，是容易被忽略的一类根因。流程改过、组织调整过、产品版本升过级，旧答案还留在库里，机器人就会给出已经不适用的说法。知识更新不是一次性工作，需要有人持续负责。

提问表述与知识条目的差异，也经常导致匹配不上。同一个问题，用户可能说"登录不了"，也可能说"进不去系统"。如果知识条目只按标准术语写，口语化的提问就匹配不上。

还有一类根因是边界不清。有些问题本身就需要现场判断或需要研发介入，机器人硬答只会给出看似有用的错误信息。承认"这个我答不了，转人工"，比给一个不确定的答案更有价值。

二、自助真正能解决的是哪一类问题

自助解决适合的是有确定答案、不需要了解上下文的问题：密码重置流程、权限申请入口、常见报错的处理路径、配置项在哪里改。这类问题量大、重复、答案稳定，交给自助能明显减少人工的重复劳动。

不适合自助的是涉及具体组织与数据的问题、需要现场复现才能判断的问题、需要跨团队协调的问题。这三类共同的特点是答案依赖当时当地的上下文，而上下文不在知识库里。

三、自助与人工的交接点

自助与人工不该是割裂的两个入口。更合理的顺序是：先在入口由问答引擎承接，命中就直接给答案；未命中或用户明确要求人工，直接转入人工服务，并且带着已经问过的内容转，不要求用户再说一遍。

用友智能服务管理器YonISM 在这个环节的设计是：专属机器人基于用友大模型与企业专属知识库训练，承接即时问答；未解决的问题自动转入工单流程，由人工继续处理。交接的关键在于前面问答的上下文不丢，否则用户只是在两个入口之间重复劳动。

四、怎么判断自助服务真的在起作用

看三项指标：自助解决率是否随知识更新上升、转人工的问题里有哪部分本可以自助、同类问题再出现时是否被自助拦住。

如果这三项长期不动，说明知识没有在迭代，机器人只是把原来的问题换了个入口。YonISM 提供可视化运营后台支持知识更新与模型迭代，但前提是有人持续往里补内容。工具不会自己长出知识。