Back office ops · Production

Why Danswer migrated to Vespa for enterprise RAG search

The problem

Danswer's RAG pipeline relied on two separate search engines for vector and keyword search that could not be weighted together, lacked flexible ranking functions for time-based decay, and could not efficiently handle multiple vector embeddings per document — limitations that degraded search accuracy at enterprise scale.

First attempt

Danswer tried applying time decay as a post-processing step after the initial search, but this workaround suffered in accuracy at large document scales.

Workflow diagram · grounded in source
1
Multi-source knowledge ingestion
integration
“We connect all of the disparate knowledge sources of a team (like Google Drive, Slack, Salesforce, etc.) and make all of this available via a single search/chat interface”
2
Multipass document indexing
ai_action
“every document is split into different sections for processing and each pass has a different size context. Vespa is (as far as I know) the only hybrid search engine that is capable of doing multiple vector embeddings for a single documen…”
3
Hybrid search with normalization
ai_action
“Vespa allows for an easy normalization across multiple search types and finally allowed us to achieve the accuracy we wanted”
4
Time-based decay ranking
ai_action
“Our users asked us to support decaying the relevance of documents if nobody touches or reads them for a long period. At the search engine level, this translated to a requirement to have flexible document ranking functions during the sear…”
5
RAG context retrieval
ai_action
“retrieving relevant context before passing it to the LLM (Retrieval Augmented Generation - RAG for short)”
6
GenAI response via chat interface
output
“make all of this available via a single search/chat interface and help users digest the content with GenAI”
Reported outcome

Migrating to Vespa enabled hybrid search with normalized weighting, native time-based decay ranking, and multipass multi-vector indexing per document, greatly reducing resource requirements while supporting tens of millions of documents per customer.

Reported metrics
Document index resource usagegreatly reduces the resources necessary to serve the document index
Document scale per customerup to tens of millions of documents per customer
Document scale where workarounds degraded accuracyseveral million
Reported stack
VespaVespa CloudGoogle DriveSlackSalesforce
Source
https://blog.vespa.ai/why-danswer-users-vespa/
Read source ↗

Frequently asked questions

What did this team achieve with this AI workflow?

Migrating to Vespa enabled hybrid search with normalized weighting, native time-based decay ranking, and multipass multi-vector indexing per document, greatly reducing resource requirements while supporting tens of mi…

What tools did this team use?

Vespa, Vespa Cloud, Google Drive, Slack, Salesforce.

What results were reported?

Document index resource usage: greatly reduces the resources necessary to serve the document index; Document scale per customer: up to tens of millions of documents per customer; Document scale where workarounds degraded accuracy: several million (source-reported, not independently verified).

What failed first in this deployment?

Danswer tried applying time decay as a post-processing step after the initial search, but this workaround suffered in accuracy at large document scales.

How is this back office ops AI workflow structured?

Multi-source knowledge ingestion → Multipass document indexing → Hybrid search with normalization → Time-based decay ranking → RAG context retrieval → GenAI response via chat interface.

Related back office ops cases