Yes you are wrong. RAG means retrieval-augmented generation. If you’re generating something and that generation is augmented by some retrieval you’re doing RAG. The retrieval doesn’t need to be from a vector db or even based on semantic similarity.

▲

kordlessagain 16 hours ago | parent [-]

Calling the framework "Retrieval-Augmented Generation" is actually an oversimplification. It's defensible, but inaccurate at best.

For RAG to succeed at scale, it relies heavily on sophisticated orchestration layers, data transformation engines (indexing) and logical loops (augmented retrieval).

Arguing semantics is important at times but being absolute about it is black and white thinking - cheap effort for a complex topic. Don't throw out the baby with the bath water!

Check out Lume: https://github.com/DeepBlueDynamics/lume. If it weren't obvious by the commits, I work on it. Probably a good reference for HOW to do good RAG, but not the ONLY way to do it.

▲

seanhunter 15 hours ago | parent [-]

Don't blame me, blame the people who invented the concept and wrote the original RAG paper.

https://arxiv.org/pdf/2005.11401

▲

kordlessagain 8 hours ago | parent [-]

Calling it an oversimplification isn't blame. It's just a fact. And you are the one that told someone they were wrong, and couldn't back it up with anything but the thing that over simplified from the beginning. That's just dumb gatekeeping.

	▲	seanhunter 2 hours ago \| parent [-]
		Backing a question about definition up with the actual source of the definition isn’t “dumb gatekeeping”. You feel that there is a right way to do RAG and you’ve written a framework that does it that way. That’s great. I’m not the one who’s saying that certain things are not RAG so I don’t really see how I’m gatekeeping. I was actually trying to be helpful.