179 questions
No questions match those filters.
Why can't you just put every knowledge source behind one vector index, and once you have several independently governed sources, how do you decide which ones to actually query per request?
This is one of the questions in the full AI/ML interview bank. Pro unlocks all 1789 questions; Premium includes the same bank plus the highest daily Practice limit.
See plansDistinct sources — legal contracts, HR policy, regional wikis, a compliance archive — often can’t merge into one index for reasons that survive any amount of engineering effort: independent ownership and update cadence, and frequently hard data-residency or compliance constraints that a single-region index can’t satisfy no matter how its rows get filtered. Given N separately governed sources, the naive move is to broadcast every query to all of them synchronously, but tail-latency risk compounds combinatorially, not linearly: P(at least one miss) = 1 − (1 − p)^N. At N = 8 sources and a modest 5% per-source miss rate, roughly a third of requests pay the tail; narrowing to 3 well-chosen sources cuts that to about 14%.
Classical collection-selection algorithms score sources lexically (CORI-style) and don’t adapt as sources drift out of sync with each other’s content, which is why modern federated RAG routes in embedding space instead — a learned router (RAGRoute-style) predicting which sources are likely useful for a given query, trained against measured per-source hit rates rather than a hand-built category table; in practice a learned router reaches meaningfully fewer queries per request than a hand-built one at the same accuracy. Merging results across selected sources has to go through reciprocal rank fusion or a shared reranker, never raw score concatenation, because a BM25-backed source and a dense-embedding source produce scores on incomparable scales. Finally, keep routing policy, merge policy, and audit policy as three separate decisions — a compliance team wanting proof that all sources were considered doesn’t need every live query to fan out to all of them; that can be satisfied by logging which sources were eligible or by a low-frequency exhaustive sample compared against the routed result, at a fraction of the cost.