We Built an Alternative to Vector RAG for AI Agent Memory(www.claix.dev)
4 pointsby gael_dev5 hours ago8 comments
  • geuis4 hours ago
    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.

  • cmenge4 hours ago
    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.

  • 5 hours ago
    undefined
  • ericol5 hours ago
    yeah no thank you. There's no way in hell I am going to share with you any sort of document.
    • gael_dev4 hours ago
      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.
  • mkgiga4 hours ago
    do you think I'm reading that wall of spam?
    • gael_dev4 hours ago
      It's not spam, it's an article made to explain Claix's Agentic RAG as best as possible.
      • onli4 hours ago
        (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.

  • OutOfHere2 hours ago
    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.

  • esafak4 hours ago
    How does it compare with alternatives? Benchmarks and feature comparison table, please.
  • hnisjafx404 hours ago
    [flagged]