Better RAG Results with Reciprocal Rank Fusion and Hybrid Search
21–30 of 59 posts
Re: Better RAG Results with Reciprocal Rank Fusion and Hybrid Search
#22(disclaimer: supabase dev who went down the rabbit hole with hybrid search)
Re: Better RAG Results with Reciprocal Rank Fusion and Hybrid Search
#23The tradeoffs of using existing systems vs building your own resonate with me. What we eventually experienced, however, is that periods of bad search performance often correlated to out-of-date search indices.
I'd be interested in another article detailing how you monitor search. It can be tricky to keep an entire search system moving.
Re: Better RAG Results with Reciprocal Rank Fusion and Hybrid Search
#24Re: Better RAG Results with Reciprocal Rank Fusion and Hybrid Search
#25LlamaIndex has a module for exactly this
https://docs.llamaindex.ai/en/stable/examples/retrievers/rel...
Re: Better RAG Results with Reciprocal Rank Fusion and Hybrid Search
#26Any tips on accomplishing this in Postgres with pg_vector?
Re: Better RAG Results with Reciprocal Rank Fusion and Hybrid Search
#271. Does anyone know a postgres reranking extension, to go beyond RRF through ML models or at least custom code? 2. If anyone is observing significant gains from incorporating knowledge graphs into the retrieval step, what kind of a knowledge graph are you working with, what is your retrieval algorithm, and what technology are you using to store it?
I'm not using that in my own experiments since I don't want to worry about the performance of running a model on production, but seems worth a try.
Re: Better RAG Results with Reciprocal Rank Fusion and Hybrid Search
#28At first, I downloaded entire channels, loaded them into a vector DB, and did RAG. The results sucked. Vector searches don't understand things very well, and in this world, specific keywords and error messages are very searchable.
Instead, I take the user's query, ask an LLM (Claude / Bedrock) to find keywords, then search Slack using the API, get results, and use an LLM to filter for discussions that are relevant, then summarize them all in a response.
This is slow, of course, so it's very multi-threaded. A typical response will be within 30 seconds.
Re: Better RAG Results with Reciprocal Rank Fusion and Hybrid Search
#29Any tips on accomplishing this in Postgres with pg_vector?
Supabase has some good examples on their website, search for hybrid search. I needed to tune the function they have there but it should show you how to approach it.
Re: Better RAG Results with Reciprocal Rank Fusion and Hybrid Search
#30Earlier quoted context omitted.
Author here: you're for sure right -- it's not a problem with RAG the theoretical concept. In fact, I think RAG implementations should likely be specific to their use cases (e.g. our hybrid search approach works well for customer support, but I'm not sure if it would work as well in other contexts, say for legal bots). I've seen the whole gamut of RAG implementations as well, and the implementation, specifically prom…
re: legal, I saw a post on this idea where their RAG system was designed to return the actual text from the document rather than a LLM response or summary. The LLM played a role in turning the query into the search params, but the insight was that for certain kinds of documents, you want the actual source because of the existing, human written summary or the detailed nuances therein