这是一个相当复杂的系统。将从最简单的架构开始，逐步（Step by Step）添加更多组件。在最简单的形式中，应用程序接收查询并将其发送到模型。模型生成响应，并将其返回给用户。没有护栏，没有增强上下文，也没有优化。模型 API框指的是第三方 API（例如 OpenAI、Google、Anthropic）和自托管 API。

从这里，可以根据需要逐步添加更多组件：

• 通过让模型访问外部数据源和信息收集工具（RAG、Agentic RAG），增强模型的上下文输入。
• 设置护栏来保护系统和用户。
• 添加模型路由器和网关以支持复杂的管道并增加更多安全性。
• 使用缓存（Prompt 、Exact、Semantic cache）优化延迟和成本。

• 添加复杂逻辑和写操作以最大化系统的能力。

可观测性，它可以让你对系统进行监控和调试以获得可见性，以及编排，它涉及将所有组件串联在一起，是平台的两个基本组成部分。

Step 1.  上下文增强（RAG）

上下文学习，即从上下文中学习，是一种持续学习的形式。它使模型能够不断吸收新信息来做出决策，防止其过时。例如，使用上周数据训练的模型将无法回答有关本周的问题，除非其情境中包含新信息。通过使用最新信息（例如 fancy-printer-A300 的最新规格）更新模型的上下文，该模型将保持最新状态，并可以在截止日期之后响应查询。

1.1 RAGs

最著名的上下文构建模式是RAG，即检索增强生成。RAG由两个组件组成：生成器（例如语言模型）和检索器，后者从外部来源检索相关信息。

• 基于Term的检索

• 基于嵌入的检索（也称为向量搜索）

• 召回率：算法找到的最近邻的比例。
• 每秒查询数（QPS）：算法每秒能够处理的查询数量。这对于高流量应用至关重要。
• 构建时间：构建索引所需的时间。如果你需要频繁更新索引（例如，因为你的数据发生变化），这个指标尤其重要。
• 索引大小：算法创建的索引的大小，这对于评估其可扩展性和存储需求至关重要。

1.2 包含表格数据的RAGs

• 文本到 SQL：根据用户查询和表模式，确定需要什么 SQL 查询。

• SQL 执行：执行 SQL 查询。

• 生成：根据 SQL 结果和原始用户查询生成响应。

1.3 Agentic RAGs

互联网是数据的一个重要来源。像 Google 或 Bing API 这样的网络搜索工具可以让模型访问丰富的最新资源，以收集每个查询的相关信息。例如，给定查询“今年谁获得了奥斯卡奖？”，系统会搜索有关最新奥斯卡奖的信息，并使用此信息生成对用户的最终回复。

基于Term的检索、基于嵌入的检索、SQL 执行和 Web 搜索是模型可以采取的操作，以增强其上下文。可以将每个操作视为模型可以调用的函数。可以合并外部操作的工作流也称为agentic。

Agentic RAGs架构

» Action vs 工具 «

一个工具允许执行一项或多项操作。例如，人员搜索工具可能允许执行两项操作：按姓名搜索和按电子邮件搜索。但是，两者之间的区别很小，因此会交替使用action和工具。

» 只读actions与写入actions «

从外部源检索信息但不改变其状态的操作是只读actions。赋予模型写入actions（例如更新表中的值）可使模型执行更多任务，但也会带来更多风险。

1.4 查询重写

通常，需要重写用户查询以增加获取正确信息的可能性。考虑以下对话。

User: When was the last time John Doe bought something from us?AI: John last bought a Fruity Fedora hat from us two weeks ago, on January 3, 2030.User: How about Emily Doe?

最后一个问题“Emily Doe 怎么样？”含糊不清。如果逐字使用此查询来检索文档，则可能会得到不相关的结果。需要重写此查询以反映用户实际询问的内容。新查询本身应该有意义。最后一个问题应该重写为“Emily Doe 上次从我们这里买东西是什么时候？”

查询重写通常使用其他 AI 模型来完成，使用类似于“给定以下对话，重写最后的用户输入以反映用户实际询问的内容”的提示。

查询重写可能会变得很复杂，特别是当需要进行身份解析或整合其他知识时。如果用户问“他的妻子怎么样？”，首先需要查询数据库以找出他的妻子是谁。如果没有这些信息，重写模型应该承认这个查询是不可解决的，而不是产生一个名字的幻觉，从而导致错误的答案。

Step 2.  设置护栏

护栏有助于降低 AI 风险，不仅保护您的用户，还保护开发人员。只要有可能出现故障，就应该设置护栏。这篇文章讨论了两种类型的护栏：输入护栏和输出护栏。

2.1 输入护栏

输入护栏通常可以防止两种类型的风险：将私人信息泄露给外部 API，以及执行危害系统的恶意提示（模型越狱）。

向外部 API 泄露私人信息

此风险特定于使用外部模型 API，即当你需要将数据发送到组织外部时。例如，员工可能会将公司的机密或用户的私人信息复制到提示中，并将其发送到托管模型的任何地方。
早期最引人注目的事件之一是三星员工将三星的专有信息放入 ChatGPT 中，意外泄露了公司的机密。目前尚不清楚三星是如何发现这次泄密的，以及泄露的信息是如何被用来对付三星的。然而，这起事件的严重性足以让三星在 2023 年 5 月禁止使用 ChatGPT。
使用第三方 API 时，没有万无一失的方法可以消除潜在的泄漏。但是，你可以使用护栏来缓解它们。你可以使用许多可用的自动检测敏感数据的工具之一。要检测哪些敏感数据由你指定。常见的敏感数据类别有：

• 个人信息（身份证号码、电话号码、银行账户）。

• 人类的面孔。

• 与公司知识产权或特权信息相关的特定关键字和短语。

许多敏感数据检测工具使用 AI 来识别潜在的敏感信息，例如确定字符串是否类似于有效的家庭住址。如果发现查询包含敏感信息，您有两个选择：阻止整个查询或从中删除敏感信息。例如，可以使用占位符 [PHONE NUMBER] 屏蔽用户的电话号码。如果生成的响应包含此占位符，请使用 PII 可逆字典将此占位符映射到原始信息，以便您可以取消屏蔽，如下所示。

模型越狱

试图越狱人工智能模型，让它们说坏话或做坏事，已经成为一项在线运动。虽然有些人可能会觉得让 ChatGPT 发表有争议的言论很有趣，但如果客户支持聊天机器人（带有您的名称和徽标）做同样的事情，那就没那么有趣了。这对于有权使用工具的人工智能系统来说尤其危险。想象一下，如果用户找到一种方法让系统执行破坏数据的 SQL 查询。
为了解决这个问题，应该首先在系统上设置护栏，以便不会自动执行任何有害操作。例如，未经人工批准，不能执行可以插入、删除或更新数据的 SQL 查询。这种增加的安全性的缺点是它会降低系统速度。

为了防止应用程序发表不该发表的离谱言论，可以为应用程序定义超出范围的主题。例如，如果应用程序是客户支持聊天机器人，它就不应该回答政治或社会问题。一个简单的方法是过滤掉包含通常与有争议的话题相关的预定义短语的输入，例如“移民”或“反疫苗”。更复杂的算法使用人工智能来分类输入是否与预定义的受限主题之一有关。
如果系统中的有害提示很少见，可以使用异常检测算法来识别不寻常的提示。

2.2 输出护栏

AI 模型是概率性的，因此其输出不可靠。可以设置护栏来显著提高应用程序的可靠性。输出护栏有两个主要功能：

• 评估每一次生成的质量。

• 指定处理不同故障模式的策略。

输出质量测量

要发现不符合标准的输出，需要了解故障是什么样子的。以下是故障模式的示例及其发现方法。

• 空的回应。

• 格式错误的响应不符合预期的输出格式。例如，如果应用程序需要 JSON，而生成的响应缺少右括号。有些验证器适用于某些格式，例如正则表达式、JSON 和 Python 代码验证器。还有一些用于约束抽样的工具，例如指导、大纲和讲师。

• 有害反应，例如种族主义或性别歧视的反应。可以使用多种毒性检测工具之一来捕获这些反应。

• 模型产生的幻觉是事实不一致的反应。幻觉检测是一个活跃的研究领域，其解决方案包括SelfCheckGPT和SAFE、搜索引擎事实性评估器。可以通过为模型提供足够的背景信息和提示技术（例如思路链）来缓解幻觉。

• 包含敏感信息的回复。这可能发生在两种情况下。

• 模型已针对敏感数据进行了训练并将其重新输出。

• 系统从内部数据库检索敏感信息以丰富其上下文，然后将该敏感信息传递给响应。

可以通过不针对敏感数据训练模型并首先不允许其检索敏感数据来防止这种故障模式。可以使用与输入护栏相同的工具来检测输出中的敏感数据。

• 品牌风险响应，例如错误描述贵公司或竞争对手的响应。例如，当由 X 训练的模型 Grok 生成一个响应，暗示 Grok 是由 OpenAI 训练的，这导致互联网怀疑 X 窃取了 OpenAI 的数据。这种故障模式可以通过关键字监控来缓解。一旦确定了与品牌和竞争对手相关的输出，就可以阻止这些输出，将它们传递给人工审核员，或者使用其他模型来检测这些输出的情绪，以确保只返回正确的情绪。

• 通常情况下，回答都很糟糕。例如，如果要求模型写一篇文章，而那篇文章写得很糟糕，或者你要求模型提供低热量蛋糕食谱，而生成的食谱含有过多的糖。使用人工智能评判员来评估模型回答的质量已经成为一种流行的做法。这些人工智能评判员可以是通用模型（比如 ChatGPT、Claude），也可以是经过训练的专门评分员，他们可以根据查询对回答输出具体的分数。

故障管理

AI 模型是概率性的，这意味着如果您再次尝试查询，可能会得到不同的响应。许多故障可以通过使用基本的重试逻辑来缓解。例如，如果响应为空，请重试 X 次或直到您得到非空响应。同样，如果响应格式不正确，请重试，直到模型生成格式正确的响应。

但是，这种重试策略可能会产生额外的延迟和成本。一次重试意味着 API 调用次数增加 2 倍。如果在失败后进行重试，则用户所经历的延迟将增加一倍。为了减少延迟，可以并行进行调用。例如，对于每个查询，不必等待第一个查询失败后再重试，而是同时将此查询发送到模型两次，获得两个响应，然后选择更好的一个。这会增加冗余 API 调用的数量，但保持延迟可控。

依靠人工来处理棘手的查询也很常见。例如，如果查询包含特定的关键短语，则可以将其转交给人工操作员。一些团队使用专门的模型（可能在内部训练）来决定何时将对话转交给人工。例如，当情绪分析模型检测到用户生气时，一个团队会将对话转交给人工操作员。另一个团队在一定次数后转移对话，以防止用户陷入无限循环。

2.3 护栏权衡

可靠性与延迟的权衡：虽然承认护栏的重要性，但一些团队告诉我，延迟更重要。他们决定不实施护栏，因为护栏会显著增加应用程序的延迟。然而，这些团队是少数。大多数团队发现，增加的风险比增加的延迟更昂贵。

在流完成模式下，输出防护措施可能无法正常工作。默认情况下，整个响应在显示给用户之前生成，这可能需要很长时间。在流完成模式下，新令牌在生成时会流式传输给用户，从而减少用户等待查看响应的时间。缺点是很难评估部分响应，因此在系统防护措施确定应阻止不安全的响应之前，它们可能会被流式传输给用户。

自托管与第三方 API 的权衡：自托管模型意味着不必将数据发送给第三方，从而减少了对输入护栏的需求。然而，这也意味着您必须自己实现所有必要的护栏，而不是依赖第三方服务提供的护栏。

护栏可以是独立的工具，也可以是模型网关的一部分。如果使用评分器，则将其归类在模型 API 下，因为评分器通常也是 AI 模型。用于评分的模型通常比用于生成的模型更小、更快。

Step 3.  添加模型路由器和网关

随着应用程序变得越来越复杂并且涉及更多的模型，出现了两种类型的工具来处理多种模型：路由器和网关。

3.1 路由器

应用程序可以使用不同的模型来响应不同类型的查询。针对不同的查询提供不同的解决方案有几个好处。首先，这允许拥有专门的解决方案，例如一个专门用于技术故障排除的模型和另一个专门用于订阅的模型。专用模型的性能可能比通用模型更好。其次，这可以节省成本。可以将更简单的查询路由到更便宜的模型，而不是将所有查询路由到昂贵的模型。

路由器通常由一个意图分类器组成，该分类器可以预测用户想要做什么。根据预测的意图，查询将被路由到适当的解决方案。例如，对于客户支持聊天机器人，如果意图是：

• 要重置密码 –> 将此用户引导至有关密码重置的页面。

• 要纠正计费错误 –> 将此用户转接给人工操作员。

• 要解决技术问题 –> 将此查询路由到针对故障排除进行微调的模型。

意图分类器还可以帮助您的系统避免超出范围的对话。例如，可以使用意图分类器来预测查询是否超出范围。如果查询被视为不合适（例如，如果用户询问您将在即将到来的选举中投票给谁），聊天机器人可以使用其中一个常规回复（“作为聊天机器人，我没有投票权。如果您对我们的产品有疑问，我很乐意为您提供帮助。”）礼貌地拒绝参与，而不会浪费 API 调用。

如果系统可以访问多个操作，路由器可以包含下一步操作预测器，以帮助系统决定下一步要采取什么操作。如果查询不明确，则一个有效的操作是要求澄清。例如，在响应查询“冻结”时，系统可能会问：“您想冻结您的帐户还是在谈论天气？”或者简单地说，“对不起。你能详细说明一下吗？”

意图分类器和下一步行动预测器可以是通用模型或专用分类模型。专用分类模型通常比通用模型小得多且速度快得多，因此系统可以使用多个专用分类模型，而不会产生显著的额外延迟和成本。

当将查询路由到具有不同上下文限制的模型时，查询的上下文可能需要进行相应调整。假设一个包含 1,000 个标记的查询，该查询适用于具有 4K 上下文限制的模型。然后系统执行操作（例如网络搜索），该操作会返回 8,000 个标记上下文。可以截断查询的上下文以适应最初预期的模型，也可以将查询路由到具有更大上下文限制的模型。

3.2 网关

模型网关是一个中间层，可让组织以统一且安全的方式与不同的模型进行交互。模型网关的最基本功能是让开发人员能够以相同的方式访问不同的模型 - 无论是自托管模型还是 OpenAI 或 Google 等商业 API 背后的模型。模型网关使维护代码变得更加容易。如果模型 API 发生变化，只需更新模型网关，而不必更新使用此模型 API 的所有应用程序。

最简单的模型网关形式是一个统一的包装器，如以下代码示例所示。此示例旨在了解如何实现模型网关。它不具备功能性，因为它不包含任何错误检查或优化。

import google.generativeai as genaiimport openai
def openai_model(input_data, model_name, max_tokens):openai.api_key = os.environ["OPENAI_API_KEY"]response = openai.Completion.create(engine=model_name,prompt=input_data,max_tokens=max_tokens)return {"response": response.choices[0].text.strip()}
def gemini_model(input_data, model_name, max_tokens):genai.configure(api_key=os.environ["GOOGLE_API_KEY"])model = genai.GenerativeModel(model_name=model_name)response = model.generate_content(input_data, max_tokens=max_tokens)return {"response": response["choices"][0]["message"]["content"]}
@app.route('/model', methods=['POST'])def model_gateway():data = request.get_json()model_type = data.get("model_type")model_name = data.get("model_name")input_data = data.get("input_data")max_tokens = data.get("max_tokens")
if model_type == "openai":result = openai_model(input_data, model_name, max_tokens)elif model_type == "gemini":result = gemini_model(input_data, model_name, max_tokens)return jsonify(result)

模型网关是访问控制和成本管理。不必向所有想要访问 OpenAI API 的人提供的组织tokens（这些tokens很容易泄露），而只需向人们提供模型网关的访问权限，从而创建一个集中且受控的访问点。网关还可以实现细粒度的访问控制，指定哪个用户或应用程序应该有权访问哪个模型。此外，网关可以监控和限制 API 调用的使用，从而防止滥用并有效管理成本。

模型网关还可用于实施回退策略，以克服速率限制或 API 故障（不幸的是后者很常见）。当主要 API 不可用时，网关可以将请求路由到替代模型，短暂等待后重试，或以其他优雅的方式处理故障。这可确保您的应用程序能够顺利运行而不会中断。

由于请求和响应已经流经网关，因此它是实现其他功能（如负载平衡、日志记录和分析）的好地方。一些网关服务甚至提供缓存和护栏。

由于网关的实现相对简单，因此有许多现成的网关。例如 Portkey 的网关、MLflow AI 网关、WealthSimple 的llm-gateway、TrueFoundry、Kong和Cloudflare。

随着网关和路由器的增加，生成式AI平台变得更加精彩。与评分一样，路由也位于模型网关中。与用于评分的模型一样，用于路由的模型通常比用于生成的模型小。

Step 4.  使用缓存减少延迟

4.1 提示缓存

4.2 精确缓存

4.3 语义缓存

• 对于每个查询，使用嵌入模型生成其嵌入。
• 使用向量搜索找到最接近当前查询嵌入的缓存嵌入。假设此相似度得分为 X。
• 如果 X 小于您设置的相似度阈值，则认为缓存查询与当前查询相同，并返回缓存结果。如果不相同，则处理此当前查询并将其与其嵌入和结果一起缓存。

Step 5.  添加复杂逻辑与写动作

到目前为止，讨论过的应用程序的流程相当简单。基础模型生成的输出大部分返回给用户（除非他们没有通过护栏）。但是，应用程序流程可能会更复杂，包含循环和条件分支。模型的输出还可用于调用写入操作，例如撰写电子邮件或下订单。

5.1 复杂逻辑

一个模型的输出可以有条件地传递到另一个模型，或作为下一步输入的一部分反馈给同一个模型。这个过程一直持续到系统中的某个模型决定任务已完成，并应将最终响应返回给用户。

当让系统能够规划并决定下一步做什么时，就会发生这种情况。例如，考虑查询“规划巴黎周末行程”。该模型可能首先生成一个潜在活动列表：参观埃菲尔铁塔、在咖啡馆吃午餐、游览卢浮宫等。然后可以将每一项活动反馈到模型中以生成更详细的计划。例如，“参观埃菲尔铁塔”可以促使模型生成子任务，例如查看开放时间、购买门票和查找附近的餐馆。这个迭代过程持续进行，直到创建全面而详细的行程。

基础设施现在有一个箭头，将生成的响应指向上下文构建，然后再反馈给模型网关中的模型。

5.2 写操作

用于构建上下文的操作是只读操作。它们允许模型从其数据源读取以收集上下文。但系统也可以有写操作，对数据源和世界进行更改。例如，如果模型输出：“向 X 发送一封包含消息 Y 的电子邮件”，系统将调用该操作send_email(recipient=X, message=Y)。

写操作使系统功能更加强大。它们可以让你自动化整个客户拓展工作流程：研究潜在客户、寻找他们的联系人、起草电子邮件、发送第一封电子邮件、阅读回复、跟进、提取订单、用新订单更新数据库等。

然而，让人工智能自动改变我们生活的前景令人恐惧。就像你不应该让实习生有权删除你的生产数据库一样，你也不应该允许不可靠的人工智能发起银行转账。对系统功能及其安全措施的信任至关重要。你需要确保系统受到保护，以免被那些试图操纵系统执行有害操作的坏人所利用。

与其他软件系统一样，人工智能系统也容易受到网络攻击，但它们还有另一个弱点：提示注入。提示注入是指攻击者操纵输入提示进入模型，使其表现出不良行为。可以将提示注入视为针对人工智能而非人类进行的社会工程。

许多公司担心的情况是，他们让人工智能系统访问其内部数据库，而攻击者会诱骗该系统泄露这些数据库中的私人信息。如果系统对这些数据库具有写权限，攻击者可以诱骗系统破坏数据。

任何想要利用人工智能的组织都需要认真对待安全问题。然而，这些风险并不意味着人工智能系统永远不应该被赋予在现实世界中行动的能力。人工智能系统可能会失败，但人类也会失败。如果我们能让人们相信机器能带我们进入太空，希望有一天，安全问题足以让我们信任自主人工智能系统。

5.3 可观察性

虽然将可观察性放在了单独的部分，但它应该从一开始就集成到平台中，而不是事后才添加。可观察性对于各种规模的项目都至关重要，其重要性随着系统的复杂性而增长。

可观察性的所有细微差别并未全部涵盖，仅简要概述监控的三大支柱：日志、追踪和指标。关于用户反馈、偏差检测和调试就不过多介绍了。

指标

讨论监控时，大多数人都会想到指标。要跟踪哪些指标取决于想要跟踪系统的哪些方面，这些指标与应用程序相关。但是，一般来说，需要跟踪两种类型的指标：模型指标和系统指标。

系统指标可以告诉整个系统的状态。常见指标包括吞吐量、内存使用率、硬件利用率以及服务可用性/正常运行时间。系统指标是所有软件工程应用程序所共有的。

模型指标评估模型的性能，例如准确度、毒性和幻觉率。应用程序管道中的不同步骤也有自己的指标。例如，在 RAG 应用程序中，检索质量通常使用上下文相关性和上下文精度来评估。向量数据库可以通过索引数据所需的存储空间以及查询数据所需的时间来评估

模型输出失败的原因有很多种。识别这些问题并制定指标来监控这些问题至关重要。例如，可能希望跟踪模型超时、返回空响应或生成格式错误的响应的频率。如果担心模型泄露敏感信息，请找到一种方法来跟踪这些信息。

与长度相关的指标（例如查询、上下文和响应长度）有助于了解模型的行为。一个模型是否比另一个模型更冗长？某些类型的查询是否更有可能导致冗长的答案？它们对于检测应用程序中的变化特别有用。如果平均查询长度突然减少，则可能表明存在需要调查的潜在问题。

长度相关指标对于跟踪延迟和成本也很重要，因为较长的上下文和响应通常会增加延迟并产生更高的成本。

跟踪延迟对于了解用户体验至关重要。常见的延迟指标包括：

• 第一个令牌的时间(TTFT)：生成第一个令牌所需的时间。

• 令牌间隔时间（TBT）：每个令牌生成之间的间隔。

• 每秒令牌数(TPS)：生成令牌的速率。

• 每个输出令牌的时间（TPOT）：生成每个输出令牌所需的时间。

• 总延迟：完成响应所需的总时间。

还需要跟踪成本。与成本相关的指标包括查询数量以及输入和输出令牌的数量。如果使用具有速率限制的 API，则跟踪每秒的请求数非常重要，以确保保持在分配的限制范围内并避免潜在的服务中断。

计算指标时，可以选择抽样检查或详尽检查。抽样检查涉及对数据子集进行抽样以快速识别问题，而详尽检查则评估每个请求以获得全面的性能视图。选择取决于您的系统要求和可用资源，两者结合可提供平衡的监控策略。

计算指标时，确保可以按相关轴（例如用户、发布、提示/链版本、提示/链类型和时间）进行细分。这种粒度有助于了解性能变化并识别特定问题。

日志

日志的理念很简单：记录一切。记录系统配置。记录查询、输出和中间输出。记录组件的启动、结束、崩溃等时间。记录日志时，请确保为其添加标签和 ID，这样可以帮助了解此日志来自系统的哪个位置。

记录所有内容意味着日志量会快速增长。许多用于自动日志分析和日志异常检测的工具都由 AI 提供支持。

虽然不可能手动处理日志，但每天手动检查生产数据以了解用户如何使用的应用程序很有用。随着开发人员与更多数据的交互，他们对好输出和坏输出的看法会发生变化，这使得他们既可以重写提示以增加获得良好响应的机会，也可以更新评估流程以捕捉不良响应。

追踪

追踪是指对请求通过各种系统组件和服务的执行路径进行详细记录。在 AI 应用程序中，追踪揭示了从用户发送查询到返回最终响应的整个过程，包括系统采取的操作、检索到的文档以及发送给模型的最终提示。它还应显示每个步骤所需的时间及其相关成本（如果可衡量）。例如，这是Langsmith跟踪的可视化。

理想情况下，应该能够逐步跟踪每个查询在系统中的转换。如果查询失败，您应该能够准确指出出错的确切步骤：是处理有误、检索到的上下文不相关，还是模型生成了错误的响应。

5.4 AI管道编排

AI应用程序可能相当复杂，包含多个模型、从多个数据库检索数据，并且可以使用各种工具。编排器可帮助指定如何将这些不同的组件组合（串联）在一起以创建端到端的应用程序流程。

从高层次上看，编排器的工作分为两个步骤：组件定义和串联（也称为流水线）。

• 组件定义
  需要告诉编排器您的系统使用哪些组件，例如模型（包括用于生成、路由和评分的模型）、系统可以从中检索数据的数据库以及系统可以采取的操作。与模型网关直接集成可以帮助简化模型入门，并且一些编排器工具希望成为网关。许多编排器还支持与评估和监控工具集成。

• 串联（或流水线）
  告诉编排器系统从接收用户查询到完成任务所采取的步骤顺序。简而言之，串联只是函数组合。以下是流水线的示例。

  编排器负责在步骤之间传递数据，并提供工具来帮助确保当前步骤的输出符合下一步所需的格式。

1. 处理原始查询。

2. 根据处理后的查询检索相关数据。

3. 原始查询和检索到的数据结合在一起，创建符合模型预期格式的提示。

4. 模型根据提示生成响应。

5. 评估响应。

6. 如果响应被认为良好，则将其返回给用户。如果不好，则将查询路由给人工操作员。

编排器负责在步骤之间传递数据，并可以提供工具，帮助确保当前步骤的输出格式是下一个步骤所期望的。

在为具有严格延迟要求的应用程序设计管道时，尽可能多地并行执行。例如，如果有一个路由组件（决定将查询发送到哪里）和一个PII（个人身份信息） 删除组件，它们可以同时执行这两项操作。

有很多 AI 编排工具，包括LangChain、LlamaIndex、Flowise、Langflow和Haystack。每个工具都有自己的 API，不在这里展示实际的代码。

虽然在启动项目时直接使用编排工具很诱人，但首先不要使用编排工具来构建应用程序。任何外部工具都会增加复杂性。编排器可以抽象出系统工作原理的关键细节，使理解和调试系统变得困难。

随着您进入应用程序开发过程的后期阶段，可能会决定使用编排器可以让任务更轻松。在评估编排器时，牢记以下三个方面。

• 集成和可扩展性
  评估编排器是否支持已在使用或将来可能采用的组件。例如，如果想使用 Llama 模型，请检查编排器是否支持该模型。考虑到有多少模型、数据库和框架，编排器不可能支持所有内容。因此，还需要考虑编排器的可扩展性。如果它不支持特定组件，那么改变它有多难？

• 支持复杂管道
  随着应用程序的复杂性不断增加，可能需要管理涉及多个步骤和条件逻辑的复杂管道。支持分支、并行处理和错误处理等高级功能的编排器将帮助您高效管理这些复杂性。

• 易用性、性能和可扩展性
  考虑编排器的用户友好性。寻找直观的 API、全面的文档和强大的社区支持，因为这些可以大大减少团队的学习曲线。避免使用会发起隐藏 API 调用或给您的应用程序带来延迟的编排器。此外，确保编排器能够随着应用程序、开发人员和流量数量的增长而有效扩展。

6. 结论

从基本架构开始，然后逐渐添加组件以应对日益增长的应用程序复杂性。每增加一个组件都会带来一系列好处和挑战，需要仔细考虑和实施。

虽然组件分离对于保持系统模块化和可维护性很重要，但这种分离是流动的。组件之间有很多重叠。例如，模型网关可以与护栏共享功能。缓存可以在不同的组件中实现，例如在矢量搜索和推理服务中。

全文1.36万字，但还有很多细节还没有进一步探讨，尤其是关于可观察性、上下文构建、复杂逻辑、缓存和护栏。