这是探讨构建企业级智能体人工智能系统综合框架的两篇系列文章的第一篇。我们将深入探讨四个协同运作的关键支柱：智能体编排（大脑）、高级 RAG 流水线（知识引擎）、基础设施和部署（身体和规模）以及可观测性和优化（健康和性能）。

介绍

大规模部署人工智能系统的竞赛揭示了一个残酷的现实：训练有素的模型仅仅是开始。从实验性笔记本到生产系统的过渡，需要跨多个复杂领域进行周密的协调。无论是构建能够自主决策的智能体、能够准确回答问题的检索增强生成（RAG）系统，还是能够可靠扩展的基础设施，架构都至关重要。

这是探讨构建企业级智能体人工智能系统综合框架的两篇系列文章的第一篇。我们将深入探讨四个协同运作的关键支柱：智能体编排（大脑）、高级 RAG 流水线（知识引擎）、基础设施和部署（身体和规模）以及可观测性和优化（健康和性能）。对于负责将人工智能从概念验证阶段推进到生产阶段的工程师和架构师而言，理解这些支柱及其相互作用至关重要。

我们将探讨的架构并非理论上的。它代表了在构建处理现实世界复杂性的系统中涌现出的模式：管理多个并发代理任务、维护分布式基础设施的一致性、即使数据增长也能保持系统的响应能力，以及了解黑盒内部发生的事情。

四大支柱：系统概述

在深入探讨每个组成部分之前，让我们先建立概念基础。现代智能体人工智能系统需要四个层面协同工作：

大脑决定行动方案——它协调代理、管理工具、维护上下文并执行推理循环。知识引擎确保决策基于充分的信息——它在决策时摄取、处理和检索相关信息。身体和规模保障一切运行——基础设施、容器、服务层和模型托管能够可靠地处理并发请求。健康和性能保障一切正常运行——可观测性、监控和持续优化。

把它想象成一个人类专家系统：大脑需要获取知识（书籍、数据、专业知识），依靠健康的身体才能运作（睡眠、营养、身体健康），并且必须了解自身的表现才能随着时间的推移而改进。

第一部分：主动协调——大脑

1.理解核心

智能体编排是决策发生的地方。这并非指向大语言模型（LLM）发起一次推理调用，而是要协调多个步骤、管理工具使用、在交互过程中保持上下文关联，并实现推理循环，使智能体能够迭代地思考问题。

代理位于中心位置，接收用户查询并决定采取哪些步骤。这需要多个相互关联的系统无缝协作。

2.代理/LLM核心

编排的核心在于代理本身，它通常由大型语言模型驱动。代理接收用户查询，理解当前任务，并决定调用哪些工具以及调用顺序。这并非简单的查找，而是在不确定性下进行推理。

最佳实践是将代理接口和底层模型清晰分离。编排层应该抽象出代理所使用的具体 LLM。这样，您就可以在不重构编排逻辑的情况下更换模型（例如，从 GPT-4 更换为 Claude 或其微调版本）。使用一个所有 LLM 调用都经过的定义接口，这样就可以轻松地更改模型提供程序、添加备用模型或实现成本优化策略。

另一个关键考虑因素是提示工程设计和上下文管理。智能体的指令必须精确。模糊的指令会导致不可预测的行为。然而，指令也不应过于僵化，以至于限制智能体的灵活推理能力。最佳方法通常是为智能体提供清晰的目标、明确的约束、用于少样本学习的示例输出以及可用工具的信息。必须谨慎管理上下文，以避免超出令牌限制，同时保留关键信息。

3.工具注册和规范

没有工具的智能体就像没有双手的人——它能思考却不能行动。工具注册表维护着智能体可以执行的所有操作的目录：数据库查询、API 调用、文件操作、计算或特定领域的操作。

一个完善的工具注册表不仅仅列出可用的工具，它还会详细说明每个工具的签名、参数、预期输出、错误情况和使用模式。这些元数据至关重要，因为代理需要了解何时以及如何有效地使用每个工具。

最佳实践：使用正式规范而非非正式文档来定义工具。无论您使用 LangChain 的工具定义、JSON 模式还是 OpenAI 的函数调用格式，规范都应确保机器可读且精确。这可以降低智能体错误调用工具或在不恰当的时机调用工具的概率。规范中应包含工具成本（如果调用外部 API）、预期延迟以及潜在故障模式等信息。

另一个重要的模式是语义工具组织。随着工具库的增长，智能体需要找到合适的工具来完成任务。与其向智能体推送数十种工具，不如实现一个语义搜索或分类层。当智能体需要执行任务时，系统会根据工具与任务描述的自然语言相似度，筛选出相关的工具。这可以降低智能体的认知负荷，并提高决策质量。

4.执行循环：思考与行动

现代智能体系统实现了推理循环，其中智能体在思考和行动之间交替进行。这可能遵循类似 ReAct（推理+行动）的模式，即智能体推理自身需要做什么，采取行动（调用工具），观察结果，然后推理下一步该做什么。

实现这种模式需要谨慎处理循环终止。智能体应该知道何时已掌握足够的信息来回答用户的问题。糟糕的终止逻辑会导致过早响应或无限循环。因此，需要建立清晰的停止条件：当智能体收集到足够的信息、达到最大步数或明确判定任务完成时。

最佳实践是对执行循环进行插桩，以便进行调试和优化。记录每个步骤：代理的决策、调用的工具、结果以及代理的响应。这些信息对于理解代理做出特定决策的原因以及识别系统性故障至关重要。

5.记忆管理：短期和长期

智能体需要记忆才能有效工作。记忆有两种截然不同的形式：适用于当前对话的短期上下文记忆，以及贯穿多个对话的长期记忆。

短期记忆通常是一个上下文窗口——用户和代理之间的最后 N 条消息。这里的挑战在于上下文窗口的优化。令牌成本高昂且数量有限。与其盲目地包含所有之前的消息，不如实现智能的上下文选择。对较早的对话进行摘要，优先考虑最近的消息，并丢弃无关信息。一些方法使用分层摘要，其中对非常久远的交互进行比近期交互更严格的压缩。

Redis 或 PostgreSQL 等工具非常适合上下文存储。Redis 为频繁访问的上下文提供速度和简洁性；PostgreSQL 则在需要搜索对话历史记录时提供持久性和复杂的查询能力。具体选择取决于您的规模和一致性要求。

长期记忆的处理更为复杂。一些方法会存储关于用户或先前交互的明确事实或摘要。另一些方法则利用语义搜索来检索对话历史记录中相关的过往交互。最佳方法通常是将两者结合起来：使用结构化事实来存储关键信息（用户偏好、重要结果），并使用语义搜索来探索先前交互的更广泛背景。

6.状态管理：一致性和可靠性

当智能体执行复杂的多步骤任务时，它们会积累状态。智能体可能已部分检索数据、存在待处理操作或有中间结果。必须谨慎管理这些状态。

为复杂的代理工作流实现显式状态机。不要依赖隐式顺序，而是显式定义状态（例如，“等待用户确认”、“执行工具”、“处理结果”）以及它们之间的有效转换。这能显著简化对正在发生的事情的推理，并便于处理边界情况或故障。

对于任何重要数据，都应该使用持久状态存储。Redis 适用于可以重新计算的临时状态，但对于关键信息，PostgreSQL 或类似的数据库必不可少。状态必须能够经受住进程崩溃、网络中断和部署更新的考验。

另一个关键模式是幂等性。代理操作应该可以安全地重试。如果代理调用某个工具但响应超时，那么再次调用同一个工具应该不会产生重复的副作用。这需要精心设计 API：操作应该是幂等的，或者应该跟踪哪些操作已经执行过。

7.上下文窗口优化：实际约束

上下文窗口是有限的。即使是大型模型也存在局限性，而这些局限性会直接转化为成本和延迟。优化上下文使用并非可有可无，而是构建可扩展系统的基础。

采用分层方法：优先考虑最新和最相关的信息。对较早的上下文进行积极的摘要处理。考虑将较长的对话拆分成多个会话，并明确交接。对于检索增强型生成（将在下一节中介绍），仅包含检索到的最相关的文档，而不是所有可用的上下文。

一种更精细的方法是使用语义重要性评分。它并非假设所有旧消息都同等重要，而是根据消息与当前查询的语义相似度对其进行评分。保留高分消息，并对低分消息进行总结或丢弃。这样既能保留关键上下文，又能显著减少词元消耗。

第二部分：高级 RAG 管道——知识引擎

1.RAG 在现代系统中的作用

仅靠智能体系统，其能力受限于训练数据中蕴含的知识。RAG（检索增强生成）通过允许智能体在决策时访问外部知识源来解决这个问题。这正是能够推理的智能体与能够针对特定数据、文档和领域知识进行推理的智能体之间的区别所在。

RAG 管道很复杂，因为它们必须处理信息的整个过程：从各种来源摄取信息、处理成有用的块、嵌入语义空间、存储在可搜索的索引中，以及在需要时进行精确检索。

2.文档导入和处理

整个流程始于信息导入。组织机构的数据无处不在：PDF、网页内容、数据库、专有文件格式等等。您的数据导入层必须能够可靠地处理这种多样性。

最佳实践是采用模块化数据摄取方式，并使用特定格式的处理程序。不要只构建一个“摄取”函数。相反，应该为每种数据源类型创建专门的处理程序：PDF 解析器、HTML 提取器、数据库连接器以及针对特定领域格式的自定义解析器。每个处理程序都知道如何从其源类型中提取干净、结构化的文本。

除了读取文件之外，还要考虑元数据。这份文档来自何时？由谁创建？其可靠性如何？这些元数据应该贯穿整个流程。它有助于筛选结果（仅显示来自可信来源的最新文档），并且可以呈现给用户，以便他们了解所检索信息的来源。

常见的错误模式是对所有文档一视同仁。实际上，操作手册可能比论坛帖子更可靠，最近的新闻文章可能比旧新闻文章更具时效性。在文档导入过程中，应为其分配可信度评分和时效性权重。这些评分应影响检索排名。

3.块状策略：找到合适的粒度

如何将文档分割成块会从根本上影响检索质量。块太小，会丢失上下文；块太大，则会将无关信息与相关段落混杂在一起。虽然没有通用的解决方案，但目前已经涌现出几种有效的策略。

固定大小且带重叠的分块方法简单易行，适用于多种情况。文档被分割成固定大小（例如 512 个词元）且允许重叠（例如 50 个词元）的块。这样可以确保跨越块边界的概念不会丢失。

语义分块法根据自然的语义边界分割文档。它不采用任意的词元界限，而是在一个主题结束、另一个主题开始的地方进行分割。这需要理解文档结构，但通常能产生更高质量的分块。

层级分块技术可以创建多个粒度级别的块。长文档可以拆分为章节（大块）、节（中块）和段落（小块）。检索可以在任何层级进行，从而可以灵活地将查询的具体性与文档结构相匹配。

最佳实践是包含元数据的上下文感知分块。每个分块不仅应包含其内容，还应包含其来源信息：文档标题、章节或节、日期。这有助于排名和解释。

4.嵌入模型和向量数据库

需要将数据块转换为嵌入向量——一种密集的向量表示，其中语义相似的内容映射到向量空间中相邻的点。嵌入向量的质量直接影响检索质量。

谨慎选择嵌入模型。您的选择会影响成本、延迟和检索质量。像MTEB排行榜上的优胜者这样的开源模型，其性能足以媲美商业产品。考虑针对您的特定领域对嵌入进行微调——领域特定的嵌入通常优于通用嵌入。

对嵌入进行版本控制是一项至关重要的最佳实践。当您更改嵌入模型或对其进行微调时，向量空间也会发生变化。旧的嵌入将不再兼容。维护版本控制，以便您可以跟踪哪个模型生成了哪些嵌入，并系统地处理迁移。

像 Pinecone、Weaviate、Chroma 或 Milvus 这样的向量数据库能够高效地存储和搜索词嵌入。它们可以处理扩展、索引和相似性搜索。选择向量数据库时，需要考虑以下几个因素：它是否支持元数据过滤？它如何处理扩展？它的运维开销是多少？它能否处理混合搜索（结合语义搜索和关键词搜索）？

混合搜索的重要性日益凸显。语义搜索功能强大，但有时关键词匹配才是您真正需要的。因此，应实现结合两种搜索方式的系统：利用语义向量理解文本含义，并结合传统的全文搜索进行精确匹配。智能地整合搜索结果，例如，略微优先考虑同时满足两种搜索条件的文档。

5.搜索与排名：超越相似性

检索不仅仅是找到语义相似的文档，而是找到最能回答特定问题的文档。

实现多阶段排序。首先，使用快速相似性搜索检索一个更大的候选集。然后，对这个较小的候选集应用更复杂的排序算法。这可能包括基于特定查询的相关性评分、时效性加权、数据导入过程中建立的可信度评分，或特定领域的排序规则。

考虑查询扩展和重构。有时用户的查询语句不够清晰，不利于语义搜索。查询扩展可以生成替代语句或相关概念，从而显著提高召回率。同样，重构查询以突出关键概念也有助于检索到更相关的结果。

一种更复杂的方法是使用针对特定领域训练的排序学习模型。这些模型会学习哪些特征组合（语义相似度、时效性、元数据字段、文档可信度）能够最好地预测文档对查询的有效性。它们通常优于手动调整的排序规则，尤其是在复杂性增加的情况下。

6.语义相关性和元数据过滤

检索到候选文档后，筛选就变得至关重要。某个文档可能在语义上与查询相似，但由于其他原因而不相关：例如，它来自不可靠的来源、已经过时，或者它涉及不同的上下文。

实现元数据感知过滤。在数据导入过程中，为文档附加元数据：主题、创建日期、来源可信度、访问权限。在数据检索过程中，使用这些元数据进行过滤。这可能包括排除早于特定日期的文档、仅包含来自可信来源的文档，或按主题相关性进行过滤。

召回率和精确率之间的平衡至关重要。过滤过于激进虽然能降低噪声，但可能会遗漏相关文档。最佳实践是采用带有评分的软过滤。与其使用硬过滤直接排除文档，不如给文档赋予分数。符合过滤条件的文档会获得更高的分数，而其他文档仍然可以检索，但排名较低。

第三部分：基础设施与部署——主体与规模

1.容器编排：构建可扩展系统

现代人工智能系统运行在容器化基础设施上。Docker 容器提供了一致性（代码在任何地方运行都相同）、隔离性（服务之间互不干扰）以及与 Kubernetes 等编排平台的兼容性。

最佳实践是根据工作负载的基本原理来设计容器。许多开发者照搬 Web 开发的模式，但 AI 系统具有不同的特性。模型规模庞大，推理过程可能占用大量内存，而且 GPU 资源珍贵且昂贵。容器设计应该体现这些现实情况。

构建仅包含必要组件的最小容器。大型容器镜像会降低部署速度并浪费带宽。使用多阶段构建来保持最终镜像的精简。模型权重通常应挂载自外部存储，而不是嵌入到镜像中，这样您就可以在不重新构建和部署整个容器的情况下更新模型。

Kubernetes 之所以成为标准的编排平台，原因显而易见：它可以自动处理调度、扩展和网络。然而，它也很复杂。建议从托管 Kubernetes（EKS、GKE、AKS）入手，而不是自行部署。这样可以将运维开销转移给拥有可靠运行 Kubernetes 经验的云服务提供商。

2.服务层：使模型易于访问

如果没有服务层使原始模型能够通过网络访问，那么它们就毫无用处。服务层处理 HTTP 请求、管理请求队列、实现批处理以提高效率，并优雅地处理故障。

目前有几种成熟的方案可供选择：vLLM 用于高吞吐量的 LLM 推理，TensorFlow Serving 用于传统机器学习模型，TorchServe 用于 PyTorch 模型，以及 SageMaker Endpoints 或 Vertex AI 等云原生方案。您可以根据具体需求进行选择，但应优先考虑能够处理批处理并支持 GPU 加速的框架。

请求路由和负载均衡是关键考虑因素。请求不应集中发送到单个模型实例——需要多个副本来处理流量。负载均衡器负责分发请求，健康检查会移除不健康的实例，而自动扩缩容功能则会根据负载情况添加/移除副本。

实现请求级监控和追踪。每个请求都应该有一个唯一的 ID，该 ID 会流经整个系统。这使得调试成为可能：当出现问题时，您可以追踪请求从入口点到模型推理再到响应的完整路径。Jaeger 或 Zipkin 等工具提供了分布式追踪功能。

3.模型托管和资源管理

模型是昂贵的资源。一个大型语言模型可能需要占用 40GB 的 GPU 内存。高效的资源管理必不可少。

实现模型版本控制和生命周期管理。您需要跟踪哪些模型版本存在、哪些版本正在生产环境中使用，以及何时可以安全地弃用旧版本。容器镜像仓库（例如 ECR、Docker Hub）跟踪镜像版本。模型仓库（例如 MLflow、Weights & Biases）跟踪模型工件和元数据。

对于资源受限的环境，可以考虑模型量化和优化。将模型精度从 float32 降低到 float16 或 int8 可以减少内存使用量并提高吞吐量，同时将精度损失降到最低。知识蒸馏等技术可以创建更小的模型来近似更大的模型。这些优化需要仔细评估——精度降低有时会对模型质量造成不可接受的损害，尤其是在您的领域中。

GPU资源管理至关重要。GPU价格昂贵，而且许多团队共享GPU集群。因此，必须实施资源配额和优先级调度。高优先级推理请求应优先于低优先级批处理作业。耗时的训练不应占用所有GPU资源。NVIDIA GPU Manager等工具可以帮助公平地分配稀缺资源。

4.部署策略和金丝雀发布

部署新模型或进行基础设施变更都存在风险。部署错误可能会降低所有用户的体验质量。金丝雀发布可以缓解这种情况：新版本首先部署到一小部分流量中，然后随着信心的增强逐步推广到更多用户。

在负载均衡器层级实施流量拆分。初始阶段将 5% 的流量分配到新版本，监控各项指标，然后逐步增加到 10%、25%、50%，最终达到 100%。如果出现任何异常情况，则将所有流量回滚到旧版本。

蓝绿部署是另一种模式：维护两个完全相同的生产环境（蓝色和绿色）。旧版本运行在蓝色环境中，新版本运行在绿色环境中。绿色环境经过测试和验证后，将流量切换到新版本。如果出现问题，则切换回蓝色环境。这样可以实现即时回滚。

关键的最佳实践是在部署前、部署中和部署后都采用全面的指标。您需要了解部署是否导致了性能下降。比较不同版本之间的延迟、错误率、输出质量和业务指标。设定阈值：如果延迟增加超过 5% 或错误率超过 0.5%，则自动回滚。

5.自动扩展和成本优化

云基础设施具有弹性——您可以根据需要添加资源，并在不需要时移除资源。智能自动扩展功能可在保持性能的同时，有效控制成本。

实现基于指标的自动扩缩容。当 CPU 利用率或请求队列长度超过阈值时，增加实例；当它们低于阈值时，移除实例。Kubernetes 水平 Pod 自动扩缩器 (HPA) 会自动处理容器化工作负载的这一过程。

基于计划的扩展也至关重要。如果您的系统流量模式可预测（工作时间繁忙，夜间空闲），请提前进行扩展。不要等到指标显示过载才进行扩展；在高峰时段到来之前就增加容量。

最佳实践是成本可视化和优化。按服务、模型和请求类型跟踪支出。了解系统中哪些部分成本高昂。有时，只需进行一些小的优化（例如模型压缩），就能以最小的努力节省大量资金。Kubecost 等 Kubernetes 工具可以提供这种可视化效果。

6.容器注册和ECR/GCR管理

容器镜像会迅速积累。如果没有管理，镜像仓库的存储成本会变得很高，部署速度也会变慢。因此，需要实施镜像清理策略：删除超过 N 天的镜像，或者只保留每个服务的最新 M 个版本。

对镜像文件使用语义化版本控制。版本号应反映变更内容：主版本号用于表示重大变更，次版本号用于表示新增功能，补丁版本号用于表示错误修复。这有助于团队了解兼容性并做出部署决策。

第四部分：可观测性和优化——健康状况和性能

1.可观测性支柱：追踪、指标和日志记录

可观测性是指通过检查系统的输出来了解系统内部运行状况的能力。它与监控不同：监控告诉你哪里出了问题，而可观测性则帮助你理解问题的原因。

可观测性基于三大支柱。追踪功能跟踪系统中的请求，显示哪些组件处理了每个请求以及时间都花费在了哪些地方。指标是数值测量值：延迟、吞吐量、错误率、GPU 利用率。日志记录功能捕获离散事件：代理决策、工具调用、错误。

将这三者结合起来实施。指标会告诉你存在问题（延迟飙升）。追踪可以帮助你精确定位问题所在（推理速度变慢）。日志会解释原因（模型被替换，导致重新编译）。

最佳实践是结构化日志记录。不要编写自由格式的日志消息。相反，应生成包含固定字段的结构化日志，例如：时间戳、级别、服务名称、请求 ID 和消息。这样可以使日志可查询和可聚合。ELK（Elasticsearch、Logstash、Kibana）等工具或云原生解决方案（CloudWatch、Cloud Logging）可以智能地搜索和分析日志。

2.追踪代理工作流

对于智能体系统而言，追踪尤为重要，因为其工作流程十分复杂：一个智能体可能调用多个工具，每个工具又可能调用下游服务，而且故障可能会级联发生。分布式追踪能够揭示全局情况。

使用标准追踪库（OpenTelemetry 已逐渐成为标准库），并确保每个操作都会创建 span。当代理调用工具时，就创建了一个 span。当工具调用数据库时，就创建了一个子 span。完整的 span 树展示了工作流程在系统中的流转方式以及时间的消耗情况。

在合适的抽象层次上进行检测。你需要对主要操作（例如 agent.reason、tool.invoke、rag.retrieve）进行跨度检测，但不需要对每一行代码都进行检测——那样噪音太大。要在细节和信噪比之间找到平衡点。

一项关键的最佳实践是建立贯穿整个系统的关联 ID。在入口点为每个用户请求分配一个唯一的 ID。将此 ID 传递给每个服务、每次数据库调用和每条日志消息。这样，您就可以重现用户在系统中的完整操作路径。

3.指标和绩效监控

指标应同时反映系统健康状况和业务成果。常用指标包括延迟（请求所需时间）、吞吐量（每秒请求数）、错误率（失败比例）和资源利用率（CPU、内存、GPU）。

具体到人工智能系统，还要跟踪其他指标：令牌使用情况（模型消耗了多少令牌？）、模型调用次数（每个模型被调用了多少次？）、嵌入延迟（向量搜索需要多长时间？）、工具调用成功率（代理使用工具时，是否成功？）。

应该采用基于百分位数的指标，而不是仅仅使用平均值。平均延迟可能会掩盖重要的性能下降。如果第 99 百分位数的延迟突然增加，而平均值保持不变，则说明大多数用户体验良好，但部分用户可能正经历糟糕的体验。因此，需要跟踪第 50 百分位数、第 95 百分位数和第 99 百分位数的延迟。

明智地使用告警功能。不要对每个指标偏差都发出告警——否则你会感到告警疲劳。只对真正重要的事件发出告警：例如错误率超过阈值、延迟显著增加或资源利用率出现问题。根据你的服务级别目标 (SLO) 设置阈值。

4.评估和持续改进

对于人工智能系统而言，判断输出结果是否正确是一项挑战。评估必须是系统的一部分。应实施持续评估质量的机制。

自动采集评估数据。当客服人员回复查询时，采集回复内容以及用户反馈（如有）。用户是否觉得回复有用？他们是否需要后续跟进？记录这些信息。

实施结构化评估框架。对于 RAG 系统，衡量检索质量：检索到的文档是否包含回答查询所需的信息？对于智能体，衡量任务完成情况：智能体是否成功完成其目标？构建自动化测试，以便在更改模型或流程时捕获回归问题。

最佳实践是采用影子模式进行评估。将组件的新版本（例如新的嵌入模型、新的代理提示）与生产版本并行运行，比较它们的行为，而不会影响面向用户的结果。这样，您就可以在更改影响用户之前对其进行评估。

5.微调和基于LoRA的优化

有时候，通用模型并不完全适用于你的领域。微调可以将模型调整到你的特定用例中。然而，对所有模型进行微调成本高昂，并且会带来维护方面的挑战。

使用LoRA（低秩自适应）及类似的参数高效微调方法。LoRA 并非更新所有模型权重，而是添加小型可学习矩阵来调整模型。这在保持灵活性的同时，显著降低了内存需求和训练时间。

将微调后的模型与基础模型一起进行版本控制。跟踪哪个微调后的版本正在生产环境中使用，以便您可以重现结果并了解它与基础模型之间的差异。

一项关键的最佳实践是基于评估的微调。不要凭空猜测进行微调。通过评估识别具体的故障模式，收集相关数据，并进行微调以解决这些问题。这确保了微调能够改善实际问题，而不是仅仅为了优化虚荣指标。

6.量化优化

模型量化可以降低内存占用并改善延迟。将 float32 量化为 float16 可以将内存占用减少一半。int8 量化可以进一步降低内存占用。对于许多应用来说，量化模型与全精度模型几乎没有区别。

量化有多种形式。训练后量化适用于已训练好的模型，无需重新训练。量化感知训练将量化融入训练过程，通常能带来更好的模型质量。动态量化则在推理阶段应用量化。

最佳实践是在量化后进行仔细评估，衡量质量下降情况。对于某些模型和任务，量化的影响微乎其微；而对于另一些模型和任务，量化则会造成显著影响。只有在验证质量达到可接受水平后，才能部署量化后的模型。

7.整合所有内容：系统一致性

理解各个组成部分固然重要，但只有当它们协同运作时，才能真正发挥其作用。代理编排层需要了解 RAG 的功能并加以调用。基础设施必须同时支持有状态的代理交互和无状态推理。可观测性必须能够跟踪代理的决策、知识引擎的检索以及基础设施的资源使用情况。

最佳实践是考虑端到端数据流和延迟预算。用户查询进入系统。编排层需要推理该如何操作（这需要时间和令牌）。它调用 RAG 来检索信息（这需要时间）。它通过服务层调用工具（这需要时间）。最后，它生成响应。总延迟是这些组成部分延迟的总和。了解延迟预算：在不违反延迟 SLO 的前提下，每个组成部分可以花费多少时间？

类似地，追踪数据流。用户查询会经过编排流程，编排流程会调用 RAG，RAG 会查询向量数据库，向量数据库可能会调用知识摄取管道，知识摄取管道的输出会由评估系统进行评估。可观测性需要覆盖整个流程。RAG 摄取日志可以帮助我们了解编排流程中存在的问题。