[inboulder]

PageRank for better centrality seems neat, but it still doesn't address the probably unsolvable flaw with RAG, the reason why RAG basically can't work. All RAG DBs under-perform expectations because RAG fundamentally can't find relationships between words necessary to find the information the user cares about. Weird right, isn't this what the 'attention' mechanism is supposed to be good for? It just isn't good enough.

Example: Say you're searching an article and you want to know what occupation a mentioned person has, let's say the person 'Sharon,' is mentioned to have attended several physical chemistry conferences but her occupation is never explicitly mentioned. There's a very good chance every single rag approach will fail to return correct results, will fail to make this connection between 'occupation' attends conference, type of conference and infers 'chemist'. I could go on, but this sort of error is pervasive along all types of information when trying to retrieve with RAG. In the end, solutions like the above seem to just sort of reinvent other query methods, SQL, pagerank etc, with extra steps... there's little point in vectorization at that point...

[samsonradu]

Isn't this inference an LLM's job? The RAG component just needs to find the Sharon article among a large dataset and pass it (entirely) to the LLM as context.

[jsenn]

On the contrary, examples like yours are the entire point of approaches like this one. If you read the HippoRAG paper cited by OP, their motivating example is almost identical to yours, and their evaluations are largely on multi-hop question answering of this kind.

[queueueue]

I don't see how this is not possible using knowledge graphs? You retrieve the entity, Sharon, and the additional context you get will be the nodes and edges close to Sharon. After this it becomes the LLM's job because if it is not mentioned in the given context, it should let the prompter know "In the given context the occupation of Sharon could not be found".