本文概述了生成式 AI 平台的常见组件、它们的作用以及它们的实现方式。
本文重点介绍部署 AI 应用程序的整体架构。
它讨论了需要哪些组件以及构建这些组件时的注意事项。
它不是关于如何构建 AI 应用程序。
这就是整体架构的样子。
这是一个相当复杂的系统。
这篇文章将从最简单的架构开始，逐步添加更多组件。
在最简单的形式中，应用程序接收查询并将其发送到模型。模型生成响应，该响应将返回给用户。
模型 API 框是指第三方 API（例如 OpenAI、Google、Anthropic）和自托管 API。
- 通过为模型提供对外部数据源和信息收集工具的访问权限，增强模型的上下文输入
- 设置防护机制以保护系统和用户。
- 添加模型、路由器和网关以支持复杂的管道并增加更多安全性。
- 使用缓存优化延迟和成本。
- 添加复杂的逻辑和编写操作以最大限度地发挥系统的功能。
1.增强上下文
平台的初始扩展通常涉及添加机制，以允许系统使用必要的信息来扩充每个查询。收集相关信息称为上下文构建。
许多查询需要上下文来回答。上下文中的相关信息越多，模型对内部知识的依赖就越少，由于其训练数据和训练方法，这些知识可能不可靠。研究表明，在上下文中访问相关信息可以帮助模型生成更详细的反应，同时减少幻觉（Lewis 等人，2020 年）。
例如，给定查询“Acme 的 fancy-printer-A300 是否打印 100pps？”
如果给定 fancy-printer-A300 的规格，模型将能够更好地响应。
基础模型的上下文构建等同于经典 ML 模型的特征工程。
它们的作用相同：为模型提供处理输入所需的信息。
情境学习，即从情境中学习，是一种持续学习的形式。它使模型能够不断整合新信息以做出决策，防止其过时。例如，除非新信息包含在其上下文中，否则使用上周数据训练的模型将无法回答有关本周的问题。
通过使用最新信息（例如 fancy-printer-A300 的最新规格）更新模型的上下文，模型将保持最新状态，并可以响应超过其截止日期的查询。
RAGs
上下文构造最著名的模式是 RAG，即 Retrieval-Augmented Generation。
RAG 由两个组件组成：生成器（例如语言模型）和检索器，检索器从外部来源检索相关信息。
检索并非 RAG 所独有。它是搜索引擎、推荐系统、日志分析等的支柱。
为传统检索系统开发的许多检索算法可用于 RAG。
检索并非 RAG 所独有。它是搜索引擎、推荐系统、日志分析等的支柱。
为传统检索系统开发的许多检索算法可用于 RAG。
加载并 Chunk(分块)来自外部内存源的数据后，使用两种主要方法执行检索:
1 基于字词的检索
这可以像关键字搜索一样简单。
例如，给定查询 “transformer”，获取包含此关键字的所有文档。
更复杂的算法包括 BM25（利用 TF-IDF）和 Elasticsearch（利用倒排索引）。
基于术语的检索通常用于文本数据，但它也适用于具有文本元数据（如标题、标签、标题、注释等）的图像和视频。
2 基于嵌入的检索（也称为向量搜索）
可以使用嵌入模型（如 BERT、句子转换器）以及 OpenAI 或 Google 提供的专有嵌入模型，将数据块转换为嵌入向量。
给定一个查询，将检索其向量最接近查询嵌入的数据（由向量搜索算法确定）。
向量搜索通常被定义为最近邻搜索，使用近似最近邻 （ANN） 算法，
例如 FAISS（Facebook AI 相似性搜索）、Google 的 ScaNN、Spotify 的 ANNOY 和 hnswlib。
ANN-benchmarks 网站使用四个主要指标比较多个数据集上的不同 ANN 算法，同时考虑到索引和查询之间的权衡：
- Recall：算法找到的最近邻的分数。
- 每秒查询次数 （QPS）：算法每秒可以处理的查询次数。这对于高流量应用至关重要。
- Build time：构建索引所需的时间。此指标非常重要，尤其是在需要频繁更新索引时（例如，因为数据发生变化）。
- 索引大小：算法创建的索引的大小，这对于评估其可扩展性和存储要求至关重要。
这不仅适用于文本文档，还适用于图像、视频、音频和代码。
许多团队甚至尝试汇总 SQL 表和数据帧，然后使用这些摘要生成 embeddings 以进行检索。
基于字词的检索比基于 embeddings 的检索更快、更便宜。
它可以开箱即用，使其成为一个有吸引力的开始选择。
BM25 和 Elasticsearch 在行业中得到广泛应用，是更复杂的检索系统的强大基准。
基于 embeddings 的检索虽然计算成本高昂，但随着时间的推移可以得到显著改进，从而优于基于术语的检索。
生产级别的检索系统通常结合了多种方法。
将基于字词的检索和基于 embeddings 的检索相结合称为混合搜索。
一种常见的模式是 sequential。
- 首先，使用便宜、不太精确的检索器（例如基于术语的系统）来获取候选项。
- 然后，一种更精确但成本更高的机制（例如 k 最近邻）会找到这些候选者中的最佳值。这一步也称为重新排名(reranking)。
例如，
给定术语 “transformer”，可以提取包含单词 transformer 的所有文档，
无论它们是关于电子设备、神经体系结构还是电影。然后，使用向量搜索在这些文档中查找实际 transformer 查询相关的文档。
上下文 reranking 与传统搜索 reranking 的不同之处在于，参与 reranking 元素的确切位置不太重要。
在搜索中，元素的排名（例如，第一或第五）至关重要。
在上下文 reranking 排序中，文档的顺序仍然很重要，因为它会影响模型处理文档的程度。
正如论文 Lost in the middle （Liu et al.， 2023） 所建议的那样，
模型可以更好地理解上下文开头和结尾的文档。
但是，只要包含文档，与搜索排名相比，其顺序的影响就不那么显著。
另一种模式是 ensemble。
请记住，这种模式的检索器的工作原理是按文档与查询的相关性分数对文档进行排名。
使用多个检索器同时获取候选内容，然后将这些不同的排名组合在一起以生成最终排名。
包含表格数据的 RAG
外部数据源也可以是结构化的，例如 DataFrame 或 SQL 表。
从 SQL 表中检索数据与从非结构化文档中检索数据有很大不同。
给定一个查询，系统的工作方式如下：
- Text-to-SQL：根据用户查询和表架构，确定需要的 SQL 查询。
- SQL 执行：执行 SQL 查询。
- 生成：根据 SQL 结果和原始用户查询生成响应。
对于 Text 到 SQL 步骤，如果有许多可用表的架构无法全部适应模型上下文，
则可能需要一个中间步骤来预测每个查询要使用哪些表。
Text 到 SQL 可以由用于生成最终响应的相同模型或许多专门的文本到 SQL 模型之一来完成。
Agentic RAGs
一个重要的数据来源是 Internet。
Google 或 Bing API 等 Web 搜索工具可以让模型访问丰富的最新资源，以收集每个查询的相关信息。例如，给定查询“Who won Oscar this year？”，
系统会搜索有关最新 Oscar 的信息，并使用此信息生成对用户的最终响应。
基于字词的检索、基于嵌入的检索、SQL 执行和 Web 搜索是模型可以采取的用于增强其上下文的操作。
可以将每个操作视为模型可以调用的函数。
可以合并外部操作的工作流程也称为 agentic。
基本的架构图如下所示：
» Action 和 tool «
工具允许执行一个或多个操作。
例如，人员搜索工具可能允许两个操作：按姓名搜索和按电子邮件搜索。
但是，差异很小，因此许多人可以互换使用 action 和 tool。
» 只读操作与写入操作 «
从外部源检索信息但不更改其状态的操作是只读操作。
给模型写操作，例如更新表中的值，使模型能够执行更多任务，但也带来了更多风险，这将在后面讨论。
Query rewriting
通常，需要重写用户查询，以增加获取正确信息的可能性。请考虑以下对话。
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 怎么样？”，是模棱两可的。
如果逐字使用此查询来检索文档，则可能会得到不相关的结果。
需要 Query rewriting 重写这个查询以反映用户实际询问的内容。
新查询本身应该有意义。
最后一个问题应该改写为“Emily Doe 上一次从我们这里买东西是什么时候？
查询重写通常使用其他 AI 模型完成，
使用类似于“给定以下对话，重写最后一个用户输入以反映用户实际询问的内容”的提示。
Query rewriting 可能会变得复杂，尤其是在需要进行身份解析或整合其他知识时。
如果用户问 “How how how his wife？”，
首先需要查询数据库以找出他的妻子是谁。
如果没有此信息，重写模型应承认此查询无法解决，
而不是产生名称幻觉，从而导致错误的答案。
后续的内容咱们会讲一下：
- 为大模型应用构建安全防护
- 添加模型路由器和网关
- 使用缓存减少延迟
- 添加复杂逻辑和写入操作
- AI 应用平台的可观察性
- AI 应用 Pipeline 构建
原文链接：https://huyenchip.com/2024/07/25/genai-platform.html
