元数据与文档管理:过滤、引用与权限的根基

01-RAG基础与架构 核心 约 15 分钟 #元数据#过滤#权限#文档管理 更新 2026-10-02
当前状态:未学
本文基于模型知识整理(生成时未联网核对),关键结论建议对照经典文献复核。

一句话定义

元数据是附着在每个块上的结构化信息(来源、标题、章节、时间、部门、权限、版本),它让检索从"全库语义匹配"升级为"先按结构条件圈定范围、再语义匹配",同时支撑引用展示、增量更新与权限隔离。

为什么重要

只有向量的 RAG 是"失忆的全库模糊搜索":无法回答"只在 2024 年政策里找""只搜我部门可见的文档"这类天然需求,也无法输出可信引用。元数据是 RAG 从 demo 走向生产系统的分水岭——权限与合规(kp-030)完全建立在它之上。

前置知识

kp-002、kp-005(解析产物是元数据的来源)。

核心概念

  • 来源标识:文档 ID、文件名、URI、页码/位置——引用展示与人工核查的依据。
  • 结构信息:文档类型、章节路径(如"员工手册 > 考勤 > 年假")、条款号——天然的范围过滤器与分块边界。
  • 时间信息:创建/生效/失效时间——支持"最新版优先"与时效过滤(kp-029)。
  • 权限标签:可见部门、密级、租户 ID——检索前的硬过滤(kp-030)。
  • 质量控制:解析置信度、语言、chunk 哈希——支持降权与增量更新比对。

原理与机制

过滤检索(filtered retrieval / pre-filtering vs post-filtering):先按元数据条件筛选候选集再做向量检索(pre-filter,主流向量库支持),或先向量检索再剔除(post-filter)。pre-filter 的语义正确但可能因过滤后候选太少导致召回不足;post-filter 会浪费 top-k 名额并可能全部被滤光。混合方案:带过滤的 ANN 检索 + 保底数量回退。

元数据越丰富,查询理解越重要:"去年Q3华东区的退货政策"里的时间、地域、主题三类约束应被解析成元数据过滤条件 + 语义查询两部分——这一步叫元数据抽取/查询路由,可由小模型或规则完成。做不好它,元数据就只是死数据。

存储位置:元数据与向量同库(便于联合查询,主流向量库皆支持 payload/filter)或分离(元数据在关系库,向量库只存 ID)——前者工程简单,后者适合复杂权限模型(继承、ACL 图)。

图示

chunk = { id, text, embedding,
          meta: { doc_id, uri, page: 12, section: "考勤>年假",
                  doc_type: "policy", effective: 2024-01-01,
                  dept: "HR", tenant: "acme", ocr_conf: 0.97 } }
查询: "年假规定" + filter(dept=HR, tenant=acme, effective<=today)
     → 向量检索在过滤后的子集上进行

实例或案例

  • 法务系统按"合同类型 + 签署年份"过滤后再语义搜索条款。
  • 多产品线客服:product 标签保证 A 产品的问题不会命中 B 产品手册(否则噪音严重)。
  • 引用展示:"《员工手册》第 3 章第 2 节(更新于 2024-06)"——全部来自元数据拼接。

常见误区

  • 误区一:"元数据以后再补"。回填历史索引成本极高(等于重建),schema 必须在首版索引前定好,宁多勿少。
  • 误区二:"post-filter 凑合用"。k 个结果滤完可能剩 0 个,用户体验是随机空答;必须 pre-filter 或带回退策略。
  • 误区三:"权限过滤放在生成层"。检索层不看权限 = 越权内容已进入上下文,有泄露事实;过滤必须在检索前完成(kp-030)。

与其他知识点的关系

  • kp-010:混合检索中元数据过滤与关键词检索的配合。
  • kp-029:增量更新以 doc_id/哈希为键。
  • kp-030:权限是元数据的最高优先级用途。
  • kp-022/025:图检索同样按元数据(节点标签、时间)裁剪子图。

自测题

  1. pre-filtering 与 post-filtering 的取舍?

答:pre-filter 语义正确、支持先圈范围,但过滤后候选少时召回下降;post-filter 简单但浪费 top-k 且可能滤空;生产多用 pre-filter + 保底回退。

  1. 为什么权限过滤必须在检索层做?

答:生成层过滤意味着越权内容已进入模型上下文,存在泄露与"答案提及"事实;检索前硬过滤才能从根上阻止。

  1. 举三个"查询应被拆成语义+元数据过滤"的例子要素。

答:时间(去年Q3→effective 范围)、组织(华东区→region 标签)、类型(退货政策→doc_type=policy)。

延伸阅读

  • Pinecone/Qdrant/Milvus 文档:filtering 与 payload 设计。
  • LlamaIndex 文档:Metadata Filters 与 auto-retriever。
  • AWS Builders' Library 关于企业搜索权限修剪(permission trimming)的文章。