ARTICLE · 1308021
AI 系统全景:模型、知识、工具、规则、评测与基础设施如何协作?
AI 系统全景:模型、知识、工具、规则、评测与基础设施如何协作?大语言模型已经能够理解问题、分析信息、生成代码，甚至通过工具执行操作。但当我们真正把 AI 接入业务系统时，会发现一个问题： 模型能力越来越强，为什么构建一个可靠的 AI 应用，仍然需要知识库、工具、业务规则、评测系统和基础设施？ 原因在于，模型只是 AI 系统中的一个组成部分。 模型可以分析故障，却不一定掌握当前的运行状态；可以提出解决方案，却不一定有权限执行；可以调用工具，却不一定能判断业务目标是否真正达成。 要让 AI 从回答问题走向解决实际问题，就需要理解一个完整 AI 系统的组成结构，以及这些部分如何协作。 可以把一个企业 AI 应用理解为一套围绕业务目标组织起来的系统。 当用户提出问题时，系统需要接收请求、获取必要信息、进行分析、判断下一步行动，并在需要时调用业务能力。操作完成后，还要验证结果是否符合预期。 这个过程涉及多个不同的组成部分。 模型： 理解请求、分析信息、生成答案和提出行动建议。 知识系统： 提供文档、规范、历史案例等参考资料。 工具与业务接口： 连接数据库、业务 API、监控系统等外部能力。 规则与工作流： 约束业务条件、执行顺序、审批和失败处理。 评测与可观测性： 判断系统是否可靠，并帮助定位问题。 AI 基础设施： 提供模型运行、计算资源、服务部署和运行保障。 这些组件不是相互独立的功能清单，而是共同构成一条从请求到业务结果的执行链路。 例如，用户询问某项订单为什么退款失败，系统可能需要先查询订单状态，再检索退款规则，结合当前数据分析原因。如果需要执行退款，还必须检查权限、退款条件和审批要求，最后验证退款状态。 模型负责分析，并不意味着它可以代替所有其他环节。 大语言模型是 AI 应用的核心能力之一。 它可以理解自然语言，提取问题中的关键信息，归纳不同来源的内容，并根据上下文生成回答。 但模型的能力有明确边界。 1. 模型不一定掌握最新的业务状态 假设用户询问：“这笔订单为什么退款失败？” 模型可能知道常见的退款失败原因，却不知道这笔订单当前的支付状态、退款记录或具体错误码。 这些信息必须从实际业务系统中获取。 2. 模型的判断不等于事实 模型可能根据现有信息提出一个合理的解释，但合理不代表已经得到验证。 因此，涉及重要业务判断时，系统需要区分事实、推断和未知信息。 3. 模型生成的操作建议不等于操作已经完成 模型可以建议关闭某项服务、重启应用或执行退款，但真正执行这些操作，需要相应的业务能力和权限控制。 模型提供智能分析能力，整个应用则负责把分析转化为可靠的业务结果。 模型并不一定天然掌握企业内部的操作手册、产品规范、历史故障记录和最新业务知识。 这时可以通过外部知识系统提供相关资料。 一种常见方案是 RAG，即检索增强生成（Retrieval-Augmented Generation）。 它的基本流程是： 用户提出问题。 系统从知识库中检索相关资料。 将检索结果与用户问题一起交给模型。 模型结合这些资料生成回答。 例如，运维人员询问：“应用升级失败后应该怎么恢复？” 系统可以从运维手册中检索版本回滚流程，再让模型根据相关内容解释操作步骤。 不过，知识检索并不能解决所有问题。 如果需要确认当前部署的是哪个版本，系统仍然需要查询部署平台；如果需要确认某项操作是否获得审批，则需要读取审批系统中的实际状态。 因此，知识系统主要解决的是“有哪些相关知识可以作为依据”，而不是代替所有业务数据查询和操作。 如果模型只能读取文字并生成回答，它的能力主要停留在信息处理层面。 当应用需要获取实时数据或执行操作时，就需要工具。 工具可以是一个查询接口、一个业务 API，也可以是能够执行特定操作的程序。 例如： 查询订单及退款状态。 获取服务器监控指标。 查询最近的部署记录。 创建运维工单。 调用经过授权的退款或回滚接口。 模型可以根据任务需要选择调用哪个工具，并生成相应的参数；应用程序负责校验参数、执行调用并处理结果。 在工具接入方面，Function Calling（函数调用）是一种常见机制：模型输出结构化的工具调用请求，由应用程序实际执行相应函数，再将结果交回模型继续处理。 MCP（Model Context Protocol，模型上下文协议）则提供了一种标准化的方式，让兼容的 AI 应用连接外部工具和数据资源。 需要注意，MCP 本身不是业务执行引擎。无论通过哪种方式接入工具，实际操作仍然由工具实现及其背后的业务系统完成。 工具调用也可能失败，例如网络超时、参数错误、权限不足或业务状态不符合要求。因此，系统不能只看模型有没有发出调用请求，还需要检查真实的执行结果。 模型具有一定的灵活性，但企业业务通常存在一些不能随意改变的约束。 例如： 退款金额不能超过允许的范围。 某些操作必须经过人工审批。 未获得权限的用户不能执行生产环境操作。 失败后最多允许重试一次。 操作结果不明确时，不能直接重复执行有副作用的请求。 这些约束不能只寄希望于模型每次都能正确理解。 1. 规则系统负责明确的业务条件 规则系统适合处理可以明确表达的条件和判断。 例如，退款是否满足业务规定，可以依据订单状态、退款金额、时间范围等条件进行判断。 当规则明确时，应尽量通过可验证的程序逻辑执行，而不是让模型每次自由推断。 2. 工作流负责组织执行过程 Workflow（工作流）用于组织任务的步骤、分支和状态转换。 例如，退款流程可以规定： 检查订单状态 → 校验退款条件 → 发起审批 → 执行退款 → 查询退款结果。 如果审批未通过，流程就不能进入退款执行阶段。 工作流也可以规定失败后的处理方式，例如最多重试一次，仍然失败就停止并报告。 3. 模型判断与确定性约束需要协作 在一些场景中，系统需要模型分析不确定的问题，同时又必须遵守明确的执行规则。 例如，运维 Agent 可以分析日志并提出回滚建议，但是否允许执行回滚，需要由权限系统、业务规则和工作流共同约束。 这并不意味着所有系统都必须使用独立的规则引擎或复杂工作流。简单应用可以通过普通程序逻辑实现这些约束；只有当业务复杂度和治理要求增加时，才需要更明确的组件划分。 假设支付服务出现大量超时，系统需要分析原因，并在必要时采取行动。 整个过程可以分为以下阶段。 阶段一：获取证据 系统接收到告警后，先获取必要的运行信息。 从知识库检索故障处理手册和历史案例。 从监控平台查询错误率、响应时间和资源使用情况。 从部署平台查询最近的版本变更记录。 知识文档提供排查方法，实时监控提供当前状态，部署记录提供变更事实。 阶段二：分析问题 模型结合这些信息分析可能的原因。 例如，它发现错误率上升与最近一次部署的时间接近，因此提出“新版本可能引发异常”的假设。 但时间上的关联还不足以证明因果关系。系统可能需要进一步检查日志、依赖服务和版本差异。 阶段三：判断是否执行操作 如果证据支持回滚方案，Agent 可以提出回滚建议。 接下来，系统需要检查： 当前版本是否允许回滚。 操作是否在授权范围内。 是否必须经过人工审批。 回滚操作是否存在重复执行的风险。 只有满足相应条件，工作流才允许进入执行阶段。 阶段四：执行并验证 工具调用回滚接口后，系统还需要检查实际状态。 例如，确认部署版本是否已经恢复、服务健康检查是否通过，以及错误率是否回到预期范围。 如果接口返回成功，但服务仍未恢复，就不能直接宣布任务完成。 这个案例说明，可靠的 AI 应用并不是让模型一次性给出所有答案，而是让模型、知识、工具、规则和工作流在各自职责范围内协作，并通过实际结果验证任务是否成功。 即使系统已经连接模型、知识库和工具，也不能由此推断它能够稳定完成任务。 需要通过评测和运行记录，分别检查系统的质量与执行情况。 1. 评测回答质量 可以建立固定测试集，检查模型是否理解问题、是否使用正确依据、答案是否符合预期。 对于知识问答，还需要检查检索结果是否相关，以及答案是否得到检索证据支持。 2. 评测工具使用与任务完成情况 对于需要执行操作的系统，还需要检查： 是否选择了正确的工具。 参数是否正确。 是否遵守权限和审批要求。 是否正确处理超时和失败。 最终业务目标是否真正完成。 回答正确率不能代替端到端任务成功率。 3. 记录运行过程 可观测性用于帮助开发人员理解系统实际发生了什么。 例如，系统可以记录请求编号、检索结果、模型调用、工具执行状态、耗时、异常和最终结果。 当用户反馈“AI 没有正确处理退款”时，这些记录可以帮助定位问题究竟来自数据、检索、模型判断、工具调用，还是业务流程。 4. 使用固定测试验证修改效果 如果调整了检索策略、模型或工作流，应使用相同的测试用例比较修改前后的表现。 除了答案质量，还应关注任务成功率、安全约束、响应时间和运行成本。 不能因为某个案例成功了，就认定整个系统已经可靠。 前面讨论的是 AI 应用的逻辑组成部分，但这些能力最终需要运行在真实的计算和软件环境中。 这就是 AI 基础设施（AI Infrastructure，AI Infra）发挥作用的地方。 它涉及多个方面： 计算资源： CPU、GPU 等处理器，以及内存、显存和存储。 模型服务： 模型加载、推理执行、请求调度和服务接口。 数据与网络： 数据读取、服务通信、存储和传输。 运行管理： 部署、扩缩容、监控、故障恢复和资源管理。 例如，当多个用户同时调用模型时，系统不仅需要考虑模型能否回答问题，还需要考虑并发请求、响应延迟、资源使用和服务稳定性。 如果模型服务不可用，或者工具接口频繁超时，上层 Agent 和工作流就可能无法完成任务。 不过，并不是每个 AI 应用都需要自己部署模型或建设复杂的基础设施。使用云端模型 API，也是一种合理的架构选择。具体采用哪种方式，应结合业务要求、成本、安全和运维能力判断。 系统设计不应该从“需要使用多少种技术”出发，而应该从业务目标和风险出发。 场景一：简单文本处理 例如总结一段文字、改写一封邮件。 可能只需要模型调用和基本的输入输出校验。 场景二：企业知识问答 需要回答内部规范、操作流程等问题。 可以在模型之外增加知识检索、访问控制、引用依据和答案评测。 场景三：实时业务查询 例如查询订单状态、监控指标或部署版本。 除了知识能力，还需要连接真实业务数据源，并处理工具调用失败和数据时效性问题。 场景四：自动执行复杂任务 例如分析告警、发起审批、执行回滚并验证恢复结果。 这类系统可能需要 Agent、工作流、业务规则、权限控制、状态管理、评测与运行监控的协同。 应用越接近真实业务执行，越需要明确操作边界和结果验证机制。 AI 系统不是单个大模型的简单封装，而是围绕业务目标组织起来的一套协作体系。 模型提供理解和分析能力，知识系统提供参考依据，工具连接真实业务系统，规则与工作流控制业务约束和执行过程，评测与可观测性帮助判断质量和定位故障，AI 基础设施则保障这些能力能够稳定运行。 这些组件并非越多越好，也不需要在每个项目中全部独立部署。合理的设计应当根据任务复杂度、风险和实际需求选择必要能力，并明确各组件的职责边界。 衡量一个 AI 系统是否可靠，不只是看模型能不能回答问题，更要看系统能否基于可靠证据作出判断、在约束范围内执行操作，并通过真实结果验证业务目标是否达成。 参考资料 Lewis 等，《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》：https://arxiv.org/abs/2005.11401 Model Context Protocol 官方文档：https://modelcontextprotocol.io/ OpenAI Agents SDK：https://developers.openai.com/api/docs/guides/agents/sdk OpenAI Agents 中的 Guardrails 与 Human Review：https://developers.openai.com/api/docs/guides/agents/guardrails-approvals OpenAI Agents 中的 Integrations 与 Observability：https://developers.openai.com/api/docs/guides/agents/integrations-observability
