-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Basic implementation of an plugin system for OA #2765
Basic implementation of an plugin system for OA #2765
Conversation
- added mussing types - fixed typos in react imports
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @draganjovanovich, first and foremost kudos for the great effort here!
So cool! if possible can you add some docstrings to some of the important functions to make it easier to try just jump in and understand them? I'm not 100% sure if we have any standards etc around this yet in the repo - but was thinking if thinking about some docs maybe starting there might be least painful for now potentially as such a big PR. |
- swaped "Question" from prompt with "New Input", works better with llama-SFT-7E3 - seed -> 43 - similarity coef for tool selection reduced
currently testing: llama-sft-7-e3 and small fixes - small prompt composition tweaks - fix for chat memory deletion - tweaking of sampling parameters - increased limit of request result truncation
What would be a good way to try help test this out? Would it be feasible for me to try this "locally" in some way? |
I can tell you how I ran this "locally" if it helps. I used docker for the complete OA stack on my local server like: As for requirements for the model, there are some details in readme.md files inside of inference and worker folders. |
Strangely I keep encountering
with the frontend. Can you also elaborate more on how to run it using just the inference text client and reducing the number of container services we need? For instance what docker container command line do you use to start the calculator plugin service? EDIT: I cleaned up the issue there but the above is more about ways to set up a service like the calculator and possibly reduce the service dependencies to just a text client. In both cases we will need to start the plugin service as it won't be available from a GUI frontend as well. |
Hi, Plugin is not included in docker containers, as its just example for now, there is no internal agreement yet, how we would go about default 'out-of-the-box' plugins. You can for now just run this command from the plugin folder: And update IP of the plugin in inference/server/oaast_inference_server/routes/configs.py the accordingly to your network environment. |
That's ok. The idea however is to spin it up so that we can experiment with a plugin in general and the changes here.
Not sure if all of this is enough: I did
and adapted the IP in diff --git a/inference/server/oasst_inference_server/routes/configs.py b/inference/server/oasst_inference_server/routes/configs.py
index 46a8ff99..7c0f2a0e 100644
--- a/inference/server/oasst_inference_server/routes/configs.py
+++ b/inference/server/oasst_inference_server/routes/configs.py
@@ -12,7 +12,7 @@ from oasst_shared.schemas import inference
# NOTE: Replace this with plugins that we will provide out of the box
DUMMY_PLUGINS = [
inference.PluginEntry(
- url="http://192.168.0.35:8085/ai-plugin.json",
+ url="http://192.168.0.31:8085/ai-plugin.json",
enabled=False,
trusted=True,
), then tested the port opening via |
All that you have done seems about right. |
It would be cool if you or someone can make some automated "dev" chat sessions like: |
Unfortunately no error of any kind (also no
and I can see the minimal plugin being listed in the work request:
Perhaps the plugin_config should be populated and values here should be different? |
- tweaked sampling settings for plugin usage - tweaked prompting templage - fix for tool extraction function - fix in final prompt when plugin is not used
legal_info_url: str | None = None | ||
endpoints: List[PluginOpenAPIEndpoint] | None = None | ||
|
||
def __getitem__(self, key: str) -> Any: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you sure these are working as wanted? pydantic does quite a bit of magic, I'm particularly worried about the use of setattr
here, but it's just a feeling, no particular knowledge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure, It works. but could be that I am misusing it?
|
||
|
||
class PluginUsed(pydantic.BaseModel): | ||
name: str | None = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why could name or url be none here? does it make sense ot have a PluginUsed
with only execution details and nothing else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that I had some misconfigured plugins while developing it, and then got the error with name cant be None, just added None, so it can be deleted. But regarding plugins and parsing, there are quite a few weak points, i will address them soon, as i found them while trying various other plugins...
For example this one will fail:
https://chatgpt-plugin-ts.transitive-bullshit.workers.dev/.well-known/ai-plugin.json
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed it just half hour ago, will push it later then.
deleted package-lock.json in the root of the repo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Web stuff LGTM.
Still needs a clean up but we can do that in another PR, this one is getting way too big.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, except the small part on storing used plugins with work parameters. maybe fix that, then good to merge
Hmm, seems like the merge of |
f7daea2
to
cbc914c
Compare
I reverted it, will try rebase, to fix conflicts |
30d3d42
to
cbc914c
Compare
❌ pre-commit failed. |
- fixed conflicts with frontend part of the app
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Server/worker stuff LGTM with latest changes!
# the plugins Hi, this is my first PR here, but I was somewhat active on other fronts of OA development. This pr will bring some basic plugin functionality to the Open Assistant, and as discussed with @yk @andreaskoepf there are quite a few directions for something like this to be integrated with OA, but this should serve a purpose as some initial proof-of-concept and exploratory feature for 3rd party integrations with OA. I also included a small **calculator** plugin as a possible candidate for the OA internal plugin, which would be like the default one, for people to try out and also as an example, of how one could implement own plugins. If we decide to include this plugin, there should be added a deployment/hosting mechanism for it. I will push a separate branch in the next couple of days, that will serve as an alternative to the approach, so we can A/B test it along with the new models (SFT-s/RLHF-s) I also tried to comment on every weird quirk or decision in code, so one could easily understand, and change it, but there are quite a few places, where a simple new line char or like " char in specific strings, could affect LLM performance in the plugin usage scenario. Will also try to push some documentation regarding plugin development, but there are already some useful comments in **calculator** plugin on what should be paid attention to. Here are some of the current UI changes introduced with this PR. <details> <summary>Plugin chooser component</summary> <img width="854" alt="Screenshot 2023-04-20 at 00 55 38" src="https://user-images.githubusercontent.com/13547364/233217078-d2e4e28f-36eb-451e-a655-1679188aed52.png"> </details> <details> <summary>Plugin execution details component</summary> <img width="824" alt="Screenshot 2023-04-19 at 21 40 38" src="https://user-images.githubusercontent.com/13547364/233216884-e69bcf9c-707f-43de-a52d-41db5d92c504.png"> <img width="744" alt="Screenshot 2023-04-19 at 21 40 56" src="https://user-images.githubusercontent.com/13547364/233217161-c114f5b9-881f-4476-a2b1-459179a9353e.png"> <img width="545" alt="Screenshot 2023-04-19 at 21 30 18" src="https://user-images.githubusercontent.com/13547364/233217187-17fb87e5-e4be-43e4-96ac-7cdd84223147.png"> </details> <details open> <summary>Plugin assisted answer</summary> <img width="837" alt="Screenshot 2023-04-19 at 21 29 52" src="https://user-images.githubusercontent.com/13547364/233217260-4986f456-efa5-47a5-aabc-926a8a5a9a2f.png"> <img width="943" alt="Screenshot 2023-04-21 at 18 28 45" src="https://user-images.githubusercontent.com/13547364/233687877-0d0f9ffb-b16a-48de-96ad-e4c3a02f4c66.png"> </details> <details> <summary>Verified plugin usage UI look</summary> <img width="864" alt="Screenshot 2023-04-20 at 15 08 36" src="https://user-images.githubusercontent.com/13547364/233376402-52ed5a3d-631a-4350-9130-61548a8d7b02.png"> </details> <details> <summary>Some plugin usage examples</summary> <img width="1048" alt="Screenshot 2023-04-18 at 01 57 33" src="https://user-images.githubusercontent.com/13547364/233217685-79b262bd-81fd-4641-9ad9-110e8b689e42.png"> <img width="993" alt="Screenshot 2023-04-17 at 23 17 35" src="https://user-images.githubusercontent.com/13547364/233217687-561773a1-b16a-49f5-bdbc-f30b46bed33d.png"> </details> <details open> <summary>Mixed usage example where model chooses not to use plugin on its own</summary> <img width="690" alt="Screenshot 2023-04-20 at 21 31 46" src="https://user-images.githubusercontent.com/13547364/233469420-25c72893-7c7a-426c-9f4b-ce9144d643ae.png"> </details> --------- Co-authored-by: agi <you@example.com> Co-authored-by: Yannic Kilcher <yk@users.noreply.github.com> Co-authored-by: Oliver Stanley <olivergestanley@gmail.com>
the plugins
Hi, this is my first PR here, but I was somewhat active on other fronts of OA development.
This pr will bring some basic plugin functionality to the Open Assistant, and as discussed with @yk @andreaskoepf
there are quite a few directions for something like this to be integrated with OA, but this should serve a purpose as some initial proof-of-concept and exploratory feature for 3rd party integrations with OA.
I also included a small calculator plugin as a possible candidate for the OA internal plugin, which would be like the default one, for people to try out and also as an example, of how one could implement own plugins.
If we decide to include this plugin, there should be added a deployment/hosting mechanism for it.
I will push a separate branch in the next couple of days, that will serve as an alternative to the approach, so we can A/B test it along with the new models (SFT-s/RLHF-s)
I also tried to comment on every weird quirk or decision in code, so one could easily understand, and change it, but there are quite a few places, where a simple new line char or like " char in specific strings, could affect LLM performance in the plugin usage scenario.
Will also try to push some documentation regarding plugin development, but there are already some useful comments in calculator plugin on what should be paid attention to.
Here are some of the current UI changes introduced with this PR.
Plugin chooser component
Plugin execution details component
Plugin assisted answer
Verified plugin usage UI look
Some plugin usage examples
Mixed usage example where model chooses not to use plugin on its own