Open Wildshire opened 11 months ago
Hey @Wildshire! Thanks for the detailed post. I'll need to look at this in more detail, but wanted to drop a quick note. Some parameters can't be passed to actions running on the action server e.g. LLM/LLMTaskManager. This is because they are instances which exist in the main guardrails process. The actions server is meant for actions that are more self contained. So, actions that need those parameters need to be registered as system actions in the main process.
Hello @drazvan
First thanks a lot for the response. I was wondering if you had any news on this topic (perhaps with the new release).
Best
Thanks for the ping @Wildshire ! Still wrapping up the last pieces for the 0.6.0
release. As soon as that's done, I'll have a look at this as well.
Hello
First of all, congrats on developing this tool. I have been playing with NeMo for a while and I have a few questions / issues related with the
actions_server
when deployed to separately execute theactions
there. First I am going to share my set up:launch_server.py
action_server.py
-> Your action server.For the sake of simplicity, all actions on the
actions
folder DO NOT perform any operationsexample:
output_moderation.py
I will explain later why I added the
config
andevents
keywords.trial.py
-> Load railing configuration and perform generations. Note: I have added multiple policies at the same time, without action server, behaviour works as expected (except with hallucination_check as you have mentioned in the repo, WIP to make it work, although that's another issue to be discussed another time).In a nutshell: idea is to perform
jailbreak_check
before interacting with the LLM, then when bot responds, dohallucination_check
,output_moderation
andblock_list
. Order of these last 3 does not matter for now.Action server is defined in
YAML
configurationHere is the code
So, when I launch the
trial.py
script I have encountered these issues: 1) Apparently, even though actions are perfectly loaded into the server when launched, theActions_Dispatcher
inside theapp
created ontrial.py
needs to register such actions (I register them asdummy
functions on thepatch
intrial.py
). I think this is because of this (Just realized editing this that you have the TODO tag in the line above). With that taken care of, then we can execute this part. I want to know if this workaround is okay or if I forgot to include something somewhere else. 2) When actions are executed in the actions server here, I had issues getting theLLMTaskManager
,context
and thellm
to the server. I saw that you had a #TODO tag here if to pass thosekwargs
to the actions server. I managed to make it work with something like between L283-284 :In the
actions
then I decode the objects so I can use them as expected:If actions are programmed as they should, then the action is performed and status is returned to be okay with response. My question is if of course this patch would be viable or if it has flaws.
3) And speaking about flaws I encountered my roadblock that triggered this issue here. Let's say I perform this generation on
trial.py
:I get this logs (ending):
action_server logs:
So what's the issue? With this set up, hallucination_check returns
False
. Still, thebot inform answer prone to hallucination
is chosen as the next step. My hunch is that due to having theaction_server
,events
or even theconfig
(I think not but just in case I mention it), are not properly updated when the action is returned from the server. I have checked the returned events from the actions server and they are mostlyNone
. Trying to debug it I reached this line of code and stoped. No matter what is returned, the event belowhallucination_check
is used as the next event. For example, if I put on the colang files everything withcontinue
(if $allowed: continue), behaviour is as expected but no guardrails :( . Here is my trace so far (og version, I added custom logging places trying to debug this):I also want to ask about clarification in if adding the
@action(is_system_action=True)
decorator is mandatory in this set up. This is because of thisif
.Also, perhaps as I am adding too many policies other type of bugs might arise. Still, when not using the server, I managed to create a very nice complex guardrails with multiple policies at the same time.
Sorry for the length of the post. This is actually my first issue post so, if there is anything needed to solve this issue or simplify it to tackle each one of themn separetely I will gladly contact you guys.