LangChain 中的 RAG 链路

LangChain 做 RAG 的价值，不是让 RAG 变神奇，而是把加载文档、切片、检索、Prompt 和模型调用这些重复连接工作组织起来。

真正要关注的是：框架帮我们省掉了什么，哪些工程边界仍然要自己负责。

一条典型链路

LangChain 里的 RAG 通常会经过：

• Document Loader 读取内容。
• Text Splitter 切分文本。
• Embedding 写入向量库。
• Retriever 召回相关片段。
• Prompt 组织上下文。
• ChatModel 生成回答。

这些抽象适合学习链路，也适合快速搭建原型。

仍然要自己管的部分

LangChain 不会自动解决：

• 文档版本一致性。
• 权限过滤。
• 引用展示。
• 调用成本。
• 线上评估。

如果这些边界不补，RAG 原型跑起来也不等于能上线。

什么时候直接写更清楚

如果链路很短，团队也只接一个模型和一个向量库，直接用 SDK 写可能更清楚。等重复逻辑多了，再引入 LangChain 更自然。

框架应该减少复杂度，而不是提前制造抽象。

一句话先记住

LangChain 能帮我们组织 RAG 链路，但不能替我们设计 RAG 系统。

继续阅读

• 04-rag/002-rag-architecture.md
• 07-langchain-langgraph/007-framework-boundary.md