So, yes, maybe there's a way to "distribute" RAG. (I still wonder if that isn't just MoE taken to its logical conclusion)
So, dig for ColBERT papers, might be helpful. (I wish I had the time to do that)
I could see that in the very long term, but as it stands, it works the way you intuited: 2 turkeys don't make an eagle, i.e. there's some critical size where its speaking coherently, and its at least an OOM bigger than it needs to be in order to be interesting for products
fwiw RAG for me in this case is: - user asks q.
- llm generates search queries.
- search api returns urls.
- web view downloads urls.
- app turns html to text.
- local embedding model turns text into chunks.
- app decides, based on "character" limit configured by user, how many chunks to send.
- LLM gets all the chunks, instructions + original question, and answers.
It's incredibly interesting how many models fail this simple test, there's been multiple Google releases in the last year that just couldn't handle it.
- Some of it is basic too small to be coherent, bigcos don't make that mistake though.
- There's another critical threshold where the model doesn't wander off doing the traditional LLM task of completing rather than answering. What I mean is, throwing in 6 pages worth of retrieved webpages will cause some models to just start rambling like its writing more web pages, i.e. they're not able to "identify the context" of the web page snippets, and they ignore the instructions.
One simple way is what Omar Khattab (ColBert) mentioned about scoring function instead of a simple vector.
Another is to use a classifier at the start directing queries to the right model. You will have to train the classifier though. (I mean a language model kind of does this implicitly, you are just taking more control by making it explicit.)
Another is how you index your docs. Today, most RAG approaches do not encode enough information. If you have defined domains/models already, you can encode the same in metadata for your docs at the time of indexing, and you pick the model based on the metadata.
These approaches would work pretty well, given a model as small as 100M size can regurgitate what is in your docs. And is faster compared to your larger models.
Benefit wise, I don't see a lot of benefit except preserving privacy and gaining more control.
Could you please provide some more info (or maybe links) about this, please?
What I meant was that at the time of indexing, you can add more information to any chunk. This[1] is a simple example by Anthropic where they add more relevant context. In our case, say you have two models, D1 and D2. At the time of creating a vector store, you can add which model is more suitable to a chunk, so that when you retrieve it, you use the same model for inference. This is custom built, very dependent on datasets, but would get you to the functionality described. I suggest this approach when there are linkages between various docs (eg: financial statements/earning calls etc.).
I try to explain this a bit better here: https://pa-mar.net/Study/AiKiDo/VirtualBudoPass.html
Btw, I notice only now that the link that was supposed to explain my question better is completely wrong.
https://news.ycombinator.com/item?id=42589014
(But you still provided much needed clarification).
The general idea is probably be better for the code use case too, since having the module's whole codebase in context likely allows for more precise edits. Whereas RAG is just search, not edit.
That said, probably code assistants must somewhat do this already, though it must be more ad-hoc. Obviously they wouldn't be able to do any completions if they don't have detailed context of the adjacent code.
These could all presumably be the same physical instance, just each query would use a different system prompt and perhaps different embeddings. (I'm guessing; I don't actually know how RAG works). So, a little slower and clunkier, but presumably way more efficient. And match could be anywhere between horrible to better-than-one-large-model. This would be more like how businesses organize docs.
Or maybe there's no real benefit to this, and each subclassifier would require just as big of a model as if you were to throw all docs into a single model anyway. I assume it's probably been tried before.