本章介绍了围绕大型语言模型（LLMs）设计系统的两种主要模式——批处理和实时模式。决定架构批处理或实时应用程序将取决于你正在处理的用例。一般来说，批处理用例是围绕生成数据并在稍后使用的场景进行构建的。例如，你将利用LLMs从大量数据中提取数据点，然后生成摘要供业务分析师每天使用。而在实时用例中，数据会在可用时立即使用。例如，你将利用LLMs作为在线代理，通过聊天或语音界面回答客户或员工的问题。
深入探讨批处理模式，它涉及批量发送查询以提高吞吐量，但以增加延迟为代价。这更适用于长时间、耗时的生产工作负载和大规模数据消费。此外，批量生成的结果不会立即展示给终端用户，这样可以选择通过额外的管道审查内容。这些管道可以在提示发送给LLM之前集成，其中可以进行数据清洗和提示工程，或者在收到LLM响应后集成，你可以增强回复以匹配特定格式或添加来自其他数据源的附加数据。
实时设计模式提供了更快的双向查询体验。尽管吞吐量较低，实时设计模式提供了更快的反馈，并可以通过多轮记忆机制增强，增加对之前请求的意识。实时推理受制于延迟要求，用户体验可能会受到影响，因此审查结果的机会减少。
在这种情况下，你可以在推理时应用一些过滤，并应用检索增强生成（RAG）管道，在查询发送到LLM之前增强用户查询。此外，在入口点和出口点保持一层过滤，可以帮助确保应用程序的安全性。
我们将提供批处理和实时查询的示例用例，以突出它们的权衡。读者将学习根据规模、成本和延迟要求等因素，何时使用每种方法。
我们将在本章中涵盖以下主要主题：
-
批处理和实时集成模式：
- 批处理模式涉及批量发送查询以提高吞吐量，但延迟较高。它更适用于长时间运行的工作负载和大规模数据消费。
- 实时模式提供更快的双向查询，提供更快的反馈，但吞吐量较低。它更适用于低延迟要求。
-
不同的管道架构：
批处理与实时对不同集成管道组件（如入口点、预处理、推理、后处理和结果呈现）的影响。 -
集成框架中的应用集成模式：
批处理和实时模式的细微差别如何映射到集成框架的不同阶段，包括入口点、提示预处理、推理、结果后处理和结果呈现。 -
用例示例——通过生成式AI（GenAI）增强搜索：
使用GenAI增强网站搜索的示例用例，其中文档摄取在批处理模式下进行，而搜索/响应生成在实时模式下进行。
批处理和实时集成模式
评估批处理与实时集成方法时，第一个关键决策是关于数据的即时性——你到底什么时候需要GenAI输出？这归结为你是否需要响应及时的结果，如满足按需用户查询，还是使用场景中，模型输出的洞察可以在一段时间内积累，再被消费。
让我们用RAG（检索增强生成）示例来说明这一点，在RAG中，LLM评估搜索结果，以形成易于理解的查询响应。这是一个实时用例；你需要AI生成的答案，要求最小延迟，以提供像对话助手或搜索引擎等应用程序中的优质用户体验。数据必须在产生时立即投入使用。
与此对比的是自动化内容生成工作流，例如从产品目录中提取元数据。尽管你仍然希望快速获得内容，但在模型输出下游被消费的时间上有更多的灵活性。你可以在批处理模式下运行生成模型，排队处理提示，并根据可用的容量异步处理它们。生成的文本随后按照其自己的计划流入你的电子商务数据库。
实时交互式集成模式优先考虑低延迟和响应式体验。用户几乎可以通过请求/响应的应用接口即时接收到AI结果。批处理模式则解耦了这一点，牺牲了即时交互性，以换取更高的整体吞吐量和大规模的成本效率。长时间运行的工作优化了池化模型的利用率。
因此，批处理与实时决策依赖于分析数据的新鲜度需求。对于需要即时满足的体验，如查询信息或进行创意构思迭代，你将需要一个基于请求的交互架构。而当目标更多是最大化生成模型的输出量，并且对延迟容忍度更为灵活时，批处理提示能够带来更好的经济效益。准确把握集成模式是充分利用GenAI价值的关键。
不同的管道架构
除了集成模式本身，实时处理与批处理决策对周围的数据管道和基础设施架构有重大影响。预处理和后处理工作流根据其各自的模式，具有非常不同的特性和优化。
对于实时、低延迟的用例，如查询回答或对话式AI，轻量级的即时预处理管道是理想选择。这些管道在向生成模型发出单一推理请求之前，处理提示清理、上下文增强和其他步骤，且开销最小。输出随后通过后处理阶段，重点进行安全过滤、响应排名和结果格式化。这些过程需要优化，因为端到端的延迟至关重要。
实时管道通常托管在动态可扩展的容器化基础设施或无服务器云环境中。积极的缓存层和负载均衡将请求量分配到可用的推理资源上。整个实时架构优化了即时响应性，优先考虑这一点。
与此相对，批处理管道在操作更大数据量时进行更重的预处理工作。这可能包括主题聚类、语义搜索、翻译等任务——这些都在向生成模型发送提示之前进行。然后，这些提示进入异步队列系统，将请求累积成批次，以提高模型执行的吞吐量。
在输出方面，重型后处理管道应用内容结构化、总结、质量过滤、法律合规扫描以及其他各种增强任务。像云存储和数据仓库这样的暂存区域临时存储输出，供分析使用，然后再异步集成到下游系统中。
由工作流引擎或托管批处理服务进行编排，这些管道旨在最大化在成本限制下的总体数据吞吐量，并在较长时间跨度内进行处理。与实时系统不同，延迟是一个可接受的权衡，以换取更高的整体可扩展性和较低单位成本下的并行处理。
解耦的缓冲区将上游和下游系统与生成式AI模型的直接依赖关系隔离开。这使得在云端或本地环境中，分布式工作池可以线性扩展。自动扩展策略将配置资源与需求不断匹配。
虽然架构上更复杂，但批处理管道能够高效地在结构化的时间表上生成大量的AI数据。成本计算对比了扩展基础设施费用与固定基础设施成本。对于许多大规模的用例，尽管管道的开销较重，但批处理能迅速分摊成本。
在评估这些权衡时，实时交互与离线批处理之间的决策涵盖了许多架构要求。实时系统优化低延迟，而批处理系统则在更灵活的时间窗口内提供更高的整体吞吐量。精心设计的管道，能够与数据需求和生成用例对齐，对于系统整体性能和成本效率至关重要。
集成框架中的应用集成模式
之前，我们探讨了生成式AI模型的实时集成和批处理集成方法之间的高层架构权衡。那么，这些模式的细微差别如何映射到我们集成框架各个阶段的不同组件呢？以下图表展示了这些步骤：
让我们在接下来的章节中逐步解析每个步骤。
入口点
在入口点阶段，实时系统与批处理系统的优先级在最终用户体验上有显著的不同。对于实时交互式应用程序，提示源头的入口点需要高度简化，以简便和易用为核心。毕竟，这些输入将直接暴露给人类用户，并驱动他们接收到的即时AI响应。
因此，实时提示界面应该优化为简洁、用户友好的设计，包含搜索栏、专注的聊天窗口、简洁的语音接口和直观的上传小工具。整个体验应提炼为核心信号，去除任何可能影响响应性的复杂性。
这些提示往往也来源于不可预测的上下文，因此界面必须能够在不同设备类型和使用场景中保持自然流畅。
相比之下，批处理的入口点发生在幕后，用户看不见。这些提示通常来源于数据管道——无论是来自API的JSON负载、数据库导出文件、存储在云中的文档，还是其他结构化/非结构化数据源。界面优化的重点是稳定的高吞吐量数据摄取，而不是实时的人机交互。
适合批处理的常见输入格式包括JSON/JSONL流、CSV上传、Parquet文件等。经过预解析的可消费格式，这些提示可以由另一个模型或其他机制解析和评估，然后发送到下游队列系统，进行大规模的模型执行。以下是一个JSONL文档的示例：
{"name": "Paula", "music_genres": [["blues", "8"], ["rock", "5"]]}
{"name": "John", "music_genres": [["pop", "15"], ["country", "2"]]}
{"name": "Mary", "music_genres": []}
{"name": "Adam", "music_genres": [["pop", "5"]]}
提示预处理
提示预处理步骤涉及在将输入提示送入语言模型进行生成之前，准备和转换这些提示。
提示预处理的需求和限制可以根据系统是设计用于实时处理还是批处理而有很大不同。在实时应用程序中，如对话助手或搜索引擎，预处理工作流中的每一步都会增加宝贵的响应时间。如果延迟过高，可能会对用户体验产生不利影响，特别是在即刻性和响应性至关重要的场景中。
例如，在使用RAG管道的实时系统中，提示必须经过几个耗时的步骤，才能让语言模型生成响应。这些步骤可能包括：评估提示是否符合安全AI标准、生成提示的嵌入（向量表示）、查询向量存储以检索相关信息，可能还需要对检索到的数据进行额外处理。每一步都会增加整体延迟，进一步加剧用户体验中的延迟。
相比之下，批处理提示预处理工作流则具有更大的灵活性，能够容纳更多计算密集型操作，而不会显著影响用户体验。由于处理不是实时发生的，因此可以有更多的余地应用更深入的增强技术，比如通过提取元数据来增强提示、执行查询重写以提高检索信息的质量，或应用先进的自然语言处理技术来更好地理解提示背后的意图。
批处理中的这种灵活性可以导致语言模型提供更全面、更准确的响应，因为预处理后的提示可以通过相关的上下文信息进行增强，并且更好地与模型的优势对接。然而，重要的是在预处理的深度和所需的计算资源之间找到平衡，因为过度的预处理可能会带来更高的成本，从而影响解决方案的整体投资回报率。
推理
虽然实时和批处理提示预处理工作流在方法和优先级上有所不同，但核心的推理阶段是这两种模式汇聚的地方，因为它们最终都利用相同的基础生成模型能力。然而，在这一阶段采用的优化策略在这两种集成模式之间可能有显著差异。
在实时生成式AI系统中，主要关注点是最小化延迟并最大化个别请求的响应速度。这些系统通常一次处理一个推理请求，而不是将多个请求批量处理。当使用开箱即用的模型，如Google的Gemini、OpenAI的ChatGPT或Anthropic的Claude时，底层的基础设施和资源分配对用户是抽象的。在这种情况下，服务提供商负责处理推理所需资源的正确配置，确保每个请求都能高效处理，同时遵循服务的性能和成本目标。
然而，在组织选择自行托管和部署生成模型的场景中，例如使用Google的Gemini、Meta的LLaMA或其他开源或专有模型时，正确配置基础设施的责任则落在组织本身。这一过程被称为“正确配置（right-sizing）”，涉及在潜在延迟和成本之间仔细平衡。
正确配置的目标是确定计算资源的最佳配置，例如GPU的数量和类型、CPU核心数和内存，这些配置能够有效地处理预期负载，同时最小化延迟和控制成本。这个过程通常涉及负载测试和在不同资源配置和模拟流量模式下对模型性能的基准测试。
模型的大小、复杂性以及推理任务的性质（例如文本生成、问答、摘要）在确定资源需求方面起着至关重要的作用。较大且更复杂的模型通常需要更多的计算能力来实现可接受的推理延迟，这可能会增加整体的部署和运营成本。
组织必须仔细评估在实现低延迟（可能需要过度配置资源）和控制成本（可能接受略高的延迟）之间的权衡。找到合适的平衡至关重要，因为过高的延迟会降低用户体验，而过度配置资源则会导致不必要的开支。
另一方面，批处理集成模式优先考虑成本优化和批量处理提示的吞吐量。这些系统不是单独处理请求，而是将多个提示聚合成批次，然后将其发送到生成模型进行推理。通过批量处理提示，计算资源可以更高效地利用，因为初始化模型和设置推理管道的开销可以在多个提示之间进行摊销。
这种方法可以带来显著的成本节约，尤其是在处理大量提示时，因为计算资源得到更有效的利用，总体吞吐量得到提高。
然而，重要的是要注意，批处理方法引入了吞吐量和延迟之间的权衡。虽然它优化了成本和整体吞吐量，但单个请求可能会经历更高的延迟，因为它们需要等待足够数量的提示积累，才能在批处理中进行处理。正如前面所提到的，批处理集成模式更适合实时响应性不那么关键的场景，例如批量文本生成、文档摘要或其他离线处理任务。
结果后处理
在实时应用中，后处理阶段在确保顺畅且吸引人的用户体验方面起着至关重要的作用。由于生成的响应旨在立即交付，后处理工作流优先使用能够快速进行响应过滤、排序和渲染的技术。一个常见的做法，特别是在对话式AI应用（如聊天机器人）中，是使用标记语言（如Markdown）格式化生成的输出。通过这种方法，可以无缝地集成丰富的文本格式，包括标题、列表、代码块和其他结构元素，增强响应的可读性和视觉吸引力。
实时后处理可能会结合针对特定用例的技术，例如通过根据情感应用颜色模式进行情感分析。例如，在客户服务聊天机器人中，可以根据响应与客户查询的相关性对其进行过滤和排序，确保优先展示最合适和最有帮助的响应。
与实时系统不同，生成式AI系统中的批处理工作流为后处理提供了更多的灵活性和计算资源。由于生成的输出不打算立即交付，批处理后处理可以在将数据持久化到数据存储或下游系统之前，对聚合输出应用更全面且计算密集型的增强。
一个常见的批处理后处理技术是摘要生成，其中将生成的输出压缩为简洁且连贯的摘要，便于后续的消费和分析。结构提取是另一个有价值的后处理步骤，系统从生成的文本中识别并提取相关信息，如关键实体、关系或事件描述。这些结构化数据可以存储在数据库中，或用于填充知识图谱，从而提高查询和分析的效率。
批处理后处理还可以结合更深入的质量过滤机制，利用针对质量评估的语言模型微调、自然语言推理或事实核查等技术。这些高级过滤方法可以帮助识别并标记低质量或事实错误的输出，确保只有高质量和可靠的信息会被保留并供下游使用。
批处理后处理工作流可以涉及更复杂的转换和增强，如文本风格化、情感迁移或特定领域或格式的内容生成（例如，生成营销文案、产品描述或技术文档）。
结果呈现
结果呈现无疑是这两种模式之间最显著的差异。实时UI/API集成要求即时更新——通常通过服务器渲染或数据绑定框架实现。而在批处理模式下，结果更可能通过管道批量导出到数据仓库或操作数据存储中，以供报告、分析、文档系统等的异步消费。
自然，日志记录和监控需求与每种模式的系统特征密切相关。实时模式需要围绕每个请求的指标（如延迟、错误和资源使用情况）进行严格的仪表化。批处理则强调吞吐量、管道性能和数据血统的可观察性。
从数据工程的角度来看，实时模式更倾向于采用优化速度和路径的Lambda架构。批处理则更倾向于利用云存储、Spark集群、托管工作流编排器和MPP数据仓库目标的传统现代数据管道。
实时集成与有状态应用无缝融合，并提供非常响应的用户界面。批处理则为大型异步AI驱动的操作解锁了更高的可扩展性，例如文档生成、报告自动化和大规模的对话数据标注。
这两种模式也带来了各自独特的可支持性考虑。实时模式依赖于高度冗余、自愈的服务网格。批处理则更多依赖于强大的恢复编排、幂等重启和自动重试。
正如你所看到的，尽管利用了相同的核心生成式AI能力，但这两种模式在上游/下游架构优先级和交付特征上存在显著差异。正确的选择取决于评估延迟敏感度、规模目标、成本参数和用例的契合度。许多企业可能会采用一种混合网格，结合这两种模式的特点。
用例示例——通过GenAI增强搜索
为了说明实时和批处理用例，我们将以一个公司使用GenAI技术来增强其网站搜索体验的例子为基础。在这个例子中，文档摄取将是一个批处理过程，而搜索本身将是实时的。
想象一个公司，它旨在通过利用GenAI技术来提升其网站的搜索体验。在这个场景中，公司的目标是为用户提供更全面和相关的搜索结果，超越简单的关键词匹配，提供具有上下文相关性且自然语言的响应。
文档摄取过程，涉及索引和处理公司内容库（例如，产品描述、知识库文章、产品手册），将是一个批处理操作。这个步骤将包括文本提取、实体识别、主题建模和整个文档库的语义嵌入生成等技术。这些嵌入捕捉了文档的语义意义和上下文，然后存储在向量数据库或其他适当的数据存储中。
在实时搜索体验中，当用户在公司网站上提交查询时，查询将经过提示预处理，这可能包括查询重写、意图检测和嵌入生成。生成的查询嵌入将用于根据语义相似性从向量数据库中检索最相关的文档。这些检索到的文档将作为GenAI模型的知识源。
然后，GenAI模型将根据检索到的文档和用户的查询生成自然语言响应。这个响应可以是简明的摘要、详细的答案，甚至是对话式的对话，具体取决于要求和公司决定设置的语气。
实时后处理阶段将开始，格式化生成的响应，以便在网站上进行最佳展示。这可能包括响应排序、结果结构化（例如，将响应拆分成部分或项目符号点）以及使用适当的标记或视觉元素进行渲染。
通过将文档摄取的批处理与实时查询处理和生成相结合，公司可以为用户提供无缝且丰富的搜索体验。批处理确保公司内容库被彻底索引并语义理解，而实时组件则利用这些知识提供相关且符合自然语言的响应，针对每个用户的查询量身定制。
批处理集成——文档摄取
文档摄取管道中的批处理部分在为公司内容库有效搜索和检索做准备方面起着至关重要的作用。此阶段涉及多个步骤，旨在提取有意义的信息，并将其转换为适合高效查询和生成的格式：
- 数据提取和预处理：第一步是从各种来源（如数据库、内容管理系统或文件库）提取文本数据。这些数据可能有不同的格式（例如HTML、PDF、Word文档），需要采用预处理技术，如文本提取、去重和标准化，以清理和标准化输入数据。
- 元数据提取：文本数据预处理后，可以应用高级自然语言处理技术，如命名实体识别（NER）和实体链接。这些任务可以通过预测AI模型或生成式AI模型来执行。此步骤识别并提取文本中相关的实体（例如人物、组织、产品、地点），并通过将它们与外部知识库或本体进行链接，进一步丰富数据，提供额外的上下文信息。
- 嵌入生成：批处理阶段的核心是为每个文档生成语义嵌入。这些嵌入是密集的向量表示，捕捉文本中的上下文含义和关系。常用的技术包括Transformer语言模型（例如BERT和RoBERTa）或专门的嵌入模型（例如Google Vertex AI文本嵌入模型和OpenAI文本嵌入）来生成这些嵌入。
- 向量数据库索引：生成的嵌入、提取的实体、主题和元数据被存储在专门的向量数据库或其他适合相似性搜索和检索的数据存储中。这个索引过的内容库将作为实时搜索和生成过程的知识库。
通过执行这些批处理步骤，公司内容库被转化为高度结构化且语义丰富的表示形式，从而实现高效的检索，并为生成式AI模型在实时搜索体验中生成相关和准确的响应提供必要的上下文。
实时集成——搜索
该过程的实时部分处理用户的搜索查询，并利用在批处理阶段创建的知识库生成具有上下文相关性的响应。
从高层次来看，图4.4展示了体验的组成部分：
- 查询处理：如图4.4的第1步所示。当用户在公司网站上提交搜索查询时，该查询会经历类似于批处理阶段的预处理步骤。这可能包括文本标准化、实体识别和嵌入生成，使用与文档内容库相同的模型。在这一步骤中，你还可以对查询进行安全评估。
- 语义检索：如图4.4的第2步和第3步所示，生成的查询嵌入用于对包含已索引文档嵌入的向量数据库进行相似性搜索。这一步从内容库中检索最相关的文档，基于它们与用户查询的语义相似性，确保检索到的信息在上下文上是适当的。在此步骤中，你还可以根据用例和可用的元数据对结果进行重新排序。
- 提示增强与生成：在第4步中，检索到的文档、原始查询和任何附加上下文（例如用户资料或浏览历史）被用来构建一个丰富的提示供生成式AI模型使用。可以采用提示工程、上下文增强和RAG等技术，创建一个信息丰富且简洁的提示，准确捕捉用户的信息需求。
- 响应生成：在第5步和第6步中，生成式AI模型将增强后的提示作为输入，生成自然语言响应。这个响应可以是简洁的摘要、详细的答案，甚至是对话式的对话，具体取决于需求和模型的能力。
- 后处理和渲染：在第6步中，生成的响应会经过一个后处理阶段，这可能包括格式化、结构提取、结果排序和渲染，以便在网站上进行最佳展示。这可以包括提取关键点或摘要、突出相关实体，并整合多媒体内容的视觉元素，以增强用户体验。
总结
本章介绍了围绕大型语言模型（LLMs）设计系统的两种主要模式——批处理和实时模式。选择哪种模式取决于组织的用例需求。我们了解到，批处理模式涉及批量发送查询，以提高吞吐量，但以较高的延迟为代价。它更适用于长时间运行的工作负载和大量数据的消费。结果不会立即暴露给用户，因此可以在模型推理之前或之后进行额外的审查管道。
我们还了解到，实时模式提供更快速的双向查询，为最终用户提供更快的反馈。它的吞吐量较低，但更适用于低延迟要求，但减少了审查结果的机会，以防延迟增加。
本章中，我们讨论了批处理与实时处理对集成管道中不同组件的影响。在入口点，实时模式优化了简化的用户提示，而批处理则处理数据管道输入。在预处理阶段，实时模式采用较轻的技术来最小化延迟，而批处理则允许进行更重的增强。在推理阶段，实时模式专注于每个请求的低延迟，而批处理则将请求分批处理，以提高吞吐量。
实时后处理涉及更快的格式化和过滤，但批处理允许进行更复杂的转换。在展示方面，实时模式提供即时的UI更新，而批处理则异步导出结果。
此外，本章还提供了一个使用GenAI增强网站搜索的示例用例，其中文档摄取是批处理模式，搜索和响应生成是实时模式，转变了最终用户体验，获得了更相关和个性化的答案。
在下一章中，我们将深入探讨一个利用GenAI从10-K文档中提取数据的用例。
