上周一个朋友跟我吐槽他们公司上了个知识库系统花了小十万结果员工还是到处问人。搜年假怎么休系统返回100条结果排第一的还是个过期政策。我说你这不叫知识库叫文件陈列馆。这不是个例。我接触过好几个想做知识库问答的团队初期都信心满满觉得把文档扔进去AI就能答。结果上线后被吐槽最多的就是——“搜出来的东西太没用了”。今天聊聊我是怎么用Agent方案把这个事情翻盘的。FAQ搜索的三宗罪先说传统FAQ搜索为什么不行。第一关键词匹配太死板。员工问离职手续怎么办系统只认离职这个词。如果问的是辞职流程或者怎么办理离职匹配度直接掉一半。第二语义理解约等于零。搜年假几天能返回关于年假的所有政策——包括2018版的、2021版的、还有草案版的。系统完全不知道用户要的是最新有效政策。第三没有上下文意识。同一个问题这个能报销吗用在差旅报销和用在设备采购上答案完全不一样。但传统搜索不管这些它就按关键词相关性排。我改成了AgentRAG的方案后来我给这个系统动了个手术把底层搜索从关键词匹配换成了AgentRAG架构。结构其实不复杂用户提问 ↓ Agent理解意图是查政策/问流程/还是找文档 ↓ RAG检索向量检索 BM25混合 ↓ 召回结果给AgentAgent判断是否匹配 ↓ 综合回答如果不够Agent触发追问或改写查询第一步让Agent先理解意图这是最关键的一步。传统搜索一上来就搜关键词而Agent的方案是先判断用户到底想问什么。比如用户输入那个费用怎么报传统搜索搜费用→ 返回100条包含费用的结果Agent方案先判断→历史对话中用户在聊差旅报销→将查询改写为2024年差旅费报销流程和标准→然后才去检索这个查询改写的效果非常明显。我实测下来检索命中率从51%提升到了83%。代码大概长这样不复杂defrewrite_query(user_input:str,context:dictNone)-str:根据对话上下文改写用户查询promptf 用户提问{user_input}对话上下文{上次聊的是差旅报销ifcontext.get(topic)travelelse无}请将这个模糊的问题改写成标准的知识库查询语句。 直接输出改写后的查询语句不要解释。 returnllm.chat(prompt)第二步混合检索兜底改写后的查询我用的是稠密向量 BM25混合检索。说实话一开始我只用了向量检索因为觉得这玩意儿先进。结果翻车了——向量检索对专有名词和新词特别不敏感。比如搜《绩效管理办法2025修订版》向量检索可能把办法和修订分开理解了匹配到很多不相关的文档。加了一层BM25全文检索做互补之后召回率从62%提升到了89%。defhybrid_search(query:str,top_k:int10)-list:# 向量检索vector_resultsvector_db.search(query,top_ktop_k)# BM25全文检索bm25_resultsbm25_db.search(query,top_ktop_k)# RRF合并排序combinedrrf_merge(vector_results,bm25_results)returncombined[:top_k]RRFReciprocal Rank Fusion合并算法是关键公式不复杂但效果比简单取交集好很多。第三步Rerank提纯精排检索召回了一堆候选但排前面的不一定是最相关的。我加了Cross-Encoder做重排序效果立竿见影——首条回答的准确率从43%跳到了78%。fromsentence_transformersimportCrossEncoder rerankerCrossEncoder(BAAI/bge-reranker-v2-m3)defrerank_results(query:str,candidates:list)-list:pairs[[query,doc[text]]fordocincandidates]scoresreranker.predict(pairs)fordoc,scoreinzip(candidates,scores):doc[rerank_score]scorereturnsorted(candidates,keylambdax:x[rerank_score],reverseTrue)这里有个坑Rerank模型的推理速度比向量检索慢一个数量级。所以我只对top-20的候选结果做重排序不做全量。20条Candidate的重排序耗时大概在200-300毫秒可以接受。第四步Agent整合回答检索到内容后Agent负责组装答案。不是简单地复制粘贴而是提取与问题最相关的段落整合多个来源的信息加入时间标注这个政策是哪年出的如果不够完整主动追问用户比如员工问我今年能休几天年假Agent会回答“根据《员工考勤管理制度2026版》第4章第2条累计工作满1年不满10年的员工年休假为5天。你的入职时间是2024年3月目前工龄2年所以今年可以休5天。需要帮你提交休假申请吗”看到了吗这不是简单的搜到答案念出来而是理解整合行动建议。上线后的真实效果跑了3个月几个数据供参考回答准确率从传统搜索的67%→92%用户满意度从3.2/5→4.6/5人工咨询量减少了约40%IT和HR部门的反馈响应时间平均2-3秒用户基本无感知最让我意外的是员工搜索找不到答案的场景反而暴露了知识库本身的缺口。有几个月度数据发现某类问题检索为空率特别高——追查发现是某份政策文件漏上传了。所以AgentRAG方案还有个隐藏价值帮知识库补坑。哪些场景不适合说了这么多好处也得坦白说说不适合的场景。高频、极简问答比如几点下班→ 直接写死在规则里不要上RAG成本高收益低需要强权限控制的场景→ RAG的文档级权限控制目前还不够成熟实时性要求极高秒级必须出结果→ 如果没有GPU加速RAG的检索速度可能不够写在最后我折腾这个项目最大的感受是不是技术难而是把技术组合好难。向量检索、Rerank、查询改写——单独看都是成熟技术。但把它们串成一个流畅的Agent工作流需要考虑大量边界情况查不到怎么办、查太多怎么办、回答有冲突怎么办。做AI产品的人最常犯的错就是高估模型能力、低估工程复杂度。我那朋友后来看了改造后的效果也决定把他们的知识库重做一遍。他说了一句话我觉得挺对的“花十万买个搜索系统不如花两万做个聪明的Agent。”有问题评论区交流或者你们有什么好的知识库方案也可以分享。