构建 RAG 时，哪个模块最容易“卡壳”？面试官的关注点揭秘

前不久在知乎回答了一个提问：大家觉得做一个大模型检索增强生成（RAG）系统，最难搞定的是那部分工作？这里也分享给大家。我先说结论： RAG 最难的，从来不是“把流程跑起来”，而是“让它真的好用”。几乎所有人第一次做 RAG，都会被这套标准流程迷惑住：

荔枝学Python

599人浏览 · 2025-11-18 11:16:08

荔枝学Python · 2025-11-18 11:16:08 发布

前不久在知乎回答了一个提问：大家觉得做一个大模型检索增强生成（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 是大模型落地的“脊梁骨”。

它不花哨，却决定成败。

“好用”比“能跑”难十倍，但也值十倍。

在大模型时代，我们如何有效的去学习大模型？

现如今大模型岗位需求越来越大，但是相关岗位人才难求，薪资持续走高，AI运营薪资平均值约18457元，AI工程师薪资平均值约37336元，大模型算法薪资平均值约39607元。
在这里插入图片描述

掌握大模型技术你还能拥有更多可能性：

• 成为一名全栈大模型工程师，包括Prompt，LangChain，LoRA等技术开发、运营、产品等方向全栈工程；

• 能够拥有模型二次训练和微调能力，带领大家完成智能对话、文生图等热门应用；

• 薪资上浮10%-20%，覆盖更多高薪岗位，这是一个高需求、高待遇的热门方向和领域；

• 更优质的项目可以为未来创新创业提供基石。

可能大家都想学习AI大模型技术，也_想通过这项技能真正达到升职加薪，就业或是副业的目的，但是不知道该如何开始学习，因为网上的资料太多太杂乱了，如果不能系统的学习就相当于是白学。为了让大家少走弯路，少碰壁，这里我直接把都打包整理好，希望能够真正帮助到大家_。

👉[CSDN大礼包🎁：全网最全《LLM大模型入门+进阶学习资源包》免费分享（安全链接，放心点击）]()👈

一、AGI大模型系统学习路线

很多人学习大模型的时候没有方向，东学一点西学一点，像只无头苍蝇乱撞，下面是我整理好的一套完整的学习路线，希望能够帮助到你们学习AI大模型。

在这里插入图片描述

第一阶段：从大模型系统设计入手，讲解大模型的主要方法；

第二阶段：在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段：大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段：大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段：大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段：以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段：以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。