先把结论甩这儿RAG答非所问、答得驴唇不对马嘴十有八九不是模型笨、也不是提示词没写好是根本没召回到对的那段文字。别急着调 top_k、调温度、换 rerank 模型,先去看一眼——你问的那条信息,到底有没有被切进某个 chunk 里、那个 chunk 又有没有被检索出来。覆盖率不查清楚,后面所有调参都是在给一口空锅加调料。事情是这么来的。上个月我给团队搭了个查内部制度的问答助手,把公司那堆 SOP、报销规则、请假流程的 Word 一股脑塞进知识库。前两天测着挺好,问出差住宿标准多少答得有模有样。结果周五财务那位姐过来问我:年假到底能不能跨年用? 我对着助手敲进去,它跟我扯了一通调休和病假的区别,就是不提跨年那茬。我又换了三种问法,年假结转没休完的年假今年的假明年还能不能用,一个比一个答得离谱。当时我第一反应也是俗套——提示词不行?加了句请严格依据知识库内容回答。没用。换了个更大的模型,也没用。把 top_k 从 3 拉到 8,它倒是开始引用更多内容了,但还是没引到点上。折腾到晚上九点多,我才想起来该回去看数据本身。把那份《考勤管理办法》的切片结果导出来扒了一遍,傻眼了。年假未休完的,可顺延至次年3月31日前使用这句关键的话,正好卡在两个 chunk 的接缝上——前半句年假未休完的在上一片的结尾,可顺延至次年在下一片的开头。我按默认的 512 字符定长切的,一刀切下去,把唯一能回答这个问题的句子劈成了两半。检索的时候,谁都凑不齐完整语义,自然召回不到。说白了,答非所问的源头在切和召回这两步,根本轮不到生成那一步背锅。我之前一直盯着生成端调,纯属南辕北辙。后来我把排查顺序固定成了三步,谁再跟我说 RAG 不准,我都先让走一遍:步骤查什么怎么判断1. 覆盖率用户问的事实,在原文里有没有、被切进哪个 chunk关键句被切断 必坏,先修切分2. 召回拿真实问题去检索,目标 chunk 在不在 top_k 里不在 召回问题,跟生成无关3. 生成chunk 召回对了,模型答得对不对到这步才轮到调提示词/换模型第一步最容易被跳过,偏偏踩坑最多。我后来粗粗统计了下手头几个案子,大概七成的答非所问,卡在第一步——要么原文压根没这信息(用户以为有),要么被切分切碎了。切分这块我后来改成了按语义/段落切,加了点重叠(overlap),让相邻 chunk 首尾各兜一截,接缝处的句子至少有一片是完整的。年假那条立马就召回对了。这事也让我对先验证数据,再怀疑模型这句老话服气了。值得说一嘴的是,这套排查我没自己写一行召回脚本去跑。我搭助手用的是那种零代码就能配智能体的平台,拖一拖配一配——挂个现成大模型、传一批文档当私有知识库,十几分钟一个能问答的小助手就出来了,不用碰向量库、不用自己写 chunk 逻辑。它自带的检索调试视图能直接看到每次召回了哪几片、相似度多少,我就是靠盯着那个面板才揪出接缝切断这毛病的。当然也不是没短板。默认的定长切分就坑过我(上面那茬);第一版机器人答得特别干,跟背条文似的,得自己补几轮提示词调语气;文档一多,后台索引要等个把分钟。这玩意儿擅长把搭骨架、配召回、发布成接口这些杂活包圆,真正答得准不准,八成功夫还是在你喂进去的数据和切分上——工具替不了你理解业务。所以下次再遇到 RAG 胡说八道,别下意识去拧生成端那几个旋钮了。先导出切片,拿真问题跑一遍召回,看目标那段文字到底在不在 top_k 里。覆盖率这关过不了,调参全是白费。你们踩过最离谱的 RAG 召回坑是啥?是切分切断、还是原文压根没那信息、又或者 embedding 选错了?评论区聊聊,我猜被切分坑过的不止我一个。(模型这层我直接走的讯飞星辰 MaaS,现成大模型 API 调用,没自己部署算力,省了一大截事)
