3 常见的 Metadata 有哪些
P0 · rag
🏷 标签：rag, metadata, classification
1️⃣ 考察意图
面试官想看你是否理解元数据（Metadata）在 RAG 系统中不是“可有可无的标签”，而是检索精度和过滤效率的核心杠杆。考察类型是系统设计 + 工程取舍。刁钻点在于：很多人只会背“描述性、结构性、管理性”的分类，但答不出为什么选这个字段而不选那个，以及元数据如何影响检索召回率和排序。答好了能展示你对 RAG 整条链路（从数据预处理到检索后过滤）的掌控力，以及从业务场景反推技术选型的硬实力。
2️⃣ 标准答
RAG 中的 Metadata 不是简单的“标签”，而是结构化索引的骨架。按功能可分为四类，每类有明确的工程取舍：
描述性元数据（Descriptive）
- 字段：标题、作者、摘要、关键词、语言、文档类型（PDF/网页/代码）。
- 为什么重要：在向量检索中，这些字段可直接用于预过滤（Pre-filtering）。例如，只检索“作者=张三”的 chunk，能大幅缩小搜索空间（从 100 万降到 1 万），提升召回速度 10 倍以上。
- 取舍：存储成本 vs 检索效率。每多一个字段，索引体积增加约 20%（以 HNSW 为例），但过滤后延迟降低 50%。实际落地：只索引高频过滤字段（如语言、文档类型），低频字段（如摘要）用倒排索引（BM25）单独存储。
结构性元数据（Structural）
- 字段：章节标题、段落编号、文档层级（H1/H2/H3）、页眉页脚、表格/图片位置。
- 为什么重要：解决“chunk 碎片化”问题。例如，一个 chunk 只包含表格的一部分，通过“表格 ID”元数据，检索后能合并完整表格，避免信息断裂。
- 坑 + 解法：PDF 解析时，表格可能被分页切割。解法：用 LayoutLM 或 pdfplumber 提取表格边界，在 chunk 中记录“表格起始页”和“表格结束页”，检索时按元数据合并。
管理性元数据（Administrative）
- 字段：创建时间、修改时间、版本号、权限（RBAC 标签）、来源（文件路径/URL）、数据质量评分（如 OCR 置信度）。
- 为什么重要：支撑时效性过滤和权限控制。例如，法律文档只检索“版本号=最新”的 chunk，避免引用过时条款。
- 取舍：时间戳精度 vs 更新成本。精确到秒的更新时间需要每次写入时计算，增加 5% 延迟；而按天精度可缓存，但可能漏掉同一天更新的文档。实际落地：对高频更新文档（如新闻）用秒级，对静态文档（如手册）用天级。
领域特定元数据（Domain-Specific）
- 字段：医疗（ICD-10 编码、诊断日期）、法律（案号、法条编号）、金融（股票代码、财报季度）、电商（SKU、价格区间）。
- 为什么重要：直接提升检索的业务相关性。例如，医疗问答中，通过“ICD-10 编码”过滤，能排除无关科室的文档，召回率提升 30%（【通用知识】）。
- 坑 + 解法：自动提取准确率低。解法：用正则 + 微调 BERT（如 BioBERT）做 NER，先提取候选字段，再用规则校验（如 ICD-10 编码格式为字母+数字），准确率可达 95%。
总结：元数据选择遵循 80/20 法则——80% 的检索提升来自 20% 的高频过滤字段。先按业务场景列出 Top-5 过滤条件（如“只查 2024 年后的中文法律文档”），再反推元数据字段，避免过度设计。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从描述性、结构性、管理性、领域特定四个层面回答。描述性元数据（如标题、作者）用于预过滤，结构性元数据（如章节标题）解决 chunk 碎片化，管理性元数据（如时间戳）支撑时效性控制，领域特定元数据（如 ICD-10 编码）提升业务相关性。总结一句：元数据不是越多越好，而是按检索过滤频率选 Top-5 字段，用 20% 的字段覆盖 80% 的检索场景。”
4️⃣ 高频追问 & 应对
追问 1：如果元数据字段很多，怎么设计索引结构？
用混合索引策略。高频过滤字段（如语言、文档类型）直接嵌入向量索引的 Filter 层（如 Pinecone 的 metadata filter），低频字段（如摘要）用倒排索引（BM25）单独存储。查询时先做预过滤（高频字段），再对结果做后过滤（低频字段）。取舍：预过滤减少搜索空间，但后过滤增加排序延迟。实际落地：监控过滤命中率，若后过滤丢弃超过 30% 的结果，则将该字段升级为预过滤字段。
追问 2：元数据提取错误怎么处理？
分两层处理。第一层：提取时用置信度阈值（如 OCR 置信度 < 0.8 的字段标记为“低质量”），在检索时排除低质量 chunk。第二层：检索后做元数据校验（如 ICD-10 编码格式检查），若发现错误，回退到 BM25 检索（不依赖元数据）。取舍：校验增加 10% 延迟，但避免错误过滤导致召回率下降 20%。实际落地：对关键字段（如法律案号）做强制校验，对非关键字段（如作者）不做校验。
追问 3：元数据更新了，历史 chunk 怎么办？
用版本化索引。每个 chunk 记录“元数据版本号”，查询时只检索版本号匹配的 chunk。更新时，对受影响 chunk 做增量重建（只更新元数据字段，不重新 embedding），减少 90% 的计算成本。取舍：版本号增加索引体积 5%，但避免全量重建。实际落地：用 Apache Kafka 监听元数据变更事件，触发增量更新。
5️⃣ 避坑 · 常见错误答法
- ❌ 只背分类（“描述性、结构性、管理性”），不举具体字段名和工程取舍。 → ✅ 每个分类至少给 2 个具体字段（如“标题、作者”），并说明为什么选这个（如“标题用于预过滤，作者用于权限控制”）。
- ❌ 说“元数据越多越好”，忽略存储和检索成本。 → ✅ 强调“80/20 法则”，只索引高频过滤字段，低频字段用倒排索引。
- ❌ 不提元数据提取的坑（如 OCR 错误、PDF 表格切割）。 → ✅ 主动暴露坑（如“PDF 表格被分页切割”），并给解法（如“用 LayoutLM 提取表格边界”）。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“元数据如何提升检索召回率”切入，举例你项目中用“时间戳”过滤后，召回率从 70% 提升到 85%。
- 如果你只做过传统 NLP：用“实体识别”类比元数据提取，说你用正则 + BERT 提取 ICD-10 编码，准确率 95%。
- 如果你是校招无项目：聚焦“元数据分类的论文复现”，说你读过《Metadata for Retrieval-Augmented Generation》的博客，并自己实现了一个基于 LangChain 的元数据过滤 demo。
- 《Metadata for Retrieval-Augmented Generation: A Practical Guide》（博客）
- 《Hybrid Search: Combining Vector and Keyword Search with Metadata Filtering》（论文）
- 《LayoutLM: Pre-training of Text and Layout for Document Image Understanding》（论文）
- 《Pinecone Metadata Filtering Documentation》（工具文档）
- 《Apache Kafka for Real-Time Metadata Updates》（技术博客）