I read a piece on HippoRAG and it named something I’d been noodling about over vector database RAG for quite some time. Most RAG setups do nearest-neighbor lookup and hand-off to the LLM to connect the dots as understanding. The ingestion embeds everything, then the queries find what’s close, call it a day. HippoRAG builds a graph instead, one where “kitchen gadgets” pulls in “steam cooker” and “coffee grinder” because the concepts are actually related, not because two vectors happened to land near each other. And, whether it works better on not (TBD), that’s a better analogue to the way human memory works when one thought drags another in sideways.
What’s maybe more interesting is that HippoRAG can keep ingesting without rebuilding the graph. My experiments with vector databases haven’t ever been large enough to warrant a full reindex, but I’ve read that there’s a nuance to it such that you can end up with a poor distribution in the vector space and the query results will suffer for it. The solutions aren’t straightforward.
HippoRAG appears to sidestep the issue and I’m wondering if it’s worth thinking about using HippoRAG in addition to a vector database to successfully navigate situations where a corpus may or may not fall into the “good” category of indexable document collections.