知识库问答翻车了？我的Agent方案比传统FAQ搜索强在哪

上周一个朋友跟我吐槽：他们公司上了个知识库系统，花了小十万，结果员工还是到处问人。搜"年假怎么休"，系统返回100条结果，排第一的还是个过期政策。

我说：你这不叫知识库，叫文件陈列馆。

这不是个例。我接触过好几个想做知识库问答的团队，初期都信心满满，觉得"把文档扔进去，AI就能答"。结果上线后被吐槽最多的就是——“搜出来的东西太没用了”。

今天聊聊我是怎么用Agent方案把这个事情翻盘的。

FAQ搜索的三宗罪

先说传统FAQ搜索为什么不行。

第一，关键词匹配太死板。
员工问"离职手续怎么办"，系统只认"离职"这个词。如果问的是"辞职流程"或者"怎么办理离职"，匹配度直接掉一半。

第二，语义理解约等于零。
搜"年假几天"，能返回关于"年假"的所有政策——包括2018版的、2021版的、还有草案版的。系统完全不知道用户要的是最新有效政策。

第三，没有上下文意识。
同一个问题"这个能报销吗"，用在差旅报销和用在设备采购上，答案完全不一样。但传统搜索不管这些，它就按关键词相关性排。

我改成了Agent+RAG的方案

后来我给这个系统动了个"手术"：把底层搜索从关键词匹配换成了Agent+RAG架构。

结构其实不复杂：

用户提问 ↓ Agent理解意图（是查政策/问流程/还是找文档？） ↓ RAG检索（向量检索 + BM25混合） ↓ 召回结果给Agent，Agent判断是否匹配 ↓ 综合回答（如果不够，Agent触发追问或改写查询）

第一步：让Agent先理解意图

这是最关键的一步。传统搜索一上来就搜关键词，而Agent的方案是先判断"用户到底想问什么"。

比如用户输入"那个费用怎么报"：

• 传统搜索：搜"费用"→ 返回100条包含"费用"的结果
• Agent方案：先判断→历史对话中用户在聊差旅报销→将查询改写为"2024年差旅费报销流程和标准"→然后才去检索

这个查询改写的效果非常明显。我实测下来，检索命中率从51%提升到了83%。

代码大概长这样，不复杂：

defrewrite_query(user_input:str,context:dict=None)->str:"""根据对话上下文改写用户查询"""prompt=f""" 用户提问：{user_input}对话上下文：{'上次聊的是差旅报销'ifcontext.get('topic')=='travel'else'无'}请将这个模糊的问题改写成标准的知识库查询语句。 直接输出改写后的查询语句，不要解释。 """returnllm.chat(prompt)

第二步：混合检索兜底

改写后的查询，我用的是稠密向量 + BM25混合检索。

说实话，一开始我只用了向量检索，因为觉得这玩意儿"先进"。结果翻车了——向量检索对专有名词和新词特别不敏感。

比如搜"《绩效管理办法（2025修订版）》"，向量检索可能把"办法"和"修订"分开理解了，匹配到很多不相关的文档。

加了一层BM25全文检索做互补之后，召回率从62%提升到了89%。

defhybrid_search(query:str,top_k:int=10)->list:# 向量检索vector_results=vector_db.search(query,top_k=top_k)# BM25全文检索bm25_results=bm25_db.search(query,top_k=top_k)# RRF合并排序combined=rrf_merge(vector_results,bm25_results)returncombined[:top_k]

RRF（Reciprocal Rank Fusion）合并算法是关键，公式不复杂，但效果比简单取交集好很多。

第三步：Rerank提纯精排

检索召回了一堆候选，但排前面的不一定是最相关的。

我加了Cross-Encoder做重排序，效果立竿见影——首条回答的准确率从43%跳到了78%。

fromsentence_transformersimportCrossEncoder reranker=CrossEncoder("BAAI/bge-reranker-v2-m3")defrerank_results(query:str,candidates:list)->list:pairs=[[query,doc['text']]fordocincandidates]scores=reranker.predict(pairs)fordoc,scoreinzip(candidates,scores):doc['rerank_score']=scorereturnsorted(candidates,key=lambdax:x['rerank_score'],reverse=True)

这里有个坑，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秒，用户基本无感知

最让我意外的是：员工搜索"找不到答案"的场景，反而暴露了知识库本身的缺口。有几个月度数据发现，某类问题检索为空率特别高——追查发现是某份政策文件漏上传了。

所以Agent+RAG方案还有个隐藏价值：帮知识库"补坑"。

哪些场景不适合

说了这么多好处，也得坦白说说不适合的场景。

• 高频、极简问答（比如"几点下班"）→ 直接写死在规则里，不要上RAG，成本高收益低
• 需要强权限控制的场景→ RAG的文档级权限控制目前还不够成熟
• 实时性要求极高（秒级必须出结果）→ 如果没有GPU加速，RAG的检索速度可能不够

写在最后

我折腾这个项目最大的感受是：不是技术难，而是"把技术组合好"难。

向量检索、Rerank、查询改写——单独看都是成熟技术。但把它们串成一个流畅的Agent工作流，需要考虑大量边界情况（查不到怎么办、查太多怎么办、回答有冲突怎么办）。

做AI产品的人最常犯的错就是高估模型能力、低估工程复杂度。

我那朋友后来看了改造后的效果，也决定把他们的知识库重做一遍。他说了一句话我觉得挺对的：“花十万买个搜索系统，不如花两万做个聪明的Agent。”

有问题评论区交流，或者你们有什么好的知识库方案也可以分享。