Milvus 心智模型
Collection、Schema、Entity、Index、Search、Query 与 Load
本页解决的问题
先给结论「Milvus 心智模型」要解决的关键问题是什么？
Collection、Schema、Entity、Index、Search、Query 与 Load
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
| Milvus | 可类比为 | 职责 |
|---|---|---|
| Collection | 表 | 一组具有同一 Schema 的 Entity |
| Schema / Field | 表结构 / 列 | 约束主键、向量维数与标量类型 |
| Entity | 行 | 一条业务对象；主键必须能稳定定位 |
| Index | 索引 | 加速向量近邻搜索 |
{
"id": 42, # 主键：用于更新、删除、追踪
"vector": [0.12, ...], # 向量字段：用于 Search
"text": "退款通常 3 天到账",
"category": "refund", # 标量字段：用于 Filter / Query
"active": true
}
Search
输入查询向量，按距离返回 Top-K；可附加 filter='active == true'。答案是“语义上谁最像”。
Query
不传向量，按主键或标量表达式取数据。答案是“哪些记录满足条件”。
Load
搜索前把 collection 的索引与数据准备到查询节点。创建成功不代表已经可搜，资源不足时也要规划释放。
| Index | 优势 | 代价 / 场景 |
|---|---|---|
| FLAT | 精确、无需训练 | 全量比较；小数据集或 Recall 基线 |
| IVF_FLAT | 通过聚类缩小候选 | 需调 nlist / nprobe；数据量较大、成本可控 |
| HNSW | 高 Recall、低延迟 | 占更多内存且建索引较慢；在线检索常用 |
「核心对象」为什么能找到相关内容
「输入查询向量，按距离返回 Top-K；可附加 filter='active == true' 。答案是“语义上谁最像”」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案，召回之后还要核对
在「搜索前把 collection 的索引与数据准备到查询节点。创建成功不代表已经可搜，资源不足时也要规划释放」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。
先区分找得到和找得准
把「搜索前把 collection 的索引与数据准备到查询节点。创建成功不代表已经可搜，资源不足时也要规划释放」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。
从「核心对象」走到「一条知识库 Entity」
「核心对象」先把问题落在「Milvus 可类比为 职责 Collection 表 一组具有同一 Schema 的 Entity Schema / Field 表结构 / 列 约束主键、向量维数与标量类型 Entity 行 一条业务对象；主键必须能稳定定位 Index 索引 加速向量近邻搜索」上；到了「一条知识库 Entity」，讨论继续推进到「{ "id" : 42, # 主键：用于更新、删除、追踪 "vector" : [0.12, ...], # 向量字段：用于 Search "text" : "退款通常 3 天到账" , "category" : "refund" , # 标量字段：用于 Filter / Query "active" : true }」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「核心对象」：Milvus 可类比为 职责 Collection 表 一组具有同一 Schema 的 Entity Schema / Field 表结构 / 列 约束主键、向量维数与标量类型 Entity 行 一条业务对象；主键必须能稳定定位 Index 索引 加速向量近邻搜索
- 「一条知识库 Entity」：{ "id" : 42, # 主键：用于更新、删除、追踪 "vector" : [0.12, ...], # 向量字段：用于 Search "text" : "退款通常 3 天到账" , "category" : "refund" , # 标量字段：用于 Filter / Query "active" : true }
- 「索引选型不是“越高级越好”」：Index 优势 代价 / 场景 FLAT 精确、无需训练 全量比较；小数据集或 Recall 基线 IVF_FLAT 通过聚类缩小候选 需调 nlist / nprobe；数据量较大、成本可控 HNSW 高 Recall、低延迟 占更多内存且建索引较慢；在线检索常用 生命周期： 定义 Schema → 创建 Collection → 写 Entity → 建 Index → Load → Search / Quer…
最后的「索引选型不是“越高级越好”」把讨论落到「Index 优势 代价 / 场景 FLAT 精确、无需训练 全量比较；小数据集或 Recall 基线 IVF_FLAT 通过聚类缩小候选 需调 nlist / nprobe；数据量较大、成本可控 HNSW 高 Recall、低延迟 占更多内存且建索引较慢；在线检索常用 生命周期： 定义 Schema → 创建 Collection → 写 Entity → 建 Index → Load → Search / Quer…」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。