不用 LangChain 的 RAG：无需 Python 框架构建生产级检索管道

每当有人在 Reddit、Stack Overflow 或任何 AI Discord 上问"我该怎么构建 RAG"时，LangChain 已经成为了默认推荐。这是有道理的：在 2023-2024 年间，它让人们从零到一个可工作的原型比其他任何工具都快。你可以用五十行 Python 代码连接一个向量数据库、一个嵌入模型和一个聊天补全端点。

但越来越多的生产团队正在悄悄地将其移除。不是因为 LangChain 不好——它确实帮助引导了 RAG 生态系统。他们移除它是因为那些让 LangChain 在原型阶段表现出色的特性在生产规模下变成了负担。

如果你正在评估如何在不使用 LangChain 的情况下构建 RAG 管道，或者在考虑是否应该迁移，这是一篇诚实的分析：到底有什么问题、有哪些替代方案，以及什么时候 LangChain 仍然是正确的选择。

抽象税

每个框架都有代价。你用控制权换取便利性。当抽象是稳定的、文档齐全的，并且能清晰地映射到你对底层系统的心智模型时，这种权衡是值得的。

LangChain 的抽象在生产环境中的这三个方面都表现不佳。

版本变动。 LangChain 的 API 接口在各版本之间变化剧烈。基于 langchain==0.0.x 构建的团队发现他们的代码被 0.1.x 破坏，然后又被 langchain-core / langchain-community 的拆分再次破坏。在原型环境中，你固定一个版本就继续前进。在有 CI/CD 管道、依赖审计和安全审查的生产系统中，每次破坏性变更都要消耗工程时间。

调试黑盒。 当 RAG 管道返回一个不好的答案时，你需要检查每个阶段：查询转换、嵌入、检索步骤、重排序和提示词组装。LangChain 将每一个都包裹在层层抽象中——链、可运行对象、回调——这使得很难看到每个步骤实际发生了什么。团队报告说花在调试框架上的时间比调试管道逻辑的时间还多。

简单管道的过度工程化。 大多数生产 RAG 系统遵循一个简单直接的模式：嵌入查询、搜索向量存储、将上下文组装到提示词中、调用模型。这大概是 100 行直接代码。LangChain 为本质上是线性数据流的东西引入了链、代理、输出解析器、检索器和记忆对象等概念。认知开销是真实的，特别是在让新工程师熟悉代码库时。

供应商耦合。 LangChain 通过其集成层支持数十个 LLM 提供商、向量存储和嵌入模型。但这个集成层意味着你依赖 LangChain 来维护每个供应商的包装器。当供应商更新他们的 SDK 时，你要等 LangChain 跟上。当你想使用供应商特定的功能时，你要与抽象作斗争才能访问它。

这些都不意味着 LangChain 是一个糟糕的项目。它意味着这个框架是为广度和入门速度优化的，而不是为生产中重要的运营关注点优化的：可调试性、稳定性和透明性。

替代方案 1：直接 SDK 调用

团队离开 LangChain 时最常走的路是最简单的：完全放弃框架，直接调用供应商的 SDK。

使用直接调用构建的生产 RAG 管道通常是这样的：

1. 嵌入查询，使用你的嵌入供应商的 SDK（OpenAI、Cohere 或通过 sentence-transformers 使用本地模型）
2. 搜索向量存储，使用存储的原生客户端（Pinecone、Weaviate、Qdrant、pgvector）
3. 可选地重排序检索到的分块，使用交叉编码器或重排序 API
4. 组装提示词，将检索到的上下文插入你的提示词模板
5. 调用 LLM，使用供应商的 SDK 和你组装好的提示词

每个步骤都是一个函数调用。每个函数调用返回你可以独立记录、检查和测试的数据。没有框架状态需要管理，没有回调系统需要配置，你和实际操作之间没有链式抽象。

适用场景： 拥有强大 Python/TypeScript 工程能力的团队，定义明确且不会频繁改变形态的管道，以及在每个步骤都需要完全可观测性的需求。当你想要除已有服务之外零外部依赖时，这是 LangChain 最佳的本地替代方案。

代价： 你要写更多代码。你要构建自己的重试逻辑、自己的批处理、自己的提示词管理。对于单个管道来说这很简单。对于多个团队的十个管道，你最终会构建一个内部库——实际上就是你自己的迷你框架。

替代方案 2：LlamaIndex

LlamaIndex（前身为 GPT Index）占据了一个中间地带。它仍然是一个框架，但专门为检索和索引设计，而不是通用的 LLM 编排。

哲学上的关键区别：LangChain 试图抽象整个 LLM 应用栈（代理、工具、记忆、链）。LlamaIndex 专注于数据索引和检索问题——如何为模型获取正确的上下文。

在实践中，这意味着 LlamaIndex 的抽象与 RAG 管道实际做的事情更紧密地对应。它的核心概念——节点、索引、查询引擎和检索器——直接对应检索管道中的各个阶段。你花更少的时间与框架作斗争，因为框架的心智模型与问题匹配。

LlamaIndex 在 API 变更方面也更为保守，尽管它也经历了自己的重构（llama-index-core 的拆分与 LangChain 的模块化如出一辙）。

适用场景： 想要框架便利性——预构建集成、合理的默认值、文档解析工具——但不想要 LangChain 庞大抽象表面的团队。如果你的管道涉及复杂的文档处理（层次化分块、多文档合成、从 PDF 中提取结构化数据），LlamaIndex 特别强大。

代价： 你仍然在框架中。你仍然依赖维护者来保持集成的更新。但表面积更小，所以依赖风险更低。

替代方案 3：可视化管道构建器

第三类方案已经出现，面向那些想要在不使用 LangChain 且完全不编写管道编排代码的情况下构建 RAG 管道的团队：可视化管道构建器和低代码平台。

Flowise、Langflow、Haystack Studio 等工具以及专用企业平台让你通过在可视化图中连接节点来组装检索管道。每个节点代表一个步骤——嵌入、检索、重排序、生成——平台处理执行、监控和部署。

其中一些工具在底层使用 LangChain 或 LlamaIndex，但将你与框架的复杂性隔离开来。其他工具则基于自己的执行引擎构建。

适用场景： 构建 RAG 管道的人是领域专家（数据分析师、产品经理、解决方案工程师）而非后端工程师的团队。也适用于快速实验——你可以在一个下午通过交换节点尝试二十种不同的分块策略。

代价： 你用代码级别的控制换取了易用性。超出平台支持范围的自定义需要变通方法或插件。当你无法看到或修改底层代码时，性能调优更困难。而且你在基础设施之上增加了一个平台依赖。

什么时候 LangChain 仍然是正确的选择

写一篇关于不用 LangChain 的 RAG 的文章而不承认 LangChain 真正闪光的地方，那是不诚实的。

学习和原型化。 如果你是 RAG 新手并想了解各个组成部分，LangChain 的教程和社区资源是无与伦比的。你用 LangChain 获得可工作原型的速度比任何其他方法都快。在生产中成为负担的抽象在你学习时是资产——它们让你专注于概念而不被实现细节淹没。

快速实验。 当你需要在一周内测试十几种不同的检索器策略、模型提供商和提示词模式时，LangChain 的即插即用集成节省了真正的时间。当你在探索、尚未确定特定架构时，框架的广度是一个优势。

以代理为中心的架构。 如果你的系统确实需要代理行为——工具使用、多步推理、动态路由——LangChain 的代理抽象（特别是通过 LangGraph）是目前最成熟的。当你在构建自主代理时，直接 SDK 调用会很快变得复杂。

需求广泛的小团队。 一个三人创业团队构建一个 AI 功能不需要定制的管道架构。LangChain 让他们更快地进入市场，而其抽象的运营成本在他们达到一定规模之前不会显现——而达到那个规模本身就是一个好问题。

决策框架

以下是一种简单的思考方式，帮助你判断哪种方法适合你的情况：

诚实的答案是，没有普遍最佳的方法。不使用 Python 框架构建生产检索管道的团队往往会在核心管道上收敛于直接 SDK 调用，并保留一个框架用于实验。需要快速行动且尚未担心运营成熟度的团队可以很好地使用 LangChain。

重要的是根据团队的具体约束有意识地做出选择——而不是因为"每个人都在用 LangChain"或因为"框架不好"。这两种说法在任何真正的工程决策面前都站不住脚。

Ertas 的定位

Ertas 专为那些已经决定要掌控自己 AI 基础设施的团队设计。无论你是直接调用供应商 SDK、使用 LlamaIndex，还是从 LangChain 迁移，Ertas 处理底层的运营层：模型部署、数据管道管理和治理控制。

你按自己的方式构建 RAG 管道。Ertas 确保它可靠运行、保持合规，并在不需要重新架构的情况下扩展。不强加框架意见——只是不妨碍你的基础设施。