2026年刚刚过去第一个工作周易慧智能就连续收到几个分量不低的奖项通知——业内俗称的“凌云奖”年度智能应用、某项年度数字化创新奖以及一个由多家行业分析师联合评选的技术创新产品奖。消息在团队群里转了两轮大家开心了十几分钟很快又各自扑回项目上。做企业服务的人大概都有同感年底年初这种奖项满天飞含金量参差不齐真正拿到手里沉甸甸的并不多。但“凌云奖”这个评选体系我们内部一直比较看重。原因很简单它的评审不是看一页纸的申报材料而是包含随机抽访真实客户、盲测产品功能、评审团现场质询等环节。也就是说能被它认可的基本等于业务真实性和产品力都扛过一轮“背调”。这篇内容不打算写成获奖通稿我想把奖项背后我们这一年沉淀下来的技术判断、交付方法论和踩坑记录摊开讲一讲。无论你是在做企业级AI产品还是正在给自家业务设计智能助手里面不少东西应该可以直接拿回去用。1. 先看奖项这类荣誉到底在评什么、怎么评1.1 “凌云奖”这类评选的评审逻辑和公关榜单是两码事很多人容易把行业奖项一概归为“花钱买背书”但成熟一些的评选体系早就不是简单看品牌声量了。“凌云奖”的做法是官方提名加自主报名并行随后进入一个比较硬核的评审流程材料初审提交产品介绍、技术架构说明、客户案例、量化效果数据。这一关先刷掉一批没有实际交付案例的申报者。平台功能盲测评审委员会安排一个独立的评测团队用预设任务集在真实部署环境里跑产品。比如你申报的是智能知识库产品评测团队就会导入一份陌生领域的企业文档看系统能在多长时间内完成解析、能不能回答出带有专业门槛的问题、答案有没有依据。客户抽样访谈这是最劝退“刷奖型”选手的一环。评审组会从申报材料中随机抽取一两个客户直接约电话访谈问部署周期、使用频率、真实业务指标变化、售后服务响应速度。如果材料里写的效果和客户实际说的对不上直接扣分甚至取消资格。技术委员会终审最后一关由技术委员会成员投票维度包括技术原创性、可量化业务价值、规模化落地能力、服务质量。从我们自己的经历看这里面最要命的不是功能演示而是客户抽样访谈那一环。销售和售前可以把材料写得天花乱坠但客户CIO一开口项目是不是真用起来了、效果数据是不是从后台真实拉出来的几句话就能判断出来。所以如果你想申报这类奖项第一条建议是别把精力花在包装上把自己服务的客户做深做透评审会替你找到证据。1.2 把外部评价当成产品体检信号比奖杯本身值钱我观察到一个现象很多人对奖项的态度是两个极端要么嗤之以鼻要么当作门面四处宣传。但比较务实的做法是把它当成一次第三方体检尤其是那些带客户访谈和盲测环节的奖项。今年我们的产品经理专门把几个评审反馈翻出来逐条对照了一遍产品路线图。有三条反馈让我们印象很深客户在访谈中提到知识库的“冷启动”体验还有优化空间。“冷启动”指的是客户上了系统之后从导入文档到真正能用起来这段时间。如果文档解析要两三天、人工校对要一周即使后面效果好第一印象也会打折扣。私有化部署场景下客户对资源占用格外敏感。很多传统企业不可能为一个大模型产品单独划出一台顶配GPU服务器他们更希望用一个相对紧凑的配置把事情跑起来。“无损升级”是客户反复提到的高频词。企业级客户最怕版本升级把正在跑的业务搞挂所以升级过程的平滑性几乎和功能本身一样重要。这三条反馈直接改进了我们的季度优先级。有些功能本来排在后面因为评审反馈提前了两个版本上线。这里想说的核心是奖项的价值不在于挂在官网首页上而在于它提供一个外部的、相对客观的视角让你看到自己团队因为天天泡在代码里而忽略的问题。2. 获奖背后的技术底盘产品矩阵与架构决策2.1 从“对话机器人”到“智能业务中枢”的产品思路转折易慧智能早期的产品形态其实很常见就是一个企业级智能客服机器人核心能力是FAQ问答客户把帮助文档丢进来我们做一个检索问答系统解决“怎么退换货”“发票多久开”这类问题。做了差不多一年我们意识到一个瓶颈客户真正愿意持续付费的不是“会说话的文档”而是能跟业务系统打通的执行型智能体。举个例子客户问“帮我查一下这个订单为什么还没发货”如果只是文档问答系统只能回一句“请您联系客服”。但如果把订单系统、物流接口、工单系统都接进来智能体可以自己查出订单状态、判断滞留环节、自动提交一个催办工单然后告诉用户“已经帮您催办了预计明天下午更新进度”。后者带来的价值完全是不同量级的。因此从去年下半年开始我们把整个产品从“单点问答”重构为三层架构接入与编排层负责渠道接入Web、企业微信、钉钉、App、会话管理、Agent任务编排。能力引擎层包含知识问答引擎RAG、流程执行引擎Agent、数据分析引擎指标归因。数据与治理层知识库管理、权限体系、审计日志、模型配置与评测。选择这套架构并不是因为它听起来高级而是综合了三个现实考量。第一企业客户的知识库和业务系统通常是不断变化的能力层和管理层分离可以避免改动数据时碰坏上层逻辑。第二大模型技术迭代太快我们把模型抽象成了可替换层今天用这个开源模型明天换更强的商业模型上层用户无感。第三私有化交付是很多客户的硬指标分层清晰意味着可以按模块打包资源占用更可控。2.2 核心引擎一企业级知识问答系统与检索增强落地细节知识问答是我们最成熟也是在评奖时最经得起盲测的一块能力。技术框架大家可能听过不少次了就是RAGRetrieval-Augmented Generation检索增强生成。但很多人对RAG的理解停留在“向量化文档检索TopK拼给大模型”这个层面真正到了企业环境里坑远比教程里写得多。先解释一个关键选择为什么用RAG而不是直接微调大模型企业知识库有一个显著特点内容高频更新。今天上了新品产品手册要改明天出了新政策客服话术要变。如果靠微调意味着每一次内容变更都要重新训练成本高且周期长而且大模型微调容易把新旧知识搞混。RAG则把“知识存储”和“内容生成”分离文档更新后重新切片向量化即可十秒钟生效天然支持审计留痕——答案下面可以挂来源文档链接这是企业合规的硬性要求。在RAG落地上我们早期版本只用了向量检索效果并不理想尤其是遇到专业术语或者长尾问题。后来改成多路召回加重排的架构BM25稀疏检索擅长精确匹配对型号、工单号、合同编号这类专业标识符非常有效。向量稠密检索擅长语义匹配能捕捉同义改写。数据库精确查知识库中包含大量结构化信息例如“设备编号A-102的保养周期是多少”直接查表答案更可靠。三条路径的结果汇总后再交给一个重排序模型统一打分只保留最相关的3到5个片段连同来源信息一起交给大模型生成答案。这样做的直接效果是答案准确率显著提高而且幻觉率大幅下降因为生成阶段看到的上下文更集中、更精准。切片参数也踩过不少坑。实践中比较稳的经验是对于企业文档单个切片控制在256到512个字符之间并在切片间设置少量重叠防止一个完整段落被拦腰截断。一开始我们图省事把切片设成1024结果一个问题往往同时命中多个切片重排之后依然能打到关键信息但偶尔会出现答案把两个不相关上下文“缝合”起来的情况让客户误以为系统在编造内容。2.3 核心引擎二业务Agent与任务编排的中台设计“智能体”和“对话框机器人”最大的区别在于前者能干活。我们遇到的客户需求常常是这样希望员工用自然语言直接发起流程而不是去复杂的业务系统里一层层点菜单。这就需要一个能理解意图、拆解任务、调用工具、执行动作的Agent框架。我们的Agent中台借鉴了一些通用Agent思路但更偏“流程优先、模型兜底”的策略。为什么这么做因为企业级应用最重要的是可靠。你让模型完全自由地规划步骤它可能今天这么干明天那么干还可能冒出用户没授权的操作。所以在设计中我们强制划分了两种模式固定流程模式适用于高频、确定性强的场景。表单填写、工单创建、订单查询这些动作我们直接画好流程节点Agent只能按节点走。自由规划模式适用于低频、开放式的场景。比如“帮我把这个季度所有异常订单做个归因分析”允许模型自主拆分任务但涉及写操作、发送邮件、创建订单等敏感动作时必须经过用户确认节点。这里分享一个非常惨痛的教训。早期我们给某零售客户做了一个巡检Agent它发现门店监控数据异常后会自动创建维修工单。某个周末系统一次巡检发现三十家门店的温控设备上报数据波动Agent一口气自动创建了三十张加急工单而实际上只是传感器校准的临时故障。门店负责人周一上班看到一堆待办直接打电话投诉。从此我们立了一条铁规矩凡是会对外产生实际影响的动作必须加人机确认环节。自动化不是越彻底越好有节制的自动化才是企业客户真正需要的。2.4 核心引擎三指标洞察与经营监控产品矩阵里第三个比较重要的模块是数据洞察层通俗讲就是给业务和管理层看效果报表同时用AI辅助解读。客户花几十万上百万采购一套智能产品老板不可能只关心“这个机器人聊天聊得好不好”。他真正关心的是投资回报率比如客服平均响应时长降了多少、工单积压减少了多少、自助解决率有没有提升。所以我们在产品里内置了一个“价值仪表盘”自动汇总以下指标自助服务解决率问题被智能体直接解决的比例平均响应时间从用户提问到获得有效回答的耗时人工介入率智能体无法处理转人工的比例高频问题聚类自动总结客户最常问的五类问题这些指标在评奖的客户访谈环节帮了大忙。因为客户不需要凭印象说“效果不错”而是能直接报出一串从后台拉取的数据。这也是我想提醒同行的一点做企业级AI产品从第一天就要把可量化的效果埋点想清楚。后补数据等于没有数据因为历史基线已经丢了。3. 拿下奖项的“硬通货”两个真实交付场景复盘3.1 制造行业设备维修知识库的从0到1制造业客户是易慧智能今年重点深耕的方向之一。我们服务的一家大型装备制造集团以下简称“某制造集团”典型痛点很鲜明维修手册有几十本分散在不同部门老师傅的维修经验没有沉淀出了问题只能靠电话到处问新员工培训周期长故障排查上手慢。这个项目的实施过程非常典型提炼出来大概是四步第一步知识盘点与清洗。我们和客户的知识工程师一起把所有故障相关的文档收集起来包括设备手册、维修记录、历史工单、常见故障案例。这一步的顽疾是文档格式极其混乱有PDF、Word、Excel表格还有大量扫描件。我们借助OCR识别加人工复核把内容统一成结构化文档耗时大概是整个项目周期的三成。千万不要低估这一步的工作量后面问答效果好不好八成取决于这一步做得干不干净。第二步建立“故障案例库”问答对。客户维修场景中最有价值的不是设备手册而是历史故障是如何发生、如何排查、如何解决的。我们召集了几位资深维修工程师通过访谈提炼出两百多个高频故障案例每个案例写成标准问答对包括故障现象、可能原因、排查步骤、维修建议。第三步上线RAG并嵌入工单系统。维修工在工单系统里输入故障描述我们的引擎自动返回维护建议并附上来源文档。关键点在于系统返回的建议是给“人看”的不是直接自动执行所以维修工保留最终判断权。这一点在制造业客户中特别重要因为老师傅们有很强的专业自尊心一旦系统直接给出“接管”指令反而会引发抵触。第四步持续运营迭代。项目上线后我们搭了一个每周数据回顾机制看哪些问题命中率低哪些问法没有覆盖到然后由客户内部的知识管理员补充内容。效果方面几个关键指标很能说明问题维修工搜索故障资料的平均耗时从过去大约8分钟降到40秒左右故障一次性解决率提升了约27%新员工培训周期缩短了近三成。客户CIO在“凌云奖”评审访谈环节里主动提供了这些数据这在评奖现场确实很有说服力。3.2 零售连锁智能巡检与经营助手另一个获奖的支撑案例来自零售连锁行业客户叫“某连锁零售”全国有几百家门店。他们的需求不像制造业那么“重”但非常碎片化。最核心的场景是两个。第一是门店巡检以往靠区域督导去门店拍照、填表格、打勾效率低且主观性很强。第二是经营分析门店的经营数据分散在Excel、POS系统和手工报表里店长想看个“本周环比为什么下滑”都费劲。我们的方案拆成两条线巡检自动化门店现场的货架陈列照片上传后通过图像识别模型自动判断货架是否饱满、价签是否对应、陈列是否符合标准结果回传到巡检系统生成整改工单。这里有个技术挑战是门店带宽差、终端算力弱所以我们在端侧跑一个小模型做初步分类只把置信度低的图片上传到云端大模型二次判断兼顾了速度和成本。经营问答助手把POS数据、库存数据和会员数据接通到分析引擎店长用自然语言提问例如“上周末饮品销量为什么比前一周跌了”系统自动拆解出销量、天气、促销活动、竞品动向等维度生成一份带归因建议的周报摘要。这里的实施经验是零售客户特别在意“今天能不能用起来”他们没耐心等你三个月打磨所以我们采取了两周出MVP最小可行产品的策略。先上巡检模块人工打标几百张图片快速跑通经营问答先做三个高频问题模板随着使用再扩展自由问答。事实证明这样的节奏是对的门店早一天用上早一天反馈我们也能更早拿到真实数据做迭代。3.3 一条可复用的POC验收模板很多团队在POC概念验证阶段翻车问题往往出在前期的评估标准没定清楚。这里分享一条我们实战沉淀下来的POC验收模板几乎适用于所有企业级AI项目选场景挑一个效果好量化、容错空间相对大的场景。比如知识检索、报表生成而别一上来就选“自动报价”“自动发邮件”这种高风险动作。定基线先测量当前人工处理该场景的表现比如平均响应时间、解决率、错误率。没有基线就没有对比后面做得再好也没法证明是系统的功劳。设指标明确经过AI改造后希望达到的目标例如“检索响应时间≤30秒”“答案准确率≥85%”“用户满意度≥90分”。指标要能直接抽取不能靠感觉打分。做盲测把旧方案和新方案的结果打乱顺序让真实业务人员盲打分。这一步可以过滤掉“因为是自己团队做的所以觉得好”的偏差。定门槛只有当盲测结果达到预设门槛时项目才进入规模化交付阶段。不要因为销售压力而放低门槛翻车的代价远高于丢单。这套模板的核心是把感性的“看起来不错”变成可数字验证的“确实更好”。评奖的客户访谈环节只是个放大器真正的前提是你的产品确实经得起这套标准检验。4. 组织效率拿奖不是一次冲刺而是常年跑出来的4.1 版本节奏与研发纪律获奖这种东西很多人以为是项目组在评审前突击一个月的结果。以我们这次的经验看恰恰相反。真正让客户在访谈里给出好评的是过去一年里一百多个版本迭代积累下来的稳定性。我们的研发纪律比较朴素但执行得很彻底双周迭代每两周发布一个小版本功能增量控制在可评审的范围内。太小的发布会让客户觉得没变化太大的发布容易引入风险。每个版本三件套一份变更日志、一份升级脚本、一份回滚方案。缺任何一样都不允许对外发版本。这三件套看着不起眼但很大程度上决定了客户对你专业度的评价。每月一次稳定性演练模拟极端情况比如某个服务挂了、数据库慢查询拖垮接口训练团队快速定位和恢复。我们有个很直观的感受当客户知道你的产品能像一个成熟开源项目那样按节奏发布、正常升级、出了问题有回滚方案时他们会主动参与共创而不是和你处于一种“甲方防乙方”的对立状态。4.2 复盘会怎么开才有效果企业服务团队很容易陷入一种恶性循环出问题-互相甩锅-解决完-下个问题继续出。我们的复盘机制没那么复杂但有两条原则是硬性的只问“为什么会发生”不问“谁该负责”。责任的事后面单独聊复盘会只谈系统的漏洞和流程的缺失。这样大家才会愿意暴露真实问题而不是想尽办法掩盖。每个事故都要变成一条改进项和一篇案例。改进项进下个版本的发布清单案例则归档进团队内部的知识库新同事入职培训第一周的任务就是读“事故集”。举个例子今年我们出过一个不大不小的故障。某客户的升级脚本在导入新版知识库时没有校验向量索引和新文档的映射关系导致一部分问答突然检索不到内容。客户当场就发现了问题场面一度很难看。复盘走了一遍发现根源不是脚本写错而是发布流程里缺少“数据一致性自检”这一环。后来我们在所有版本的发布流程里加了一个固定步骤导入新数据后自动跑一遍抽样查询确认Top3结果里至少有一个命中预期片段否则直接阻断发布。从那以后这类问题再没出现过。这种朴素的“把事故变成资产”的做法短期看是增加工作量长期看却是降低整个团队的返工成本。评审团不会只看你“成功案例”里做得有多好他们更关心那些“看似差点崩掉但被你接住”的时刻——因为这才是真实的企业服务。5. 经验型避坑指南这一年我们解决的几个典型问题5.1 大模型幻觉在知识问答里怎么压到最低很多团队一开始做大模型应用最大的心理障碍就是“模型会编造答案”。尤其在企业知识库场景一个编造的维修建议或者一个不存在的政策条款都可能引发严重后果。我们把幻觉率压到内部评测的2%以下主要靠三招检索强约束模型生成答案前必须从给定的检索片段中提取信息而不是依赖自己的“记忆”。做法是在提示词里明确“只基于提供的资料回答”同时在检索质量上下功夫相关内容找不到就不要硬答。引用强制每个回答都要挂上来源文档编号或段落号。如果模型生成的答案找不到对应引用系统直接判定为生成异常重新生成或转人工。拒绝策略当检索结果的置信度低于阈值时系统明确说“当前知识库中未找到相关信息建议转人工”。宁可承认不知道也不能给一个漏洞百出的回答。实际效果验证下来这三招组合基本堵住了幻觉的大部分来源。客户第一次看到系统说“未找到相关信息”时往往不会觉得产品弱反而会觉得这个系统很诚实、很可靠。5.2 Agent“看起来很美”时怎么分阶段落地Agent是今年最热的方向但也是最容易“演示惊艳、生产翻车”的方向。我们在一个客户那里尝试过让Agent自动完成“客户询价-生成报价单-发送审批”的完整闭环结果在一次测试中Agent因为读取了错误的产品目录给客户报了低价差点造成实际损失。好在那是在POC阶段没有酿成严重后果。教训很明确Agent的能力要逐步放开权限边界要严格设置。我们的原则是第一阶段Agent只能查不能写。查询天气、查库存、查订单状态随便试。第二阶段Agent可以写但只能写入草稿或待审批状态。比如帮你生成一张报价单但必须人工点击“提交”才会进入流程。第三阶段在客户充分信任、沙箱环境验证充分后才放开自动执行并且保留监控熔断机制。这是个老生常谈的建议但确实是用真金白银换来的。宁可落地的速度慢一点也别让客户对Agent的信任度崩盘。信任一旦崩了再好的技术也很难救回来。5.3 私有化部署环境里的性能与兼容问题企业级客户里相当比例要求私有化部署不允许数据出内网。这就带来一个现实问题客户服务器配置往往不高还要跑大模型推理。我们的应对策略分三层模型层优先选择7B到14B规模的开源模型并启用量化方案如AWQ、GPTQ用较小的精度损失换取数倍的推理速度提升。实测下来在客户的CPU-only服务器上7B量化模型配合优化过的检索链路也能达到可用的响应速度。推理层部署时启用批量推理和KV Cache复用对高频问题做结果缓存避免同一个问题反复跑模型。这一步优化空间很大某些场景下能让单卡吞吐量翻倍。架构层把“小模型处理琐事大模型处理难题”作为默认策略。分类、意图识别、实体抽取这类任务用一个几百M的小模型做真正需要语义理解的长文本生成才调用大模型。这里想提醒的是做私有化交付不止要懂算法还要懂部署。客户不会因为你的产品用了最新的大模型就容忍一台GPU服务器必须用满三个月才能跑起来。让产品适配客户现有的IT环境比逼客户为你的模型买单更实际。最后再说点个人体会回看这次拿到的几个奖我最深的体会不是“我们技术多牛”而是“我们踩过的坑足够多且每次都没白踩”。整理评审材料的过程本质上是一次系统的产品自查它逼着我们把每个功能点、每个客户案例、每个效果数据重新过了一遍也让我们更清楚下一阶段该把力气花在哪里。如果你想申报类似的行业奖项我的建议很简单不要把时间浪费在打磨申报材料上要把时间花在让客户真正用出效果上。访谈环节里客户发自内心的一句“他们确实帮了我们很多”比任何措辞精美的PPT都有杀伤力。之后自然就会轮到你说那些奖杯的话了。
