正在加载，请稍候
企业知识库 AI 检索不到内容，多数时候不是模型的问题，而是检索链路的问题。本文拆解分块、混合检索、重排、查询改写、权限隔离、评估集 6 个环节的典型失败点与可落地修复路径。
一家制造企业把 200 万 token 的售后手册接进知识库 AI 后，用户问"设备异响怎么处理"，回答却指向了"保养周期表"。这是今年（2026 年 8 月）企业知识库 AI 项目里反复出现的场景。先别急着换模型——大部分"答非所问"发生在模型看到内容之前，也就是检索链路。
成本模型变了。InfoQ 在 AICon 2026 的直播讨论中提到，从今年 6 月 1 日起，主流 AI 编程与推理工具开始全面转向 token 消费制，企业 AI 成本从订阅制变成按量计费；平凯数据库（TiDB）智能研发中心负责人柏佳辰在同一场讨论里说，金融行业客户"每人每月大概几百美金预算，只有少部分人用光"。预算收紧之后，检索不到内容意味着每次回答都要靠多轮重试补齐，token 和人工成本同时放大。InfoQ AICon 2026 直播实录把这背后的组织适配问题讲得很细。
另一条线是 Agent 工程对"上下文"的重新定义。LangChain 在 8 月发布的生产级 Agent 案例里，monday.com Sidekick 的复盘明确提出"capable agents need more than just tools"——工具之外，上下文、权限、记忆才是决定成败的部分。LangChain 官方博客同期也在讨论"你的 Agent 调用里有多少真的需要前沿模型"。企业知识库 AI 本质上是把"上下文"做对，检索质量就是上下文工程的地基。研发团队用 Agent Memory 终结口口相传的落地实录，讲的就是记忆与上下文如何变成生产系统的一部分。
最常见的切法是按固定字符数切，比如 500 字一刀。结果一段完整的"故障处理流程"从中间被切断：前半段落在第 42 个分块，后半段落在第 43 个分块。向量检索按相似度取 top-k 时，两个分块各自只命中一半语义，模型拿到的都是残片，自然拼不出完整答案。
这个问题的解法在 2024 年就被 Anthropic 讲清楚了：Contextual Retrieval 提出在切分时把文档级上下文（这条内容属于哪个章节、主题是什么）注入每个分块，检索命中率明显提升。Anthropic 工程博客把这件事归入更系统的"上下文工程"（Effective context engineering for AI agents）。我们自己的项目也是这么改的：先按 Markdown 标题边界切，再给每个分块补一行来源上下文，检索质量立刻上了一个台阶。从 RAG 到 Agent 原生记忆的演进，可以看这篇企业知识库 AI 三代演进。
def split_by_structure(md_text, max_chars=800):
segments, buf = [], []
for line in md_text.splitlines():
if line.startswith("#"): # 标题边界是语义边界
if buf:
segments.append("\n".join(buf))
buf = [line]
else:
buf.append(line)
# 超长段落再按句子边界补切，避免把流程从中间砍断
return segments企业知识库和公开网页不一样：同一份合同有 v1/v2/v3，同一篇制度在不同部门各存一份，还有大量带权限的机密内容。全部塞进同一个向量索引，旧版本和重复文档会抢占 top-k；更麻烦的是机密内容先被召回、再在应用层拦截，等于把敏感信息过了一遍模型上下文，既浪费 token 又有泄露风险。
今年企业客户对这块尤其敏感。InfoQ 的 AICon 讨论里提到，金融行业客户的流程自动化和互联网公司不一样，有大量需要人审批的阶段，组织协同问题会通过产品层暴露出来。权限隔离不应该事后补，而是索引设计的一部分：权限标签写进 metadata，检索时用 filter 硬过滤，至少把公开区与内部区拆成两个 collection。
纯向量检索对专有名词、型号、编号很弱。用户搜"型号 XH-200 的报警代码 E12"，向量可能匹配到语义相近的"设备告警处理"，而精确关键词"XH-200"在倒排索引里一查就中。生产环境的主流做法是混合检索：向量召回 + BM25 关键词召回，合并去重后再进入下一环节。向量库规模上去之后，HubSpot 语义搜索的架构案例值得对照。从 Demo 到 200 亿向量的演进讲的就是这一步怎么撑住。
from rank_bm25 import BM25Okapi
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("BAAI/bge-large-zh-v1.5")
def hybrid_search(query, segments, k=20):
q_vec = model.encode([query])[0]
vec_scores = [cosine(q_vec, model.encode([s])[0]) for s in segments]
bm25 = BM25Okapi([s.split() for s in segments])
bm25_scores = bm25.get_scores(query.split())
# 两路分数各自归一化后加权合并，再取 top-k
merged = [0.5 * v + 0.5 * b for v, b in zip(norm(vec_scores), norm(bm25_scores))]
return [s for _, s in sorted(zip(merged, segments), reverse=True)[:k]]向量检索的 top-k 按 embedding 相似度排序，但 embedding 相似不等于"回答这个 query 最有用的片段"。企业知识库里一个 query 往往只有一两段是正确答案，其余是相关但无用的噪音。不加重排，模型要么被不相关片段带偏，要么把多个片段的信息错误拼接。Anthropic 在 2025 年 9 月的上下文工程文章里，把 rerank 列为上下文工程的必要组件，我们验证下来确实如此：加一个 cross-encoder 重排（bge-reranker 这类），只取 top-3 进上下文，宁可少喂，不要喂错。更多检索链路的工程取舍，参考这篇企业知识库 AI 搭建实战。
用户提问是口语、短句、带指代："上次说的那个方案还有效吗？"直接拿这句去做向量检索，效果可想而知。企业知识库用户不会像工程师一样精确提问，查询改写应该成为检索链路的一环：补全指代、扩展同义词、拆出关键实体，改写后的 query 再进检索。注意改写本身也要控成本，短 query 用轻量模型即可。
这是我们见过最多的隐形坑：团队花两周调切分参数、换 embedding、加重排，效果"感觉好了一点"，但拿不出数据。企业知识库的检索质量必须有评估集：50-100 条真实用户 query，配上标注好的标准答案段落。每次改动跑一遍，记录命中率和首答正确率，才能判断改动是正向还是负向。另一个团队把同类坑踩了一遍后的复盘，见检索增强生成落地五个坑。
eval 已经是 Agent 工程的标配。Anthropic 工程博客从今年 1 月起连续发布 eval 相关文章（"Demystifying evals for AI agents""Designing AI-resistant technical evaluations"），LangChain 也把 Evaluation 列为核心产品线。DeepSeek 在 8 月开源 Harness 时，模型、工具、Agent Loop 全部插件化——InfoQ 报道里强调的可插拔思路，恰恰说明没有评估集的 Agent 链路是无从优化的。先建 eval set，再谈优化；每次改动记录三个数：命中率、MRR、端到端首答正确率。
| 坑 | 典型症状 | 修复路径 | 优先级 |
|---|---|---|---|
| 分块切碎语义 | 回答只有半个流程 | 语义切块 + 上下文注入 | P0 |
| 索引混入噪音 | 旧版本/重复文档抢占 top-k | 去重 + 权限过滤 | P0 |
| 纯向量检索 | 型号、编号、专有名词搜不到 | 向量 + BM25 混合检索 | P1 |
| 无重排 | 上下文被噪音带偏 | cross-encoder rerank | P1 |
| 无查询改写 | 口语问法命中率低 | LLM 查询改写 | P1 |
| 无评估集 | 改完无法回归，全凭感觉 | eval set + 指标 | P0（最先做） |
大部分无关。检索链路（切分、索引、召回、重排）决定模型能看到什么，模型只负责把看到的内容组织成答案。先修检索，再谈换模型，顺序反了预算就白花了。
中文场景先看评测，BGE/M3E 这类开源模型在中文长尾上够用。重点是 embedding 要和文档的语言、领域一致，并且和整条检索链路一起评测，不要单独看单点分数。
会有少量开销，但通常可接受。两路召回加合并排序在百万级分块内是毫秒级；真正的延迟大头在重排和 LLM 生成，不在召回。
索引层。权限标签写进元数据，检索时用 filter 过滤，比应用层事后过滤更安全——避免机密内容先被召回再被拦截，既省 token 又降低泄露风险。
如果你的知识库 AI 也遇到"答非所问"或"检索不到内容"，欢迎把具体场景发给我们，蓝曜炬辉（www.lanyaoai.com）可以基于你现有的文档结构做一次检索链路诊断，先看数据，再定方案。