知识库答非所问，问题多半不在模型

搭知识库的人最后都会遇到同一幕：明明文档就在库里，它答的却是别的东西，或者干脆编一段。换更大的模型往往没用——瓶颈常在切分、召回和文档的生命周期管理上。这个专题把踩过的坑按环节拆开，每个都给出可点开的原始出处。

相关搜索：AI 知识库 · 企业知识库 搭建 · RAG 答非所问 · 知识库 切分 · 本地知识库 部署 · 知识库 检索 不准

用户到底在抱怨什么

chunk 切太小，一个条款被拆成三块

有团队做合同审查，chunk_size 设成 200，结果一条完整的「违约责任」被切成三段，模型只看到其中一段，自然理解不了全貌，给出的判断看起来像在胡说。切分参数不是调优项，它直接决定模型「能看到什么」——切错了，后面再强的模型也只能瞎猜。

有个客户做合同审查，chunk_size设了200。结果一个完整的“违约责任”条款被切成3块，AI只看其中一块，理解不了全貌。 —— 腾讯云开发者社区：企业 RAG 落地踩的 7 个坑（20 个客户经验）

搜编号、型号、法条号，关键词那一路直接失效

纯向量检索对「第 130 条」「RTX 4090」「GB/T 19001」这类精确字符串很不友好：语义相近的段落会挤掉真正匹配的那一条。有人测完 Dify 的多种检索模式后直接提了 issue：关键词检索经常召回不到，底层用的还是通用分词。企业知识库里最常被搜的恰恰是这类精确词，所以混合检索（向量 + BM25）不是加分项，是及格线。

I have found that keyword retrieval often fails to recall. —— Dify issue #5076：Full text search keyword search enhancement

旧文件排在新文件前面，模型就拿旧规回答

一个风控系统的真实事故：知识库里 2023 新规和 2021 旧规同时存在，用户问最新指标，模型答了旧数字。原因不玄：旧文件措辞更贴合用户说法，向量相似度反而更高，于是旧片段排到了前面。模型没有「时效」这个概念，你给它什么顺序，它就信什么顺序。

旧文件措辞更直接匹配了用户用语，而新文件用了一些新术语，向量相似度得分反而略低 —— 人人都是产品经理：知识库「保鲜」困境——如何避免旧知识干扰回答质量

检索没找到东西，它照样给你一段答案

RAGFlow 的一次安全修复写得很直白：当工具执行失败或返回空上下文时，Agent 会编一个答案出来。这是 RAG 最危险的一种失败——空检索本该回答「没找到」，结果它用模型的记忆补了一段，用户还以为是从你的文档里查出来的。知识库的可信度，全押在「没依据就闭嘴」这一条上。

the Agent hallucinate an answer if tool execution fails or returns an empty context —— RAGFlow PR #14305：empty retrieval 时的编造问题（源自内部 mini-audit）

文档删了，索引里还留着

有人提交了一个很要命的问题：删除文档时只删了文档行，没有删它的 chunk 和元数据记录，于是检索仍然能把已删除的内容召回出来。对知识库来说这不只是脏数据——员工离职了、合同作废了、文件按合规要求删除了，答案里还在引用它。「删」必须是删干净：文档行、切片、向量、缓存，一处都不能剩。

RemoveDocumentKeepFile deletes the document row but not its chunk data or metadata record —— RAGFlow issue #20659（2026-10）

法务不肯签字：不知道它凭什么这么说

一家公司的法务团队直接拒绝使用这套系统，理由只有一句：AI 说这个条款有风险，但不知道它凭什么这么说，怎么敢签字。这不是「解释性」这种虚词，而是签字责任的要求——每一句结论必须能点到原文的那一段、那一页。做不到溯源，知识库就只能当玩具，进不了任何需要签字的流程。

AI说这个条款有风险，但我不知道它凭什么这么说，我怎么敢签字？ —— 同上，企业 RAG 落地踩的 7 个坑

能解决这些痛点的开源项目

• RAGFlow（自托管）— 中文场景里解析与切分做得比较细的自托管方案：按文档类型配置切分模板，检索带引用定位，能直接看出答案来自哪一段。 痛点标签：中文文档、检索/识别准、数据不出内网、团队共享。注意：组件多（向量库、解析服务、模型服务），内存开销大；升级前先看 changelog，切片结构改过几次。
• Dify（自托管）— 把知识库接进工作流最省事的一条：检索节点、重排、条件分支都是可视化配置，适合非工程团队自己搭问答应用。 痛点标签：部署简单、团队共享、中文文档。注意：关键词检索这一路偏弱（issue #5076），编号/型号类查询要自己加重排或接外部全文索引。
• AnythingLLM（桌面端）— 桌面端零代码起步：拖文件建工作区，接本地模型或云端 API 都行，适合先验证「这套文档能不能答对」再决定上线。 痛点标签：本地离线、部署简单、数据不出内网。注意：个人/小组够用；文档量大之后检索与权限都吃紧，别拿它当企业知识库。
• MinerU（本地离线）— 入库前的解析环节。页眉页脚、双栏、表格这些噪声清不干净，检索就会被噪声占据——先把 PDF 转成干净的结构化文本，再谈切分。 痛点标签：中文文档、检索/识别准、本地离线、批量稳定。注意：解析是 CPU/GPU 重活，几百份要排队；扫描件效果取决于清晰度。
• Qdrant（Docker）— 自建向量库的稳妥选择：过滤条件（部门、密级、有效期）与向量检索一起下推，做「只能搜自己有权看的」这类限制时比纯向量库省事。 痛点标签：数据不出内网、团队共享、部署简单。注意：只管向量；分片、副本、磁盘规划要自己算，数据量上来后调参是体力活。
• pgvector（Docker）— 已经有 Postgres 的话，加个扩展就有向量检索，事务和权限沿用原来的——数据治理最容易落地的一条路。 痛点标签：部署简单、数据不出内网、团队共享。注意：千万级向量以上，索引构建与查询会明显吃力；HNSW 参数没调好，召回率悄悄掉。

常见问题

换个更强的模型，答非所问就好了吗？

多数情况下不会。答非所问通常是「检索给错了材料」，模型只是忠实地把错材料组织成通顺的句子。先看检索命中：把同一个问题跑出来，看召回的片段里到底有没有答案——没有，换模型也白搭。

一定要加重排（rerank）吗？

中文企业文档里基本是必须的。向量相似度对「第 130 条」「A-2023-08」这类精确字符串不敏感，重排模型能把真正匹配的那一条提到前面。代价是每问一次多一次模型调用，延迟翻倍。

文档更新了，怎么防止旧版本被引用？

靠流程，不靠模型。给每份文档加版本与有效期字段，新版本入库时把旧版标记为废止并移出检索范围，检索时按有效期过滤。指望 embedding 自己分辨「哪版作废」是不现实的——它只算相似度，不懂时效。

怎么验收一个知识库到底行不行？

准备 50 个真实问题，每题写明「答案在哪份文档哪一段」。跑一遍，算两个数：命中率（检索有没有捞到那段）和拒答率（没有依据时有没有老实说不知道）。只看前者会奖励瞎编的模型，两个一起看才有意义。

本地部署的知识库，效果会比云端差很多吗？

检索层本地化几乎不损失什么；生成层用本地小模型，长文归纳和中文表达会弱一些，但「只依据材料回答」这一类任务够用。真正的差距不在模型大小，在解析与切分的工程质量。

最后更新 2026-11-06。内容基于公开讨论与项目公开文档整理，不构成采购建议；价格与配额随时可能变，下单前请自行核对。