解决方案
以企业数据为依据、为长期运营而构建的 AI 系统
我们设计并构建的 AI 系统，依据您的文档与业务记录作答，在团队已经使用的产品内完成工作，并且在上线之后仍然可以度量、审计和纠正。
问题域
大多数组织都能在几天内做出一个令人信服的 AI 演示。一个语言模型、几份文档加上一个聊天界面，就足以给出一个看起来正确的答案。从这个演示到一套让人放心依赖的系统，中间的距离正是工程所在：在数百万份文档的语料中找到正确段落的检索，随用户进入每一次查询的权限控制，带有出处引用的回答，以及判断上周的改动让效果变好还是变差的手段。
这一类系统有着相似的形态。知识助手依据内部内容回答问题。文档智能从合同、发票、理赔材料和报告中抽取结构化数据。Copilot 嵌入现有产品，负责起草、摘要或建议下一步操作。决策支持为仍需对结果负责的人汇集证据。在每一种场景里，模型都只是众多组件之一，而且通常并不是决定系统成败的那一个。
我们把 AI 系统看作一套带有概率性组件的软件系统。这意味着提示词与索引要做版本管理，交付流水线中要有自动化评估，每一次模型调用都要可追踪，成本与延迟要有明确预算，哪些数据可以到达哪个模型要有管控。这也意味着，当一条确定性规则、一个搜索索引或一次数据库查询能以更低成本、更高可靠性解决问题时，我们会尽早说明。
难在哪里
工程挑战
检索质量决定上限
模型无法依据它从未见过的段落给出正确答案。简单的定长切分会把表格和条款拦腰截断，纯向量检索会漏掉料号、保单代码这类精确标识，过期的索引会返回已被取代的文档。大多数糟糕的回答，根源在检索而不在模型。
访问控制必须贯穿检索
一个什么都索引、什么都不过滤的助手，会把董事会文件展示给初级分析师。源系统中的权限必须带入索引并在查询时强制执行，而且在文档调整密级或人员变更岗位之后依然保持正确。
无人能够度量的质量
没有评估集，每一次提示词修改都是猜测，每一次效果回退都由用户发现，团队最终只能凭个例争论。系统需要一套经过整理的问题集，附带预期的证据与答案，并在每次变更时自动评分。
编造的和缺乏依据的回答
无论检索到的上下文是否支持，模型都会生成流畅的文字。这种失效之所以危险，正是因为它读起来很通顺。回答需要能够对应到真实段落的引用，需要校验其中的论断是否有这些段落支撑，并且在证据不足时有明确定义的行为。
提示注入与数据泄露
系统读取的任何文档、邮件或网页，都可能包含针对模型的指令。如果同一个模型还能调用工具，被注入的指令就会变成实际操作。检索到的内容必须视为不可信输入，工具权限的范围必须按用户界定，而不是按模型界定。
真实流量下的成本与延迟
试点阶段花费不多的提示词，在每天数万次请求时会成为一笔可观的开支；四次串行的模型调用也满足不了交互式场景的延迟预算。模型路由、缓存、上下文裁剪和流式输出必须在设计阶段就纳入，而不是等账单到了再补。
我们如何构建
架构
生产级 AI 系统把数据摄取、检索、编排、护栏与评估分开，使每一部分都能独立变更和度量。模型位于网关之后，被视为可替换的组件。
- 01
数据摄取与索引流水线
连接器从文档库、Wiki、工单系统和数据库拉取内容，随后进行解析、清洗，并沿标题、条款、表格行等结构边界切分。每个分块都携带来源、版本、生效日期和访问控制元数据。流水线支持增量处理，文档被编辑或删除后无需全量重建即可反映到索引中。
- 02
混合检索与重排序
查询同时在向量索引和关键词索引上执行，因为语义检索擅长找到同义表述，词法检索擅长命中精确术语。重排序模型对合并后的候选结果排序，再把一小组相关内容交给生成模型。权限过滤在查询内部执行，而不是在查询之后，受限内容因此不会进入上下文窗口。
- 03
编排层
由一个服务负责组装提示词、调用模型、调用工具并管理会话状态。提示词是纳入源码管理的版本化制品，像代码一样发布。当任务需要多个步骤时，流程被建模为迭代次数有上限的显式图，行为可以追踪，也不会出现失控的循环。
- 04
模型网关
所有模型调用都经过同一个网关，由它处理路由、重试、超时、限流、缓存和成本归属。它让小模型承担分类与抽取，让大模型承担推理，并且只需在一处就能更换供应商或模型版本。数据驻留与脱敏规则也在这里执行。
- 05
护栏与策略执行
输入要筛查注入模式和敏感数据；输出在到达用户之前，要检查结构是否合法、论断是否有依据、是否违反策略。工具调用以发起调用的用户的权限执行，高影响操作需要确认。这些检查尽可能用确定性代码实现，因为用第二个模型去看守第一个模型并不可靠。
- 06
评估框架
维护一套由代表性问题、预期来源和参考答案组成的数据集，每当提示词、检索配置或模型发生变更时都重新评分。指标涵盖检索召回率、回答的依据充分性、答案正确性和拒答行为。评估框架运行在交付流水线中，回退超过约定阈值的发布会被拦截。
- 07
可观测性与反馈
每个请求都会生成一条追踪记录，涵盖查询、检索到的分块、提示词版本、模型、token 数量、延迟和结果。用户反馈与抽样人工评审都会关联到这些追踪记录，并回流到评估集。正因如此，几周之后仍然能够解释某一个具体的回答。
摄取
- 01
数据源
文档、数据库、内部 API
- 02
解析与切分
提取文本，保留结构
- 03
向量化
批量生成嵌入，模型有版本
- 04
索引
带 ACL 的向量与关键词索引
查询
- 01
提问
已认证用户及其权限范围
- 02
检索
向量与关键词混合检索
- 03
重排
只保留相关性最高的段落
- 04
生成
有依据并附引用的答案
- 05
评估与记录
追踪、评分并收集反馈
一次合作交付什么
- 用例评估，并就 AI 适用与不适用的场景给出建议
- 带来源级访问控制的数据摄取流水线与索引
- 位于文档化 API 之后的检索与编排服务
- 评估数据集，以及交付流水线中的自动评分
- 护栏、脱敏与工具权限策略
- 追踪、成本与质量仪表盘
- 涵盖模型升级、索引重建与事故处理的运维手册
开始之前
需要尽早做出的决策
- 检索、微调，还是两者并用
- 当答案依赖会变化或必须注明出处的事实时，使用检索，这涵盖了大部分企业知识场景。当您需要提示词无法稳定保持的统一格式、语气或专门的分类能力，并且手中有可用于训练的标注样本时，可以考虑微调。两者互为补充：经过微调的模型仍然需要检索才能知道今天的事实是什么。
- 托管模型 API，还是自行部署模型
- 托管 API 提供能力最强的模型，且无需运维基础设施，适合供应商的数据处理条款可以接受的大多数工作负载。当数据不能离开自有环境、调用量大到足以支撑 GPU 投入，或延迟需要严格控制时，自行部署开放权重模型才有意义。它会带来实实在在的运营成本：容量规划、模型服务和升级都将由您负责。
- 给系统多大的自主权
- 先从系统提议、人工批准开始。只有当某个操作可撤销、影响小并且有评估证据支撑时，才把它改为自动执行。涉及资金划转、修改客户记录或对外发送信息的操作，应保留人工审批步骤，直到错误率被相关责任人了解并接受。
- 建设平台，还是单个应用
- 如果眼前只有一个用例，就把这个应用做好，同时让网关、评估和追踪保持为可拆分的组件。等到第二、第三个用例出现，不建平台就要重复建设数据摄取、访问控制和治理时，共享平台才值得投入。先建平台，往往得到的是一套没有用户的基础设施。
常见问题
常见问题
系统能否只使用我们自己的数据？
可以。系统的设计是依据检索到的内容作答，并在内容不包含答案时明确说明。回答带有指向来源段落的引用，依据充分性检查会标记超出证据范围的回答。没有任何设计能够完全消除这类风险，因此评估与评审始终是运营的一部分。
你们使用哪些模型？
架构不绑定特定模型。网关把应用与任何单一供应商隔离开来，因此商用 API 与开放权重模型之间的取舍可以按任务，依据质量、成本、延迟和数据处理要求来决定，并随着模型的演进重新评估。
如何处理敏感数据或受监管的数据？
数据分级在摄取阶段完成，访问控制在检索阶段执行，内容发送给模型之前先经过脱敏规则。部署方式可以安排为让数据留在选定的云区域或私有环境内。我们设计的系统用于支持您履行合规义务；义务本身由您和您的顾问界定。
模型供应商发布新版本时会怎样？
新版本在承接任何流量之前，先在评估数据集上运行。如果得分保持稳定，就在网关之后逐步放量；如果出现回退，则先调整提示词或检索配置。在对比完成之前，原有版本保持锁定。