Can anyone suggest a RAG pipeline that is production ready?
Also I wonder if it's now better to use Claude Agent SDK instead of RAG. If anyone has tried this, I would be interested in hearing more.
From zero to a RAG system: successes and failures
91–100 of 129 posts
Re: From zero to a RAG system: successes and failures
#92Cool work! Would be so interested in what would happen if you would put the data and you plan / features you wanted in a Claude Code instance and let it go. You did carefully thinking, but those models now also go really far and deep. Would be really interested in seeing what it comes up with. For that kind of data getting something like a Mac mini or whatever (no not with OpenClaw) would be damn interesting to see h…
But where is the fun with that?
Being curious is always fun right.
Re: From zero to a RAG system: successes and failures
#93Is there a 'sqlite equivalent' for RAG? e.g. something I could give Claude w/o a backend and say use command X to add a document, command Y to search, all in a flat file?
Re: From zero to a RAG system: successes and failures
#94And some have been saying that RAGs are obsolete—that the context window of a modern LLM is adequate (preferable?). The example I recently read was that the contexts are large enough for the entire "The Lord of the Rings" books. That may be, but then there's an entire law library, the entirety of Wikipedia (and the example in this article of 451 GB). Surely those are at least an order of magnitude larger than Tolkien…
[flagged]
Re: From zero to a RAG system: successes and failures
#95Good company-ready RAG benefits a lot from some basic pre-processing/labeling of the data instead of solely dumping unstrucuted data into a vector database and calling it a day. Different heuristics and different schemas of embedded data go a long way in ensuring quality and flexibility of querying.
Then you can do ReAG, which let's you reason on top of the top K intelligently.
And things like memory knowledge graph services as well, can help reduce your search space, and provide extra context over time that gets updated, beyond just treating static docs as sources of truth. You can give it more context as to how it should interpret older docs, vs. newer docs, and allowing users (based on correctness or not) to help audit the what is embedded in your RAG systems.
I appreciate the thorough write up, but doing RAG systems seriously requires much more than just embeddings and a basic chromadb set up.
Happy to share any thoughts here or on a call if anyone wants to chat.
Re: From zero to a RAG system: successes and failures
#96[flagged]
Re: From zero to a RAG system: successes and failures
#97I implemented many RAGs and feel sorry for anyone proclaiming "RAG is dead". These folks have never implemented one, maybe followed a tutorial and installed a "Hello World!" project but that's it. I don't want to go into detail but 100% agree with the author's conclusion: data is key. Data ingestion to be precisely. Simply using docling and transforming PDFs to markdown and have a vector database doing the rest is ri…
[dead]
Re: From zero to a RAG system: successes and failures
#98[flagged]
Re: From zero to a RAG system: successes and failures
#99If you want to build a prod ready RAH architecture with decent benchmark scores I can recommend this blog post based on our experiences what techniques actually work: https://bytevagabond.com/post/how-to-build-enterprise-ai-rag...
thank you for sharing your experience