RAG 框架与系统架构：LangChain、LlamaIndex 与自建
06-工程化与前沿
入门
约 15 分钟
#框架#LangChain#LlamaIndex#架构
更新 2026-10-02
当前状态：未学
本文基于模型知识整理（生成时未联网核对），关键结论建议对照经典文献复核。
一句话定义
主流 RAG 框架（LangChain、LlamaIndex、Haystack 等）把流水线各环节组件化，加速原型；而生产系统往往走向"关键链路自建 + 框架仅取零件"的形态——框架的价值在起步速度，代价在抽象泄漏与升级耦合。
为什么重要
框架选型是每个 RAG 项目的第一个工程决策。用错姿势的两种典型结局：全程深度耦合框架后升级即重构，或完全自建后把 80% 时间花在重造检索器。理解框架各自强项与"用框架的度"，能省下大量试错时间。
前置知识
kp-002（流水线是框架组件化的蓝图）。
核心概念
- LangChain：通用 LLM 应用编排——组件最全（loader/splitter/retriever/agent），生态最大；抽象层多，调试需要穿透框架看 prompt。
- LlamaIndex：以数据索引与检索为核心——分块/索引结构（tree、keyword、knowledge graph index）最丰富，RAG 专注度高；通用编排弱于 LangChain。
- Haystack：检索管线出身（deepset），管道声明式、生产部署口碑稳。
- 向量库自带 SDK（Pinecone/Qdrant/Milvus）：没有框架也能直接搭最小链路。
- 自建 vs 框架的判据：原型期用框架快速验证；生产期把"核心差异化链路"（分块策略、检索融合、评测）自建为显式代码，框架只作零件供应商。
原理与机制
框架抽象的泄漏点：RAG 效果高度依赖底层细节（prompt 措辞、分块参数、检索参数），而框架把这些藏进默认值——"换框架默认行为"即效果漂移，且默认值随版本变化。因此生产纪律是：显式化一切关键参数（自己写 prompt 模板、显式传 chunk/overlap、显式融合逻辑），把框架当便利函数库而非黑盒管线。
评测与框架解耦：无论用哪个框架，评测层（kp-016）必须直接对着"线上同款 prompt + 检索配置"跑，避免"框架内部行为与评测实现不一致"的假绿。
架构形态参考：典型生产栈 = 摄入管道（队列 + 解析 worker）+ 双库（向量库 + 图库/搜索引擎）+ 服务层（检索编排、路由、缓存）+ 评测/观测旁路（对齐 kp-031）。框架可占据其中任何一格，但格与格之间的接口要自己定义。
实例或案例
- 两周原型：LlamaIndex 默认管线 + 100 条评测集，验证业务可行性——框架的甜点区。
- 生产迁移：把分块与检索融合改为自研模块（显式参数 + 单测），LangChain 仅保留 loader 与工具调用——升级解耦。
- 大流量服务：干脆自建（请求量大后框架层的 Python 开销与抽象成为负担），框架只用于离线实验。
常见误区
- 误区一："框架默认配置就是最佳实践"。默认值是"能跑通"而非"最优"；不显式化参数的团队等于把效果交给框架版本变更摆布。
- 误区二："换框架能解决效果问题"。效果瓶颈几乎总在数据与检索细节（kp-017），换框架只是换了同一瓶酒的包装。
- 误区三："评测跟着框架走"。评测实现与线上链路不一致（不同 prompt、不同检索参数）会给出误导性指标；评测必须钉住线上配置。
与其他知识点的关系
自测题
- 框架抽象在 RAG 场景的主要泄漏点？
答：关键效果参数（prompt、分块、检索参数）被藏进随版本变化的默认值；对策是显式化全部关键参数、框架仅作零件库。
- 评测为什么要与框架解耦？
答：评测必须对齐线上真实 prompt 与检索配置；经框架黑盒跑评测会与线上行为不一致，指标失真。
- "核心链路自建"指哪些环节？
答：构成差异化效果的环节——分块策略、检索融合/路由、prompt 模板与评测；加载器等通用件可继续用框架。
延伸阅读
- LangChain / LlamaIndex / Haystack 官方文档的 RAG 教程与版本变更记录。
- Chip Huyen《AI Engineering》关于框架取舍的章节。
- 各向量库官方 quickstart（无框架最小链路）。