Agent Engineering
The Milvus Mental Model
Start with tables, columns, and rows, then add the two vector-specific ideas: ANN indexes and loading for search.
Core objects
| Milvus | Rough analogy | Responsibility |
|---|---|---|
| Collection | Table | Entities sharing one schema |
| Schema / Field | Table definition / column | IDs, vector dimensions, and scalar types |
| Entity | Row | One business object with a stable primary key |
| Index | Index | Accelerates nearest-neighbor search |
One knowledge-base entity
{"id": 42, "vector": [0.12, ...], "text": "Refunds take three days",
"category": "refund", "active": true}
Search, Query, and Load
Search
Takes a query vector and returns Top-K by distance, optionally with a scalar filter. It answers “what is semantically closest?”
Query
Takes a primary-key or scalar expression, not a query vector. It answers “which records meet these conditions?”
Load
Makes collection data and indexes available to query nodes. A created collection is not automatically search-ready in every lifecycle.
Index trade-offs
| Index | Strength | Cost / fit |
|---|---|---|
| FLAT | Exact; no training | Full scan; small sets and recall baseline |
| IVF_FLAT | Clusters narrow candidates | Tune nlist / nprobe; practical at larger scale |
| HNSW | High recall and low latency | More memory and slower builds; strong online choice |
Lifecycle: define schema → create collection → insert entities → build index → load → search/query. IDs track records, vectors provide similarity, and scalar fields enforce tenant, ACL, time, and state constraints.
Takeaway Search is “find by meaning”; Query is “fetch by condition.” Index controls speed, while Load controls readiness.