如何构建 RAG 流水线：分步指南

大多数人工智能系统在被问及从未见过的信息时会惨遭失败。

根本缺陷不在于语言模型本身，而在于将其视为独立的预言机，而非协作伙伴。

当您学习如何构建 RAG 管道时，您实际上是在教 AI 实时进行事实核查，将不可靠的生成模型转变为值得信赖的知识系统。这种架构转变悄然改变了前瞻性公司部署 AI 的方式，通过基于事实、可验证的响应，将臭名昭著的“幻觉问题”转变为竞争优势。

什么是 RAG 管道

搜索和人工智能通常承诺“问我任何问题！”，但现实可能令人失望。大型语言模型 (LLM) 可能听起来很有说服力，但有时会捏造事实、遗漏最新更新，或在专业主题上表现不佳。 RAG 管道将搜索引擎与 LLM 结合，以提供更准确、更可靠的答案。

了解 RAG 管道的基础知识

RAG 分两步工作

• 检索： 就像一位细心的图书管理员，它能找到正确的信息。
• 生成： 就像一位熟练的讲故事者，它能创作出准确且引人入胜的答案。

这种协作减少了人工智能编造信息的可能性，例如给出不存在的街道的指示。

最近的研究强调了这种方法的有效性。例如，CiteFix：提高 RAG 准确性研究报告称，其 RAG 系统的整体准确性指标相对提高了 15.46%。

对于开发团队而言，RAG 具有实用性。与微调整个语言模型需要大量资源不同，RAG 系统可以逐步构建。您可以从简单开始，并根据实际反馈逐步改进您的检索方法、分块策略或嵌入模型。

RAG 管道的实际应用

RAG 管道在处理不断变化的数据时表现出色。例如

• 电子商务： 产品目录、退货政策和运输规则经常变化。RAG 驱动的助手从内部数据库和政策文件中提取最新详细信息，确保客户获得最新信息。

• SaaS： SaaS 平台（如客户服务帮助台或知识管理工具）使用 RAG 管道提供即时答案。如果用户询问 API 限制或当前停机，RAG 系统会检索实时文档和最新事件更新，然后生成准确的、带有来源引用的响应。

• 法律： 准确性至关重要。律师事务所使用 RAG 管道查找相关法规和判例法，然后生成摘要或草拟引用其来源的回复。这有助于建立问责制和信任。

RAG 管道具有适应性。它们可以搜索任何集合——PDF、Notion 页面、网络文章——并且生成模型可以根据需要被引导引用来源、总结或翻译。

结果是流畅、基于事实、最新且可验证的响应。 在信任至关重要的环境中，RAG 管道提供了可靠的基础。

设计您的 RAG 管道

每一座伟大的建筑都始于蓝图，但最好的建筑反映了其环境、用户需求和一些创造性的风险。设计 RAG 管道也遵循类似的路径。您选择的架构会影响每一个用户查询、响应时间和用户满意度。

RAG 架构的关键组成部分

RAG 管道的工作方式类似于接力赛，每个参与者都小心翼翼地传递接力棒。团队包括

• 数据连接器：这些连接器从云驱动器、Notion 页面或网络档案中收集原始数据。例如，一个连接器可能会在清晨从 Google Drive 中提取策略文档，而另一个连接器则每小时从 Notion 中获取产品常见问题解答。
• 嵌入模型：这会将每个段落翻译成独特的指纹——高维空间中的一个向量。它创建能够捕捉每个数据块精髓的向量。正确的模型取决于您的内容；法律文档可能需要与电子商务支持聊天不同的方法。
• 向量数据库：这就像一个超级图书馆卡目录。例如，搜索“数字商品的退款政策”将找到讨论“退货”、“下载”或“商店积分”的文档，即使措辞不同。
• 检索机制： 该组件充当智能导航器，确定在哪里以及如何搜索相关信息。
• 生成模型：最后的讲故事者，将检索到的事实编织成连贯的、上下文丰富的答案。无论是 GPT-4 还是其他 LLM，模型合成和引用信息的能力都取决于它收到的上下文质量。

这些组件之间的交互——它们如何传递信息、从错误中恢复以及适应新数据——定义了系统的行为。

为 RAG 系统选择合适的工具

为您的 RAG 管道选择工具就像组建一支爵士乐队。每种乐器都应该表现良好，但真正的优势在于它们的互动。

下表重点介绍了 RAG 架构的每个关键步骤中常用的领先开源和商业工具。此参考资料可以帮助您启动原型设计或规划生产级部署

在 RAG 中处理不同数据类型

数据种类繁多。产品手册、客户支持聊天和监管文件各具独特特点。有效的 RAG 管道尊重这些差异。

• 结构化数据与非结构化数据：产品规格的 CSV 文件可以按原样索引，每行作为一个块。法律合同受益于递归分块——如果需要，可以按部分、段落，然后按句子拆分。
• 多语言内容
• 动态内容：价格或库存等经常变化的数据需要快速重新摄取和重新索引。

了解您的数据类型并进行适当处理可确保相关且可信的响应。

逐步构建 RAG 管道

本指南中，我们将从原始数据到智能对话答案，构建一个完整的 RAG 管道。您将看到 LangChain、Meilisearch 和 OpenAI 等工具在每一步中的实际应用。

数据摄取和准备

首先整理您的数据源，包括 PDF、Notion 页面、Google Docs 和网页文章。有些源结构良好，而另一些则包含复杂的脚注和侧边栏。您的首要任务是使这些多样性有序。

为每个数据源编写连接器。例如，使用 LangChain 的 PDFLoader 处理 PDF。

import { PDFLoader } from "@langchain/document_loaders/fs/pdf";
const loader = new PDFLoader("path/to/handbook.pdf");
const docs = await loader.load();

LangChain 有数十种文档加载器，几乎可以支持您能想象到的任何数据源。例如，CSVLoader 可以处理结构化的电子表格数据，而像 RecursiveURL 这样的网络专用加载器可以抓取并提取整个网站的内容（以及所有链接的子页面）。您还可以找到适用于 PDF、Slack、Google Drive、Reddit 等的连接器。

分割内容

接下来，我们需要将文档分割成块，以便每个块都足够小以进行高效处理和检索，但又足够大以在回答查询时提供有用的上下文。

将文档分成块。分块平衡了上下文和大小：太小会丢失上下文，太大则会使系统不堪重负。

LangChain 的 RecursiveCharacterTextSplitter 尊重自然边界

import { RecursiveCharacterTextSplitter } from "@langchain/text_splitter";
const splitter = new RecursiveCharacterTextSplitter({
  chunkSize: 1000,
  chunkOverlap: 100,
});
const chunks = await splitter.splitText(rawText);

对于复杂查询，语义分块根据嵌入相似性检测到的主题变化进行分割。最佳分块策略取决于您的领域。

LangChain 提供了多种文档分块技术，以优化数据处理，用于检索和下游任务

• 基于长度的分割： 按标记或字符分割文档。
• 基于结构的分割： 利用 Markdown、HTML 或 JSON 结构等元素。
• 基于语义的分割： 检测主题变化以实现更具上下文感知的分块。
• 递归文本分割： 迭代应用多种分割方法以精细化分块。

生成嵌入

使用 embedder.embedDocuments() 批量生成嵌入，以并行生成 1536 维向量

import { OpenAIEmbeddings } from "@langchain/openai";
const embedder = new OpenAIEmbeddings({
  openAIApiKey: process.env.OPENAI_API_KEY,
  modelName: "text-embedding-ada-002"
});
const embeddingVectors = await embedder.embedDocuments(chunkTexts);

批量嵌入可以节省时间并降低成本。例如，批量处理 10,000 个文档的语料库可以降低 30% 的成本，并将处理时间缩短一半。

Meilisearch 支持混合搜索，将关键字精度与语义相似性相结合。配置索引以接受用户提供的向量

await index.updateSettings({
  embedders: {
    default: {
      source: "userProvided",
      dimensions: 1536
    }
  }
});

上传您已向量化、包含丰富元数据的块

await index.addDocuments(chunkArray);

此时，您的知识库成为一个可搜索的、活生生的记忆。

使用 Meilisearch 实现检索机制

检索是 RAG 的核心。这是你的 AI 图书管理员找到正确段落的时候。Meilisearch 的混合搜索将侦探工作与搜索引擎的精度相结合。

当用户询问“我们的数据保留政策是什么？”时，嵌入查询

const userQuery = "What does this policy say about data retention?";
const queryEmbedding = await embedder.embedQuery(userQuery);

使用查询及其向量搜索 Meilisearch

const results = await index.search(userQuery, {
  vector: queryEmbedding,
  hybrid: { embedder: "default", semanticRatio: 0.7 },
  limit: 3
});

semanticRatio 控制语义匹配和精确匹配之间的平衡。0.7 的比例会浮现细致入微、上下文丰富的答案，而 0.3 则倾向于精确匹配——这对于合规查询很有用。根据用户的需求调整此设置。

集成生成模型

检索到的块通过 LangChain 构成 LLM 的提示

import { OpenAI } from "langchain/llms/openai";
import { createRetrievalChain } from "langchain/chains";
const model = new OpenAI({ openAIApiKey: process.env.OPENAI_API_KEY, modelName: "gpt-4o" });
const qaChain = await createRetrievalChain({ llm: model, retriever, prompt });
const answer = await qaChain.call({ input: userQuery });

该提示指示模型：“根据以下上下文回答问题。”LLM 使用检索到的上下文，但在需要时可以即兴发挥。在客户支持中，与标准 LLM 相比，这种方法将幻觉答案减少了 40%。

为您的数据选择合适的嵌入模型

并非所有嵌入模型都表现相同。OpenAI 的 ada-002 是一个可靠的默认选项。然而，对于代码密集型文档，针对技术文本进行微调的模型（例如 Hugging Face transformer）可以提高相关性。

优化分块策略以提高检索效果

分块极大地影响了检索质量。在一个法律合规项目中，重叠块（100 个令牌）保持了关键条款的完整性，使监管查询的检索准确率提高了 15%。

对于产品常见问题解答，不重叠的块减少了噪音并提高了答案清晰度。

最佳分块策略取决于您的数据、用户和检索目标。通常，此过程涉及测试不同的方法、衡量结果并进行迭代。

构建 RAG 管道不仅仅是连接组件。 每一个深思熟虑、具有上下文意识的决策都塑造了您的 AI 如何为用户提供服务、提供信息和支持。 代码很重要，但真正的技能在于您在整个过程中做出的选择。

部署和优化您的 RAG 管道

启动 RAG 管道就像开通一条新铁路线：真正的挑战始于用户到来，揭示出意想不到的问题以及持续关注的必要性。

本节介绍如何操作、扩展和优化 RAG 系统，使其从原型发展为可靠的业务解决方案。

监控和维护您的 RAG 管道

RAG 管道是一个需要持续维护的活系统。文档会发生变化，法规会演变，用户行为也会发生变化。最优秀的团队会像对待高性能车辆一样对待他们的管道——始终保持调优，从不闲置。

监控不仅仅是正常运行时间。它详细跟踪检索和生成质量。例如，一位 SaaS 技术负责人可能会设置仪表板来监控

• 检索延迟，包括 Meilisearch 搜索时间和嵌入 API 响应时间

• 查询量和分布以识别热门主题
• 检索准确性，检查基准查询的前 3 个结果中是否出现正确的块
• LLM 响应质量，通过用户反馈或自动评分衡量

您可以使用 LangChain 的 LangSmith 来记录每个查询、检索到的块和最终答案。当用户标记出糟糕的响应时，团队会追溯问题到检索错误或 LLM 幻觉。这项侦查工作通过改进分块和检索设置，在两个月内将答案准确性提高了 15%。

维护还包括保持知识库的最新性。计划任务会重新摄取和重新嵌入已更改的文档。例如，一家与 Notion 和 Google Drive 同步的公司每晚运行一个任务来

• 检查更新
• 仅重新分块和重新嵌入已更改的内容
• 将更新的块插入 Meilisearch

这种增量方法降低了成本，并确保用户访问最新信息。

衡量 RAG 管道的有效性

有效性涉及多个信号，而不仅仅是一个数字。有些指标是明确的，例如延迟、每次查询的成本和检索召回率。另一些则更微妙，例如用户信任、感知的答案质量以及棘手情况的处理。

具体指标包括

• 检索召回率@k：正确答案出现在前 k 个结果中的查询百分比
• LLM 幻觉率：包含不受支持或虚假声明的答案百分比
• 延迟 (p95)：第 95 百分位响应时间
• 每次查询成本：嵌入、LLM 和基础设施成本的总和
• 用户反馈得分：用户对答案有用性的直接评分

数字并不能说明全部。你可能拥有很高的召回率@3分数，但用户仍然抱怨答案不相关。在这种情况下，分块策略可能过于宽泛，将重要细节埋藏在冗长的段落中。切换到带有重叠的递归分块可以提高检索精度和用户满意度，即使召回率@3几乎没有变化。

有效性也取决于信任。在受监管行业中，将答案追溯到其来源至关重要。团队将源元数据包含在每个块中，并指示 LLM 在其答案中引用源。这建立用户信心并支持合规性。

RAG 管道的高级考量

构建 RAG 管道需要坚实的基础，但真正的挑战在于系统面临实际使用、不断变化的需求和意想不到的问题时。最有效的 RAG 系统不仅技术健全，而且 具有弹性、成本效益，并考虑到隐私。本节将涵盖 RAG 实施中的实际挑战和解决方案。

成本分析和优化策略

想象一家 SaaS 初创公司推出了一款由 RAG 驱动的支持机器人。最初，一切运行良好。然后，用户查询的激增导致 OpenAI 账单飙升。突然之间，每一次 API 调用、嵌入和文本块都被仔细审查。在 RAG 中，成本会根据设计选择而波动。

例如，一个团队处理 10,000 个策略文档，每个文档分成 20 个块，导致 200,000 次嵌入调用。以每个嵌入 0.0001 美元（使用 OpenAI 的 ada-002）计算，初始成本为 20 美元。这看起来可以管理，直到更新、重新分块或新文档增加嵌入。每周刷新会迅速提高成本。

优化成本意味着确保可持续性，而不仅仅是削减开支。 考虑以下策略

• 缓存嵌入： 存储未更改文本的嵌入，以避免冗余处理。
• 批量 API 调用： 使用OpenAI 的批量处理来减少开销和延迟。
• 调整块大小： 避免太小的块（增加噪音和成本）或太大的块（可能遗漏细节）。
• 混合搜索： 将关键词和向量搜索相结合，以低成本处理常见查询，并将语义搜索保留给复杂查询。

RAG 实施中的安全和隐私

如果说成本是城市的预算，那么隐私就是其分区法——常常看不见，却总是塑造着可能性。RAG 管道通常处理敏感数据，例如内部政策、客户记录或专有研究。一个错误就可能让一个有用的助手变成一个累赘。

要构建注重隐私的 RAG 系统，请应用以下实践

• 元数据过滤： 使用Meilisearch 的过滤功能在结构化字段上标记敏感文档，并将其从特定查询中排除。
• 访问控制： 永远不要在客户端代码中暴露您的 Meilisearch 主密钥。使用搜索密钥或多租户令牌来限制访问。
• 审计追踪： 记录每次查询和检索，如果需要，匿名化数据以跟踪访问历史。
• 设备端检索： 对于高度敏感的数据，在本地或私有云中运行 Meilisearch，以将数据和查询保留在防火墙内。

把你的 RAG 管道想象成一个藏有珍贵手稿的图书馆。你不会让任何人 unsupervised 地在书架间漫游。相反，你会有一个签到台、限制区域和谁查看了什么的日志。同样的原则也适用于这里。

安全和隐私并非事后才考虑的——它们构成了支持 RAG 系统增长的框架。 最优秀的团队在整个管道中整合这些考量，将其视为持续的责任，而非一次性任务。

您的 RAG 管道之旅从这里开始

构建 RAG 管道使您的应用程序能够处理知识密集型任务，通过将 LLM 连接到最新数据，使其变得动态。

借助 Meilisearch 的混合搜索和所讨论的架构，您可以创建平衡精度、召回率和简洁性的系统，以实现快速迭代。

人工智能的未来不仅取决于更好的模型，还取决于在正确的时间将它们与正确的信息连接起来。