评估企业 AI，别只考一道题：要看它能否形成改进闭环

同一道测试题，选不出真正适合企业的 AI

以一个选型演练为例：企业给几家方案同一批文档和问题，比较谁回答得更快、更像标准答案。演示当天，答案准确、界面流畅的一方获胜。真正上线后，使用者换了一种问法，新制度替代旧制度，权限复杂起来，错误无法回溯，维护团队也不知道该改数据、知识、规则还是提示。

问题不在测试题太少，而在评估对象被缩小成了“模型的一次输出”。企业实际购买或建设的是一套长期运行的工作方式：业务人员如何提出真实需求，系统如何取得语境，结果如何被验证并进入行动，错误如何被发现和修正，变化如何被重新纳入。

因此，企业 AI 不应按静态回答能力选型，而应按闭环能力评估。 一个在演示中略显保守、但能说明依据、拒绝越界问题并被持续校准的系统，往往比偶尔给出惊艳答案却无法治理的系统更适合生产环境。

为什么传统功能清单在 AI 面前失效

确定性软件可以用“是否支持某功能”比较，因为相同输入通常产生稳定行为。生成式 AI 的表现则受到业务语境、输入表达、模型版本、检索范围和交互过程共同影响。“支持知识问答”这一勾选项，无法说明它读了哪份制度、如何处理冲突版本、权限是否继承、答错后怎样纠正。

演示环境还会制造三重偏差。供应方熟悉题目，能够提前整理材料；企业评委往往替真实用户提出规范问题；标准答案只检查最终文字，不检查引用、推理路径和后续动作。系统被优化成通过考试，而不是适应日常工作中的模糊、缺失与例外。

更重要的是，AI 质量不是固定属性。业务规则会变化，新数据会进入，人员会形成新的提问习惯。上线第一周的准确率即使很高，也不能回答维护成本、退化速度和纠错效率。若评估忽略运营环节，就把未来长期成本藏在一次漂亮演示之后。

“闭环能力六面盘”

可以用“闭环能力六面盘”组织企业 AI 的评价。六个面缺一不可，权重则应随场景风险调整。

一、场景真实性。 测试是否由真实角色在真实流程节点发起，问题是否来自日常任务，而非为系统量身定做。评估单位可以是一份合同审查、一次设备故障判断或一个客户请求，不应只是孤立问句。

二、语境可维护。 系统需要哪些数据、知识、定义和规则？谁能补充、修改、停用？冲突来源如何处理？如果每次改动都需要供应商工程师介入，初始效果再好也难以持续。

三、判断可解释。 输出能否关联来源、时间、适用范围和不确定性；遇到证据不足时能否提出澄清或拒绝。解释不是暴露模型思维过程，而是提供业务人员可以检查的事实链。

四、行动可到达。 结果能否进入现有任务、审批、业务系统和责任关系。一个建议如果还需人工复制、重新找对象、重新判断权限，就没有真正缩短流程。

五、治理可控制。 不同角色能看到什么、能建议什么、能执行什么？高风险动作是否需要批准，关键操作能否审计，出现异常能否暂停、撤回和降级？治理能力必须在错误演练中验证，而不是只读安全说明。

六、反馈可学习。 使用者如何标记错误、补充语境或拒绝建议？维护者能否看见问题分布，区分数据、规则、检索、模型与流程原因，并验证修复没有破坏其他场景？这决定系统是逐渐可靠，还是逐渐失真。

六面盘的意义不在计算一个总分，而在暴露短板。某方案可能回答质量优秀，却在语境维护与反馈上代价很高；另一方案行动集成成熟，却不适合处理高不确定的判断。决策者需要知道自己接受了什么权衡。

一次能够代表真实运行的 POC

第一步由业务流程负责人选择一个边界清晰的场景，并与技术、数据、安全和一线使用者共同写出评估说明。说明包括任务对象、当前做法、可接受输出、错误类型、后果、人工复核和结果动作。输入应使用经过授权的真实结构，必要时脱敏；输出是可执行的评估任务，而不是功能愿望清单。

第二步建立“参考集”和“开放集”。参考集用于让各方案获得必要语境，覆盖核心定义、常见案例和应当拒绝的问题；它不是最终考试题。开放集由真实用户在不背题的情况下完成日常任务，观察他们如何追问、修正和放弃。这样才能看见系统面对自然表达和未知组合时的行为。

第三步给所有方案相同的准备目标，而不是相同的准备方式。记录达到可用质量需要多少领域专家时间、数据整理、规则配置和技术支持。语境建设本来就是系统的一部分，把它排除在评估成本之外会误导选型。

第四步运行“错误日”。主动加入过期制度、权限不足、证据冲突、对象重名和无法回答的问题，检查系统能否提示不确定、保留来源、触发复核和完成降级。安全负责人关注越权与审计，业务负责人关注错误是否可识别，运营团队关注修复路径。

第五步进入短期影子运行。AI 给出建议，但不直接影响生产结果；使用者按原流程完成任务并比较。记录答案正确性、业务相关性、从提问到可用行动的时间、人工修订量、拒绝原因、严重错误和语境修复时间。检查点还包括版本变化后能否复测。

最后召开基于证据的选择会议。业务所有者评价实用性与行动衔接，领域专家评价事实和边界，技术团队评价集成与维护，治理角色评价风险。输出不仅是“选谁”，还要包括适用范围、上线条件、未解决问题、责任分工和退出路径。

四类看似严谨、实际失真的评估

只算平均准确率。 两个方案平均分相同，但一个偶尔出现高后果错误，另一个只是格式不佳，风险完全不同。应按错误类型和后果分层。

让项目组代替真实用户。 熟悉数据结构的人会提出系统容易理解的问题，也会自动补全缺失语境。真实使用者的语言、耐心和判断能力才决定采用结果。

忽略正确拒绝。 企业 AI 不是每问必答。没有权限、证据不足或超出适用范围时，可靠的拒绝比自信猜测更有价值。

把 POC 当缩小版上线。 POC 只验证关键假设，不应在价值未证实时建设全部集成。但若完全使用假数据、假流程和项目人员，又无法验证真实闭环。应精简范围，而不是抽空现实。

还要承认边界：低风险创意辅助可以更看重速度和可用性；合同批准、财务控制、人员决策等场景必须提高解释、权限和人工复核权重。不存在一张适用于所有 AI 的统一排行榜。

用评估本身检验合作方式

Luminent 的方案验证会从业务场景和现有环境出发，先明确对象、语境、行动和风险，再设计 POC。评估过程本身也是一次合作测试：企业能否共同维护定义，技术能否连接系统，错误能否进入改进流程。若六个面可以在小范围内被真实验证，后续系统建设才有可靠基础；若不能，继续堆功能只会扩大不确定性。