We Built an Alternative to Vector RAG for AI Agent Memory | Hacker News Reader

We Built an Alternative to Vector RAG for AI Agent Memory

claix.dev

4 pointsgael_dev10 comments

The entire site looks like it was generated with Claude. The site hijacks scrolling.

I scanned through paragraph after paragraph of overbloated and repetitive descriptions of what and how RAG works compared to how "modern agents" need to access documents.

What I never saw at any point was whatever this "alternative to RAG" was supposed to be.

Honestly the entire body of copy feels like it was llm generated.

You should add hnslop to your browser. Adds the percent AI of a link before you open it.

For example this one says 100% AI: https://www.salahadawi.com/hacker-news-ai-detector/49993820

https://hnslop.nilsherzig.com/

I read the first paragraph or two, but then I stopped for two reasons:

A) searching using BM25 and via vector embeddings are two different methods of search; both have their uses, many practical use cases benefit from having both. The search method is independent of who calls it when, i.e. whether you just have a static pipeline, or a dynamic one where the search tool calls them.

B) you're describing the static pipeline as if it were SOTA. We dropped that well over a year ago IIRC. There might still be cases where that is good enough, but in general, agentic search has pretty much become the default since LLMs became reasonably good at tool calling.

yeah no thank you. There's no way in hell I am going to share with you any sort of document.

The idea isn’t that you should share documents with us. It’s about giving agents structured, source-traceable memory without relying on a central vector database.

do you think I'm reading that wall of spam?

It's not spam, it's an article made to explain Claix's Agentic RAG as best as possible.

(If that is your project, you should mark it as Show HN to get feedback with a nicer default).

I'm sorry, but then that article fails. It is very repetitive without clearly answering the differences. It gives the LLM feeling because it does not give a straight-forward answer to what the alternative actually is. Yes, something the agent can call itself while doing the task without having to pre-process the data, but that encompasses basically everything. What exactly is the proposal, what is the thing that was (according to the title) built?

Instead you get a quick answer box after the introduction that repeats the introduction, and the FAQ at the bottom leads with two similar sounding points. Even for an LLM-generated document that's not a good result.

How does it compare with alternatives? Benchmarks and feature comparison table, please.

Firstly, I think it would be useful for each document to first be neatly converted to markdown, including detailed Latex/Mermaid/captions for images. This would be at the time of insertion into the store.

Secondly, I think vectoring should never apply over simple chunks. A document's markdown should be separated into distinct subtopical assortments by a reasoning LLM, with each subtopic having a subtitle and text. Each such subtopic must then be added to the BM25 and vector stores as a row. Speaking of which, don't overlook BM25 search co-integration besides vector search.

Thirdly, I think agentic RAG should apply only as an optional final step to refine what was generated using BM25+vector search.

Reply on news.ycombinator.com