Faster Retrieval for Better, More Efficient RAG

(machinelearning.apple.com)

55 points | by zerop 1 hour ago

2 comments

  • comandillos 43 minutes ago
    I feel like retrieval approaches, despite how good your ranking mechanisms are, end up biasing LLMs into what a heuristics-based system with way worse understanding of the domain says. I guess is a trade off between speed and quality, but letting the LLM explore without a bias (based on my personal experience) seems to generally provide much better results in terms of quality for the final output.
  • brrrrrm 21 minutes ago
    as a recovering RAG-enthusiast, I will share a quote from a peer that has really stuck with me:

    "why not use grep?"

    • goldenarm 18 minutes ago
      Grep is the fastest tool for many things, but for production RAG it cannot search with meaning, different languages or typos like hybrid vector search can. And it won't scale on terabytes of documents across distributed servers if you want to say under 1000ms.
      • dv_dt 10 minutes ago
        If the data is this large then why not ask the llm to build a query
        • nostrebored 4 minutes ago
          latency is often the reason, distilling interactions into significantly better retrieval is the second.
        • aaroninsf 5 minutes ago
          My case:

          With a very large dataset of totally unnormalized data, semantic folding is a silver bullet.