我不用 LangChain 重造了 RAG 流水线：哪些变好了、哪些变糟了
来源：dev.to — 2026-09-06
📋 概述
作者第一次真正动摇对框架的信任，不是因为模型幻觉，而是因为答案看起来合理、带着引用、却仍是错的：助手捞到一个已废弃帮助页的 chunk，因为流水线某一段应用了元数据过滤、另一段没有，最终提示组装让一切都显得自洽，调试只能一层层扒 wrapper 而问不出真正的问题。他把 LangChain 从 RAG 的核心降级为可选集成层，用显式阶段重建了流水线。最大的收获不是性能而是流水线变得「可读、每处接缝可见」；最大代价是他从此要自己背起一大堆框架替你藏起来的枯燥胶水代码。
🔑 核心要点
- 最大的赢不是性能而是显式：拆成 plan_query→retrieve→select_evidence→build_prompt→generate 的普通函数序列后，检索烂看 plan/retriever、prompt 烂看 builder、答案不忠查 evidence——失败与你之间再无 chain 抽象
- chunking 从文本问题变成文档结构问题：把 chunk 当「证据单元」，表格要保留表头语义、代码块带上紧邻解释、编号步骤不与引言拆散——带上下文的 E1042 比裸行更容易检索、重排与忠实使用
- 检索前先做轻量 query planner 抽取结构化意图（改写检索词、抽 filters、选 hybrid/keyword/semantic 模式），且权限过滤应是检索的一部分而非后处理，否则会因不可访问文档丢掉最佳候选
- 混合搜索是标识符的务实解：向量管语义召回、关键词管精确 token（SKU/错误码/API 路由），reciprocal rank fusion 融合结果；重排是最高杠杆的质量闸门，retrieve broad→rerank narrow→select evidence
- 去掉框架的代价被诚实摊开：文档加载器极其难做（多栏 PDF/跨页表格/导航菜单噪音）、要自己维护嵌入批处理/索引迁移/缓存失效/租户过滤等大量运营胶水——重建是一笔交易：换来了控制也背上了更重的运维责任
💡 金句
去掉 LangChain 的收益不是流水线变小了，而是它变得可以读懂了——而一旦流水线可读，每一个难题都变得更容易定位。
👍 0
👎 0
← 返回 dev.to 首页