Faster Retrieval for Better, More Efficient RAG

(machinelearning.apple.com)

59 points | by zerop 2 hours ago

2 comments

  • comandillos 50 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 29 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 25 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 17 minutes ago
        If the data is this large then why not ask the llm to build a query
        • nostrebored 12 minutes ago
          latency is often the reason, distilling interactions into significantly better retrieval is the second.
        • aaroninsf 12 minutes ago
          My case:

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