Skip to main content

Retrieval in RAG systems

After storing embeddings, you need to retrieve relevant chunks to answer user queries.

Mastra provides flexible retrieval options with support for semantic search, filtering, and re-ranking.

How retrieval works
Direct link to How retrieval works

  1. The user's query is converted to an embedding using the same model used for document embeddings
  2. This embedding is compared to stored embeddings using vector similarity
  3. The most similar chunks are retrieved and can be optionally:
  • Filtered by metadata
  • Re-ranked for better relevance
  • Processed through a knowledge graph

Basic retrieval
Direct link to Basic retrieval

The simplest approach is direct semantic search. This method uses vector similarity to find chunks that are semantically similar to the query:

import { embed } from 'ai'
import { PgVector } from '@mastra/pg'
import { ModelRouterEmbeddingModel } from '@mastra/core/llm'

// Convert query to embedding
const { embedding } = await embed({
  value: 'What are the main points in the article?',
  model: new ModelRouterEmbeddingModel('openai/text-embedding-3-small'),
})

// Query vector store
const pgVector = new PgVector({
  id: 'pg-vector',
  connectionString: process.env.POSTGRES_CONNECTION_STRING,
})
const results = await pgVector.query({
  indexName: 'embeddings',
  queryVector: embedding,
  topK: 10,
})

// Display results
console.log(results)

The topK parameter specifies the maximum number of most similar results to return from the vector search.

Results include both the text content and a similarity score:

[
  {
    text: 'Climate change poses significant challenges...',
    score: 0.89,
    metadata: { source: 'article1.txt' },
  },
  {
    text: 'Rising temperatures affect crop yields...',
    score: 0.82,
    metadata: { source: 'article1.txt' },
  },
]

Advanced retrieval options
Direct link to Advanced retrieval options

Metadata Filtering
Direct link to Metadata Filtering

Filter results based on metadata fields to narrow down the search space. This approach - combining vector similarity search with metadata filters - is sometimes called hybrid vector search, as it merges semantic search with structured filtering criteria.

This is useful when you have documents from different sources, time periods, or with specific attributes. Mastra provides a unified MongoDB-style query syntax that works across all supported vector stores.

For detailed information about available operators and syntax, see the Metadata Filters Reference.

Basic filtering examples:

import { MongoDBVector } from '@mastra/mongodb'

const mongoVector = new MongoDBVector({
  id: 'mongodb-vector',
  uri: process.env.MONGODB_URI,
  dbName: process.env.MONGODB_DB_NAME,
})

// Simple equality filter
const equalityResults = await mongoVector.query({
  indexName: 'embeddings',
  queryVector: embedding,
  topK: 10,
  filter: {
    source: 'article1.txt',
  },
})

// Numeric comparison
const priceResults = await mongoVector.query({
  indexName: 'embeddings',
  queryVector: embedding,
  topK: 10,
  filter: {
    price: { $gt: 100 },
  },
})

// Multiple conditions
const compoundResults = await mongoVector.query({
  indexName: 'embeddings',
  queryVector: embedding,
  topK: 10,
  filter: {
    category: 'electronics',
    price: { $lt: 1000 },
    inStock: true,
  },
})

// Array operations
const tagResults = await mongoVector.query({
  indexName: 'embeddings',
  queryVector: embedding,
  topK: 10,
  filter: {
    tags: { $in: ['sale', 'new'] },
  },
})

// Logical operators
const categoryResults = await mongoVector.query({
  indexName: 'embeddings',
  queryVector: embedding,
  topK: 10,
  filter: {
    $or: [{ category: 'electronics' }, { category: 'accessories' }],
    $and: [{ price: { $gt: 50 } }, { price: { $lt: 200 } }],
  },
})

Common use cases for metadata filtering:

  • Filter by document source or type
  • Filter by date ranges
  • Filter by specific categories or tags
  • Filter by numerical ranges (e.g., price, rating)
  • Combine multiple conditions for precise querying
  • Filter by document attributes (e.g., language, author)

Where the filter is applied
Direct link to Where the filter is applied

Vector stores differ in when they apply a metadata filter, which affects how filtered queries scale.

MongoDB can evaluate the filter inside the vector index itself. This keeps the query on a single round trip to $vectorSearch, so it avoids the pre-filter pass that collects matching document IDs and the 16 MB BSON limit that pass is subject to. Declaring the fields you filter on in filterFields when you create the index is what enables it:

// Declare the metadata fields you want to filter on
await mongoVector.createIndex({
  indexName: 'embeddings',
  dimension: 1536,
  filterFields: ['source', 'price', 'category', 'inStock', 'tags'],
})

// createIndex() returns before the index finishes building
await mongoVector.waitForIndexReady({ indexName: 'embeddings' })

// The filter is applied during the index search
const results = await mongoVector.query({
  indexName: 'embeddings',
  queryVector: embedding,
  topK: 10,
  filter: { source: 'article1.txt' },
})

Mastra passes the filter to the index only when every field it references is declared in filterFields and every operator is one the index accepts: $and, $or, $eq, $ne, $gt, $gte, $lt, $lte, $in, and $nin. A filter that uses an undeclared field or any other operator takes a fallback path: Mastra matches the collection first and passes the matching document IDs into the vector search. That fallback holds only while the ID set fits within MongoDB's 16 MB BSON document limit. On large collections the query fails once that limit is exceeded, so declare your filter fields when you expect selective filters over large data sets.

pgVector applies the filter as an ordinary query condition:

const results = await pgVector.query({
  indexName: 'embeddings',
  queryVector: embedding,
  topK: 10,
  filter: { source: 'article1.txt' },
})

Postgres vector indexes (HNSW and IVFFlat) can't restrict that search to rows matching a condition. When a filter is present, pgVector instead compares the query vector against every matching row and returns the closest topK. Results are exact, but the work grows with the number of rows the filter matches. Indexing the metadata column speeds up row retrieval. The distance comparisons still happen per row.

Vector Query Tool
Direct link to Vector Query Tool

Sometimes you want to give your agent the ability to query a vector database directly. The Vector Query Tool allows your agent to be in charge of retrieval decisions, combining semantic search with optional filtering and reranking based on the agent's understanding of the user's needs.

import { createVectorQueryTool } from '@mastra/rag'
import { ModelRouterEmbeddingModel } from '@mastra/core/llm'

const vectorQueryTool = createVectorQueryTool({
  vectorStoreName: 'pgVector',
  indexName: 'embeddings',
  model: new ModelRouterEmbeddingModel('openai/text-embedding-3-small'),
})

When creating the tool, pay special attention to the tool's name and description - these help the agent understand when and how to use the retrieval capabilities. For example, you might name it "SearchKnowledgeBase" and describe it as "Search through our documentation to find relevant information about X topic."

This is particularly useful when:

  • Your agent needs to decide at runtime what information to retrieve
  • The retrieval process requires complex decision-making
  • You want the agent to combine multiple retrieval strategies based on context

Database-Specific Configurations
Direct link to Database-Specific Configurations

The Vector Query Tool supports database-specific configurations that enable you to use unique features and optimizations of different vector stores.

note

These configurations are for query-time options like namespaces, performance tuning, and filtering, not for database connection setup.

Connection credentials (URLs, auth tokens) are configured when you instantiate the vector store class (e.g., new LibSQLVector({ url: '...' })).

import { createVectorQueryTool } from '@mastra/rag'
import { ModelRouterEmbeddingModel } from '@mastra/core/llm'

// Pinecone with namespace
const pineconeQueryTool = createVectorQueryTool({
  vectorStoreName: 'pinecone',
  indexName: 'docs',
  model: new ModelRouterEmbeddingModel('openai/text-embedding-3-small'),
  databaseConfig: {
    pinecone: {
      namespace: 'production', // Isolate data by environment
    },
  },
})

// pgVector with performance tuning
const pgVectorQueryTool = createVectorQueryTool({
  vectorStoreName: 'postgres',
  indexName: 'embeddings',
  model: new ModelRouterEmbeddingModel('openai/text-embedding-3-small'),
  databaseConfig: {
    pgvector: {
      minScore: 0.7, // Filter low-quality results
      ef: 200, // HNSW search parameter
      probes: 10, // IVFFlat probe parameter
    },
  },
})

// Chroma with advanced filtering
const chromaQueryTool = createVectorQueryTool({
  vectorStoreName: 'chroma',
  indexName: 'documents',
  model: new ModelRouterEmbeddingModel('openai/text-embedding-3-small'),
  databaseConfig: {
    chroma: {
      where: { category: 'technical' },
      whereDocument: { $contains: 'API' },
    },
  },
})

// LanceDB with table specificity
const lanceQueryTool = createVectorQueryTool({
  vectorStoreName: 'lance',
  indexName: 'documents',
  model: new ModelRouterEmbeddingModel('openai/text-embedding-3-small'),
  databaseConfig: {
    lance: {
      tableName: 'myVectors', // Specify which table to query
      includeAllColumns: true, // Include all metadata columns in results
    },
  },
})

Key Benefits:

  • Pinecone namespaces: Organize vectors by tenant, environment, or data type
  • pgVector optimization: Control search accuracy and speed with ef/probes parameters
  • Quality filtering: Set minimum similarity thresholds to improve result relevance
  • LanceDB tables: Separate data into tables for better organization and performance
  • Runtime flexibility: Override configurations at runtime based on context

Common Use Cases:

  • Multi-tenant applications using Pinecone namespaces
  • Performance optimization in high-load scenarios
  • Environment-specific configurations (dev/staging/prod)
  • Quality-gated search results
  • Embedded, file-based vector storage with LanceDB for edge deployment scenarios

You can also override these configurations at runtime using the request context:

import { RequestContext } from '@mastra/core/request-context'

const requestContext = new RequestContext()
requestContext.set('databaseConfig', {
  pinecone: {
    namespace: 'runtime-namespace',
  },
})

await pineconeQueryTool.execute({ queryText: 'search query' }, { mastra, requestContext })

For detailed configuration options and advanced usage, see the Vector Query Tool Reference.

Vector Store Prompts
Direct link to Vector Store Prompts

Vector store prompts define query patterns and filtering capabilities for each vector database implementation. When implementing filtering, these prompts are required in the agent's instructions to specify valid operators and syntax for each vector store implementation.

vector-store.ts
import { MONGODB_PROMPT } from '@mastra/mongodb'

export const ragAgent = new Agent({
  id: 'rag-agent',
  name: 'RAG Agent',
  model: 'openai/gpt-5.6-sol',
  instructions: `
  Process queries using the provided context. Structure responses to be concise and relevant.
  ${MONGODB_PROMPT}
  `,
  tools: { vectorQueryTool },
})

Re-ranking
Direct link to Re-ranking

Initial vector similarity search can sometimes miss detailed relevance. Re-ranking is a more computationally expensive process, but more accurate algorithm that improves results by:

  • Considering word order and exact matches
  • Applying more advanced relevance scoring
  • Using a method called cross-attention between query and documents

Here's how to use re-ranking:

import { rerankWithScorer as rerank, MastraAgentRelevanceScorer } from '@mastra/rag'

// Get initial results from vector search
const initialResults = await pgVector.query({
  indexName: 'embeddings',
  queryVector: queryEmbedding,
  topK: 10,
})

// Create a relevance scorer
const relevanceProvider = new MastraAgentRelevanceScorer(
  'relevance-scorer',
  'openai/gpt-5.6-sol',
)

// Re-rank the results
const rerankedResults = await rerank({
  results: initialResults,
  query,
  scorer: relevanceProvider,
  options: {
    weights: {
      semantic: 0.5, // How well the content matches the query semantically
      vector: 0.3, // Original vector similarity score
      position: 0.2, // Preserves original result ordering
    },
    topK: 10,
  },
})

The weights control how different factors influence the final ranking:

  • semantic: Higher values prioritize semantic understanding and relevance to the query
  • vector: Higher values favor the original vector similarity scores
  • position: Higher values help maintain the original ordering of results
note

For semantic scoring to work properly during re-ranking, each result must include the text content in its metadata.text field.

You can also use other relevance score providers like Voyage AI, Cohere, or ZeroEntropy:

import { VoyageRelevanceScorer } from '@mastra/voyageai'

const relevanceProvider = new VoyageRelevanceScorer({ model: 'rerank-2.5' })
const relevanceProvider = new CohereRelevanceScorer('rerank-v3.5')
const relevanceProvider = new ZeroEntropyRelevanceScorer('zerank-1')

Voyage AI provides dedicated reranking models: rerank-2.5 and rerank-2.5-lite both allow up to 32,000 tokens for the query and any single document combined, and up to 600,000 tokens across a request. VoyageRelevanceScorer reads VOYAGE_API_KEY from the environment, or accepts an apiKey in its config.

The re-ranked results combine vector similarity with semantic understanding to improve retrieval quality.

For more details about re-ranking, see the rerank() method.

For graph-based retrieval that follows connections between chunks, see the GraphRAG documentation.

On this page