LangChain 社区聚焦：基于 LangChain 的企业级 RAG 🔎📚

Soba Labs 的 Kacper Klusek 展示了如何在 LangChain 上构建企业级 RAG——先修复检索，再动模型。在 Anthropic 公开的评估中，他推荐的检索链（上下文化嵌入 + BM25 + 重排序器）将检索失败率降低了 67%。随后，LangSmith 的在线评估能捕捉文档变更后开始出现的效果衰减。

📖 阅读完整指南：https://sobalabs.ai/blog/enterprise-rag-on-langchain/…

基于 LangChain 的企业级 RAG：先修复检索 | Soba Labs

来源：https://sobalabs.ai/blog/enterprise-rag-on-langchain/

标题卡片写着 “Enterprise RAG: fix retrieval first”，左上角是 LangChain 标志，深蓝色背景上是一个金色轮廓的检索流水线：一个文档窗口拆分为多个文本块行，与关键词行融合后通过一个重排序漏斗，排名第一的行发出金色光芒。

你的企业级 RAG 系统不会在你注视的地方失败。模型会为错误答案背锅，但杠杆率最高的修复环节其实在更早的一步——那些检索从未返回的文本块中。

先修复检索：上下文分块、混合搜索和重排序器在 Anthropic 公开评估中将检索失败率降低了 67%，比任何模型升级带来的收益都大。

LangChain 提供了这套技术栈的每个组件，而 LangSmith 通过评估器闭环，能捕捉到 demo 永远暴露不出来的效果衰减。本文按照数据建议的构建顺序来讲解这套技术栈：架构、分块、混合检索、重排序，然后是保持系统诚实的评估闭环。

检索在模型之前就失败了

支持 RAG 的理由没有变：模型具有 LangChain 检索文档所称的有限上下文和静态知识，因此系统在查询时获取相关外部知识。变化的是生产团队在哪里失利。当 RAG 给出错误答案时，先看检索结果再怪模型：在我们的评审中，包含答案的段落要么被切分不当、要么脱离上下文被嵌入、要么被近似重复内容排挤、要么根本没有被索引——而模型忠实地总结了错误的上下文。以上每一种都是检索缺陷，每一种都有明确的修复方案，成本远低于升级前沿模型。

这种优先级排序才是实际要点。团队调提示词、换模型，是因为这些改动一个下午就能完成，而检索栈看起来像管道工程。管道就是产品。在生产级 RAG 中，生成模型很少是瓶颈；你交给它的文本块才是。

按控制权归属选择架构

当前 LangChain 文档将 RAG 组织为三种架构，选择的关键在于控制权。在两步式 RAG 中，检索总是在生成之前执行，因此延迟可预测，LLM 调用次数有上限。在 Agentic RAG 中，Agent 在推理过程中自行决定何时检索以及如何检索；文档指出，Agent 只要能访问获取外部知识的工具，就具备 RAG 行为。混合设计介于两者之间，将检索包裹在验证步骤中：查询增强、检索验证（当文档返回内容不足时可重新检索）、以及基于来源的答案验证。

除非你能明确指出它在哪类问题上失败，否则从两步式开始。我们在 LangGraph 生产环境中的 Agent 中提出了同样的观点：给模型能回答问题的最小循环，因为你赋予的每一度自由度，都是你必须评估的一种失败模式。

分块是检索决策，不是预处理

分块看似预处理，实则影响排序：你切出的边界就是唯一存在的检索单元。Splitter 文档对默认值的说明异常直白：“对于大多数用例，从 RecursiveCharacterTextSplitter 开始。它在保持上下文完整和管理块大小之间提供了稳健的平衡。” 它会尽可能保持段落完整，仅当某个单元超出块大小时才下降到句子和词级别；对于 HTML、Markdown 或 JSON，基于结构的 splitter 会遵循文档自身的边界。LangChain 的知识库教程给出了实用的默认值：

from langchain_text_splitters import (
    RecursiveCharacterTextSplitter,
)

splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200,
    add_start_index=True,
)
chunks = splitter.split_documents(pages)
# 教程中那个 107 页的 PDF 被切成 516 个块

add_start_index=True 保留了每个块的字符偏移量，第一次有用户问答案来自哪里时你就会需要它。更深层的问题在于，从文档中切出的块会丢失其指代关系，而这正是上下文检索要修复的：Anthropic 的公开方法在嵌入之前为每个块前置一段简短的生成上下文，仅上下文嵌入一项就将 top-20 检索失败率从 5.7% 降低到 3.7%，降幅 35%，一次性成本为每百万文档 token 1.02 美元。同一篇文章还给出了在动手构建之前值得确认的退路：“如果你的知识库小于 200,000 token（大约 500 页材料），你可以直接把整个知识库放进给模型的提示词中，无需使用 RAG 或类似方法。”

混合搜索赢得嵌入模型漏掉的查询

在向量数据库上进行的稠密语义搜索匹配含义，但对精确字符串无能为力——当用户第一次搜索错误代码、零件编号或条款引用时，这就是问题。修复方案是一项刻意保留的老技术：将稠密索引与 BM25 配对，即在精确标识符上仍然胜出的稀疏检索算法，然后融合结果集。Weaviate 的混合搜索文档直白地描述了这一模式：“混合搜索通过融合向量搜索和关键词（BM25F）搜索的结果来组合两者。融合方法和相对权重均可配置。” 其 alpha 权重从 0（纯关键词）到 1（纯向量），自 v1.24 起相对分数融合（Relative Score Fusion）成为默认融合方法，因此混合搜索已变成一个配置决策。

Anthropic 上述评估测量的正是同样的组合：在上下文嵌入的基础上加入上下文 BM25，失败率从 3.7% 降至 2.9%，相比 5.7% 的基线总降幅达到 49%。不过要诚实评估其适用范围：BM25 在充满标识符和术语的语料库中才能发挥价值，而在日期、产品或租户等字段上使用元数据过滤往往能比任何一种索引更低成本地缩小候选集。

重排序是剩下的最便宜的精度提升

第一阶段检索——无论是稠密还是混合——都是为在大规模语料库上提升召回率而设计的。重排序器是一个第二阶段模型，它根据与查询的实际相关性对小型候选集重新排序。由于它同时读取查询和文档，因此能捕捉到双编码器嵌入在结构上无法捕捉的东西。Cohere 的 Rerank 文档简洁地描述了该端点：给定一个查询和一组文档，它按语义相关性从高到低排序，当前模型阵容已发展到 Rerank 5。收益是公开且具体的：Cohere 的 Rerank 3.5 发布公告在金融服务业数据集上测得其表现比混合搜索高 +23.4%、比 BM25 高 +30.8%；Anthropic 的流水线检索 top 150 候选，经重排序后取 top 20，将失败率阶梯终结在 1.9%，即引言中承诺的 67% 降幅。

以 top-20 失败率基线 5.7% 为起点的三个检索阶段对比：上下文嵌入达到 3.7%，加入上下文 BM25 达到 2.9%，加入重排序器达到 1.9%。

Anthropic 公开的失败率阶梯：每个阶段都带来改善，重排序器将其终结在 1.9%。

成本是每次查询多一次模型调用（处理几十个候选），再加上应在投入前先测量的延迟。如果你的错误预算本季度恰好允许做一项检索升级，这就是那个背后有公开数据支撑的选择。

评估闭环才能捕捉无声衰减

一个 RAG 系统通过了上线评审，然后语料库变了：文档被改写、产品被重命名、昨天的先例与今天的政策相矛盾。

RAG 系统通过数据而非代码衰减，因此任何部署时测试都无法捕捉到它的衰减。

LangSmith 的 RAG 评估教程将质量拆分为四项比较，而不是一个分数：正确性（回答 vs 参考答案）、相关性（回答 vs 输入）、有据性（回答 vs 检索到的文档）、检索相关性（检索到的文档 vs 输入）。这种拆分使闭环具有诊断能力。有据但不相关的回答是检索问题；相关但无据的回答则是模型自由发挥——这正是我们在你的 Agent 摘要不是来源中拆解过的失败模式。

离线数据集只能覆盖你想到要测试的内容。生产环境需要在线评估：LangSmith 的在线评估针对实时 trace 运行 LLM-as-a-judge 评估器，“以识别问题、衡量改进并确保长期稳定的质量”，并设有用于成本控制的采样率——0.1 即评估十分之一的 trace。LangChain 的 2026 年 1 月通讯阐述了我们会着重标记两次的运营原则：“生产环境的 trace 成为活的测试用例，决定你接下来评估什么。” 将有据性和检索相关性接为在线评估器，无声衰减就不再是无声的。评估器校准本身是一门独立的学问，我们在 LangSmith LLM-as-judge 中做过探讨。

Agentic RAG 构建上线前我们检查什么

我们在任何 Agentic RAG 评估关卡前执行的检查清单，来自我们对一个知识捕获系统所做的生产架构评审——该系统检索规则和历史人工判断，并将每一次修正回写为未来的先例。其中三项检查可迁移至几乎所有企业级 RAG 构建，它们也是我们承接的 LangChain 实施工作的一部分。

**陷阱：**写入库中的一次修正，并不等于系统将来一定会检索到它。它能否再次出现取决于相关性阈值和 top-N，因此一个优秀的修复可能被保存却永远不再出现，也没有任何失败的测试来暴露它。

第一，写读往返测试：人工修正写回后，运行一个近似相同的输入，断言新的先例确实出现在检索结果中。第二，当数据变化时重新运行黄金集回归测试，而不只是在代码部署时——语料库更新时检索会无声地破坏，而那时恰好没有人在关注 CI。第三，从第一天起在每条记录上记录嵌入模型版本，因为模型会被弃用、跨嵌入版本的相似度毫无意义，而对数千条记录重新嵌入是一次你希望提前规划而非事后才发现的迁移。这些都不需要新工具；三者都是你现有测试框架可以承载的断言。

总结

基于 LangChain 的企业级 RAG 胜负在检索栈。选择能回答你问题类别的最小架构，采用文档中的分块默认值并为块添加上下文，将 BM25 与你的向量索引融合，把唯一一次升级机会花在重排序器上：这条链路在 Anthropic 公开评估中经过端到端测量，在生成模型看到第一个 token 之前就消除了三分之二的检索失败。然后将评估视为系统的生产侧一半，配备有据性和检索相关性的在线评估器、每条写入路径的往返测试、以及在数据变化时触发的回归测试。模型会自己不断进步。检索栈才是你系统中只有因为你这样构建才会变好的部分——这与我们在 MCP 现已内建于 LangChain 中剖析的是同一个赌注。

来源

• Retrieval，LangChain 文档（https://docs.langchain.com/oss/python/langchain/retrieval）
• Text splitters，LangChain 文档（https://docs.langchain.com/oss/python/integrations/splitters）
• Build a knowledge base，LangChain 文档（https://docs.langchain.com/oss/python/langchain/knowledge-base）
• Introducing Contextual Retrieval，Anthropic（https://www.anthropic.com/news/contextual-retrieval）
• Hybrid search，Weaviate 文档（https://docs.weaviate.io/weaviate/search/hybrid）
• Rerank overview，Cohere 文档（https://docs.cohere.com/docs/rerank-overview）
• Introducing Rerank 3.5，Cohere（https://cohere.com/blog/rerank-3pt5）
• Evaluate a RAG application，LangSmith 文档（https://docs.langchain.com/langsmith/evaluate-rag-tutorial）
• Online evaluations，LangSmith 文档（https://docs.langchain.com/langsmith/online-evaluations）
• January 2026 LangChain newsletter，LangChain 博客（https://blog.langchain.com/january-2026-langchain-newsletter）