RAG 的关键从来不是向量——是你能不能把对的内容捞出来

RAG 的关键从来不是向量——是你能不能把对的内容捞出来“咱们做个 AI 知识库吧。”团队里只要有人提这么一句接下来的动作几乎是条件反射搭一个向量数据库把文档切成小块灌进去让 AI 按相似度去捞。好像不上向量就不算做了 AI。可你的资料其实就那么几类结构清清楚楚。一套向量库搭下来检索效果还经常不如直接翻目录。钱花了活没干漂亮问题到底出在哪出在第一步就想错了。AI 要帮你干活前提是先从你成百上千个文档里找到那几条真正有用的。这件事有个词叫 RAG。而十有八九你一听到 RAG脑子里立刻蹦出来的就是那个词——向量数据库。这恰恰是要掰扯的第一个误区。RAG 的关键从来不是向量。是你能不能把对的内容捞出来。一、一提 RAG 就想到向量库你已经把手段当目的了为什么大家会有这种条件反射因为现在但凡讲 RAG 的教程、文章、开源项目几乎都是同一套动作文档切块、灌进向量库、按相似度召回。看多了所有人脑子里就刻下一个等式——RAG向量库。可这个等式从一开始就是错的。向量只是 RAG 的一种实现手段不是 RAG 本身。把用了向量当成做对了 RAG就像把买了跑鞋当成已经在跑步——工具到位了正事一步没动。更麻烦的是这种错位会让你彻底忽略真正该想的问题RAG 到底要解决什么只有想清楚这个你才知道向量该不该上、什么时候上。二、RAG 的内核检索增强生成命门在检索到对的先回到这三个字母本身。RAG全称是检索增强生成Retrieval-Augmented Generation。拆开看就三步先检索把相关资料找出来再用这些资料增强模型的输入最后让模型生成回答。很多人盯着生成觉得 AI 聪不聪明决定了一切。也有很多人盯着用什么库、什么模型。但真正的命门是中间那个动作——检索。更准确地说是能不能检索到对的内容。这话听起来像废话其实不是。你想想模型本身并不知道你的资料。它能回答好你的问题靠的不是它有多懂你而是你在它回答之前把对的那几条资料喂到了它嘴边。你喂对了再普通的模型也能答得像模像样。你喂错了——或者喂了一大堆里面只有一两条有用——再强的模型也救不回来。它只会从一堆杂音里挑出几句看着像答案的话然后一本正经地说错。所以 RAG 好不好用不取决于你用了哪种技术范式而取决于一件事你能不能稳定地、可靠地把 AI 这一步真正需要的那条内容捞出来。三、什么叫检索到对的内容厨子要的是一根葱打个比方。把 AI 想象成一个厨子。它手艺不错但它的冰箱是空的——它不知道你家有什么菜。每做一道菜它都得让你去拿料。它说“给我一根葱。”你递上一根葱。它三两下菜就成了。这叫检索到对的内容。但换个场景。它还是说给我一根葱。你怕拿少了不够用干脆把整个冰箱搬到它面前——葱、姜、蒜、昨天的剩菜、过期的酸奶全堆在案板上。你觉得自己很负责料给得足足的。可厨子傻眼了它得先从这一堆里翻出那根葱翻的过程中还可能顺手抓错把香菜当成葱扔进锅里。这道菜大概率糊。这就是检索最反直觉的一点捞上来的不是越多越好是越准越好。很多知识库不好用不是因为资料太少恰恰是因为每次检索都捞回来一大堆看着相关、其实没用的东西。AI 被这些杂音淹没反而抓不住重点。你给它的不是一根葱是一整个冰箱。记住这个画面。后面讲向量、讲目录都用这把尺子来量你这套方法到底是稳定地递上一根葱还是经常端来一整个冰箱四、大多数场景一个好目录就能稳定递上那根葱那怎么才能稳定地递上一根葱答案可能让你意外对绝大多数人、绝大多数场景来说不需要向量按业务维度建一个好目录就够了。举个具体的例子。假设你要给一个团队整理知识库里面有产品文档、技术方案、对接接口说明、历史问题记录、规章制度。一种做法是把所有文档切成小块全灌进向量库。用户问退款接口怎么调系统去算哪些文本块跟这句话语义接近。它可能捞回来退款接口文档也可能捞回来一篇讲退款政策的制度文件——因为这两个在语义上都挺接近。准不准全看运气和调参。另一种做法是先想清楚一件事这些资料人是怎么分类的产品文档归产品接口说明归技术对接问题记录按模块归档。建一套这样的目录就像图书馆的分类号。用户问退款接口怎么调顺着目录定位到技术对接 → 支付模块 → 退款接口直接翻到那一篇。哪种更可能递上那根葱显然是后一种。因为目录这件事的本质不是存资料而是把人对业务的理解变成了一条条检索路径。你按业务维度分好的每一个类目其实就是一条检索逻辑。AI 不用去猜哪段文字语义接近它顺着你定义好的结构一层层走到正确的位置。五、光有目录还不够得先给 AI 一张地图但这里藏着一个很多人会踩的坑。目录建好了文件夹分得清清楚楚AI 就能用了吗不能。你把它直接丢进这堆文件夹里它跟一个第一天来的新人没两样——面前一排柜子不知道哪个抽屉装什么只能一个个拉开翻。要么翻半天要么干脆翻错柜子。它缺的是一张地图。所以结构化检索真正的关键一步是在目录之外单独写一份描述这套目录长什么样的文档——有哪几个大类、每一类装的是什么、大概放在哪。说白了就是给整个知识库画一张大纲一张目录的目录。AI 来找东西不是一头扎进文件夹乱翻而是先读这张地图看懂全局判断这次任务该往哪一类走再钻进去。而且这张地图可以分层。大类下面如果还很复杂那一类里再放一份更细的小地图描述它内部的结构。AI 顺着大地图找到方向进了某一类再读那一类的小地图接着往下直到精确定位到要的那一篇——才把完整内容调出来看。这套先看地图、再逐层深入的机制有个名字叫渐进式披露不一次把所有资料都摊给 AI而是它走到哪一层才披露那一层的信息。它和你在图书馆找书的过程一模一样先看大厅的分区指示牌走到对应区域再看货架编号最后才走到那一格、抽出那本书。没人会把全馆的书都搬到面前再挑。这么做的好处有两个。一个是准。AI 每一步只看当前这层必要的信息不会被几百份无关文档淹没——还是那句话递一根葱不是端一冰箱。另一个是稳。整个过程可追溯它走到哪一层、为什么进这个类目你都看得见错了也知道错在哪一步。六、这套土办法凭什么比向量靠谱可能有人会说目录加大纲听着这么土怎么会比向量库还好恰恰是这个土藏着三样向量给不了的东西。它能解释。AI 找到一条内容你能清楚地知道它为什么是这一条——因为它就在支付模块这个类目下地图怎么指、它怎么走一步步都看得见。换成向量捞回来一段文字你问它为什么是这段得到的答案是因为它的向量距离最近。这话没法跟人解释也没法审计。它能改。发现某类问题 AI 老找错地方你直接去调目录、改大纲、把那篇文档挪到正确的类目下就行改完立刻见效。向量库里你想精准干预这个问题应该优先匹配这篇非常别扭往往得重新切片、重新灌库折腾半天还不一定准。它跟着业务长。业务怎么分模块、怎么划边界目录和大纲就怎么写。业务变了跟着改一行就行检索逻辑永远和真实业务对齐。向量不一样它脱离业务语义——只懂文字像不像不懂你这家公司的业务边界到底在哪。所以这真不是土不土的问题。可解释、可修改、可审计恰恰是一套严肃系统最离不开的东西。它递上来的是一根葱而且你知道它为什么递的是葱。说到底整套方法就闭环了人按业务把目录和大纲定义清楚秩序AI 顺着地图一层层检索在秩序里找资料每一步都能解释为什么是这一条可审计。这正是人定义秩序AI 在秩序里生长体系负责验证在检索这件事上的样子。这种结构化检索 渐进式披露的协作方式也沉淀在了开源的agent-workflows里配合framework的工程底座你可以直接拿去用。七、那向量什么时候才该上讲到这得说句公道话向量不是没用它是被滥用了。向量真正该上场的是这么一种场景——海量、模糊、说不清类目。什么意思比如一个面向全网的搜索产品文档量是千万级、上亿级内容五花八门你根本没法、也来不及给它建一套清晰的人工目录和大纲。用户的提问又特别口语化、特别模糊“那个能把照片变清楚的工具叫啥”这种问题没有现成的类目能对上。这时候向量的按语义模糊匹配才真正发挥价值——它不需要精确路径能在一片混沌里捞回来一批大致相关的候选。注意这是一种用模糊换覆盖的取舍你放弃了精确和可解释换来了在海量、无结构数据里还能找到点东西的能力。只有当你的场景确实到了人工目录维护不过来的规模这笔交易才划算。而且更进一步——就算到了这种规模向量也不该是你每个项目自己手搓一套。它最好的形态是被封装成一个 MCP对外提供接入。这里得提一个东西叫 MCP——你可以把它理解成一种标准化的能力接口。海量向量检索这种又重、又专业、又吃资源的能力最合理的方式是由专门的平台做好封装成一个标准接口谁需要谁接进来调用而不是每个做知识库的团队都从头搭一套向量库、自己切片、自己调参、自己维护。说到底给做产品的人一句实在话先老老实实把结构化目录和大纲维护好。只有当数据真的到了平台级海量、又没法结构化的程度才考虑向量而且优先接别人封装好的 MCP别自己造轮子。八、写在最后回到开头那个问题你的资料那么多AI 怎么才能找到需要的信息答案不是上一个向量库。答案是先把怎么才能检索到对的内容这件事想清楚再选技术。想清楚了一个好目录就够想不清楚再贵的向量库也只是换了个姿势端冰箱。RAG 的内核从来不是向量是检索检索的命门也不是找得多是找得准。技术只是手段能不能稳定递上那根葱才是真问题。未来真正会用 AI 的人不一定是懂多少检索算法的人而是能先想清楚AI 这一步到底需要哪条内容、再把资料组织成它够得着的样子的人。下一篇聊个新问题一个 AI 能干的活终究有限当任务复杂到它一个人忙不过来怎么把活拆给一个AI 团队——多个 Agent 怎么分工、怎么交接、谁来兜底这事儿比你想的更像管理一个真实的团队。关于 ArchAIHarness这篇文章是「看懂 AI 与智能体」专栏的一部分由ArchAIHarness持续输出。ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产主张架构师定义秩序AI 在秩序中生长。人立法AI 执行体系审计。如果你也希望 AI 在明确的架构边界内协作而不是在混沌中碰运气欢迎到 GitHub 上看看我们在做什么组织主页github.com/ArchAIHarness — 了解完整理念与资产全景本专栏zhuanlan-ai-and-agents— 所有文章的源码与发布记录实践指南docs— 架构哲学、工程方法和落地指南开源工具agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools工程样例framework— DDD AI 协作的工程底座展示如何在开发中融合 AIEngineered by Architects · Empowered by AI · Audited by Discipline