Skip to content
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

Support for compression #82

Open
LemonBreezes opened this issue Sep 22, 2023 · 1 comment
Open

Support for compression #82

LemonBreezes opened this issue Sep 22, 2023 · 1 comment

Comments

@LemonBreezes
Copy link
Contributor

LemonBreezes commented Sep 22, 2023

Hi. This falls into the more general need for a framework for creating AI pipelines but... How about also a way to loop over a prompt with GPT 3.5 and compress it so that we can send larger queries (ie work around the context limit)

@rksm
Copy link
Owner

rksm commented Sep 22, 2023

Yeah I was previously rejecting this but I'm open for ideas in how to approach this and of course would welcome contributions. The tricky bit here is to have something that makes sense for the "fork" and "reduce".

First, it can make a big difference in how you split something up. E.g. when summarizing an article or interviews there are certain places in the text that are better than others, e.g. after a paragraph ends, before a new chapter/subsection starts, after a reply to a question etc. This depends on the kind of text and to get the best result should be customizable. So for example allowing for some kind of function that can indicate positions inside of a text to trim.

Then, do you want a serial/rolling prompt or parallel prompting? With the former it is possible to e.g. embed a reply ("carry over") from the previous prompt which can e.g. be useful for summaries.

Then the final processing step. The simplest solution is to just concatenate the outputs but e.g. for a parallel summarization strategy you would want all the outputs combined in a last prompt to "summarize the summaries" etc.

So my concern here is the following: Providing support and an abstraction for all this is a lot of work (and would add complexities on its own) while at the same time that support might not be general enough to be useful for a particular use cases. Which would then make you go and just pull out an SDK in your favorite language and script your own... So I would like some ideas in how an implementation would be useful before starting work on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants