AI产品开发的艺术——搜索与检索增强生成

本章内容涵盖

语义嵌入语义搜索语言模型与定制知识的整合检索增强生成（RAG）高级检索增强生成优化

在大多数公司里，多年来积累的专业知识——战略洞察、协作学习和行业经验——散落在Wiki、知识库和内部文档中。当关键需求出现时，员工常常难以快速找到相关信息。通过检索增强生成（RAG），你可以将这丰富的知识动态地整合进语言模型（LM）应用中。RAG使你能够动态检索相关知识，并将其融入LM生成的回答中，从而让交互更具相关性和上下文感知。

Alex 亲身感受到定制数据整合的需求。他花了大量时间调整应用中的提示，但用户依然感到内容与其领域知识脱节。LM输出往往泛泛、过时且缺乏特色。RAG使他能够将LM能力与客户所需的具体、最新信息结合起来，使AI生成的内容更相关、更可靠。

常见陷阱：根据我的经验，最容易失去用户信任的方式之一，就是交付一个“不了解”他们领域、听起来像业余水平的AI应用。如果用户不得不频繁后期修改模型输出，他们最终会放弃你的产品。像RAG和微调（见第8章）等技术能帮助你规避这一风险。

本章将帮助你扎实理解RAG架构，并学会就数据、模型和提示作出明智决策。我们先从语义搜索入手——这是知识管理中的基础能力，能通过上下文理解提升搜索准确性。语义搜索功能强大，同时也是RAG架构的核心组成部分。在7.3节，我们将结合语义搜索与语言模型，构建完整的RAG系统。图7.1展示了这两种架构的示意。

图7.1 从语义搜索到完整的检索增强生成（RAG）系统

我们将完整地介绍语义搜索和完整RAG这两项功能的发展周期。首先，我们将看到Alex搭建初始系统的过程，就像画家用宽大自信的笔触勾勒画作的粗略轮廓。随后，他会不断细化和完善，加入更多细节和微妙之处。整个过程由持续的评估和迭代引导。图7.2总结了各阶段相关的关键组件和技术。

图7.2 RAG系统的生命周期

本章假设你已经熟悉第5章中介绍的语言模型（LM）相关概念。我们还会参考第6章中的提示工程技术和最佳实践。提示在RAG中起着关键作用——它允许你向大型语言模型（LLM）提供相关上下文，并构建问题框架，以提取最准确、有用的信息。读完本章，你将了解如何搭建RAG系统，并具备持续挖掘其潜力的能力，将用户数据转化为强大的资产。

7.1 利用定制数据专属化语言模型

在向精选设计合作伙伴发布了应用的Alpha版本后，Alex需要快速收集反馈并规划后续改进。因此，他对设计合作伙伴进行了密集访谈。

7.1.1 提示工程随着时间推移的不足

他的第一位设计合作伙伴是Tom，一家中型B2B软件即服务（SaaS）公司营销主管，该公司提供流程自动化平台。访谈内容如下：

Alex：感谢抽时间，Tom。能介绍一下你们公司以及目前如何使用我们的内容生成应用吗？
Tom：我们是一家专注于流程自动化的B2B SaaS公司，我负责营销团队。我们产出大量内容——博客文章、白皮书、案例研究。已经用这款应用几个月了，帮助我们生成草稿和简化制作流程。
Alex：很高兴听到这些。应用目前表现如何？
Tom：还算有帮助，但也遇到了一些瓶颈。刚开始确实提速了，但用久了感觉内容过于泛泛。我们的受众主要是运营经理和IT专业人士，他们需要深度、行业特定的洞察，而AI生成的内容缺乏这种深度，内容主要基于通用知识，跟我们内部的具体见解脱节，总是落后于用户的知识水平。
Alex：所以内容对于你们来说太宽泛了？
Tom：没错。应用生成的草稿能用，但需要大量编辑才能符合我们的品牌声音和受众需求。普通话题还行，遇到技术细节或客户痛点时内容就显得不足了。
Alex：能具体说说你们的编辑流程吗？
Tom：比如写一篇制造业流程优化的博客，应用可能给个不错的开头，但一般非常泛泛，比如“流程自动化提高效率”，我们的读者早已知道。我们希望提供内部数据支持的具体且有趣的案例，比如平台如何帮助客户降低成本或缩短生产时间。我们得手动从Confluence、Salesforce和Google Drive搜集这些数据，过程很慢。其他团队也面临类似问题——我们积累了大量知识，却难以有效利用。
Alex：明白了。能自动访问你们的内部数据，生成更符合受众需求的内容，会有帮助吗？
Tom：绝对有用。如果应用能访问我们的内部案例和具体数据，比如客户的成本降低数据，会节省很多时间，内容也更有价值。这样感觉AI“理解”了我们的业务和受众。
Alex：明白了。还有什么关于内容生成的挑战吗？
Tom：有时应用用的是过时信息，尤其是外部引用方面。AI领域变化快，我们需要反映最新趋势和发展，往往得花额外时间更新内容。
Alex：感谢提醒，Tom。我知道最新信息对你们很重要。如果应用能结合你们的专有数据和最新行业洞察，能减少你们手动核查和更新的工作。我会探索集成实时外部数据和内部知识库的方案，让应用生成准确、相关且符合品牌声音的内容。
Tom：太好了，谢谢你考虑这些改进。期待你们的进展！

7.1.2 访谈总结

访谈后，Alex整理笔记成以下备忘录：

职位：中型B2B SaaS公司营销主管

公司聚焦：流程自动化平台

痛点：

语言模型生成内容缺乏针对小众受众的深度和专业性内部数据分散在多个平台（Confluence、Salesforce、Google Drive），拖慢内容生成需人工整合专有洞察进AI生成内容过时或泛泛信息未反映快速变化的行业趋势

需求：

无缝整合内部数据进LM生成内容获取最新的外部市场洞察内容需贴合公司产品、受众和专业知识，具备个性化特征

Alex 回想起RAG架构——他在研究不同语言模型方法时接触过的方案。RAG让语言模型能动态检索相关内部信息，无需昂贵的微调或再训练。它似乎是集成定制数据、保持内容实时更新的理想方案。深受启发后，他决定继续推进，为应用原型设计一个初步的检索组件。

7.2 通过语义搜索检索相关文档

本节将介绍语义嵌入如何显著提升你产品中的信息检索能力。与仅匹配精确关键词、只能浅层挖掘知识的基础搜索不同，语义搜索能够捕捉上下文和含义，通常能提供更准确、更相关的结果。

7.2.1 搜索在B2B场景中的作用

企业可以将搜索作为独立功能，支持探索性、创造性和需要用户整合不同来源信息的认知任务。它也可以作为更专门搜索应用的基础。

独立功能

当Alex将Tom公司的数据整合进应用时，他意识到高效的信息检索不仅仅是内容生成的辅助工具。对于像Tom这样的用户来说，面对分散孤立的数据，检索本身就是一项重要价值。举例来说，Tom在准备新产品功能的演示时，需要翻查各种工具——Confluence、Google Drive、内部邮件、公司Wiki——希望迅速定位最新的产品文档。这一过程枯燥且效率低下，尤其当他不确定信息最新版本存放在哪时。

借助Alex的应用，Tom能够“一站式”搜索公司所有数据仓库。不必打开多个标签页，在每个平台里手动搜索，他只需直接在应用中输入功能名称。应用凭借先进的搜索算法，理解语义、关键词和元数据，在几秒内返回最相关的文档和细节。这不仅仅是更快的搜索，更是更智能的搜索，能过滤掉无关结果，精准呈现Tom所需内容。除了临时的信息请求，这项功能还能用于创新规划等创造性任务，帮助用户保持专注状态，而不必分散注意力于多个信息源。

基于搜索的应用

除了作为独立工具，搜索引擎还可以作为其他应用和客户端系统的基础。在Alex的应用中，搜索支持定制化内容生成。以下是其他一些基于搜索的应用示例：

人力资源：搜索合适候选人是增强筛选和招聘流程的第一步。销售：从不同触点获取客户相关信息，是设计追加销售话术的起点。产品管理：聚合所有关于特定产品功能的信息和反馈，是决定该功能是否保留、修改或弃用的基础。可持续发展：运行搜索，汇总相关信息以生成公司可持续发展报告草案。

这些应用将搜索无缝集成到更大的工作流程中，提高用户效率。接下来我们将深入实现细节，了解如何构建和准备文本数据以支持语义搜索。

7.2.2 使用语义嵌入进行搜索

为了实现语义搜索，文档会被转换成嵌入向量（也称为向量表示），并保存到数据库中。本节首先介绍嵌入的工作原理，随后讲解如何在嵌入数据库中高效存储、管理和检索。正确使用时，嵌入是AI工具箱中的强大武器，值得仔细学习。

利用嵌入捕捉语义相似性

嵌入基于分布式相似性原则，这是一条普适的语义学规律。1959年，语言学家J. R. Firth提出：“你可以通过一个词的上下文环境来了解该词的含义。”大多数情况下，只要我们知道某个词的上下文，就能轻松推断出词义。例如，看下面这句话：

The customer finally signed the cotnratc.

虽然最后一个单词明显拼写错误，但我们可以立即判断它是“contract”，因为其上下文词汇如customer（客户）和signed（签署）都指向这一含义。其它可能的词还有agreement（协议）、deal（交易）、arrangement（安排）等，它们之间也具有一定的语义相似度。

因此，一个词的上下文信息透露了大量语义信息。深度学习利用这一洞见构建了嵌入，即词的代数向量表示[1]。具体工作原理如下：

嵌入是词的代数表示（向量），能够捕捉词出现的上下文。例如，单词“apple”的嵌入会由它经常出现的上下文词汇特征构成，如eat（吃）、juice（果汁）、sweet（甜的）、fruit（水果）、healthy（健康的）等。出现在相似上下文中的词，其语义相近，嵌入也相似。例如，“banana”和“apple”常见相同上下文，因此它们的嵌入相近。相比之下，“car”（汽车）出现的上下文截然不同，其嵌入向量与“apple”较远。嵌入之间的相似度反映了词语之间的语义相似性（见图7.3）。例如，“apple”与“banana”比与“car”更为相似。

图7.3 语义相近的词在嵌入空间中距离更近。

分布式相似性对搜索非常有用，因为它能捕捉词的语义，而传统的关键词搜索只依赖精确匹配。因此，如果你搜索“cars”，但文档集中只有“vehicle”一词，关键词搜索不会返回任何结果，而语义搜索——即寻找相似的嵌入向量——则会显示包含“vehicle”的文档。

同样的原理也适用于更大的语言单元，如句子、文本或带有相关元数据的整篇文档。我们总结一下良好嵌入的属性：

语义相似的实体在嵌入空间中对应的点应该彼此靠近。语义不同的实体在嵌入空间中对应的点应该距离较远。

图7.4 展示了多个句子在嵌入空间中的表示。可以看到，语义相似的句子——例如“I adore my dog”、“I love my dog”和“I like my dog”这三个句子——在空间中聚集在一起。

图7.4 句子在嵌入空间中的排列

Alex 对分布式相似性非常着迷。它使他能够将客户的数据转换成一种高效的数值格式，既能准确反映数据的语义，又能用于后续的搜索。于是，他开始尝试不同的嵌入模型。尽管大多数商业LLM提供商（如OpenAI和Cohere）都提供嵌入模型的API，Alex仍然相信他能快速集成一个开源模型，从而降低成本并提高定制化能力。他前往Hugging Face，测试了多种方案，包括Doc2Vec、MiniLM和Universal Sentence Encoder。

在为Tom的Confluence页面生成嵌入后，他们进行了一轮快速的效果评估。此时，他们只是凭直觉观察不同模型认为相似的页面对，结果发现MiniLM生成的效果最为准确。Alex知道他可以进一步针对Tom及其他客户的数据进行模型微调，但目前他先继续完成端到端的流程。下一步是将嵌入存储到数据库中，以供搜索算法调用。

构建你的嵌入数据库

为了支持Alex的开发，Tom为他提供了公司Google Drive和Confluence的访问权限——这些是常用且包含大量新内容的数据源。图7.5展示了Alex构建嵌入数据库的过程。

当 Alex 审查数据时，他注意到文档长度差异很大。有些文档简短只有一页，有些则是篇幅较长、结构松散的笔记，还有些是跨越多页的详尽报告。Alex 疑惑：需要统一长度的语义嵌入，是否能有效捕捉如此多样化内容的语义？

他的疑虑是有道理的——文本长度是语义搜索的重要考量。过短的文本可能承载不了足够的语义，难以准确匹配用户查询；而过长的文本可能涵盖多个不同话题，导致嵌入向量产生噪声。嵌入模型在处理长度适中且相似的文本时效果最佳。因此，第一步是将文档拆分（chunking），即把文档分割成长度相近的片段，以增加每个片段专注于单一主题的可能性。Alex 决定从固定大小拆分开始，把文档分成每段300个token。

接着，Alex 使用 MiniLM 为这些片段生成嵌入，并将结果存储到 Weaviate——一个简化语义嵌入存储、索引和检索的嵌入数据库。嵌入数据库有多种类型和应用场景。除了商业方案如 Weaviate 和 Pinecone，还有以下选项：

www.ibm.com/products/wa…

如果你对这些选项的技术差异感兴趣，可以参考 “An (Opinionated) Checklist to Choose a Vector Database” （mng.bz/V9dO），该文提供了选择适合你具体]() RAG 应用的嵌入数据库的结构化方法。

执行语义搜索

Alex 现在可以通过数据库中存储的嵌入执行搜索。搜索算法已内置于他的嵌入数据库，无需额外开发。Alex 仍想深入了解以优化搜索质量。他了解到，在语义搜索中，相似度近似于相关性，即嵌入在代数空间中的距离。首先，用于生成文本片段嵌入的模型也被用来生成用户查询的嵌入。然后，算法检索与查询最相似的前k个文本嵌入。图7.6 展示了语义搜索的流程。

注意：最广泛使用的相似度度量是余弦距离（cosine distance）。还有其他选项，如内积（inner product）和欧氏距离（Euclidean distance），你也可以尝试；更多选项请参见 mng.bz/xZmY。

这里的 k 是要检索的文本数量，是针对具体应用需要调整的参数。如果 k 过大，可能会检索到大量无关结果，计算时间也会增加；如果 k 过小，结果可能不包含用户需要的相关信息。

检索步骤看似简单，却不易做到精准。Alex 发现 Weaviate 检索出的 top-k 文档并不总是与他的测试查询相关。主要原因之一是嵌入向量在转换过程中丢失了部分文本的初始信息，从而影响了整个系统的准确性。在第 7.2.4 节，你将看到一些优化技术；但在应用这些技术之前，我们需要先评估搜索系统的表现和潜在改进效果。

7.2.3 搜索评估

对搜索系统进行评估非常重要，它是发布前的最后一步，也是进行高级优化（如细化分块策略或改进检索算法）的基础。没有评估，你可能会优化错误的环节，浪费时间和资源。下面介绍三种评估方法——定性、定量和实际应用评估。你不需要一开始就使用所有方法，通常先采用不需要大量数据的定性方法，随着数据积累和优化深入，再逐步引入更高级、更可靠的度量。

定性评估

定性评估可以从开发团队手动感受开始，逐步开展更系统的实验。对 Alex 来说，这能让他获得关于搜索系统表现的真实反馈，了解用户（如 Tom 的团队）是否觉得搜索有用。早期收集详细反馈，有助于识别改进方向并为后续调整建立基准。常用定性方法包括：

用户研究

相关性评估

基于任务的评估

虽然定性评估为 Alex 提供了宝贵反馈，但他知道这远远不够。随着应用规模扩大、用户增多，他需要更可靠、量化的评估策略。

定量评估

定量评估帮助衡量搜索系统的准确度和相关性，支持更有针对性的优化。它需要“标准答案”，即输入（搜索查询）和期望输出的集合，用来对比系统实际输出。Alex 的标注团队整理了一套多样化的常用查询，反映真实用户需求。例如测试“工作流自动化最佳实践”、“免费套餐用户反馈”等查询，作为基准评测搜索系统对不同信息的表现。然后，团队人工评定检索结果的相关性，形成评测基线。

Alex 使用以下三个关键指标评估搜索性能：

精确率（Precision）

召回率（Recall）

平均倒数排名（Mean Reciprocal Rank，MRR）

这些指标还可以指导后续优化，验证改进是否达到预期效果。

真实环境监测与持续调整

完成量化评估后，Alex 明白持续监测实际环境中的表现至关重要。即使测试表现良好，随着新数据和文档的加入，或用户行为变化，搜索性能也会波动。在生产环境中，他监控以下指标：

点击率（Click-through Rate，CTR）

查询日志分析

用户参与度指标

Alex 还分析完整用户会话。例如，Tom 的团队在准备报告时连续执行多次查询，Alex 评估整体会话效率，帮助他全面理解搜索系统对用户工作流程的支持程度。

通过建立定性和定量评估体系，Alex 确保自己充分了解检索系统表现，为后续优化指明方向，比如改进文档拆分策略和提升结果排序效果。

7.2.4 优化你的搜索系统

随着 Alex 持续优化内容生成应用中的搜索系统，他认识到通过调整多个环节提升结果的准确性和相关性至关重要。通过细化文档拆分方法、调整嵌入模型、整合元数据和改进检索算法，系统能发挥最佳性能，为用户提供有价值的结果。图7.7 总结了当前搜索系统的完整架构，并指出了优化的潜力所在。

高级分块方法

在优化过程中，我们通常首先处理数据预处理环节。因此，Alex 需要改进对文档（如文章、报告和研究论文）的分块方式。到目前为止，他采用了最简单的方法——按固定的200个token分块。现在，他想尝试一些更高级的方法，以保留文本的语义。经过进一步检查他的文档集合，他还发现不同类型的文档可能需要不同的分块技术：

对于相对较短的内容，如操作指南或案例研究，按句子或段落拆分效果较好。每个部分独立，便于检索特定信息。对于更复杂的内容，如行业分析或市场趋势报告，语义分块可以根据文本含义拆解文档，确保每个片段对应一个独立主题。对于较长文档，如年度报告或深度研究论文，分层分块可以先将文本拆成章节或部分，再进一步细分成更小的块。这让用户能快速定位相关章节，无论是寻找执行摘要还是详细分析。

此外，Alex 还尝试了不同大小的分块。较短的分块适合用户需要具体细节时使用，比如财务报告中的统计数据；较长的分块则适用于生成开放式内容并需要更多上下文的场景，比如基于广泛行业见解撰写详细报告时。较长的分块确保检索到的内容提供足够背景，帮助用户产出信息全面且有深度的成果。

上下文化分块

分块往往会切割信息，丢失关键上下文。上下文检索（contextual retrieval）通过在嵌入和索引前为每个分块添加背景信息来解决这个问题。例如，假设语义搜索检索到一个分块内容是：“该平台将处理时间缩短了30%。”单独看这句话缺少重要细节：是哪个平台？什么流程？何时发生的？上下文检索会为其添加相关背景，如：“该案例研究描述了一家物流公司如何在2023年第四季度利用该平台将发票处理时间缩短了30%。”添加了这些上下文信息，搜索系统能处理更精确、更有意义的数据，从而提升检索质量和生成响应的准确度。

由于手工标注数百万个分块不可行，Alex 采用自动化方式。通过一个简单的提示，让语言模型基于周围文档内容生成简短、针对特定分块的摘要：

Given this document and chunk, generate a concise summary to clarify its meaning for retrieval.

这会生成一个50到100个token的上下文，该上下文会被附加在嵌入和索引之前。实施上下文检索后，Alex 发现检索失败率下降了35%。

微调嵌入模型

接下来轮到嵌入模型发挥作用了，它负责捕捉查询和检索文档的语义，其性能对于保证搜索结果的相关性至关重要。
当Alex尝试使用预训练模型如Sentence Transformers或MiniLM时，他发现这些模型有时会忽略领域特定的细微差别，尤其是在用户检索技术报告或行业白皮书时。为了解决这个问题，Alex使用专有文档（如内部报告、案例研究和客户白皮书）对MiniLM嵌入模型进行了微调。这保证了模型能够理解行业特有的语言和概念。例如，微调后，系统能够识别“ROI”（投资回报率）和“成本效益”等词在某些行业中经常一起出现，从而提升了针对Tom及其团队等专业用户的搜索结果相关性。

增加词汇搜索以提升精确度

尽管语义搜索效果显著，但在某些情况下，特定术语或短语需要精确匹配，尤其是涉及高度专业或公司特定查询时。
例如，Tom团队搜索“augmented workflow”（增强工作流）这一产品分类中的固定短语时，语义搜索返回了各种相关文档，但它们不一定指向这一具体功能。另一位在DevOps公司的用户抱怨无法从API文档中准确检索出提及特定端点的内容。还有一名航空公司员工需要关于飞机“商务舱”的文档，但系统却检索到了所有与“商务”相关的资料。

Alex结合了语义搜索和词汇搜索以提升搜索的精确度，确保既能检索到精确的术语匹配，也能获取语义相关的内容。他集成了Best Matching 25（BM25）算法，这是一种通过计算术语出现频率和该术语在整个数据集中的独特性来评分文档的排序算法，如图7.8所示。这有助于优先显示最相关的匹配，而不是简单返回包含该术语的所有文档。

通过整合这两种方法，Alex 在语义搜索的上下文理解能力和词汇搜索的精确匹配能力之间找到了平衡。这确保了包含精确术语的文档能够被检索到，同时语义相关的文档也能提供额外的上下文信息。

利用元数据优化搜索结果

除了嵌入向量，元数据在优化搜索结果方面也起着关键作用，尤其是在处理大量文章、报告和白皮书时。元数据为文档提供了结构化信息，如作者、发布日期、文档类型和关键词等。

Alex 确保用户能够通过元数据筛选来细化搜索结果。例如，用户如果想查找关于云计算的最新报告，可以筛选出过去六个月内由知名行业领导者发布的报告。这种筛选极大地缩小了搜索范围，使用户更容易找到最相关、最新的信息。

此外，Alex 认识到内容必须依赖及时的最新信息。因为每份文档都有时间戳，他在搜索算法中引入了时间偏差，使得较新的文档在搜索排名中获得优先，而较旧的文档则被降权，排在后面。

利用重排技术解决信息损失问题

语义嵌入将文本信息压缩成密集的数值格式，虽然便于后续处理和计算，但会丢失一些原始信息。如果检索仅依赖嵌入，可能导致不准确，最相关的文档未必排在前列。

Alex 在系统中发现了这一问题，他采用了一种称为“重排”（reranking）的技术来解决。首先使用嵌入检索到较多相关文档，然后对这些文档原始内容与查询的相似度重新评估并进行排序。重排器是针对具体应用训练和微调的额外监督模型，例如 Cohere Rerank（txt.cohere.com/rerank/）。重排器处理原始文档，从而恢复压缩过程中丢失的信息。由于重排在推理阶段运行，它还能结合用户查询的上下文更准确地分析文档含义，而不是仅仅生成一个泛泛的平均意义。

既然重排更准确，为什么不直接跳过语义搜索，对所有文档进行重排呢？答案是性能。语义搜索速度快（数值表示已预计算），而重排速度慢。因此，最优方案是先用嵌入检索出一批相对相关的文档，再用重排器从中选出最相关的结果。

在整个优化过程中，Alex 持续评估搜索系统的表现，跟踪量化指标和真实用户行为。通过监测用户首次搜索是否找到相关信息及其与搜索结果的交互，Alex 能够进行迭代改进，确保系统持续提供快速、准确且上下文相关的结果。但在最终定型之前，他还需将语义搜索集成进更大的RAG系统框架中进行综合评估。

7.3 构建端到端的 RAG 系统

RAG 优雅地将语义搜索与大型语言模型（LLM）的文本生成能力结合起来，确保信息访问更加直接且直观。因此，用户无需从众多搜索结果中筛选、总结结论，而是能够直接获得对其查询的答案。例如，在 Mark 的系统中，RAG 系统会直接生成针对特定主题的定制化专业内容。图 7.9 展示了 RAG 系统的整体架构。

图 7.9 RAG 系统示意图。用户通过查询向系统发出请求，系统将结果输入到嵌入数据库。这些结果生成增强型提示，输入到大型语言模型（LLM），由 LLM 生成对用户查询的最终响应。

让我们回顾并理解“检索增强生成”（retrieval-augmented generation，RAG）这一术语的组成部分：

语义搜索用于从数据库中检索最相关的文档。这些文档被用来为提示增加相关的上下文信息。LLM 利用这些特定知识来生成答案。

虽然搜索通常作为工作流中的一个额外子步骤执行，RAG 则自动将搜索结果整合进下游任务，如问答和内容生成，消除了手动搜索步骤的摩擦，使工作流程更加顺畅。

7.3.1 基础的 RAG 系统搭建

一旦搜索功能就绪，搭建基础的 RAG 系统就非常简单。首先，选择合适的语言模型（LM）；然后，设计符合用户需求的提示，并结合从检索文档中获取的附加上下文信息进行丰富。

选择用于生成响应的语言模型

关于 LM 的选择，章节 5 中的建议（尤其是第 5.5 节描述的流程）同样适用于 RAG 系统。以下是一些额外的注意事项：

在大多数 RAG 系统中，LM 用于开放式生成。因此，Alex 选择它们来生成开放领域的内容。在其他场景下，LM 也可以直接与用户对话，这要求模型规模较大、拥有丰富的通用知识，并针对对话进行微调。典型的 LLM 是大多数 RAG 系统的理想选择（见第 5 章，第 5.2.1 节）。由于 RAG 系统中的提示需要容纳多个文本块，提示较长。需要考虑输入 token 的成本，以及 LLM 处理长上下文的能力，尤其是提示中间区域信息处理的关键能力 [3]。了解你是否希望系统的响应融合通用的世界知识，还是只使用数据库中的信息。如果系统主要用于检索事实信息，建议依赖数据库内部信息；如果想进一步丰富信息，则可以借助 LLM 丰富的领域知识。例如，Alex 希望在内容生成时最大化访问知识，使内容更加丰富、有趣且有差异化。在这种情况下，应优先选择对用户相关领域和关系有良好理解的 LLM。目前，Alex 使用的模型——商业版的 GPT-4o 和开源版本的 Llama 3.2——似乎满足这些要求，因此他继续构建 RAG 系统的提示。

构建基础的 RAG 提示

检索完成后，top-k 文本块可作为上下文供 LLM 生成响应。RAG 提示的主要组成部分包括：

系统提示，告诉 LLM 使用提供的来源，例如：“使用提供的上下文回答以下查询，简明扼要。”指令。包含检索到的文本块的上下文。

Alex 在筛选现有提示后，设计了以下增强版 RAG 提示：

[system prompt]You are an expert content creator with deep knowledge of AI regulations, including the EU AI Act. You are tasked with writing high-quality content that educates professionals about AI compliance. You understand industry trends and legal implications, and your tone is authoritative yet accessible. For each task, you get access to a range of high-quality sources. You actively use these sources in your content.[instruction]Generate a detailed blog article on the <topic>[EU AI Act]. The article should be informative, actionable, and easy to understand for business professionals looking to ensure their AI systems are compliant.[context]Here are the sources based on which you should generate the blog article:[{“url”:“https://www.euractiv.com/section/tech/news/controversial-california-ai-bill-can-inspire-and-enhance-eu-ai-regulation-experts-say/”,“text”: “Experts think a controversial California artificial intelligence (AI) bill regulating the most powerful AI models could strengthen and complement EU AI regulation if passed, but as it enters the final legislative phase the bill faces opposition from both industry and congress democrats.”},{“url”: “https://commission.europa.eu/news/ai-act-enters-force-2024-08-01_en”,“text”: “Proposed by the Commission in April 2021 and agreed by the European Parliament and the Council in December 2023, the AI Act addresses potential risks to citizens’ health, safety, and fundamental rights. It provides developers and deployers with clear requirements and obligations regarding specific uses of AI while reducing administrative and financial burdens for businesses.”},{“url”:“https://www.euronews.com/next/2024/10/16/are-ai-companies-complying-with-the-eu-ai-act-a-new-llm-checker-can-find-out”,“text”: “The leading generative artificial intelligence (GenAI) models, including OpenAI, Meta and Anthropic, don’t fully comply with Europe’s AI rules, according to a report released on Wednesday.”},…]

他迅速搭建了一个用户界面原型，用户可以选择角色（例如 AI 合规专家）并自定义系统提示。之后，用户输入指令，完整的提示会自动组装完成。

这就是 RAG 系统的第一个简单搭建步骤。一旦你拥有文档集合和搜索机制，编写合适的提示，整合到大型语言模型中，系统就可以运行了。然而，尽管这可能作为概念验证有效，构建和维护一个生产级别的 RAG 系统绝非易事。为了实现并保持稳定且高质量的输出，产品团队需要优化多个参数，例如提示内容和用于生成响应的语言模型。在深入这些高级技术之前，我们先定义一个合适的 RAG 系统评估策略。

7.3.2 评估你的 RAG 系统

RAG 系统是一个复合型 AI 系统，包含两个主要步骤——检索相关信息和生成响应。分别评估这两个步骤以及整体系统的性能，对于进行有效改进至关重要。

组件级评估

让我们看看 Alex 如何评估他的 RAG 系统的两个核心组件。对于检索部分，流程已在第 7.2.3 节介绍过。Alex 通过精确率、召回率和平均倒数排名（MRR）等标准定量指标衡量搜索结果质量，这些指标帮助他理解系统从客户内部文档库中检索相关文档的效果。

但在评估响应生成时，情况更复杂。与搜索结果通常有明确的正确性不同，生成式输出变化较大。针对同一个查询，模型可能给出多种不同但均有效的回答。例如，用户问：“AI 最新趋势有哪些？”系统可能生成一系列答案，有的强调技术进展，有的关注市场采纳。

Alex 采用了类似于评估语言模型时的方法来处理这种复杂性。他通过固定评估过程中的某些变量来保持一致性。例如，测试系统生成报告结构的连贯性时，他固定检索结果，确保输出变化只源于提示调整，而非检索数据的差异。

Alex 计划随着用户使用逐步用真实数据完善评估，随着查询和生成响应增加，评估将更贴合实际使用场景。

端到端评估——用大型语言模型作为裁判

在完成组件级评估后，Alex 进行端到端评估，考察系统整体性能，尤其是检索相关信息和生成有用且准确响应的能力。为了扩大评估规模，Alex 使用一小批强大的大型语言模型对应用的输出质量进行评价。例如，当应用需要生成一份“软件即服务（SaaS）中的 AI 趋势”报告时，Alex 让 LLM 基于两个关键标准评估回答：

内容基于性（Groundedness）

答案相关性

此外，当收到诸如输出风格或语调等表现问题反馈时，Alex 会临时纳入评估。这需要严密监督，因为大型语言模型作为裁判（LLMaaJ）的评估质量，极大依赖于评价标准的设置。

鉴于这些评估对系统性能的了解至关重要，Alex 选择了最先进的 LLM 进行评估。截止 2025 年，他使用 GPT-4o 和 DeepSeek。使用顶尖模型如 GPT-4o 进行评估，精确度和准确性值得这笔投入，确保上线过程有信心，同时可靠地衡量优化效果。

7.3.3 优化你的 RAG 系统

在持续完善 RAG 系统的过程中，Alex 识别出几个可优化的关键组件：他可以提升用户查询表达、改进提示内容及其附加上下文的方式，并对 LLM 进行针对客户特定领域的微调，如图 7.10 所示。这些要素共同构成生成相关、连贯且符合用户需求内容的基础。

分析和优化用户查询

Alex 发现用户经常提交含糊或结构不佳的查询，这使得系统难以检索到准确的信息。例如，一位产品经理可能会问：“我们应该关注 AI 哪些趋势？”虽然这个问题看似简单，但范围过于宽泛，难以进行精准检索。系统可能返回涵盖医疗领域的 AI、金融领域的 AI 等多种结果，这些内容可能并不符合用户的实际需求。

为了解决这一问题，Alex 实施了查询扩展和查询转换技术。系统不会仅依赖原始输入，而是对查询进行重写和扩展，以提供更优质的结果。例如，“我们应该关注 AI 哪些趋势？”可以扩展成针对客户的子查询，如“面向 SaaS 平台的最新 AI 趋势有哪些？”以及“哪些 AI 发展正在影响工作流自动化？”这些精细化的查询能让系统检索到更有针对性的信息。

随着时间推移，Alex 发现用户查询行为呈现出越来越多的模式。他决定集成查询分类功能，将不同的查询引导至不同的处理流程。例如，当用户询问 AI 相关内容时，系统会判断该查询是关于技术进步、市场趋势、产品集成还是其他主要领域。此信息用于设置检索参数，比如为特定查询类型优先检索某些数据源。

优化提示语

有时，Alex 的模型生成的内容并非基于检索到的文档。例如，在被要求生成一份关于 SaaS 中 AI 趋势的报告时，模型可能引入了它在训练中见过的与 AI 医疗领域相关但无关的示例。为此，Alex 动态地向提示语中添加约束。当用户生成高度特定的内容，比如基于公司内部文档的教程时，会加入以下约束条件：

[constraints]Observe the following constraints:Use only the information from the provided sources.When referencing a source, include the URL or document title.

相反，对于更具探索性质的内容——例如一篇关于 AI 代理在工作流自动化中应用的启发性文章——模型则被指示更多地利用其已有的知识：

[constraints]Observe the following constraints:Combine this information with your general knowledge to generate a comprehensive analysis.

这样，模型不仅仅是简单地重复文档内容，而是能有效地将检索到的内容与其更广泛的知识结合起来，同时保持主题的连贯性。

Alex 还尝试了高级提示技术，如链式思维（CoT）提示（见第6章6.3.1节），该方法指导模型将复杂查询拆解为逻辑步骤。例如，在撰写技术报告时，提示可能先引导模型总结关键趋势，解释这些趋势对不同行业的影响，并为 Tom 的公司提供可行的见解。这种方法减少了错误的可能性，确保内容组织有序、易于理解。接着，再通过反思提示（见第6章6.3.3节）进行内容的最后润色，消除任何残留的不一致。

高效的增强与上下文策划

当系统检索到相关文档后，Alex 发现一个常见问题——直接将所有检索到的内容输入模型生成文本，往往导致输出内容重复或断裂。例如，在生成关于 SaaS 中 AI 趋势的报告时，系统从多个来源抓取了类似的观点，造成内容冗余。

为改善这一点，Alex 实施了融合处理。系统将相似信息合并，去除冗余并连贯地组织内容。例如，如果两个来源讨论了同一个 AI 趋势，系统会将信息整合为统一且简明的说明，而非重复相同观点。该融合过程还能确保语调和风格的一致性，这对于保持最终生成内容的专业和精炼至关重要。

此外，Alex 引入了多轮检索，针对复杂内容如白皮书或市场分析，系统会在第一轮检索基础上再获取额外的上下文信息，填补遗漏。通过迭代检索，确保最终文档内容详尽、完整。

工程角：GraphRAG 利用结构化知识增强 RAG
GraphRAG 通过将图结构化数据引入检索过程，改进了传统的 RAG。它不仅依赖文本相似度，还利用实体之间的关系检索更丰富、更精准的上下文信息。
为何使用 GraphRAG？
基于实体关系而非仅关键词匹配，提高检索准确度。通过检索结构化知识，增强对复杂多步查询的上下文感知。通过将 AI 回答依托于结构化知识库，减少幻觉，提高输出可信度。
如何在系统中实现 GraphRAG：
构建知识图谱，将结构化和非结构化数据转换成图，节点代表实体（如公司或产品），边代表实体间的关系（如“被收购”、“竞争对手”等）。启用基于图的检索，通过子图遍历提取相关联的信息，而非孤立的文本片段。将图检索与 RAG 流水线结合，融合语义搜索（向量嵌入）和图推理，呈现最相关的见解。根据具体领域定制图谱结构，例如金融领域建模法规、公司与市场事件间的关系。
GraphRAG 尤其适合技术、法律和研究密集型应用，单纯检索孤立文本片段不足以满足需求。引入结构化知识使得 AI 驱动的检索更具洞察力、可解释性和可信度。欲了解更深入的实现细节，可参阅微软的 GraphRAG 项目（microsoft.github.io/graphrag/）以及论文“Graph Retrieval-Augmented Generation: A Survey”[4]。

为领域专属知识微调大型语言模型（LLM）

随着Alex尝试各种优化，他的RAG系统生成的内容明显得到了提升。然而，他意识到语言模型本身有时缺乏撰写专业且具有说服力文本所需的深度领域知识。尤其在数据源可能包含不准确或矛盾信息的主题上，这种情况尤为尴尬。例如，当模型被要求撰写B2B自动化领域中AI的深入分析时，它往往引用许多为营销目的撰写的文章，明显偏向某些特定产品或方案。输出结果反映了这种偏见，推崇相关产品和公司，这对于希望确立自身产品定位和思想领导力的Alex的用户来说是个致命缺陷。于是，Alex决定对其开源模型进行微调，进一步加强内容生成的可靠性。语言模型微调的相关内容将在第8章详细讲解。如果你想暂停一下，更深入理解RAG系统及其优化策略，可以参考综合调研论文《Retrieval-Augmented Generation for Large Language Models: A Survey》[5]。

总结

检索增强生成（RAG）系统将语义搜索与大型语言模型（LLM）结合，检索相关文档并利用这些文档生成具体、最新且具有上下文相关性的内容。RAG帮助产品构建者弥合生成式AI强大能力与用户特定领域和数据之间的差距。语义嵌入是现代自然语言处理（NLP）的关键表示方法，能准确反映词语和文本的语义。语义嵌入使得在搜索上下文中（无论是独立搜索还是作为RAG系统一部分）高效检索相关文档成为可能。在提示中提供检索到的文档作为额外上下文，确保LLM的回答具有事实依据并符合领域特点。通过测量上下文相关性、事实依据性和答案相关性来评估RAG系统，确保输出的高质量和可靠性。RAG系统虽设计简单，但实现不易。完成基础的端到端系统搭建后，产品团队需尝试多种优化参数，以达到高质量输出。为优化语义搜索，可采用先进的分块方法、改进嵌入模型，并加入词汇搜索和元数据过滤器以实现更精准的检索。为优化响应生成，可微调用于内容生成的提示和语言模型。