RAG 知识库问答详解从最小链路到企业落地前言Agent 基座系列第十一篇也是收官篇。企业里最常被提的需求是「让 AI 回答内部知识」——制度文档、操作手册、历史方案。把文档直接塞给模型问和搭一套 RAG是两条完全不同的路。这篇讲清楚为什么、怎么做、怎么评估。一、为什么长上下文代替不了 RAG模型上下文窗口已经很大为什么不直接把文档全塞进去维度全量塞上下文RAG成本每轮对话都带全量文档费用随文档量线性涨只带命中的几个切片质量文档越多「大海捞针」衰减越明显检索先过滤生成聚焦时效文档更新要重新喂只更新向量库权限全量在上下文里没法按人裁剪检索时按人过滤最后一条是决定性的企业知识几乎都有权限边界薪酬制度、合同模板、部门规范全量进上下文等于人人可见全部。第四篇的铁律在这里同样成立权限过滤要发生在检索层不能寄希望于模型「看到了也当没看到」。二、最小链路切片、向量化、检索、生成五十行以内可以跑通的核心链路# 1. 切片按二级标题切超长再按段落细分defchunk(doc):sectionssplit_by_heading(doc,level2)return[sforsinsectionsiflen(s)MAX_CHUNK]# 2. 向量化入库文本本体 权限元数据ids[f{doc_id}-{i}fori,cinenumerate(chunks)]collection.add(idsids,documentschunks,metadatas[{doc:doc_id,acl:doc_acl(doc_id)}]*len(chunks))# 3. 检索问题取 top-k带权限过滤hitscollection.query(query_texts[question],n_results5,where{acl:user_dept})# 过滤发生在检索层# 4. 生成命中内容作为上下文要求标注来源promptf仅依据以下资料回答资料里没有就明确说不知道。 资料{hits}问题{question}四个环节里最不被重视、但最影响效果的是第 1 步切片——模型和向量库都只是放大器切片决定了每块语义的完整性。三、企业化改造权限、更新、混合检索最小链路跑通后三件事决定它能不能上线权限过滤做进检索层切片入库时带 ACL 元数据部门/密级查询时where条件过滤。和管理体系打通的最简方式权限矩阵单独一张表维护入库和查询都查它——文档权限变更时改表即可不用重灌向量库知识更新要有生命周期文档下架、改版对应切片要同步删除/更新。常见的烂法是「文档早改了向量库里还是老版本AI 一本正经地答旧制度」——给每条切片记 source 和版本定期全量校验一次混合检索纯向量检索对专有名词、编号、缩写很不友好形如Q3-OPS-017的查询向量化后语义模糊。加一路关键词检索BM25两路结果合并去重。内部知识库恰恰专有名词密度最高这步基本不能省。四、效果评估没有测试集就没有调参RAG 调优最怕「改了个参数感觉好像好了一点」。先建测试集eval_set[{q:年假怎么折算,should_hit:hr/leave-policy-v3.md},{q:服务器登不上去找谁,should_hit:it/helpdesk.md},# 几十条起步高频问题 边角问题 知识库里故意没有的问题]两个指标hitktop-k 检索结果里是否包含正确文档——衡量「找没找到」答案质量人工抽评或用模型按「忠实于资料 / 是否拒答」打分——衡量「答没答对」。第三类测试别漏知识库里没有的问题系统会不会老实说不知道。检索强行捞回不相关切片、模型硬答是 RAG 最损信任的失败模式。—### 五、进阶混合排序与多轮检索第三节的三件套解决上线这一节解决「上线后检索质量上不去」1.RRF两路结果的合并公式向量和 BM25 两路结果的分数不可比余弦距离 vs 词频分直接加权是玄学。倒数排序融合RRF只用排名不用分数python def rrf(rankings, k60): # rankings: 每路一个 [doc_id, ...] 按相关性排好 scores {} for ranking in rankings: for rank, doc in enumerate(ranking, 1): scores[doc] scores.get(doc, 0) 1 / (k rank) return sorted(scores, keyscores.get, reverseTrue)不用调权重、对分数分布不敏感是混合检索合并的默认起点。2.rerank用精度换延迟召回 top50 → cross-encoder 逐对精排 → 取 top5 进上下文。召回层向量BM25求快求全精排层求准。代价是每次多几十对的推理适合「召回质量到顶、答案还是不准」的阶段再加别第一天就上。3.多轮对话先改写再检索第二轮问「那它的替代品呢」——「它」检索不到任何东西。先用模型把当前问题结合历史改写成自包含问题指代消解补全省略再进检索管线。一次便宜的调用多轮场景召回提升立竿见影——和踩坑清单里「问法改写」是同一个思想的两处应用在检索前把问题变好检索。4.GraphRAG 一句话定位把文档抽成实体关系图再检索适合「A 的上游供应商是谁」这类关系型查询。普通知识问答用不上别为跟风引入图数据库——先把 RRF 和 rerank 做扎实。—### 六、踩坑清单切片粒度太小单句语义不完整命中也没法答太大整章检索不准且挤占上下文。经验起点 300–800 字符 按标题边界切宁可切大不切断一张表格表格是重灾区Markdown 表格从中间切开两半都废掉。处理表格整体不切或转成「每行一条记录」的文本再入库问法和写法不一致文档写「终端设备」用户问「电脑」。缓解检索前用模型把口语问题改写成文档用语——一次便宜的调用召回提升明显PDF / 扫描件版面解析会丢表格、乱阅读顺序先解析再入库别直接抽文本塞进去不要追求一步到位先小范围上线一个部门、一类文档用第四节的测试集滚动评估再逐步扩。参考资料Anthropic 工程博客Contextual RetrievalChroma 向量库文档本系列第四篇《让 AI 直接连数仓》—— 权限过滤的同款思路