企业 RAG 数据怎样进入 Milvus：文档版本、切分、索引与权限

1. 替换原文件，旧答案为什么还会出现

知识库里的一份制度文档已经更新，RAG 仍然引用旧条款。直接检查大模型提示词，很可能错过真正的问题：旧文档产生的 Chunk 和向量还留在索引中。

一份文档进入 RAG，要经过多层派生：

Document Source
  → Raw Object
  → Document Version
  → Parse Result
  → Chunk
  → Embedding
  → Milvus Collection
  → Retrieve / Rerank
  → Citation

删除原始文件不会自动删除下游向量。平台需要保存各层关系，才能让更新和删除传播下去。

2. 原文与解析结果要分开

原始 PDF、Word 或网页快照可以放在对象存储，MySQL 保存文档身份、版本、权限和处理状态：

Document
  id
  knowledge_base_id
  title
  current_version_id

DocumentVersion
  id
  document_id
  source_uri
  checksum
  parser_version
  status
  created_at

文档更新时创建新版本，不覆盖旧记录。这样可以回答某次回答引用的是哪一版原文，也能在新解析失败时继续识别旧版本状态。

解析结果还要保存页码、标题层级、表格位置和字符范围。只保存纯文本会让引用难以回到原文位置。

3. Chunk 是可以重建的派生数据

切分策略会改变检索单位。固定字符数、标题分段、滑动窗口和表格专用解析会产生不同 Chunk。

Chunk
  id
  document_version_id
  chunk_index
  text
  page_number
  section_path
  content_hash
  acl_scope

Chunk ID 应该稳定或可追踪。文档重新切分后，需要知道哪些旧向量失效，哪些内容没有变化可以复用。

切分大小没有通用最佳值。它受到文档结构、Embedding 模型、检索方式、上下文窗口和答案任务影响。资料示例中的参数不能直接当成项目结论。

4. Embedding 版本决定索引版本

向量维度和含义由 Embedding 模型决定。更换模型、归一化方式或输入预处理后，旧向量通常不能与新查询向量混用。

平台可以记录：

EmbeddingVersion
  model_id
  model_revision
  dimension
  preprocessing_version
  distance_metric

Milvus Collection Schema 中的向量字段维度和索引配置要与之匹配。发布新 Embedding 时，可以建立新的 Collection 或明确的新分区，在验证完成后切换检索别名。

直接清空旧集合再重建，会制造检索不可用窗口，也失去回滚能力。

5. 向量库里还要保存标量字段

只写 id + vector，检索结果就无法解释。至少需要带回文档身份、版本、Chunk、来源和权限范围：

chunk_id
document_id
document_version_id
knowledge_base_id
text
source_uri
page_number
acl_scope
embedding_version
vector

Milvus 支持向量字段和标量字段，查询时可以使用过滤条件。权限过滤应来自服务端可信身份，不能让前端自由传入任意部门编号。

Milvus 负责索引和检索，不负责判断文档是否真实有效，也不会代替业务系统管理授权。Java 检索服务在调用前校验知识库权限，并把允许范围转成受控过滤条件。

6. 更新和删除需要沿血缘传播

一份文档新版本发布时，可以执行：

保存原文版本
  → 解析并校验
  → 生成新 Chunk
  → 计算 Embedding
  → 写入候选索引
  → 抽样检查引用
  → 切换当前版本
  → 标记旧向量待清理

如果中途失败，当前可用版本不应提前失效。索引任务要支持重试，并通过文档版本和任务编号保持幂等。

删除同样分两种：撤销当前可见性和物理清理。前者应尽快阻止继续检索，后者可以由后台任务清除对象、解析结果和向量。两步之间仍要保证权限过滤不再返回已撤销内容。

7. 检索成功不等于答案有依据

一次查询至少记录：

query_id
query_text_hash
embedding_version
collection_version
filter_scope
retrieved_chunk_ids
scores
reranked_chunk_ids
cited_chunk_ids

检索返回 Top K，只说明索引找到了相似项。答案是否正确，还要检查引用是否真正支撑结论、是否遗漏关键内容、是否使用过期版本。

向量相似度也不适合所有查询。编号、精确术语和专有名词可能需要关键词或混合检索。Rerank 可以改变排序，但同样需要版本和评估数据。

8. Kubernetes 上可以拆成哪些任务

文档解析和 Embedding 往往适合后台 Job：

Java API
  → IndexJob record
  → Queue
  → Parser Job
  → Embedding Job
  → Milvus upsert
  → Validation
  → Publish index version

API 返回任务编号，不等待全部文档处理完成。Worker 失败后可以重试，平台保存每个阶段的输入版本、执行次数和错误摘要。

在线检索服务与离线索引任务分开部署。索引高峰不应直接抢占在线查询所需资源。

RAG 的数据对象不只是向量。原文、版本、解析、Chunk、Embedding、索引和引用共同构成可追踪链路；向量数据库解决检索问题，数据治理和权限仍然要由平台承担。把索引与检索拆开后，各自才能独立演进。

相关阅读

• Agent 平台为什么要保存 Trace 和 Evidence：从一次检索到受控 Action
• SQL 能运行，为什么问数结果还是错的？
• 仰望星空：从 Databricks、Snowflake 与 Palantir 看数据平台走向 Agent

参考资料

• Milvus：RAG Pipeline
• Milvus：Schema
• Milvus：向量检索