Retrieval
Retrieval is the step where Dataworkz finds the content most relevant to a user's question and assembles it into the context passed to the LLM. Retrieval quality determines whether the generated response is accurate, on-topic, and grounded in your data. All retrieval options are configurable in Step 4 of the custom RAG wizard.
How Retrieval Works
The user's query is converted into a vector using the same embedding model used for documents
Dataworkz performs a similarity search against stored document vectors in the vector database
The top N most similar chunks are selected
Selected chunks are assembled into a context window and sent to the LLM along with the query
The LLM generates a response grounded in the retrieved content
Retrieval Options
Top N
Controls how many chunks are retrieved per query. Retrieving more chunks gives the LLM broader context but increases response latency and token cost. The right value depends on average chunk size and document complexity.
Metadata Filters
Restricts retrieval to chunks that match specific metadata values — for example, only documents tagged with department = "legal" or region = "EMEA". Filters are applied before similarity search, narrowing the search space.
Auto-extraction — Dataworkz can parse filter values directly out of the query text. If a user asks "What are the EMEA travel policies?", the system automatically applies region = EMEA as a filter without the user specifying it explicitly.
Query Rewriting
Rephrases the user's query before embedding to improve retrieval accuracy. Common rewrites include expanding acronyms, resolving pronouns, and reformulating conversational questions into retrieval-friendly statements.
Hybrid Search
Combines dense vector search (semantic similarity) with keyword search (BM25) to improve precision on domain-specific terms, product names, or codes that embedding models may not represent well semantically.
Input Guardrails
Defines topics or patterns that should be blocked or flagged before retrieval runs. Use guardrails to prevent the RAG app from processing out-of-scope or sensitive queries.
Caching
Returns stored responses for queries that are semantically similar to previously answered questions. Caching reduces LLM latency and cost for high-volume deployments with recurring query patterns.
Encoder / Chunking Configuration
Allows retrieval-time adjustment of how the retrieved chunks are re-segmented or re-encoded before being passed to the LLM — useful for tuning context window usage.
Retrieval Source Configuration
A RAG application can query one or more collections simultaneously. Results from multiple collections are merged and ranked before being passed to the LLM. Keeping source types in separate collections (see Ingestion) makes per-collection filter configuration more precise.
Last updated