2026年8月17日1. 今天学了什么今天主要解决了一个看起来基础、但在真正做 RAG 项目时很容易混淆的问题LangChain 和 RAG 到底是什么关系LangChain 是不是 RAG 的一部分我之前容易把它们放在同一个层级理解好像RAG └── LangChain或者反过来LangChain └── RAG但这两个理解都不准确。更准确的关系是LangChain Framework开发 / 编排框架 RAG Architecture / Pattern应用架构 / 技术模式也就是说RAG 描述“这个系统要怎么利用外部知识回答问题”LangChain 描述“工程上如何把这些组件组织和调用起来”。这是今天最值得留下的认知。2. LangChain 不是 RAG 的子集RAG 也不是 LangChain 的子集这是今天最重要的纠错。我原来容易理解成因为很多 RAG 教程都是用 LangChain 写的所以很容易形成RAG LangChain甚至LangChain 是专门做 RAG 的框架实际上都不对。RAG 是什么RAG全称Retrieval-Augmented Generation检索增强生成核心思想是User Query ↓ Retrieval ↓ 找到外部知识 ↓ Context ↓ LLM ↓ Answer也就是模型在回答之前先从外部知识源中检索相关内容再把这些内容作为 Context上下文交给模型。因此RAG 描述的是一种LLM Application Architecture大模型应用架构它关心的是知识从哪里来 怎么检索 检索结果怎么交给模型 模型怎么基于这些内容生成答案LangChain 是什么LangChain 更准确的定位是LLM Application Orchestration Framework大模型应用编排框架它提供大量抽象和统一接口用来组织Document Loader Text Splitter Embedding Model Vector Store Retriever Prompt LLM Output Parser Tool Agent ...所以 LangChain 本身不是一种 RAG 算法也不是一个 Vector Database。它更像是把不同组件连接起来的一层工程框架。3. 一个类比让我彻底分清两者可以把它们类比成 Web 开发。假设我要开发一个“商品搜索系统”。那么搜索系统 我要实现的业务架构 / 功能而Django / Spring 帮助我开发这个系统的框架不能说Django 搜索系统也不能说搜索系统必须使用 Django同样RAG 我要实现的 AI 系统模式而LangChain 帮助我组织 RAG 各个组件的框架所以可以用 LangChain 实现 RAG但实现 RAG 并不必须使用 LangChain。反过来也一样LangChain 也不仅能做 RAG它还可以组织 Tool Calling、Agent、Workflow 等其他 LLM 应用。这两个判断基本就把它们的边界划清楚了。4. LangChain 在 RAG 流程中到底出现在哪里如果把一个典型 RAG 系统展开Raw Documents ↓ Document Loader ↓ Chunking ↓ Embedding ↓ Vector Store ↓ Retriever ↓ User Query ↓ Relevant Documents ↓ Prompt / Context ↓ LLM ↓ AnswerLangChain 并不是这里面的某一个步骤。更准确地说它可以对这些步骤提供抽象并把它们串起来。例如RAG Architecture Document ↓ Loader ← LangChain 可以提供接口 ↓ Splitter ← LangChain 可以提供接口 ↓ Embedding ← LangChain 可以封装不同模型 ↓ Vector Store ← LangChain 可以连接向量数据库 ↓ Retriever ← LangChain 提供统一 Retriever 抽象 ↓ Prompt ← LangChain Prompt abstraction ↓ LLM ← LangChain Model abstraction因此不能说LangChain 负责“做检索”。因为真正执行向量搜索的可能是FAISS Qdrant Milvus Weaviate Chroma也不能说LangChain 就是 Embedding。Embedding 可能来自完全不同的模型。LangChain更接近Application ↓ LangChain ↓ ┌───────────────┐ Embedding Model Vector Store Retriever LLM Tools ... └───────────────┘这也让我开始理解所谓Orchestration编排到底是什么意思它不是代替所有底层组件而是负责让不同组件按照统一接口协同工作。5. 一个很重要的工程认知框架不等于底层能力这个问题其实不只适用于 LangChain。以前看到retriever.invoke(query)很容易觉得LangChain 完成了检索。但如果继续往下一层拆LangChain Retriever ↓ Vector Store Adapter ↓ Vector Database / Index ↓ Similarity Search真正执行搜索的可能是向量数据库或向量索引。类似地LangChain ChatModel ↓ Model API ↓ 真正的 LLM所以以后看任何 AI Framework都要问三个问题它自己真正实现了什么 它只是提供了什么抽象 真正执行计算的是谁这其实是理解 LangChain、LangGraph、Ollama、Vector Database 等技术时非常通用的一种方法。6. 今天踩的坑不要按照“谁包含谁”理解 LangChain 和 RAG我原来以为可能存在这样的层级AI └── RAG └── LangChain实际上两者属于不同分类维度RAG ↓ Architecture / Pattern LangChain ↓ Framework所以它们并不存在严格的包含关系。更合理的表达是RAG Application │ ┌──────────┼──────────┐ ↓ ↓ ↓ Retriever Prompt LLM ↑ ↑ ↑ └──────────┼──────────┘ │ LangChain 可以参与编排这些组件这也是今天最重要的一次概念纠偏。7. 和真实 RAG 项目的关系这个区别在真实项目里非常重要。如果面试官问你的 RAG 项目为什么用了 LangChain不能回答因为 RAG 就是用 LangChain 做的。这个回答暴露的是概念边界不清楚。更合理的回答是RAG 是系统采用的检索增强生成架构而 LangChain 是工程实现中的编排层。我可以用它统一 Document、Embedding、Vector Store、Retriever、Prompt 和 LLM 等组件的接口从而减少不同基础设施之间的适配成本但检索算法、向量数据库和模型本身并不是 LangChain。如果项目不复杂甚至完全可以不用 LangChainquery 什么是 RAG docs vector_db.search(query) context \n.join(docs) prompt f 请根据下面资料回答问题 {context} 问题 {query} answer llm(prompt)这段代码已经具备 RAG 的核心结构Query ↓ Retrieval ↓ Context ↓ LLM ↓ Answer虽然这里没有from langchain ...但它仍然是 RAG。这个例子反过来验证了RAG 的成立取决于系统架构而不是有没有导入 LangChain。8. 今天形成的新理解今天真正学会的并不是一句LangChain 可以做 RAG而是建立了一种更准确的技术分层意识。以后看到一个 AI 技术我需要先判断它属于哪一层LLM → Model RAG → Architecture / Pattern LangChain → Application Framework Vector Database → Retrieval Infrastructure只有先把层级分清楚才能继续判断谁负责数据 谁负责检索 谁负责生成 谁负责连接组件否则项目代码虽然能跑技术理解却很容易停留在框架 API 层。今天留下的问题1. LangChain 的 Retriever 到底只是接口抽象还是会真正参与 Retrieval Algorithm检索算法的实现2. 如果不用 LangChain手写一个完整 RAG Pipeline需要自己负责哪些组件之间的适配3. 当 RAG 从简单的 Vector Search 发展到 Hybrid Retrieval、Reranker 等复杂流程后LangChain 的编排价值会体现在哪里今天最值得记住的一句话是RAG 决定系统“怎么利用外部知识回答问题”LangChain解决的是“工程上如何把实现这个系统所需的组件组织起来”。两者不是包含关系而是 Architecture 与 Framework 的关系。