Using Guardrails to Screen Outputs
You can use Patronus evaluations after the fact to check how your system performed. But you can also use Patronus evaluations in real-time to impact the flow of a chatbot. For instance if you catch a failure you can decide not to respond to a user's original question and send a canned response instead. This cookbook will show you how to use task chaining to impact the final output. You can also do this with single evaluate() calls for an API-driven experience.
Setup
First, make sure you have installed the required dependencies:
Set environment variables:
Define Evaluation Metrics
For our chatbot, we will consider the following three evaluation criteria:
- patronus:is-helpful: Checks if the chatbot output is a helpful response that addresses the user's query.
- patronus:no-openai-reference: Checks if the chatbot output does not mention it is an OpenAI LLM.
- does-not-contain-code: Checks if the output is free of code. This one needs to be defined by the user as a custom criteria.
Create Chain
By creating a chain we can inspect the results of previous tasks before outputting a final response to the user. This works for experiments by the same dependencies can be coded up using single API calls to the Patronus evaluate() endpoint.
Step 1: Route the initial user request to OpenAI for an answer.
Step 2: Check if the answer passes all the evaluators that we have set up.
Step 3: If all evaluators pass, return the OpenAI response. If one of the evaluators fails, choose the appropriate canned response.
Example Script
We get the following output with some print statements mixed in:
Notice that the 4th example (80% completion rate) gets a response back from OpenAI with code. We do not want to return any code to our customers. The code check catches that and provides the canned response saying that code is not safe to return. Our code guardrail worked well in this situation and saved us from returning undesired responses to our users.