Les pipelines RAG souffrent depuis longtemps d'une inefficacité fondamentale : les données brutes vivent dans un data lake, mais les vecteurs doivent être copiés dans un stockage séparé. Chaque mise à jour des données sources déclenche un cycle de ré-embedding et de re-synchronisation, créant une surcharge opérationnelle et une obsolescence potentielle. L'architecture zero-copy de Milvus 3.0 change cela en permettant à la recherche vectorielle de lire directement les fichiers Parquet dans S3 ou autre stockage de data lake. Cela signifie que l'index vectoriel devient une couche légère sur les données existantes, pas une seconde copie. Les avantages immédiats sont des coûts de stockage réduits, une gouvernance des données simplifiée et des résultats de recherche plus frais. Pour les équipes construisant des systèmes RAG en production, cela réduit le besoin de pipelines ETL complexes et ouvre la possibilité d'interroger de grands ensembles de données auparavant trop coûteux à dupliquer. Le compromis est une latence de requête potentiellement accrue, car les vecteurs doivent être récupérés depuis le stockage objet, ce qui est acceptable pour de nombreuses charges de travail. Ce modèle s'aligne avec la tendance plus large de l'industrie vers la séparation du calcul et du stockage, traitant la recherche vectorielle comme un service sur le data lake.
Milvus 3.0 lit les vecteurs directement depuis les data lakes, éliminant le stockage dupliqué et les jobs de synchronisation dans les pipelines RAG.