始终没能投入生产的 AI 试点：数据与运维上缺了什么

试点是成功的。在一批人工挑选的文档上，模型抽出了字段、给工单分了类，也说服了当初提出需求的人。几个月过去，它仍然在沙箱里跑着样本数据，没有人说得清要把它接到真实队列上还需要做些什么。

这个缺口靠换模型补不上。演示回答的是模型能不能读懂一份文档。生产要问的是每一份文档会怎样——包括扫描件、被转发的邮件串，以及模型弄错的那一份——而且所用的数据可能从来就不被允许送达试点所用的那个服务。

演示证明模型读得懂，生产环境要过问每一份文档

2015 年，Google 的 Sculley 等人写道，真实世界的机器学习系统中只有一小部分由机器学习代码构成，而所需的周边基础设施庞大且复杂。语言模型管道也是同样的形状，只用那一小部分搭起来的试点，周围没有任何能让它在生产环境中运行的东西。

把试点拥有的东西和生产队列需要的东西摆在一起，缺失的工作就成了一张清单：

• 评估：试点是几个有人看着满意的示例，生产要的是一份按字段约定了合格线的标注集
• 数据：试点用的是导出文件、样本或托管 API，生产面对的是可能不得离开你基础设施的实时数据源
• 输入：试点是干净的 PDF，生产面对的是扫描件、邮件串、附件，以及会不打招呼就变的模板
• 输出：试点是给人读的文本，生产要的是由另一个系统消费、且该系统必须信得过的记录
• 运维：试点是一次一个用户，生产要应对峰值流量和模型服务器宕机，还要有上线后的负责人

动模型之前，先写好验收集

缺失的第一件制品，是一份由真实文档组成的标注集，每份文档都附有它应当产出的答案。没有它，每一次改提示词或换模型，都由当天看输出的人说了算，而试点也无法通过一道从未被写下来的关卡。

Google 的 Rules of Machine Learning 把测量放在模型之前：Rule #2 就是「首先，设计并实现指标」。对于信息抽取和工单分派，指标不是给整份文档打的一个分数：

• 从真实流量中抽取文档，时间跨度要足够长，覆盖月末、节假日，以及使用古怪格式的发送方
• 让如今在做这项工作的人来标注，其中一部分由两个人各自独立标注，并把他们之间的分歧当作规格说明里的缺口，而不是噪声
• 每个字段单独打分，因为日期错了，不会因为名称对了就被平均掉
• 按字段、按文档类型写下合格线，并明确哪些字段可以自动化、哪些始终交给人处理
• 在同一份数据集上测量现有的人工流程，让模型与真实的基线比较，而不是与完美比较
• 留出一部分数据，不让任何调提示词的人接触，这样最终分数就不是在提示词所拟合的那些示例上测出来的

数据不能出边界，改变的是架构，而不只是供应商

如果试点是在托管模型上、用样本、合成数据或经人工审核放行的文档搭起来的，而真实数据又不得送往外部提供方，那么试点的结果就无法照搬：部署在内部的模型可能是另一个模型，也可能是同一个开放权重模型、但量化方式和推理服务设置不同；无论哪种情况，它的质量都必须在验收集上重新测量。

模型是最容易想到要搬进内部的组件，但不是唯一的一个，因为语言模型管道会把数据复制到模型调用之外的更多地方：

• 推理服务器和模型权重，版本均已锁定
• 嵌入向量和向量索引：它们由文档派生而来，必须像文档本身一样受到保护
• 日志里的提示词、输出和追踪记录，因为被记入日志的提示词包含构建它所用的文档
• 验收集、标注工具和复核队列
• 监控和错误追踪：以托管服务形式运行时，它们就成了数据在外部的一份副本

在日志必须离开受限区域的地方，脱敏能起作用。Presidio 是一个起源于 Microsoft 的开源框架，用于检测并匿名化文本中的个人数据；它的文档写明，由于检测是自动完成的，无法保证能找出所有敏感信息。脱敏缩小的是暴露面，它不能取代把数据留在内部。

输入是不起眼的那一半：扫描件、会话串和附件

试点收到的是文档；生产环境收到的是发送方发来的任何东西。在调用模型之前，管道必须先把这些东西变成能追溯回原处的文本：

• 扫描件和照片要经过 OCR，而 OCR 在数字和表格列上犯的错，会以看似确凿的文本到达模型
• 邮件和工单的会话串里夹带着引用的回复、签名和免责声明，所以最新一条消息必须和历史内容分开
• 内容往往在附件里，而每种格式都需要自己的抽取路径
• 每个分块都保留自己的来源——文件、页码和偏移量——这样每个抽取出的字段都能追溯到它所出自的原文片段
• 重复项，例如被转发的通知或通过邮件重新打开的工单，要在变成两条记录之前被检测出来

长输入需要单独对待。在 2024 年发表于 TACL 的 Lost in the Middle 一文中，Liu 等人表明，对于他们测试的模型，当相关信息位于输入上下文的开头或结尾时，性能往往最高；当它位于长上下文的中间时，性能会显著下降。作为默认做法，按章节切分长文档、并在每个分块上保留来源，比假设模型会均匀地读完整个上下文更稳妥；而对你的文档来说哪种情况成立，由验收集来说明。

结构化输出需要 schema、校验器，以及安放错误答案的去处

约束解码把模型的输出限定为符合 schema 的 JSON：vLLM 以 structured outputs（结构化输出）的形式支持它，llama.cpp 则通过 grammars（语法）支持。它能固定记录的形状——前提是在后端所支持的 schema 特性范围之内，并且生成没有被 token 上限截断——却固定不了记录的真实性：一条格式完好的记录，照样可能带着错误的日期。

真实性要在模型之后检查，由业务方已经信任的代码来做：

• 类型与格式检查：日期、币种，以及带校验位的标识符，例如 ISIN
• 跨字段规则，例如期间结束日期不能早于开始日期
• 对照公司已经在维护的参考数据做查询，例如已知的金融工具或客户
• 与原文一致：每个抽取出的值，在规范化之前，都必须出现在它所引用的原文片段里

模型自己的置信度是一道薄弱的关卡。OpenAI 于 2023 年发布的 GPT-4 Technical Report 显示，在一个多项选择基准上，预训练模型的校准程度很高，而后训练降低了校准程度。模型自报的确定性或某个 token 的概率，是一个需要拿验收集去检验的信号，而不是一个默认就可以信任的阈值。

任何一项检查没通过的记录，都进入复核队列，而不是进入下游系统。这个队列本身就是一个产品：它需要一个负责人、一份以复核人员工时计算的容量计划、在每个字段旁边展示的原文片段，以及能回流进验收集的更正。

工单和文档是模型的不可信输入

客服工单是公司外部的人写的文本，而文档里可能带着发送方有意放进去的指令。OWASP Top 10 for LLM Applications 2025 把提示词注入（Prompt injection）列在第一位，其中包括间接注入：指令随模型处理的外部内容（例如某个网站或某个文件）一起进入。

同一份清单中有三项，可以转化为文档处理管道的设计规则：

• 提示词注入（Prompt injection）：把每份文档和每条工单都标记为不可信内容，并与指令分开，指令放在发送方无法编辑的模板里
• 不当输出处理（Improper output handling）：在任何系统据此采取动作之前先校验模型输出，就像校验来自用户的输入一样
• 过度代理（Excessive agency）：只给管道完成任务所需的最小权限，让读工单的模型无法关闭账户或发起付款

OWASP 还指出，目前尚不清楚是否存在万无一失的提示词注入防范手段。真正起作用的是输出检查和权限限制，而不是提示词的措辞。

把模型、提示词和解析器锁定为同一个版本

管道的行为，是若干个各自独立变化的制品共同作用的结果。把它们当作一次发布来对待，并在这次发布产出的每一条记录上存下它的标识符：

• 以校验和标识的模型权重，连同量化方式和推理服务器版本
• 提示词模板、输出 schema 和解码参数
• OCR 引擎、分块规则和校验器
• 该发布版本打分时所依据的验收集版本

锁定版本并不能让输出完全一致。Thinking Machines Lab 在 2025 年 9 月表明，推理服务器在温度为零时，对同一个提示词也可能返回不同的补全，因为一个请求的结果取决于有多少其他请求与它共处同一批次；同一篇文章还表明，批次不变（batch-invariant）内核能消除这种差异，但要付出速度上的代价。除非服务器运行的是这类内核，否则可复现性意味着每次发布都重跑验收集并比较分数，而不是指望得到一模一样的文本。

运维：容量、队列，以及模型服务器宕机的那一小时

容量按 token 规划，而不是按文档。要在真实流量上测量输入和输出长度的分布，因为一个长附件的开销可能抵得上许多条短工单，而生成时间随输出长度增长。

推理服务系统会把请求组成批次，让加速器保持繁忙。在 SOSP 2023 上发表的 vLLM 论文中，Kwon 等人报告：与他们评估的系统相比，对注意力的键值缓存做分页管理，在相同延迟水平下将吞吐量提升了 2 到 4 倍。更大的批次提高吞吐量，同时也提高每个请求的延迟；后台队列吸收得了这部分延迟，交互步骤吸收不了，所以两者要分开：

• 交互式工作，例如客服人员正在等待结果的工单分诊，有自己的容量和延迟目标
• 批处理工作，例如夜间抽取，放在一条能吸收峰值、可以暂停的队列上
• 在接收环节与模型服务器之间设置背压：有界队列加并发上限，让突然涌入的文档排队等待，或带着重试信号被拒绝，而不是压垮服务器
• 以文档为键的幂等处理，让崩溃之后的重试不会生成第二条记录
• 模型服务器不可用时降级到人工流程，让工作等人来处理，而不是凭空消失

正是降级方案让开启管道这件事可以撤回。今天已有的人工流程始终是兜底，管道逐个字段地从它身上接走工作，而不是在某一天整体取代它。

监控答案，而不只是服务器

服务器仪表盘告诉你管道有没有作答，却不告诉你答案对不对；而一个在新模板上质量退化的模型，延迟照样不变。监控抽取或工单管道要两者兼顾：

• 按字段、按文档类型、按发布版本统计：进入复核队列的比例，以及复核人员的更正
• 定期抽样自动处理的记录，由人对照验收标准重新检查
• 输入漂移：新的发送方、新的模板、语言构成以及文档长度
• 按规则统计的校验失败，它们可能在准确率指标变化之前就暴露出新的格式
• 按文档类型统计的 token 数、加速器机时和排队时长，与每个阶段的延迟放在一起

NIST 于 2024 年 7 月发布的 Generative AI Profile（NIST AI 600-1），按照其 AI Risk Management Framework（AI 风险管理框架）的四项职能来组织这项工作：治理、映射、测量和管理。名称本身不如它带来的后果重要：上线后的测量是一项有明确名目、配备了人手的工作，而不是试点团队有空时才做的事。

按字段、按文档类型逐步上线：影子模式、辅助模式，再到自动化

在某一天把管道对所有内容一次性开启，会把所有风险绑进同一个事件。分阶段上线则把它们分开：

• 影子模式：管道处理线上流量，但不写入任何地方，其产出的记录与人工产出的结果进行比对
• 辅助模式：管道预填，由人确认每一条记录，更正按字段计数
• 按字段、按文档类型开启自动化，仅限在线上流量中持续达到合格线的部分，其余一律仍需复核
• 按文档类型切回辅助模式的开关：当某个受监控的比率越过其限值时，运营负责人无需另行审批即可使用

一个文档读得很好、却始终没能投入生产的试点，并不是败在阅读上。它从来没有得到过一份要通过的验收集、一条允许它使用的数据路径、一个安放错误答案的去处，也没有一个在上线之后接手的负责人。

能交付这类工作的公司，先要你的文档，再问你偏好的模型

本文背后的问题——谁能把 LLM 管道部署进你自己的基础设施、并真正交付上线——有一个不需要供应商名单的判别方法。做这类工作的公司，在推荐模型之前会先问验收和运维：

• 要求在你的环境内或在你的数据协议约束下，审阅一批真实文档和工单的样本，包括质量差的那些，并询问目前的人工流程是怎么处理它们的
• 提议在做任何调优之前，先和你方人员一起建立验收集，并按字段设定合格线
• 列出数据会被复制到的每一个地方，从权重和索引，到日志、追踪记录、评估数据、复核工具和监控，并表明每一处都留在边界之内
• 把校验器、复核队列以及降级到人工处理的方案，和模型写进同一份设计文档
• 拿出一个把模型、提示词、schema 和解析器一起锁定的发布版本，以及按字段从影子模式推进到自动化的上线计划
• 说清楚上线后由谁运营管道、由谁复核抽样，以及模型服务器停机时找谁

每一项都是你在第一次谈话里就能问的，而含糊的回答说明试点缺失的那部分工作还没有被界定范围。

所以第一个问题不是在你的边界之内跑哪个模型，而是：你愿意接受哪些文档上的哪些字段自动化处理，以什么为衡量基准，以及校验不通过的记录由谁来接手。

除上文摘要中所述的生产集成之外，amBrain 可以公开证实的内容：amBrain 自 2019 年起做软件开发。我们有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。