书接上回，继续往下讲,本节会说一下复杂逻辑，可观测性和Pipeline
添加复杂逻辑和写入操作
到目前为止，我们讨论的应用程序具有相当简单的流程。
基础模型生成的输出大多返回给用户（除非它们没有通过护栏）。
但是，应用程序流可能更复杂，包括循环和条件分支。
模型的输出还可用于调用写入操作，例如撰写电子邮件或下订单。
1. 复杂逻辑
模型的输出可以有条件地传递给另一个模型，也可以作为下一步输入的一部分反馈给同一模型。
这种情况一直持续到系统中的模型决定任务已完成并且应将最终响应返回给用户。
为系统提供规划和决定下一步操作的能力时，可能会发生这种情况。
例如，考虑查询 "Plan a weekend itinerary for Paris"。
该模型可能首先生成一个潜在活动列表：
参观埃菲尔铁塔、在咖啡馆吃午饭、游览卢浮宫等。
然后，这些活动中的每一个都可以反馈到模型中，以生成更详细的计划。
例如，"参观埃菲尔铁塔"可以提示模型生成子任务。
例如检查营业时间、购买门票和查找附近的餐馆。
这个迭代过程会一直持续，直到创建全面而详细的行程。
2. 写入操作
用于上下文构造的操作是只读操作。
它们允许模型从其数据源中读取数据以收集上下文。
但系统也可以编写操作，对数据源和世界进行更改。
例如，如果模型输出："send an email to X with message Y"，
则系统将调用操作 send_email(recipient=X, message=Y) 。
然而，赋予 AI 自动改变我们生活的能力的前景令人恐惧。
写入操作使系统的功能大大增强。
它们可以能够自动化整个客户拓展工作流程：
研究潜在客户、寻找他们的联系人、起草电子邮件、
发送第一封电子邮件、阅读回复、跟进、提取订单、使用新订单更新数据库等。
就像不应该授予实习生删除生产数据库的权限一样，也不应该允许不可靠的 AI 发起银行转账。
对系统功能及其安全措施的信任至关重要。
需要确保系统受到保护，免受可能试图操纵系统执行有害操作的不良行为者的侵害。
AI 系统与其他软件系统一样容易受到网络攻击，但它们也有另一个弱点：prompt注入。
当攻击者将输入提示操纵到模型中以使其表达不良行为时，就会发生提示注入。
可以将提示注入视为在AI而不是人类上完成的工具。
许多公司担心的一种情况是，他们让 AI 系统访问其内部数据库，
攻击者欺骗该系统泄露这些数据库中的私人信息。
如果系统对这些数据库具有写入权限，攻击者可以诱骗系统破坏数据。
任何想要利用 AI 的组织都需要认真对待安全和安保问题。
然而，这些风险并不意味着 AI 系统永远不应该被赋予在现实世界中行动的能力。
AI 系统可能会失败，但人类也可能失败。
如果我们能让人们信任一台机器将我们带到太空，
我希望有一天，安全足以让我们信任自主的人工智能系统。
AI 应用平台的可观察性
虽然我已将可观测性放在其自己的部分，但它应该从一开始就集成到平台中，而不是后来才添加。
可观测性对于各种规模的项目都至关重要，其重要性随着系统复杂性的增加而增加。
虽然我已将可观测性放在其自己的部分，但它应该从一开始就集成到平台中，而不是后来才添加。
可观测性对于各种规模的项目都至关重要，其重要性随着系统复杂性的增加而增加。
1. Metrics
在讨论监控时，大多数人会想到指标。
要跟踪的指标取决于要跟踪的系统内容，这是特定于应用程序的。
但是，一般来说，需要跟踪两种类型的指标：模型指标和系统指标。
系统指标告诉整个系统的状态。
常见指标包括吞吐量、内存使用情况、硬件利用率和服务可用性/正常运行时间。
系统指标对于所有软件工程应用程序都是通用的。在本文中，将重点介绍模型指标。
模型指标评估模型的性能，例如准确性、毒性和幻觉率。
应用程序管道中的不同步骤也有自己的指标。
例如，在 RAG 应用程序中，检索质量通常使用上下文相关性和上下文精度来评估。
可以通过索引数据所需的存储量以及查询数据所需的时间来评估矢量数据库。
模型的输出失败的方式多种多样,
识别这些问题并制定指标来监控它们至关重要。
例如，可能希望跟踪模型超时、返回空响应或生成格式错误的响应的频率。
如果担心模型会泄露敏感信息，也请找到一种方法来跟踪它。
与长度相关的指标 （如 query、context 和 response length） 有助于了解模型的行为。
一个模型是否比另一个模型更冗长？
某些类型的查询是否更有可能产生冗长的答案？
它们对于检测应用程序中的更改特别有用。
如果平均查询长度突然减少，则可能表示存在需要调查的潜在问题。
与长度相关的指标对于跟踪延迟和成本也很重要，
因为较长的上下文和响应通常会增加延迟并产生更高的成本。
跟踪延迟对于了解用户体验至关重要。常见的延迟指标包括:
- Time to First Token （TTFT）：生成第一个 Token 所需的时间
- 令牌间隔时间 （TBT）：每次令牌生成之间的间隔。
- 每秒令牌数 （TPS）：生成令牌的速率。
- 每个输出令牌的时间 （TPOT）：生成每个输出令牌所需的时间
- Total Latency （总延迟）：完成响应所需的总时间。
还需要跟踪成本。
与成本相关的指标是查询数量以及输入和输出令牌的数量。
如果使用具有速率限制的 API，则跟踪每秒请求数非常重要，
以确保保持在分配的限制范围内并避免潜在的服务中断。
在计算指标时，请确保它们可以按相关轴进行细分，
例如用户、发布、提示/链版本、提示/链类型和时间。
这种粒度有助于了解性能变化和识别具体问题。
2. Logs
日志记录的理念很简单：记录所有内容。
记录系统配置。记录查询、输出和中间输出。
记录组件何时启动、何时结束、何时崩溃等。
在记录一段日志时，请确保为其提供标签和 ID，以帮助了解此日志来自系统中的哪个位置。
记录所有内容意味着拥有的日志数量可能会非常迅速地增长。
许多用于自动日志分析和日志异常检测的工具都由 AI 提供支持。
3. Traces
Trance是指通过各种系统组件和服务详细记录请求的执行路径。
在 AI 应用程序中，跟踪揭示了从用户发送查询到返回最终响应的整个过程，
包括系统执行的操作、检索的文档以及发送到模型的最终提示。
它还应该显示每个步骤花费了多少时间及其相关成本（如果可衡量）。
例如，这是 Langsmith 跟踪的可视化效果:
理想情况下，应该能够通过系统逐步跟踪每个查询的转换。
如果查询失败，应该能够查明出错的确切步骤：
是处理不正确、检索到的上下文无关紧要，还是模型生成了错误的响应。
基于Pipeline构建AI应用
AI 应用程序可能会变得相当复杂，由多个模型组成，
从许多数据库中检索数据，并且可以访问各种工具。
Pipeline编排工具可帮助指定如何将这些不同的组件组合（链）在一起，以创建端到端应用程序流。
概括地说，业务流程协调程序分两个步骤工作：组件定义和链（也称为管道）：
-
组件定义
需要告诉Pipeline的系统使用哪些组件，
例如模型（包括用于生成、路由和评分的模型）、
系统可以从中检索数据的数据库以及系统可以执行的操作。
许多Pipeline工具还支持与工具集成，以便进行评估和监视。
-
Chaining
告诉Pipeline的系统从接收用户查询到完成任务所采取的步骤顺序。
下面是例子：
- 处理原始查询。
- 根据已处理的查询检索相关数据。
- 原始查询和检索到的数据将组合在一起，以模型所需的格式创建提示。
- 模型将根据提示生成响应
- 评估响应
- 如果响应被认为是好的，请将其返回给用户。如果没有，请将查询路由到人工操作员
Pipeline负责在步骤之间传递数据，并且可以提供工具，以帮助确保当前步骤的输出采用下一步所需的格式。
在为具有严格延迟要求(高性能要求)的应用程序设计管道时，可以尝试尽可能多地并行执行。
例如，如果有一个路由组件（决定将查询发送到何处）和一个 PII 删除组件，
则它们可以同时执行这两项操作。
AI编排工具有很多，
比如 LangChain、LlamaIndex、Flowise、Langflow 和 Haystack。
每个工具都有自己的 API。
虽然在启动项目时直接跳转到编排工具很诱人**，但无需先使用编排工具即可开始构建应用程序**。
任何外部工具都会增加复杂性。
编排器可以抽象出系统工作方式的关键细节，过度复杂后就会变的难以理解和调试系统。
进入应用程序开发过程的后期阶段时，可能会决定使用Pipeline工具可以使工作更轻松。
以下是评估使用Pipeline编排工具时要记住的三个方面：
-
集成和可扩展性
评估Pipeline工具是否支持当前使用或将来可能采用的组件。
例如，如果要使用 Llama 模型，请检查编排器是否支持该模型。
考虑到模型、数据库和框架的数量，编排器不可能支持所有内容。
因此，还需要考虑编排器的可扩展性。如果它不支持特定组件，那么改变它有多难？
-
支持复杂Pipeline
随着应用程序复杂性的增加，
可能需要管理涉及多个步骤和条件逻辑的复杂管道。
支持分支、并行处理和错误处理等
高级功能的Pipeline工具将帮助有效地管理这些复杂性。
- 易用性、性能和可扩展性
考虑Pipeline工具的用户友好性。
寻找直观的 API、全面的文档和强大的社区支持，
因为这些可以显著缩短您和您的团队的学习曲线。
避免使用启动隐藏 API 调用或给应用程序带来延迟的编排器。
此外，确保Pipeline工具可以随着应用程序、开发人员和流量数量的增长而有效扩展。
全文完。