如何解决 Milvus 在处理百万级长文本切片后的检索精度下降问题

Milvus 在处理百万级长文本切片时，最容易掉进的坑就是：切片太细导致语义丢失，切片太粗导致噪声太大，最后检索出来的 Top-K 结果虽然相关，但根本没命中关键答案。

我之前在做一个法律文档知识库，单篇文档几万字，直接用固定长度（比如 512 token）暴力切分，检索精度掉得离谱。后来尝试了「父子索引（Parent-Child Retrieval）」方案，精度直接回升了 30% 以上。

核心逻辑是：检索用短片段（Child），喂给 LLM 用长片段（Parent）。

具体操作步骤如下：

1. 重新设计 Schema
不要只存一个向量字段。在 Milvus 中建立两个 Collection，或者在一个 Collection 里通过 parent_id 建立关联。
子片段表：存储 128-256 token 的极短切片 → 负责高精度匹配。
父片段表：存储 1024-2048 token 的原始段落 → 负责提供上下文。

2. 索引配置优化
百万级数据量下，千万别用 FLAT，太慢。建议用 HNSW，但要注意 M 和 efConstruction 的参数。如果发现召回率下降，把 ef 调高。

# Milvus 索引参数参考
index_params = {
    "metric_type": "L2", 
    "index_type": "HNSW", 
    "params": {"M": 16, "efConstruction": 64} 
}

3. 检索链路改造
不要直接把 search() 出来的文本丢给模型，而是通过 parent_id 回溯到父片段。

# 伪代码流程
# 1. 在子片段 Collection 中检索 Top-K
results = child_collection.search(query_vector, anns_field="vector", limit=5)

# 2. 提取 parent_id
parent_ids = [res.entity.get("parent_id") for res in results[0]]

# 3. 根据 parent_id 从父片段 Collection 中查询完整文本
full_context = parent_collection.query(
    expr=f"id in {parent_ids}", 
    output_fields=["text"]
)

踩过的坑：

• 切片重叠度（Overlap）：设置 10%-20% 的重叠度是必须的，否则关键语义刚好被切断，向量化后会产生偏移。
• 维度灾难：如果用的是 text-embedding-3-large，记得在 Milvus 创建索引时核对维度是否一致，否则会报 Dimension mismatch。
• 内存溢出：百万级数据开启 HNSW 后，内存占用会激增。如果机器内存吃紧，考虑把 index_type 换成 IVF_FLAT，虽然精度微降，但能保住服务不挂。

这种方案本质上是用存储空间换检索精度。比起单纯调整 Prompt，从数据索引结构入手才是解决 RAG 精度问题的根源。