人工智能落地

人工智能落地 — 是把模型嵌进一个已经在跑的流程里，而不是在它旁边另起一套系统。模型读取公司的数据、从中找出规律并给出决定；执行这个决定的动作，则由流程所在的那套系统来完成——CRM、ERP、仓储程序、收银台、门户、即时通讯。

因此项目不是从挑模型开始，而是从四个答案开始：有哪些数据、它们是什么状态；需要做出什么决定；由谁、用什么去执行这个决定；用哪个数字来看出情况变好了。缺了其中任何一个，模型就只是又添了一个没人负责的数据源。

哪里不需要 AI。 如果一条规则一行就能写清——「库存低于五件，通知采购」——那就把它写成规则：更便宜、可预期，而且能逐行核验。AI 适用的地方是：判断依据有几十条、还会随时间变化，而人一直以来都是「凭眼睛」在定：给咨询分类、估计需求、找出不寻常的操作、从自由格式的文档里抽取字段。

采集来的数据还不能直接用：同一个商品有三种叫法、计量单位互相搞混、一半的记录缺必填标识，还有一部分行是同一笔操作的重复。用这样的数据集训练出来的模型，只会把混乱复现一遍，而不会找出规律。

AI 处理 在这里覆盖三件事：把记录统一成同一种形态、在缺失的地方补上标识，以及把对象归入原始数据中并不存在的类别。

• 规范化 — 日期、数字、计量单位、电话、地址和登记信息的统一格式
• 名称匹配 — 「VVGng 电缆 3x2.5」「VVG-ng 3*2.5」和「vvgng 电缆 3x2.5 GOST」被归并为同一个商品条目
• 补全缺失 — 缺失的类目、品牌或计量单位，可根据卡片上的其他字段推断出来
• 分类 — 商品归入某个组，咨询归入某个主题，付款归入某个费用科目，往来单位归入某个分层
• 特征抽取 — 从描述里提取出各项参数：容量、重量、功率、成分、保质期
• 重复项检测 — 同一往来单位的两张卡片、或同一批到货的两份单据，靠字段组合来发现，而不是靠字符串完全相同
• 矛盾校验 — 库存为负、发货日期早于下单日期、各行金额之和与单据合计对不上

动作： 有把握的更正自动应用，并连同原值写入日志；有疑问的则汇成一份清单交给台账责任人确认，而不是一封一封发邮件。

为什么这是一项独立的工作

数据质量不是项目开始前的一次性大扫除，而是一个持续的过程：台账每天都在增加，供应商会改价目表的格式，业务员宁可重新建卡也不去搜已有的那张。因此清洗的规则和模型与数据一起活在系统里，并在每一次加载时生效。

每一次更正都有作者——某条规则或某个模型——以及时间、旧值和新值。这不是官僚主义：没有这段历史，就没法弄清上个月的报表为什么今天显示的是另一组数字。

结果

台账不再枝蔓丛生，按商品组和费用科目出的报表彼此对得上，数据准备也不再吃掉任何一个分析项目的大半工期。

普通报表只回答别人问它的问题：按月的收入、按分支机构的销售、按仓库的库存。问题由人提出，因此你看到的恰好是有人想到要看的那一部分。

AI 处理 在这里把方向反了过来：模型自己去翻各个切面，把指标表现与预期不符的那些带回来。不是「给我画张图」，而是「这三个地方发生了不寻常的事，而且它与这些因素相关」。

智能分析都做什么：

• 分群 — 客户、销售网点和商品按实际行为分组，而不是按事先想好的类别
• 指标拆解 — 收入下滑被拆解为各类目、各分支机构、各渠道和客单价的贡献：一眼就能看出到底是哪一块掉了
• 事件之间的关联 — 订单、客户或网点的哪些特征，更常伴随着拒收、退货、逾期付款或客户流失
• 风险评估 — 订单被取消、账单未按时支付、客户不再购买的概率
• 注意力排序 — 一份需要排查的对象清单，按可能的损失排序，而不是按字母排序
• 用日常语言提问 — 用文字向数据提问，答复中必须附上数据来源和时间范围

动作： 发现不会停留在看板上——它会变成一项带接收人和时限的任务：去查那个下滑的网点、联系风险组里的客户、检查退货上升的那个类目。

日常，指的是那些一天重复几十次、需要注意力却不需要专业技能的操作：把数据从邮件抄进卡片、给付款归费用科目、指派执行人、检查单据是否齐全、设置状态。

AI 处理 用在输入不规范的地方：邮件是用文字写的、单据是别人的格式、申请每个客户的说法都不一样。模型把这样的输入整理成结构，之后就交给普通规则去处理——可预期、可核验。

转为自动执行的操作：

• 分拣来信和申请
• 判定咨询的主题和紧急程度
• 指派执行人和时限
• 创建客户卡片和商机
• 从文档中抽取数据
• 把单据与订单和发票核对
• 把付款归入费用科目和合同
• 检查一套单据是否齐全
• 就常规询问生成答复
• 翻译文本并统一成同一种形态
• 按模板准备对账单和证明
• 根据描述填写商品卡片的字段
• 申请启动前检查其完整性
• 给任务队列排优先级
• 按班次、按天、按区段出简报
• 按事件向责任人发送提醒

动作与结果： 操作由系统完成，并连同操作者、时间和原值写入日志。员工则从录数据转向处理例外——那些模型没有把握、或者出错代价很高的情况。

数据： 送货单、发票、验收单、合同、规格书、付款委托书、申请书、设备铭牌、带附件的信件。格式五花八门：pdf、手机拍的照片、扫描件、导出文件、纸质原件。

AI 处理： 文字识别、判定单据类型、抽取字段和表格部分、把行项目与商品台账匹配，以及把单据与订单、合同或往来单位关联起来。每一个字段都会返回一个值和对它的置信度。

抽取什么：

• 双方的信息 — 名称、登记编号、地址、银行信息
• 单据的编号与日期 ，以及指向合同、发票和订单的引用
• 表格部分 — 行项目、数量、单价、金额、税率
• 合计 — 不含税金额、税额、应付合计、币种
• 期限与条件 — 付款期限、供货条件、质保、违约金
• 签字与盖章 — 只判断有无，不判断真伪：真伪属于具有法律效力的单据流转的范畴

动作： 单据与订单和发票做核对，差异汇成清单，然后单据要么过账，要么转给某位具体员工去排查。 结果： 录入单据不再是一个专门的岗位职责，而差异在付款之前就被发现，而不是月结时才发现。

边界划在哪里

识别在任何一套单据上都做不到百分之百准确——也不该做到。意义在别处：系统会指出哪些字段它有把握、哪些需要人来确认。操作员只核对被标出的那几个字段，而不必把整份单据敲一遍。

原件质量差，不构成悄悄出错的理由：照片模糊、页面被裁掉、规格书缺了第二页，都会被明确标出，并注明原因退回给发件方。

结果

处理速度不再取决于来件量的多少，而财务和采购在一份清单里就能看到各单据的状态，不必再去翻各个员工的邮箱。

数据： 邮件、网站上的申请、即时通讯里的消息、通话转写、支持聊天的往来记录、评价和评分。这些全是自由格式的文本，至今都要由人来读、来分拣。

AI 处理： 把咨询归入主题和子主题，判定紧急程度和情绪，从文本中抽取订单号、商品名称、地址和其他实体，并把咨询与客户历史关联起来。就同一件事的重复咨询会被合并为一个案例。

动作： 申请带着已填好的字段进入对口小组的队列，响应时限按紧急程度计算，重复咨询会被提高优先级，客户则收到带编号和预计时限的确认。

结果： 咨询不再躺在公共邮箱里等到第二天早上，而负责人看到的不是「投诉很多」，而是一个结构：哪些主题的量在增长、哪里的响应时间在变长、哪些产品在产生重复咨询。

把整条流一起看，能得到什么

单条咨询讲的是一个案例，整条流讲的是产品和流程。按主题对一段时间做分类，能看出到底是什么在引发疑问：说明书不清楚、商品描述有误、下单流程某一步出故障、某家配送服务在拖延。

因此主题不是拍脑袋定的：先由系统按语义自动把咨询分组，再人工修订这些分组并固化为一份台账。此后它与产品一同演进，新的分组由系统来建议。

机器人不是一个模型，而是几个相连的部件。这样拆开有实际意义：每个部件都有自己的失效方式、自己的指标和自己的修复办法。

• 理解请求 — 这个人想做什么、他说出了哪些参数：订单号、日期、商品、地址
• 知识检索 — 挑选出用来生成答复的那些文档片段和记录
• 访问系统 — 一组被允许的操作：查看订单、创建申请、修改配送日期。每一项都写得很明确；机器人没有任意动作可做
• 组织答复 — 模型严格依据检索到的内容和系统返回的数据来组织答复；不在来源里的东西，不会出现在答复里
• 发送前校验 — 答复与来源核对，动作与用户权限和额度核对
• 转交人工 — 升级规则：置信度低、重复提问、负面反应、属于受限清单的主题
• 日志 — 问了什么、找到了什么、机器人做了什么、依据是什么。没有这个，投诉就无从复盘

接入渠道包括网站和个人中心、即时通讯、邮件、带语音识别的电话线路、内部门户和员工工作台。其中的逻辑始终一致：渠道改变的是输入形式，而不是机器人被允许做什么。

答复是从哪里来的

机器人并不「记住」贵方的文档——它在提问的那一刻去检索，并按检索到的内容作答。因此制度一更新，上传之后立即生效，不必等模型重训；也因此每一条答复都有出处。

机器人是怎么上线的

第一件事是汇集一批真实问题——来自往来信件、咨询和内部群聊。上线之前先在这批问题上检验机器人：答复与来源逐一核对，错误按原因逐条分析。之后才对用户开放，通常先开放给一个小组。

内部助手与面向顾客的机器人，区别在源数据：它处理的是企业信息，而且是在某位具体员工的权限之内。同一个问题，仓管员问和财务总监问，得到的答复不同——因为他们能访问的文档不同。

助手在工位上做什么：

• 依据制度作答 — 怎么办理、谁来审批、期限多久、用哪份表单，并附条款引用
• 就某个对象汇总要点 — 客户、商机、合同、订单、设备：历史、未解决的问题、临近的时限
• 起草文稿 — 信件、报价单、咨询答复、任务描述、会议纪要
• 替员工做记录 — 把通话或会议的结果转成任务、时限和卡片更新
• 提交申请 — 提给人事、采购、技术支持：字段从对话中填入，而不是去填一张二十个字段的表
• 生成班次简报 — 这段时间该区段发生了什么、还有什么没结、什么需要拍板

结果： 员工把时间花在工作上，而不是花在找文件、回忆制度和填表上。助手不替人做决定——它只是把准备工作那一部分拿掉。

企业知识很少集中在一个地方：制度在一个文件夹里，合同在第二个，技术文档在第三个，而一半的答案在往来信件里。在这里按文件名检索是不管用的，因为人要找的不是文档，而是答案。

数据： 制度和文件、合同和附件、技术与项目文档、操作规程、已解决咨询的案例库、纪要、台账、往来信件归档——每一项都注明所有者和访问级别。

AI 处理： 文档被拆成片段，每个片段按语义建索引；问题匹配的是片段，而不是标题。答复由检索到的内容组装而成，并附引文以及指向文档、页码和版本的引用。

动作与结果： 员工几秒钟就能拿到带出处的答复，而不必挨个去问同事；有争议的情况可以对照引文核验；过期文档也一眼可辨——如果答复来自两年前的版本，答复里会直接写明。

什么让知识库真正管用

• 统一入口 — 各数据源接入索引，而不是被人工搬进一个新仓库
• 版本与日期 — 每个片段都知道所属文档的版本；现行版与归档版分开
• 权限继承 — 权限从源系统继承，因此索引不会变成绕过访问限制的手段
• 按事件更新 — 文档一改就立即重建索引，而不是每月按计划跑一次
• 反馈 — 「这条答复没帮上忙」可以在界面里标记，并连同问题一起进入复盘
• 缺口可见 — 找不到出处的问题会汇成一份清单：这就是「该补写哪份制度」的任务书

知识库不做什么

它不取代文档流转系统，也不成为事实的唯一来源：具有法律效力的文档仍然留在它被签署和保存的地方。索引是找到它并引用它的手段，而不是一份自行其是的副本。

申请以自由格式、通过任意渠道进来：邮件、消息、网站表单、电话、附件。落地之前，要由人来读它、把数据搬进系统、判定类型并指派执行人——这一套要花几分钟到几小时的排队等待。

AI 处理： 判定申请类型、抽取字段——对象、地址、时限、联系人、合同号——检查完整性、评估紧急程度，并把申请与客户及其历史关联起来。缺失的信息会在同一渠道里自动追问。

动作： 申请以填好字段的形态在系统里建单，按规则指派小组或执行人，设定时限，并发出带编号的确认。就同一件事的重复申请会被关联起来，而不是再生成第二张单。

结果： 执行人拿到的是一张完整的单，可以直接开工，而不是先去补细节。从进来到指派的时长，不再取决于谁在什么时候打开了公共邮箱。

一张申请的全程

要配置好什么

• 申请类型台账，以及指派执行人的规则
• 每种类型的必填字段——否则追问机制不工作
• 按合同和优先级设定的响应时限
• 就同一件事合并重复咨询的规则

模型总会出错——问题在于多久错一次、错在哪里、代价多大。因此每一次落地都有两组数字：模型自身的质量，以及流程发生的变化。前者工程师关心，后者业务关心，而两者并不会自动一致。

• 准确率与召回率 — 按每个类别分别统计，而不是用一个平均数：一个罕见但昂贵的类别，比一个常见类别更重要
• 自动决定占比 — 在设定的置信阈值下，有多少操作是无人参与完成的
• 更正占比 — 有多少自动决定被人撤销或修改了
• 操作时长 — 从进来到完成，与落地之前的基线水平作对比
• 错误的代价 — 漏判要付出什么、误报要付出什么；阈值按这个比值来调，而不是按指标好不好看
• 数据漂移 — 输入数据构成发生变化，导致系统一个字没改，质量却在下降

置信阈值是一个可调的旋钮，而不是一个常数。调高它，公司得到的自动化更少、错误也更少；调低则相反。取值按具体流程中错误的代价来定。

面板里能看到什么

上线之后的运维

模型不是一次性交付。数据在变：新商品、新的咨询主题、新的单据格式、新的供应商都会出现。因此项目里要预留：在新数据上定期做质量检验、按计划或按阈值触发重新训练，以及复盘那些被人更正过的案例。

客服的更正是最有价值的训练材料：它们会被汇成一个单独的数据集，用于下一轮训练。这样系统是在自己的工作上变好，而不是在别人的数据上。