Qdrant can retain both dense and BM25 sparse representations and fuse their rankings through Query API. I would test this before changing databases; technical identifiers also need explicit tokenization and exact-match checks, not semantic retrieval alone.

Hybrid retrieval inside the reference

Qdrant documents server-side BM25 encoding and dense/sparse rank fusion through Query API. These replace the reference's dense-only search operation, not its database or backend. Match the API and encoding configuration to the deployed server/client versions.

My proposed test: retrieve bounded candidate sets from both representations, fuse them, and compare with dense-only retrieval. For repository documents, include literal identifiers, paths, and configuration keys. Inspect tokenization rather than assuming BM25 preserves every identifier. Use an explicit exact-match route when literal identity matters.

The hypothesis is better coverage of both paraphrases and terminology. No corpus-specific improvement has been measured.