-
Notifications
You must be signed in to change notification settings - Fork 113
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
feat: get responses from multiple models from a single generation #14
Comments
yeah this would be dope. probably not the default flow but can probably tuck away in the menus somewhere
can you explain this a little more |
Keep in mind this is a very rough idea in head. Basically, I would love to have something that allows me to chain like this: System -> User -> GPT3.5 -> User -> GPT4 -> User -> GPT 3.5 -> User -> GPT 4 Here, if someone switches a model to higher cost, then only the previous output is sent through (does that phrasing make sense?) Basically I would love to be able to test something like lang chain but in a canvas like environment, I guess a mix of what flux is now + https://github.com/logspace-ai/langflow But I think that is a separate (and much heavier ask) than being able to just decide nodes for response (generate 3 responses, one from gpt3.5, one from gpt 4, one from cohere), which would be my basic request. |
could probably just add a new node type called "langchain/langflow" or something that takes a node tree as input like any other node and can spit out n responses that have the langchain logic applied to them. u'd set the behavior of the node by clicking on it which would open a modal where you could edit things via langflow/json/etc not sure i'm ready to take on that maintenance burden just yet but would def be interested to explore soon |
Hi,
I very often do response comparisons between GPT 4 and GPT 3.5. I would love an option like (nat.dev), to generate one leaf from GPT4, another from GPT3.5. It would also be cool to be able to change those in middle of the route to test efficient chaining (ex: cleanup using 3.5, important classification using 4 etc)
The text was updated successfully, but these errors were encountered: