Dense Vector and Sparse Vector and Fulltext and Tensor Reranker = Best for RAG? • Hacker News Board

Re: Dense Vector and Sparse Vector and Fulltext and Tensor Reranker = Best for RAG?

#11

Post by yingfeng » Wed, Jul 17, 2024, 4:51 AM UTC

fm100 wrote: post #9

Why do you guys implement tensor data type instead of integrating colbert directly?

Because colbert is not an end-to-end solution. As seen for RAGatouille, it has integrated colbertv2 into this repo. However, it's not a database, we implement tensor within infinity, aim to make an end-to-end solution for late interaction based ranking models.

Re: Dense Vector and Sparse Vector and Fulltext and Tensor Reranker = Best for RAG?

#12

Post by philippemnoel » Wed, Jul 17, 2024, 12:11 PM UTC

yingfeng wrote: post #4

yuzhichang wrote: post #3

Many vector database vendors claim sparse vector is enough for precise retrieval, bm25 is not necessary.

Hi, I'm one of the creators of infinity, and the article has mentioned about the sparse vector vs bm25. While the sparse vector performs well under some evaluations, it is obtained by training a model, which means that it can't fully represent all of the user's keywords/tokens, and those that don't appear in the training set, are truncated. So this is a very big impact for many enterprise vertical scenarios. And bm25…

BM25 is indeed way more important than these vector DBs will claim. At ParadeDB, we've observed significant use cases where customers need both

Re: Dense Vector and Sparse Vector and Fulltext and Tensor Reranker = Best for RAG?

#13

Post by philippemnoel » Wed, Jul 17, 2024, 12:16 PM UTC

yingfeng wrote: post #10

newpeak wrote: post #8

What's your advantages over paradedb? it also has dense+sparse+bm25

paradedb could also deliver three-way hybrid search through pg_vector, pg_sparse and pg_search. Compared with paradedb, infinity has following advantages: 1. Performance The performance of pg_vector is far slower than vector search of Infinity due to the vector index design. The performance of pg_sparse is also slower than sparse vector search of infinity. The performance of pg_search is much slower than full text se…

Hey folks, ParadeDB co-founder here. Cool project! Just thought I'd chime in and clarify a few things:

1. pg_sparse is deprecated. pgvector released native sparse vector support with the `sparsevec` datatype, and ParadeDB no longer maintains pg_sparse. It has been this way for several months already.

I'd love to see a benchmark re: Tantivy. You claim that pg_search is much slower, but Tantivy is state-of-the-art for full-text search performance and the ParadeDB performance is robust. You can see our benchmarks in our repository README, where we compare ourselves to Elastic.

4/5. ParadeDB is Postgres by design. If you are adopting Postgres, which many are, then ParadeDB can be installed directly as an extension via logical replication on a read replica. This removes the need for ETL to a non-Postgres system, which drastically reduces operational burden.

Of course, if you're not using Postgres, ParadeDB is not designed for you and a tool like Infinity seems like a viable option alongside other standalone search engines.