LLM TREND

大模型技术趋势分享：LLM、RAG、Prompt、Agent、Fine-tuning等

RAG

驾驭AI：从嵌入到生产级检索增强生成（RAG）的完整指南

By llmtrend #RAG

在人工智能应用领域，有效存储、搜索和检索信息的能力至关重要。无论是构建一个能够回答有关公司文档问题的聊天机器人，还是创建推荐系统或语义搜索引擎，理解嵌入（Embeddings）和检索增强生成（Retrieval-Augmented Generation, RAG）架构都是不可或缺的。本文将带您深入了解从嵌入的基本原理到生产级RAG架构的构建过程，涵盖从分词（Tokenization）策略到向量数据库选择和优化等各个方面。

1. 理解嵌入与分词

嵌入本质上是将文本、图像或其他数据类型转换成高维向量空间中的数值表示，以捕捉其语义含义。可以将其想象成多维空间中的坐标，其中相似的概念彼此靠近。例如，句子“线粒体是细胞的动力工厂”经过嵌入后，可能变成一个由384个数字组成的向量 [0.12, -0.34, 0.89, ..., 0.45]。这个向量并非随机生成，而是经过大量数据训练，使得语义相近的句子，其向量在空间中距离更近。

分词则是将文本分解成模型可以理解的更小单元的过程，是文本转换成嵌入之前的关键步骤。有效的分词能够保证文档索引和查询处理的一致性。例如，使用 bert-base-uncased 模型进行分词，句子 “The cat sits on the mat” 会被分解成 ['the', 'cat', 'sits', 'on', 'the', 'mat']。但更复杂的词汇，如 “Mitochondria”，会被分解成子词 ['mit', '##och', '##ond', '##ria']。这种子词分词的方式，有效处理了词汇表中未出现的词语，并且提高了模型的泛化能力。

关键概念:

  • Token限制：多数模型对输入长度有限制（例如，基于BERT的模型限制为512个token）。因此，长文本需要进行切割。
  • Tokenizer一致性：索引和查询必须使用相同的Tokenizer，否则会影响检索效果。
  • 分块策略：在分割长文档时，要尽量保持语义的完整性。

2. 嵌入的必要性与作用

计算机处理的是数字，而人类交流使用的是文字。这就产生了一个根本性的挑战：计算机如何理解语义的相似性？ 例如：

  • 句子1: “The dog is running”
  • 句子2: “A canine is jogging”
  • 句子3: “The car is broken”

对于计算机来说，这仅仅是不同的字符序列。但人类知道句子1和2比句子3更相似。嵌入的出现，解决了这一难题。嵌入将文本转换成高维数值向量，捕捉其语义含义。

  • “dog” → [0.2, -0.1, 0.8, 0.3, ...]
  • “canine” → [0.18, -0.12, 0.83, 0.28, ...]
  • “car” → [-0.1, 0.9, -0.2, 0.7, ...]

向量之间的距离表示语义相似度。distance(dog, canine) = 0.05 (非常相似)，而 distance(dog, car) = 0.89 (非常不同)。这就是嵌入的魔力，它创造了一个多维语义空间，将相似的概念聚集在一起，并保留了概念间的关系。例如，通过向量运算 king - man + woman ≈ queen 可以得到近似的结果。

嵌入模型对于RAG至关重要。传统关键词搜索在很多情况下会失效。例如，用户查询 “What organelle produces energy?”，而文档内容为 “Mitochondria are the powerhouse of the cell”。关键词搜索可能无法匹配，因为没有共享的词语。但通过嵌入搜索，可以实现高度匹配，因为它理解了概念的相似性。”energy production” 和 “powerhouse”，”cell organelle” 和 “mitochondria” 在嵌入空间中距离很近。

嵌入模型是经过专门训练的神经网络，能够理解语义关系。通过学习数百万的文本对，模型能够识别相似的文本并生成相似的嵌入，不同的文本生成不同的嵌入。

嵌入模型分类：

  • 词级别模型 (Word2Vec, GloVe, FastText)：每个词只有一个嵌入，不考虑上下文。例如，”bank” 一直具有相同的嵌入，无论其是河岸还是银行。
  • 上下文模型 (BERT, RoBERTa, sentence-transformers)：嵌入会根据周围的词语变化。例如，”bank” near “river” 和 “bank” near “money” 会得到不同的嵌入。
  • 句子/文档级别模型 (Sentence-BERT, E5, OpenAI embeddings)：专门训练用于嵌入整个句子或段落，最适合用于文档检索，在RAG流程中表现最佳。

3. 从分词到嵌入再到搜索的完整流程

一个完整的流程包含以下步骤：

  1. 原始文本：例如，document = "Photosynthesis is the process by which plants convert sunlight into energy"
  2. 分词：使用 all-MiniLM-L6-v2 模型进行分词，得到 ['photo', '##syn', '##thesis', 'is', 'the', 'process', ...]
  3. Token IDs：将 token 转换成对应的 ID，例如 [101, 6302, 23433, 21369, 2003, 1996, 2832, ...]
  4. 嵌入生成：使用 SentenceTransformer('all-MiniLM-L6-v2') 模型生成嵌入，其形状为 (384,)。
  5. 存储到向量数据库：将嵌入、文本和元数据（例如，来源、章节）存储到向量数据库中。

每一步的重要性:

  • 分词：确保模型能够一致地处理文本。
  • Token 限制：防止内存溢出，保证质量。
  • 嵌入：捕捉语义信息，用于相似度搜索。
  • 一致性：索引和查询之间的一致性对于准确性至关重要。

常见的陷阱:

  • 不一致的Tokenizer：不要使用不同的Tokenizer进行索引和查询。
  • 忽略Token限制：需要将长文档分成多个 chunk。
  • 为任务选择了错误的模型：不要使用词级别模型进行文档搜索，而应该使用句子级别的模型。

4. 嵌入模型架构与选择

模型选择至关重要。

  • 原型设计：all-MiniLM-L6-v2 (轻量级，免费)。
  • 生产环境（API预算）：OpenAI text-embedding-3-small。
  • 最大精度：OpenAI text-embedding-3-large。
  • 隐私/本地部署：Sentence-BERT 或 E5 模型。

向量存储模式:

  • 全文本 + 向量存储:
{
  "id": "chunk_123",
  "vector": [0.12, -0.34, ...],
  "text": "The actual chunk content here...",
  "metadata": {
    "document_id": "doc_456",
    "page_number": 5
  }
}

优点：快速**检索**，无需额外的查找。缺点：更高的存储成本，数据重复。
  • 基于引用的存储:
{
  "id": "chunk_123",
  "vector": [0.12, -0.34, ...],
  "metadata": {
    "document_id": "doc_456",
    "page_number": 5,
    "offset_start": 1240,
    "offset_end": 1680
  }
}

优点：更低的存储成本，单一数据源。缺点：查询时需要额外的查找。

5. 向量数据库：现代RAG的基础

2024年的向量数据库格局：

  • Qdrant：Rust编写，性能卓越，尤其擅长高级过滤。适用于需要复杂元数据过滤的生产应用。支持自托管或云部署。
  • Milvus：高吞吐量，专为大规模AI应用设计。适用于具有海量数据集的大规模分布式系统。支持Kubernetes原生和云平台。
  • Weaviate：云原生，基于GraphQL接口，结合了向量搜索和复杂的数据关系和知识图谱功能。适用于结合向量搜索和结构化数据的应用。支持自托管或托管云。
  • Pinecone：完全托管，生产就绪，提供卓越的开发者体验。适合希望零基础设施管理的团队。仅支持托管云。

对于需要语义和关键词混合搜索的应用，OpenSearch 和 Elasticsearch 提供了原生混合能力。

6. 高级 RAG 架构

  • 传统 RAG vs. 混合 RAG

    • 传统向量 RAG：嵌入文档 -> 存储到向量数据库 -> 嵌入查询 -> 查找相似向量 -> 检索原始文本 -> 传递给 LLM。
    • 混合 RAG (推荐)：索引文本 (BM25) 和向量 (语义) -> 使用关键词和语义搜索进行查询 -> 使用倒数排名融合等技术组合得分 -> 将最佳结果传递给 LLM。

  • 分块策略

    • 固定大小分块：按照固定数量的token进行分割， 例如，chunk_size=300, overlap=50。
    • 语义分块：按照语义边界进行分割，例如，按句子分割，并尽量保证每个chunk的语义完整性。

  • 分层嵌入架构

    对于复杂的文档，可以实施多级嵌入：文档 -> 章节 -> 段落 -> 句子。查询策略是：章节级别搜索 -> 段落级别细化 -> 句子级别精确提取。

  • 基于 Token 的优化技术

    可以存储 token ID 而不是存储完整的文本，用于保护隐私或在空间受限的环境中使用。

7. 生产实施模式

  • 可扩展 RAG 的系统架构

    • 微服务设计
      • 文档处理服务：PDF/文本提取、分块和预处理、元数据提取。
      • 嵌入服务：模型托管（本地或 API）、批量处理能力、缓存。
      • 搜索服务：向量相似度搜索、元数据过滤、结果排序和融合。
      • 响应生成服务：LLM 集成、上下文组装、响应格式化。

  • 成本优化策略

    • 嵌入成本降低
      • 内容去重：在生成嵌入之前，对内容进行去重。可以使用哈希算法来检测重复的 chunk。
      • 嵌入缓存：使用 Redis 等缓存系统来缓存嵌入。可以使用内容哈希作为缓存的 key。

  • 质量保证和监控

    • 检索质量指标：相关性评分（例如，平均倒数排名 MRR）。
    • A/B 测试框架：比较不同的检索策略的效果。

8. 高级优化技术

  • 查询增强策略

    • 查询扩展：添加同义词和相关术语。
    • 假设文档嵌入 (HyDE)：生成假设答案，并嵌入该答案用于搜索。

  • 多向量搜索策略

    • 集成检索：结合语义搜索和关键词搜索的结果。

  • 上下文窗口优化

    • 只选择最相关的 chunk，并保证总长度不超过 LLM 的上下文窗口限制。

9. 部署和扩展注意事项

  • 本地开发设置

    • 可以使用 Docker Compose 快速启动 OpenSearch 等服务。

  • 生产部署模式

    • 可以使用 Kubernetes 部署 RAG 服务，并设置环境变量来配置向量数据库和嵌入模型。

  • 监控和可观察性

    • 使用 Prometheus 等工具来监控 RAG 服务的性能指标，例如搜索请求总数、搜索延迟、活动连接数等。

10. 关键设计决策和架构模式

一个根本性的误解是认为嵌入本身可以为 LLM 提供上下文。这绝对是错误的！

  • 单向性

    嵌入是压缩的有损表示，捕捉语义含义。LLM 是在文本上训练的，而不是在嵌入向量上训练的。没有“反向嵌入”函数可以将向量解码回文本。向量空间针对相似性进行了优化，而不是文本重建。

  • 正确的做法

    1. query_embedding = embed_text("What is photosynthesis?")
    2. similar_chunks = vector_db.search(query_embedding, k=5)
    3. context_text = [chunk.metadata['text'] for chunk in similar_chunks]
    4. response = llm.generate(query="What is photosynthesis?", context=context_text)

高级存储架构模式

  • 基于引用的轻量级存储

    在向量数据库中仅存储最小的信息，例如文档ID、页码、偏移量、文件路径。在检索时，加载原始文件并提取特定的 chunk。

  • 分层多级检索

    构建多级存储结构，例如文档 -> 章节 -> 段落 -> 句子。查询策略是：章节级别搜索 -> 段落级别细化 -> 句子级别精确提取。

回退和弹性模式

  • 多策略检索，具有优雅的降级

    依次尝试不同的策略，例如语义搜索、关键词搜索、模糊搜索。如果某个策略失败，则尝试下一个策略。

通过缓存进行性能优化

  • 内容感知嵌入缓存

    使用 Redis 等缓存系统，并使用内容哈希作为缓存的 key。

11. 最佳实践与常见陷阱

  • 关键 Do’s

    • 始终存储原始文本或可靠的引用。
    • 在索引和查询之间使用一致的分词。
    • 实施适当的分块策略，以保留语义边界（300-512 个 token，50 个 token 重叠）。
    • 使用内容哈希缓存相同内容的嵌入，以降低成本。
    • 在处理复杂文档时，设计用于分层检索。
    • 使用适当的指标和 A/B 测试来监控检索质量。
    • 从一开始就计划使用适当的架构模式进行扩展。
    • 为主要检索方法失败时实施回退策略。

  • 关键 Don’ts

    • 不要尝试将嵌入直接传递给 LLM。
    • 不要忽略分块文档时的 token 限制。
    • 不要为索引和查询使用不同的嵌入模型。
    • 不要忘记向量数据库中的元数据过滤功能。
    • 不要忽略需要精确匹配的应用程序的混合搜索。
    • 不要跳过生产中的监控和可观察性。
    • 不要假设嵌入是可逆的。
    • 不要将所有内容都存储在向量数据库中。

关键架构见解:

  • 嵌入现实检查：嵌入是为相似性而优化的单向转换，而不是重建。
  • 存储策略决策矩阵：全文本存储、基于引用的存储、分层存储。
  • 性能优化优先级：内容去重、嵌入缓存、批量处理、多级检索、优雅降级。

12. 结论

构建生产就绪的 RAG 系统需要仔细考虑多个组件：嵌入模型、分词策略、向量数据库、分块方法和部署架构。 随着新的模型和数据库的不断涌现，技术格局也在迅速发展。 成功的关键在于理解您的具体用例需求：

  • 准确性 vs. 速度：相应地选择嵌入模型和数据库。
  • 规模 vs. 简单性：平衡功能丰富性和运营复杂性。
  • 成本 vs. 性能：根据您的预算和延迟要求进行优化。

随着该领域的不断发展，在保持分词、嵌入和检索策略等扎实基础的同时，不断尝试新的方法。 对理解这些核心概念的投资将为你在新技术出现时提供良好的服务。

By llmtrend

Related Post

RAG

突破炒作迷雾：利用RAG、MongoDB Atlas与Google Cloud构建真实世界的上下文感知AI

llmtrend
RAG

解锁高级 RAG 的力量：构建下一代 RAG 系统的实战指南

llmtrend
RAG

零代码构建RAG聊天机器人：BladePipe + OpenAI实战指南

llmtrend

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

You Missed

LLM

pydiode：揭秘 ChatGPT Python Canvas 的运行时真相

LLM

大语言模型 (LLM)：聊天机器人背后的智能大脑，理解 Tokens、Transformers 以及 ChatGPT 的工作原理

LLM

大模型时代的“天鹅绒牢笼”：重塑智识主权宣言

LLM

利用生成式AI（GenAI）进行数据增强与合成：提升模型性能的实战指南