拆解 RAG：从僵化协议到灵活抽象

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。

作者注

我最初在2025年9月写下这篇文章，正值 GraphRAG 等架构即将巩固之际。它被保存在一个“数字抽屉”里，但今天重新审视时，我惊讶地发现其中的架构诊断仍然适用。我决定将其发布，保持原文不变以保留分析的上下文，只在末尾添加一段简短的说明，阐述过去几个月RAG生态系统的演变。

---

这个定义既广泛又强大。它并未规定检索应当如何进行。然而，在实践中，生态系统已经大规模地趋向于一种非常具体的实现：在非结构化文本数据库上进行 向量相似度搜索。这项技术如此主导，以至于它不仅开始塑造我们对RAG的认知，也影响了我们围绕它构建的工具和协议。而正是在这里，作为架构师，我们必须停下来分析其后果。

当 API 反映机制而非意图

当客户端应用需要与外部服务形式的 retriever 交互时，它会通过 API 完成。虽然没有正式的标准，但事实上的模式已经相当明确，且在向量数据库（如 Pinecone、Weaviate 或 Chroma）兴起的推动下得到广泛推广：

• APIs RESTful 基于 HTTP/S（使用 JSON）
• gRPC 以获得更高性能

正如往常一样，细节决定成败。一次典型的向量 retriever 服务调用大致如下：

{
  "vector": [0.12, 0.54, ..., -0.08],
  "topK": 5,
  "metric_type": "cosine"
}

观察这套 API 的语言。它的“动词”和“名词”是 vector、topK（最近的 K 个邻居）以及 metric_type。这是一种本质上 几何 与 统计 的语言。该 API 并非为“检索信息”而设计，而是为“在 N 维空间中找到离某一点最近的邻居”而设计。

深层含义： 任何针对该 API 编写的客户端都会被强耦合——不是与抽象的 RAG 概念耦合，而是与其某一种具体实现耦合。传输层把我们锁定在单一范式中。
如果我们的 “retriever” 并不使用向量会怎样？
如果它是一个 SQL 数据库呢？
或者是气象 API？
又或者是逻辑知识图谱？

当前的 API 并没有能够表达这些问题的词汇。

Source: …

将功能提升到应用层

这种应用层与底层“引擎”之间的耦合问题在我们的行业并不新鲜。我们在几十年前就已经在数据库领域经历过，当时每个厂商都有自己的协议。解决方案是创建一个应用层的抽象层：ODBC 和 JDBC。

今天我们在 RAG 生态系统中看到的正是同样的解决方案，由 LangChain 等库主导。它们不是强迫开发者去对一个僵硬的传输 API 编码，而是提供了一个更高层次的契约。

LangChain 的 BaseRetriever 接口

在 LangChain 中，这就是 BaseRetriever 接口。它的主要方法简洁得让人惊叹：

get_relevant_documents(query: str) -> List[Document]

对该契约的分析

一个针对该接口编程的客户端不再需要，也不关心底层实现细节。BaseRetriever 可以是：

• PineconeRetriever – 在内部将 query 转换为向量并执行我们之前看到的 HTTP 调用。
• SQLRetriever – 将自然语言问题翻译为结构化的 SQL 查询，可能通过语言模型或规则集实现。
• 任何其他我们能想到的检索器。

这种灵活性不仅是理论上的练习；它是打开那些单纯向量相似度搜索无法解决的问题的大门。

用例：需要空间逻辑的领域

让我们暂时考虑一个领域，其中“真相”不是类似的文本，而是一个逻辑和空间结构：一个地理信息系统（GIS）。

查询示例：
“哪些农作物地块位于距离过去两年内经历干旱的水道不到500米的范围内？”

传统向量检索器会怎样？

它会搜索包含 parcela（地块）、cauce（水道）、sequía（干旱）和 500 metros（500米）这些词的文档。结果会是一系列文本（技术报告、新闻等），但永远不会得到直接且精确的答案。

假设的 GeoRetriever 如何工作？

1. 理解问题

   • 大语言模型（LLM）与检索器协作，将查询拆解为空间和时间组件：
     • tipo: parcela（类型：地块）
     • relación: distancia < 500 m（关系：距离 < 500 米）
     • condición: sequía en los últimos 2 años（条件：过去两年内的干旱）

2. 执行空间逻辑

   • 查询空间数据库（例如 PostGIS），获取满足距离条件和时间限制的地块。

3. 构建答案

   • 将结果格式化后返回给用户，形式可以是结构化列表或交互式地图。

注意： 构建这样的 GeoRetriever 是一项巨大的工程挑战，涉及多个学科。我并不是把它当作一个简单的解决方案，而是作为我们正在忽视的潜力的示例。

为什么我们需要灵活的架构

灵活的架构使我们能够：

• 想象并最终构建今天看似难以解决的问题的解决方案。
• 逐步前进，而不必在每次出现比简单向量搜索更强大的知识引擎时，拆除并重建应用程序。

这种在占主导但受限的解决方案与对更大灵活性的需求之间的张力，在我们的领域并不是新现象；它是技术生态系统演进中的重复出现的模式。

历史类比：数据库

多年来，每个厂商都强加自己的通信协议，把开发者锁定在专有生态系统中。创新受到阻碍，直到出现了像 ODBC 和 JDBC 这样的抽象层，才使应用摆脱实现细节的束缚，让生态系统得以繁荣。

我们在 RAG 上所看到的正是这一循环的重演：

• 生态系统已经迅速收敛到一种高效的实现（向量搜索），但它是 耦合的。
• 解决方案不是抛弃该实现，而是 在其之上构建抽象层，让我们重新获得创新的自由。

这些抽象层不仅是技术便利；它们是任何技术长期健康的 根本机制。

开发者的沮丧

“当前的 API 很高效，但它是一扇狭窄的门，只允许一种类型的问题通过。”

作为开发者，我深感沮丧，因为限制我的不是技术本身，而是我们被提供的 “入口门”。

更灵活的 API

我们的目标应该是设计 表达用户意图的 API，而不是内部机制。不要使用这样提问的 API：

“这个向量的 K 最近邻是什么？”

我们应该追求这样提问的 API：

“使用 此策略 检索与此查询相关的信息。”

可行的策略

机制的决定应尽可能由 服务器端 决定，从而在基础设施演进时保持应用层的稳定。

为什么重要

• 过于具体关注 “如何” 的 API 会在出现更好的 “如何” 时迅速变得过时。
• 专注于 “什么” 的 API 能持久存在，因为它们让创新在表层之下蓬勃发展，而无需上层世界进行变更。

构建门，而不仅是走廊

RAG范式远不止相似度检索。它承诺让 AI 动态查询任何知识来源，以支撑其回答。

如今主流的 API 是一条狭窄的走廊，只能通向一个目的地：向量检索。

解决方案不是放弃这条走廊，而是构建一个拥有多扇门的前厅。像 LangChain 这样的抽象是第一步：它们将应用与检索机制解耦，并为连接未来的知识引擎提供一个标准的“插口”。

下一个重大突破

下一个在 RAG 领域的重大突破不会是一个向量算法快 1 % 的改进。它将是一种全新的 Retriever 类别，此前没人想到将其连接起来。只有在我们构建了允许它的架构后，才能使用它。

思考： 我们构建的工具最终决定了我们能解决的问题。如果我们只有用于向量搜索的 API，我们只能解决统计相似性的问题，而无法解决需要结构化推理的问题。

结论

作为架构师，我们的工作不仅是优化已知的路径，还要确保我们拥有探索尚未存在的路径的自由。

---

注

当我几个月前开始撰写本文时，向量检索仍然是 RAG 中的主导范式。此后，生态系统迅速发展：

• GraphRAG（微软）以及其更高效的变体 LazyGraphRAG
• LinearRAG
• LightRAG

这些项目展示了我在此所倡导的趋势：我们正从严格的向量 RAG 转向融合知识图谱、结构化推理和混合检索机制的方法。

这些进展并未否定对向量数据库几何 API 的批评；相反，它们强化了该批评。只有借助诸如 LangChain 或类似的抽象层，我们才能充分利用这些新可能。

Source: …

LlamaIndex：在不重写应用的情况下集成新的 retrievers

我们曾想象的未来已经到来。

对于想深入了解 RAG 系统的技术和架构基础，并探索主流实现之外内容的读者，这里精选了一些关键资源。

📚 原始基础

• “Retrieval‑Augmented Generation for Knowledge‑Intensive NLP Tasks”
  Patrick Lewis 等 (2020)

  这篇论文首次提出了 RAG 缩写。阅读它对于理解框架的原始愿景至关重要——该愿景有意更宽泛且对检索机制保持中立，而许多当前实现则并非如此。

🔧 主流生态系统（向量检索）

• 向量数据库文档

  • Pinecone
  • Weaviate
  • Chroma

  除了教程之外，这些文档的概念与架构章节详细解释了我们在文章中分析的 API 背后的“为什么”。它们是了解已形成事实标准协议的最佳来源。

• “Vector Search for Practical Machine Learning”
  A. Aji 等

  综述文章，提供了对实现大规模相似度搜索的算法和数据结构（如 HNSW）的扎实技术视角。

🧩 抽象层与未来

• LangChain 与 LlamaIndex 关于 “Retrievers” 的文档

  • 分析 LangChain 中的 BaseRetriever 接口。
  • 探索 LlamaIndex 中的 QueryEngine 与 Retriever 概念。

  这是最直接观察我们所提出抽象层在实践中如何运作的方式。对于希望构建灵活、解耦的 RAG 系统的开发者而言，这些文档是必备的。

• “Seven Failure Points When Engineering a Retrieval Augmented Generation System”
  Scott Barnett 等 (2024)

  实用文章，描述了设计稳健 RAG 流水线时常见的风险点以及相应的缓解措施。