Prototype · three rewrite strategies benchmarked
Query Rewriting for a Global Asset Manager’s Research RAG (Prototype)
An asset manager’s internal research assistant retrieved well when users asked well. We benchmarked three ways to rewrite the questions they actually ask, and matched each to the kind of question it fixes.
The problem
A global asset manager already ran a multimodal RAG pipeline over its research publications. Retrieval was fine for precise questions and poor for real ones: vague questions that never named the asset class, compound questions that asked three things at once, and questions that needed a follow-up the user had not thought of.
What we built
A prototype query-rewriting layer in front of the existing retriever, tested on the firm’s own public research (an emerging-markets report). Each strategy was measured on retrieval before and after the rewrite, so the result was a routing decision, not an opinion.
Before
- Vague questions without keywords
- Three questions asked at once
- Users unsure what to ask next
How it works
Hypothetical answer first (HyDE). For a vague question, the model drafts a plausible answer, a question is rewritten from that draft, and both are embedded. The draft may be wrong, but it carries the vocabulary the real documents use.
Rewrite, retrieve, read. For a compound question, a rewriter splits it into separate retrievable queries before anything is searched, so each part finds its own evidence.
Perspective-driven follow-ups (STORM). For an exploratory question, a small set of perspective agents each proposes one follow-up query, surfacing angles the user would have asked next.
Measure at retrieval, not at the answer. Every strategy was scored on what it retrieved, against the unrewritten baseline, so a fluent answer could not hide a weak search.
Route by question type. The outcome: HyDE for vague questions, rewrite-retrieve-read for compound ones, STORM when the user needs help deciding what to ask.
After
Prototype · three rewrite strategies benchmarked
Stack
RAGQuery RewritingHyDEAsset ManagementWhy it holds up
Most RAG failures are blamed on the model and caused by the question. Rewriting is cheap, but only one strategy suits each kind of question; applying all of them to every query adds latency and noise. Measuring at retrieval is what made the routing defensible.
Related service: Enterprise RAG
More case studies
Big 4 client · fully on-premise
Enterprise RAG Chatbot for a Big 4 Accounting Firm
Multimodal retrieval over a Big 4 firm’s full compliance library, tuned for citation instead of summary — every answer arrives with its source paragraph attached.
- Juniors reading thousands of pages per question
- Seniors acting as search engines
200k calls/month · 67% booking rate vs 77% human
24/7 AI Agent Call Center: 200k Calls a Month Across 60 US HVAC Brands
Voice agents orchestrating 200,000 calls a month across 60 US HVAC brands for a 5,000-person enterprise, booking 67% of calls against 77% for human agents — within 10 points of a trained team, around the clock. Built as a product, an AI front desk that answers, books and routes, not a pilot.
- Night and weekend calls unanswered
- Staffing every shift hard to justify
US$1M collected in the first 3 months
AI Payment Collection and Reminders
The companion product to the AI front desk: it chases unpaid invoices with polite, timed reminders and a payment link, and stops the moment the customer pays or replies. It collected over US$1 million for the client in its first three months.
- Chasing payment is awkward and late
- Billable time lost to collections
Get started
Talk to the engineer who will build it.
You will speak with me directly. Bring the use case, the data and the constraints, and I will give you a straight view on feasibility, effort and the first thing to ship.
