Milvus(@milvusio)

𝗠𝘂𝗹𝘁𝗶-𝗵𝗼𝗽 𝗥𝗔𝗚 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗮 𝗴𝗿𝗮𝗽𝗵 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 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.

💬1🔄1❤️3👀86📊2

⚡ 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👀229

⚡ 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👀177📊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❤️3👀205📊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👀176

⚡ 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👀244📊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👀221📊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👀684📊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👀195

⚡ 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👀231

⚡ 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👀252📊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👀303📊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👀199📊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👀235📊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👀246

⚡ 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👀115

⚡ 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👀3966📊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👀441📊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👀377📊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

⚡ Powered by xgo.ing

A user tells your support chatbot “my service keeps freezing.” Your knowledge base has the right art...

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

A user tells your support chatbot “my service keeps freezing.” Your knowledge base has the right articles, but retrieval misses them because the docs use different words like “unresponsive,” “blocked,” or “request hangs.”

𝗤𝘂𝗲𝗿𝘆 𝗿𝗲𝘄𝗿𝗶𝘁𝗶𝗻𝗴 𝗵𝗲𝗹𝗽𝘀 𝗰𝗹𝗼𝘀𝗲 𝘁𝗵𝗶𝘀 𝗴𝗮𝗽 𝗯𝗲𝗳𝗼𝗿𝗲 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹. You rewrite the user's input to include the terms your docs actually use. A vague question about "timeout settings" can be expanded with specific terms like Nginx, upstream, proxy_read_timeout.

𝗧𝘄𝗼 𝗰𝗼𝗺𝗺𝗼𝗻 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵𝗲𝘀 𝗮𝗿𝗲:
• Build a synonym dictionary: fast, but only covers the mappings you've defined
• Use a small query-rewriting model: more flexible, but adds latency

𝗤𝘂𝗲𝗿𝘆 𝗿𝗲𝘄𝗿𝗶𝘁𝗶𝗻𝗴 𝘄𝗼𝗿𝗸𝘀 𝗯𝗲𝘀𝘁 𝘄𝗵𝗲𝗻 𝘂𝘀𝗲𝗿𝘀 𝗮𝗻𝗱 𝗱𝗼𝗰𝘀 𝘀𝗽𝗲𝗮𝗸 𝘃𝗲𝗿𝘆 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲𝘀 — technical documentation, API references, troubleshooting guides. If your knowledge base is already in user language (support tickets, chat logs), the gap is small and the payoff is limited.

💬0🔄0❤️0👀131

⚡ Powered by xgo.ing

𝗠𝗶𝗹𝘃𝘂𝘀 𝗵𝗮𝘀 𝗿𝗲𝗹𝗲𝗮𝘀𝗲𝗱 𝗔𝘁𝘁𝘂 𝟯.𝟬 𝗕𝗲𝘁𝗮, 𝗮 𝗿𝗲𝗯𝘂𝗶𝗹𝘁 ...

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

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

It gives developers and operators one place to manage clusters, inspect data, troubleshoot issues, and move faster from local debugging to production operations.

What changed:
Multi-cluster management, with one-click switching and persistent local state.

A built-in AI Agent connected to 50+ Milvus tools, plus diagnostic skills for cluster health, search performance, writes, and configuration checks.

A redesigned data browser, Prometheus-backed metrics, an API Playground, GUI backup and restore, and simpler RBAC workflows.

We recorded a quick walkthrough of the new Attu experience, including cluster diagnostics, the data browser, API Playground, Agent setup, and links into Zilliz Cloud and Milvmilvus.io/blog/attu-3-0-… 3.0 Beta and tell us what you think: https://t.co/Z37S2MmS29

Your browser does not support the video tag.

🔗 View on Twitter

💬1🔄0❤️0👀233📊1

⚡ Powered by xgo.ing

𝗗𝗼 𝘆𝗼𝘂 𝗸𝗻𝗼𝘄 𝗵𝗼𝘄 𝗺𝗮𝗻𝘆 𝗯𝗶𝗿𝗱𝘀 𝘁𝗵𝗲𝗿𝗲 𝗮𝗿𝗲 𝗶𝗻 𝘁𝗵𝗲 𝗠𝗶𝗹𝘃𝘂𝘀 𝗮𝗻𝗱 ...

Milvus (@milvusio) — Fri, 12 Jun 2026 15:30:00 GMT

𝗗𝗼 𝘆𝗼𝘂 𝗸𝗻𝗼𝘄 𝗵𝗼𝘄 𝗺𝗮𝗻𝘆 𝗯𝗶𝗿𝗱𝘀 𝘁𝗵𝗲𝗿𝗲 𝗮𝗿𝗲 𝗶𝗻 𝘁𝗵𝗲 𝗠𝗶𝗹𝘃𝘂𝘀 𝗮𝗻𝗱 𝗭𝗶𝗹𝗹𝗶𝘇 𝗲𝗰𝗼𝘀𝘆𝘀𝘁𝗲𝗺?
More than you might expect. 
Welcome to the 𝗭𝗶𝗹𝗹𝗶𝘇 𝗕𝗶𝗿𝗱𝗽𝗲𝗱𝗶𝗮.

𝗠𝗶𝗹𝘃𝘂𝘀: 𝘁𝗵𝗲 𝗸𝗶𝘁𝗲 
A bird of prey that scans a wide territory before striking. Milvus follows the same pattern for vector search: able to scan hundred-billion-scale vectors in high-dimensional spaces, then find nearest neighbors fast.

𝗖𝗮𝗿𝗱𝗶𝗻𝗮𝗹: 𝘁𝗵𝗲 𝘀𝘁𝗮𝗻𝗱𝗼𝘂𝘁 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗲𝗿 
A cardinal is vivid, confident, and hard to miss on any branch. Same idea behind Cardinal — and hard to beat on benchmarks. It's Zilliz Cloud's most advanced vector search engine built for high-performance ANN search, top-K, range search, and filtering-heavy workloads.

𝗪𝗼𝗼𝗱𝗽𝗲𝗰𝗸𝗲𝗿: 𝘁𝗵𝗲 𝗿𝗲𝗹𝗶𝗮𝗯𝗹𝗲 𝘄𝗿𝗶𝘁𝗲𝗿 
A woodpecker strikes again and again with steady force and shock resistance. Woodpecker, Milvus's cloud-native WAL, absorbs continuous writes, records them in order, and keeps recovery possible after failures — no Kafka or Pulsar required.

𝗟𝗼𝗼𝗻: 𝘁𝗵𝗲 𝗱𝗲𝗲𝗽 𝗱𝗶𝘃𝗲𝗿 
Loons are diving birds and they dive deep, stay submerged, and use denser bones to move with control beneath the surface. That's the idea behind Loon, the new storage engine powering Milvus 3.0 as well as the Zilliz Vector Lakebase: dive into the data lake, find the right version of constantly changing vector data, and read only what the query needs.

𝗕𝗶𝗿𝗱𝘄𝗮𝘁𝗰𝗵𝗲𝗿: 𝘁𝗵𝗲 𝗼𝗯𝘀𝗲𝗿𝘃𝗲𝗿 
A birdwatcher doesn't join the flock. They watch closely. Birdwatcher inspects the internal state of Milvus components so operators can see exactly what's happening.

Behind every bird name is architecture doing serious work.

Which birds do you like best? Drop your pick in the comments.

💬1🔄0❤️2👀196📊1

⚡ Powered by xgo.ing

𝗟𝗘𝗠𝗨𝗥 𝗶𝘀 𝘁𝗵𝗲 𝗺𝘂𝗹𝘁𝗶-𝘃𝗲𝗰𝘁𝗼𝗿 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆 𝘁𝗵𝗮𝘁 𝗹𝗼𝗼𝗸𝘀 𝗲𝗮𝘀𝗶𝗲𝘀𝘁 ...

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

𝗟𝗘𝗠𝗨𝗥 𝗶𝘀 𝘁𝗵𝗲 𝗺𝘂𝗹𝘁𝗶-𝘃𝗲𝗰𝘁𝗼𝗿 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆 𝘁𝗵𝗮𝘁 𝗹𝗼𝗼𝗸𝘀 𝗲𝗮𝘀𝗶𝗲𝘀𝘁 𝘁𝗼 𝗮𝗱𝗼𝗽𝘁 — 𝗻𝗼 𝘁𝘂𝗻𝗶𝗻𝗴, 𝗱𝗮𝘁𝗮-𝗱𝗿𝗶𝘃𝗲𝗻, 𝗰𝗼𝗺𝗽𝗿𝗲𝘀𝘀𝗲𝘀 𝘆𝗼𝘂𝗿 𝗺𝘂𝗹𝘁𝗶-𝘃𝗲𝗰𝘁𝗼𝗿𝘀 𝗶𝗻𝘁𝗼 𝘀𝗶𝗻𝗴𝗹𝗲 𝘃𝗲𝗰𝘁𝗼𝗿𝘀 𝗼𝗻 𝗶𝘁𝘀 𝗼𝘄𝗻. 𝗕𝘂𝘁 𝗼𝗻 𝗹𝗼𝗻𝗴-𝘁𝗮𝗶𝗹𝗲𝗱 𝗰𝗼𝗿𝗽𝗼𝗿𝗮, 𝗶𝘁 𝗰𝗮𝗻 𝗾𝘂𝗶𝗲𝘁𝗹𝘆 𝘀𝘁𝗮𝗿𝘁 𝗿𝗮𝗻𝗸𝗶𝗻𝗴 𝗯𝘆 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁 𝗹𝗲𝗻𝗴𝘁𝗵 𝗶𝗻𝘀𝘁𝗲𝗮𝗱 𝗼𝗳 𝗿𝗲𝗹𝗲𝘃𝗮𝗻𝗰𝗲.

𝗟𝗼𝗧𝗧𝗘, 𝗝𝗶𝗻𝗮-𝗖𝗼𝗹𝗕𝗘𝗥𝗧-𝘃𝟮: 
📈 𝗘𝘅𝗮𝗰𝘁 𝗠𝗮𝘅𝗦𝗶𝗺 — nDCG@10 = 0.722, R@100 = 98%
📉 𝗟𝗘𝗠𝗨𝗥 — nDCG@10 = 0.109, R@100 = 30.5%

𝗪𝗵𝘆? 𝗜𝘁'𝘀 𝗻𝗼𝘁 𝗮𝗻 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗯𝘂𝗴 — 𝗶𝘁'𝘀 𝗮 𝗹𝗲𝗻𝗴𝘁𝗵 𝗯𝗶𝗮𝘀 𝗯𝗮𝗸𝗲𝗱 𝗶𝗻𝘁𝗼 𝗵𝗼𝘄 𝗟𝗘𝗠𝗨𝗥 𝘁𝗿𝗮𝗶𝗻𝘀.
LEMUR's labels are MaxSim scores — for a sampled vector, its highest inner product against any token in a document. A longer document has more tokens, so it's more likely to hold a high value regardless of relevance, a pure statistical effect. The MLP learns "longer scores higher" instead of "more relevant scores higher," and the ranking follows length.

𝗜𝘁 𝗼𝗻𝗹𝘆 𝗯𝗿𝗲𝗮𝗸𝘀 𝘄𝗵𝗲𝗻 𝘁𝘄𝗼 𝘁𝗵𝗶𝗻𝗴𝘀 𝗹𝗶𝗻𝗲 𝘂𝗽: 
• First, a length-sensitive model, which comes with high separability. On Jina, docs under 50 tokens average a MaxSim of 0.492; docs over 1,000 average 0.666 — a 0.174 gap the model assigns to length alone. 
• Second, heavy length variance. LoTTE runs 10 to 4,109 tokens, about a 400x range.
𝗟𝗼𝗧𝗧𝗘 𝗵𝗮𝘀 𝗯𝗼𝘁𝗵, 𝗮𝗻𝗱 𝗶𝘁 𝗳𝗮𝗶𝗹𝘀 𝗮𝘁 𝗰𝗼𝗺𝗽𝗿𝗲𝘀𝘀𝗶𝗼𝗻, 𝗻𝗼𝘁 𝗿𝗲𝗿𝗮𝗻𝗸𝗶𝗻𝗴 — 𝗠𝗮𝘁𝗵 𝗥@𝟭𝟬𝟬 𝘁𝗵𝗲𝗿𝗲 𝗶𝘀 𝟮𝟰.𝟳%, 𝘀𝗼 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝘀 𝗮𝗿𝗲 𝗱𝗿𝗼𝗽𝗽𝗲𝗱 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝗰𝗮𝗻𝗱𝗶𝗱𝗮𝘁𝗲 𝘀𝗲𝘁 𝗯𝗲𝗳𝗼𝗿𝗲 𝗿𝗲𝗿𝗮𝗻𝗸𝗶𝗻𝗴 𝗰𝗮𝗻 𝗵𝗲𝗹𝗽.

𝗧𝗵𝗲 𝗰𝗼𝗻𝘁𝗿𝗼𝗹 𝗿𝘂𝗻𝘀 𝗶𝘀𝗼𝗹𝗮𝘁𝗲 𝘁𝗵𝗲 𝗰𝗮𝘂𝘀𝗲: For length-uniform data (SciFact): same LEMUR behaves normally — 0.651 vs BruteForce 0.719. For a low-separability model (AnswerAI on LoTTE): unaffected — R@100 91.5%.

𝗧𝘄𝗼 𝗰𝗵𝗲𝗰𝗸𝘀 𝗳𝗼𝗿 𝘆𝗼𝘂𝗿 𝗼𝘄𝗻 𝗰𝗼𝗿𝗽𝘂𝘀: 
→ 𝗟𝗲𝗻𝗴𝘁𝗵: if P90/P10 is under 5 it's fairly uniform and LEMUR is usually safe; over 20 (LoTTE is ~400), be cautious. 
→ 𝗦𝗲𝗽𝗮𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝘆: sample ~1,000 token vectors, take the std of their MaxSim scores. Under 0.08 is low, LEMUR is safe; over 0.12 is high — use TokenANN or MUVERA.

𝗜𝗳 𝘆𝗼𝘂'𝗿𝗲 𝗮𝗹𝗿𝗲𝗮𝗱𝘆 𝗰𝗼𝗺𝗺𝗶𝘁𝘁𝗲𝗱 𝘁𝗼 𝗟𝗘𝗠𝗨𝗥, 𝗹𝗲𝗻𝗴𝘁𝗵-𝗯𝗮𝗹𝗮𝗻𝗰𝗲𝗱 𝘀𝗮𝗺𝗽𝗹𝗶𝗻𝗴 𝗵𝗲𝗹𝗽𝘀: 𝘀𝘁𝗿𝗮𝘁𝗶𝗳𝘆 𝗯𝘆 𝗹𝗲𝗻𝗴𝘁𝗵 (𝟬–𝟭𝟬𝟬, 𝟭𝟬𝟬–𝟯𝟬𝟬, 𝟯𝟬𝟬–𝟭,𝟬𝟬𝟬, >𝟭,𝟬𝟬𝟬 𝘁𝗼𝗸𝗲𝗻𝘀) 𝗮𝗻𝗱 𝗱𝗿𝗮𝘄 𝗲𝗾𝘂𝗮𝗹 𝘀𝗮𝗺𝗽𝗹𝗲𝘀 𝗽𝗲𝗿 𝗯𝗮𝗻𝗱. 𝗜𝘁 𝘄𝗲𝗮𝗸𝗲𝗻𝘀 𝘁𝗵𝗲 𝗹𝗲𝗻𝗴𝘁𝗵 𝘀𝗶𝗴𝗻𝗮𝗹 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗳𝘂𝗹𝗹𝘆 𝗿𝗲𝗺𝗼𝘃𝗶𝗻𝗴 𝗶𝘁.

💬0🔄0❤️0👀145📊1

⚡ Powered by xgo.ing

𝗛𝗼𝘄 𝗱𝗼𝗲𝘀 𝗮 𝘀𝘁𝗼𝗰𝗸 𝗺𝗲𝗱𝗶𝗮 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺 𝘄𝗶𝘁𝗵 𝟮𝟬𝟬𝗠+ 𝘃𝗶𝘀𝘂𝗮𝗹 ...

Milvus (@milvusio) — Wed, 10 Jun 2026 15:17:00 GMT

𝗛𝗼𝘄 𝗱𝗼𝗲𝘀 𝗮 𝘀𝘁𝗼𝗰𝗸 𝗺𝗲𝗱𝗶𝗮 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺 𝘄𝗶𝘁𝗵 𝟮𝟬𝟬𝗠+ 𝘃𝗶𝘀𝘂𝗮𝗹 𝗮𝘀𝘀𝗲𝘁𝘀 𝗿𝗲𝗱𝘂𝗰𝗲 𝗰𝗼𝘀𝘁𝘀 𝘄𝗵𝗶𝗹𝗲 𝗺𝗮𝗶𝗻𝘁𝗮𝗶𝗻𝗶𝗻𝗴 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗾𝘂𝗮𝗹𝗶𝘁𝘆?

Moving from keyword search to semantic search changes the infrastructure requirements behind image retrieval.

At a smaller scale, that can be manageable.

But for a stock media platform like 𝟭𝟮𝟯𝗥𝗙, the problem changes quickly once the asset library grows into the hundreds of millions. Latency, cost, indexing stability, and operational complexity all become harder to control.

After migrating to 𝗭𝗶𝗹𝗹𝗶𝘇 𝗖𝗹𝗼𝘂𝗱, 123RF 𝗰𝘂𝘁 𝗰𝗼𝘀𝘁𝘀 𝗯𝘆 𝟱𝟬% and brought query latency down from around 𝟭𝟬𝟬𝗺𝘀 𝘁𝗼 𝟯𝟬–𝟱𝟬𝗺𝘀.

For a stock content platform, several capabilities mattered most:

𝟭. 𝗦𝘁𝗿𝗼𝗻𝗴 𝘀𝘂𝗽𝗽𝗼𝗿𝘁 𝗳𝗼𝗿 𝗱𝗲𝗻𝘀𝗲 𝘃𝗲𝗰𝘁𝗼𝗿𝘀
 - Search quality in visual content is not static. It needs to evolve with new content types, modalities, and user intent.
 - Zilliz Cloud helps 123RF store, index, and retrieve CLIP-generated dense vectors at scale, capturing semantic relationships that keyword search cannot easily represent.

𝟮. 𝗗𝘆𝗻𝗮𝗺𝗶𝗰 𝘀𝗰𝗮𝗹𝗶𝗻𝗴
 - Stock content platforms often see clear traffic peaks and valleys.
 - With Zilliz Cloud, clusters can scale up or down based on expected query load, controlling costs during quieter periods while keeping response times stable.

𝟯. 𝗗𝗲𝗰𝗼𝘂𝗽𝗹𝗲𝗱 𝗱𝗮𝘁𝗮 𝗶𝗻𝗰𝗿𝗲𝗺𝗲𝗻𝘁𝗮𝗹 𝗶𝗻𝗴𝗲𝘀𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗼𝗻𝗹𝗶𝗻𝗲 𝘀𝗲𝗮𝗿𝗰𝗵
 - Content platforms need to keep adding new assets without disrupting live search.
 - Zilliz Cloud decouples data ingestion from online queries, allowing new assets to be written into the system steadily and quickly without downtime.

𝟰. 𝗖𝘂𝘀𝘁𝗼𝗺 𝗿𝗮𝗻𝗸𝗶𝗻𝗴 𝗹𝗼𝗴𝗶𝗰
 - Search for stock media cannot rely on vector similarity alone. Business-specific ranking rules can also affect which results should appear first.
 - Zilliz Cloud supports custom reranking logic, helping search results better align with platform goals.

At this scale, the real challenge of production semantic search is keeping search fast, stable, and easy to keep improving as the system grows.

💬1🔄0❤️1👀158📊2

⚡ Powered by xgo.ing

𝗪𝗲 𝗰𝗹𝗮𝘀𝘀𝗶𝗳𝘆 𝗛𝗲𝗿𝗺𝗲𝘀 𝘄𝗶𝘁𝗵 𝘀𝗸𝗶𝗹𝗹𝘀 𝗮𝘀 𝗮𝗻 𝗟𝟯. 𝗛𝗲𝗿𝗲'𝘀 𝘄𝗵𝘆, 𝗮𝗻𝗱 ...

Milvus (@milvusio) — Tue, 09 Jun 2026 15:43:00 GMT

𝗪𝗲 𝗰𝗹𝗮𝘀𝘀𝗶𝗳𝘆 𝗛𝗲𝗿𝗺𝗲𝘀 𝘄𝗶𝘁𝗵 𝘀𝗸𝗶𝗹𝗹𝘀 𝗮𝘀 𝗮𝗻 𝗟𝟯. 𝗛𝗲𝗿𝗲'𝘀 𝘄𝗵𝘆, 𝗮𝗻𝗱 𝗵𝗲𝗿𝗲'𝘀 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂 𝗰𝗮𝗻 𝗱𝗼 𝘁𝗼 𝗴𝗲𝘁 𝗺𝗼𝗿𝗲 𝗼𝘂𝘁 𝗼𝗳 𝗶𝘁.

We classify agents into four levels. L1 does the work for you. L2 gets better on its own across sessions. L3 applies the judgment you’ve encoded, even when you are not actively supervising it. L4 improves the users' judgment, not just their output.

Hermes + skills is already a strong L3 stack: persistent memory, reusable skills, and a layer for carrying identity and preferences across sessions. But it's still L3, and L3 has its drawbacks.

𝗧𝗵𝗲 𝗯𝗶𝗴𝗴𝗲𝘀𝘁 𝗱𝗿𝗮𝘄𝗯𝗮𝗰𝗸 𝗼𝗳 𝗟𝟯 𝗮𝗴𝗲𝗻𝘁𝘀 𝗶𝘀 𝘁𝗵𝗮𝘁 𝘆𝗼𝘂𝗿 𝗯𝗿𝗮𝗶𝗻 𝗰𝗮𝗽𝘀 𝘁𝗵𝗲𝗶𝗿 𝗽𝗼𝘁𝗲𝗻𝘁𝗶𝗮𝗹. They can run many tasks in parallel, but you can't review them that way. Switching between sessions to check each one costs real cognitive effort, and the more you switch, the worse your judgment gets across all of them.

𝗧𝗵𝗲 𝘄𝗮𝘆 𝘁𝗼 𝗴𝗲𝘁 𝘁𝗵𝗲 𝗺𝗼𝘀𝘁 𝗼𝘂𝘁 𝗼𝗳 𝗟𝟯 𝗶𝘀 𝘁𝗼 𝗴𝗶𝘃𝗲 𝘁𝗵𝗲 𝗮𝗴𝗲𝗻𝘁 𝘆𝗼𝘂𝗿 𝗷𝘂𝗱𝗴𝗺𝗲𝗻𝘁 𝘂𝗽 𝗳𝗿𝗼𝗻𝘁: 𝘆𝗼𝘂𝗿 𝗳𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸, 𝘆𝗼𝘂𝗿 𝗽𝗿𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀, 𝗵𝗼𝘄 𝘆𝗼𝘂 𝘄𝗲𝗶𝗴𝗵 𝘁𝗿𝗮𝗱𝗲𝗼𝗳𝗳𝘀, 𝘄𝗵𝗮𝘁 𝗴𝗼𝗼𝗱 𝗹𝗼𝗼𝗸𝘀 𝗹𝗶𝗸𝗲. It evaluates its own output against those standards. You stop switching between sessions to make decisions, and the agent's throughput is less bottlenecked by your attention.

𝗟𝟯 𝗮𝗴𝗲𝗻𝘁𝘀 𝘀𝘁𝗶𝗹𝗹 𝗵𝗮𝘃𝗲 𝗮 𝗹𝗶𝗺𝗶𝘁. The agent can only be as good as the judgment you gave it, and that judgment is only as current as the last time you updated it. If you're not growing, your rules go stale, and the agent keeps performing inside a dated framework.

That's the L4 problem: how does the agent improve the person using it, not just serve them faster? More on that next.

💬0🔄0❤️3👀175📊1

⚡ Powered by xgo.ing

📣 𝗢𝘂𝗿 𝘄𝗲𝗯𝗶𝗻𝗮𝗿 𝗮𝗯𝗼𝘂𝘁 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗶𝘀 𝗵𝗮𝗽𝗽𝗲𝗻𝗶𝗻𝗴 𝘁𝗼𝗱𝗮𝘆! Join us...

Milvus (@milvusio) — Mon, 08 Jun 2026 14:23:00 GMT

📣 𝗢𝘂𝗿 𝘄𝗲𝗯𝗶𝗻𝗮𝗿 𝗮𝗯𝗼𝘂𝘁 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 𝗶𝘀 𝗵𝗮𝗽𝗽𝗲𝗻𝗶𝗻𝗴 𝘁𝗼𝗱𝗮𝘆! 

Join us with core maintainers Li Liu and Jiang Chen for:
Milvus 3.0 architecture → A clear picture of the Milvus 3.0 roadmap → How Milvus 3.0 powers Zilliz Vector Lakebase → 15–20 min AMA with maintainers

zilliz.com/event/whats-ne…0 #Milvus�#VectorDatabase/#Zillizv#VectorSearchv#AIInfrastructuree #Zilliz#VectorSearch#AIInfrastructure

Milvus@milvusio

🌐 𝗪𝗲𝗯𝗶𝗻𝗮𝗿 | 𝗪𝗵𝗮𝘁’𝘀 𝗡𝗲𝘄 𝗶𝗻 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬: 𝗟𝗶𝘃𝗲 𝗪𝗮𝗹𝗸𝘁𝗵𝗿𝗼𝘂𝗴𝗵 & 𝗔𝗠𝗔, 𝗝𝘂𝗻𝗲 𝟴 𝗼𝗻𝗹𝗶𝗻𝗲

Milvus 3.0 beta is the biggest architectural upgrade since the project began. It brings native support for indexing and querying vectors directly on your data lake, along with a query engine that goes beyond top-K search.

In this live session, core maintainers Li Liu and Jiang Chen will walk through what shipped, the design choices behind it, and how Milvus 3.0 powers 𝗭𝗶𝗹𝗹𝗶𝘇 𝗩𝗲𝗰𝘁𝗼𝗿 𝗟𝗮𝗸𝗲𝗯𝗮𝘀𝗲.

🎤 𝗧𝗼𝗽𝗶𝗰𝘀
• What changed in Milvus 3.0 beta
• Why data lake-native vector search matters
• What’s in beta now and what’s coming in GA
• How Milvus 3.0 powers Zilliz Vector Lakebase
• 15–20zilliz.com/event/whats-ne… maintainers

📅 𝗝𝘂𝗻𝗲 𝟴, 𝟮𝟬𝟮𝟲, 𝟰:𝟬𝟬 𝗽𝗺 𝗣𝗗𝗧
🔗 Register here: https://t.co/ccpclyAQa8

Bring your questions about migration, performance, arc#Milvusr#VectorDatabasee#Zilliz’d like to ask the maintainers. Looking forward to the conversation! 
#Milvus#VectorDatabase#Zilliz

🔗 View Quoted Tweet

💬0🔄0❤️0👀215

⚡ Powered by xgo.ing

𝗬𝗼𝘂 𝗰𝗮𝗻 𝗿𝘂𝗻 𝟮𝟱 𝗺𝗶𝗹𝗹𝗶𝗼𝗻 𝘃𝗲𝗰𝘁𝗼𝗿𝘀 𝗶𝗻 𝗠𝗶𝗹𝘃𝘂𝘀 𝘂𝘀𝗶𝗻𝗴 𝘂𝗻𝗱𝗲𝗿 ...

Milvus (@milvusio) — Fri, 05 Jun 2026 17:58:00 GMT

𝗬𝗼𝘂 𝗰𝗮𝗻 𝗿𝘂𝗻 𝟮𝟱 𝗺𝗶𝗹𝗹𝗶𝗼𝗻 𝘃𝗲𝗰𝘁𝗼𝗿𝘀 𝗶𝗻 𝗠𝗶𝗹𝘃𝘂𝘀 𝘂𝘀𝗶𝗻𝗴 𝘂𝗻𝗱𝗲𝗿 𝟭𝗚𝗕 𝗼𝗳 𝗺𝗲𝗺𝗼𝗿𝘆. 

A user had 25M image vectors, each with 1280 dimensions, and only 32GB of memory available for Milvus on a single machine. The default FP32 sizing estimate was 139GB.

They first tried more advanced indexes, but neither worked out: 
• 𝗔𝗜𝗦𝗔𝗤 looked right for constrained hardware, but the build path was too heavy for the machine.
• 𝗜𝗩𝗙_𝗙𝗟𝗔𝗧 built successfully, but the collection load hung at 14% and never finished.

After working with our developers, the user switched to 𝗙𝗟𝗔𝗧, the simplest index in Milvus.
FLAT avoided extra ANN structures and build/load complexity, while Milvus provided the pieces that made the setup practical:
• 𝗙𝗣𝟭𝟲 storage cut each vector dimension from 4 bytes to 2 bytes, reducing raw vector data by half.
• 𝗺𝗺𝗮𝗽 let Milvus access raw vector data through memory-mapped files instead of loading it all into process memory.
• 𝗦𝗰𝗮𝗹𝗮𝗿 𝗳𝗶𝗹𝘁𝗲𝗿𝗶𝗻𝗴 narrowed each query first using fields like dataid and classid, so Milvus compared only a few thousand vectors instead of 25 million.

𝗧𝗵𝗲 𝗿𝗲𝘀𝘂𝗹𝘁: 𝗮𝗿𝗼𝘂𝗻𝗱 𝟲𝟬𝟬𝗠𝗕 𝗼𝗳 𝗿𝗲𝘀𝗶𝗱𝗲𝗻𝘁 𝗺𝗲𝗺𝗼𝗿𝘆 𝗮𝗻𝗱 𝘄𝗮𝗿𝗺 𝗾𝘂𝗲𝗿𝗶𝗲𝘀 𝘂𝗻𝗱𝗲𝗿 𝟭𝟬𝟬𝗺𝘀.

When the real search space is much smaller than the full comilvus.io/blog/25-millio…enant RAG, labeled image search, or e-commerce search, FLAT + FP16 + mmap can be a practical option.

Full breakdown in the blog: https://t.co/1aBXgMhf2l

💬0🔄2❤️13👀1004📊5

⚡ Powered by xgo.ing

𝗪𝗲𝗯𝗶𝗻𝗮𝗿 𝗥𝗲𝗺𝗶𝗻𝗱𝗲𝗿 | 𝗪𝗵𝗮𝘁’𝘀 𝗡𝗲𝘄 𝗶𝗻 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬: 𝗟𝗶𝘃𝗲 ...

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

𝗪𝗲𝗯𝗶𝗻𝗮𝗿 𝗥𝗲𝗺𝗶𝗻𝗱𝗲𝗿 | 𝗪𝗵𝗮𝘁’𝘀 𝗡𝗲𝘄 𝗶𝗻 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬: 𝗟𝗶𝘃𝗲 𝗪𝗮𝗹𝗸𝘁𝗵𝗿𝗼𝘂𝗴𝗵 & 𝗔𝗠𝗔, 𝗵𝗮𝗽𝗽𝗲𝗻𝗶𝗻𝗴 𝗻𝗲𝘅𝘁 𝗠𝗼𝗻𝗱𝗮𝘆

Milvus 3.0 marks one of the most important architectural updates since the project began. If you’re using Milvus to build RAG, multimodal search, recommendation systems, and AI agent memory, or if you’re dealing with data silos, top-K limits, schema evolution, and hybrid search pipelines, this webinar is for you.

Core Milvus maintainers Li Liu and Jiang Chen will walk you through the key design decisions behind Milvus 3.0 and why they matter for your stack. We’ll also set aside 15–20 minutes for an AMA, so you can ask your questions directly.

Can’t join live? Register now and we’ll send you the recording and demo after the session.

Milvus@milvusio

🌐 𝗪𝗲𝗯𝗶𝗻𝗮𝗿 | 𝗪𝗵𝗮𝘁’𝘀 𝗡𝗲𝘄 𝗶𝗻 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬: 𝗟𝗶𝘃𝗲 𝗪𝗮𝗹𝗸𝘁𝗵𝗿𝗼𝘂𝗴𝗵 & 𝗔𝗠𝗔, 𝗝𝘂𝗻𝗲 𝟴 𝗼𝗻𝗹𝗶𝗻𝗲

Milvus 3.0 beta is the biggest architectural upgrade since the project began. It brings native support for indexing and querying vectors directly on your data lake, along with a query engine that goes beyond top-K search.

In this live session, core maintainers Li Liu and Jiang Chen will walk through what shipped, the design choices behind it, and how Milvus 3.0 powers 𝗭𝗶𝗹𝗹𝗶𝘇 𝗩𝗲𝗰𝘁𝗼𝗿 𝗟𝗮𝗸𝗲𝗯𝗮𝘀𝗲.

🎤 𝗧𝗼𝗽𝗶𝗰𝘀
• What changed in Milvus 3.0 beta
• Why data lake-native vector search matters
• What’s in beta now and what’s coming in GA
• How Milvus 3.0 powers Zilliz Vector Lakebase
• 15–20zilliz.com/event/whats-ne… maintainers

📅 𝗝𝘂𝗻𝗲 𝟴, 𝟮𝟬𝟮𝟲, 𝟰:𝟬𝟬 𝗽𝗺 𝗣𝗗𝗧
🔗 Register here: https://t.co/ccpclyAQa8

Bring your questions about migration, performance, arc#Milvusr#VectorDatabasee#Zilliz’d like to ask the maintainers. Looking forward to the conversation! 
#Milvus#VectorDatabase#Zilliz

🔗 View Quoted Tweet

💬0🔄0❤️0👀202

⚡ Powered by xgo.ing

With the same multi-vector model, and the same dataset, nDCG@10 can drop from 0.701 to 0.109 — rough...

Milvus (@milvusio) — Thu, 04 Jun 2026 15:37:00 GMT

With the same multi-vector model, and the same dataset, nDCG@10 can drop from 0.701 to 0.109 — roughly a 6x gap. Why? It's because you changed the approximate retrieval strategy.
 𝗜𝗻 𝗺𝘂𝗹𝘁𝗶-𝘃𝗲𝗰𝘁𝗼𝗿 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹, 𝗽𝗶𝗰𝗸𝗶𝗻𝗴 𝘁𝗵𝗲 𝘄𝗿𝗼𝗻𝗴 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆 𝗰𝗮𝗻 𝗰𝗼𝘀𝘁 𝘆𝗼𝘂 𝗺𝗼𝗿𝗲 𝘁𝗵𝗮𝗻 𝗽𝗶𝗰𝗸𝗶𝗻𝗴 𝘁𝗵𝗲 𝘄𝗿𝗼𝗻𝗴 𝗺𝗼𝗱𝗲𝗹.

Multi-vector models like ColBERT turn every token in a document into its own vector. You can't just load millions of token vectors into an ANN index and search, because the score that matters is document-level MaxSim — for each query token, find its closest token in the document, then sum. 𝗦𝗼 𝗲𝘃𝗲𝗿𝘆 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵 𝗿𝘂𝗻𝘀 𝗶𝗻 𝘁𝘄𝗼 𝘀𝘁𝗮𝗴𝗲𝘀: 𝗮𝗻 𝗮𝗽𝗽𝗿𝗼𝘅𝗶𝗺𝗮𝘁𝗲 𝘀𝗲𝗮𝗿𝗰𝗵 𝗽𝗶𝗰𝗸𝘀 𝗰𝗮𝗻𝗱𝗶𝗱𝗮𝘁𝗲 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝘀 𝗳𝗶𝗿𝘀𝘁, 𝘁𝗵𝗲𝗻 𝗲𝘅𝗮𝗰𝘁 𝗠𝗮𝘅𝗦𝗶𝗺 𝗿𝗲-𝗿𝗮𝗻𝗸𝘀 𝘁𝗵𝗲𝗺. 𝗧𝗵𝗲 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀 𝗼𝗻𝗹𝘆 𝗱𝗶𝗳𝗳𝗲𝗿 𝗶𝗻 𝗵𝗼𝘄 𝘁𝗵𝗲𝘆 𝗱𝗼 𝘁𝗵𝗮𝘁 𝗳𝗶𝗿𝘀𝘁 𝘀𝘁𝗲𝗽.

𝗪𝗲 𝘁𝗲𝘀𝘁𝗲𝗱 𝘁𝗵𝗿𝗲𝗲: 𝗧𝗼𝗸𝗲𝗻𝗔𝗡𝗡 (𝗶𝗻𝗱𝗲𝘅 𝗲𝘃𝗲𝗿𝘆 𝘁𝗼𝗸𝗲𝗻 𝘃𝗲𝗰𝘁𝗼𝗿 𝗱𝗶𝗿𝗲𝗰𝘁𝗹𝘆), 𝗠𝗨𝗩𝗘𝗥𝗔 (𝗿𝗮𝗻𝗱𝗼𝗺-𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝗶𝗼𝗻 𝗰𝗼𝗺𝗽𝗿𝗲𝘀𝘀𝗶𝗼𝗻), 𝗟𝗘𝗠𝗨𝗥 (𝘁𝗿𝗮𝗶𝗻 𝗮𝗻 𝗠𝗟𝗣 𝘁𝗼 𝗰𝗼𝗺𝗽𝗿𝗲𝘀𝘀).
On LoTTE, with Jina-ColBERT-v2 held fixed:
📈 TokenANN — nDCG@10 = 0.701
📉 LEMUR — nDCG@10 = 0.109

The only thing that changed is the first-stage approximation. For scale: moving from a plain dense model up to this multi-vector one lifted the exact score from 0.611 to 0.722 on the same data. The loss from the wrong strategy was bigger than the gain from the better model.

𝗪𝗵𝘆? 𝗔 𝘀𝘁𝗿𝗼𝗻𝗴 𝗽𝗿𝗲𝗱𝗶𝗰𝘁𝗼𝗿 𝗶𝘀 𝗲𝗺𝗯𝗲𝗱𝗱𝗶𝗻𝗴-𝘀𝗽𝗮𝗰𝗲 𝘀𝗲𝗽𝗮𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝘆 — 𝘄𝗵𝗲𝘁𝗵𝗲𝗿 𝗮 𝗺𝗼𝗱𝗲𝗹'𝘀 𝘁𝗼𝗸𝗲𝗻 𝘃𝗲𝗰𝘁𝗼𝗿𝘀 𝘀𝗶𝘁 𝗳𝗮𝗿 𝗮𝗽𝗮𝗿𝘁 𝗼𝗿 𝗽𝗶𝗹𝗲 𝘁𝗼𝗴𝗲𝘁𝗵𝗲𝗿.
𝗙𝗼𝗿 𝘀𝗽𝗿𝗲𝗮𝗱 𝗼𝘂𝘁 (𝗝𝗶𝗻𝗮): each token is a precise probe, so TokenANN and MUVERA land on the right document tokens. LEMUR, though, risks collapsing on long-tailed data. 
𝗙𝗼𝗿 𝗰𝗹𝘂𝘀𝘁𝗲𝗿𝗲𝗱 (𝗔𝗻𝘀𝘄𝗲𝗿𝗔𝗜): one query token pulls back a crowd of close-but-irrelevant tokens, so TokenANN and MUVERA produce weak candidates. LEMUR is the one that still works.

𝗬𝗼𝘂 𝗰𝗮𝗻 𝗺𝗲𝗮𝘀𝘂𝗿𝗲 𝘀𝗲𝗽𝗮𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗯𝗲𝗳𝗼𝗿𝗲 𝗰𝗼𝗺𝗺𝗶𝘁𝘁𝗶𝗻𝗴. Sample a few hundred token vectors, treat each as a query, and take the standard deviation of their MaxSim scores across documents. Jina sits at 0.157; AnswerAI at 0.050 — at 0.050, nearly every document scores the same, so relevant and irrelevant blur. Recall tracks it: Jina's TokenANN holds Math R@100 of 68.5–88.5% across the four datasets, AnswerAI's 44.6–65.5%.

𝗦𝗼 𝗯𝗲𝗳𝗼𝗿𝗲 𝘁𝘂𝗻𝗶𝗻𝗴 𝗮𝗻𝘆𝘁𝗵𝗶𝗻𝗴: 
→ Wide spread (closer to 0.15): start with TokenANN or MUVERA 
→ Tight spread (closer to 0.05): start with LEMUR
𝗧𝗵𝗲 𝗺𝗼𝗱𝗲𝗹 𝗶𝘀 𝗼𝗻𝗹𝘆 𝗵𝗮𝗹𝗳 𝘁𝗵𝗲 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻. 𝗣𝗮𝗶𝗿 𝗶𝘁 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝘄𝗿𝗼𝗻𝗴 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆, 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗯𝗲𝘀𝘁 𝗺𝗼𝗱𝗲𝗹 𝗰𝗮𝗻'𝘁 𝗺𝗮𝗸𝗲 𝘂𝗽 𝘁𝗵𝗲 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲.

💬0🔄0❤️3👀189📊1

⚡ Powered by xgo.ing

𝗧𝗵𝗲𝗿𝗲 𝗮𝗿𝗲 𝘁𝗵𝗿𝗲𝗲 𝗰𝗼𝗺𝗺𝗼𝗻 𝘄𝗮𝘆𝘀 𝘁𝗼 𝗰𝗵𝘂𝗻𝗸 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝘀 𝗳𝗼𝗿 𝗥𝗔𝗚....

Milvus (@milvusio) — Wed, 03 Jun 2026 15:35:00 GMT

𝗧𝗵𝗲𝗿𝗲 𝗮𝗿𝗲 𝘁𝗵𝗿𝗲𝗲 𝗰𝗼𝗺𝗺𝗼𝗻 𝘄𝗮𝘆𝘀 𝘁𝗼 𝗰𝗵𝘂𝗻𝗸 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝘀 𝗳𝗼𝗿 𝗥𝗔𝗚. 𝗪𝗵𝗶𝗰𝗵 𝗼𝗻𝗲 𝘄𝗼𝗿𝗸𝘀 𝗱𝗲𝗽𝗲𝗻𝗱𝘀 𝗼𝗻 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂𝗿 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝘀 𝗹𝗼𝗼𝗸 𝗹𝗶𝗸𝗲.

𝗙𝗶𝘅𝗲𝗱-𝗹𝗲𝗻𝗴𝘁𝗵 𝗰𝗵𝘂𝗻𝗸𝗶𝗻𝗴 (𝟱𝟭𝟮 𝗼𝗿 𝟭𝟬𝟮𝟰 𝘁𝗼𝗸𝗲𝗻𝘀 𝗽𝗲𝗿 𝗰𝗵𝘂𝗻𝗸) 𝗶𝘀 𝘁𝗵𝗲 𝗲𝗮𝘀𝗶𝗲𝘀𝘁 𝘁𝗼 𝘀𝗲𝘁 𝘂𝗽, 𝗯𝘂𝘁 𝗶𝘁 𝗰𝗮𝗻 𝘀𝗽𝗹𝗶𝘁 𝗮 𝗰𝗼𝗺𝗽𝗹𝗲𝘁𝗲 𝗮𝗻𝘀𝘄𝗲𝗿 𝗶𝗻 𝗵𝗮𝗹𝗳. Say the steps for configuring Nginx timeouts take 600 tokens. A 512-token chunk cuts right through the middle, and retrieval may only return one side of it. The user gets an incomplete answer, even though the source document had the full information..

𝗦𝗹𝗶𝗱𝗶𝗻𝗴-𝘄𝗶𝗻𝗱𝗼𝘄 𝗰𝗵𝘂𝗻𝗸𝗶𝗻𝗴 (𝟱𝟬–𝟭𝟬𝟬 𝘁𝗼𝗸𝗲𝗻𝘀 𝗼𝗳 𝗼𝘃𝗲𝗿𝗹𝗮𝗽) 𝘀𝘁𝗼𝗽𝘀 𝗮𝗻𝘀𝘄𝗲𝗿𝘀 𝗳𝗿𝗼𝗺 𝗴𝗲𝘁𝘁𝗶𝗻𝗴 𝗰𝘂𝘁 𝗺𝗶𝗱-𝘀𝗲𝗻𝘁𝗲𝗻𝗰𝗲, 𝗯𝘂𝘁 𝗶𝘁 𝗰𝗿𝗲𝗮𝘁𝗲𝘀 𝗱𝘂𝗽𝗹𝗶𝗰𝗮𝘁𝗲𝘀. The same passage shows up in three overlapping chunks, all three score high, and they fill your top results — leaving no room for other relevant content.

𝗦𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝗰𝗵𝘂𝗻𝗸𝗶𝗻𝗴 (𝘀𝗽𝗹𝗶𝘁𝘁𝗶𝗻𝗴 𝗯𝘆 𝗽𝗮𝗿𝗮𝗴𝗿𝗮𝗽𝗵, 𝗵𝗲𝗮𝗱𝗶𝗻𝗴, 𝗼𝗿 𝘀𝗲𝗰𝘁𝗶𝗼𝗻) 𝗸𝗲𝗲𝗽𝘀 𝗺𝗲𝗮𝗻𝗶𝗻𝗴 𝗶𝗻𝘁𝗮𝗰𝘁, 𝗯𝘂𝘁 𝗶𝘁 𝗼𝗻𝗹𝘆 𝘄𝗼𝗿𝗸𝘀 𝘄𝗵𝗲𝗻 𝘁𝗵𝗲 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁 𝗵𝗮𝘀 𝗰𝗹𝗲𝗮𝗻 𝗳𝗼𝗿𝗺𝗮𝘁𝘁𝗶𝗻𝗴. Internal wikis, chat logs, and ticket systems usually don't, so there's nothing for semantic chunking to split on.

𝗪𝗵𝗮𝘁'𝘀 𝘄𝗼𝗿𝗸𝗲𝗱 𝗳𝗼𝗿 𝘂𝘀:
• 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗱𝗼𝗰𝘀: semantic chunking, with sliding-window as a fallback
• 𝗖𝗵𝗮𝘁 𝗹𝗼𝗴𝘀 𝗮𝗻𝗱 𝘁𝗶𝗰𝗸𝗲𝘁𝘀: fixed-length, with a larger overlap
• 𝗔𝗣𝗜 𝗱𝗼𝗰𝘀 𝗮𝗻𝗱 𝗰𝗼𝗻𝗳𝗶𝗴 𝗿eferences: split by section

Sort your documents by type first. The right chunking method follows from there.

💬0🔄0❤️1👀178📊1

⚡ Powered by xgo.ing

Your RAG tested well and went live, but recall is getting worse. 𝗧𝗵𝗿𝗲𝗲 𝗰𝗼𝗺𝗺𝗼𝗻 ...

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

Your RAG tested well and went live, but recall is getting worse. 
𝗧𝗵𝗿𝗲𝗲 𝗰𝗼𝗺𝗺𝗼𝗻 𝗰𝗮𝘂𝘀𝗲𝘀:

• 𝗧𝗵𝗲 𝗶𝗻𝗱𝗲𝘅 𝗶𝘀 𝘀𝘁𝗮𝗹𝗲. New docs get added, old ones get edited or deleted, but the vector index is still the one you built three months ago. Retrieval is searching an outdated snapshot.

• 𝗧𝗵𝗲 𝗲𝗺𝗯𝗲𝗱𝗱𝗶𝗻𝗴 𝗺𝗼𝗱𝗲𝗹 𝗰𝗵𝗮𝗻𝗴𝗲𝗱. Providers like OpenAI update their embedding models without much warning. Your existing documents were embedded with the old version, new queries use the new one, and the vectors no longer line up the way they used to.

• 𝗨𝘀𝗲𝗿𝘀 𝘀𝘁𝗮𝗿𝘁𝗲𝗱 𝗮𝘀𝗸𝗶𝗻𝗴 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁𝗹𝘆. Your user base grew, the product changed, and the way people phrase questions shifted with it. The queries your system handles today aren't the same ones it was tested on.

𝗧𝗵𝗲𝗿𝗲'𝘀 𝗮𝗹𝘀𝗼 𝗮 𝗳𝗼𝘂𝗿𝘁𝗵 𝗿𝗲𝗮𝘀𝗼𝗻 𝗿𝗲𝗰𝗮𝗹𝗹 𝗹𝗼𝗼𝗸𝘀 𝘄𝗼𝗿𝘀𝗲. Your test set drifted from reality, or it never covered certain query types to begin with. That doesn't cause recall to drop — it just means you can't see where it already has.

💬0🔄0❤️1👀212📊1

⚡ Powered by xgo.ing

Vector search works well when semantic meaning matters, but it can be unreliable with exact terms. S...

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

Vector search works well when semantic meaning matters, but it can be unreliable with exact terms. Search for "XR-2048" using vector search alone, and you may get specs for a similar product, but not the exact model you asked for.

BM25 is better at the thing vector search often misses: exact terms. Search for “refund policy” when the document says “return process,” though, and BM25 may miss it. 

𝗧𝗵𝗮𝘁'𝘀 𝘄𝗵𝘆 𝗵𝘆𝗯𝗿𝗶𝗱 𝘀𝗲𝗮𝗿𝗰𝗵 𝗲𝘅𝗶𝘀𝘁𝘀. 𝗩𝗲𝗰𝘁𝗼𝗿 𝘀𝗲𝗮𝗿𝗰𝗵 𝗰𝗼𝘃𝗲𝗿𝘀 𝘀𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝗺𝗮𝘁𝗰𝗵𝗲𝘀, 𝗕𝗠𝟮𝟱 𝗰𝗮𝘁𝗰𝗵𝗲𝘀 𝗲𝘅𝗮𝗰𝘁 𝘁𝗲𝗿𝗺𝘀, 𝗮𝗻𝗱 𝗥𝗥𝗙 (𝗥𝗲𝗰𝗶𝗽𝗿𝗼𝗰𝗮𝗹 𝗥𝗮𝗻𝗸 𝗙𝘂𝘀𝗶𝗼𝗻) 𝗺𝗲𝗿𝗴𝗲𝘀 𝗯𝗼𝘁𝗵 𝗶𝗻𝘁𝗼 𝗼𝗻𝗲 𝗿𝗮𝗻𝗸𝗲𝗱 𝗹𝗶𝘀𝘁.

𝗜𝗻 𝗠𝗶𝗹𝘃𝘂𝘀, 𝘆𝗼𝘂 𝗰𝗮𝗻 𝘀𝗲𝘁 𝘁𝗵𝗶𝘀 𝘂𝗽 𝗶𝗻 𝘁𝗵𝗿𝗲𝗲 𝘀𝘁𝗲𝗽𝘀:
1️⃣ Add both dense and sparse vector fields to the same collection 
2️⃣ Enable the built-in BM25 Function so Milvus can generate sparse vectors from raw text 
3️⃣ Use RRFRanker to fuse the vector and BM25 results

⚠️ 𝗢𝗻𝗲 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝗻𝗼𝘁𝗲: 𝗜𝗳 𝘆𝗼𝘂 𝘂𝘀𝗲 𝘁𝗵𝗲 𝗯𝘂𝗶𝗹𝘁-𝗶𝗻 𝗕𝗠𝟮𝟱 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻, 𝗱𝗼 𝗻𝗼𝘁 𝗺𝗮𝗻𝘂𝗮𝗹𝗹𝘆 𝗶𝗻𝘀𝗲𝗿𝘁 𝘀𝗽𝗮𝗿𝘀𝗲 𝘃𝗲𝗰𝘁𝗼𝗿𝘀. Milvus generates them for you. You only provide your own sparse vectors when using an external sparse embedding model, such as BGE-M3.

𝗜𝗳 𝘆𝗼𝘂𝗿 𝗾𝘂𝗲𝗿𝗶𝗲𝘀 𝗶𝗻𝗰𝗹𝘂𝗱𝗲 𝗽𝗿𝗼𝗱𝘂𝗰𝘁 𝗻𝗮𝗺𝗲𝘀, 𝗲𝗿𝗿𝗼𝗿 𝗰𝗼𝗱𝗲𝘀, 𝗔𝗣𝗜 𝗲𝗻𝗱𝗽𝗼𝗶𝗻𝘁𝘀, 𝗼𝗿 𝗼𝘁𝗵𝗲𝗿 𝗲𝘅𝗮𝗰𝘁 𝗶𝗱𝗲𝗻𝘁𝗶𝗳𝗶𝗲𝗿𝘀, 𝘃𝗲𝗰𝘁𝗼𝗿 𝘀𝗲𝗮𝗿𝗰𝗵 𝗮𝗹𝗼𝗻𝗲 𝗶𝘀 𝗽𝗿𝗼𝗯𝗮𝗯𝗹𝘆 𝗻𝗼𝘁 𝗲𝗻𝗼𝘂𝗴𝗵. 𝗧𝗿𝘆 𝗵𝘆𝗯𝗿𝗶𝗱 𝘀𝗲𝗮𝗿𝗰𝗵.

💬0🔄0❤️7👀202📊2

⚡ Powered by xgo.ing

🌐 𝗪𝗲𝗯𝗶𝗻𝗮𝗿 | 𝗪𝗵𝗮𝘁’𝘀 𝗡𝗲𝘄 𝗶𝗻 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬: 𝗟𝗶𝘃𝗲 𝗪𝗮𝗹𝗸𝘁𝗵𝗿𝗼𝘂𝗴𝗵 & ...

Milvus (@milvusio) — Sat, 30 May 2026 15:12:57 GMT

🌐 𝗪𝗲𝗯𝗶𝗻𝗮𝗿 | 𝗪𝗵𝗮𝘁’𝘀 𝗡𝗲𝘄 𝗶𝗻 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬: 𝗟𝗶𝘃𝗲 𝗪𝗮𝗹𝗸𝘁𝗵𝗿𝗼𝘂𝗴𝗵 & 𝗔𝗠𝗔, 𝗝𝘂𝗻𝗲 𝟴 𝗼𝗻𝗹𝗶𝗻𝗲

Milvus 3.0 beta is the biggest architectural upgrade since the project began. It brings native support for indexing and querying vectors directly on your data lake, along with a query engine that goes beyond top-K search.

In this live session, core maintainers Li Liu and Jiang Chen will walk through what shipped, the design choices behind it, and how Milvus 3.0 powers 𝗭𝗶𝗹𝗹𝗶𝘇 𝗩𝗲𝗰𝘁𝗼𝗿 𝗟𝗮𝗸𝗲𝗯𝗮𝘀𝗲.

🎤 𝗧𝗼𝗽𝗶𝗰𝘀
• What changed in Milvus 3.0 beta
• Why data lake-native vector search matters
• What’s in beta now and what’s coming in GA
• How Milvus 3.0 powers Zilliz Vector Lakebase
• 15–20zilliz.com/event/whats-ne… maintainers

📅 𝗝𝘂𝗻𝗲 𝟴, 𝟮𝟬𝟮𝟲, 𝟰:𝟬𝟬 𝗽𝗺 𝗣𝗗𝗧
🔗 Register here: https://t.co/ccpclyAQa8

Bring your questions about migration, performance, arc#Milvusr#VectorDatabasee#Zilliz’d like to ask the maintainers. Looking forward to the conversation! 
#Milvus#VectorDatabase#Zilliz

💬0🔄1❤️4👀665📊2

⚡ Powered by xgo.ing

𝗖𝗹𝗮𝘂𝗱𝗲 𝗢𝗽𝘂𝘀 𝟰.𝟴 brings longer independent work, sharper judgment, and stronger self-chec...

Milvus (@milvusio) — Fri, 29 May 2026 17:31:00 GMT

𝗖𝗹𝗮𝘂𝗱𝗲 𝗢𝗽𝘂𝘀 𝟰.𝟴 brings longer independent work, sharper judgment, and stronger self-checking to coding agents.

Coding agents are no longer just generating snippets. They are planning changes, calling tools, editing files, checking outputs, and staying inside the same workflow for longer.

𝗧𝗵𝗮𝘁 𝗰𝗵𝗮𝗻𝗴𝗲𝘀 𝘁𝗵𝗲 𝗿𝗼𝗹𝗲 𝗼𝗳 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹.

When a chatbot retrieves the wrong context, it may give the wrong answer. When an agent retrieves the wrong context, the mistake can shape what it does next: the plan it follows, the tool it calls, the code it changes, and the memory it carries forward.

So retrieval can no longer stop at “find a few similar chunks.” Agents need context that is relevant, fresh, scoped, and traceable enough to support action.

That is where a vector database like Milvus matters. It gives agents a retrieval layer built for hybrid search, metadata filtering, and reliable access to production context.

Stronger agents don’t reduce the need for retrieval quality. They make retrieval quality more visible.

💬0🔄0❤️2👀122

⚡ Powered by xgo.ing

When RAG gives a wrong answer, the team's first move is usually a bigger model or more prompt tweaki...

Milvus (@milvusio) — Thu, 28 May 2026 15:00:02 GMT

When RAG gives a wrong answer, the team's first move is usually a bigger model or more prompt tweaking. 𝗕𝘂𝘁 𝘁𝗵𝗲 𝗳𝗶𝗿𝘀𝘁 𝘁𝗵𝗶𝗻𝗴 𝘁𝗼 𝗳𝗶𝘅 𝗶𝘀 𝘂𝘀𝘂𝗮𝗹𝗹𝘆 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹.

𝗛𝗲𝗿𝗲'𝘀 𝗮 𝘁𝗵𝗿𝗲𝗲-𝘀𝘁𝗲𝗽 𝘄𝗮𝘆 𝘁𝗼 𝗺𝗲𝗮𝘀𝘂𝗿𝗲 𝘄𝗵𝗲𝗿𝗲 𝗶𝘁'𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗯𝗿𝗲𝗮𝗸𝗶𝗻𝗴:

1️⃣ 𝗕𝘂𝗶𝗹𝗱 𝗮 𝘀𝗲𝘁 𝗼𝗳 𝗴𝗼𝗹𝗱𝗲𝗻 𝗾𝘂𝗲𝗿𝗶𝗲𝘀, 𝗯𝘂𝗰𝗸𝗲𝘁𝗲𝗱 𝗯𝘆 𝗾𝘂𝗲𝗿𝘆 𝘁𝘆𝗽𝗲.
5–10 per bucket: exact terms (model numbers, API names, error codes), multi-hop, long-tail, and unanswerable.

2️⃣ 𝗥𝘂𝗻 𝘁𝗵𝗲𝗺 𝗮𝗻𝗱 𝗰𝗵𝗲𝗰𝗸 𝗥𝗲𝗰𝗮𝗹𝗹@𝗸 𝗽𝗲𝗿 𝗯𝘂𝗰𝗸𝗲𝘁.
Don't look at the overall average. It hides the weak bucket.

3️⃣ 𝗧𝗵𝗲 𝘄𝗲𝗮𝗸 𝗯𝘂𝗰𝗸𝗲𝘁 𝘂𝘀𝘂𝗮𝗹𝗹𝘆 𝘁𝗲𝗹𝗹𝘀 𝘆𝗼𝘂 𝘄𝗵𝗲𝗿𝗲 𝘁𝗼 𝗹𝗼𝗼𝗸 𝗳𝗶𝗿𝘀𝘁:
📦 𝗘𝘅𝗮𝗰𝘁-𝘁𝗲𝗿𝗺 𝗯𝘂𝗰𝗸𝗲𝘁 𝗹𝗼𝘄 → dense retrieval's blind spot for exact strings. Model numbers and error codes often do not land near the right context in embedding space → add hybrid search (dense + BM25).

🔗 𝗠𝘂𝗹𝘁𝗶-𝗵𝗼𝗽 𝗹𝗼𝘄 → the answer got split across chunks, or your candidate set is too small → check your chunking and how many results you pull back

🌊 𝗟𝗼𝗻𝗴-𝘁𝗮𝗶𝗹 𝗹𝗼𝘄 → users' wording doesn't match the docs' terminology → add query rewriting, or add the terminology users actually search for to the docs.

📉 𝗘𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴 𝗹𝗼𝘄 → your embedding model doesn't fit your domain → swap it or fine-tune.

𝗧𝗵𝗮𝘁'𝘀 𝘁𝗵𝗲 𝘃𝗮𝗹𝘂𝗲 𝗼𝗳 𝗱𝗶𝗮𝗴𝗻𝗼𝘀𝗶𝗻𝗴 𝗯𝘆 𝗯𝘂𝗰𝗸𝗲𝘁: 𝗻𝗼𝘁 "𝗿𝗲𝗰𝗮𝗹𝗹 𝗶𝘀 𝗯𝗮𝗱," 𝗯𝘂𝘁 𝘄𝗵𝗶𝗰𝗵 𝗾𝘂𝗲𝗿𝗶𝗲𝘀 𝗳𝗮𝗶𝗹, 𝘄𝗵𝘆, 𝗮𝗻𝗱 𝘄𝗵𝗮𝘁 𝘁𝗼 𝗳𝗶𝘅.

💬0🔄0❤️1👀112📊1

⚡ Powered by xgo.ing

𝗜𝗻 𝗮 𝗹𝗼𝗻𝗴-𝗿𝘂𝗻𝗻𝗶𝗻𝗴 𝗥𝗔𝗚 𝘀𝘆𝘀𝘁𝗲𝗺, 𝘁𝗵𝗲 𝗺𝗼𝘀𝘁 𝗱𝗮𝗻𝗴𝗲𝗿𝗼𝘂𝘀 𝗯𝘂𝗴 ...

Milvus (@milvusio) — Wed, 27 May 2026 15:00:02 GMT

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

It's easy to miss: the model generates from a bad retrieval → no one corrects it, so the system assumes it's right → it gets written back to memory → the next query pulls it up again and reinforces the error.

𝗖𝗥𝗔𝗚 (𝗖𝗼𝗿𝗿𝗲𝗰𝘁𝗶𝘃𝗲 𝗥𝗔𝗚) 𝗯𝗿𝗲𝗮𝗸𝘀 𝘁𝗵𝗶𝘀 𝗹𝗼𝗼𝗽. It adds one step between retrieval and generation: evaluation. A lightweight evaluator judges whether each retrieved document actually answers the question and tags it with a confidence score, stored alongside the memory.

The evaluator sorts results into three tiers:

• 0.9 → correct: refine and use
• 0.5–0.9 → ambiguous: add a web search
• <0.5 → wrong: discard and search instead

On the next retrieval, the system pre-filters first, keeping only entries above 0.7. Weak content gets screened out before it's reused, so it never re-enters the store → retrieve → reinforce loop.

CRAG needs a vector database that can store confidence scores dynamically, run hybrid rmilvus.io/blog/fix-rag-r…en#RAG.#VectorDatabase�#Milvus�#LLM�#AIEngineering�𝘁𝗮𝗱𝗮𝘁𝗮 𝗳𝗶𝗹𝘁𝗲𝗿𝗶𝗻𝗴, 𝗵𝘆𝗯𝗿𝗶𝗱 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹, 𝗮𝗻𝗱 𝗣𝗮𝗿𝘁𝗶𝘁𝗶𝗼𝗻 𝗞𝗲𝘆 𝗼𝘂𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗯𝗼𝘅, 𝘄𝗵𝗶𝗰𝗵 𝗶𝘀 𝗲𝘅𝗮𝗰𝘁𝗹𝘆 𝘄𝗵𝗮𝘁 𝗖𝗥𝗔𝗚 𝗻𝗲𝗲𝗱𝘀.

𝗟𝗲𝗮𝗿𝗻 𝗵𝗼𝘄 𝘁𝗼 𝘀𝗲𝘁 𝘂𝗽 𝗖𝗥𝗔𝗚: https://t.co/iebI7W1lc6#RAG#VectorDatabase#Milvus#LLM#AIEngineering

💬0🔄0❤️1👀137📊1

⚡ Powered by xgo.ing

𝗖𝗥𝗔𝗚 𝗰𝗮𝗻 𝗺𝗮𝗸𝗲 𝘆𝗼𝘂𝗿 𝗥𝗔𝗚 𝘀𝘂𝗿𝗳𝗮𝗰𝗲 𝘁𝗵𝗲 𝗮𝗻𝘀𝘄𝗲𝗿 𝘆𝗼𝘂 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 ...

Milvus (@milvusio) — Tue, 26 May 2026 15:22:00 GMT

𝗖𝗥𝗔𝗚 𝗰𝗮𝗻 𝗺𝗮𝗸𝗲 𝘆𝗼𝘂𝗿 𝗥𝗔𝗚 𝘀𝘂𝗿𝗳𝗮𝗰𝗲 𝘁𝗵𝗲 𝗮𝗻𝘀𝘄𝗲𝗿 𝘆𝗼𝘂 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗻𝗲𝗲𝗱 — 𝘁𝗵𝗲 𝗰𝘂𝗿𝗿𝗲𝗻𝘁 𝗼𝗻𝗲, 𝗻𝗼𝘁 𝗷𝘂𝘀𝘁 𝘁𝗵𝗲 𝗰𝗹𝗼𝘀𝗲𝘀𝘁 𝗺𝗮𝘁𝗰𝗵 𝗶𝗻 𝗺𝗲𝗮𝗻𝗶𝗻𝗴.
  𝗕𝘆 𝗱𝗲𝗳𝗮𝘂𝗹𝘁, 𝘆𝗼𝘂𝗿 𝗥𝗔𝗚 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲 𝗽𝗿𝗼𝗯𝗮𝗯𝗹𝘆 𝗱𝗼𝗲𝘀𝗻'𝘁 𝗸𝗻𝗼𝘄 𝘄𝗵𝗮𝘁 𝘆𝗲𝗮𝗿 𝗶𝘁 𝗶𝘀: 𝗶𝘁 𝗰𝗮𝗻'𝘁 𝘁𝗲𝗹𝗹 𝗮 𝟮𝟬𝟭𝟵 𝗮𝗻𝘀𝘄𝗲𝗿 𝗳𝗿𝗼𝗺 𝗮 𝟮𝟬𝟮𝟰 𝗼𝗻𝗲. Vector search ranks by meaning, not time, and two documents from different years can read as almost the same. Search "Python async best practices," for example, and the outdated docs come back alongside the current ones.

  𝗬𝗼𝘂 𝗰𝗮𝗻'𝘁 𝗿𝗲𝗹𝗶𝗮𝗯𝗹𝘆 𝗳𝗶𝘅 𝗶𝘁 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝗾𝘂𝗲𝗿𝘆 𝘀𝗶𝗱𝗲 𝗲𝗶𝘁𝗵𝗲𝗿. Embedding models have a weak sense of time, so dropping "2024" into the query nudges the ranking but doesn't actually sort by recency.

  𝗖𝗥𝗔𝗚 (𝗖𝗼𝗿𝗿𝗲𝗰𝘁𝗶𝘃𝗲 𝗥𝗔𝗚) 𝗶𝘀 𝘄𝗵𝗮𝘁 𝗳𝗶𝗹𝗹𝘀 𝘁𝗵𝗮𝘁 𝗴𝗮𝗽.
  𝗧𝗵𝗲 𝗸𝗲𝘆 𝗶𝘀 𝘁𝗵𝗲 𝗲𝘃𝗮𝗹𝘂𝗮𝘁𝗲 𝘀𝘁𝗲𝗽 𝗶𝘁 𝗮𝗱𝗱𝘀. Between retrieval and generation sits an evaluator — a lightweight model that scores how well each retrieved document matches the query, and doesn't write any answers itself.

  𝗪𝗵𝗲𝗻 𝗮 𝗿𝗲𝘀𝘂𝗹𝘁 𝗰𝗼𝗺𝗲𝘀 𝗯𝗮𝗰𝗸 𝗶𝗻𝗰𝗼𝗿𝗿𝗲𝗰𝘁 𝗼𝗿 𝗮𝗺𝗯𝗶𝗴𝘂𝗼𝘂𝘀, 𝗖𝗥𝗔𝗚 𝗴𝗼𝗲𝘀 𝗼𝘂𝘁𝘀𝗶𝗱𝗲 𝘁𝗵𝗲 𝗸𝗻𝗼𝘄𝗹𝗲𝗱𝗴𝗲 𝗯𝗮𝘀𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝘄𝗵𝗮𝘁'𝘀 𝗺𝗶𝘀𝘀𝗶𝗻𝗴: 
  ~ Ambiguous → keep the useful part of what RAG retrieved, refine it, amilvus.io/blog/fix-rag-r… we#RAGa#VectorDatabasee#LLMOpsr#AIEngineeringr#Milvusesults and go straight to web search, so time-sensitive queries still come back right

  Across this whole flow, CRAG needs what production systems demand — multi-tenant isolation, hybrid retrieval, and schema flexibility. 𝗠𝗶𝗹𝘃𝘂𝘀 𝗶𝘀 𝗯𝘂𝗶𝗹𝘁 𝘁𝗼 𝗱𝗲𝗹𝗶𝘃𝗲𝗿 𝗲𝘅𝗮𝗰𝘁𝗹𝘆 𝘁𝗵𝗮𝘁.

  𝗟𝗲𝗮𝗿𝗻 𝗵𝗼𝘄 𝘁𝗼 𝘀𝗲𝘁 𝘂𝗽 𝗖𝗥𝗔𝗚 𝗵𝗲𝗿𝗲: https://t.co/wWetTlzu3K
  #RAG#VectorDatabase#LLMOps#AIEngineering#Milvus

💬0🔄0❤️1👀151📊1