Qdrant Vector Storage
RAG.Core/Services/QdrantVectorStore.cs owns Qdrant interaction.
Each vector carries citation payload
new Dictionary<string, object?>
{
["documentId"] = chunk.Chunk.DocumentId.ToString(),
["fileName"] = chunk.Chunk.FileName,
["chunkIndex"] = chunk.Chunk.ChunkIndex,
["text"] = chunk.Chunk.Text,
["chunkType"] = chunk.Chunk.ChunkType
}RAG.Core/Services/QdrantVectorStore.cs owns Qdrant interaction.
Each point stores:
- vector;
documentId;fileName;chunkIndex;pageNumber;sourceObjectKey;text;chunkType;title;- generated-artifact provenance fields such as
isGeneratedArtifact,artifactKind, provider, model, prompt version, generation time, and source chunk/page indexes.
The vector search endpoint returns matching chunks and payloads. Payloads become citations, diagnostics, and LLM context. Preserving provenance in Qdrant means a generated book-club profile can survive the round trip from ingestion to retrieval to citation rendering without being confused with source text.
The store also supports two non-vector retrieval helpers:
GetDocumentProfileChunksAsyncGetChunksContainingTextAsync
These exist because vector search is not always enough. If a user asks a comparison question with named characters, exact-name lookup can ensure each named subject contributes evidence.
That is how the project handles questions like:
Can you find any similarities between Calpurnia and Hermione?Pure top-k semantic retrieval may over-focus on one book. The improved retrieval path combines semantic search, profile chunks, and exact-name chunks.
The vector store also has a document-level delete operation. Reindexing and deletion both call DeleteDocumentAsync so old vector points do not remain after derived data changes or a user removes a document.