元数据的必要性
在 RAG（检索增强生成）系统中，仅将文档切分为纯文本块（Chunk）会导致以下严重问题：
-
缺乏可信度（无法溯源）：用户询问规则依据时，系统只能回答内容，无法提供出处（文档名、章节、页码），导致答案缺乏公信力。
-
安全隐患（权限失控）：不同部门/角色的敏感信息（如薪酬、财务数据）若未标记权限，可能被无权限员工检索到，造成数据泄露。
-
维护困难（难以纠错）：当发现答案过时或错误时，由于缺乏来源标识和位置信息，无法在海量文本块中快速定位并修正特定 Chunk。
解决方案 ：为每个文本块附加元数据。元数据不参与语义向量化，但在检索前后的过滤、排序、引用生成及运维管理中起关键作用。
定义
-
定义：给每个 Chunk 贴上的"标签"，如同书的封面、目录和版权页。
-
流程位置 ：位于分块（Chunking）之后 ，向量化（Embedding）之前。
-
数据结构示例
{ "content": "文本内容...", "metadata": { "doc_id": "唯一标识", "source_url": "原文链接", "file_name": "文件名", "title": "章节标题", "page_number": 页码, "created_at": "创建时间", "department": "所属部门", "access_roles": ["允许访问的角色"], "start_offset": 0, "end_offset": 58 } }
常见元数据字段
元数据的必要性
1、 文档标识类 (基础必备)
字段：doc_id (唯一ID), source_url (访问链接), file_name (文件名)。
作用：
溯源：生成引用链接，让用户查看原文。
管理：用于文档去重、版本更新（批量删除旧 doc_id 的块）。
建议：几乎所有场景必须包含。
2、结构信息类 (提升体验)
字段：h1_title, h2_title, page_number (页码)。
作用：
精准引用：回答时显示"依据《手册》第二章 2.1 节"，而非模糊的"依据《手册》"。
排序优化：概述性问题优先展示高层级标题内容。
建议：适用于有明确章节结构的文档（PDF, Word, Markdown）。
3、时间版本类 (确保时效)
字段：created_at, updated_at (系统自动生成); effective_date (生效时间), expiration_date (失效时间)。
作用：
过滤过时信息：检索时自动排除已失效的政策或活动规则。
版本追踪：了解知识的演变历史。
建议：适用于政策、产品手册等随时间变化的知识。
4、 权限控制类 (安全保障)
字段：access_roles (角色), access_departments (部门), sensitivity_level (敏感等级), ACL (访问控制列表)。
作用：
检索前过滤：在向量数据库检索阶段，根据当前用户身份过滤掉无权限的 Chunk，从源头防止泄露。
粒度控制：支持基于角色、部门、用户或敏感级别的组合控制。
建议：企业内部知识库必须实施，公众知识库可省略。
5、 位置追溯类 (运维纠错)
字段：start_offset, end_offset (字符位置), chunk_index (序号)。
作用：
快速定位：发现错误内容时，直接映射回原文的具体位置进行修正。
上下文分析：便于查看相邻 Chunk 的内容。
建议：需要人工审核或高准确率要求的场景推荐包含。
6、 业务自定义类 (场景扩展)
字段：product_category (商品类目), tech_stack (技术栈), priority (优先级) 等。
作用：满足特定业务的过滤和排序需求（如优先展示高优先级规则，或限定特定技术栈的回答）。
建议：按需添加，避免冗余。
| 优先级 | 字段类型 | 典型字段 | 适用性 |
|---|---|---|---|
| 必须 | 文档标识 | doc_id, file_name |
所有场景 |
| 必须 | 权限控制 | access_roles, access_departments |
内部知识库 |
| 推荐 | 结构/位置 | title, page_number, offset, chunk_index |
需引用/纠错场景 |
| 推荐 | 时间版本 | created_at, updated_at |
动态知识场景 |
| 可选 | 业务自定义 | category, priority |
特定业务需求 |
| 可选 | 时效控制 | effective_date, expiration_date |
强时效性政策 |
元数据字段添加方案
1、少即是多 (Less is More)
只添加对检索过滤、结果展示、运维管理有实际帮助的字段。
过多的元数据会增加存储成本、维护难度并可能降低检索性能。
2、粒度匹配业务
公众文档：只需标识和结构信息。
内部知识库：必须包含权限、时间版本和位置追溯信息。
垂直业务：添加特定的业务标签（如类目、优先级）。
3、分层标注降低成本
文档级：上传时标注一次（如部门、敏感级），自动继承给所有 Chunk。
Chunk 级：系统自动生成（如页码、偏移量、序号）。
按需精细化：仅对核心高频文档人工标注复杂字段（如生效日期）。
总结
1、本文介绍了元数据的必要性，即只使用纯文本块chunk会导致（缺乏可信度，权限失控，难以纠错），从而提出了为每个文本块附加元数据，元数据不参加语义向量化。
2、接着介绍了元数据的定义，以及流程的位置，并给出了其数据结构的示例{content,metadata}
3、然后又介绍了常见的元数据字段（文档标识类，结构信息类，时间版本类，权限控制类，位置追随类，业务自定义类）介绍它们的字段，作用，以及使用建议。并提供了一个表格给出这些分类的常见示例和使用时机。
4、又提出了元数据字段的几个添加方案少即是多（不要使用过多的元素）；力度匹配业务（公共文档，内部知识库，垂直业务，不同业务使用不同标签）；分层标注以降低成本（文档级，chunk级，不同级别使用不同保住）