RAG 如何为您的数据启用 AI

✂️使用 QA Wolf (赞助) 将您的 QA 周期缩短至几分钟

如果缓慢的 QA 流程成为您或您的软件工程团队的瓶颈，并且因此导致发布速度变慢 — — 您需要查看 QA Wolf。

QA Wolf 的 AI 原生服务支持 Web 和移动应用程序，在几周内提供 80% 的自动化测试覆盖率，并通过将 QA 周期缩短至几分钟来帮助团队将交付速度提高 5 倍。

QA Wolf帮您完成测试。他们可以帮您：

• 移动和 Web 应用程序的无限制并行测试运行

• 24 小时维护和按需测试创建

• 人工验证的错误报告直接发送给您的团队

• 零碎屑保证

好处是什么？不再需要手动端到端测试。不再需要缓慢的 QA 周期。生产环境中不再出现 bug。

借助 QA Wolf， Drata 的 80 多名工程师团队实现了 4 倍的测试用例和86% 更快的 QA 周期。

安排演示以了解更多信息

像 GPT-4 和 Claude 这样的大型语言模型彻底改变了我们与计算机交互的方式。然而，尽管它们在一般场景中拥有令人难以置信的实用性，但它们也面临着一些根本性的限制，使得它们无法在许多商业环境中立即发挥作用。

其中一些限制如下：

• LLM 的知识通常在其训练截止日期就被冻结了。如果我们向 GPT-4 询问其训练数据收集之后发生的事件，除非它连接到互联网收集信息，否则它根本无法得知。

• LLM 无法访问公司私有数据。组织的内部文档、客户记录、产品规格和专有流程不属于任何公共模型的训练数据。当员工询问公司政策或客户询问特定产品时，标准 LLM 只能根据从公共互联网数据中学习到的常见模式提供通用的响应。

• LLM 也容易出现幻觉，他们会编造看似合理但却错误的信息。当被问及他们不了解的具体细节时，他们可能会自信满满地编造事实、引用引文或虚构场景。

• 即使法学硕士拥有相关知识，他们的回答也往往是通用的，而不是针对所需的具体情况。

检索增强生成 (RAG) 通过让 AI 系统访问特定文档和数据来解决这些问题。

RAG 并非仅仅依赖于模型在训练过程中学到的知识，而是允许系统在生成响应之前从特定的文档集合中查找相关信息。这相当于为 AI 提供了一个参考库，让它在需要回答问题时随时查阅。

帮助我们改进 ByteByteGo 新闻通讯

TL:DR：请花 2 分钟时间完成这项调查，以便我可以进一步了解您是谁、您做什么，以及我如何改进 ByteByteGo

参加 ByteByteGo 调查

CodeRabbit：CLI 中的免费 AI 代码审查（赞助）

CodeRabbit CLI 是一款直接在终端中运行的 AI 代码审查工具。它提供智能代码分析，及早发现问题，并与 Claude Code、Codex CLI、Cursor CLI 和 Gemini 等 AI 编码代理无缝集成，确保您的代码在发布前即可投入生产。

• 支持对分阶段和非分阶段变更进行预先提交的审查，从而创建多层次的审查流程。

• 兼容现有的 Git 工作流程。无需中断当前开发流程，即可审查未提交的更改、暂存文件、特定提交或整个分支。

• 根据您的需要审查特定文件、目录、未提交的更改、暂存更改或整个提交。

• 支持的编程语言包括 JavaScript、TypeScript、Python、Java、C#、C++、Ruby、Rust、Go、PHP 等。

• 提供具有速率限制的免费 AI 代码审查，以便开发人员可以免费体验高级审查。

• 标记幻觉、代码异味、安全问题和性能问题。

• 支持其他 AI 生成器、AST Grep 规则和基于路径的指令的指南。

立即开始

什么是 RAG？

从本质上讲，检索增强生成是一种将两个不同的过程结合到一个系统中的技术：

• 从文档集合中检索相关信息。

• 使用该信息生成准确的响应。

名字本身就说明了一切。我们首先检索相关文档，然后利用检索到的上下文来增强生成过程。

想象一下，你走进图书馆，向图书管理员询问一个关于当地税法的具体问题。普通图书管理员可能会分享一些关于税收的常识，但一位能够查阅该城市具体税务文件的图书管理员，可以走到合适的书架，拿出相关手册，阅读具体章节，并根据这些官方文件给出准确的答案。这就是 RAG 所做的。

RAG 和直接询问 LLM 之间的区别很大。当我们向一个标准的 LLM 询问公司的休假政策时，它可能会用在培训期间学到的典型休假政策的通用信息来回答。它可能会说“许多公司提供两到三周的带薪假期”，因为这可能是它见过的常见情况。

使用 RAG，系统首先检索实际的员工手册，找到有关休假政策的部分，然后根据该特定文档生成回复。答案将是“根据员工手册，全职员工第一年可享受 15 天带薪休假，三年后可增加到 20 天。”

请参阅下图，了解 RAG 的工作原理：

了解何时需要 RAG 以及何时标准 LLM 已足够，是做出正确架构决策的重要因素。以下是 RAG 更有用的一些情况：

• 当用例涉及经常变化的信息时，例如产品库存、定价或新闻。

• 当处理不属于模型训练数据的私人或专有信息时，例如内部文档、客户记录或机密研究。

• 当准确性至关重要并且幻觉是不可接受的时，例如在法律、医疗或金融应用中。

• 当需要提供引文或证明信息来源时，系统可以指向特定的文档和段落，从而提供标准 LLM 答复无法实现的透明度和可审计性。

• 当应用程序需要处理无法在每个提示中包含的大型文档集合时，RAG 的选择性检索就变得非常有价值。

另一方面，对于 LLM 已经可以很好处理的一般知识问题，我们不需要 RAG，例如解释常见概念、执行基本推理或创造性写作任务。

RAG 的工作原理 – 查询的旅程

这次旅程涉及两个发生在不同时间的不同阶段：

• 文档准备，在系统设置时进行一次。之后，当系统添加新的文档或信息源时，也可以进行文档准备。

• 每当用户提出问题时，查询处理都会实时发生。

这种两阶段方法非常强大，因为它在计算密集型文档准备阶段和延迟敏感查询阶段之间提供了关注点分离。

让我们更详细地看一下这两个阶段：

1 – 准备

文档准备阶段就像图书馆开馆前的整理工作。这项基础工作在用户提出任何疑问之前进行，涉及几个关键步骤。参见下图：

整个过程如下：

• 首先，需要收集和处理文档。每个文档（PDF、Word 文档、网页或数据库记录）都必须转换为系统可以处理的纯文本。此提取过程可处理各种格式，并确保实际内容与格式和元数据清晰分离。

• 文本提取完成后，系统会将其拆分成更小的块。这种拆分非常必要，因为文档通常篇幅过长，无法单独处理。一份 50 页的技术手册可能会被拆分成数百个小段落，每个段落包含几个段落。这些块的大小很重要。太小，缺乏上下文；太大，则不够精确。大多数系统使用 500 到 1000 个单词的块，并且相邻块之间通常会有一些重叠，以保留跨边界的上下文。

• 下一步是将这些文本块转换为数字表示，即嵌入。每个块都会被转换成一个数字列表，以捕捉其语义。例如，关于“季度财务报告”的块可能会变成一个像 [0.23, -0.45, 0.67, …] 这样的向量，具有数百或数千个维度。这些数字以一种允许数学比较的方式编码文本的含义。相似的概念会产生相似的数字模式，这使得系统即使使用不同的词语也能找到相关的内容。

• 这些嵌入向量以及原始文本块及其元数据随后会被存储在一个专门的向量数据库中。该数据库针对相似向量的查找进行了优化。它以一种允许在数百万个块中进行快速相似性搜索的方式对嵌入向量进行索引。与每个块一起存储的元数据通常包括源文档、页码、时间戳以及任何其他可能有助于筛选或归因的相关信息。

2 – 用户查询处理

当用户提交查询时，实时查询处理阶段就开始了。由于用户期望快速响应，因此此阶段需要快速高效。

请参阅下图来了解该过程的高级视图：

下面详细介绍了它的工作原理：

• 当用户的问题进入系统时，旅程就开始了。该问题首先会经历与文档块相同的嵌入过程。例如，“我们的电子产品退款政策是什么？”这个问题会使用与处理文档相同的嵌入模型，转换成其自身的数值向量。

• 现在，查询以向量形式呈现，系统会在向量数据库中搜索最相似的文档块。这种相似性搜索速度很快，因为它使用数学运算而非文本比较。数据库可能包含数百万个块，但专门的算法可以在几毫秒内找到最相关的块。通常，系统会根据相似度得分检索出最相关的前 3 到 10 个块。

• 然后，需要将这些检索到的词块准备好输入语言模型。系统会将它们组合成一个上下文，通常按相关性排序，有时还会根据元数据或业务规则进行筛选。例如，较新的文档可能优先于较旧的文档，或者某些来源可能被认为比其他来源更具权威性。

• 语言模型现在会同时接收用户的原始问题和检索到的上下文。提示可能包含以下详细信息：

  • 提供上下文文档。

  • 用户的具体问题。

  • 根据提供的上下文来回答的说明。

  • 处理上下文中未找到的信息的指南。

• 语言模型会处理这个增强提示并生成响应。由于其上下文中包含具体且相关的信息，因此响应可以准确详细，而非泛泛而谈。该模型可以直接引用检索到的文档，综合多个词块的信息，并基于源材料提供具体的答案。

• 最后，响应通常会经过后期处理才能到达用户手中。这可能包括添加指向源文档的引用链接、格式化响应以提高可读性，或检查答案是否正确解决了问题。一些系统还会记录查询、检索到的文档和响应，以便进行分析和改进。

嵌入 – RAG 的核心

信息检索的根本挑战在于，人们用无数不同的方式表达同一个想法。传统的关键词搜索寻找精确的词语匹配，却无法捕捉到这些变化。

例如，如果文档中说“公司允许 30 天内退货”，但用户搜索“我多久可以退货？”，尽管这些文本之间存在明显的关系，但关键字搜索却找不到任何结果。

想想人们询问电脑问题的各种方式：“笔记本电脑无法启动”、“电脑无法启动”、“系统无法开机”或“电脑死机”。这些短语几乎没有共同的词汇，但它们描述的都是同一个问题。基于关键词的系统会将这些查询视为完全不同的查询，从而错过使用不同术语的故障排除指南。这种词汇不匹配问题困扰了信息检索系统数十年。

嵌入通过捕捉语义而不是表面级别的词语匹配来解决这个问题。

语义含义指的是文本的实际含义，而不仅仅是所使用的具体词语。当文本转换为嵌入时，生成的数字代表了文本中的概念和思想。关于退货的句子最终会呈现相似的数字模式，无论它们使用的是“退货”、“退款”、“寄回”还是“换货”等词语。

将文本转换为数字的过程可能看起来很神秘，但原理却很简单。

• 嵌入模型读取文本并输出数字列表，通常有数百或数千个数字。

• 这些数字将文本定位为多维空间中的一个点。

• 我们将其视为地图上的坐标，只不过嵌入不仅仅使用纬度和经度这样的两个维度，而是使用数百个维度来捕捉含义的许多细微差别。

参见下图：

这种数值表示法实现了原始文本无法实现的数学运算。最重要的是，我们可以计算两个嵌入之间的距离，以衡量它们含义的相似程度。例如，关于“笔记本电脑维修”和“电脑修理”的文本在这个空间中的嵌入距离很近，而“笔记本电脑维修”和“烹饪食谱”的嵌入距离则很远。这种距离计算通过简单的数学运算完成，即使处理数百万个文档，也能非常快速地完成。

相似的含义会产生相似的数字模式，原因在于嵌入模型的训练方式。

在训练过程中，该模型会查看数百万个文本示例，并学习某些单词和短语在相似的语境中出现的情况。例如，“医生”和“医师”等词会出现在相似的句子中，可以互换使用，并且与相同的概念相关。该模型会学习为它们分配相似的数值模式。这种学习是通过接触大量文本自动进行的，无需任何人明确编程来设定这些关系。

嵌入尤其令人着迷，因为我们并不完全理解每个维度代表什么。当一个嵌入模型为一段文本输出 768 个数字时，我们不能简单地说维度 1 代表“正式性”，维度 547 代表“技术复杂性”。这些维度在训练过程中自然而然地出现，因为模型会弄清楚需要追踪哪些模式才能有效地理解语言。有些维度可能与我们认识的概念（例如情绪或主题）松散地相关，但许多维度捕捉的是抽象模式，这些模式并不映射到我们用词描述的任何概念上。

重要的是要理解嵌入模型和大型语言模型在 RAG 系统中服务于完全不同的目的。

• 嵌入模型专门用于一项任务：将文本转换为有意义的数字。它无法生成文本、回答问题或进行对话。它只是读取文本并输出向量。这类模型相对较小、速度快，并且在单一任务上效率较高。

• 相比之下，LLM 是旨在理解和生成类似人类文本的大型模型。它们可以编写、回答问题、总结、翻译以及执行无数其他语言任务。然而，与嵌入模型相比，它们规模更大、速度更慢、运行成本更高。

正是由于这种专业化，RAG 系统使用了两个独立的模型。嵌入模型能够高效地将所有文档和查询转换为向量，从而实现快速的相似性搜索。然后，LLM 模型会获取检索到的相关文档，并生成智能的、基于上下文的响应。

构建 RAG 系统

构建检索增强生成 (RAG) 系统时，第一步是清晰地理解需求。与大多数系统一样，一切都始于用户。以下是一些应该提出的问题：

• 该系统是否是为内部员工设计的，其中速度不如准确性和可靠性重要？

• 或者对于外部客户来说，快速响应和完善的体验最重要吗？

接下来，我们需要仔细研究文档格局。处理一百个文件还是数十万个文件，规模至关重要。不同的文件量需要不同的存储和检索策略。可能的内容类型（PDF、Word 文档、Confluence 页面或 Notion 数据库）决定了提取和预处理流程。同样重要的是，通过回答以下问题来理解查询模式：

• 大多数查询都是直接查找，例如“我们的休假政策是什么？”，还是需要复杂的推理，例如“比较第三季度和第四季度的销售策略”？

• 用户是否期望引用和审计跟踪，还是仅期望对话答案？

这些问题的答案决定了系统必须达到什么样的复杂程度。一旦需求明确，我们就可以转向技术栈。一些最流行的工具和技术如下：

• 该系统的核心是大型语言模型 (LLM)。OpenAI 的 GPT-4、Anthropic 的 Claude、Google 的 Gemini 或 Cohere 的企业模型等闭源模型易于采用且性能强劲，但它们存在供应商锁定和数据隐私问题。Llama 3、Mistral 等开源模型或专用领域模型（用于医学的 BioBERT 和用于金融的 FinBERT）提供了更强的控制力和灵活性，但需要 GPU 基础设施和内部专业知识才能大规模运行。

• 除了 LLM，我们还需要一个嵌入模型。OpenAI 的 text-embedding-3 或 Cohere 的 embed-v3 是常见的选择，而开源的句子转换器也提供了免费的替代方案。诸如 E5 或 Instructor 嵌入之类的专用模型可以进一步提高特定领域的准确性。需要注意的是，LLM 和嵌入模型不必来自同一提供商。

• 第三个构建块是向量数据库，用于存储和搜索嵌入。像 Pinecone、Weaviate Cloud 或 Qdrant Cloud 这样的云托管服务非常适合快速上手并平稳扩展，尽管价格较高。像 ChromaDB、Milvus、带有向量搜索功能的 Elasticsearch 或 PostgreSQL 的 pgvector 扩展这样的自托管解决方案可以提供更好的控制力，并且长期来看可能更便宜，但需要 DevOps 方面的投资。正确的选择取决于数据量（数十万个向量还是数十亿个向量）、查询负载（每秒数十个请求还是数万个请求）和预算。

• 最后，我们需要一个编排框架。很少有团队会从零开始构建一切。LangChain 是最受欢迎的，它拥有广泛的生态系统，并且几乎涵盖了所有组件的抽象，尽管对于简单的用例来说，它可能会显得笨重。LlamaIndex 专为文档密集型 RAG 应用程序设计，提供简洁的数据提取和查询管道。Haystack 专注于生产环境，对复杂的工作流程提供了强大的支持。

结论

检索增强生成 (RAG) 为 LLM 在商业应用中的实际局限性提供了一个切实可行的解决方案。通过将嵌入语义搜索的强大功能与 LLM 的生成功能相结合，RAG 使 AI 系统能够根据组织自身的文档和数据提供准确、具体的答案。

理解 RAG 的核心概念有助于我们做出明智的决策，判断其是否适用于特定用例。如果我们需要能够访问公司私有信息、提供最新更新、引用来源或保持严格准确性的 AI，RAG 或许就是最佳选择。文档准备和查询处理的两阶段架构使其具有可扩展性和高效性，而嵌入技术的使用则确保用户无论以何种方式提出问题都能找到相关信息。

RAG 领域持续快速发展，检索技术不断改进，嵌入模型更加完善，生成策略也更加复杂。然而，本文涵盖的基本原则始终保持不变。

赞助我们

将您的产品展示给超过 1,000,000 名技术专业人士。

我们的时事通讯将您的产品和服务直接呈现在重要的受众面前——数十万工程领导和高级工程师——他们对重大技术决策和大宗采购有影响力。

空间很快满员 – 立即预订

广告位通常提前4周左右售罄。为了确保您的广告能够触达这些极具影响力的受众，请立即发送电子邮件至[email protected] 预订您的广告位。

原文： https://blog.bytebytego.com/p/how-rag-enables-ai-for-your-data