RAG will have a place in the LLM world, since it's a way to obtain data/facts/info for relevant queries. Since you asked about alternatives... (a) "World models" where LLMs structure information into code, structured data, etc. and query those models will likely be a thing. AlphaGeometry uses this[1], and people have tried to abstract this in different ways[2]. (b) Depending on how you define RAG, knowledge graphs co…
I don't understand why knowledge graph would be an alternative to RAG? Knowledge graphs can (and are already) used as part of a RAG pipeline.
Ask HN: Is RAG the Future of LLMs?
101–108 of 108 posts
Re: Ask HN: Is RAG the Future of LLMs?
#102Earlier quoted context omitted.
tl;dr we only need a vector database if we want to do semantic vector-embedding search AND our dataset is too large for memory long answer: RAG is just a pattern of working with LLMs, independent of particular database technologies. Basically it means you inject some context data or domain specific data into the prompt to achieve the following: 1. Nudging the model into the right direction so it will use the "correct…
Thank you for your insights. AS someone who is absolutely new to this, could you clarify the role of embedding in RAG? Do I need to use OpenAI's OpenAI embedding model (text-embedding-ada-002) always to use for embeddings ? Supposing I do use text-embedding-ada-002 model and store the index in a vector database, will I be able use these for RAG with other LLMs such as Claude Haiku etc. ? Or does each LLM have its own…
The Embedding model is independent of the actual LLM used in generation. You can use any embedding model with any LLM. In fact ada is only one option and there are lot of really good embedding models, also ones you can easily run local, or ones which are a lot of better than ada, readily available. ada is not the best choice in all cases.
Re: Ask HN: Is RAG the Future of LLMs?
#103Earlier quoted context omitted.
uh yeah it works out of the box, this is how most RAG systems are designed, just look at pgvector for example.
Nope that’s not how most rag systems work today. I looked at pgvector and couldn’t find anything similar. Do you have a link? Or maybe you misunderstood what I was taking about
Re: Ask HN: Is RAG the Future of LLMs?
#104Earlier quoted context omitted.
It's becoming so complex that it will stop being called RAG. It's just an application that uses an LLM as one part of it.
I see many folks misunderstanding RAG for a technology. It's just a process. No matter the complexity, if the underlying principal is to augment the LLM with specific information to the question at hand - it is RAG.
Re: Ask HN: Is RAG the Future of LLMs?
#105Earlier quoted context omitted.
Do you have a problem with LangChain and LlamaIndex due to their changing codebases/APIs/etc., or do you think there's a fundamental issue with RAG itself?
Maybe a mixture of both? I think both projects were super useful, grateful for them. There is a lot of utility tucked away in both projects. A year ago,I started using LLM APIs in non-Python languages and realized that sometimes building from scratch is better.
Re: Ask HN: Is RAG the Future of LLMs?
#106Earlier quoted context omitted.
Nope that’s not how most rag systems work today. I looked at pgvector and couldn’t find anything similar. Do you have a link? Or maybe you misunderstood what I was taking about
Sorry for the late response. I must be misunderstanding your comment. I read your comment as "RAG doesn't pre-compute KV for each document, which is inefficient". With RAG, you convert your text into vectors and then store them in a DB — this is the pre-compute. Then you just need to compute the vector of your query, and search for vector similarity. So it seems to me like RAG doesn't suffer from inefficiency you wer…
The current workflow is to use the embedding to retrieve documents then dump the text corresponding to the embedding into the LLM context for generation.
Often, the embedding is from a different model from the LLM and it is not compatible with the generation part.
So yea, RAG does not pre-compute the KV for each document.
Re: Ask HN: Is RAG the Future of LLMs?
#107Earlier quoted context omitted.
Sorry for the late response. I must be misunderstanding your comment. I read your comment as "RAG doesn't pre-compute KV for each document, which is inefficient". With RAG, you convert your text into vectors and then store them in a DB — this is the pre-compute. Then you just need to compute the vector of your query, and search for vector similarity. So it seems to me like RAG doesn't suffer from inefficiency you wer…
No, you've only discussed the Retrieval part of RAG, not the generation part. The current workflow is to use the embedding to retrieve documents then dump the text corresponding to the embedding into the LLM context for generation. Often, the embedding is from a different model from the LLM and it is not compatible with the generation part. So yea, RAG does not pre-compute the KV for each document.
Re: Ask HN: Is RAG the Future of LLMs?
#108Try it out: https://github.com/truefoundry/cognita