為什麼RAG不好? 什麼比較好

如果模型答不好是因为它没见过你公司的政策、内部文档或某批数据，那这类信息本来就不在权重里，检索补上它是合理的。但如果缺的是推理、判断或稳定执行某个动作的能力，再塞多少文档也补不上，反而会让人误以为问题解决了。立正讲RAG时提醒，很多人从切文档、做embedding、存向量库这条管线学起，把“做过RAG”当成学会了，这只带来进步的感觉，真正难的是上下文管理、任务拆解和结果确定性这些看起来软的部分⁠1。所以先问：把资料直接放进提示里，模型能不能答对？能，说明缺的是资料；不能，说明缺的是别的。

RAG真正解决的问题是：资料太多、放不进上下文，或者需要按问题挑出相关的那几段。它把“带知识的应用”变成可运行的东西，比如基于政策文档回答产假天数，但那个案例最后也转向规则引擎来保证计算准确⁠2。这说明检索只是入口，答案准不准还取决于资料是否可靠、检索是否找对、结果是否可核对。如果资料量很小、一次就能全放进上下文，搭一套检索管线可能只是多了一层排错成本。

立正反复强调学AI要靠真的去build，在做的过程中学到的才有用，光靠知识没用⁠3。放到这个问题上，与其先争论RAG值不值得，不如拿你那个“模型缺知识”的具体问题做一次小对照：一次把相关资料直接给模型，一次用检索挑出相关片段再给模型，看哪种答得更准、错在哪里。如果直接给资料就能答对，说明瓶颈在资料获取而不在检索；如果资料太多给不全、或给全了模型抓不住重点，检索才有用武之地。这个对照能帮你判断该不该投入，而不是先决定要不要学RAG这个名词。

立正主张把每个新名词拆成两半：一半是为绕开当年技术限制而生的包装，限制消失就贬值；一半是一直存在的问题。RAG的固定流程（切分、向量化、检索）是上下文窗口小、模型不太会调工具时的产物，真正要学的是信息检索本身。所以面对内部规范，先问：模型强十倍后这套做法还重要吗？它到底在解决什么问题？如果规范只是几十页、问题也不多，把整份规范放进长上下文可能比搭检索管线更省事；如果规范很长、条目多、还要按权限区分，检索才有必要⁠1,2。

立正把带知识的AI应用归为第二层：模型基于文档、政策、数据作答，技术重点在切分、混合检索、重排、元数据过滤、权限感知、引用和时效控制，而不是写好提示词。但他也举过一个学员案例：产假计算最初想做检索，最后改成规则引擎直接算天数、生成申请文本，因为政策是确定的计算规则，检索反而不如规则可靠。你的规范如果大量是“满足什么条件就怎么处理”的条款，规则引擎或结构化查询可能比检索更准；如果是分散的说明、案例、口径解释，检索或长上下文更合适⁠3,4。

现有材料没有专门讨论LLM-wiki，无法判断它是否更好。可以按立正的比较方法自己检验：不用它时，你最合理的做法是什么——整份规范塞进上下文、让agent用命令行搜索文件、还是写规则？如果LLM-wiki只是把规范整理成模型易读的条目，它改善的是“资料可读性”，那要先确认你的瓶颈是不是这个；如果瓶颈是规范更新频繁、口径不一致，整理成wiki反而增加维护成本。可以先拿一小块规范试：同一批真实问题分别用整份上下文和整理后的版本回答，看答案是否准确、引用是否可追溯、规范改动后是否容易同步⁠5,6。

立正在一期讲“不学概念、学动作”的视频里提到，团队围绕RAG出过一篇文章，并给出一个判断：基础的RAG管线里真正有用的部分，已经被平台吸收了，企业愿意付钱的是围绕结果的那些动作，比如权限控制、监控、诊断、上下文工程、工作流设计和评估。他还举了另一家公司的例子：去年推MCP，今年觉得MCP不好用又想换skills，领导层却刚下令所有东西都做成MCP。只盯名词、不盯结果，就会反复踩这种坑⁠1。

另一篇讲AI叙事陷阱的长文里，RAG被当作同一类跳跃的例子：切片检索能找到语义相近的段落，却可能丢掉理解所需的关系。他们用三年聊天记录做实验，切片加embedding能回答谁说过什么，却答不好“大家对AI协作的理解怎样演化”，因为相近的几段话不一定保留了这些关联。后来他们把能放进长上下文的完整记录交给模型，再逐步反思、验证、提炼。资料多到一次读不完时，他们更推荐保留文档结构的markdown加搜索加智能routing，让AI按问题选文件、补读，而不是先搭一套固定的切片检索流程⁠2。

这不等于RAG没用。在给学员项目分类时，立正把“基于文档、知识库、政策作答”的应用归为Grounded AI/RAG这一层，关键是让AI有依据地作答，而不是自由发挥。其中一个产假助手项目最初想用RAG从政策文档里提取信息，最后转向规则引擎直接算天数，因为计算本身不需要模型判断。这说明选RAG还是规则、长上下文、agent自行搜索，取决于任务需要怎样的信息，而不是先接受“私有资料就该切片检索”的默认路线⁠3,2。