正文
RAG就是个图书馆，LLM可以根据问题去想好需要找哪些资料，然后再召回资料，找回来后再简单过滤筛选重排下，找不到，可以再去互联网搜。现在也都是这么干的。
对于找到的资料是否相关，比较垂直的领域里，判断准确还是可以调好的。通用AI场景就不好调了。
面试官问：RAG 系统里面最难搞定的是哪个部分？
RAG 最难的，从来不是“把流程跑起来”，而是“让它真的好用”。
几乎所有人第一次做 RAG，都会被这套标准流程迷惑住：
用户提问 → 文档检索 → 拼接上下文 → 交给大模型生成。
代码很好写，十几行 Python + 一个向量库 API 就能跑通。 但你真要让它“在生产环境下稳定地答出好答案”， 难度是成倍增长的。
一、RAG 不是算法问题，而是“系统问题”
RAG 的本质是一个系统性工程，而不是一个单点算法。 它的难点是——每个环节看似简单，但环环相扣， 任何一环的瑕疵都会直接导致答案“看起来不太聪明的样子”。
举个例子：
- 检索不准 → 模型找不到关键信息；
- 检索不全 → 模型答偏题；
- 拼接上下文太多 → 超过 token 上限，输出混乱；
- 拼接上下文太少 → 模型信息不足，回答空洞。
所以真正的难点不是“能不能跑”， 而是：怎么设计一个端到端可控的 RAG 管线。
二、从我的经验看，RAG 最难搞定的其实有四关：
1️⃣ 数据准备：垃圾进，垃圾出（GIGO 原则）
很多人上来就想着搭 Milvus 或 FAISS， 但根本没搞清楚自己要检索的是什么。
RAG 的灵魂在知识库。 而知识库的质量，取决于数据处理的精细程度。
比如文档切块（Chunking）：
- 切太碎，语义被切断，模型失去上下文；
- 切太大，召回粗糙，匹配不准；
- 关键内容分散在多段中，还容易被 embedding 稀释。
我在做企业知识 RAG 时， 我们尝试过不同粒度的切块策略（按标题/段落/语义距离）， 最后还得结合 动态窗口 + 语义相似聚类 才稳定下来。
如果你随便“split(500)”一刀切， 那 RAG 的后果大概率是：
“答案看起来没错，但总觉得答偏了。”
2️⃣ 检索召回：不是找最相似的，是找最有用的
很多人以为用个 embedding 模型就完事了。 但 embedding 模型之间差距极大。
在实际项目中，我们踩过很多坑： 同样一份知识库，换不同 embedding 模型， RAG 的命中率能差出 30% 以上。
比如：
- text-embedding-ada-002 适合英文、通用任务；
- BGE/M3E 在中文任务上召回效果更好；
- SimCSE 在短文本匹配上有优势；
- 有些企业项目甚至需要多模态 embedding。
而最难的是调 召回阈值。 阈值太低，检索一堆废话； 阈值太高，漏掉关键句子。 最终我们是靠 Reranker 模型（重排器） 才解决的。
这部分调优过程，堪比玄学。 很多同学第一次做 RAG 的时候，卡死在这里。
3️⃣ Query 理解：用户问的，不一定是模型听懂的
很多人以为检索的 query 就是用户的问题本身。 但在实际场景里，这一步其实最“坑”。
举个例子： 用户问「合同续签流程怎么走？」 你去知识库检索“合同续签流程”， 结果命中 0 条。
为什么？ 因为原文里写的是「合同延展」或「合同二次审批」。
所以在工业级 RAG 系统里， Query 重写（Query Rewriting） 是非常关键的一环。
我们通常会在这一步加一个小模型（或规则引擎）：
- 把口语化的问题改写成语义标准的搜索词；
- 结合上下文补全隐藏条件；
- 或者动态生成多个检索子 query。
比如上面的问题，我们会改写成：
“合同延展审批流程 / 合同二次签署操作指引 / HR 系统续签权限”
这样召回的结果才会命中核心知识。 很多人忽略这步，RAG 就废了一半。
4️⃣ 生成阶段：RAG 不是“检索+生成”的简单加法
最后一个坑，是很多人误解了“RAG + LLM”的关系。
真正成熟的 RAG 系统，是 在生成阶段做控制 的。 否则 LLM 很容易“自作聪明”，胡编乱造。
比如我们在企业问答里， 会在 Prompt 中明确规定：
“如果检索结果不足，不要编造，请回复‘知识库中暂无相关信息’。”
或者给模型输入：
“仅基于以下内容回答，不要添加额外推理。”
还有更高级的做法： 用 Retrieval Score 作为奖励信号， 训练一个 RAG-Fusion 模型， 让模型学会“信任检索结果”。
这就是为什么很多团队做完 RAG 后觉得模型还是乱答， 因为他们只做了“拼接”，没做“约束”。
三、那到底哪一部分最难搞？
如果我必须选一个，我会说： 最难的是让整个系统“协同”起来。
你可以让每个模块都各司其职， 但要让他们协同到最优， 就需要你既懂算法，又懂工程。
比如你要同时考虑：
- 文档更新频率（知识库维护）
- 向量召回性能（索引优化）
- Prompt 格式（生成阶段控制）
- 模型响应速度（API 并发与缓存）
换句话说， RAG 是所有“大模型项目”中最能体现“算法工程师功底”的模块。 它要求你既能设计算法，又能搭系统。
这也是为什么很多人能写出“能跑的 RAG”， 但写不出“能上线的 RAG”。
四、未来趋势：RAG 已经进化为 DataAgent
今年（2025）我观察到一个趋势： 越来越多公司在讲“RAG 已死，DataAgent 当立”。 其实不是死，而是进化。
过去的 RAG 是被动检索—— 用户问问题，系统查知识库。
而现在的 DataAgent 是主动更新—— Agent 自动从网页、API、数据库收集信息， 动态更新知识库，实现“长记忆 + 实时性”。
这背后考验的不是某个算法点， 而是你能否构建一个数据闭环系统： 从信息采集 → 清洗 → 切块 → Embedding → 检索 → 生成 → 评估。
RAG 的“门槛”，也正在从“技术实现” 转向“工程架构设计”。
五、最后的小结
如果要一句话回答这个知乎问题：
“做一个大模型检索增强生成（RAG）系统，最难搞定的是什么？”
我的答案是：
最难的，不是某一环节，而是让每一环节都有章可循、能被验证。
RAG 不是一段代码，而是一整套数据流系统。 你要把它做好，既得懂 NLP，又得懂工程； 既得懂 Prompt，又得懂数据库； 既得能跑通 Demo，又得能稳定上线。
也许别人眼中这只是一个“附属模块”， 但真正懂的人都知道—— RAG 是大模型落地的“脊梁骨”。
它不花哨，却决定成败。
“好用”比“能跑”难十倍，但也值十倍。