-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add option for RAG-style augmentation #1
Comments
Take a look at how continue.dev comes with its own little embeddings server. It's a new experimental feature, and it's a big piece of software. https://continue.dev/docs/walkthroughs/codebase-embeddings Anyway, a minimal version of a similar thing could work with clipea. I would be able to essentially dump stuff into its memory, and then use slash-commands or @-tags to summon those into the prompt. A contrived but hopefully helpful quick example of slash-commands and @-tags. The slash makes the bot do something special ("verb") and @makes it include something ("what").
|
Ooh, that'd be very cool! I've had a play with ChromaDB but not done much with embeddings yet.
https://llm.datasette.io/en/stable/embeddings/index.html How would you envisage the setup? Something like this?
Might require simonw/llm#216 for it to be effective. |
I don't have a strong candidate to offer. My intuition says to stay away from abstract verbs like "embed", they are better suited for llm, which is a lower level library. We at command line level could ignore what's happening behind the scenes and /study or /find or /learn as CLI users who wouldn't have to even know what's driving this magic bus. That could be an aspiration if not full reality. Generally, the embeddings would be in two categories. The user will have some permanent knowledge they want the CLI to be aware of. It can't really be "all my files, past and future" because then the top-k chunks won't be that relevant for a specific case. Or the risk of them becoming less relevant increases. The very first instinct would be to not add embeddings at all. Instead you could rely that Assuming that, then this permanent knowledge could be referred at runtime by clipea.
Above, Now, an evolution from that could be one-time or even throwaway embeddings. Perhaps another verb for that, which explicitly is documented to create a collection and throw it away.
Parsing multiple verbs can get tricky, and it wouldn't be a crime to just support one verb at a time. Even if this sounds good, there's still the distinction between verb and object. Slash and @. Or maybe not. Continue.dev has made a distinction, probably for a reason, which I haven't fully analyzed. They've made some other clever choices, so I wouldn't shrug it off as YAGNI without thinking. Since clipea is a command line tool, one could also build an argument that verbs should be options and targets should be what follows them.
But that is venturing off from the natural-language land ("just say what you want") and in the syntax land, which kind of is what a tool like this is supposed to abstract away. SOME syntax is probably necessary, but what would be the most plain-english way to do it, that's what I suppose needs to be invented. |
I would like to boost this |
https://ai.meta.com/blog/retrieval-augmented-generation-streamlining-the-creation-of-intelligent-natural-language-processing-models/
https://www.promptingguide.ai/techniques/rag
Either manually or automatically provide man pages or --help output to the LLM.
Need to find examples where this is beneficial. Eg newer or esoteric software.
Some man pages are large and would likely slow down the response.
If automatic, maybe regex or maybe as the LLM if a man page would help.
Relates to #4
The text was updated successfully, but these errors were encountered: