A precise answer from the price list and the policy

“How much is it and can I return it” is one question whose answer lives in two different documents. An ordinary search over one big base misses on these: it finds five fragments about the price and none about returns.

What is inside

1. Customer question — the entry, and it goes to all three places at once.
2. Search the price list and Search the policies run in parallel, one base each.
3. Fusing the two result sets makes them comparable.
4. Re-ranking by meaning keeps the four fragments that actually answer.
5. The answer is assembled from those only.

Why three steps and not one search

Two bases instead of one big one — because they go stale differently: prices change monthly, rules yearly. Separate bases are updated independently.

Fusion is needed because the two searches have their own similarity scales and cannot simply be added. It looks at positions in each result set rather than at scores, which is what makes it work across different bases.

Re-ranking is the one measured lever on retrieval quality. Search selects by vector proximity and formally similar text lands in the top five regularly; re-ranking compares each fragment against the whole question. It is billed per fragment — which is why eight are fetched and four survive.

What to set up for yourself

• The two bases and their ids.
• How many before and after. top_k on the searches and top_n on the re-rank: this is the direct cost-versus-quality dial.
• A third base is a third search into the same fusion, with no other edits.

What to connect

Two knowledge bases under Documents. This scenario costs noticeably more than plain RAG: two searches, two embedding calls and a re-rank per fragment. It is for questions where a wrong answer costs more than a turn.