Milvus keeps recent writes in growing segments for fast access, then moves them into sealed segments with indexes and persistent storage.
2
Stable identifiers, metadata, and deliberate chunking let a RAG system find records again when documents or embeddings need updates.
3
Jina CLIP adds text-to-text contrastive training to CLIP's image-text training so one model can support multimodal and text-only retrieval.
Summary
Stephen Batifol explains why updating a RAG system needs more planning than inserting documents once. In Milvus, stable identifiers let an upsert replace an existing entity or insert a new one. Growing segments hold recent changes in memory, while sealed segments are written to object storage and indexed for later search. He recommends choosing identifiers that remain tied to the underlying document or chunk, and using metadata or composite identifiers when updates target groups of records. Saba Sturua and Andreas Koukounas then explain Jina CLIP. Standard CLIP trains image and text encoders on paired examples, but its text encoder can perform poorly on text-only retrieval because it sees short captions and is optimized against images. Jina CLIP adds text-to-text contrastive training, longer captions, and supervised hard negatives across multiple training stages. Their demo indexes text and image documents in one vector space and retrieves either modality with a text query.
RAG systems need an update plan before documents change
Stephen Batifol says RAG demonstrations usually focus on inserting data and querying it, while leaving updates unexplained. A basic pipeline extracts content from PDFs, images, or other sources, chunks it, embeds the chunks, stores them in Milvus, and retrieves the nearest results for a user query. When the source changes, the system must identify the affected records and replace them. Vector databases also handle indexing, persistence, filtering, backup, and scaling, which can become difficult when those tasks are built around a simple vector plugin.
Milvus separates storage and compute so workloads can scale independently
Milvus separates storage from compute and uses object storage such as MinIO or S3 so data does not have to remain in memory. Its query, data, and index nodes have different jobs. Query nodes serve search requests, data nodes process mutations and snapshots, and index nodes build search indexes. These services can be scaled independently. For example, a workload receiving a large amount of incoming data can add data-node capacity without also scaling query nodes that are not serving more traffic.
Growing and sealed segments balance fresh reads with indexed historical data
Milvus uses growing segments as in-memory containers for new information. Updates enter these segments and can be accessed quickly, which helps searches see recent data. When a growing segment reaches the point where it should be persisted, Milvus turns it into a sealed segment. Sealed segments are immutable, stored on disk or object storage, and indexed for faster search. The result is a division between fresh mutable data and older indexed data.
Stable identifiers determine whether an update can find its target
Stephen recommends avoiding auto-incrementing or opaque generated IDs when records must be updated later. The application should assign a stable unique identifier to each document, image, vector, or chunk. Metadata such as author, type, or creation date can support filtered updates, while composite identifiers can combine fields such as a user and timestamp. Hierarchical IDs such as project, chapter, and section can target a specific part of a complex dataset, including when only one section needs a new embedding.
Milvus upsert uses the supplied identifier to insert or replace an entity
An upsert sends an identifier, vector, and other fields for a collection. Milvus checks whether that identifier already exists. If it does not, the entity is inserted. If it does, the existing entity is updated. The same operation can be scoped to a partition. Behind the API, the request passes through the proxy and data coordinator, enters a growing segment, and is later flushed, persisted, and indexed as the segment becomes sealed.
CLIP's image-text training can leave its text encoder weak for text-only retrieval
Saba Sturua describes CLIP as two encoders trained on paired images and text. Contrastive learning increases similarity for matching pairs and decreases similarity for mismatched pairs. She says earlier CLIP models often initialized the text tower with limited language capability, trained it against images rather than other text, and used short captions with small context lengths. Those choices make text-only retrieval weaker. A production system may therefore need one vector for image-text retrieval and another from a text-only embedding model.
Jina CLIP jointly trains on image-text pairs and text pairs
Jina CLIP adds a text-to-text objective alongside the usual image-text contrastive objective. Its training has multiple stages. The first uses image-text pairs and text pairs, the second adds image-text examples with longer captions, and the third uses supervised triplets with hard negatives to improve text retrieval. Andreas Koukounas explains that the model starts from a text backbone with long-context support and an image encoder, then combines the losses from the multimodal and text-only tasks.
One shared embedding space can hold text and images for retrieval
Saba's demo loads Jina CLIP from Hugging Face and creates an in-memory document index with DocArray. Each document has a modality, an embedding, and either text or an image URL. Text is encoded with encode_text and images with encode_image. A text query such as a Buddha frog statue can retrieve a related text document or, after filtering on the image modality, the matching frog image. The same pattern can be connected to another vector store for larger collections.
"What we wanted to achieve with this model was mainly to have one common model for multimodal retrieval and text-to-text retrieval."Andreas Koukounas39:17
Who should watch
You are building a RAG system whose source documents change and need to be replaced without losing track of chunks or embeddings.
You are deciding whether a vector database should handle updates, indexing, persistence, and scaling instead of assembling those pieces yourself.
You want one embedding model for image-text search and text-only retrieval, and need to understand why standard CLIP may require a separate text model.
