back_office_ops · saas · workflow
Why Danswer migrated to Vespa for enterprise RAG search
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.
How it works
Common implementation structure
How this type of workflow is generally built, generalized across documented cases — not tied to any one vendor's stack. Click any stage to read what happens there. Specific products that implement these stages appear in “Tools commonly seen” below.
Stage 1 · Multi-source knowledge ingestion
Danswer connects disparate knowledge sources such as Google Drive, Slack, and Salesforce into a single search and chat interface.
Tools used
VespaVespa Cloud
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.
What failed first
Danswer tried applying time decay as a post-processing step after the initial search, but this workaround suffered in accuracy at large document scales.
Results
Volumegreatly reduces the resources necessary to serve the document index
Grounding & classification
Source type: technical build writeup
21 fields verified against source quotes.
enterprise searchknowledge searchragknowledge basebuilder submittedfailure mode describednamed customerproduction runtime claimedsource backedtools describedworkflow describedsoftwareaccuracy improvementcost reductiontechnical build writeupback office opsrag answering