Principle:FlowiseAI Flowise Vector Store Query

Attribute	Value
Sources	packages/ui/src/api/documentstore.js
Domains	Document_Store_Ingestion
Last Updated	2026-02-12 14:00 GMT

Overview

Vector_Store_Query is a technique for testing document retrieval by querying a vector store with natural language and analyzing the relevance of returned results. This validation step completes the document ingestion pipeline by confirming that the indexed documents are retrievable with expected queries.

Description

After upserting documents, users test retrieval quality by sending natural language queries to the vector store. The query is embedded and used for similarity search against stored vectors. Results include matching document chunks with their content, metadata, and timing metrics.

The query workflow operates as follows:

• Query formulation -- The user enters a natural language question or search phrase that represents a typical query their RAG chatflow would receive.
• Query embedding -- The system embeds the query text using the same embedding model that was used to embed the document chunks, ensuring the query vector exists in the same vector space.
• Similarity search -- The vector store performs nearest-neighbor search to find the most similar chunk vectors to the query vector. The search type (similarity, MMR) and topK parameter control result behavior.
• Result analysis -- The user examines the returned chunks to assess retrieval quality: Are the most relevant chunks returned? Is the ordering correct? Are irrelevant results included?

Key query parameters include:

• topK -- The maximum number of results to return. Typical values range from 3-10 for RAG applications.
• Search type -- similarity returns the K most similar vectors. mmr (Maximal Marginal Relevance) balances relevance with diversity, reducing redundancy in results.
• Filters -- Metadata filters that constrain search to specific subsets of the indexed documents (e.g., by source, date, or category).

Usage

Use vector store query when validating that a document store's vector search returns relevant results for expected queries. Typical scenarios include:

• Post-upsert validation -- Testing retrieval immediately after upserting documents to confirm indexing was successful.
• Retrieval quality assessment -- Running a battery of expected queries to evaluate the overall quality of the embedding and chunking configuration.
• Debugging retrieval issues -- Investigating why a chatflow returns irrelevant or missing context by directly querying the underlying vector store.
• Parameter tuning -- Experimenting with topK, search type, and filters to optimize retrieval for specific query patterns.

// Query the vector store with a natural language question
const result = await documentStoreApi.queryVectorStore({
    storeId: 'store-123',
    query: 'How do I configure authentication?',
    inputs: {
        topK: 5,
        searchType: 'similarity'
    }
})
console.log(`Found ${result.data.docs.length} results in ${result.data.timeTaken}ms`)
result.data.docs.forEach((doc, i) => {
    console.log(`Result ${i + 1}: ${doc.pageContent.substring(0, 100)}...`)
    console.log(`  Source: ${doc.metadata.source}`)
})

Theoretical Basis

Vector store query implements similarity search using dense vector embeddings, the core retrieval mechanism in RAG systems:

• Shared vector space -- The query text is embedded into the same vector space as the document chunks using the identical embedding model. This ensures that semantic similarity between the query and documents can be measured via vector distance. Using a different embedding model for query vs. documents would produce incompatible vector spaces and meaningless similarity scores.
• Nearest-neighbor search -- The vector store performs approximate nearest-neighbor (ANN) search to find chunk vectors closest to the query vector. ANN algorithms (HNSW, IVF, etc.) trade a small amount of accuracy for dramatic speed improvements over brute-force search, enabling millisecond-level retrieval even for millions of vectors.
• Similarity vs. MMR search -- Pure similarity search returns the K closest vectors, which may be highly redundant if multiple chunks cover the same topic. Maximal Marginal Relevance (MMR) addresses this by iteratively selecting results that are both relevant to the query and diverse from already-selected results, providing better coverage of different aspects of the query topic.
• Metadata filtering -- Filters applied before or after vector search narrow results to specific document subsets. Pre-filtering restricts the search space (faster but may miss relevant cross-category results), while post-filtering applies after vector search (complete but may reduce the effective topK).
• Timing metrics -- The returned timeTaken metric enables performance monitoring and helps identify when vector store scaling or optimization is needed.

The query validation step is essential because embedding quality is not directly observable -- only by testing retrieval with representative queries can users assess whether their pipeline configuration (chunking, embedding model, vector store) produces satisfactory results for their use case.

Related Pages

• Implementation:FlowiseAI_Flowise_QueryVectorStore
• Principle:FlowiseAI_Flowise_Vector_Store_Upsert -- Previous step: upserting chunks to enable querying
• Principle:FlowiseAI_Flowise_Vector_Store_Provider_Configuration -- Configuring the providers used for query
• Principle:FlowiseAI_Flowise_Chunk_Management -- Editing chunks to improve retrieval quality