Milvus(@milvusio)

A customer searches by image and gets a list of similar products. But the page also needs brand fil...

Milvus (@milvusio) — Thu, 13 Aug 2026 15:35:00 GMT

A customer searches by image and gets a list of similar products.

But the page also needs brand filters, price ranges, representative items, and a sensible order across pages.

Before Milvus 3.0, the application had to build that second layer itself: retrieve candidates, group them by brand, calculate counts and averages, select representative items, and sort the results.

That means more data leaving the database, more post-processing code, and more room for errors. For example, sorting each fetched page by price does not produce a globally price-sorted result.

𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗺𝗼𝘃𝗲𝘀 𝘁𝗵𝗶𝘀 𝘄𝗼𝗿𝗸 𝗶𝗻𝘁𝗼 𝘁𝗵𝗲 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗲𝗻𝗴𝗶𝗻𝗲:
• 𝗤𝘂𝗲𝗿𝘆 𝗔𝗴𝗴𝗿𝗲𝗴𝗮𝘁𝗶𝗼𝗻 returns exact grouped statistics over filtered, visible rows.
• 𝗦𝗲𝗮𝗿𝗰𝗵 𝗔𝗴𝗴𝗿𝗲𝗴𝗮𝘁𝗶𝗼𝗻 returns buckets, metrics, and representative hits over ANN candidates.
• 𝗦𝗲𝗿𝘃𝗲𝗿-𝘀𝗶𝗱𝗲 𝗢𝗥𝗗𝗘𝗥 𝗕𝗬 sorts results before they reach the application.

Now a product-search experience can receive structured results directly, rather thanmilvus.io/blog/from-retr…hat needs to be rebuilt after retrieval.

Full technical walkthrough:
https://t.co/WCWW9oLyHw

💬0🔄0❤️1👀209

⚡ Powered by xgo.ing

A Milvus Snapshot is a named, read-only, point-in-time version of a collection. It records referenc...

Milvus (@milvusio) — Wed, 12 Aug 2026 16:42:29 GMT

A Milvus Snapshot is a named, read-only, point-in-time version of a collection.

It records references to the data and index files already in object storage, rather than duplicating the dataset.

That makes it useful before a model upgrade or data backfill.

Here’s the basic workflow:
• 𝗦𝗲𝘁 𝘁𝗵𝗲 𝗯𝗼𝘂𝗻𝗱𝗮𝗿𝘆
If recent writes must be included, run Flush first. Growing segments are not included in a snapshot.
• 𝗖𝗿𝗲𝗮𝘁𝗲 𝘁𝗵𝗲 𝘀𝗻𝗮𝗽𝘀𝗵𝗼𝘁
Give it a meaningful name, such as before_model_v2, so its retention purpose is clear.
• 𝗨𝘀𝗲 𝗶𝘁
Restore into a new collection to validate a rollback, or read it through Spark / External Collection as fixed input.

Then clean up. Snapshot-referenced files cannot be garbage-collected, so drop snapshots when they no longer eamilvus.io/blog/milvus-sn…walkthrough: https://t.co/sIBHa6dwAR

💬0🔄0❤️0👀203

⚡ Powered by xgo.ing

Before an embedding model upgrade or data backfill, you need a recovery point. But a full backup ...

Milvus (@milvusio) — Tue, 11 Aug 2026 15:30:00 GMT

Before an embedding model upgrade or data backfill, you need a recovery point.  

But a full backup is too heavy to take before every re-embedding or data backfill.

𝗠𝗶𝗹𝘃𝘂𝘀 𝗦𝗻𝗮𝗽𝘀𝗵𝗼𝘁𝘀 create a point-in-time, read-only view of a collection by recording existing data, index, and metadata files—without copying vector data.

If a change goes wrong, restore the snapshot into a new collection: no full re-import, no index rebuild, and no overwrite of production.

A recovery point you can afford to take before every risky change.

Knomilvus.io/blog/milvus-sn…t.co/sIBHa6dwAR

💬0🔄0❤️2👀207

⚡ Powered by xgo.ing

Milvus 3.0 further expands what its retrieval engine can handle, with stronger support for in-engine...

Milvus (@milvusio) — Mon, 10 Aug 2026 15:31:00 GMT

Milvus 3.0 further expands what its retrieval engine can handle, with stronger support for in-engine ranking, aggregation, multi-vector search, and sparse retrieval.

In production, vector search rarely ends with top-k ANN results. Beyond retrieving candidates, applications often need to sort by freshness, price, rating, inventory, or timestamp; group results by category; return facets; and work with entities that contain many vectors, such as document chunks, video frames, product images, or ColBERT token vectors.

Milvus has long supported dense and sparse vector search, hybrid retrieval, and filtering. Milvus 3.0 builds on that foundation by bringing more ranking, grouping, and result-processing work closer to the retrieval path.

ORDER BY sorts filtered query results by scalar fields and can also sort ANN candidates within Milvus. Query-side aggregation supports count, sum, avg, min, and max, grouped by scalar fields. Search aggregation adds faceted search over retrieved hits, returning bucket counts, aggregate statistics, and top-N sample hits per bucket. Since it operates on ANN results, facet counts are approximate; use query-side aggregation when exact counts matter.

StructArray lets a single entity contain a variable-length list of structured elements and vectors while remaining one row. It fits workloads such as document chunks, video frames, product images, and late-interaction models like ColBERT.

Sparse retrieval is also enhanced with compressed BM25 indexes and SINDI, an algorithm designed for learned sparse embeddings such as SPLADE.

For retrieval teams, the practical benefit is less over-fetching and less custom application-side logic for ranking, grouping, faceting, multi-vector scoring, and sparse search.

More in the Milvus 3.0 launch blog: milvus.io/blog/announcin…

💬0🔄1❤️10👀452📊2

⚡ Powered by xgo.ing

When an AI Agent gives a bad answer, the model is not always the first place we should look. When a...

Milvus (@milvusio) — Fri, 07 Aug 2026 15:30:00 GMT

When an AI Agent gives a bad answer, the model is not always the first place we should look.

When an answer is weak, teams often look at the prompt, model, or agent logic first. But many issues start earlier: the system retrieved the wrong context, missed the right one, or filtered it out before the LLM saw it.

That is why Simon Hearne's talk on visualizing vector search is worth watching. It makes the retrieval layer feel less like a black box.

In SQL, EXPLAIN shows the plan, index, and why a query behaves a certain way.

Vector search is messier. Results are shaped by embeddings, index choice, quantization, metadata filters, and the latency/recall tradeoffs teams make.

Simon walks through examples that come up quickly in production:
• Brute-force search is easy to trust, until the dataset gets large.
• IVF, HNSW, and DiskANN each make different tradeoffs.
• Quantization can help with speed and storage, but recall still needs checking.
• Filters can remove the paths to the best matches.
For teams building RAG or agents, the lesson is simple: debug retrieval directly.

Track recall@k. Look at score distributions. Watch filter hit rates. Treat index and embedding changes as quality changes.

This is the engineering work Milvus is built around: a production retrieval layer teams can tune, scale, and reason about.
Watch Simon's visual explanation here: youtube.com/watch?v=kY-il0…

💬1🔄0❤️3👀257📊2

⚡ Powered by xgo.ing

𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗰𝗵𝗮𝗻𝗴𝗲𝘀 𝘀𝗼𝗺𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗮𝘀𝘀𝘂𝗺𝗽𝘁𝗶𝗼𝗻𝘀 𝗯𝗲𝗵𝗶𝗻𝗱 ...

Milvus (@milvusio) — Fri, 07 Aug 2026 05:52:09 GMT

𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗰𝗵𝗮𝗻𝗴𝗲𝘀 𝘀𝗼𝗺𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗮𝘀𝘀𝘂𝗺𝗽𝘁𝗶𝗼𝗻𝘀 𝗯𝗲𝗵𝗶𝗻𝗱 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲.

With lake-native External Collections and richer retrieval capabilities like grouping, faceting, sorting, filtering, and aggregation, Milvus can work with data where it already lives — while giving applications more precise control over retrieval than semantic similarity alone.

That opens up some practical architecture questions:
-> Where should embeddings live?
-> How should you tune hybrid search for your workload?
-> How do filters affect the trade-off between recall and latency?
-> And when an answer looks plausible but the retrieved context is wrong, where do you start debugging?

If you’re working through questions like these, bring them to 𝗠𝗶𝗹𝘃𝘂𝘀 𝗢𝗳𝗳𝗶𝗰𝗲 𝗛𝗼𝘂𝗿𝘀.

Book a 20-minute 1:1 session with Milvus experts to talk through schema design, performance, scaling, troubleshomeetings.hubspot.com/chloe-williams…r Milvus 3.0 architecture decisions.

🔥 Book a session: https://t.co/CCeh01Cjko

💬0🔄1❤️2👀260📊1

⚡ Powered by xgo.ing

𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗺𝗮𝗸𝗲𝘀 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗺𝗼𝗿𝗲 ...

Milvus (@milvusio) — Thu, 06 Aug 2026 15:30:00 GMT

𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗺𝗮𝗸𝗲𝘀 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗺𝗼𝗿𝗲 𝗶𝗻𝘁𝗲𝗿𝗲𝘀𝘁𝗶𝗻𝗴.

Vectors no longer live in isolation. With lake-native External Collection and structured queries like grouping, faceting, sorting, and aggregation, Milvus can sit closer to the data systems teams already use.

That raises real questions:

Where should embeddings live?
How do you tune hybrid search?
How do you balance recall, latency, filters, and cost?
How do you debug retrieval when answers look plausible but context is wrong?

𝗕𝗿𝗶𝗻𝗴 𝘁𝗵𝗼𝘀𝗲 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 𝘁𝗼 𝗠𝗶𝗹𝘃𝘂𝘀 𝗢𝗳𝗳𝗶𝗰𝗲 𝗛𝗼𝘂𝗿𝘀.

Book a 20-minute 1:1 session with Milvus experts for help on schema design, performmeetings.hubspot.com/milvus-office-…hooting, or Milvus 3.0 architecture decisions.

🙋🏻♀️ Join here: https://t.co/FwBKy9bIe1

💬0🔄1❤️3👀200📊1

⚡ Powered by xgo.ing

𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗼𝗻𝗹𝗶𝗻𝗲 𝘀𝗰𝗵𝗲𝗺𝗮 𝗲𝘃𝗼𝗹𝘂𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 ...

Milvus (@milvusio) — Wed, 05 Aug 2026 15:15:00 GMT

𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗼𝗻𝗹𝗶𝗻𝗲 𝘀𝗰𝗵𝗲𝗺𝗮 𝗲𝘃𝗼𝗹𝘂𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗯𝗮𝗰𝗸𝗳𝗶𝗹𝗹, 𝗮𝗹𝗹𝗼𝘄𝗶𝗻𝗴 𝘁𝗲𝗮𝗺𝘀 𝘁𝗼 𝗰𝗵𝗮𝗻𝗴𝗲 𝗮 𝗰𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻’𝘀 𝗱𝗮𝘁𝗮 𝗺𝗼𝗱𝗲𝗹 𝘄𝗵𝗶𝗹𝗲 𝗶𝘁 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗲𝘀 𝘀𝗲𝗿𝘃𝗶𝗻𝗴 𝘁𝗿𝗮𝗳𝗳𝗶𝗰.

In production retrieval systems, schemas rarely remain static. As retrieval requirements evolve, teams frequently need to add new embedding models, sparse vectors, labels, metadata fields, text columns, and retention policies. Before Milvus 3.0, these data model changes often came with high operational costs, requiring disruptive collection rebuilds or carefully scheduled migration windows to avoid service impact.

To resolve this pain point, Milvus 3.0 enables teams to add, populate, and drop fields without taking the collection offline. Adding a field creates a new nullable column without rewriting existing data. Dropping a deprecated or experimental field updates the collection metadata at runtime. Both operations simply update the collection manifest instead of forcing a full data rewrite, significantly reducing operational overhead.

While online schema changes support structural updates, backfill complements the capability by completing the full schema-evolution workflow and populating newly added fields with valid data.

Milvus 3.0 supports inner backfill for values derived from data already stored in the collection. For example, Milvus can generate BM25 sparse vectors directly from a text field, removing the need for a separate client-side encoder in dense-and-sparse hybrid retrieval pipelines.

In addition to in-engine backfill, external backfill is on the roadmap for scenarios where new column values need to be computed outside Milvus. The workflow is straightforward: take a snapshot, run Spark against the stable view, compute the new column, write the values back, and let Milvus update the relevant indexes incrementally.

Combined together, online schema evolution and backfill enable retrieval pipelines to iterate flexibly. Teams can continuously adjust data models to fit evolving busimilvus.io/blog/announcin…uilding the entire collection every time schema updates occur.
More in the Milvus 3.0 launch blog: https://t.co/hq4qqZASuX

💬0🔄0❤️1👀299📊1

⚡ Powered by xgo.ing

𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬: 𝗦𝘁𝗮𝗯𝗹𝗲 𝗦𝗻𝗮𝗽𝘀𝗵𝗼𝘁𝘀 𝗮𝗻𝗱 𝗕𝗮𝘁𝗰𝗵 𝗣𝗿𝗼𝗰𝗲𝘀𝘀𝗶𝗻𝗴 𝗳𝗼𝗿 ...

Milvus (@milvusio) — Tue, 04 Aug 2026 15:30:00 GMT

𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬: 𝗦𝘁𝗮𝗯𝗹𝗲 𝗦𝗻𝗮𝗽𝘀𝗵𝗼𝘁𝘀 𝗮𝗻𝗱 𝗕𝗮𝘁𝗰𝗵 𝗣𝗿𝗼𝗰𝗲𝘀𝘀𝗶𝗻𝗴 𝗳𝗼𝗿 𝗘𝘃𝗼𝗹𝘃𝗶𝗻𝗴 𝗔𝗜 𝗗𝗮𝘁𝗮

Milvus 3.0 introduces Collection Snapshot and a Spark connector to help teams create consistent views of changing AI data, run distributed batch processing, and write updated results back into Milvus.

Traditional business data mainly records facts such as orders, product details, or device states. In AI systems, however, more data is generated by models. Embeddings, quality scores, classification labels, and reranking features all depend on specific models and processing logic. When models or business rules change, the same source data often needs to be recomputed, even while the production collection continues serving queries and accepting writes.

𝗖𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻 𝗦𝗻𝗮𝗽𝘀𝗵𝗼𝘁 provides a stable input for these workflows. It creates a read-only view of a collection at a specific point in time by referencing existing data files, index files, and metadata, without copying the full dataset. Teams can use snapshots for model migration, embedding regeneration, schema changes, backfills, evaluation, deduplication, and isolated testing.

Snapshots can also serve as logical recovery points, but they do not replace backups. A snapshot may still share the same underlying storage as production, making it better suited to short-term isolation and recovery. Independent backups remain necessary for long-term retention and disaster recovery.

The Spark connector, built on Spark DataSource V2, allows Spark, Databricks, and Amazon EMR to read from and write to Milvus directly. Teams can process snapshot data with distributed jobs, then write new embeddings, labels, scores, or curated results back into Milvus.

Snapshots provide a stable data view. Spark provides distributed compute. Milvus 3.0 connects them into one workfmilvus.io/blog/announcin…ata improvement.
More in the Milvus 3.0 launch blog: https://t.co/hq4qqZASuX

💬0🔄1❤️2👀295📊1

⚡ Powered by xgo.ing

Milvus 3.0 resolves the fundamental AI workload conflict between continuously changing production da...

Milvus (@milvusio) — Mon, 03 Aug 2026 15:30:00 GMT

Milvus 3.0 resolves the fundamental AI workload conflict between continuously changing production data and stable offline computation by introducing low-cost, point-in-time, read-only collection snapshots.

In AI systems, data states shift constantly: models are updated, embeddings are regenerated, and schemas evolve, while online collections must continuously serve queries and ingest new writes. Offline batch jobs, however, require fixed, reproducible data views to generate consistent results—a gap snapshots are designed to fill.

𝗦𝗻𝗮𝗽𝘀𝗵𝗼𝘁𝘀 achieve low overhead by referencing existing data, index, and metadata files instead of duplicating full datasets. This enables lightweight checkpoint creation before risky operations including model swapping, re-embedding, and schema migration.

While the primary production collection keeps changing, immutable snapshot views support a wide range of isolated batch workflows, such as A/B evaluation, deduplication, backfill validation, and offline testing.

Snapshots also accelerate data recovery and cloning. Milvus reuses existing data and index files via object storage server-side copy, eliminating expensive full data reimports and index rebuilds.

This capability is critical for AI pipelines, because embeddings and derived features are version-dependent outputs rather than permanent source-data attributes. Snapshots provide stable, low-cost checkpoints for validating iterations and rolling back faulty releases without heavy backup overhead.

Notably, snapshots do not replace backups. Snapshots rely on live collection resources and serve short-term logical operations: version rollback, cloning, and stable view isolation. Backups create independent, durable copies for long-term retention and disaster recovery.

In summary, snapshots manage frequent data changes for agile AI iteration, while backups protect against permanent data loss.

Knmilvus.io/blog/milvus-sn…svDWFw3lp

💬0🔄2❤️4👀237📊1

⚡ Powered by xgo.ing

🎉 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗶𝘀 𝗻𝗼𝘄 𝗮𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲, 𝗮𝗻𝗱 𝗶𝘁’𝘀 𝗮 𝗺𝗮𝗷𝗼𝗿 𝘀𝘁𝗲𝗽 ...

Milvus (@milvusio) — Fri, 31 Jul 2026 15:00:02 GMT

🎉 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗶𝘀 𝗻𝗼𝘄 𝗮𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲, 𝗮𝗻𝗱 𝗶𝘁’𝘀 𝗮 𝗺𝗮𝗷𝗼𝗿 𝘀𝘁𝗲𝗽 𝘁𝗼𝘄𝗮𝗿𝗱 𝗹𝗮𝗸𝗲-𝗻𝗮𝘁𝗶𝘃𝗲 𝘃𝗲𝗰𝘁𝗼𝗿 𝘀𝗲𝗮𝗿𝗰𝗵.

🔥 Key highlights:
• External Collections let teams build retrieval directly where their data already lives: in object storage, open data formats like Parquet and Vortex, and open table formats like Lance and Iceberg.
• Loon Storage v3 improves point reads for lake-native retrieval on S3-style object storage.
• Snapshots, Spark DataSource V2, and live schema changes bring stable collection views into batch workflows, recovery, backfill, and schema evolution.
• ORDER BY, aggregation, and faceted search move more result processing into the retrieval engine.
• StructArray and SINDI strengthen multi-vector, sparse, and hybrid retrieval workloads.

For builders working on RAG, agents, multimodal search, and AI data pipelines, Milvus 3.0 reduces duplicate data movement and pushes more retrieval logic into the engine itself.

It is a big step toward a cleaner architecture: lake-native storage, offline data improvement, online serving, and retrieval-time processigithub.com/milvus-io/milv…one open-source vectormilvus.io/blog/announcin…https://t.co/3ckzkUVicH 
📖 Full launch blog: https://t.co/hq4qqZASuX

💬1🔄0❤️3👀229📊2

⚡ Powered by xgo.ing

𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗦𝘁𝗼𝗿𝗮𝗴𝗲 𝘃𝟯, 𝗮𝗹𝘀𝗼 𝗸𝗻𝗼𝘄𝗻 𝗮𝘀 𝗟𝗼𝗼𝗻, 𝗮 ...

Milvus (@milvusio) — Thu, 30 Jul 2026 15:30:00 GMT

𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗦𝘁𝗼𝗿𝗮𝗴𝗲 𝘃𝟯, 𝗮𝗹𝘀𝗼 𝗸𝗻𝗼𝘄𝗻 𝗮𝘀  𝗟𝗼𝗼𝗻, 𝗮 𝘀𝘁𝗼𝗿𝗮𝗴𝗲 𝗲𝗻𝗴𝗶𝗻𝗲 𝗯𝘂𝗶𝗹𝘁 𝗳𝗼𝗿 𝘀𝗲𝗿𝘃𝗶𝗻𝗴-𝘀𝘁𝘆𝗹𝗲 𝗮𝗰𝗰𝗲𝘀𝘀 𝗼𝗻 𝗼𝗯𝗷𝗲𝗰𝘁 𝘀𝘁𝗼𝗿𝗮𝗴𝗲.

Loon handles a specific problem: after ANN search returns candidate IDs, Milvus still has to fetch the fields for those rows.

On object storage, that fetch can become expensive. Analytical file formats are optimized for scans, not serving-style point reads. A query may only need a few vectors or metadata fields, but the layout can force the engine to read much more.

𝗟𝗼𝗼𝗻 𝗿𝗲𝗱𝘂𝗰𝗲𝘀 𝘁𝗵𝗶𝘀 𝗿𝗲𝗮𝗱 𝗮𝗺𝗽𝗹𝗶𝗳𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗯𝘆 𝗼𝗿𝗴𝗮𝗻𝗶𝘇𝗶𝗻𝗴 𝗱𝗮𝘁𝗮 𝗶𝗻𝘁𝗼 𝗖𝗼𝗹𝘂𝗺𝗻𝗚𝗿𝗼𝘂𝗽𝘀 𝘄𝗶𝘁𝗵 𝗮𝗹𝗶𝗴𝗻𝗲𝗱 𝗿𝗼𝘄 𝗜𝗗𝘀. Different fields can then use layouts that match how they are actually accessed:
• Scalar fields can be laid out for filtering.
• Vectors and point-read-heavy fields can use layouts for narrow lookups.
• Vector and inverted indexes stay separate from the file format.
• Each dataset version is tracked by an immutable manifest.

In one internal benchmark, point-read Imilvus.io/blog/why-we-bu….4 MB with Parquet to 0.07 MB with Vortex and Loon. This matters because zero-copy search still needs a storage path built for retrieval workloads.

Blog: https://t.co/d4Fgu31EfN

💬0🔄1❤️6👀273📊2

⚡ Powered by xgo.ing

Milvus (@milvusio) — Wed, 29 Jul 2026 14:06:18 GMT

💬0🔄0❤️1👀105

⚡ Powered by xgo.ing

Milvus (@milvusio) — Wed, 29 Jul 2026 14:06:17 GMT

💬1🔄0❤️1👀119📊1

⚡ Powered by xgo.ing

🎉 We're so excited to announce that Milvus 3.0 is available today! This is the biggest architectura...

Milvus (@milvusio) — Wed, 29 Jul 2026 14:06:16 GMT

🎉 We're so excited to announce that Milvus 3.0 is available today! This is the biggest architectural release in the project's history, with two big shifts.

🌊 𝗦𝗛𝗜𝗙𝗧 𝟭 — 𝗟𝗮𝗸𝗲-𝗻𝗮𝘁𝗶𝘃𝗲 𝗶𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲
The problem: your vectors already live in the lake, but your search engine needs its own copy. So you build an ETL pipeline — and then maintain it forever. With Milvus 3.0, you get:

1. External Collections → index and serve data that stays in Parquet, Lance, Iceberg, or Vortex. No second copy, no sync job.

2. Loon (Storage v3) → a columnar engine built for the point reads that follow an ANN search. I/O per read went from 9.4 MB to 0.07 MB in our benchmarks.

3. Snapshots + Spark + live schema changes → dedupe, re-embed, and evaluate your data while the live collection keeps serving.

⚡ 𝗦𝗛𝗜𝗙𝗧 𝟮 — 𝗔 𝗺𝗼𝗿𝗲 𝗽𝗼𝘄𝗲𝗿𝗳𝘂𝗹 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗲𝗻𝗴𝗶𝗻𝗲
The problem: too much of your retrieval pipeline lives in application code. You over-fetch candidates, then sort, count, and reassemble them yourself. With Milvus 3.0, you get:

1. Server-side ORDER BY, aggregation, and faceted search → sort by price or freshness, count by category, all inside the engine.

2. StructArray → one row per document, many vectors inside. ColBERT and ColPali finally have a native home.

3. SINDI + BM25 compression → a sparse index ~3× smaller, with up to ~10× the QPS on learned sparse embeddings.

Put together: one system, one copy of your data, and a lot less glue code.

That matters most if you're building: 🤖 AI agents whose data changes constantly 🔍 Multimodal retrieval with late-interaction models 🔒 Governed systems where the data has to stay where it is 📚 RAG and knowledge bases over long documents 🛍️ Search that mixes relevance with price, rating, or inventory

🙏 Huge thanks to the Milvus community — you filed the issues, tested the release candidates, and told us what was actually painful. This releagithub.com/milvus-io/milv…wipe through for the milvus.io/blog/announcin…r#Milvust#VectorDatabaseU#AIInfrastructurec#RAGo#OpenSourcet.co/hq4qqZASuX
#Milvus#VectorDatabase#AIInfrastructure#RAG#OpenSource

💬1🔄3❤️12👀573📊4

⚡ Powered by xgo.ing

⭐ 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗘𝘅𝘁𝗲𝗿𝗻𝗮𝗹 𝗖𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻𝘀, 𝗮 𝘄𝗮𝘆 𝘁𝗼 ...

Milvus (@milvusio) — Tue, 28 Jul 2026 15:30:00 GMT

⭐ 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗘𝘅𝘁𝗲𝗿𝗻𝗮𝗹 𝗖𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻𝘀, 𝗮 𝘄𝗮𝘆 𝘁𝗼 𝗺𝗮𝗸𝗲 𝗹𝗮𝗸𝗲-𝗿𝗲𝘀𝗶𝗱𝗲𝗻𝘁 𝘃𝗲𝗰𝘁𝗼𝗿 𝗱𝗮𝘁𝗮 𝘀𝗲𝗮𝗿𝗰𝗵𝗮𝗯𝗹𝗲 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗰𝗼𝗽𝘆𝗶𝗻𝗴 𝗶𝘁 𝗶𝗻𝘁𝗼 𝗮 𝘀𝗲𝗿𝘃𝗶𝗻𝗴 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲.

Many teams already have embeddings and metadata in object storage: Parquet files in S3, Lance datasets, Iceberg tables, or other lakehouse formats.

Before Milvus 3.0, there were usually two ways to make that data searchable.
𝗢𝗽𝘁𝗶𝗼𝗻 𝗼𝗻𝗲: 𝗰𝗼𝗽𝘆 𝗶𝘁 𝗶𝗻𝘁𝗼 𝗮 𝘃𝗲𝗰𝘁𝗼𝗿 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲. You get low-latency ANN search, but now you have a second copy and an ETL pipeline to keep in sync.
𝗢𝗽𝘁𝗶𝗼𝗻 𝘁𝘄𝗼: 𝗾𝘂𝗲𝗿𝘆 𝘁𝗵𝗲 𝗹𝗮𝗸𝗲 𝗱𝗶𝗿𝗲𝗰𝘁𝗹𝘆. You avoid duplication, but without ANN indexes, vector search turns into a brute-force scan.

𝗘𝘅𝘁𝗲𝗿𝗻𝗮𝗹 𝗖𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻𝘀 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲 𝗮 𝘁𝗵𝗶𝗿𝗱 𝗽𝗮𝘁𝗵.
You keep the data where it is, map external fields into a Milvus schema, and use the same Milvus search and query APIs. Milvus builds vector, BM25 inverted, JSON, and scalar indexes over the lake-resident data. The source files do not move.

For teams where the lake owns permissions and freshness, every extra copy creates sync, access-control, and debugging work.

𝗔 𝗳𝗲𝘄 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝗱𝗲𝘁𝗮𝗶𝗹𝘀 𝗺𝗮𝘁𝘁𝗲𝗿:
• External Collections are read-only and zero-copy.
• Milvus can index newly added fragments instead of rebuilding the whole collection.
• Three load mmilvus.io/docs/create-an…etween lower storage cost and lower latency.

Native Milvus collections are better for write-heavy serving. External Collections are for lake datasets that need production search without another copy.
Know the details: https://t.co/NR2QfOORyC

💬0🔄0❤️7👀273📊1

⚡ Powered by xgo.ing

How do you combine structured filters and keyword signals with semantic similarity in ecommerce sear...

Milvus (@milvusio) — Mon, 27 Jul 2026 15:30:00 GMT

How do you combine structured filters and keyword signals with semantic similarity in ecommerce search?

Take this query:
“pink headphones for kids with ears under $20”
“Pink headphones for kids with ears” expresses semantic intent. “Under $20” is a hard price constraint. Ratings, reviews, brand, category, and visual similarity may also influence the results.
𝗦𝗼 𝗲𝗰𝗼𝗺𝗺𝗲𝗿𝗰𝗲 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗻𝗲𝗲𝗱𝘀 𝗺𝗼𝗿𝗲 𝘁𝗵𝗮𝗻 𝘃𝗲𝗰𝘁𝗼𝗿 𝘀𝗲𝗮𝗿𝗰𝗵 𝗮𝗹𝗼𝗻𝗲.

Lumen, a demo built by @Simon Hearne, shows how these signals can work together in a small Amazon-style product search experience.

The app combines:
• Query understanding to separate product intent from numeric filters  
• Dense vector search for semantic relevance  
• BM25 for exact keyword matching  
• Milvus filters for price, rating, reviews, brand, and category  
• Text and image vectors for “More like this” recommendations

A diagnostics panel also makes the retrieval process visible, including the effective Milvus query, embedding dimension, fusion strategy, and latency.

That transparency matters. Search quality may feel subjective to users, but builders need to identify exactly which signal failed when the results feel wrong.

Lumen keeps the scope intentionally small: one catalog, one search flow, and one clear retrieval stack. It’s a useful example of the components modern product discovery often needs—hybrid retrieval, metadata filtering, multimodal similarity, and an API layer thatvdb-ecom.pages.devials segithub.com/simonhearne/ve…ps://t.co/nMg9Lf9bBo
Repo: https://t.co/XYw6BzRVV1

💬0🔄0❤️2👀244📊1

⚡ Powered by xgo.ing

Embedding model selection used to be mostly a leaderboard question. In 2026, it feels much closer t...

Milvus (@milvusio) — Fri, 24 Jul 2026 15:15:00 GMT

Embedding model selection used to be mostly a leaderboard question.

In 2026, it feels much closer to a data-shape question.

A text knowledge base, a scanned contract, a product screenshot, a financial report, and a video archive contain different retrieval signals. Sending all of them through the same chunking and embedding pipeline can discard the information that matters most.

𝗙𝗼𝗿 𝗻𝗼𝗿𝗺𝗮𝗹 𝘁𝗲𝘅𝘁 𝗞𝗕𝘀, dense embeddings are still the practical starting point. Qwen3 Embedding, Jina v5 text, BGE-M3, OpenAI text-embedding-3, Voyage, and Cohere are all worth testing against your real chunks.

𝗙𝗼𝗿 𝗣𝗗𝗙𝘀, 𝗶𝗺𝗮𝗴𝗲𝘀, 𝘀𝗰𝗿𝗲𝗲𝗻𝘀𝗵𝗼𝘁𝘀, 𝗮𝘂𝗱𝗶𝗼, 𝗮𝗻𝗱 𝘃𝗶𝗱𝗲𝗼, models like Gemini Embedding 2, Jina v5 omni, Cohere Embed 4, Qwen3-VL-Embedding, and Voyage Multimodal are making it easier to keep more original context in retrieval.

𝗙𝗼𝗿 𝗹𝗼𝗻𝗴 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝘀, contextualized chunk embeddings like Voyage context-4 address a painful issue: chunks often lose meaning when separated from the full document.

𝗙𝗼𝗿 𝗰𝗼𝗺𝗽𝗹𝗲𝘅 𝗹𝗮𝘆𝗼𝘂𝘁𝘀, ColPali-style multi-vector retrieval is worth a look, especially when tables, figures, page regions, or scanned details decide the answer.

Benchmarks like MTEB, MMEB, and ViDoRe are useful filters. But the final test still has to be your own documents, your own queries, and your own failure cases.

𝗠𝗶𝗹𝘃𝘂𝘀 𝟮.𝟲 also moves part of the embedding plumbing into the database layer: with Text Embedding Function, you can insert raw text, let Milvus call the configured embedding provider, store the vectors, and run text queries without managing embedding calls in every client.

We wrote a practical guide on how to choose embedding models for the second half of 2026.

💬0🔄1❤️1👀355📊1

⚡ Powered by xgo.ing

𝗠𝘂𝗹𝘁𝗶-𝗵𝗼𝗽 𝗥𝗔𝗚 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗮 𝗴𝗿𝗮𝗽𝗵 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 Multi-hop retrieval is often ...

Milvus (@milvusio) — Thu, 23 Jul 2026 15:00:01 GMT

𝗠𝘂𝗹𝘁𝗶-𝗵𝗼𝗽 𝗥𝗔𝗚 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗮 𝗴𝗿𝗮𝗽𝗵 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲
Multi-hop retrieval is often solved by adding a separate graph store. We wanted to see how far we could get with Milvus alone — so we built an open-source library and found out.

Vector Graph RAG achieves multi-hop reasoning using only Milvus. Neo4j, Cypher queries, and the second system once needed to operate are all things of the past (in this scenario).

Vector Graph RAG is built upon the fact that knowledge graph relations are just text. An example, (metformin, is the first-line drug for, type 2 diabetes) is a directed edge in a graph database — but it's also a sentence you can embed and store in Milvus, alongside entities and source passages.

𝗩𝗲𝗰𝘁𝗼𝗿 𝗚𝗿𝗮𝗽𝗵 𝗥𝗔𝗚 𝘀𝘁𝗼𝗿𝗲𝘀 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴 𝗶𝗻 𝘁𝗵𝗿𝗲𝗲 𝗠𝗶𝗹𝘃𝘂𝘀 𝗰𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻𝘀 𝘄𝗶𝘁𝗵 𝗜𝗗 𝗰𝗿𝗼𝘀𝘀-𝗿𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀:• 𝗘𝗻𝘁𝗶𝘁𝗶𝗲𝘀 — deduplicated nodes, each carrying a list of the relation IDs they participate in
• 𝗥𝗲𝗹𝗮𝘁𝗶𝗼𝗻𝘀 — embedded triples pointing to the entity IDs and source passage IDs on each side
• 𝗣𝗮𝘀𝘀𝗮𝗴𝗲𝘀 — original document chunks with back-references to the extracted entities and relations

Those ID references are the graph structure. Subgraph expansion follows them to surface bridge entities that the question never mentions — the step that makes multi-hop reasoning work. Then a single LLM reranking pass filters the expanded candidate pool down to what actually answers the question, and one generation call produces the answer from the full source passages.

That pipeline makes 𝟮 𝗟𝗟𝗠 𝗰𝗮𝗹𝗹𝘀 𝗽𝗲𝗿 𝗾𝘂𝗲𝗿𝘆 (rerank + generate), compared to 3-5 for IRCoT and 5-10+ for Agentic RAG. Against a 5-call iterative baseline, that works out to roughly 𝟲𝟬% 𝗹𝗼𝘄𝗲𝗿 𝗔𝗣𝗜 𝗰𝗼𝘀𝘁 𝗮𝗻𝗱 𝟮-𝟯𝘅 𝗳𝗮𝘀𝘁𝗲𝗿 𝗿𝗲𝘀𝗽𝗼𝗻𝘀𝗲𝘀, with predictable latency instead of spikes when an agent decides to loop again.

On the benchmarks: 𝟴𝟳.𝟴% 𝗮𝘃𝗲𝗿𝗮𝗴𝗲 𝗥𝗲𝗰𝗮𝗹𝗹@𝟱 across MuSiQue, HotpotQA, and 2WikiMultiHopQA — against 𝟴𝟳.𝟭% for HippoRAG 2, under the same evaluation setup, with no graph database and no ColBERTv2.

𝗛𝗼𝘄github.com/zilliztech/vec…𝗹𝗹 𝘁𝗵𝗶𝘀? You only need to type"pip install vector-graph-rag". It defaults to Milvus Lite — a local .db file, so you don't need to configure anything. 
𝗙𝗼𝗿 𝗺𝗼𝗿𝗲 𝗶𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻, 𝘀𝗲𝗲 𝗶𝘁𝘀 𝗴𝗶𝘁𝗵𝘂𝗯 𝗽𝗮𝗴𝗲: https://t.co/uyBstuGBcq

If your corpus is knowledge-dense — legal, biomedical, financial — and your questions routinely cross 2-4 document boundaries, this is the architecture worth testing first.

💬2🔄3❤️7👀338📊4

⚡ Powered by xgo.ing

Semantic search, full-text search, metadata filtering, and hybrid retrieval in one open-source syste...

Milvus (@milvusio) — Thu, 23 Jul 2026 06:22:07 GMT

Semantic search, full-text search, metadata filtering, and hybrid retrieval in one open-source system. Thanks to @DanKornas for sharing this clear overview of Milvus and the use cases it supports.

Dan Kornas@DanKornas

Need one retrieval layer for semantic search, full-text search, and metadata filtering?

Milvus is an open-source vector database for AI engineers building RAG, semantic search, multimodal search, and recommendation systems.

It helps you organize and search unstructured data by storing vectors alongside scalar fields, then combining vector search with metadata filters, full-text search, or hybrid retrieval.

Key features:

• Dense and sparse retrieval – supports semantic vectors, BM25 full-text search, and learned sparse embeddings.
• Hybrid search – stores dense and sparse vectors together and can rerank results from multiple searches.
• Multiple index types – includes HNSW, IVF, FLAT, SCANN, DiskANN, and quantized variants.
• Flexible deployment – runs as Milvus Lite, on one machine in Standalone mode, or in a distributed, Kubernetes-native architecture.
• Access controls – includes user authentication, TLS encryption, and role-based access control.

It’s open-source (Apache 2.0 license).

Link in the reply 👇

🔗 View Quoted Tweet

💬0🔄0❤️2👀325

⚡ Powered by xgo.ing

Everyone is talking about agent memory, but the term is starting to hide more than it explains. For...

Milvus (@milvusio) — Wed, 22 Jul 2026 15:00:01 GMT

Everyone is talking about agent memory, but the term is starting to hide more than it explains.

For coding agents, it is not just “save chat history, embed it, retrieve top-k” anymore.

These open-source projects show that “agent memory” can mean very different things:

1. codebase-memory-mcp
github.com/DeusData/codeb…

Memory as codebase structure: functions, classes, call chains, routes, dependencies, and impact paths.

2. MemSearch
github.com/zilliztech/mem…

Memory as retrieval infrastructure: Markdown as the source of truth, Milvus as the index, plus hybrid search and progressive recall.

3. agentmemory
github.com/rohitg00/agent…

Memory as workspace context that follows coding agents across Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and MCP clients.

4. Basic Memory
github.com/basicmachines-…

Memory as a readable knowledge base: Markdown notes that humans can edit and agents can search.

5. ai-memory
github.com/akitaonrails/a…

Memory as continuity and handoff, so work can move between agent vendors without re-explaining architecture, failed attempts, and open questions.

These projects point to a simple trend: agent memory is moving from “store more context” to “retrieve the right context.”

For coding agents, memory is becoming less like a notes file and more like a retrieval layer.

💬2🔄0❤️2👀234📊3

⚡ Powered by xgo.ing

When 𝗞𝗶𝗺𝗶 𝗞𝟯 came out, we tested it right away. This is our experimental sharing: Kimi K3 has...

Milvus (@milvusio) — Tue, 21 Jul 2026 15:00:01 GMT

When 𝗞𝗶𝗺𝗶 𝗞𝟯 came out, we tested it right away. This is our experimental sharing:

Kimi K3 has 2.8T parameters, a 1M-token context window, native visual understanding, and strong coding-agent scores. After a few internal runs, we decided to move part of our workflow from Fable to K3.

The first surprise came from marketing.
One teammate in marketing used K3 to prototype a campaign landing page in one afternoon. Not production-ready, but enough to align the idea before involving engineering.

That was the good part.

The less fun part was the token bill.

Large-context coding agents can spend a lot of tokens just figuring out where things are in a repo. Kimi's pricing makes that visible: cache-hit input is $0.30/MTok, cache-miss input is $3.00/MTok, and output is $15.00/MTok.

So we added 𝗰𝗹𝗮𝘂𝗱𝗲-𝗰𝗼𝗻𝘁𝗲𝘅𝘁.

It gives coding agents semantic code search, so they retrieve relevant files and snippets instead of loading whole directories into the prompt.

In our controlled evaluation, Claude Context MCP reduced tokens by around 40% at equivalent retrieval quality.

K3 made the agent stronger. claude-context made it cheaper to aim that strength at the rigithub.com/zilliztech/cla…s://t.co/yyWCfHbgZv

💬0🔄0❤️4👀233📊1

⚡ Powered by xgo.ing

𝗛𝗼𝘄 𝗱𝗼 𝘆𝗼𝘂 𝗰𝗼𝗺𝗯𝗶𝗻𝗲 𝗮𝗴𝗲𝗻𝘁 𝗺𝗲𝗺𝗼𝗿𝘆 𝘄𝗶𝘁𝗵 𝘀𝗸𝗶𝗹𝗹𝘀? 𝗧𝗿𝘆 𝗼𝘂𝗿 ...

Milvus (@milvusio) — Mon, 20 Jul 2026 15:30:00 GMT

𝗛𝗼𝘄 𝗱𝗼 𝘆𝗼𝘂 𝗰𝗼𝗺𝗯𝗶𝗻𝗲 𝗮𝗴𝗲𝗻𝘁 𝗺𝗲𝗺𝗼𝗿𝘆 𝘄𝗶𝘁𝗵 𝘀𝗸𝗶𝗹𝗹𝘀? 𝗧𝗿𝘆 𝗼𝘂𝗿 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲 𝘁𝗼𝗼𝗹 𝗺𝗲𝗺𝘀𝗲𝗿𝗮𝗰𝗵 𝘁𝗵𝗮𝘁'𝘀 𝘂𝗽𝗱𝗮𝘁𝗲𝗱 𝘁𝗵𝗲 𝗳𝗲𝗮𝘁𝘂𝗿𝗲, 𝗺𝗲𝗺𝗼𝗿𝘆-𝘁𝗼-𝘀𝗸𝗶𝗹𝗹.

𝗔𝗴𝗲𝗻𝘁 𝗺𝗲𝗺𝗼𝗿𝘆 𝘁𝗵𝗮𝘁'𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝘃𝗮𝗹𝘂𝗮𝗯𝗹𝗲 𝗰𝗮𝗽𝘁𝘂𝗿𝗲𝘀 𝘁𝗵𝗿𝗲𝗲 𝘁𝗵𝗶𝗻𝗴𝘀: 𝘄𝗵𝗮𝘁 𝘁𝗵𝗲 𝗮𝗴𝗲𝗻𝘁 𝗸𝗻𝗼𝘄𝘀, 𝘄𝗵𝗮𝘁 𝗶𝘁 𝗵𝗮𝘀 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲𝗱, 𝗮𝗻𝗱 𝗵𝗼𝘄 𝗶𝘁 𝗱𝗼𝗲𝘀 𝘁𝗵𝗶𝗻𝗴𝘀.

Developers used to keep those in three separate systems: knowledge went into RAG, experience piled up in an agent memory layer, and procedures were written down as skill files.

But those memories — debug sessions, API integrations, releases, user corrections — are essentially part of the agent's skills too. Each one carries the scenario, the feedback, and the outcome. Plenty of reusable workflows are already hiding in there.

𝗦𝗼 𝘄𝗲 𝗯𝘂𝗶𝗹𝘁 𝗠𝗲𝗺𝗼𝗿𝘆-𝘁𝗼-𝗦𝗸𝗶𝗹𝗹 𝗶𝗻𝘁𝗼 𝗠𝗲𝗺𝗦𝗲𝗮𝗿𝗰𝗵, 𝘁𝗵𝗲 𝗮𝗴𝗲𝗻𝘁 𝗺𝗲𝗺𝗼𝗿𝘆 𝗹𝗶𝗯𝗿𝗮𝗿𝘆 𝘄𝗲 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲𝗱 𝗲𝗮𝗿𝗹𝗶𝗲𝗿 𝘁𝗵𝗶𝘀 𝘆𝗲𝗮𝗿.

An opt-in background pass mines your history for the workflows that keep recurring and are worth capturing, then automatically distills them into candidate skills. If a release workflow keeps showing up, the system recognizes it can be abstracted into a skill and writes it up as a candidate file. When the workflow changes later, the candidate evolves with it.

𝗕𝘂𝘁 𝗻𝗼 𝗮𝗴𝗲𝗻𝘁 𝗲𝘃𝗲𝗿 𝗮𝘂𝘁github.com/zilliztech/mem…𝗱𝗶𝗱𝗮𝘁𝗲 𝘀𝗸𝗶𝗹𝗹. It stays a draft. You review it, edit it, confirm it, and then install it into the skill directory of Claude Code, Codex, or other agents you use.

𝗠𝗲𝗺𝗦𝗲𝗮𝗿𝗰𝗵 𝗶𝘀 𝗼𝗽𝗲𝗻 𝘀𝗼𝘂𝗿𝗰𝗲. 𝗜𝗳 𝘆𝗼𝘂'𝗿𝗲 𝗮𝗹𝘀𝗼 𝘄𝗼𝗿𝗸𝗶𝗻𝗴 𝗼𝗻 𝗮𝗴𝗲𝗻𝘁 𝗺𝗲𝗺𝗼𝗿𝘆, 𝗹𝗼𝗻𝗴-𝘁𝗲𝗿𝗺 𝗰𝗼𝗻𝘁𝗲𝘅𝘁, 𝗼𝗿 𝗰𝗿𝗼𝘀𝘀-𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺 𝗔𝗜 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄𝘀, 𝗴𝗶𝘃𝗲 𝗶𝘁 𝗮 𝘁𝗿𝘆: https://t.co/eGAavvLonV

💬0🔄0❤️0👀192

⚡ Powered by xgo.ing

Semantic search in news feeds, e-commerce, and recommendation systems needs to balance relevance wit...

Milvus (@milvusio) — Fri, 17 Jul 2026 15:00:01 GMT

Semantic search in news feeds, e-commerce, and recommendation systems needs to balance relevance with freshness. 
𝗠𝗶𝗹𝘃𝘂𝘀 𝗽𝗿𝗼𝘃𝗶𝗱𝗲𝘀 𝘁𝗵𝗿𝗲𝗲 𝗱𝗲𝗰𝗮𝘆 𝗳𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝘀 𝗳𝗼𝗿 𝗿𝗲𝗿𝗮𝗻𝗸𝗶𝗻𝗴. Three decay models are available, each producing a different freshness curve:
• 𝗘𝘅𝗽𝗼𝗻𝗲𝗻𝘁𝗶𝗮𝗹: fast initial decay with a long tail. News and social feeds where recency should dominate.
• 𝗚𝗮𝘂𝘀𝘀𝗶𝗮𝗻: bell-shaped curve with gradual roll-off. Balanced search like restaurant recommendations, where moderate distance should reduce rather than eliminate a result's score.
• 𝗟𝗶𝗻𝗲𝗮𝗿: constant penalty with a clear cutoff point. Event search where anything older than two weeks should not appear at all.

In this test, the query is "artificial intelligence advancements," against seven articles spanning 1 to 120 days old, under four ranking approaches.

No decay: pure semantic similarity.
• Ranking is determined entirely by L2 distance (lower = more similar). Time is invisible.
• Two articles with nearly identical content but published 90 days apart score the same: 0.7090. The 90-day-old article sits at #1.
• An article about "AI Ethics Guidelines" scores lowest because "ethics" is semantically farther from "advancements" than the other articles, even though it is also about AI.

Gaussian decay (offset: 7 days, scale: 14 days, decay: 0.5)
• The two newest articles (1-day and 5-day) jump to the top two positions. Both fall within the 7-day offset, so they receive no time penalty and rank by their original semantic similarity.
• A 15-day-old article drops to 0.3601 but stays visible. A 30-day-old article falls to 0.0642.
• Everything older than 60 days: 0.0000. The bell curve penalizes gradually at first, then sharply.

Exponential decay (offset: 3 days, scale: 10 days, decay: 0.3)
• A 1-day-old article scores 0.5979. A 5-day-old article drops to 0.4774 because it has already exceeded the 3-day offset, even though it is still relatively new.
• At 15 days: 0.1065, far below Gaussian's 0.3601 for the same article. At 30 days: nearly zero.
• Under this configuration, the steepest curve. It forgets faster than Gaussian and penalizes harder at every age beyond the offset.

Linear decay: the most gradual decline.
• A 90-day-old article still scores 0.3037. A 120-day-old article: 0.2339. Both score zero under Gaussian and exponential.
• Because the penalty is constant rather than accelerating, semantic relevance carries more weight relative to time. A highly relevant 90-day-old article outranks a weakly relevant 30-day-old one: the time penalty was not steep enough to override the stronger semantic match.
• The slope is gentle, but linear decay does reach zero at a clear cutoff point, giving you a predictable expiration boundary.
𝗖𝗵𝗼�milvus.io/docs/tutorial-…𝘃𝗲 𝗺𝗮𝘁𝘁𝗲𝗿𝘀 𝗺𝗼𝗿𝗲 𝘁𝗵𝗮𝗻 𝗰𝗵𝗼𝗼𝘀𝗶𝗻𝗴 𝘁𝗼 𝗮𝗱𝗱 𝗱𝗲𝗰𝗮𝘆.

Learn more here:https://t.co/72j2ip5E7I

💬0🔄0❤️1👀253📊1

⚡ Powered by xgo.ing

𝗜𝗻 𝗲-𝗰𝗼𝗺𝗺𝗲𝗿𝗰𝗲 𝗮𝗻𝗱 𝗻𝗲𝘄𝘀 𝘀𝗲𝗮𝗿𝗰𝗵, 𝘀𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝘀𝗶𝗺𝗶𝗹𝗮𝗿𝗶𝘁𝘆 ...

Milvus (@milvusio) — Thu, 16 Jul 2026 15:00:01 GMT

𝗜𝗻 𝗲-𝗰𝗼𝗺𝗺𝗲𝗿𝗰𝗲 𝗮𝗻𝗱 𝗻𝗲𝘄𝘀 𝘀𝗲𝗮𝗿𝗰𝗵, 𝘀𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝘀𝗶𝗺𝗶𝗹𝗮𝗿𝗶𝘁𝘆 𝗮𝗹𝗼𝗻𝗲 𝗶𝘀 𝗻𝗼𝘁 𝗲𝗻𝗼𝘂𝗴𝗵 𝘁𝗼 𝗿𝗮𝗻𝗸 𝗿𝗲𝘀𝘂𝗹𝘁𝘀. Milvus's Time-aware Ranking Functions (also called Decay Functions) rerank retrieval results by applying time-decay functions, so recent content ranks higher without sacrificing relevance. 

Milvus's Decay Functions combining vector similarity with configurable time-decay to dynamically adjust each document's relevance score. 𝗧𝗵𝗲 𝘀𝗰𝗼𝗿𝗶𝗻𝗴 𝘄𝗼𝗿𝗸𝘀 𝗶𝗻 𝘁𝗵𝗿𝗲𝗲 𝘀𝘁𝗲𝗽𝘀:
• 𝗖𝗼𝗻𝘃𝗲𝗿𝘁 𝗱𝗶𝘀𝘁𝗮𝗻𝗰𝗲𝘀 𝗶𝗻𝘁𝗼 𝗵𝗶𝗴𝗵𝗲𝗿-𝗶𝘀-𝗯𝗲𝘁𝘁𝗲𝗿 𝘀𝗰𝗼𝗿𝗲𝘀. For L2 and JACCARD (lower = more similar): normalized_score = 1.0 − (2 × arctan(score)) / π. COSINE, IP, and BM25 scores are used directly.
• 𝗖𝗼𝗺𝗽𝘂𝘁𝗲 𝗮 𝗱𝗲𝗰𝗮𝘆 𝘀𝗰𝗼𝗿𝗲 from a numeric field like a timestamp, using one of three decay models: exponential, Gaussian, or linear. The result is a value between 0 and 1, representing how close the document is to a reference point (typically "now").
• 𝗠𝘂𝗹𝘁𝗶𝗽𝗹𝘆: final_score = normalized_similarity_score × decay_score. In hybrid search with multiple vector fields, Milvus takes the maximum normalized score first: final_score = max(normalized_scores) × decay_score.

Each model takes a configurable origin, scale (the distance beyond thmilvus.io/docs/decay-ran…core drops to the decay value), and an optional offset (a no-penalty zone around the origin where the score stays at 𝟭.𝟬).

𝗟𝗲𝗮𝗿𝗻 𝗺𝗼𝗿𝗲 𝗵𝗲𝗿𝗲: https://t.co/PLK2ouE4Dt

💬0🔄1❤️2👀231📊1

⚡ Powered by xgo.ing

𝗚𝗿𝗲𝗽-𝘀𝘁𝘆𝗹𝗲 𝘀𝗲𝗮𝗿𝗰𝗵 𝗶𝗻 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝘄𝗼𝗿𝗸𝘀 𝗳𝗼𝗿 𝗰𝗼𝗱𝗲 ...

Milvus (@milvusio) — Wed, 15 Jul 2026 15:30:00 GMT

𝗚𝗿𝗲𝗽-𝘀𝘁𝘆𝗹𝗲 𝘀𝗲𝗮𝗿𝗰𝗵 𝗶𝗻 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝘄𝗼𝗿𝗸𝘀 𝗳𝗼𝗿 𝗰𝗼𝗱𝗲 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹, 𝗯𝘂𝘁 𝗶𝘁 𝗯𝘂𝗿𝗻𝘀 𝘁𝗵𝗿𝗼𝘂𝗴𝗵 𝘁𝗼𝗸𝗲𝗻𝘀 𝘂𝗻𝗻𝗲𝗰𝗲𝘀𝘀𝗮𝗿𝗶𝗹𝘆. 𝗪𝗲 𝗯𝘂𝗶𝗹𝘁 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗻𝘁𝗲𝘅𝘁, 𝗮𝗻 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲 𝗠𝗖𝗣 𝘁𝗼𝗼𝗹 𝘁𝗵𝗮𝘁 𝗰𝘂𝘁𝘀 𝘁𝗼𝗸𝗲𝗻 𝘂𝘀𝗮𝗴𝗲 𝗯𝘆 ~𝟰𝟬%.

Grep-style code retrieval has drawn plenty of community discussion. For pure recall, literal matching gets the job done. But in a large codebase, it forces the model to wade through massive amounts of irrelevant code to find the few lines that matter.

𝗧𝗵𝗿𝗲𝗲 𝘁𝗵𝗶𝗻𝗴𝘀 𝗺𝗮𝗸𝗲 𝘁𝗵𝗶𝘀 𝗲𝘅𝗽𝗲𝗻𝘀𝗶𝘃𝗲 𝗮𝘁 𝘀𝗰𝗮𝗹𝗲:
• 𝗜𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 𝗼𝘃𝗲𝗿𝗹𝗼𝗮𝗱. Large repos produce hundreds of literal matches for common terms. Most are noise, but they all consume tokens and inference time.
• 𝗦𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝗯𝗹𝗶𝗻𝗱𝗻𝗲𝘀𝘀. Grep matches characters, not meaning. compute_final_cost() and calculate_total_price() do the same thing, but a string match won't connect them.
• 𝗜𝗻𝗰𝗼𝗺𝗽𝗹𝗲𝘁𝗲 𝗰𝗼𝗻𝘁𝗲𝘅𝘁. Line-level matches strip away the surrounding class and method structure. The model compensates by reading more files, burning more tokens.

𝗪𝗲 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲𝗱 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝘁𝗼 𝗮𝗱𝗱𝗿𝗲𝘀𝘀 𝗲𝘅𝗮𝗰𝘁𝗹𝘆 𝘁𝗵𝗶𝘀. 𝗜𝘁 𝗵𝗶𝘁 #𝟭 𝗼𝗻 𝗚𝗶𝘁𝗛𝘂𝗯'𝘀 𝗱𝗮𝗶𝗹𝘆 𝘁𝗿𝗲𝗻𝗱𝗶𝗻𝗴 𝗰𝗵𝗮𝗿𝘁 𝗮𝗻𝗱 𝗰𝘂𝗿𝗿𝗲𝗻𝘁𝗹𝘆 𝗵𝗮𝘀 𝗼𝘃𝗲𝗿 𝟭𝟮,𝟬𝟬𝟬 𝘀𝘁𝗮𝗿𝘀.

𝗜𝗻 𝗼𝘂𝗿 𝗯𝗲𝗻𝗰𝗵𝗺𝗮𝗿𝗸, 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗿𝗲𝗱𝘂𝗰𝗲𝗱 𝘁𝗼𝗸𝗲𝗻 𝗰𝗼𝗻𝘀𝘂𝗺𝗽𝘁𝗶𝗼𝗻 𝗯𝘆 ~𝟰𝟬% 𝗮𝘁 𝗲𝗾𝘂𝗶𝘃𝗮𝗹𝗲𝗻𝘁 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗾𝘂𝗮𝗹𝗶𝘁𝘆.
It's a code retrieval MCP server that integrates a vector database and embedding model into the search layer. It plugs into Claude Code and is also compatible with Codex CLI, Gemini CLI, Qwen Code, Cline, Cursor, Windsurf, and other MCP-compatible agents.

𝗜𝘁 𝗱𝗼𝗲𝘀 𝘁𝗵𝗿𝗲𝗲 𝘁𝗵𝗶𝗻𝗴𝘀 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁𝗹𝘆:
• 𝗦𝗺𝗮𝗿𝘁 𝗳𝗶𝗹𝘁𝗲𝗿𝗶𝗻𝗴. Vector similarity ranks code by relevance, surfacing the most related results first instead of every literal match.
• 𝗖𝗼𝗻𝗰𝗲𝗽𝘁 𝗺𝗮𝘁𝗰𝗵𝗶𝗻𝗴. Dense retrieval can match conceptually related code even when function names differ entirely.
• 𝗖𝗼𝗻𝘁𝗲𝘅𝘁-𝗮𝘄𝗮𝗿𝗲 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹. Results are chunked around complete syntactic units (functions, classes, methods), giving the model enough structural context to reason about behavior.

Under the hood, Claude Context uses MCP as its interface layer and Milvus for codebase indexing and hybrid search (BM25 + dense vectors). Embeddings support OpenAI, VoyageAI (which ships a code-specific model), and Ollama for local deployment when privacy matters.

Cgithub.com/zilliztech/cla…arsing by default, splitting along semmilvus.io/blog/claude-co…d of cutting at arbitrary line counts. For files AST can't parse, LangChain's text splitter handles the fallback.

For incremental updates, Claude Context uses Merkle-tree change detection. If the root hash hasn't changed, the index stays untouched. When it changes, the system identifies exactly which files were modified and re-embeds only those.

Change one function, and you don't re-index the entire project.

🔗 https://t.co/yyWCfHbgZv

 📝 Full benchmark and architecture: https://t.co/Sevmvp37HT

💬0🔄4❤️10👀720📊4

⚡ Powered by xgo.ing

Using a demo to estimate the real production cost of a vector database is where cost planning goes w...

Milvus (@milvusio) — Tue, 14 Jul 2026 15:00:02 GMT

Using a demo to estimate the real production cost of a vector database is where cost planning goes wrong for many teams.

The demo phase can give you a reasonable answer on two things:
• Storage: embeddings, raw content, metadata, scalar fields, and index files.
• Online serving: the compute needed for the current query volume and latency target.

But a demo usually cannot answer three other cost questions:
• Updates: how often data is added, deleted, re-embedded, re-indexed, or checked for recall regressions.
• Workload mismatch: whether offline analysis, evaluation, or batch jobs are running on always-on infrastructure.
• Duplication: how many copies of the same AI data end up across vector search, lakehouse, training, evaluation, and governance systems.

Different data scales and usage frequencies require different resource models.
For example, one autonomous driving workload needed vector search over a 1B-row collection for analysis.
𝗔 𝗱𝗲𝗱𝗶𝗰𝗮𝘁𝗲𝗱 𝗰𝗹𝘂𝘀𝘁𝗲𝗿 was estimated at about $7,000 per month. 𝗦𝗲𝗿𝘃𝗲𝗿𝗹𝗲𝘀𝘀 was about $10,800 per month. But the workload only ran for a few hours each month. With 𝗭𝗶𝗹𝗹𝗶𝘇 𝗖𝗹𝗼𝘂𝗱 𝗢𝗻-𝗗𝗲𝗺𝗮𝗻𝗱 𝗦𝗲𝗮𝗿𝗰𝗵, the cost came in under $500 per month.

In enterprise environments, however, these workload patterns usually coexist. A single system may have steady online traffic, offline batch processing, evaluation jobs, and sudden demand spikes.
The goal is not to choose one resource model for everything. It is to accurately identify each workload and match it to the right instance type.
Use dedicated capacity for steady, latency-sensitive traffic; serverless for unpredictable or spiky online demand; and on-demand compute for low-frequency analysis, evaluation, and batch jobs.

💬0🔄0❤️1👀200

⚡ Powered by xgo.ing

Duplicate text in your LLM pre-training corpus drives up training cost and reweights parts of the tr...

Milvus (@milvusio) — Mon, 13 Jul 2026 15:02:00 GMT

Duplicate text in your LLM pre-training corpus drives up training cost and reweights parts of the training data. 𝗠𝗶𝗻𝗛𝗮𝘀𝗵 𝗟𝗦𝗛 𝗺𝗮𝗸𝗲𝘀 𝘀𝗰𝗮𝗹𝗮𝗯𝗹𝗲 𝗱𝗲𝗱𝘂𝗽 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹, 𝗮𝗻𝗱 𝗠𝗶𝗹𝘃𝘂𝘀 𝟮.𝟲 𝗮𝗱𝗱𝗲𝗱 𝗶𝘁 𝗮𝘀 𝗮 𝗻𝗮𝘁𝗶𝘃𝗲 𝗶𝗻𝗱𝗲𝘅 𝘁𝘆𝗽𝗲.

The usual dedup options break down quickly:
• 𝗘𝘅𝗮𝗰𝘁 𝗺𝗮𝘁𝗰𝗵𝗶𝗻𝗴 is too strict for text dedup. Near-identical documents often differ by boilerplate, formatting, punctuation, or minor edits, and exact comparison misses all of them.
• 𝗣𝗮𝗶𝗿𝘄𝗶𝘀𝗲 𝗰𝗼𝗺𝗽𝗮𝗿𝗶𝘀𝗼𝗻 catches more, but the computation explodes with data volume. At millions of documents, it's infeasible.

𝗠𝗶𝗻𝗛𝗮𝘀𝗵 𝗟𝗦𝗛 works well as a coarse-pass filter. It's approximate deduplication with a tunable recall/precision tradeoff, fast enough to run inline during ingestion to check candidates before storing redundant content.

𝗠𝗶𝗹𝘃𝘂𝘀 𝟮.𝟲 𝗮𝗱𝗱𝗲𝗱 𝗻𝗮𝘁𝗶𝘃𝗲 𝗠𝗶𝗻𝗛𝗮𝘀𝗵 𝗟𝗦𝗛 𝗶𝗻𝗱𝗲𝘅𝗶𝗻𝗴 𝘄𝗶𝘁𝗵 𝗮 𝗱𝗲𝗱𝗶𝗰𝗮𝘁𝗲𝗱 𝗺𝗲𝘁𝗿𝗶𝗰 𝘁𝘆𝗽𝗲, 𝗹𝗲𝘁𝘁𝗶𝗻𝗴 𝘁𝗲𝗮𝗺𝘀 𝗶𝗻𝗱𝗲𝘅 𝗮𝗻𝗱 𝘀𝗲𝗮𝗿𝗰𝗵 𝗠𝗶𝗻𝗛𝗮𝘀𝗵 𝘀𝗶𝗴𝗻𝗮𝘁𝘂𝗿𝗲𝘀 𝗳𝗼𝗿 𝗱𝘂𝗽𝗹𝗶𝗰𝗮𝘁𝗲 𝗮𝗻𝗱 𝗻𝗲𝗮𝗿-𝗱𝘂𝗽𝗹𝗶𝗰𝗮𝘁𝗲 𝗱𝗲𝘁𝗲𝗰𝘁𝗶𝗼𝗻 𝗮𝘁 𝗰𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻 𝘀𝗰𝗮𝗹𝗲.

𝗪𝗵𝗲𝗿𝗲 𝘁𝗵𝗶𝘀 𝗵𝗲𝗹𝗽𝘀:
• 𝗟𝗟𝗠 𝘁𝗿𝗮𝗶𝗻𝗶𝗻𝗴 𝗱𝗮𝘁𝗮 𝗰𝗹𝗲𝗮𝗻𝗶𝗻𝗴: removing duplicate text from crawled corpora before training begins
• 𝗟𝗮𝗿𝗴𝗲-𝘀𝗰𝗮𝗹𝗲 𝗽𝗹𝗮𝗴𝗶𝗮𝗿𝗶𝘀𝗺 𝘀𝗰𝗿𝗲𝗲𝗻𝗶𝗻𝗴: detecting substantial text overlap in academic or content pipelines as a coarse-pass filter

𝗟𝗶𝗺𝗶𝘁𝗮𝘁𝗶𝗼𝗻: MinHash operates on token-set overlap, not word order or semantics. It catches verbatim and near-verbatim duplication but won't flag paraphrases. For semantic or paraphrase-level deduplication, teams layer in SimHash, TF-IDF with cosine similarity, or embedding-based methods.

In Milvus, MinHash signatures are stored as 𝗯𝗶𝗻𝗮𝗿𝘆 𝘃𝗲𝗰𝘁𝗼𝗿𝘀 approximating 𝗝𝗮𝗰𝗰𝗮𝗿𝗱 𝘀𝗶𝗺𝗶𝗹𝗮𝗿𝗶𝘁𝘆 between document token sets. Standard metrics like Jaccard, L2, or cosine can't be applied directly to these signatures, so Milvus introduced a dedicated metric called 𝗠𝗛𝗝𝗔𝗖𝗖𝗔𝗥𝗗. For higher accuracy, Milvus also supports a refined search mode that recomputes exact Jaccard using stored token sets, reducing false positives.

The dedup pipeline:
• 𝗦𝗲𝘁𝘂𝗽: Create a collection with a 𝗠𝗜𝗡𝗛𝗔𝗦𝗛_𝗟𝗦𝗛 index, using the MHJACCARD metric and configurable LSH parameters (e.g., band count)
• 𝗦𝗶𝗴𝗻𝗮𝘁𝘂𝗿𝗲 𝗴𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻: For each incoming document, tokenize or shingle it and generate a MinHash signature (e.g., using milvus.io/docs/minhash-l…�𝗰𝗮𝘁𝗲 𝗰𝗵𝗲𝗰𝗸: Search the collection with the new signature to find existing near-duplicates
• 𝗜𝗻𝘀𝗲𝗿𝘁: Store only documents that don't exceed your similarity threshold, alongside metadata

An AI model company used this pipeline to deduplicate 𝟭𝟬 𝗯𝗶𝗹𝗹𝗶𝗼𝗻 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝘀 for LLM training, more than doubling throughput and cutting costs 𝟯-𝟱𝘅 compared to their previous MapReduce-based approach.

More info here: https://t.co/3JQyKaXSCi

💬0🔄0❤️2👀236

⚡ Powered by xgo.ing

Debugging a slow Milvus cluster once meant bouncing between the console, Grafana, and several monito...

Milvus (@milvusio) — Fri, 10 Jul 2026 15:30:00 GMT

Debugging a slow Milvus cluster once meant bouncing between the console, Grafana, and several monitoring views just to find out where to look.
𝗧𝗼𝗱𝗮𝘆, 𝘄𝗶𝘁𝗵 𝗔𝘁𝘁𝘂 𝟯.𝟬 𝗯𝗲𝘁𝗮, 𝗰𝗹𝘂𝘀𝘁𝗲𝗿 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀 𝗮𝗿𝗲 𝗮𝗹𝗹 𝗼𝗻 𝗼𝗻𝗲 𝘀𝗰𝗿𝗲𝗲𝗻. 𝗬𝗼𝘂 𝗰𝗮𝗻 𝗰𝗵𝗲𝗰𝗸:
• 𝗢𝘃𝗲𝗿𝘃𝗶𝗲𝘄: version, deployment mode, node count, database count, collection count, and total entity count
• 𝗥𝗲𝗮𝗹-𝘁𝗶𝗺𝗲 𝗺𝗲𝘁𝗿𝗶𝗰𝘀: QPS, insert/delete rates, query latency, cache hit rate, and storage, pulled from a Prometheus endpoint without opening Grafana separately
• 𝗦𝗹𝗼𝘄-𝗾𝘂𝗲𝗿𝘆 𝗮𝗻𝗮𝗹𝘆𝘀𝗶𝘀: slow queries by type, duration, collection, timestamp, and user
• 𝗧𝗼𝗽𝗼𝗹𝗼𝗴𝘆 𝘃𝗶𝗲𝘄: node topology and coordinator component status
• 𝗕𝗮𝗰𝗸𝘂𝗽 𝗮𝗻𝗱 𝗿𝗲𝘀𝘁𝗼𝗿𝗲: full or incremental backups to S3, MinIO, GCS, or Azure

For teams running several Milvus clusters, the multi-cluster sidebar gives you a quick read on cluster state before you start digging. The point is that the first pass of cluster inspection no longer has to start with five tabsmilvus.io/blog/attu-3-0-…𝗧𝗵𝗲 𝗳𝘂𝗹𝗹 𝗔𝘁𝘁𝘂 𝟯.𝟬 𝗿𝗲𝗯𝘂𝗶𝗹𝗱, 𝗶𝗻𝗰𝗹𝘂𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 𝗺𝘂𝗹𝘁𝗶-𝗰𝗹𝘂𝘀𝘁𝗲𝗿 𝘀𝗶𝗱𝗲𝗯𝗮𝗿 𝗮𝗻𝗱 𝗯𝘂𝗶𝗹𝘁-𝗶𝗻 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁, 𝗶𝘀 𝗼𝗻 𝘁𝗵𝗲 𝗠𝗶𝗹𝘃𝘂𝘀 𝗯𝗹𝗼𝗴: https://t.co/LLfUcMHsnF

💬0🔄0❤️2👀257📊1

⚡ Powered by xgo.ing

𝗙𝗼𝗿 𝗮 𝗥𝗔𝗚 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲, 𝗱𝗼 𝘆𝗼𝘂 𝗰𝗵𝘂𝗻𝗸 𝗳𝗶𝗿𝘀𝘁 𝗼𝗿 𝗲𝗺𝗯𝗲𝗱 𝗳𝗶𝗿𝘀𝘁? The...

Milvus (@milvusio) — Thu, 09 Jul 2026 15:30:00 GMT

𝗙𝗼𝗿 𝗮 𝗥𝗔𝗚 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲, 𝗱𝗼 𝘆𝗼𝘂 𝗰𝗵𝘂𝗻𝗸 𝗳𝗶𝗿𝘀𝘁 𝗼𝗿 𝗲𝗺𝗯𝗲𝗱 𝗳𝗶𝗿𝘀𝘁?
The standard RAG pipeline chunks documents before embedding them. 𝗔 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗽𝗮𝘁𝘁𝗲𝗿𝗻 𝗶𝘀 𝘀𝘁𝗮𝗿𝘁𝗶𝗻𝗴 𝘁𝗼 𝘀𝗵𝗼𝘄 𝘂𝗽: 𝗲𝗺𝗯𝗲𝗱 𝗮𝗹𝗹 𝘀𝗲𝗻𝘁𝗲𝗻𝗰𝗲𝘀 𝗳𝗶𝗿𝘀𝘁, 𝘁𝗵𝗲𝗻 𝘂𝘀𝗲 𝘁𝗵𝗲𝗶𝗿 𝘀𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝘀𝗶𝗺𝗶𝗹𝗮𝗿𝗶𝘁𝘆 𝘁𝗼 𝗱𝗲𝗰𝗶𝗱𝗲 𝘄𝗵𝗲𝗿𝗲 𝘁𝗼 𝗰𝗵𝘂𝗻𝗸. Max-Min Semantic Chunking is one example.

𝗪𝗵𝘆 𝗲𝗺𝗯𝗲𝗱 𝗳𝗶𝗿𝘀𝘁? Because the standard RAG pipeline chunks documents before embedding them, which means boundaries are usually drawn without embedding-based similarity signals. Embedding all sentences upfront gives the algorithm similarity data to work with, so boundaries can follow actual shifts in meaning.

𝗜𝗻 𝗺𝗮𝗻𝘆 𝗥𝗔𝗚 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲𝘀, 𝗰𝗵𝘂𝗻𝗸𝗶𝗻𝗴 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝗯𝗲𝗳𝗼𝗿𝗲 𝗲𝗺𝗯𝗲𝗱𝗱𝗶𝗻𝗴, 𝗮𝗻𝗱 𝗰𝗵𝘂𝗻𝗸 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝘀𝘁𝗿𝗼𝗻𝗴𝗹𝘆 𝗮𝗳𝗳𝗲𝗰𝘁𝘀 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗾𝘂𝗮𝗹𝗶𝘁𝘆. The conventional sequence runs: chunk → embed → index in a vector database like Milvus → retrieve → generate. 

But at the chunking step, fixed-length and recursive splitting do not fully remove the tradeoff. Smaller chunks tend to improve precision but can lose context. Larger chunks preserve more context but can introduce noise.

𝗠𝗮𝘅-𝗠𝗶𝗻 𝗦𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝗖𝗵𝘂𝗻𝗸𝗶𝗻𝗴 𝗶𝘀 𝗼𝗻𝗲 𝗺𝗲𝘁𝗵𝗼𝗱 𝗴𝗮𝗶𝗻𝗶𝗻𝗴 𝘁𝗿𝗮𝗰𝘁𝗶𝗼𝗻 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝗲𝗺𝗯𝗲𝗱-𝗳𝗶𝗿𝘀𝘁 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵. It treats chunking as a sequential clustering problem: walk through the document in order, decide at each sentence whether it joins the current chunk or starts a new one. 𝗦𝗲𝗻𝘁𝗲𝗻𝗰𝗲𝘀 𝗺𝘂𝘀𝘁 𝘀𝘁𝗮𝘆 𝗰𝗼𝗻𝘀𝗲𝗰𝘂𝘁𝗶𝘃𝗲, 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗮𝗹𝗴𝗼𝗿𝗶𝘁𝗵𝗺 𝗻𝗲𝘃𝗲𝗿 𝗿𝗲𝗮𝗿𝗿𝗮𝗻𝗴𝗲𝘀 𝘁𝗲𝘅𝘁.

𝗛𝗲𝗿𝗲'𝘀 𝗵𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀, 𝘀𝘁𝗲𝗽 𝗯𝘆 𝘀𝘁𝗲𝗽:
• 𝗘𝗺𝗯𝗲𝗱 𝘁𝗵𝗲 𝘀𝗲𝗻𝘁𝗲𝗻𝗰𝗲𝘀 𝗳𝗶𝗿𝘀𝘁: A text embedding model maps all sentences to high-dimensional space. Suppose the first n−k sentences have been assigned to the current chunk C. The decision now is whether sentence n−k+1 joins C or starts a new chunk.
• 𝗖𝗼𝗺𝗽𝘂𝘁𝗲 𝗺𝗶𝗻𝗶𝗺𝘂𝗺 𝘀𝗶𝗺𝗶𝗹𝗮𝗿𝗶𝘁𝘆 𝘄𝗶𝘁𝗵𝗶𝗻 𝘁𝗵𝗲 𝗰𝗵𝘂𝗻𝗸: Calculate the minimum pairwise cosine similarity among all sentence vectors in C. This identifies the most semantically dissimilar pair, measuring how tightly the group holds together, and sets the bar for whether the new sentence belongs.
• 𝗖𝗼𝗺𝗽𝘂𝘁𝗲 𝗺𝗮𝘅𝗶𝗺𝘂𝗺 𝘀𝗶𝗺𝗶𝗹𝗮𝗿𝗶𝘁𝘆 𝘁𝗼 𝘁𝗵𝗲 𝗻𝗲𝘄 𝘀𝗲𝗻𝘁𝗲𝗻𝗰𝗲: Calculate the maximum cosine similarity between the new sentence and every sentence in C. This captures the strongest connection the incoming sentence has to the existing group.
• 𝗧𝗵𝗲 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻 𝗿𝘂𝗹𝗲: If the new sentence's strongest connection to the chunk beats the chunk's weakest internal link, it joins. Otherwise, a new chunk begins.
• 𝗨𝘀𝗲 𝘀𝗶𝘇𝗲 𝗹𝗶𝗺𝗶𝘁𝘀 𝗮𝗻𝗱 𝘀𝗶𝗺𝗶𝗹𝗮𝗿𝗶𝘁𝘆 𝘁𝗵𝗿𝗲𝘀𝗵𝗼𝗹𝗱𝘀 𝘁𝗼 𝗸𝗲𝗲𝗽 𝗰𝗵𝘂𝗻𝗸𝘀 𝗳𝗿𝗼𝗺 𝗴𝗿𝗼𝘄𝗶𝗻𝗴 𝘁𝗼𝗼 𝗹𝗼𝗼𝘀milvus.io/blog/embedding…unk coherence, dynamically adjust chunk size limits and similarity thresholds.
• 𝗜𝗻𝗶𝘁𝗶𝗮𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻: When the chunk has only one sentence, there's no internal minimum to compute. Compare the similarity between the first and second sentence against a preset threshold constant. Above it, they chunk together. Below it, they split.

𝗠𝗮𝘅-𝗠𝗶𝗻 𝗵𝗮𝘀 𝗶𝘁𝘀 𝘁𝗿𝗮𝗱𝗲𝗼𝗳𝗳: because it clusters sequentially and locally, it can miss long-range context dependencies in long documents. Important information spread across distant sections may end up in separate chunks.

Full walkthrough with code: https://t.co/QqyHQ4U2Rq

💬0🔄1❤️2👀311📊1

⚡ Powered by xgo.ing

𝗠𝗶𝗹𝘃𝘂𝘀 𝗰𝗼𝗺𝗽𝗮𝗰𝘁𝘀 𝘀𝗲𝗴𝗺𝗲𝗻𝘁𝘀 𝗱𝘂𝗿𝗶𝗻𝗴 𝗻𝗼𝗿𝗺𝗮𝗹 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀, ...

Milvus (@milvusio) — Wed, 08 Jul 2026 15:30:00 GMT

𝗠𝗶𝗹𝘃𝘂𝘀 𝗰𝗼𝗺𝗽𝗮𝗰𝘁𝘀 𝘀𝗲𝗴𝗺𝗲𝗻𝘁𝘀 𝗱𝘂𝗿𝗶𝗻𝗴 𝗻𝗼𝗿𝗺𝗮𝗹 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀, 𝗯𝘂𝘁 𝘄𝗶𝘁𝗵𝗶𝗻 𝗰𝗲𝗿𝘁𝗮𝗶𝗻 𝗹𝗶𝗺𝗶𝘁𝘀. 𝗢𝗻𝗰𝗲 𝘁𝗵𝗲 𝗱𝗮𝘁𝗮 𝘀𝗲𝘁𝘁𝗹𝗲𝘀, 𝘁𝗵𝗲 𝗳𝗿𝗮𝗴𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗹𝗲𝗳𝘁 𝗯𝗲𝗵𝗶𝗻𝗱 𝘁𝗮𝘅𝗲𝘀 𝗲𝘃𝗲𝗿𝘆 𝗾𝘂𝗲𝗿𝘆. 𝗔𝗱𝗱𝗿𝗲𝘀𝘀 𝗶𝘁 𝘄𝗶𝘁𝗵 𝗙𝗼𝗿𝗰𝗲 𝗠𝗲𝗿𝗴𝗲 𝗖𝗼𝗺𝗽𝗮𝗰𝘁𝗶𝗼𝗻.

During ingestion, Milvus writes data into segments and seals them as part of the ingestion path. Merging them aggressively at that point would compete with ingestion resources, so the system leaves them as they are. That is the right default while data is still changing.

The problem: Milvus does not have your application-level signal that ingestion is complete. After a bulk load wraps up, a knowledge-base refresh completes, or a migration lands, those write-optimized segments stay in place. Search queries may continue to fan out across more sealed segments than necessary.

𝗙𝗼𝗿𝗰𝗲 𝗠𝗲𝗿𝗴𝗲 𝗖𝗼𝗺𝗽𝗮𝗰𝘁𝗶𝗼𝗻 𝗶𝘀 𝗵𝗼𝘄 𝘆𝗼𝘂 𝗽𝗮𝘀𝘀 𝘁𝗵𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝗮 𝘀𝗶𝗴𝗻𝗮𝗹 𝗶𝘁 𝗰𝗮𝗻𝗻𝗼𝘁 𝗶𝗻𝗳𝗲𝗿 𝗼𝗻 𝗶𝘁𝘀 𝗼𝘄𝗻: 𝘁𝗵𝗲 𝗱𝗮𝘁𝗮 𝗵𝗮𝘀 𝘀𝗲𝘁𝘁𝗹𝗲𝗱, 𝗿𝗲𝘀𝗵𝗮𝗽𝗲 𝘁𝗵𝗲 𝗹𝗮𝘆𝗼𝘂𝘁 𝗳𝗼𝗿 𝗿𝗲𝗮𝗱𝘀.

The tradeoff is explicit. In our benchmark, the merge and index rebuild used all 16 cores during the merge and rebuild in our single-node benchmark. On a cluster, you can isolate that cost on separate DataNode and QueryNode resources. On a single node, time it for a quiet window.

𝗪𝗵𝗲𝗻 𝗙𝗼𝗿𝗰𝗲 𝗠𝗲𝗿𝗴𝗲 𝗳𝗶𝘁𝘀:
• The collection has shifted from writes to reads
• Search throughput is the bottleneck, not ingestion
• You have a maintenance window or separated cluster resources
• You can measure segment coumilvus.io/blog/force-mer…confirm the gain

𝗪𝗵𝗲𝗻 𝗶𝘁 𝗱𝗼𝗲𝘀 𝗻𝗼𝘁:
• The collection still takes steady writes or updates
• Resources are already tight with no room for the rebuild
• You are in peak traffic with no quiet window

𝗙𝗼𝗿𝗰𝗲 𝗠𝗲𝗿𝗴𝗲 𝗶𝘀 𝗶𝗻 𝗽𝘂𝗯𝗹𝗶𝗰 𝗽𝗿𝗲𝘃𝗶𝗲𝘄. 𝗥𝗲𝗮𝗱 𝗮𝗯𝗼𝘂𝘁 𝗼𝘂𝗿 𝗲𝘅𝗽𝗲𝗿𝗶𝗺𝗲𝗻𝘁 𝗵𝗲𝗿𝗲: https://t.co/bDv1Y1Qlpn

💬0🔄0❤️2👀204📊1

⚡ Powered by xgo.ing

𝗡𝗲𝗮𝗿𝗹𝘆 𝗵𝗮𝗹𝗳 𝘆𝗼𝘂𝗿 𝗠𝗶𝗹𝘃𝘂𝘀 𝘀𝗲𝗮𝗿𝗰𝗵 𝗰𝗮𝗽𝗮𝗰𝗶𝘁𝘆 𝗺𝗮𝘆 𝗯𝗲 ...

Milvus (@milvusio) — Tue, 07 Jul 2026 15:30:00 GMT

𝗡𝗲𝗮𝗿𝗹𝘆 𝗵𝗮𝗹𝗳 𝘆𝗼𝘂𝗿 𝗠𝗶𝗹𝘃𝘂𝘀 𝘀𝗲𝗮𝗿𝗰𝗵 𝗰𝗮𝗽𝗮𝗰𝗶𝘁𝘆 𝗺𝗮𝘆 𝗯𝗲 𝗴𝗲𝘁𝘁𝗶𝗻𝗴 𝗯𝘂𝗿𝗻𝗲𝗱 𝗼𝗻 𝘀𝗲𝗴𝗺𝗲𝗻𝘁-𝗹𝗲𝘃𝗲𝗹 𝗼𝘃𝗲𝗿𝗵𝗲𝗮𝗱. 𝗔𝗱𝗱𝗿𝗲𝘀𝘀 𝗶𝘁 𝘄𝗶𝘁𝗵 𝗙𝗼𝗿𝗰𝗲 𝗠𝗲𝗿𝗴𝗲 𝗖𝗼𝗺𝗽𝗮𝗰𝘁𝗶𝗼𝗻.

When a collection grows through continuous writes, Milvus keeps each sealed segment indexed separately. During ingestion that makes sense — you don't want to rebuild indexes while data is still flowing in.

After the data settles, fragmentation can remain. Queries fan out across the relevant sealed segments, and the per-segment overhead adds up: separate index searches, scheduling, result merging. The total data hasn't changed, but the query cost has.

We measured this on a 1M-vector HNSW collection. One change — consolidating 3 segments into 1 with Force Merge Compaction:
• 𝗤𝗣𝗦: ~𝟯,𝟬𝟬𝟬 → ~𝟱,𝟰𝟬𝟬–𝟱,𝟴𝟬𝟬 (roughly 1.8x QPS)
• 𝗽𝟵𝟵 𝗹𝗮𝘁𝗲𝗻𝗰𝘆: down roughly a third
• 𝗦𝗮𝗺𝗲 𝗵𝗮𝗿𝗱𝘄𝗮𝗿𝗲, 𝘀𝗮𝗺𝗲 𝗶𝗻𝗱𝗲𝘅, 𝘀𝗮𝗺𝗲 𝗱𝗮𝘁𝗮

That gap is the fan-out tax. Fewer segments means less overhead per query, and the CPU freed up serves more queries instead.

Force Merge lets you reclaim that headroom with 𝗼𝗻𝗲 𝗽𝗹𝗮𝗻𝗻𝗲𝗱 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻 after ingestion wraps up — a single rebuild, then sustained gains for similar search workloads.

𝗦𝗲𝘁�milvus.io/blog/force-mer…m, HNSW, single-node Docker Compose (16 cores / 64 GB), VDBBench Cohere 1M, Milvus 2.6.17

𝗙𝗼𝗿𝗰𝗲 𝗠𝗲𝗿𝗴𝗲 𝗶𝘀 𝗶𝗻 𝗽𝘂𝗯𝗹𝗶𝗰 𝗽𝗿𝗲𝘃𝗶𝗲𝘄. 𝗙𝘂𝗹𝗹 𝗲𝘅𝗽𝗲𝗿𝗶𝗺𝗲𝗻𝘁 𝗱𝗲𝘁𝗮𝗶𝗹𝘀 𝗶𝗻 𝘁𝗵𝗲 𝗯𝗹𝗼𝗴: https://t.co/piY1PcWznq

💬0🔄0❤️2👀239📊1

⚡ Powered by xgo.ing

𝗔𝗱𝗱𝗶𝗻𝗴 𝗮𝗻 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁 𝘁𝗼 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝘁𝗼𝗼𝗹𝗶𝗻𝗴 𝗿𝗮𝗶𝘀𝗲𝘀 𝗮𝗻 ...

Milvus (@milvusio) — Mon, 06 Jul 2026 15:30:00 GMT

𝗔𝗱𝗱𝗶𝗻𝗴 𝗮𝗻 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁 𝘁𝗼 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝘁𝗼𝗼𝗹𝗶𝗻𝗴 𝗿𝗮𝗶𝘀𝗲𝘀 𝗮𝗻 𝗼𝗯𝘃𝗶𝗼𝘂𝘀 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻: 𝗪𝗵𝗲𝗿𝗲 𝗱𝗼 𝗺𝘆 𝗱𝗮𝘁𝗮 𝗮𝗻𝗱 𝗟𝗟𝗠 𝗰𝗿𝗲𝗱𝗲𝗻𝘁𝗶𝗮𝗹𝘀 𝗴𝗼?
𝗔𝘁𝘁𝘂 𝟯.𝟬 𝗯𝗲𝘁𝗮 𝘁𝗮𝗸𝗲𝘀 𝗮 𝗯𝗿𝗶𝗻𝗴-𝘆𝗼𝘂𝗿-𝗼𝘄𝗻-𝗟𝗟𝗠 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵. It doesn’t bundle a model service or route model requests through an Attu-hosted proxy. 𝗬𝗼𝘂 𝗽𝗼𝗶𝗻𝘁 𝗔𝘁𝘁𝘂 𝗮𝘁 𝘁𝗵𝗲 𝗽𝗿𝗼𝘃𝗶𝗱𝗲𝗿 𝘆𝗼𝘂 𝗮𝗹𝗿𝗲𝗮𝗱𝘆 𝘂𝘀𝗲:
• OpenAI
• Anthropic
• DeepSeek
• Google Gemini
• OpenRouter
• any OpenAI-compatible endpoint

𝗜𝗻 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲:
• your API key is stored locally, with encryption
• model traffic goes directly to your configured provider
• you choose the model, provider, and cost profile

That means the agent can help manage Milvus through natural language across 50+ built-in tools, without forcing you into a managed LLM service behind the scenes.

𝗔𝘁𝘁𝘂 𝗽𝗿𝗼𝘃𝗶𝗱𝗲𝘀 𝘁𝗵𝗲 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗰𝗼𝗻𝘁𝗿𝗼𝗹 𝘀𝘂𝗿𝗳𝗮𝗰𝗲. 𝗬𝗼𝘂 𝗸𝗲𝗲𝗽 𝗰𝗼𝗻𝘁𝗿𝗼𝗹 𝗼𝘃𝗲𝗿 𝘁𝗵𝗲 𝗟𝗟𝗠 𝗽𝗿𝗼𝘃𝗶𝗱𝗲𝗿, 𝗰𝗿𝗲𝗱𝗲𝗻𝘁𝗶𝗮𝗹𝘀, 𝗮𝗻𝗱 𝗱𝗮𝘁𝗮 𝗽𝗮𝘁𝗵.

💬0🔄0❤️0👀249

⚡ Powered by xgo.ing

𝗠𝗶𝗹𝘃𝘂𝘀 𝗷𝘂𝘀𝘁 𝗰𝗿𝗼𝘀𝘀𝗲𝗱 𝟰𝟱,𝟬𝟬𝟬 𝗚𝗶𝘁𝗛𝘂𝗯 𝘀𝘁𝗮𝗿𝘀 ⭐️ A huge thank you ❤️ to ...

Milvus (@milvusio) — Fri, 03 Jul 2026 15:00:02 GMT

𝗠𝗶𝗹𝘃𝘂𝘀 𝗷𝘂𝘀𝘁 𝗰𝗿𝗼𝘀𝘀𝗲𝗱 𝟰𝟱,𝟬𝟬𝟬 𝗚𝗶𝘁𝗛𝘂𝗯 𝘀𝘁𝗮𝗿𝘀 ⭐️

A huge thank you ❤️ to everyone who has used Milvus, starred the repo, opened issues, contributed code, shared feedback, or built production AI systems on top of it. This milestone is yours as much as ours.

The timing's no accident — 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗶𝘀 𝗮𝗹𝗿𝗲𝗮𝗱𝘆 𝗶𝗻 𝗯𝗲𝘁𝗮, 𝘄𝗶𝘁𝗵 𝗚𝗔 𝗿𝗶𝗴𝗵𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝘁𝗵𝗲 𝗰𝗼𝗿𝗻𝗲𝗿. A few of the capabilities we're most excited about:

🔹 𝗘𝘅𝘁𝗲𝗿𝗻𝗮𝗹 𝗖𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻 — query embeddings and metadata right where they live in the lake (S3, Iceberg, Lance, Parquet, Vortex), zero-copy, no data movement
 🔹 𝗦𝗻𝗮𝗽𝘀𝗵𝗼𝘁 — a consistent, point-in-time view of your data for stable reads, versioning, and rollback
 🔹 𝗟𝗼𝗼𝗻 / 𝗦𝘁𝗼𝗿𝗮𝗴𝗲 𝗩𝟯 — a next-gen, lake-native storage engine where one copy of your vector data serves both large-scale vector and lakebase workloads
 🔹 𝗥𝗶𝗰𝗵𝗲𝗿 𝗾𝘂𝗲𝗿𝘆 𝗽𝗮𝘁𝘁𝗲𝗿𝗻𝘀 — in-kernel aggregation (count / sum / avg, group-by) and faceting, plus stronger support for structured data

…and more landing as we head to GA. Stay tuned. 

Want to get a closyoutube.com/watch?v=SAm4Yf…s webinar recording we recently hosted walking through Milvus 3.0 core features and roadmap with core maintainers here 👇
https://t.co/adRX0vCu5D

💬2🔄0❤️7👀395📊3

⚡ Powered by xgo.ing

MFS 01: https://t.co/PVPqlHy7CR

Milvus (@milvusio) — Fri, 03 Jul 2026 03:06:25 GMT

MFS 01: x.com/milvusio/statu…

Milvus@milvusio

We kept seeing the same pattern with agents: when the same agent lived inside IM instead of a terminal or separate web app, more people used it, and the answers were often better.

The reason was not the UI alone. IM already contains the working context: the question, the people involved, the decision history, the links, the screenshots, and the half-finished reasoning that never makes it into a doc.

But that context is still incomplete. The answer often depends on code, design docs, GitHub issues, database rows, customer notes, or a debugging session from last week.

That is the gap MFS is trying to close.

MFS gives those different sources stable, file-like paths, so an agent can move through them the way an engineer would: find likely places first, then inspect the original file, thread, issue, or record before answering.

For agentic workflows, this matters. The best interface may be IM, but the best answers need context from everywhere else too.

MFS turns conversations, team knowledge, and external tools into one searchable context layer for agents.

Repo: github.com/zilliztech/mfs…

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬0🔄0❤️0👀117

⚡ Powered by xgo.ing

MFS 03: https://t.co/ksYX81kOHA

Milvus (@milvusio) — Fri, 03 Jul 2026 03:06:04 GMT

MFS 03: x.com/milvusio/statu…

Milvus@milvusio

𝗪𝗲 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲𝗱 𝗠𝗙𝗦 (𝗠𝘂𝗹𝘁𝗶-𝘀𝗼𝘂𝗿𝗰𝗲 𝗙𝗶𝗹𝗲-𝗹𝗶𝗸𝗲 𝗦𝗲𝗮𝗿𝗰𝗵), a tool that can turn  a repo, a Slack thread, a design doc, a Jira issue, a CRM note, or a database row those sources into one file-like namespace with stable URIs.

Connectors feed data into mfs-server, where queue, cache, metadata, and index keep the sources searchable and browsable.

Agents can use it through the CLI, Python/TypeScript SDKs, or two skills:
• mfs-ingest registers sources, syncs updates, builds indexes, and helps inspect connectors.
• mfs-find searches across what has been ingested, then browses into the original source with commands like tree, ls, cat, head, and tail.

The architecture is straightforward: locate semantically, then verify progressively.

For agents, that means memory, skills, docs, messages, issues, PRs, emails, customer records, and tables can live in one context layer instead ofgithub.com/zilliztech/mfsate tools.

Repo: https://t.co/RJI5lMigrE

🔗 View Quoted Tweet

💬0🔄0❤️0👀63

⚡ Powered by xgo.ing

𝗪𝗲 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲𝗱 𝗠𝗙𝗦 (𝗠𝘂𝗹𝘁𝗶-𝘀𝗼𝘂𝗿𝗰𝗲 𝗙𝗶𝗹𝗲-𝗹𝗶𝗸𝗲 𝗦𝗲𝗮𝗿𝗰𝗵), a tool...

Milvus (@milvusio) — Thu, 02 Jul 2026 15:30:00 GMT

𝗪𝗲 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲𝗱 𝗠𝗙𝗦 (𝗠𝘂𝗹𝘁𝗶-𝘀𝗼𝘂𝗿𝗰𝗲 𝗙𝗶𝗹𝗲-𝗹𝗶𝗸𝗲 𝗦𝗲𝗮𝗿𝗰𝗵), a tool that can turn  a repo, a Slack thread, a design doc, a Jira issue, a CRM note, or a database row those sources into one file-like namespace with stable URIs.

Connectors feed data into mfs-server, where queue, cache, metadata, and index keep the sources searchable and browsable.

Agents can use it through the CLI, Python/TypeScript SDKs, or two skills:
• mfs-ingest registers sources, syncs updates, builds indexes, and helps inspect connectors.
• mfs-find searches across what has been ingested, then browses into the original source with commands like tree, ls, cat, head, and tail.

The architecture is straightforward: locate semantically, then verify progressively.

For agents, that means memory, skills, docs, messages, issues, PRs, emails, customer records, and tables can live in one context layer instead ofgithub.com/zilliztech/mfsate tools.

Repo: https://t.co/RJI5lMigrE

💬2🔄4❤️29👀3968📊16

⚡ Powered by xgo.ing

⏰ Coming up very soon: 𝗙𝗿𝗼𝗺 𝗩𝗲𝗰𝘁𝗼𝗿 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝘁𝗼 𝗩𝗲𝗰𝘁𝗼𝗿 𝗟𝗮𝗸𝗲𝗯𝗮𝘀𝗲 sta...

Milvus (@milvusio) — Wed, 01 Jul 2026 17:00:02 GMT

⏰ Coming up very soon: 𝗙𝗿𝗼𝗺 𝗩𝗲𝗰𝘁𝗼𝗿 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝘁𝗼 𝗩𝗲𝗰𝘁𝗼𝗿 𝗟𝗮𝗸𝗲𝗯𝗮𝘀𝗲 starts in 1 hour.
Join us for a live discussion on Vector Lakebase, one lake-native architecture for high-QPS serving, ad-hoc discovery, and offline processing.

Zilliz@zilliz_universe

🔥 Webinar invitation: 𝗙𝗿𝗼𝗺 𝗩𝗲𝗰𝘁𝗼𝗿 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝘁𝗼 𝗩𝗲𝗰𝘁𝗼𝗿 𝗟𝗮𝗸𝗲𝗯𝗮𝘀𝗲

Zilliz Vector Lakebase is now available in public preview on Zilliz Cloud, a major evolution that pairs the production vector database with a shared, lake-native data foundation.

Join James Luan, Zilliz CTO and Milvus maintainer, and Jiang Chen, Director of Technical GTM, for a live walkthrough of what Vector Lakebase is, why it matters for production AI workloads, and how it brings online serving, on-demand search, and batch processing onto one copy of your data.

📅 𝗝𝘂𝗹zilliz.com/event/from-vec…𝗔𝗠 𝗣𝗗𝗧
🔗 𝗥𝗲𝗴𝗶𝘀𝘁𝗲𝗿 𝗵𝗲𝗿𝗲: https://t.co/NZUWwMAYBt

🎤 𝗪𝗵𝗮𝘁 𝘁𝗼 𝗲𝘅𝗽𝗲𝗰𝘁:
• Where Vector Lakebase fits alongside Milvus, vector databases, and lake ecosystem
• One copy of data for multiple workloads, no migration needed
• The architecture design of One Data / One Index / One Semantic Layer
• External Collection over Iceberg, Lance, and Parquet, with no data movement
• Full-spectrum search across vector, text, JSON, geo, and hybrid retrieval
• Live AMA with #MilvusC#VectorDatabasen#AIInfraChen 

Bring your questions and join us live.
#Milvus#VectorDatabase#AIInfra

🔗 View Quoted Tweet

💬0🔄0❤️0👀278

⚡ Powered by xgo.ing

𝗪𝗲 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲𝗱 𝗢𝗽𝗲𝗻 𝗧𝗮𝗴, 𝗮𝗻 𝗼𝗽𝗲𝗻 𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗼𝗳 𝗖𝗹𝗮𝘂𝗱𝗲 𝗧𝗮𝗴....

Milvus (@milvusio) — Wed, 01 Jul 2026 15:30:30 GMT

𝗪𝗲 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲𝗱 𝗢𝗽𝗲𝗻 𝗧𝗮𝗴, 𝗮𝗻 𝗼𝗽𝗲𝗻 𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗼𝗳 𝗖𝗹𝗮𝘂𝗱𝗲 𝗧𝗮𝗴.
We wanted a practical workflow: mention an AI agent in Slack, keep the work in a shared thread, and let it pull enough context to be useful.

Claude Tag is the official path. If it fits your workspace and stack, great. But some teams want more control:
• use Claude Code or Codex as the backend
• inspect and modify the workflow
• connect their own context sources
• run the demo locally before thinking about production
• understand what the agent can read and why
That is what Open Tag is for.

In Slack, you can mention @OpenClaude or @OpenCodex. Open Tag reads the current thread, pulls authorized context through MFS, sends the task to the CLI agent, and posts the result back.

MFS is the memory and tools layer behind it. It can search across code, docs, issues, chat history, and database records, then let the agent inspect the original source.

Open Tag is still a demo, not a hardened enterprise deployment. But it shows that the Claude Tag workflow can github.com/zilliztech/mfs…mponengithub.com/zilliztech/mfst.co/yPFICJ04RR
MFS: https://t.co/RJI5lMigrE

💬3🔄1❤️3👀444📊4

⚡ Powered by xgo.ing

We kept seeing the same pattern with agents: when the same agent lived inside IM instead of a termin...

Milvus (@milvusio) — Tue, 30 Jun 2026 15:00:04 GMT

We kept seeing the same pattern with agents: when the same agent lived inside IM instead of a terminal or separate web app, more people used it, and the answers were often better.

The reason was not the UI alone. IM already contains the working context: the question, the people involved, the decision history, the links, the screenshots, and the half-finished reasoning that never makes it into a doc.

But that context is still incomplete. The answer often depends on code, design docs, GitHub issues, database rows, customer notes, or a debugging session from last week.

That is the gap MFS is trying to close.

MFS gives those different sources stable, file-like paths, so an agent can move through them the way an engineer would: find likely places first, then inspect the original file, thread, issue, or record before answering.

For agentic workflows, this matters. The best interface may be IM, but the best answers need context from everywhere else too.

MFS turns conversations, team knowledge, and external tools into one searchable context layer for agents.

Repo: github.com/zilliztech/mfs…

Your browser does not support the video tag.

🔗 View on Twitter

💬0🔄0❤️1👀380📊1

⚡ Powered by xgo.ing

⏰ Quick reminder: our webinar, 𝗙𝗿𝗼𝗺 𝗩𝗲𝗰𝘁𝗼𝗿 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝘁𝗼 𝗩𝗲𝗰𝘁𝗼𝗿 ...

Milvus (@milvusio) — Mon, 29 Jun 2026 15:00:00 GMT

⏰ Quick reminder: our webinar, 𝗙𝗿𝗼𝗺 𝗩𝗲𝗰𝘁𝗼𝗿 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝘁𝗼 𝗩𝗲𝗰𝘁𝗼𝗿 𝗟𝗮𝗸𝗲𝗯𝗮𝘀𝗲, is coming up soon.

Join our CTO James Luan and Jiang Chen, Director of Technical GTM, to learn how 𝗩𝗲𝗰𝘁𝗼𝗿 𝗟𝗮𝗸𝗲𝗯𝗮𝘀𝗲 supports production AI search, from high-QPS serving to cost-sensitive ad-hoc discovery and offline processing, on one lake-native architecture without repeated data movement.

We’ll also close with a live AMA, so bring your questions and join the discussion.

📅 𝗪𝗲lnkd.in/gsxztyGy?utm_s…� 𝟭, 𝟮𝟬𝟮𝟲
🌐 𝟭𝟭 𝗔𝗠 𝗣𝗗𝗧
🔗 Register here: https://t.co/wD6vIzXxjJ

Zilliz@zilliz_universe

🔥 Webinar invitation: 𝗙𝗿𝗼𝗺 𝗩𝗲𝗰𝘁𝗼𝗿 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝘁𝗼 𝗩𝗲𝗰𝘁𝗼𝗿 𝗟𝗮𝗸𝗲𝗯𝗮𝘀𝗲

Zilliz Vector Lakebase is now available in public preview on Zilliz Cloud, a major evolution that pairs the production vector database with a shared, lake-native data foundation.

Join James Luan, Zilliz CTO and Milvus maintainer, and Jiang Chen, Director of Technical GTM, for a live walkthrough of what Vector Lakebase is, why it matters for production AI workloads, and how it brings online serving, on-demand search, and batch processing onto one copy of your data.

📅 𝗝𝘂𝗹zilliz.com/event/from-vec…𝗔𝗠 𝗣𝗗𝗧
🔗 𝗥𝗲𝗴𝗶𝘀𝘁𝗲𝗿 𝗵𝗲𝗿𝗲: https://t.co/NZUWwMAYBt

🎤 𝗪𝗵𝗮𝘁 𝘁𝗼 𝗲𝘅𝗽𝗲𝗰𝘁:
• Where Vector Lakebase fits alongside Milvus, vector databases, and lake ecosystem
• One copy of data for multiple workloads, no migration needed
• The architecture design of One Data / One Index / One Semantic Layer
• External Collection over Iceberg, Lance, and Parquet, with no data movement
• Full-spectrum search across vector, text, JSON, geo, and hybrid retrieval
• Live AMA with #MilvusC#VectorDatabasen#AIInfraChen 

Bring your questions and join us live.
#Milvus#VectorDatabase#AIInfra

🔗 View Quoted Tweet

💬0🔄0❤️1👀306

⚡ Powered by xgo.ing

𝗚𝗿𝗮𝗻𝘁𝗶𝗻𝗴 𝗮 𝘁𝗲𝗮𝗺𝗺𝗮𝘁𝗲 𝗿𝗲𝗮𝗱-𝗼𝗻𝗹𝘆 𝗮𝗰𝗰𝗲𝘀𝘀 𝘁𝗼 𝗼𝗻𝗲 𝗠𝗶𝗹𝘃𝘂𝘀 ...

Milvus (@milvusio) — Fri, 26 Jun 2026 15:00:01 GMT

𝗚𝗿𝗮𝗻𝘁𝗶𝗻𝗴 𝗮 𝘁𝗲𝗮𝗺𝗺𝗮𝘁𝗲 𝗿𝗲𝗮𝗱-𝗼𝗻𝗹𝘆 𝗮𝗰𝗰𝗲𝘀𝘀 𝘁𝗼 𝗼𝗻𝗲 𝗠𝗶𝗹𝘃𝘂𝘀 𝗰𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻 𝘂𝘀𝗲𝗱 𝘁𝗼 𝗯𝗲 𝗮 𝗳𝗼𝘂𝗿-𝘀𝘁𝗲𝗽 𝗱𝗲𝘁𝗼𝘂𝗿. 𝗡𝗼𝘄, 𝗶𝘁'𝘀 𝗼𝗻𝗹𝘆 𝗼𝗻𝗲 𝘀𝘁𝗲𝗽: 𝘆𝗼𝘂 𝗽𝗶𝗰𝗸 𝘁𝗵𝗲 𝗹𝗲𝘃𝗲𝗹 𝗼𝗳 𝗮𝗰𝗰𝗲𝘀𝘀, 𝗮𝗻𝗱 𝗔𝘁𝘁𝘂 𝗰𝗼𝗺𝗽𝗹𝗲𝘁𝗲𝘀 𝘁𝗵𝗲 𝗿𝗲𝘀𝘁 𝗳𝗼𝗿 𝘆𝗼𝘂.

In most setups you had to:
• create the user
• create a role
• configure the privileges
• assign the role to the user
Miss a step or scope it wrong, and you either over-grant or lock someone out.

𝗔𝘁𝘁𝘂 𝟯.𝟬 𝗯𝗲𝘁𝗮 𝗯𝗿𝗶𝗻𝗴𝘀 𝗥𝗕𝗔𝗖 𝗶𝗻𝘁𝗼 𝘁𝗵𝗲 𝗰𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻 𝘃𝗶𝗲𝘄 𝗶𝘁𝘀𝗲𝗹𝗳. 𝗜𝗻 𝗮 𝗰𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗼𝗻'𝘀 𝗨𝘀𝗲𝗿𝘀 𝘁𝗮𝗯 𝘆𝗼𝘂 𝗰𝗹𝗶𝗰𝗸 𝗖𝗿𝗲𝗮𝘁𝗲 𝗨𝘀𝗲𝗿, 𝗽𝗶𝗰𝗸 𝗥𝗲𝗮𝗱𝗢𝗻𝗹𝘆 𝗼𝗿 𝗥𝗲𝗮𝗱𝗪𝗿𝗶𝘁𝗲, 𝗮𝗻𝗱 𝗔𝘁𝘁𝘂 𝗱𝗼𝗲𝘀 𝘁𝗵𝗲 𝗿𝗲𝘀𝘁 𝗶𝗻 𝗼𝗻𝗲 𝗺𝗼𝘃𝗲. It creates the user, generates a secure password, creates the matching scoped role and then completes the grant.

The same womilvus.io/blog/attu-3-0-…el, and you can authorize an existing user or revoke access in one click. You no longer jump to a separate page or need to memorize a role-naming convention.

𝗟𝗲𝗮𝗿𝗻 𝗺𝗼𝗿𝗲 𝗮𝗯𝗼𝘂𝘁 𝗵𝗼𝘄 𝘁𝗵𝗲 𝗻𝗲𝘄 𝗽𝗲𝗿𝗺𝗶𝘀𝘀𝗶𝗼𝗻 𝗺𝗼𝗱𝗲𝗹 𝘄𝗼𝗿𝗸𝘀, 𝗶𝗻 𝘁𝗵𝗲 𝗳𝘂𝗹𝗹 𝗔𝘁𝘁𝘂 𝟯.𝟬 𝗽𝗼𝘀𝘁 𝗼𝗻 𝘁𝗵𝗲 𝗠𝗶𝗹𝘃𝘂𝘀 𝗯𝗹𝗼𝗴: https://t.co/IHhmzN3eOu

💬0🔄0❤️1👀206📊1

⚡ Powered by xgo.ing

𝗔 𝘀𝗶𝗻𝗴𝗹𝗲 𝟭–𝟱 𝘀𝗰𝗼𝗿𝗲 𝗶𝘀 𝗮 𝗯𝗮𝗱 𝘄𝗮𝘆 𝘁𝗼 𝗷𝘂𝗱𝗴𝗲 𝗥𝗔𝗚 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗶𝗻 ...

Milvus (@milvusio) — Thu, 25 Jun 2026 15:00:02 GMT

𝗔 𝘀𝗶𝗻𝗴𝗹𝗲 𝟭–𝟱 𝘀𝗰𝗼𝗿𝗲 𝗶𝘀 𝗮 𝗯𝗮𝗱 𝘄𝗮𝘆 𝘁𝗼 𝗷𝘂𝗱𝗴𝗲 𝗥𝗔𝗚 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗶𝗻 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻. 𝗛𝗲𝗿𝗲'𝘀 𝘄𝗵𝘆.
𝗙𝗶𝗿𝘀𝘁, 𝗮𝗻 𝗼𝘃𝗲𝗿𝗮𝗹𝗹 𝗮𝘃𝗲𝗿𝗮𝗴𝗲 𝗵𝗶𝗱𝗲𝘀 𝗵𝗶𝗴𝗵-𝗿𝗶𝘀𝗸 𝗵𝗮𝗹𝗹𝘂𝗰𝗶𝗻𝗮𝘁𝗶𝗼𝗻𝘀. A long answer can be 90% grounded, but if the other 10% fabricates a core parameter, it's unusable in finance, medicine, or law. The averaged score still reads 4 out of 5, and the team assumes the system is basically fine.

𝗦𝗲𝗰𝗼𝗻𝗱, 𝗵𝗮𝗹𝗹𝘂𝗰𝗶𝗻𝗮𝘁𝗶𝗼𝗻𝘀 𝗮𝗿𝗲𝗻'𝘁 𝗲𝘃𝗲𝗻𝗹𝘆 𝗱𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱. Average Groundedness can look healthy while certain query types, like numeric lookups or multi-condition questions, hallucinate far above the mean. Without bucketing by question type, that skew stays invisible.

𝗧𝗵𝗶𝗿𝗱, 𝗺𝗲𝘁𝗿𝗶𝗰𝘀 𝗰𝗮𝗻 𝗺𝗮𝘀𝗸 𝗲𝗮𝗰𝗵 𝗼𝘁𝗵𝗲𝗿 When you optimize for Answer Relevance and add prompt instructions like "give fuller background," relevance scores do go up, but the model starts pulling on parametric knowledge to fill evidence gaps, and Faithfulness can drop without showing up in the headline score. One metric rises while another degrades out of sight. That's why Groundedness isn't a one-time check: it has to be monitored after every prompt change.

𝗧𝗵𝗲 𝗺𝗼𝗿𝗲 𝗿𝗲𝗹𝗶𝗮𝗯𝗹𝗲 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵 𝗶𝘀 𝗰𝗹𝗮𝗶𝗺-𝗹𝗲𝘃𝗲𝗹 𝗲𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗼𝗻, 𝗶𝗻 𝗳𝗼𝘂𝗿 𝘀𝘁𝗲𝗽𝘀:
• 𝗔𝘁𝗼𝗺𝗶𝗰 𝗰𝗹𝗮𝗶𝗺 𝗲𝘅𝘁𝗿𝗮𝗰𝘁𝗶𝗼𝗻: break the full answer into independent factual assertions. "The XR-2048 is a low-power device, draws 150W, and supports hot-swapping" becomes three separate claims.
• 𝗘𝗻𝘁𝗮𝗶𝗹𝗺𝗲𝗻𝘁 𝗰𝗵𝗲𝗰𝗸: for each claim, test whether the retrieved context actually supports it. Use an NLI model or an LLM-as-judge.
• 𝗤𝘂𝗮𝗻𝘁𝗶𝗳𝘆: Groundedness = supported claims / total claims.
• 𝗖𝗿𝗶𝘁𝗶𝗰𝗮𝗹-𝗲𝗿𝗿𝗼𝗿 𝗴𝗮𝘁𝗶𝗻𝗴: in high-stakes work, if a claim covering a key parameter is unsupported, block the answer regardless of how high the overall score is.

𝗕𝘂𝗰𝗸𝗲𝘁 𝘆𝗼𝘂𝗿 𝘀𝗰𝗼𝗿𝗲𝘀 𝗯𝘆 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻 𝘁𝘆𝗽𝗲 𝗶𝗻𝘀𝘁𝗲𝗮𝗱 𝗼𝗳 𝗿𝗲𝗮𝗱𝗶𝗻𝗴 𝗼𝗻𝗲 𝗴𝗹𝗼𝗯𝗮𝗹 𝗮𝘃𝗲𝗿𝗮𝗴𝗲.

A per-claim view tells you more than whether the answer looks solid overall. It points to the exact sentence that has nothing behind it, and it makes debugging far easier, because you can trace every unsupported claim back to where it broke: retrieval never pulled the evidence, the reranker buried it, the context window cut it off, or the model just ignored what it had.

𝗕𝘂𝗰𝗸𝗲𝘁𝗶𝗻𝗴 𝗶𝘀 𝘀𝘁𝗿𝗮𝗶𝗴𝗵𝘁𝗳𝗼𝗿𝘄𝗮𝗿𝗱 𝘁𝗼 𝘄𝗶𝗿𝗲 𝘂𝗽. Tag each evaluation record with its query type, then filter on that tag. KStore evaluation records with fields like query_type, claim_count, and unsupported_claim_count. 𝗠𝗶𝗹𝘃𝘂𝘀 can do this with a scalar or dynamic field, so the per-bucket numbers fall out of a single filter. That lets you slice results without building a separate reporting pipeline.

𝗜𝗳 𝘆𝗼𝘂𝗿 𝗥𝗔𝗚 𝘀𝘆𝘀𝘁𝗲𝗺 𝗿𝗲𝗽𝗼𝗿𝘁𝘀 𝗮 𝘀𝗶𝗻𝗴𝗹𝗲 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝘀𝗰𝗼𝗿𝗲, 𝗰𝗵𝗲𝗰𝗸 𝘄𝗵𝗮𝘁 𝗮 𝗽𝗲𝗿-𝗰𝗹𝗮𝗶𝗺, 𝗽𝗲𝗿-𝗯𝘂𝗰𝗸𝗲𝘁 𝗯𝗿𝗲𝗮𝗸𝗱𝗼𝘄𝗻 𝗱𝗼𝗲𝘀 𝘁𝗼 𝗶𝘁. 𝗧𝗵𝗲 𝗻𝘂𝗺𝗯𝗲𝗿 𝘁𝗵𝗮𝘁 𝗹𝗼𝗼𝗸𝗲𝗱 𝗳𝗶𝗻𝗲 𝘂𝘀𝘂𝗮𝗹𝗹𝘆 𝗱𝗼𝗲𝘀𝗻'𝘁 𝘀𝘂𝗿𝘃𝗶𝘃𝗲.

💬0🔄0❤️3👀206📊1

⚡ Powered by xgo.ing

𝗟𝗟𝗠𝘀 𝗸𝗲𝗲𝗽 𝗰𝗶𝘁𝗶𝗻𝗴 𝘀𝗼𝘂𝗿𝗰𝗲𝘀 𝘁𝗵𝗮𝘁 𝗱𝗼𝗻'𝘁 𝘀𝗮𝘆 𝘄𝗵𝗮𝘁 𝘁𝗵𝗲𝘆 ...

Milvus (@milvusio) — Wed, 24 Jun 2026 15:30:00 GMT

𝗟𝗟𝗠𝘀 𝗸𝗲𝗲𝗽 𝗰𝗶𝘁𝗶𝗻𝗴 𝘀𝗼𝘂𝗿𝗰𝗲𝘀 𝘁𝗵𝗮𝘁 𝗱𝗼𝗻'𝘁 𝘀𝗮𝘆 𝘄𝗵𝗮𝘁 𝘁𝗵𝗲𝘆 𝗰𝗹𝗮𝗶𝗺. 𝗛𝗲𝗿𝗲'𝘀 𝗵𝗼𝘄 𝘁𝗼 𝗳𝗶𝘅 𝗶𝘁.

𝗧𝗵𝗲 𝗳𝗮𝗶𝗹𝘂𝗿𝗲 𝗶𝘀 𝗳𝗮𝗺𝗶𝗹𝗶𝗮𝗿 𝗳𝗿𝗼𝗺 𝗮𝗻𝘆 𝗵𝗶𝗴𝗵-𝘀𝘁𝗮𝗸𝗲𝘀 𝗥𝗔𝗚: 𝗮 𝗰𝗶𝘁𝗮𝘁𝗶𝗼𝗻 𝘁𝗮𝗴 𝗱𝗼𝗲𝘀𝗻'𝘁 𝗺𝗲𝗮𝗻 𝘁𝗵𝗲 𝗰𝗶𝘁𝗲𝗱 𝗽𝗮𝘀𝘀𝗮𝗴𝗲 𝘀𝘂𝗽𝗽𝗼𝗿𝘁𝘀 𝘁𝗵𝗲 𝗰𝗹𝗮𝗶𝗺. The answer comes back with clean [1][2][3] markers, the right document is in the top-5, everything looks sourced. Then you open the citation and the cited passage says nothing that backs the sentence attached to it.

Most teams blame the generation layer and swap the model, rewrite the prompt, pile on instructions. 𝗕𝘂𝘁 𝗮 𝗹𝗼𝘁 𝗼𝗳 𝗰𝗶𝘁𝗮𝘁𝗶𝗼𝗻 𝗲𝗿𝗿𝗼𝗿𝘀 𝗻𝗲𝘃𝗲𝗿 𝗰𝗮𝗺𝗲 𝗳𝗿𝗼𝗺 𝗴𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻.

𝗔 𝗯𝗿𝗼𝗸𝗲𝗻 𝗰𝗶𝘁𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝘂𝘀𝘂𝗮𝗹𝗹𝘆 𝗼𝗻𝗲 𝗼𝗳 𝘁𝘄𝗼 𝗽𝗿𝗼𝗯𝗹𝗲𝗺𝘀, 𝗳𝗶𝘅𝗲𝗱 𝗶𝗻 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗽𝗹𝗮𝗰𝗲𝘀.
• 𝗙𝗮𝗶𝘁𝗵𝗳𝘂𝗹𝗻𝗲𝘀𝘀 is whether the generated text itself is hallucinated. The model says "150W power draw," but the retrieved docs only say "low-power." The 150W is invented. 
𝗙𝗶𝘅 𝗶𝘁 𝗶𝗻 𝘁𝗵𝗲 𝗴𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗼𝗻 𝗹𝗮𝘆𝗲𝗿: tighten prompt constraints, or switch the base model.
• 𝗖𝗶𝘁𝗮𝘁𝗶𝗼𝗻 𝗔𝗰𝗰𝘂𝗿𝗮𝗰𝘆 is whether the citation's metadata maps to the right place. The marker points to the wrong passage in the right document, or to a chunk ID that re-chunking already deleted. 
𝗙𝗶𝘅 𝗶𝘁 𝗶𝗻 𝘁𝗵𝗲 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗹𝗮𝘆𝗲𝗿: citation resolution and metadata management, which has nothing to do with model quality.

𝗖𝗶𝘁𝗮𝘁𝗶𝗼𝗻 𝗔𝗰𝗰𝘂𝗿𝗮𝗰𝘆 𝗳𝗮𝗶𝗹𝘀 𝗶𝗻 𝗳𝗶𝘃𝗲 𝘀𝗵𝗮𝗽𝗲𝘀:
• 𝗠𝗶𝘀𝘀𝗶𝗻𝗴 𝗰𝗶𝘁𝗮𝘁𝗶𝗼𝗻: a factual statement with no source attached. Fix the output format and attribution requirements.
• 𝗚𝗵𝗼𝘀𝘁 𝗰𝗶𝘁𝗮𝘁𝗶𝗼𝗻: the cited chunk ID no longer exists, usually after an index rebuild leaves old IDs stale while the prompt template keeps emitting them. Fix the ID lifecycle, not the model.
• 𝗪𝗲𝗮𝗸-𝘀𝘂𝗽𝗽𝗼𝗿𝘁 𝗰𝗶𝘁𝗮𝘁𝗶𝗼𝗻: the chunk exists but doesn't support the claim. The model says "rate limit is 100 requests/sec" and cites a chunk that only mentions "supports batch calls." Add claim-level entailment checks instead of trusting the marker.
• 𝗢𝘃𝗲𝗿-𝗰𝗶𝘁𝗮𝘁𝗶𝗼𝗻: several loosely related sources stacked behind one sentence, which dilutes trust instead of building it.
• 𝗗𝗼𝗰-𝗹𝗲𝘃𝗲𝗹 𝗰𝗶𝘁𝗮𝘁𝗶𝗼𝗻: attribution to "Document A" but not the actual passage. For long documents, that's barely verifiable.

The first three are the ones to monitor first. Each fails in a different layer, so misclassifying the error sends you to repair the wrong system. Before changing the model, check what kind of citation failure you actually have.

𝗔 𝗥𝗔𝗚 𝘀𝘆𝘀𝘁𝗲𝗺 𝘁𝗵𝗮𝘁 𝘀𝗵𝗼𝘄𝘀 𝗰𝗶𝘁𝗮𝘁𝗶𝗼𝗻 𝗺𝗮𝗿𝗸𝗲𝗿𝘀 𝗯𝘂𝘁 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗲𝘀 𝗻𝗼𝗻𝗲 𝗼𝗳 𝘁𝗵𝗲𝗺 𝗰𝗮𝗻 𝗯𝗲 𝘄𝗼𝗿𝘀𝗲 𝘁𝗵𝗮𝗻 𝗼𝗻𝗲 𝘄𝗶𝘁𝗵 𝗻𝗼 𝗰𝗶𝘁𝗮𝘁𝗶𝗼𝗻𝘀 𝗮𝘁 𝗮𝗹𝗹. 𝗔 𝗰𝗹𝗲𝗮𝗻 [𝟭][𝟮][𝟯] 𝘀𝘂𝗿𝗳𝗮𝗰𝗲 𝗺𝗮𝗸𝗲𝘀 𝘀𝘁𝗮𝗹𝗲, 𝘄𝗿𝗼𝗻𝗴, 𝗼𝗿 𝘂𝗻𝘀𝘂𝗽𝗽𝗼𝗿𝘁𝗲𝗱 𝗲𝘃𝗶𝗱𝗲𝗻𝗰𝗲 𝗹𝗼𝗼𝗸 𝘁𝗿𝘂𝘀𝘁𝘄𝗼𝗿𝘁𝗵𝘆.

💬0🔄0❤️1👀192📊1

⚡ Powered by xgo.ing

We built HNSW directly on the embedding lists, with no encoding step in between. 𝗧𝗵𝗲 ...

Milvus (@milvusio) — Tue, 23 Jun 2026 15:00:02 GMT

We built HNSW directly on the embedding lists, with no encoding step in between. 𝗧𝗵𝗲 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗰𝗮𝗺𝗲 𝗼𝘂𝘁 𝗮𝗹𝗺𝗼𝘀𝘁 𝗹𝗼𝘀𝘀𝗹𝗲𝘀𝘀, 𝗯𝘂𝘁 𝘁𝗵𝗲 𝗳𝗶𝗻𝗱𝗶𝗻𝗴 𝗶𝘀 𝘄𝗵𝗮𝘁'𝘀 𝗺𝗼𝘀𝘁 𝘃𝗮𝗹𝘂𝗮𝗯𝗹𝗲: 𝘁𝗼𝗱𝗮𝘆'𝘀 𝗮𝗽𝗽𝗿𝗼𝘅𝗶𝗺𝗮𝘁𝗲 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀 𝗹𝗼𝘀𝗲 𝗺𝗼𝘀𝘁 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗶𝗻 𝘁𝗵𝗲 𝗿𝗲𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝘀𝘁𝗲𝗽, 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗶𝗻𝗱𝗲𝘅.
 
TokenANN, MUVERA, and LEMUR all reduce a document's token vectors to single-vector ANN, just from opposite ends: MUVERA and LEMUR squeeze each document into one vector, TokenANN indexes every token separately and reassembles. Either way it's an approximation of MaxSim, and that's where the quality goes. So skip the reduction: make the whole list the index unit, one document, one list of vectors. We tried it, and it works — the quality stays close to exact.
 
𝗛𝗼𝘄 𝗶𝘁'𝘀 𝘀𝗲𝘁 𝘂𝗽:
• Each document's full embedding list is one HNSW node
• Distance between two nodes is bidirectional MeanMaxSim: 𝗠𝗲𝗮𝗻𝗠𝗮𝘅𝗦𝗶𝗺(𝗔,𝗕) + 𝗠𝗲𝗮𝗻𝗠𝗮𝘅𝗦𝗶𝗺(𝗕,𝗔)
• Bidirectional, because HNSW needs a symmetric distance and MaxSim isn't symmetric
• Mean, because raw MaxSim grows with vector count, so dividing it out keeps different-length documents comparable
• At query time it's the standard one-way MaxSim(query, doc); the query is short, so the reverse direction is mostly noise
 
𝗪𝗵𝗮𝘁 𝗶𝘁 𝘀𝗰𝗼𝗿𝗲𝗱:
• Math nDCG@10 (fidelity to exact BruteForce ranking): 𝗮𝗯𝗼𝘃𝗲 𝟬.𝟵𝟴, vs 𝟬.𝟴𝟳–𝟬.𝟴𝟵 for the best of the three approximate strategies
• End to end: 𝘁𝗶𝗲𝘀 𝗕𝗿𝘂𝘁𝗲𝗙𝗼𝗿𝗰𝗲 𝗼𝗻 𝗧𝗥𝗘𝗖-𝗖𝗢𝗩𝗜𝗗 (𝟬.𝟱𝟭𝟲), near-matches on MS MARCO (0.957 vs 0.966)
 
That gap is the whole point. All four run on HNSW, and only the three that reduce the list first lose fidelity — roughly 𝘁𝗲𝗻 𝗽𝗼𝗶𝗻𝘁𝘀 of it. The graph search is identical everywhere; the loss tracks the reduction. Get that near-lossless and end-to-end quality sits close to the exact ceiling.
 
𝗧𝘄𝗼 𝘁𝗵𝗶𝗻𝗴𝘀 𝗸𝗲𝗲𝗽 𝗶𝘁 𝗼𝘂𝘁 𝗼𝗳 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻, 𝗯𝗼𝘁𝗵 𝗮𝗯𝗼𝘂𝘁 𝗰𝗼𝘀𝘁:
• 𝗕𝘂𝗶𝗹𝗱 𝗰𝗼𝘀𝘁: each distance is inner products over every token pair between two lists — O(avg_len² × dim). Node count drops from N × avg_len to N, but net cost still scales with avg_len. Measured: 𝟲𝘅 a single-vector HNSW at avg_len 87 (MS MARCO), 𝟭𝟴𝘅 at avg_len 236 (TREC-COVID).
• 𝗟𝗶𝘀𝘁 𝗹𝗲𝗻𝗴𝘁𝗵: when a document carries thousands of vectors (𝗖𝗼𝗹𝗤𝘄𝗲𝗻𝟮: 𝟱,𝟭𝟰𝟯 𝗽𝗮𝘁𝗰𝗵𝗲𝘀 𝗽𝗲𝗿 𝗽𝗮𝗴𝗲), distance cost climbs until build and search latency aren't acceptable. That rules out multimodal and long complex-query documents — exactly where multi-vector wins most.
 
Building HNSW straight on the full lists, with no reduction step, matched BruteForce almost exactly. 𝗧𝗵𝗮𝘁 𝘁𝗲𝗹𝗹𝘀 𝘂𝘀 𝘁𝗵𝗲 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗠𝗨𝗩𝗘𝗥𝗔, 𝗟𝗘𝗠𝗨𝗥, 𝗮𝗻𝗱 𝗧𝗼𝗸𝗲𝗻𝗔𝗡𝗡 𝗴𝗶𝘃𝗲 𝘂𝗽 𝗰𝗼𝗺𝗲𝘀 𝗳𝗿𝗼𝗺 𝗵𝗼𝘄 𝘁𝗵𝗲𝘆 𝗿𝗲𝗱𝘂𝗰𝗲 𝘁𝗵𝗲 𝗲𝗺𝗯𝗲𝗱𝗱𝗶𝗻𝗴 𝗹𝗶𝘀𝘁, 𝗻𝗼𝘁 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝗛𝗡𝗦𝗪 𝗶𝗻𝗱𝗲𝘅 𝘁𝗵𝗲𝘆 𝗮𝗹𝗹 𝘀𝗵𝗮𝗿𝗲. 𝗦𝗼 𝘁𝗵𝗲 𝗻𝗲𝘅𝘁 𝗿𝗼𝘂𝗻𝗱 𝗼𝗳 𝘄𝗼𝗿𝗸 𝗴𝗼𝗲𝘀 𝘁𝗵𝗲𝗿𝗲: 𝘀𝗵𝗮𝗿𝗽𝗲𝗻 𝘁𝗵𝗲 𝗿𝗲𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝘀𝘁𝗲𝗽, 𝗮𝗻𝗱 𝗮 𝘀𝗵𝗶𝗽𝗽𝗮𝗯𝗹𝗲 𝗺𝗲𝘁𝗵𝗼𝗱 𝗰𝗼𝘂𝗹𝗱 𝗿𝗲𝗮𝗰𝗵 𝗕𝗿𝘂𝘁𝗲𝗙𝗼𝗿𝗰𝗲-𝗹𝗲𝘃𝗲𝗹 𝗾𝘂𝗮𝗹𝗶𝘁𝘆.

💬0🔄1❤️3👀371📊1

⚡ Powered by xgo.ing

Attu used to feel like a lightweight console for one Milvus instance. 𝗔𝘁𝘁𝘂 𝟯.𝟬 𝗕𝗲𝘁𝗮 𝗶𝘀 ...

Milvus (@milvusio) — Mon, 22 Jun 2026 15:30:01 GMT

Attu used to feel like a lightweight console for one Milvus instance. 𝗔𝘁𝘁𝘂 𝟯.𝟬 𝗕𝗲𝘁𝗮 𝗶𝘀 𝗯𝗲𝗰𝗼𝗺𝗶𝗻𝗴 𝗮𝗻 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀 𝗰𝗼𝗻𝘀𝗼𝗹𝗲 𝗳𝗼𝗿 𝗺𝘂𝗹𝘁𝗶-𝗰𝗹𝘂𝘀𝘁𝗲𝗿 𝗠𝗶𝗹𝘃𝘂𝘀 𝘄𝗼𝗿𝗸.
𝗢𝗻𝗲 𝗰𝗵𝗮𝗻𝗴𝗲 𝗺𝗮𝗸𝗲𝘀 𝘁𝗵𝗮𝘁 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹: 𝗹𝗼𝗰𝗮𝗹 𝘀𝘁𝗮𝘁𝗲 𝗻𝗼𝘄 𝘀𝘂𝗿𝘃𝗶𝘃𝗲𝘀 𝗿𝗲𝘀𝘁𝗮𝗿𝘁𝘀.

In 2.x, Attu was stateless. Restart the container, and your saved connections were gone. You rebuilt the workspace from scratch.

𝗜𝗻 𝟯.𝟬, 𝗔𝘁𝘁𝘂 𝘀𝘁𝗼𝗿𝗲𝘀 𝗹𝗼𝗰𝗮𝗹 𝘀𝘁𝗮𝘁𝗲 𝗶𝗻 𝗮 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲, 𝗶𝗻𝗰𝗹𝘂𝗱𝗶𝗻𝗴:•  cluster configs 
•  agent conversation history 
•  custom skills 
•  LLM config 

𝗠𝗼𝘂𝗻𝘁 𝗼𝗻𝗲 𝗗𝗼𝗰𝗸𝗲𝗿 𝘃𝗼𝗹𝘂𝗺𝗲: -𝘃 𝗮𝘁𝘁𝘂-𝗱𝗮𝘁𝗮:/𝗱𝗮𝘁𝗮 𝗮𝗻𝗱 𝘆𝗼𝘂𝗿 𝘄𝗼𝗿𝗸𝘀𝗽𝗮𝗰𝗲 𝗰𝗮𝗻 𝗻𝗼𝘄 𝗰𝗮𝗿𝗿𝘆 𝗼𝘃𝗲𝗿 𝗯𝗲𝘁𝘄𝗲𝗲𝗻 𝘀𝗲𝘀𝘀𝗶𝗼𝗻𝘀, 𝘀𝘂𝗿𝘃𝗶𝘃𝗶𝗻𝗴 𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿 𝗿𝗲𝘀𝘁𝗮𝗿𝘁𝘀.

It turns Attu from something you open and close into somethimilvus.io/blog/attu-3-0-…text as you work. It means you can configure your LLM provider once, build a pre-launch checklist as a reusable agent skill, and pick up a diagnostic conversation days later without re-explaining the problem. 

𝗙𝘂𝗹𝗹 𝗯𝗿𝗲𝗮𝗸𝗱𝗼𝘄𝗻 𝗼𝗻 𝘁𝗵𝗲 𝗠𝗶𝗹𝘃𝘂𝘀 𝗯𝗹𝗼𝗴: https://t.co/oFAc2cIyFx

💬0🔄0❤️0👀208

⚡ Powered by xgo.ing

𝗔 𝗹𝗼𝘁 𝗼𝗳 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗔𝗜 𝗳𝗲𝗮𝘁𝘂𝗿𝗲𝘀 𝘀𝘁𝗼𝗽 𝗮𝘁 𝗮𝗻𝘀𝘄𝗲𝗿𝗶𝗻𝗴 ...

Milvus (@milvusio) — Fri, 19 Jun 2026 15:00:01 GMT

𝗔 𝗹𝗼𝘁 𝗼𝗳 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗔𝗜 𝗳𝗲𝗮𝘁𝘂𝗿𝗲𝘀 𝘀𝘁𝗼𝗽 𝗮𝘁 𝗮𝗻𝘀𝘄𝗲𝗿𝗶𝗻𝗴 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀. 𝗔𝘁𝘁𝘂 𝟯.𝟬 𝗯𝗲𝘁𝗮 𝗴𝗼𝗲𝘀 𝗳𝘂𝗿𝘁𝗵𝗲𝗿: 𝗶𝘁𝘀 𝗮𝗴𝗲𝗻𝘁 𝗰𝗮𝗻 𝘁𝗮𝗸𝗲 𝗮𝗰𝘁𝗶𝗼𝗻.

Attu 3.0's AI agent connects to 50+ Milvus tools across collections, data operations, diagnostics, and RBAC. 𝗬𝗼𝘂 𝗱𝗲𝘀𝗰𝗿𝗶𝗯𝗲 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂 𝘄𝗮𝗻𝘁 𝗶𝗻 𝗻𝗮𝘁𝘂𝗿𝗮𝗹 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲, 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗮𝗴𝗲𝗻𝘁 𝗰𝗮𝗹𝗹𝘀 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝘁𝗼𝗼𝗹𝘀 𝘁𝗼 𝗿𝘂𝗻 𝗶𝘁.

You can ask it to list collections, create a collection with the right schema, insert test data, run a vector search, check cluster health, investigate slow search, inspect memory usage, compact a collection, or create a read-only user. 

𝗔𝗰𝘁𝗶𝗼𝗻𝘀 𝗮𝗿𝗲 𝗴𝗮𝘁𝗲𝗱 𝗯𝘆 𝗿𝗶𝘀𝗸:
• Read-only actions return results directly 
• Sensitive or destructive actions, such as dropping a collection or changing privileges, show a confirmation dialog with the exact parameters before anything runs 
• Every call is visible, including which tools ran, token usage, and any failures

You bring your own LLM: github.com/zilliztech/att…Seek, Gemini, or any OpenAI-compatible endpoint.milvus.io/blog/attu-3-0-…ted locally, and no agent traffic is routed through a Zilliz-managed service.

𝗧𝗿𝘆 𝗶𝘁 𝗵𝗲𝗿𝗲: https://t.co/gzwdbjtXcF
𝗢𝗿 𝗿𝗲𝗮𝗱 𝗮𝗯𝗼𝘂𝘁 𝗵𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀 𝗼𝗻 𝘁𝗵𝗲 𝗠𝗶𝗹𝘃𝘂𝘀 𝗯𝗹𝗼𝗴: https://t.co/Z37S2MmS29

💬0🔄1❤️1👀200📊1

⚡ Powered by xgo.ing

𝗬𝗼𝘂𝗿 𝘁𝗲𝘀𝘁 𝘀𝗲𝘁 𝘀𝗵𝗼𝘄𝘀 𝘀𝘁𝗿𝗼𝗻𝗴 𝗿𝗲𝗰𝗮𝗹𝗹, 𝗯𝘂𝘁 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗺𝗮𝘆 ...

Milvus (@milvusio) — Thu, 18 Jun 2026 15:30:00 GMT

𝗬𝗼𝘂𝗿 𝘁𝗲𝘀𝘁 𝘀𝗲𝘁 𝘀𝗵𝗼𝘄𝘀 𝘀𝘁𝗿𝗼𝗻𝗴 𝗿𝗲𝗰𝗮𝗹𝗹, 𝗯𝘂𝘁 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗺𝗮𝘆 𝘀𝘁𝗶𝗹𝗹 𝗳𝗮𝗶𝗹 𝗯𝗮𝗱𝗹𝘆 𝗳𝗼𝗿 𝗰𝗲𝗿𝘁𝗮𝗶𝗻 𝗾𝘂𝗲𝗿𝘆 𝘁𝘆𝗽𝗲𝘀. 𝗧𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗺𝗶𝗴𝗵𝘁 𝗯𝗲 𝗵𝗼𝘄 𝘆𝗼𝘂 𝗺𝗲𝗮𝘀𝘂𝗿𝗲 𝗿𝗲𝗰𝗮𝗹𝗹, 𝗲𝘀𝗽𝗲𝗰𝗶𝗮𝗹𝗹𝘆 𝗶𝗳 𝘆𝗼𝘂 𝗼𝗻𝗹𝘆 𝗹𝗼𝗼𝗸 𝗮𝘁 𝗮𝘃𝗲𝗿𝗮𝗴𝗲 𝗥𝗲𝗰𝗮𝗹𝗹@𝟱.

Say your average Recall@5 is 85%. That looks healthy at first glance. But break it down by query type, and you find exact-term queries are at 40%. The other categories pulled the average up, and you never saw where it failed.

𝗗𝗼 𝗻𝗼𝘁 𝘁𝗿𝗲𝗮𝘁 𝗿𝗲𝗰𝗮𝗹𝗹 𝗮𝘀 𝗼𝗻𝗲 𝗻𝘂𝗺𝗯𝗲𝗿. 𝗦𝗼𝗿𝘁 𝘆𝗼𝘂𝗿 𝘁𝗲𝘀𝘁 𝗰𝗮𝘀𝗲𝘀 𝗯𝘆 𝘁𝘆𝗽𝗲:
• Exact-term queries (product models, API names, contract IDs)
• Multi-hop questions (answer spread across several documents)
• Long-tail questions (rare, but high-risk when they fail)
• Unanswerable questions (not in the knowledge base — the system should say so)
• Permission-filtered questions (different users see different documents)

𝗣𝘂𝘁 𝗮𝘁 𝗹𝗲𝗮𝘀𝘁 𝟱–𝟭𝟬 𝗰𝗮𝘀𝗲𝘀 𝗶𝗻 𝗲𝗮𝗰𝗵 𝗰𝗮𝘁𝗲𝗴𝗼𝗿𝘆 𝗮𝗻𝗱 𝗰𝗵𝗲𝗰𝗸 𝗿𝗲𝗰𝗮𝗹𝗹 𝘀𝗲𝗽𝗮𝗿𝗮𝘁𝗲𝗹𝘆. 𝗪𝗵𝗲𝗻 𝗼𝗻𝗲 𝘀𝗲𝗴𝗺𝗲𝗻𝘁 𝗹𝗮𝗴𝘀, 𝘆𝗼𝘂 𝗸𝗻𝗼𝘄 𝘄𝗵𝗶𝗰𝗵 𝗽𝗮𝗿𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝘀𝘁𝗮𝗰𝗸 𝘁𝗼 𝗶𝗻𝘀𝗽𝗲𝗰𝘁.

💬0🔄0❤️0👀110

⚡ Powered by xgo.ing

In text retrieval, multi-vector's advantage is conditional. On short documents and simple queries, a...

Milvus (@milvusio) — Wed, 17 Jun 2026 15:20:49 GMT

In text retrieval, multi-vector's advantage is conditional. On short documents and simple queries, approximation usually erases its lead over dense. Visual documents flip that: multi-vector beat the dense baseline by 𝗻𝗲𝗮𝗿𝗹𝘆 𝟭𝟴 𝗽𝗼𝗶𝗻𝘁𝘀, and the lead held almost intact through approximation.
 
We ran ColQwen (multi-vector) against Qwen3-VL-Embedding (dense) on DocVQA. 𝗧𝗵𝗶𝘀 𝘁𝗮𝘀𝗸 𝗶𝘀 𝗺𝘂𝗹𝘁𝗶𝗺𝗼𝗱𝗮𝗹: 𝘁𝗵𝗲 𝗾𝘂𝗲𝗿𝘆 𝗶𝘀 𝘁𝗲𝘅𝘁, 𝘄𝗵𝗶𝗹𝗲 𝘁𝗵𝗲 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁 𝗶𝘀 𝗮𝗻 𝗶𝗺𝗮𝗴𝗲, 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗺𝗼𝗱𝗲𝗹 𝗲𝗻𝗰𝗼𝗱𝗲𝘀 𝘁𝗵𝗲 𝗶𝗺𝗮𝗴𝗲 𝗶𝗻𝘁𝗼 𝘃𝗲𝗰𝘁𝗼𝗿𝘀. For ColBERT-style models, such as ColQwen, the image is encoded into multiple vectors at the patch level. For dense models, such as Qwen3-VL-Embedding, the image is encoded into a single vector.
 
𝗘𝘅𝗮𝗰𝘁 𝘀𝗲𝗮𝗿𝗰𝗵 (BruteForce, the quality ceiling):
• Dense: 𝟬.𝟱𝟮𝟭 nDCG@10
• ColQwen2: 𝟬.𝟲𝟭𝟬 (+8.9 pt)
• ColQwen3: 𝟬.𝟲𝟵𝟴 (+17.7 pt)
 
𝗔𝗽𝗽𝗿𝗼𝘅𝗶𝗺𝗮𝘁𝗲 𝘀𝗲𝗮𝗿𝗰𝗵 (LEMUR, ratio=5.0):
• ColQwen2: 𝟬.𝟱𝟵𝟲 (+7.5 pt over dense)
• ColQwen3: 𝟬.𝟳𝟬𝟰 (+18.3 pt over dense)
 
𝗔𝗽𝗽𝗿𝗼𝘅𝗶𝗺𝗮𝘁𝗶𝗼𝗻 𝗰𝗼𝘀𝘁 𝘄𝗮𝘀 𝗲𝗳𝗳𝗲𝗰𝘁𝗶𝘃𝗲𝗹𝘆 𝘇𝗲𝗿𝗼. ColQwen3 landed 0.006 above its own exact score, which is noise on 100 queries. On text benchmarks like MS MARCO and SciFact, approximation usually wipes the multi-vector lead out. Here it didn't move.
 
𝗧𝗵𝗲 𝗴𝗮𝗽 𝗰𝗼𝗺𝗲𝘀 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝗽𝗮𝗴𝗲 𝗶𝘁𝘀𝗲𝗹𝗳: 𝘁𝗮𝗯𝗹𝗲𝘀, 𝗰𝗵𝗮𝗿𝘁𝘀, 𝗺𝘂𝗹𝘁𝗶-𝗰𝗼𝗹𝘂𝗺𝗻 𝗹𝗮𝘆𝗼𝘂𝘁𝘀, 𝗳𝗼𝗻𝘁 𝗵𝗶𝗲𝗿𝗮𝗿𝗰𝗵𝘆. A dense model folds all of that into one vector and loses the spatial structure. Patch-level multi-vectors keep each region as its own vector, so MaxSim can match a query against the specific parts of the page that matter. A single vector can't carry the structure of a full page.
 
𝗢𝗻𝗲 𝗰𝗮𝘃𝗲𝗮𝘁: 𝗧𝗼𝗸𝗲𝗻𝗔𝗡𝗡 𝗱𝗼𝗲𝘀𝗻'𝘁 𝘄𝗼𝗿𝗸 𝗵𝗲𝗿𝗲 𝗮𝘁 𝗮𝗹𝗹. Both models scored under 0.05. Visual models emit thousands of patches per page (ColQwen2: 5,143; ColQwen3: 1,250), and each patch covers so little of the image that per-patch ANN can't locate the right page. The usable strategies are the compression ones, MUVERA and LEMUR.
 
𝗜𝗳 𝘆𝗼𝘂'𝗿𝗲 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗶𝗻𝗴 𝗶𝗻𝘃𝗼𝗶𝗰𝗲𝘀, 𝗿𝗲𝗽𝗼𝗿𝘁𝘀, 𝘀𝗰𝗮𝗻𝘀, 𝗼𝗿 𝗣𝗗𝗙 𝗽𝗮𝗴𝗲𝘀 𝗯𝘆 𝘁𝗵𝗲𝗶𝗿 𝘃𝗶𝘀𝘂𝗮𝗹 𝗰𝗼𝗻𝘁𝗲𝗻𝘁, 𝗺𝘂𝗹𝘁𝗶-𝘃𝗲𝗰𝘁𝗼𝗿 𝘄𝗶𝘁𝗵 𝗟𝗘𝗠𝗨𝗥 𝗼𝗿 𝗠𝗨𝗩𝗘𝗥𝗔 𝗶𝘀 𝗮 𝗺𝗲𝗮𝘀𝘂𝗿𝗮𝗯𝗹𝗲 𝘀𝘁𝗲𝗽 𝘂𝗽 𝗳𝗿𝗼𝗺 𝗮 𝗱𝗲𝗻𝘀𝗲 𝗯𝗮𝘀𝗲𝗹𝗶𝗻𝗲, 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗹𝗲𝗮𝗱 𝘀𝘂𝗿𝘃𝗶𝘃𝗲𝘀 𝗼𝗻𝗰𝗲 𝘆𝗼𝘂 𝗺𝗼𝘃𝗲 𝗼𝗳𝗳 𝗲𝘅𝗮𝗰𝘁 𝘀𝗲𝗮𝗿𝗰𝗵.

💬0🔄0❤️3👀326📊1

⚡ Powered by xgo.ing

𝗜𝗳 𝘆𝗼𝘂 𝗿𝘂𝗻 𝗺𝗼𝗿𝗲 𝘁𝗵𝗮𝗻 𝗼𝗻𝗲 𝗠𝗶𝗹𝘃𝘂𝘀 𝗰𝗹𝘂𝘀𝘁𝗲𝗿, 𝘆𝗼𝘂 𝗸𝗻𝗼𝘄 𝘁𝗵𝗲 ...

Milvus (@milvusio) — Tue, 16 Jun 2026 15:30:00 GMT

𝗜𝗳 𝘆𝗼𝘂 𝗿𝘂𝗻 𝗺𝗼𝗿𝗲 𝘁𝗵𝗮𝗻 𝗼𝗻𝗲 𝗠𝗶𝗹𝘃𝘂𝘀 𝗰𝗹𝘂𝘀𝘁𝗲𝗿, 𝘆𝗼𝘂 𝗸𝗻𝗼𝘄 𝘁𝗵𝗲 𝘁𝗮𝗯 𝗽𝗿𝗼𝗯𝗹𝗲𝗺. 𝗡𝗼𝘄, 𝗶𝘁'𝘀 𝗮 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗼𝗳 𝘁𝗵𝗲 𝗽𝗮𝘀𝘁.

In the past, you would end up with dev in one browser tab, staging in another, and production in a third. Attu 2.x could only connect to one instance at a time, so every switch meant disconnecting, reconnecting, and waiting. And it was easy to run an operation against the wrong cluster without realizing it.

𝗔𝘁𝘁𝘂 𝟯.𝟬 𝗯𝗲𝘁𝗮 𝗽𝘂𝘁𝘀 𝗲𝘃𝗲𝗿𝘆 𝗰𝗼𝗻𝗻𝗲𝗰𝘁𝗶𝗼𝗻 𝗶𝗻 𝗼𝗻𝗲 𝘀𝗶𝗱𝗲𝗯𝗮𝗿 𝘄𝗶𝘁𝗵 𝗮 𝗹𝗶𝘃𝗲 𝗵𝗲𝗮𝗹𝘁𝗵 𝗶𝗻𝗱𝗶𝗰𝗮𝘁𝗼𝗿:
• 🟢 green means reachable, 🔴 red means down
• one click to switch, no reconnect needed
• each cluster gets its own scoped workspace for overview, data, users, and metrics
• comilvus.io/blog/attu-3-0-…s container restarts, so restarting Attu no longer wipes your setup

Full breakdown of the rebuild on the Milvus blog: https://t.co/Z37S2MmS29

💬0🔄0❤️0👀150