Why might you keep conversation-turn embeddings in a separate, short-lived collection rather than mixing them into your main document knowledge base?

Conversation-turn embeddings and document knowledge base embeddings have fundamentally different characteristics, and mixing them in one collection creates problems in all three dimensions: lifecycle, relevance, and access. Lifecycle: document knowledge is long-lived and changes slowly, while conversation turns are ephemeral and should expire after hours or days. A single collection can only have one retention policy, so mixing them means either keeping conversations forever (wasting storage and potentially violating privacy) or expiring documents prematurely. Relevance: conversations are about what was just said, while documents are about what is known. A query that looks for context in a conversation should not compete with document chunks in the same vector space, because the two have different distributions and different retrieval intents. Access: conversation turns are typically accessible only to the participants, while documents may be broadly accessible. A single collection means the permission model has to handle both, which complicates the filter. Separate collections let you apply different retention, different indexing parameters, and different access controls to each.

The mechanism that makes separation beneficial is that a collection is the unit of configuration in Qdrant: the vector size, the distance metric, the HNSW parameters, the quantization, the replication factor, the shard count, and the optimizer thresholds all apply per collection. If documents and conversations need different configurations - for example, documents need high recall and conversations need low latency, or conversations need a shorter retention - they cannot share a collection without compromising on one or the other. Separating them also makes it possible to drop or snapshot the conversation collection independently, which is important for privacy and for cost control. And it makes the permission model simpler: the conversation collection can be scoped per user or per session, while the document collection has its own broader access rules. The retrieval pipeline can query both and merge the results, weighting them differently, without the two interfering in the index.