Wiki Notes

Appearance

知识库与检索 ​

这一组内容聚焦的是：怎样把企业知识、文档、规则、历史记录和检索链路做成真正可用的 RAG 基础设施，而不是只堆一个向量库就宣称“知识库做完了”。

如果你已经理解了 RAG / Embedding / Token / Evals 的基础能力，这一组就是从工程落地角度回答“知识到底怎么进、怎么查、怎么控、怎么治理”的地方。

很多知识库项目粗糙，不是因为没有资料，而是因为它们只覆盖了“怎么搜”，没有把下面这些问题连起来：

  • 什么知识值得先入库
  • 文档怎么拆成可检索对象
  • 检索如何同时兼顾关键词、语义、过滤和权限
  • 结果怎么带引用、怎么处理冲突、怎么判断失效
  • 回答出错后怎么追回到数据、索引和流程 owner

OpenAI Retrieval / File search / Embeddings、Azure AI Search Hybrid search / Relevance overview、Pinecone Data modeling / Multitenancy / Production checklist、Weaviate Hybrid search / Multi-tenancy 的当前资料，都在指向同一条主线：

真实 RAG 不是一个“问答接口”，而是一条从知识对象治理到检索证据消费的完整工程链路。

1. 这一组内容主要解决什么 ​

知识库系统最常见的失败，不是模型不够强，而是下面这些问题没有被系统化处理：

  • 文档进库没有清洗、切片和 metadata 设计。
  • 检索只做语义向量，不做关键词、过滤、重排和证据打分。
  • 多租户、权限、版本、失效和审核流没有建模。
  • 线上答错后没有纠错闭环、对账机制和冷启动策略。
  • 证据和答案之间没有可追溯关系，导致事故后无法复盘。

OpenAI File search 当前官方说明已经明确提到它会同时使用语义检索和关键词检索；Azure AI Search 当前把 hybrid + semantic reranker 作为高相关性主路径；Pinecone 和 Weaviate 当前都在强调 metadata、租户隔离、多向量和数据模型。这说明真实知识库的核心，不只是“向量召回”，而是：

  • 数据对象设计
  • 索引与过滤
  • 权限与隔离
  • 证据与引用
  • 评测与治理

2. 这组内容应该怎么读 ​

2.1 想先把一个基础 RAG 系统搭出来 ​

  1. 企业知识库与文档流水线专题
  2. 向量数据库专题
  3. 长文本切片策略专题
  4. 混合检索优化专题
  5. 检索证据打分专题

2.2 想补“检索为什么答不稳” ​

  1. 检索查询改写专题
  2. 混合检索优化专题
  3. 引用冲突消解专题
  4. 结构化引用设计专题
  5. RAG失败复盘专题

2.3 想补“企业知识治理”这条线 ​

  1. AI知识运营专题
  2. AI知识版本化专题
  3. 知识权限继承专题
  4. 知识变更审核流专题
  5. 企业知识纠错闭环专题
  6. 企业知识对账专题

2.4 想补“权限、隔离与合规” ​

  1. 知识权限继承专题
  2. 多租户架构专题
  3. 企业权限模型专题
  4. AI治理与审计专题

3. 这组专题可以分成哪几层 ​

3.1 数据进入系统之前 ​

这一层关心的是：什么数据该进来、以什么粒度进来、多久更新、什么时候淘汰、冷启动先覆盖哪些高价值内容。

3.2 数据如何被表示和索引 ​

这里解决的是 chunk、embedding、索引结构、namespace、metadata、版本和回收策略。

Pinecone 当前官方资料特别强调不要把所有数据都堆在一个 namespace 再用大规模高基数 ID 过滤兜底；Azure AI Search 和 Weaviate 的资料也都说明，检索质量往往取决于索引设计、字段设计和搜索策略组合，而不只是向量本身。

3.3 查询如何被理解和排序 ​

Azure AI Search 当前把 hybrid search 定义为并行执行全文检索和向量检索，再做结果融合；Weaviate 当前把 hybrid search 解释为并行跑 BM25 与 vector search；OpenAI File search 当前也说明它会结合 semantic 与 keyword signals。对企业检索来说，这背后的启发很明确：

企业问题往往同时需要概念相似、关键词精确、过滤条件命中和结果重排。

3.4 结果如何进入答案和治理闭环 ​

这一层更偏“结果可信度”，也就是怎么给证据、怎么处理冲突、怎么判断过期、怎么把错答案追回到文档、切片、检索和排序环节。

3.5 治理和组织协同怎么接上 ​

这一层解决的是 owner、审批、回归、审计、SLA、值班和跨团队协同。没有这一层，知识库很容易停留在“技术 Demo 成功，但运营不可持续”。

4. 真实知识系统里最值得先建立的几个共识 ​

4.1 知识库不是文档仓库，而是可检索知识对象集合 ​

只有原始文件，没有 chunk、metadata、owner、版本、权限和状态，就还不算真正可治理的知识库。

4.2 混合检索通常比纯向量更接近生产现实 ​

OpenAI File search 当前官方说明已经明确提到它会同时使用语义检索和关键词检索。Azure AI Search 也把 hybrid search 作为高相关性方案的核心路径。对企业数据来说，产品名、工单号、规则编号、时间范围和组织权限都很难只靠向量检索解决。

4.3 权限应该进入检索链路，而不是事后补过滤 ​

如果权限只在最终答案层兜底，检索阶段已经可能把不该出现的内容拿进上下文。知识权限继承、租户隔离、namespace 设计和 metadata filtering，最好从索引阶段一起考虑。

4.4 RAG 答错，通常不是单点错误 ​

错误可能来自：

  • 数据没进库
  • 切片粒度不对
  • metadata 缺失
  • 查询改写跑偏
  • 排序规则不稳
  • 引用设计太弱
  • 过期知识没有被剔除

所以这组内容的重点，不只是“检索怎么配”，更是“怎么追责到具体环节”。

4.5 知识系统要按对象治理，而不是按回答幻觉治理 ​

如果只盯住“模型答错了”，团队很容易不停改 Prompt，却看不到真正的问题在：

  • 文档对象设计不一致
  • 版本状态不清楚
  • 引用粒度过粗
  • owner 缺失
  • 回收机制缺失

从知识对象开始治理，后面的检索、引用和答复稳定性才会真的提升。

4.6 检索前权限通常比答案后脱敏更关键 ​

Azure AI Search 当前 Document-Level Access Control 的官方资料明确强调：

  • 权限约束应该从数据摄取一直贯穿到查询执行

Weaviate 当前文档则明确把 filters 作为检索链路的一部分，并说明过滤发生在搜索之前。两者放在一起看，结论很直接：

  • 如果权限只在最终答案层再兜底，问题已经晚了

更稳的做法通常是：

  • 检索前先按 tenant / user / group / domain 做边界过滤
  • 检索后再决定结果怎么展示、怎么脱敏、怎么带引用

这也是为什么知识权限继承、多租户设计和 metadata filtering，不该被当成“安全附录”，而应该算知识检索主链路的一部分。

4.7 数据新鲜度不是“同步任务跑没跑完”，而是“查询到底看到了哪一版” ​

Pinecone 当前官方资料在 data modeling、check data freshness、delete records 等页面都反复提醒：

  • Pinecone 是 eventually consistent
  • 写入、更新、删除之后，查询结果不一定会立刻看到最新状态

这类提醒很重要，因为很多知识事故并不是：

  • 数据没有更新

而是：

  • 数据源已经更新
  • 索引任务也跑了
  • 但查询窗口里仍然混着旧版本结果

所以企业知识系统里更值得单独治理的是：

  • 当前 query 命中的 chunk 属于哪个版本
  • 这批 upsert / delete 的可见性窗口有多长
  • 旧版本残留是不是还会污染 top-k

4.8 agentic retrieval 和 classic RAG 不是同一层复杂度 ​

Azure AI Search 当前官方资料已经明确区分：

  • agentic retrieval
  • classic RAG

这给知识系统设计带来一个很实用的启发：

  • 不是所有检索系统一开始都要做 agentic retrieval

如果你的场景更强调：

  • 查询路径清晰
  • 结果融合简单
  • 编排可控

那 classic RAG 往往更稳。

而如果你的场景更强调：

  • 复杂问题拆解
  • 多轮检索
  • 结构化返回和引用细节

那 agentic retrieval 才更值得引入。

也就是说，知识系统不应该只问“召回对不对”，还要问：

  • 检索过程是不是也需要被编排成显式工作流

5. 先做知识库时，建议按什么顺序推进 ​

5.1 第一步：先定义知识对象 ​

先回答：

  • 一条知识的最小单位是什么
  • 它属于哪个系统、哪类文档、哪个 owner
  • 什么场景下算过期
  • 是否涉及权限或租户边界

5.2 第二步：再决定怎么切、怎么存 ​

包括：

  • chunk 规则
  • 父子关系
  • 版本策略
  • metadata 字段
  • namespace 或 tenant 设计

5.3 第三步：再决定怎么检索 ​

包括：

  • 是否先上 hybrid
  • 哪些 query 要改写
  • 哪些字段要过滤
  • 是否引入 rerank 或 evidence scoring

5.4 第四步：最后接答案消费 ​

包括：

  • 结果如何附引用
  • 冲突证据如何处理
  • 失败答案如何回收
  • 用户反馈如何回流到知识治理

这个顺序的核心是：

先治理知识对象，再治理检索链路，最后治理答案体验。

5.5 第五步：最后再接线上回流和运行闭环 ​

很多团队前四步都做了，但系统还是越跑越乱，根因通常是：

  • 线上失败样例没有回到评测集
  • 文档更新和索引更新没有统一对账
  • 检索问题只能在工单里被描述，回不到 chunk / filter / version

所以落地时最好把最后一步也补上：

  • 失败 query 回流
  • top-k 与引用留存
  • 文档 / chunk / 版本追溯
  • 纠错工单和知识 owner 绑定

如果没有这一步，知识库更像一次性交付；有了这一步，它才开始变成可运营系统。

6. 做知识库最值得跟踪的指标 ​

下面这张表更适合企业知识系统，而不只是简单问答 Demo：

指标想回答什么问题常见 owner
入库覆盖率高价值知识是否进来了知识运营 / 业务 owner
新鲜度达标率当前命中的知识是不是过期了内容 owner / 平台
权限误召回率是否召回了不该看的内容安全 / 平台
引用附着率答案是否能给出证据应用团队 / RAG 团队
检索命中率分桶哪类 query 最容易失败检索评测团队
纠错闭环时长一条错知识多久能修回去运营 / 平台
版本残留率更新后旧 chunk 是否还污染结果索引流水线 owner
新鲜度可见时延数据变更后多久能被查询稳定看到索引流水线 / 平台
权限过滤命中率检索前过滤是否真的按预期生效安全 / 平台

6.5 这些指标最好按 query 类型分桶 ​

如果所有检索指标只看总平均值，团队通常会漏掉最有价值的问题：

  • 编号类 query 和自然语言问句的失败原因不同
  • FAQ 类 query 和长文 grounding 的失败原因不同
  • 高权限内容和公开内容的过滤代价不同

更有用的分桶通常包括：

  • 精确关键词型
  • 模糊概念型
  • 多条件过滤型
  • 时间 / 版本敏感型
  • 高权限内容型

只有分桶以后，团队才知道：

  • 到底是召回策略不对
  • 还是数据对象设计不对
  • 还是过滤把结果池压空了

7. 发生知识事故时，怎么追 ​

推荐用下面这个排障顺序：

  1. 先找回答使用了哪几个 chunk。
  2. 反查这些 chunk 属于哪个父文档、哪个版本、哪个 owner。
  3. 检查是不是召回错了，还是引用错了，还是排序错了。
  4. 检查 query 是否带了错误 filter / namespace / tenant。
  5. 再判断是数据源错误、切片错误、索引错误，还是生成层规则错误。

如果你的系统还做不到这条追踪链，说明知识治理还没真正成型。

8. 哪些场景最容易把知识库做歪 ​

  • 只有文件上传，没有知识对象和版本治理。
  • 只有语义检索，没有关键词、过滤和权限设计。
  • 只做问答效果演示，不做证据留存与回放。
  • 把所有知识混在一起，不做租户、域、部门隔离。
  • 文档更新后只增量追加，不清旧版本。
  • 用户反馈只落工单，不回到知识对象和评测集。
  • 把权限放在答案层兜底，而不是在检索前就限制结果池。
  • 只看“同步成功”，不看更新后结果多久对查询真正可见。

8.5 还有一个很常见的误区：把“向量检索”当成唯一主语 ​

OpenAI File search、Azure AI Search hybrid + semantic ranking、Weaviate pre-filtering 的官方资料都在提醒：

  • 真正的企业知识检索链路从来不是只有向量这一段

它更像：

  • query understanding
  • keyword / vector / hybrid candidate generation
  • filtering
  • ranking / reranking
  • evidence packaging
  • answer consumption

如果把所有问题都归因成“embedding 不够强”或“向量库选得不对”，团队很容易在错误层上持续优化。

9. 推荐搭配阅读 ​

10. 重点官方资料 ​

以下入口在 2026-07-08 检查时可访问：