组织级上下文为什么是银行业 AI 时代的核心工程(Context Engineering)
核心摘要
- Context Engineering（上下文工程）
- 40%-50% 的工程精力花在了"上下文组装"上
- 这就是当前银行业 AI 落地最隐蔽、也最昂贵的失败模式
- 本文从 Context Engineering（上下文工程） 的视角回答三个问题：组织级上下文为什么重要、它到底包括什么内容、以及如何系统性地构建它
组织级上下文为什么是银行业 AI 时代的核心工程（Context Engineering）
文 / 金融行业风险管理从业者 · 2026-09-13
如果一家银行把最强大的大模型接入核心系统，却没有任何组织级上下文层，会发生什么？它会表现得像一个"流利陌生人"：措辞专业、语速流畅，但对客户真正的风险敞口、监管红线、内部流程一窍不通，甚至一本正经地给出违规建议。
这就是当前银行业 AI 落地最隐蔽、也最昂贵的失败模式。本文从 Context Engineering（上下文工程） 的视角回答三个问题：组织级上下文为什么重要、它到底包括什么内容、以及如何系统性地构建它。
一、为什么：没有上下文层的银行，只是"流利陌生人"
1.1 上下文工程是比提示工程更底层的杠杆
2024-2025 年行业基本共识之一是：决定模型上限的不是模型权重，而是上下文的质量。多个技术供应商的实测与统计指向同一结论：
- 银行/企业级 AI 构建过程中，40%-50% 的工程精力花在了"上下文组装"上——即把正确的数据、规则、历史与意图，在正确的时间交给模型（Persistent、AWS 的 context engineering 实践文章均强调这一点）。
- 提示工程（Prompt Engineering）解决的是"如何问"；而上下文工程解决的是"把什么、以什么结构、多大范围放进上下文"。前者是战术，后者是架构。
1.2 银行业的"上下文缺口"是结构性的
银行的业务天然是上下文密集的：
- 一笔授信审批，需要客户 360 度画像、历史违约、行业景气、担保品估值、内部信贷政策、监管参数（LTV / DSR / 集中度限额）；
- 一次反洗钱调查，需要交易链路、受益人穿透、名单命中、地域风险、客户行为基线；
- 每一次客户对话，都需要"这个客户是谁、上次说了什么、什么能承诺、什么必须拒"。
这些信息散落在核心系统、CRM、信贷审批、风控引擎、制度文档、合规手册里。没有组织级上下文层，大模型就退化为"参数记忆"，它记不住行内实时的、结构化的、管辖权各异的业务事实。
1.3 一个比喻：上下文层是银行的"可信大脑"
可以把银行 AI 架构粗略分为三层：
- Core 核心层：模型管理、身份与安全、可观测性——解决"能力和安全地基"；
- Context 上下文层（即组织级上下文）：把数据、流程、知识、历史，加上领域意识、血缘、业务规则与合规标记，组装成模型可信的"大脑"；
- Coordination 协同层：人、智能体、应用与既有系统之间的编排协作。
二、包括什么：组织级上下文的五类内容
组织级上下文不是"把数据库全塞进 Prompt"，而是有取舍、有结构、有治理的语义资产。综合 AWS（Context Engineering 定义）、IBM（企业上下文与治理）、TCS（Context Fabric 五维）等的实践，可以归纳为五类：
| 类别 | 核心内容 | 典型例子（银行） | 缺失的代价 |
|---|---|---|---|
| 数据上下文 | 数据目录、血缘、画像、可信源、口径定义 | 客户主数据、敞口视图、数据质量标签 | 模型引用过时或被篡改的数据 |
| 流程上下文 | 标准作业程序、审批态、工作流编排、异常与覆盖 | 授信审批链路、反洗钱上报时限 | 智能体跳过关键审批环节 |
| 监管上下文 | 合规红线、授权边界、管辖规则、审计留痕 | 监管限额、禁止销售条款、信息披露义务 | 给出违规/越权建议 |
| 领域上下文 | 业务方言、产品制式、本体关系、历史例外 | 信贷产品参数、担保定义、"续期"等行话 | 术语歧义导致误判 |
| 工具/知识上下文 | 工具规格、语义库、历史范例、隐性经验 | API schema、历史决议、风控经验 | 不知道该用哪个工具/该问哪个系统 |
2.1 底层组件：同义词表 + 本体 + 知识图谱
万变不离其宗，组织级上下文的语义底座通常是三件套：
- 同义词表（Synonyms）：统一"客户/借款人/债务人""敞口/风险暴露""贷款/授信"等业务方言，消除歧义；
- 本体（Ontology）：定义客户-产品-交易-风险-监管实体及其关系、权限、约束；
- 知识图谱（Knowledge Graph）：把本体实例化，按实体-关系-属性组织真实业务数据，支持血缘追溯与推理。
2.2 形式：静态上下文 + 动态上下文
- 静态/沉淀上下文：制度文档、产品手册、历史决议、FAQ——离线加工成嵌入或检索库；
- 动态/实时上下文：实时汇率、风险阈值、监管参数、客户当下状态——按触发条件注入。
二者结合，才能让模型既"懂制度"又"知当下"。
三、怎么构建：五步构建方法论
借鉴 Persistent / IBM / TCS 的框架并落地为银行可执行路径，构建组织级上下文分为五步：
摄取 → 建模 → 落地 → 交付 → 治理（闭环回灌摄取）3.1 ① 摄取（Ingest）：打标签比建仓库更重要
从 CRM、核心系统、制度库、合规库等源系统接入内容，但每条内容都必须标注：归属部门、敏感度分级、监管相关性、有效期、可信源。没有标签，后端的检索和权限控制无从谈起。
3.2 ② 建模（Model）：语义图谱化
以"客户—产品—交易—风险—监管"为主轴做实体对齐与消歧，构建本体与知识图谱，并重建血缘（每个结论可追溯到源系统字段）。这一步决定上下文的可解释性。
3.3 ③ 落地（Ground）：把监管参数送进推理
将政策、风险规则、阈值、实时市场波动等作为可被工具调用的"事实供给"，在模型推理时按需注入，而不是预埋在提示里。落地时遵循"能查不记"：凡是能实时查询的，就不该靠模型记忆。
3.4 ④ 交付（Deliver）：可解释 + 审计留痕
每个输出都应携带引用来源与置信度，供信贷员、风控、审计复核。监管（EU AI Act、FCA 消费者保护、MAS FEAT、OCC/FDIC 指引）对高影响 AI 的可解释性要求，本质上要求的就是"上下文可追溯"。
3.5 ⑤ 治理（Manage）：上下文随系统运行而演化
IBM 一针见血：治理必须随系统运行，而不是上线前一次性评审。实践中通常采用分两级刷新：
- 批量刷新（约 24h）：制度更新、产品参数、知识库沉淀；
- 流式刷新（约 60s）：汇率、限额消耗、客户即时状态。
同时维护反馈回路：模型的错误回答反向标记上下文缺口，驱动摄取环节补样。
四、红线与陷阱
- 上下文≠数据倾倒：把全部数据库塞进 Context 是多私有云成本与延迟，也不提升准确性。做取舍与分层。
- 上下文也要权限：上下文层承载敏感数据，必须继承行内的授权边界（谁能看什么、模型能对什么客户级别生效）。
- 血缘是合规的命门：没有血缘的上下文输出，等于没有审计证据，过不了监管解释要求。
- owner 要明确：组织级上下文不是 IT 部门单干的项目，需业务、风控、合规、数据四线共治。
结语
对银行而言，组织级上下文不是"要不要建"的问题，而是"不建就是流利陌生人、建了才是可信大脑"的问题。它把分散在系统、制度与人脑中的业务事实，变成模型可以信任、并可以向监管交代的结构化资产——这正是 Context Engineering 为银行业带来的最大增量。下一步的方向也很清晰：把同义词表—本体—知识图谱做实，把五类上下文接入治理闭环，先从一个高价值场景（授信、反洗钱或客户助手）跑通，再横向复制。
（本文为行业研究观点，不代表任何机构立场。）