A thresholded retriever like this gives you a clean way to keep the whole candidate set hidden, but it also turns recall into an ops problem, because the cutoff has to be tuned per embedding model and corpus drift. In practice that means a private RAG stack can silently get worse after a reindex, even if the crypto side stays unchanged.
> In practice that means a private RAG stack can silently get worse after a reindex, even if the crypto side stays unchanged.
That part feels overstated, because any retrieval pipeline can drift like that, thresholding just makes the failure mode more visible (and maybe easier to measure) than top-k with hidden scores, so I’m not sure it’s a new ops problem so much as the old one wearing a different hat....
> Hidden scores do help, but threshold tuning still sounds nastier than top-k.
Not necessarily, top-k just hides the same knob behind a rank cutoff, and with HE the more annoying part is that you can’t inspect the score distribution to see whether you’re under or over-selecting. Thresholding at least makes the precision/recall tradeoff explicit (and easier to keep stable if the embedding model shifts a bit), while top-k can look “fixed” right up until the corpus changes and the tail gets weird...