S20-A03 · 工程选型：RAG 2.0、框架与落地路径

适用读者：要把 RAG demo 做成生产系统的人。
前置：S20-A01、A02。
覆盖旧文：1949(502) 285(354) 630(96) 1927(231) 1928(227) 2080(117) 737(85) + 1065(108) = 1,720 点。
覆盖扩展：E-S20-011（RAG 2.0 与工业级优化项）。
上一篇：S20-A02 · 安全与多模态：数据边界与内容形态
下一篇：S20-X01 · 八股速查。

1. 一句话结论

RAG 的"2.0"不是新算法，而是工程化：把"检索—重排—生成"做成可评估、可观测、可回滚的流水线。选型看的是"你要自己维护多少"。

形态	谁维护	适合
托管服务（云厂商 RAG）	厂商	快速验证
框架自建（Spring AI / LangChain 类）	你	需要定制与私有化
自研 pipeline	你（全部）	规模大、要求极端

2. 工业级 RAG 的八个优化项（E-S20-011）

#	项	收益
1	混合检索（向量+BM25）	召回率
2	重排（Rerank）	精度
3	查询改写	口语化问题
4	分块策略（递归+重叠）	语义完整
5	缓存（查询/片段）	成本与延迟
6	结构化输出 + 引用	可信度
7	评估集与回归	可持续
8	权限过滤	安全

判据："这八项里我做了几项？" 少于 3 项 → 还停在 demo 阶段。

3. 框架选型的三个问题

① 团队技术栈？（Java → Spring AI；Python → LangChain/LlamaIndex）
② 需要私有化 / 合规吗？（需要 → 自建）
③ 愿意被框架锁多久？（框架 API 变动频繁）

"框架最大的风险"：抽象层太厚，出问题时看不到底层——所以核心链路（检索+重排）最好自己可控。

4. 落地路线（四阶段）

阶段	目标	验收
① 打通	能答	20 条问题的可用率
② 可评估	有指标	评估集 + 回归
③ 可运维	能看能回滚	日志/追踪/灰度
④ 降本	延迟与成本达标	P99、单次成本

判据："出问题时能定位到"加载/分块/检索/生成"哪一段吗？" 不能 → 还没到阶段 ③。

5. RAG vs 微调 vs 长上下文（A-1065）

方案	何时选
RAG	知识频繁更新、需可追溯
微调	风格/任务稳定、要小模型
长上下文	文档小且固定（S20-B01 §3）

判据："知识多久变一次？" 每周变 → RAG；几乎不变且量小 → 长上下文也行。

6. 五个误区

误区	真相
"上个框架就生产就绪"	框架只解决拼装
"RAG 2.0 是新模型"	是工程化
"自研一定更好"	维护成本高
"评估集是奢侈品"	没有它无法迭代
"长上下文能取代 RAG"	成本与更新都受限

7. 自检（架构师版）

三种形态的维护边界？
八个优化项里哪三项是"及格线"？
框架选型的三个问题？
四阶段路线与验收？
RAG/微调/长上下文怎么选？

8. 下一篇

S20-X01 · RAG/Agent 八股速查

最后一篇是附录索引，随后进入 S21（Agent 工程）。

本篇属于系列《S20 · AI 应用与工程》。旧文来源：A-1949/285/630/1927/1928/2080/737/1065；扩展点 E-S20-011。