Practical add from running pgvector in production: similarity scores are only meaningful relative to your own data, so tune thresholds empirically instead of trusting defaults. What worked for me was logging score distributions on real queries, then picking cutoffs from that, not from documentation. And if you haven't tried hybrid retrieval yet, it's worth it: dense embeddings miss exact-term matches that sparse retrieval catches easily, and combining them fixed a whole class of "the answer was right there" failures for me. The theory is clean; the tuning is where the wins are.
Great insights! Yes, there is no one-size-fits-all approach and it’s better to look at data distribution for different use case. Regarding hybrid retrieval, that is exactly what I will cover in my next article. Stay tuned!
Practical add from running pgvector in production: similarity scores are only meaningful relative to your own data, so tune thresholds empirically instead of trusting defaults. What worked for me was logging score distributions on real queries, then picking cutoffs from that, not from documentation. And if you haven't tried hybrid retrieval yet, it's worth it: dense embeddings miss exact-term matches that sparse retrieval catches easily, and combining them fixed a whole class of "the answer was right there" failures for me. The theory is clean; the tuning is where the wins are.
Great insights! Yes, there is no one-size-fits-all approach and it’s better to look at data distribution for different use case. Regarding hybrid retrieval, that is exactly what I will cover in my next article. Stay tuned!