把 AI 知识库想象成一座图书馆每个术语都好懂了事情是从一句话开始的。有一天我问了自己测试平台上的知识库一句话购物车去结算有哪些规则这一句问答系统想了十分钟才给我最终的回答。十分钟够泡两碗面还有富余。为什么会这么慢呢于是我把整套知识库从上到下拆了一遍才总算看清楚了这十分钟到底花在哪儿了。这套逻辑有个正式名字叫 RAG检索增强生成。听着很专业但如果要用大白话来解释就一句话相当于给 AI 配了一座图书馆。接下来我们就把知识库比喻成一座图书馆然后把图书馆里的每个岗位都挨个分析介绍一遍。RAG里那些拗口的名词大部分都能在这些岗位身上对上号。顺便把平时工作中或者面试的时候最可能碰上的两个问题我们也一并聊了如果RAG知识库检索慢慢在哪可以怎么入手优化如果RAG知识库答得不准从哪查怎样才能让它更准RAG是什么先说RAG到底能解决什么问题。用 AI 的人早晚都可能会碰上下面这两个糟心场面一个是你问公司内部的事它训练时都是用的网上公开的资料公司内部的它压根没见过问了也白问。另一个更气人它明明不知道却硬答编得煞有介事行话管这个叫幻觉。2020年Facebook的AI团队拉上两家大学发了篇论文给的解法特别朴素别指望模型什么都记住答题之前先去资料库翻一遍把翻到的材料跟问题一起递给它让它照着材料说话。换成图书馆的画面是这样的你提一个问题馆里几个岗位同时忙活。有人按意思找书有人按字眼查目录有人把按意思和按字眼查出来的两份名单合到一起给出候选的书还有人把候选的书逐本翻开细读最后挑出最像的几页递给 AI。AI拿着这几页纸组织成人话还给你。先检索再增强后生成三个动作连起来就是 RAG 这个缩写的意思检索增强生成。现在市面上带知识库三个字的 AI 产品跑的差不多都是这个流程我们平台也是。文档分块AI答得好不好很多时候不止看它多聪明还要看这座图书馆往它手里递了什么材料。先说书是怎么进图书馆的。你往知识库里传文档图书馆里不会整本收。一本五百页的手册塞给AI它读不完也用不着。文档在进门之前会先被裁成一段一段通常几百字一段。这个动作有正式名字文档分块英文里叫chunk。切法也有讲究 切太碎一句话被拦腰截断谁都看不懂。 切太粗一段里揉进三个话题找起来也费劲。这个也有个正式名字分块大小。每个文本块的最大字符数值小一点对应可以提高检索精度值大一点对应可以保持上下文完整性通常建议值1000-2000。而相邻的两个分块之间要有重复的字这样可以避免跨块信息丢失保持上下文连续这个叫分块重叠通常建议为分块大小的10-20%。嵌入模型书拆好了有请第一位员工导购。这位导购的本事是懂内容。你提问怎么把商品买了他不纠结字眼直接给你抽出那本写着去结算的小册子。一个词都对不上但他知道是一回事。他干活的办法是给每段话算一串数字通常几百上千个我们平台的模型算出 1024 个。你把这串数字当成这段话的坐标就行意思越近的两段话坐标挨得越近。你提问的时候问题也会被算成同样的坐标然后满馆去找最近的段落。这位导购术语叫嵌入模型。我们平台用的嵌入模型是 bge-m3跑在本机的一个 Ollama 服务里。那串坐标叫向量。整套找法叫语义检索也叫稠密检索。BM25 关键词检索算法光靠导购找有一个坑。你要是问一个错误码或者一个产品型号这种问题字面就是命根子导购那种凭意思找人的路数反而容易飘。所以馆里还备着一位老派管理员他不管你什么意思只认字。你报几个词他去目录里查哪个册子里有这些词按三条规矩打分词出现得越多分越高但有上限防着有人堆关键词。词越稀有越值钱满页都是结算两个字的时候赠品两个字的分量格外重。书太厚要吃亏两万字的书里出现三次不如三百字小册子里出现两次。这套规矩来自一个叫 BM25 的老算法上世纪九十年代的产物到今天还是搜索行业的标配。它的家当我翻过全部加起来 120KB一个词表几个参数跑了三十年…老派管理员这一路术语叫:关键词检索。相对于导购的稠密它有个别称叫:稀疏检索。RRF 倒数排名融合算法和混合检索现在导购和老派管理员这两个员工各交了一份名单得有人把这两份名单合成一份。这活归前台主管。两份合成一份难点是两个人给的分数不是一个体系老派管理员给的是分数可能是 12.5、8.3、6.1……没有上限纯粹是数的词算出来的。导购的给的是语义相似度0.87、0.72……余弦相似度范围 0~1 。直接相加毫无意义就像把 “考试排名第3” 和 “体重60公斤” 加起来。这时候前台主管想出了一个非常巧妙的思路分数没法比那就干脆不比分数只看名次。规则就一条一份材料在每份名单里拿 1 除以 60 加它的名次两边加起来就是总分。第1名拿分最多往后递减。那个 60 是论文作者试出来最稳的数。我拿真实数据算过两路都排第一的满分。一路第二、一路第五的0.96。只在导购那路排第三的0.48。里面有条规律很有意思两路都排第十名的得分比只在单路排第一的还高。它根本不理会谁在单张名单上写了第一名它奖励的是两个人同时点头的材料。这就是这套合并算法的灵魂奖励共识而不是奖励单方面的自信这套合并算法叫RRF倒数排名融合算法。两路一起用是目前主流知识库的常见配置术语叫混合检索。Reranker精排名单合完还有最后一道工序 有请馆里最资深的老馆员他负责的这道活行内叫精排。这位是较真的主。他把问题和候选材料配成对一本书一本书翻开逐字读判断这本册子跟提问到底像不像。细是真细代价也白纸黑字 假设有15份候选材料在普通CPU上读完则需要 30 秒左右。而且他排队一次只读一份你发再多查询后面的也只能排着。他为什么不用前面算坐标的快办法因为配对着逐字读才准而准是拿慢换的。他的正式名字叫Reranker中文叫重排序底层技术叫 cross-encoder交叉编码。名字不用背你记住这位老馆员的脾气就行 他最贵最慢。老馆员读完排出最终名次最靠前的几页交给 AI。到这里你回头看RAG 这个词就对全了前面所有找材料的活计加起来是检索。把材料拼进提问、递给 AI是增强。AI 照着材料把答案写出来是生成。top_k接着上面的两份名单合并说一下另一个术语top_k。两份名单合并完不是一股脑全往下送。从名单头上往下数数到第几名打住这个数就是: top_k中文名叫检索数量。top_k值越大送到下一个环节老馆员手里的候选数量就越多。值越小检索时间越快可你要的那份如果排在了名单后头就会被一刀裁掉根本检索不出来。值越大压箱底的好材料有更多机会冒头代价是老馆员桌上更厚得多读几轮时间跟着涨。所以它不是越大越好。答案经常在明面上的知识库top_k值可以小一点省时间。题目刁钻、材料分散经常得翻到七八名开外的知识库top_k值就得适当调大给它留足位置。这个数值值得拿你自己的问题来回试。相似度阈值这个值得单独细说它特别容易设错。老馆员读完每本册子得到一个相关度的分出口立着一条线分数低于线的直接淘汰不进最终名单。这条线就是相似度阈值。我们平台默认的 0.3。在混合检索这套打法里出来的分数普遍偏高0.3 形同虚设几乎什么都拦不住。得拧到 0.55 往上它才开始干正事确实不相关的材料真的被挡在了外面。但这条线不能一路往上拧。拧太狠正确的内容容易被误拦。有些材料分数不高可它偏偏就是你要的你的问法和文档里的写法差得远分数天然就低。一刀切掉AI 手里就空了材料不够它就开始自己编。你觉得它答得一本正经但全是胡话很多时候就是这条线拧过了头。拧太松是另一种病名单里混进一堆边角料AI 写出来的答案也跟着掺水。所以这条线没有标准答案得拿你自己的问题试。挑几个你门儿清答案的问题把线一点点往上拧看它什么时候开始缺料什么时候开始胡说中间那段就是你该停的地方。RAG知识库响应慢怎么解决接下来聊两个实际问题先说它为什么慢。我们平台实测过负责精排的老馆员在岗的时候那句问答跑了十分钟。让老馆员下班一分钟就给出了答案。九成的时间就耗在他一个人身上。所以知识库慢第一个要看的八成是Reranker精排。它是整个流程里最贵的环节CPU 上每批 30 秒起步还得排队一次问答多查几轮时间直接就乘上去了。怎么处理大致有三条路可以试。第一条路关闭Reranker精排服务用不上就关掉坦率的讲我知道很多人舍不得Reranker这东西听着就高级。但说实话它在很多场景里的对回答内容的质量提升有限。关掉前后那两版答案我摆在一起对比过核心规则覆盖得一样多细节上互有胜负。而关掉之后省下的是几乎全部的时间。Reranker 只决定排序不决定能不能检索到。比如你提问购物车去结算的规则有哪些购物车去结算本身就是强关键词BM25 向量检索已经把这个模块的文档排到了前面精排的增量价值空间本来就不大。同时对于规则梳理这类任务LLM 需要的是相关材料足够而不是第一名必须最准。那什么时候 Reranker 才真正有价值呢主要有3种场景知识库很大、大量相似文档多版本、近义表述互相干扰。查询模糊抽象如这个系统有什么风险关键词匹配不上靠语义精排。要求严格取 top 1~2 条且必须最相关的场景。第二条路必须要用Reranker那就换硬件一样的活给它配张显卡。把重排模型从 CPU 挪到 GPU 独立显卡上算。同样的计算GPU 通常快 50~100 倍单次 35 秒 变成 1 秒以内。这下知道为什么AI时代英伟达市值一路狂飙了吧…第三条路控制检索次数重复问题的结果缓存起来一次问答未必只查一次资料。系统可能会把问题改写一遍再查一次次数直接翻倍。AI 还爱顺藤摸瓜查完主干觉得不过瘾再追加几轮。它倒是尽责但每一轮都要重新排队耗时蹭蹭蹭就上去了。能做的两件事一是给检索设个轮数上限比如最多检索2次仅在首次结果明显不相关时允许补充检索 1 次。二是把重复问题的结果缓存起来通过把用户问题 → 检索到的材料这份对应关系存起来。将查询文本规范化去首尾空格、统一大小写 知识库 ID top_k 阈值 设计为Key存在Redis里面。下次同样的问题进来直接取上次的结果返回省掉 “嵌入 → 向量数据库检索 → RRF 融合 → Reranker” 这一整条链路。RAG知识库回答不准确怎么解决回答慢的问题说完了再说回答得不准的问题。第一个嫌疑人文档分块。前面说过它是老底子。一段话被拦腰截断或者一段里揉进好几个话题后头的人再聪明也找不回来。我的建议是先看它检查分块大小、分块重叠设置得是否合理调整对应的值。它出问题后面做什么都白搭。它没问题再往下查也不迟。第二个相似度阈值。检索结果要过一道相似度阈值才留下。比如我们平台默认的 0.3 形同虚设混合检索的模式下几乎什么都拦不住。设到 0.55 往上它才开始干正事。太紧会误杀好材料太松等于不设。这个数得拿你自己的多个问题反复试出来。第三个top_k。检索数量很重要。top_k值设置的是3但是和问题最相关的规则却排在第5位直接被砍掉了检索不出来。所以回答不准先别急着换模型看看手里的产品能不能调检索条数。检索数量设置五条还是十条值得你试。第四个Reranker精排。精排不是万能药它的主场是大知识库、老资料、说得含糊的问题。库大文档彼此长得像提问又模糊它上场回答准确度的差距马上出来。库小问题清晰它的用武之地本来就不多关了也不可惜。最后说个大动作能不碰就不碰换嵌入模型。换嵌入模型等于把整座图书馆的坐标系换掉所有藏书都得重新编目也就是整个知识库重新向量化一遍。真要换挑数据不怎么动的时候干干完确认没有新老坐标混着用。还有个不花钱的招提问方式。用文档里本来就有的行话去问命中率比大白话高得多。你想要什么尽量用它自己存资料时用过的词。写在最后RAG这套东西并不是什么魔法。简单来说就是图书馆里各个岗位的员工各干各的活。一旦发现出了毛病就有一个地方要背锅。以后碰到 AI 回答的内容离谱先不要着急骂模型。按着岗位一个个盘问过去chunk–分块有没有切坏嵌入模型–导购有没有找错了top_k–检索数量是不是设置得太小了相似度阈值–门槛是不是设置得太高了BM25–老派管理员关键词检索是不是眼花了Reranker–负责精排的老馆员是不是压根没上班文章最开始提到的我们的测试平台知识库提问系统想了十分钟才回复我最后排查下来是因为中间花了 16 次检索而Reranker精排老馆员每次都把 15 份材料从头读一遍一遍都没歇。尝试直接关闭掉Reranker精排服务后再次检索几秒就响应完了速度提升了不止10倍并且回答的内容和开启Reranker基本没有什么差别。这就是前面说的知识库体量小问题清晰Reranker的用武之地本来就不多关了也不可惜还能省下大把的时间。下次你的 AI 答得离谱或者慢得没边先别急着换大模型。想想那座馆。是不是精排老馆员一个人在扛所有的活是不是有张卡片在进门的时候就被裁坏了是不是门槛设错了把好材料全拦在了外面一个一个看过去就好。以上既然看到这里了如果觉得不错随手点个赞、在看、转发三连吧欢迎关注下方我的公众号程序员杨叔各类文章都会第一时间在上面发布持续分享各类测试开发知识干货。谢谢你看我的文章我们下次再见