数据接入与集成

20 分钟读完

7
第 II 部分 · 一次交付

数据接入与集成

FDE 的时间大多耗在集成上,而不是模型上;而一个干等数据的试点,可能把这些时间全耗在等待里。第一周就提交接入申请,在申请流转期间先用测试样本构建,并且先读上很长一段时间,再考虑写入。然后为每个连接器在客户方指定一位负责人,因为没人维护的集成,比模型坏得更早。本章最后给出一份第一天就能发出的数据接入申请。

7.1

这个阶段为了什么,又会怎样失败

上一章“划定范围与首个成果”定下的范围写明了一个工作流程、一个数字和一个日期。可是,在智能体能以可用的形式看到这个流程里的人所看到的东西之前,这些一样也建不起来。这就是本阶段的任务:拿到正确那几个系统的读取权限,把其中的内容变成模型能够据以推理的形式,并决定智能体能不能改动其中的内容、能改动什么。

做这份工作的人说,这就是工作的大部分。OpenAI 前线部署工程负责人 Colin Jarvis 说,“我们 FDE 把东西推上生产的时间里,几乎大部分”都花在“搭建数据(就是原始数据)和业务逻辑之间的翻译层,然后呃,把业务逻辑注入进去”上(Altimeter 访谈,2025 年 11 月;T4,供应商描述自己的做法)。Nabeel Qureshi 于 2015 年以 FDE 身份加入 Palantir,2023 年离开,他把同一份工作称为“数据集成,一个让大多数人昏昏欲睡的词”。它的第一步是“获得企业数据的访问权限,这通常意味着与组织里的‘数据所有者’谈判”(Qureshi,2024 年 10 月;T4,一位前员工的个人叙述)。

要清楚这些证据有多单薄。没有人测量过 FDE 的工时在集成和建模之间怎么分配。Jarvis 说的“几乎”大部分是自述,Qureshi 的叙述是一个人的回忆。独立证据指向同一方向,但测的是别的东西。RAND 访谈了 65 位从业者(RAND,2024;作为研究是 T1,但依据的是访谈,而且早于大多数团队使用大语言模型)。它列出的第二个失败根源是,“组织缺乏充分训练一个有效 AI 模型所需的数据”。第四个是,组织“可能没有足够的基础设施来管理数据、部署已完成的 AI 模型”。斯坦福数字经济实验室发现,“77% 的最难挑战是看不见、摸不着的成本:变革管理、数据质量和流程再造”(Pereira、Graylin 和 Brynjolfsson,2026 年 4 月;T2,一份只基于成功部署的草稿)。在它能够评估的部署中,有 59% 的数据“分散在由不同团队拥有的多个系统里”。接下来那句话才是要记住的:“然而,成功并不需要集中化。它需要的是接入。”

这个阶段会以三种方式失败,每一种都是发现得越晚,代价越大。

干等。团队申请权限,拿到一个工单号,然后在试点计时照走的同时用编造的数据做演示。Qureshi 说得很直白:客户会买“一个 8 到 12 周的试点,而我们把整整 8 到 12 周都花在拿数据权限上,最后一周手忙脚乱地凑点东西出来演示”(T4)。等权限到手时,已经没有时间去弄清真实数据会让原型出什么事。

过早写入。客户希望智能体直接更新记录系统,因为效率就在那里。团队在还不能可靠读取之前就答应了,而写入路径会带来审批、回滚和风险审查,这些都是试点扛不住的。

没人管的连接器。集成在交接那天还能用,但在客户那边没有归属,源系统下一次变动时就停了。背锅的是模型。

7.2

合成案例:三位审批人和一张旁路表

在这家保险公司的第 1 周。FDE 在第一周就提交了申请,要理赔系统的只读副本和文档库的访问权限,按需求挖掘阶段摸清的人名逐一发出。它需要三方审批:理赔系统负责人、IT 安全和数据保护官。每一方都有一个合理的问题:副本会增加多少负载,哪个身份从哪里读取它,以及哪些索赔人字段会离开公司、离开多久。第 5 天过去了,权限还没到。如上一章所述,负责人启用了数据条款,30 天的计时暂停,首席运营官同意先用脱敏导出的数据推进。

第 1 周到第 3 周。FDE 没有干等,而是根据脱敏导出的数据和在理赔员身边待的几个小时,构建了一批经过脱敏处理、形状与真实首次报损材料一致的测试样本。每份都有理赔申请表;大多数有照片;有些有警方报告或维修估价;很多还带着一串邮件往来或理赔员的备注。它们是故意做得这么难看的,因为真实的材料就是这样。扫描的 PDF 送来时是横着或倒着的,照片没有说明,邮件嵌套了三层回复,理赔员的备注里用的缩写从来没人写下来过。在从副本读取任何一个理赔案件之前,整条流水线已经在测试样本上端到端跑通。副本的读取权限在第 3 周到位。第一次在副本上运行,就暴露出几种测试样本漏掉的文档类型,以及一个在不同地区含义不同的状态码。

回写继续推迟。理赔总监希望把分派结果直接写进理赔系统,而 IT 早就说过,什么都不许往那里写。折中方案几乎不花什么代价:智能体把建议写到一张由保险公司自己团队拥有的旁路表里,理赔员现有的队列视图从这张表读取。这一段背后的模式是:Alpine Edge 建议在权限审批期间用脱敏的测试样本构建;The Register 报道说,回写到老旧的 NHS 系统“比读取更有挑战”;以及 Qureshi 把数据集成描述为与数据所有者的谈判。

整章靠三个选择撑起来。申请在第一周就提交了,发给具体的人,只要够用的最少权限。构建没有等它。输出落在客户已经在看的地方,也没有去碰那个他们承受不起出故障的系统。第四个选择,即你离开后由谁让它继续运转,放在最后讲。

7.3

接入申请是一场谈判

接入申请不是一张工单。它是请好几个人替你承担一份风险,所以要把它当作谈判,给每个人点头所需要的东西。

Qureshi 点出了你要谈判的两样东西(T4)。一样是政治因素:控制某个数据源的团队,常常靠“充当那个数据源的守门人”来证明自己存在的价值。另一样是实打实的:“数据访问上的拉扯,部分源于真实的数据安全顾虑”,Palantir 的应对是把控制措施直接做进集成层本身。两者都要认真对待。用写进申请里的控制措施回应安全顾虑。回应守门人,就给他一份差事:守着某个数据源的团队,天然就该负责连到这个数据源的连接器,而一个将要负责连接器的团队,有理由点头。

动笔写申请之前,先点出审批人的名字。需求挖掘应该已经为每个系统给出了能批准读取权限的人。实际中通常有三个:系统负责人(担心负载和稳定性)、安全部门(担心身份、网络路径和凭证),以及隐私或数据保护部门(担心哪些个人字段会流动、为什么、流动多久)。给他们每人发同一份文件,并在里面写明哪个问题归谁。

只要最少的,并且写成书面。一份要“理赔数据访问权限”的申请会被转给某个委员会。一份要四张具名表和文档库的只读权限、排除三个具名字段、通过一个服务身份、在客户网络内部、为期整个试点的申请,才会得到一个决定。你不会碰的字段,要和你会碰的字段列得一样仔细。

让安全部门在一开始就参与,而不是在最后。Alpine Edge 的前线部署交付计划说得很直接:“把安全和身份与访问管理(IAM)拉进需求挖掘;同时用脱敏的测试样本构建”。在第三周它又补充:“读写权限分离;凭证不进代码”(Alpine Edge,2026 年 8 月;T4,一家咨询公司的做法)。智能体以什么身份运行,是一项设计决策,而不是文书工作。本 wiki 关于智能体的限定范围凭证的页面讲了为什么智能体绝不应该借用某个人的权限。如果智能体要代表不同的用户检索文档,权限感知检索讲了为什么访问规则必须在检索之前强制执行,而不是在检索之后过滤。

同时申请一样更小的东西。副本是一个大请求。几百个近期案件的脱敏导出是个小请求,往往一位经理就能批,而且第一次演示和基线本来就需要它。两份申请在同一天提交。副本还在走流程时,有了这份导出,工作就不至于建立在编造的数据上。

一级一级往上爬。数据权限是分级的,每一级需要不同的审批:

  1. 你自己编写的合成数据。不需要任何人批准,也告诉不了你客户的任何情况。
  2. 脱敏的测试样本:真实的结构,编造的内容。
  3. 真实案件的脱敏导出。
  4. 对副本或报表库的读取权限。
  5. 对线上系统的读取权限。
  6. 写入权限,先写旁路存储,最后才写记录系统。

试点需要在第一周结束前到达第四级;这就是“交付开始之前”里的数据条款。大多数试点永远用不到第六级。在申请里把这一点写明;一位相信你会停在第四级的审批人,批得更快。

按日期升级,而不是凭感觉。把回复延迟的后果写进申请,写成发起人已经同意的一句话:“如果第 5 天之前读取权限还没到位,试点计时暂停,我们先用脱敏导出的数据推进。”日期一过,你就不是在求谁办事了。你是在报告一条规则被触发了,由发起人去催审批人。

7.4

等待期间用测试样本构建

一个试点是暂停还是停摆,区别就在脱敏的测试样本。用你已经能看到的东西来构建它们:脱敏导出的数据、你在需求挖掘时看过的屏幕,以及理赔员说出的那些文档类型。一套好的测试样本有三个特性。

  • 它有真实的形状。同样的文件类型,同样的字段名,同样的嵌套,以及同样的、把一个系统和另一个系统关联起来的标识符。
  • 它有真实的混乱。缺失的字段、重复项、混杂的语言、手写字,以及每个理赔员都在用、却没有任何文档定义过的缩写。优先仿造你跟随观察过的那些人上个月遇到的最糟情况。
  • 它标明了自己是什么。每个测试样本都标明是合成的,这样就没有人会在上面测量阈值。测试样本用来构建,绝不用来打分。

测试样本里只有你想到过的情况。RAND 引用一位受访者谈业务领导者的话:“他们以为自己数据很好,因为他们每周都拿到销售报表,但他们没有意识到,手上现有的数据可能满足不了新的用途。”RAND 还说,遗留数据往往是“出于合规或日志目的”保存的,而分析“往往需要大量关于事情为什么发生的背景,而不只是发生了什么”(RAND,T1)。理赔系统记录的是一个理赔案件发生了什么。它不记录理赔员为什么这样分派它,而那正是智能体需要的。要预料到,第一次在真实数据上运行,会弄坏测试样本没弄坏的东西,并为此预留几天,而不是几小时。

数据混乱能拦住的项目,比过去少了。斯坦福发现,它研究的部署中只有 6% 的数据“完全为 AI 准备就绪”,但有 91%“成功处理了非结构化数据,包括语音转录、扫描文档、图片、聊天记录和遗留代码”(斯坦福,T2)。作者自己给出了保留意见:样本“很可能低估了数据质量问题无法克服的情况”。所以应该把它理解为“成功的团队围绕混乱做了设计”,而不是一个承诺。围绕混乱做设计,意味着有一个解析环节,你要像测试模型一样严格地测试它;本 wiki 关于文档解析与摄取质量的深度解析讲了版面、表格和 OCR。

7.5

翻译层

权限给你的是行和文件,不是含义。Jarvis 的警告针对的是大多数团队走的捷径:“人们就像经常一上来就用 MCP,直接把 MCP 连接器插上去”。他说,他的团队“不得不一再去做”的,是“在两者之间搭一个差不多算是轻量的那种逻辑层,让模型借助它来最好地利用”数据(Altimeter,T4)。他称之为“元数据翻译层”,并指出这本是“一个老派的概念”,如今因为读它的是模型,又变得有用了。

实践中,这一层由四样东西组成,大部分由客户的专家来写:

  • 字段映射。工作流程关心的东西放在哪个系统的哪一列,以及三个看起来差不多的列里,哪一个才是大家真正在用的。
  • 术语表。在这个业务里,“open”“reserved”“assigned”和“litigation”分别是什么意思,包括各地区的变体。合成案例中那个在不同地区含义不同的状态码,就属于这里。
  • 关联关系。文档库里的一份文档怎样在理赔系统中找到它所属的理赔案件,以及找不到时会怎样。
  • 不能留给模型去推断的规则。哪些理赔类型永远要交给人,哪些标记压过其他一切。第 10 章会在模型之外用代码强制执行其中一部分。

没有这一层,模型就只能猜语义。它会猜得像模像样,却是错的,而这些错误看起来会像模型的错误。无论你用什么接口(包括 MCP),都要通过具名的、有文档的操作来暴露这一层,而不是暴露原始表;本 wiki 的MCP 服务器构建实践指南讲了怎样设计这些工具。还要把术语表写在客户能编辑的地方,因为只要系统还在运行,他们就会一直修正它。

FDE 招聘启事如何描述集成。OpenAI 的前线部署工程师(医疗)招聘启事(西雅图,2026 年 8 月)要求 FDE 构建“与客户基础设施、企业 API、数据平台、电子病历、理赔系统和运营工具集成”的系统,并把 Epic、HL7 和 FHIR 列为它看重的标准(招聘启事)。Decagon 的智能体部署工程师招聘启事(2026 年 1 月)要求工程师“设计、构建并测试与客户系统的集成”(招聘启事)。两者就雇主要求什么而言都是一手证据,就工作实际怎么做而言是 T4。

7.6

先读,后写

客户迟早会要求智能体把答案写进记录系统。他们的理由很充分。最清楚的公开叙述来自 NHS 联邦数据平台。Palantir 执行副总裁 Louis Mosley 对议员们说,回写到 NHS 系统“比从这些系统读取更有挑战,尤其是在非常老旧的系统里”。他还说:“如果这个流程的最后一步是人工回写,要有人把一个决定敲进系统里,那么很多效率就丢掉了。”一家 NHS 信托机构的首席数字信息官 Amy Freeman 从客户一侧表示赞同:“如果你不能回写到源系统,那可能会成为一个生产率上的难题”(The Register,2025 年 7 月;T3,二手报道,而且把问题归咎于老系统符合供应商的利益)。

两点都对:回写更难,而没有回写会损失效率。但试点不是为它买单的地方。写入记录系统,需要系统负责人批准一项变更,而不只是读取。它需要一个被允许修改记录的身份,需要在智能体出错时能回滚,需要一条客户风险部门认可的审计轨迹,还需要回答:如果一份恶意文档说服智能体写下了不该写的东西,会怎样。最后那个问题属于下一章“安全、治理与模型风险”。而这些没有一项能告诉你分派准不准。

出路是把智能体的输出和客户的动作分开:

  • 写到客户拥有的旁路存储里。一张表、一个队列或一个文件夹,由客户的团队控制,位于记录系统之外。智能体只能写这里,别处一概不能写。
  • 在人们已经在工作的地方呈现它。现有的队列视图、收件箱、案件页面。一个需要人们专门去打开的新工具,是你自己制造的采用问题。
  • 让人来做变更。接受一条建议的人,通过他们已经在用的路径把它写进记录系统,沿用那条路径已有的审计轨迹。
  • 记录接受和推翻。每一条被人接受或修改的建议,都是一个白得的标注,而评测那一章(第 9 章)会需要它们。

Mosley 的观点成立:由人把决定敲进去,会损失一部分收益。在试点期间清醒地接受这个代价,把回写放进“暂不做”清单,并附上触发条件。要等四件事都成立,回写才算争取到了:阈值已在真实数据上达到;目标系统的负责人批准了一项变更,而不只是读取;每一次写入都可追溯、可撤销;工作因此改变的那些人已经看过足够多的建议,愿意信任它们。在那之前,智能体提议,人来执行。

7.7

集成会老化;给它配一位负责人

你部署的模型是固定的:你选了一个版本,测试过它,它只在有人决定改动时才会变。它读取的那些系统,则按客户的日程、出于客户的理由变化,而且没人会告诉你。一个字段改了名,一个地区启用了新的状态码,理赔系统升级了。集成悄无声息地坏掉,而智能体继续根据那些含义已经变了的输入作答。

最触目惊心的公开案例年代久远,也不是 FDE 交付,但它展示了这个机制,背后还有一份审计。MD 安德森癌症中心与 IBM Watson 合作打造的肿瘤专家顾问系统(OEA),在四年多的时间里花费了“6,200 万美元”。得克萨斯大学的审计发现,在医院于 2016 年把病历系统迁到 Epic 之后,“OEA 一直没有更新以与现行系统集成”,并且“该系统没有投入临床使用,也没有在 M.D. Anderson 以外试点过”(Network World,2017 年 3 月;T3,对一份内部审计的报道,我们没有读过审计原文)。它的治理失败属于下一章。集成这一点本身就站得住:不管模型能做什么,它都已经读不了医院的病历了。

RAND 的受访者描述了日常版本。没有基础设施,就没有人监控“数据源是否改变了格式,或者没能按时到达”。从一个原型跳到下一个原型的团队,“常常发现自己对 AI 模型完成并部署之后出现的故障完全察觉不到。”然后是人的那一半:离开的数据工程师会“带走他们关于组织数据和基础设施的全部知识”,于是“没有人知道哪些数据集可靠,也没有人知道一个数据集的含义随时间可能发生了怎样的偏移”(RAND,T1)。在一次前线部署交付里,你就是那个会离开的数据工程师。

所以从第一周起,就要把集成构建成可以交出去的样子:

  • 每个数据源都有一个契约测试。一项按计划运行的检查,确认翻译层所依赖的字段、类型和代码仍然存在,含义也没变。检查失败时,智能体停止给出建议,而不是根据坏掉的输入给建议。
  • 一个时效告警。如果文档不再到达或者迟到,要在理赔员发现队列空了之前就通知到某个人。
  • 每个连接器在客户方都有一位指定的负责人,现在就商定并写进接入申请,而不是到交接时才去找。如果没有人愿意负责某个连接器,就像对待一个没有负责人的工作流程那样对待它:这是改设计的理由,而不是继续推进的理由。
  • 术语表和字段映射放在客户的代码仓库里,而不是你的,这样下一个改动源系统的人能看到有什么依赖于它。

交接本身属于第 11 章。负责人则不然:它在写接入申请的时候就定下了。

7.8

模板:数据接入申请

一份文件,第一天就发给每一位审批人,并标出每位审批人负责的问题。它做三件事:只要最少的权限,说明你在等待期间会做什么,并写明你离开后由谁负责连接器。

DATA-ACCESS REQUEST                             version / date: ____

1. PURPOSE
   Workflow served:   ______________________________________________
   Metric it serves:  ______________________________________________
   Needed by (date):  ________   If late: ___________________________

2. WHAT WE NEED (the minimum)
   System / store     Objects (tables, folders)    Access    Rung
   ______________     _________________________    read      ____
   ______________     _________________________    read      ____
   Fields excluded:   ______________________________________________
   Personal data:     categories: __________  minimised how: _______

3. HOW WE CONNECT                        [security's questions]
   Environment:       replica / reporting copy / live
   Network path:      ______________________________________________
   Identity:          one service identity, read-only: ____________
   Credentials:       held in: ____________   never in code
   Write access:      NONE in this phase  |  side store only: _____

4. DATA HANDLING                         [privacy's questions]
   Leaves the customer's environment:  yes / no   what: __________
   Residency:         ______________________________________________
   Retention:         ______   Deletion on: pilot end / on request
   Model provider retention / training: __________________________

5. LOAD AND STABILITY                    [system owner's questions]
   Query pattern:     ______________   Peak volume: ______________
   Scheduled runs:    ______________   Kill switch: ______________

6. WHILE ACCESS IS PENDING
   Fallback:          sanitised fixtures / redacted export: _______
   Export owner:      ______________   Size: ______________________
   Fixtures used for scoring: NEVER

7. AFTER THE PILOT
   Connector owner (customer):  ____________________________________
   Contract tests and freshness alarm run by: _____________________
   Glossary and field map kept in: ________________________________

8. APPROVALS                     name              date
   System owner (load, change):  ______________    ______
   Security (identity, path):    ______________    ______
   Privacy / DPO (fields, use):  ______________    ______
   Requested by (vendor):        ______________    ______

下面是按合成案例填好的版本,数字用区间表示;真实的申请会写上确切的表名、数量和日期。

DATA-ACCESS REQUEST: auto FNOL triage           version 1 / week 1

1. PURPOSE
   Workflow served:   auto first-notice-of-loss document triage
   Metric it serves:  routing accuracy; time to first action
   Needed by (date):  day 5   If late: 30-day clock pauses (agreed)

2. WHAT WE NEED (the minimum)
   System / store     Objects (tables, folders)    Access    Rung
   claims system      claim header, status,        read      4
                      assignment, event times
   document store     auto FNOL intake folders     read      4
   Fields excluded:   bank details, medical notes, full DOB
   Personal data:     categories: name, contact, vehicle, policy
                      minimised how: masked in logs and fixtures

3. HOW WE CONNECT                        [security's questions]
   Environment:       read-only replica, refreshed nightly
   Network path:      inside the insurer's network; no egress of
                      raw documents
   Identity:          one service identity, read-only, from the
                      insurer's identity provider
   Credentials:       held in: insurer's secret store; never in code
   Write access:      NONE to claims system; side table only, owned
                      by claims-platform IT

4. DATA HANDLING                         [privacy's questions]
   Leaves the customer's environment:  no raw data; prompts go only
                      to the endpoint model risk approves (Ch 8)
   Residency:         in-region
   Retention:         pilot length   Deletion on: pilot end
   Model provider retention / training: see security answers (Ch 8)

5. LOAD AND STABILITY                    [system owner's questions]
   Query pattern:     batch reads    Peak volume: hundreds to a
                                     few thousand documents a week
   Scheduled runs:    off-peak       Kill switch: revoke identity

6. WHILE ACCESS IS PENDING
   Fallback:          sanitised fixtures + redacted export
   Export owner:      claims operations   Size: a few hundred claims
   Fixtures used for scoring: NEVER

7. AFTER THE PILOT
   Connector owner (customer):  claims-platform IT lead
   Contract tests and freshness alarm run by: claims-platform IT
   Glossary and field map kept in: insurer's repository

8. APPROVALS                     name              date
   System owner (load, change):  claims-system owner   week 3
   Security (identity, path):    IT security           week 3
   Privacy / DPO (fields, use):  data-protection off.  week 3
   Requested by (vendor):        the FDE (lead cc)     week 1

填好的版本里有两行承担了大部分工作。“If late: 30-day clock pauses (agreed)”(如延迟:30 天计时暂停,已商定)把一份正在拖延的申请变成发起人早已做出的决定,而不是第 4 周的一场争吵。第 7 节则在任何东西构建出来之前就写明了负责人,而这是唯一一个容易找到负责人的时机。指向第 8 章的那几处是有意为之:模型风险审查会问同样的保留期和数据驻留问题,所以答一次就够了。

7.9

失败信号

这些信号都会在头三周出现,那时还来得及应对。

信号
通常意味着什么
怎么做
第一周结束时还没有接近生产的数据
申请发给了错误的人,或者要得太多,或者没人说过延误的代价是什么。
收窄请求,点明每位审批人负责的问题,并启用已商定的规则:暂停计时或重新划定范围。
申请卡在“一个委员会”那里
没有哪个人对这个决定负责,所以没有人会做这个决定。
请发起人为每个问题指定一位审批人:负载、身份、个人数据。
智能体的错误按地区、数据源或文档类型扎堆
这是语义缺口,不是模型缺口:某个代码、字段或关联关系的含义,翻译层没有写明。
在动提示词或模型之前,先和客户的专家一起修正术语表或字段映射。
第一次在真实数据上运行,以测试样本没出现过的方式出了问题
正常。测试样本里只有你想到过的情况。
把新情况加进测试样本和术语表,并为第一次真实运行预留几天,而不是几小时。
客户要求在试点中就做回写
他们看到的是效率提升,而不是随之而来的审批、回滚和风险审查。
现在先提供旁路存储和现有的队列视图;把回写连同它的四个条件放进“暂不做”清单。
交接之后没有人愿意负责连接器
下一次源系统升级时它就会坏,而背锅的会是模型。
现在就把它当作设计问题:找到一位负责人,或者简化到现有团队能够运行为止。
7.10

进入下一阶段

当每一项都打上勾,就进入安全审查的决策和评测:

  • 对接近生产的数据的读取权限已经到位,或者发起人已书面同意在它到位之前怎么办。
  • 流水线已经在真实或脱敏的案件上端到端跑通,而不只是在测试样本上,并且没有任何报告的数字来自测试样本。
  • 字段映射和术语表已经存在,经过客户专家的核对,并且放在客户能编辑的地方。
  • 智能体除了客户拥有的旁路存储之外,哪里都不写,回写连同它的条件已列入“暂不做”清单。
  • 每个连接器在客户方都有一位指定的负责人、一个契约测试和一个时效告警。

第一天就发出数据接入申请,发给具体的人,只要够用的最少权限。它每拖一天,试点就多一天跑在你编造的数据上。把连接器未来的负责人写进同一份申请,因为那是找到负责人不需要任何代价的最后一刻。