元数据字段设计：标签、分类、时间、来源等
在 RAG 系统中，文本切片（chunk）除了本身的语义内容，还应该携带结构化的元数据。这些元数据不直接参与语义匹配，但在检索过滤、排序加权、溯源展示、后期分析等环节中至关重要。设计好元数据字段，可以让系统在“找到相关内容”的基础上，做到“找到最可信、最新鲜、最恰当的内容”。
以下是真实落地的 RAG 系统中常用且重要的元数据字段，按照用途分组说明。
1. 来源类元数据：回答从哪儿来
这类字段是溯源和信任的基础，几乎每个切片都应当包含。
| 字段 | 说明 | 示例 | 用途 |
|------|------|------|------|
| source_name | 文档名称或标题 | 《员工手册（2025版）》 | 前端展示出处时使用 |
| source_type | 文档类型 | policy、manual、faq、contract | 按类型过滤或加权（政策类优先于聊天记录） |
| file_id | 原始文件唯一标识 | file_2012 | 文件更新时快速定位旧切片并替换 |
| chunk_index | 该切片在原文档中的顺序号 | 5（第5个切片） | 合并相邻块、排序还原上下文 |
| page_number | 所在页码（PDF 等固定格式） | 12 | 精确溯源，生成“详见第12页” |
| section_title | 章节或小节标题 | 第三章·年假规定 | 增强片段的结构信息，帮助模型理解上下文 |
设计建议：至少保证 source_name 和 chunk_index 存在，以实现基本溯源和上下文扩展。source_type 建议采用枚举值，方便后续过滤。
2. 时间类元数据：让知识保持“新鲜”
时间信息可以区分新旧版本、支持时效性控制，也能帮助分析知识演变。
| 字段 | 说明 | 示例 | 用途 |
|------|------|------|------|
| created_at | 文档创建时间 | 2024-06-01 | 标记知识首次入库时间 |
| updated_at | 最后更新时间 | 2025-01-15 | 排序或筛选最新内容 |
| effective_date | 内容生效日期（政策等） | 2025-02-01 | 场景：未来政策提前入库，但检索时不采用 |
| expiry_date | 内容失效日期 | 2025-12-31 | 过期内容自动过滤或降低权重 |
一个实际用法：在检索促销政策时，可添加过滤条件 effective_date <= today AND (expiry_date IS NULL OR expiry_date >= today)，确保只采纳当前有效的规则。配合过期日期，还能主动给用户提示“该优惠政策已于X日结束”。
3. 标签与分类类元数据：精细化组织知识
这类字段帮助系统按主题、业务线、部门等维度快速筛查，显著提升检索命中精度。
| 字段 | 说明 | 示例 | 用途 |
|------|------|------|------|
| tags | 关键词标签（可多个） | ["年假","请假","考勤"] | 过滤或加权，增强语义匹配以外的精确召回 |
| category | 一级分类 | hr_policy | 按部门或功能划分 |
| sub_category | 二级分类 | time_off | 更细粒度的分类 |
| audience | 目标受众 | all_employees、managers | 针对不同角色返回不同回答的基础 |
| language | 语言 | zh-cn | 多语言知识库必须字段 |
设计建议：标签以少量精选为宜（3-5个），不要过度标注；分类尽量使用层级结构但不要超过三层，保持逻辑清晰。category 和 sub_category 的值应提前制定规范，避免同一概念多种写法。
4. 质量与状态类元数据：方便运维和迭代
这些字段用于内部系统管理和持续优化，不在生成中直接暴露给用户。
| 字段 | 说明 | 示例 | 用途 |
|------|------|------|------|
| review_status | 审核状态 | approved、draft、deprecated | 只让审核通过的内容参与检索 |
| owner | 内容负责人 | hr_team@company.com | 错误反馈时自动通知 |
| usage_count | 被引用次数 | 1024 | 识别高频知识，指导知识优化 |
| score | 内容质量评分 | 4.8 | 结合人工或反馈评分，辅助排序 |
实用技巧：将 review_status 设为检索时的默认过滤条件，只返回 approved 状态的切片，就能避免草稿或旧版本污染正式回答。usage_count 可以通过日志定期更新，用于分析哪些知识对企业最有价值。
5. 综合设计原则
- 必选字段最小化：每个 chunk 必须带的只有少数核心字段（如来源、时间、分类），其余按需添加，避免存储浪费和管理负担。
- 字段值规范化：尽量用预定义枚举值或选填列表，防止输入随意化导致过滤失效。
- 与向量数据分离存储：元数据通常存储在向量数据库的标量字段中，与向量独立，方便过滤和更新，不影响向量维度。
- 面向检索优化设计：经常用于过滤的字段（如日期、状态、分类）要建立索引，确保过滤速度。
- 考虑权限控制：如果某些文档仅限特定部门查看，需要元数据标记访问级别，检索时联动权限系统。
元数据虽然不直接承载语义，却是将“语义搜索”提升为“智能、可控、可管理”的企业级知识服务的关键一公里。投入时间做好元数据规划，后续的检索效果和维护效率会显著受益。