RAG生产实践：LangChain等框架到底该不该用？

在AI应用开发社区里，"到底要不要用LangChain/LlamaIndex这类封装框架"的争论从未停歇。一位刚完成端到端生产级RAG引擎的开发者，在Reddit上分享了他的真实经验，给出了一个不站队但极具操作性的答案。

核心结论：框架不是信仰，是工具

这位开发者的立场很明确：如果你只是调用 chat.completions.create() 或做简单的 text[:500] 文本切分，引入LangChain就是纯粹的抽象债务——多一层封装，多一层不透明的报错堆栈。

但当系统从周末原型走向处理真实世界的文档混乱时，问题才真正浮现。他的判断是：框架不应该是一种"全有或全无"的宗教信仰。最强的RAG架构应该用原生、确定性的Python处理重数据建模、文档解析和验证逻辑，同时在可观测性、连接器和评估流水线上借助成熟框架。

什么场景该自己写

文档AST与结构层级

开箱即用的切分器会盲目地从句中截断PDF，或者把一张40行的财务表格从中间切开，彻底破坏表头上下文。这位开发者用Docling构建了自定义AST布局解析器，保留父级章节面包屑、拼接跨页表格，并将表格链接回其前面的叙述性文字。

这类需求在通用框架中几乎无法优雅实现，因为文档结构的语义完整性依赖于具体业务场景。

Docling 是 IBM 开源的一款文档解析库，专门针对 PDF、DOCX、PPTX 等复杂格式，能够输出结构化的文档对象模型（DoclingDocument）。它内部集成了版面分析模型（如 DocLayNet）和表格识别模型（如 TableFormer），可以识别标题层级、段落、列表、表格、图片以及阅读顺序。相比 PyPDF2、pdfplumber 这类纯文本抽取工具，Docling 保留了语义结构信息，因此适合构建自定义 AST 布局解析器。开发者可以基于它输出的层级节点，自定义父级章节面包屑、跨页表格拼接和表格与叙述文本的关联逻辑。Docling 同时支持 OCR 和多种导出格式（Markdown、HTML、JSON），在需要精细控制文档结构的生产级 RAG 场景中，常被选作底层解析引擎。

领域特定的验证逻辑

标准封装和通用切分器不会告诉你OCR是否误读了一个数字或偏移了一列。他在检索之前，实现了对原始PDF字节层的亚2毫秒逐字源文本校验，以及算术列对账。这种级别的校验需要深入理解数据本身，通用框架无能为力。

精细化的检索数学

自定义的稠密向量与稀疏BM25之间的倒数排名融合（RRF），结合上下文感知、token预算内的命中折叠，在纯Python中更易于维护和性能分析。

倒数排名融合（Reciprocal Rank Fusion, RRF） 是一种无需调参的混合检索结果合并算法，常用于融合稠密向量检索与稀疏关键词检索（如 BM25）的排名列表。其核心公式为：对每个文档，将其在各检索器中的排名取倒数后加权求和，通常权重设为 1/(k + rank)，其中 k 为平滑常数（常取 60）。RRF 的优势在于不依赖不同检索器分值的绝对尺度，仅利用排名信息，因此鲁棒性强且易于实现。在 RAG 系统中，RRF 能有效结合语义相似性与关键词精确匹配，提升召回质量。如文中所述，纯 Python 实现 RRF 便于嵌入上下文感知的 token 预算内命中折叠等定制逻辑，比框架内置的通用融合器更灵活。

什么场景该用框架

可观测性与链路追踪

集成LangSmith或OpenTelemetry来追踪动态工具调用、提示词变体和延迟分解，相比自建遥测基础设施可以节省数百小时。这是框架最无可替代的价值之一。

生态可移植性

在不重构客户端契约和中间件逻辑的前提下，切换向量后端（Qdrant、Chroma、PGVector）或模型提供商（Mistral、Claude、OpenAI）。这种灵活性在原型阶段尤其宝贵。

评估标准

使用经过实战检验的接口进行基准生成保真度、RAGAS指标和引用溯源评估。评估管线的标准化程度直接影响迭代速度。

RAGAS（Retrieval-Augmented Generation Assessment）是一个专为 RAG 系统设计的开源评估框架，提供了一系列无需人工标注的自动化指标，包括：忠实度（Faithfulness，衡量答案是否完全基于检索上下文）、答案相关性（Answer Relevance）、上下文精确度（Context Precision）和上下文召回率（Context Recall）。这些指标通过调用 LLM 对生成结果与检索内容进行交叉验证，帮助开发者量化检索质量和生成质量。RAGAS 可以与 LangSmith 等可观测性平台集成，形成从追踪到评估的闭环。在标准化评估管线中采用 RAGAS，能显著加快迭代速度，避免重复造轮子，这也是文中强调框架在评估层不可替代的原因之一。

混合架构才是正解

这位开发者的最终建议是采用混合架构：重数据建模、文档解析和验证逻辑用原生Python，可观测性、连接器和评估管线用标准框架。

他已经在GitHub上开源了完整的技术拆解和测试套件，涵盖AST解析、双格式表格序列化、混合RRF和LangSmith遥测。对于正在生产环境运行RAG的团队来说，核心问题不是"用不用框架"，而是"在哪些层面用框架"。

这种务实的分层思路，或许比任何一方的极端立场都更有参考价值。