In this session, we are exploring how to extend guardrails capabilities with custom validators.
Our goal is to create a secure environment that automatically identifies and handles personally identifiable
information within our data, ensuring privacy and compliance.
We begin by importing the necessary modules, including Ari, for regex operations.
Validator and other related functions from guardrails for custom validation logic.
In the context of guardrails, framework validation result, pass result, and failed result are pivotal
components that determine how inputs are assessed against specified validation rules.
These components play a crucial role in custom validators.
Validation result act as a base class for the outcome of validation attempts.
It encapsulates the result of applying a validator to a given piece of data, serving as a foundation
for a more specific result types such as pass result and failed result.
Pass result is a subclass of validation result that signifies a successful validation.
When a pass result is returned by a validator, it indicates that the input data has met the validation
criteria set by the validator and doesn't violate any of the rules.
Conversely, failed result also extends validation result, but represents a failure in meeting the
validation criteria.
A failed result contains additional information, such as an error message detailing why the validation
failed.
This outcome is particularly useful for identifying inputs that contain errors, breach of policy,
or, in our specific case, PII that shouldn't be disclosed.
Next, we are defining a custom validator called Mi Filter.
It leverages regular expression to identify patterns indicative of sensitive information, such as social
security number.
Taxpayer identification number, credit card numbers, and phone numbers.
These patents cover a range of formats, acknowledging the diverse ways such information can be represented.
The heart of PII filter lies in its validate method.
Where the defined regex PRG is applied to the input value.
If a match is found indicating the presence of PII.
A failed result is written along with an error message highlighting the issue.
If no PII is detected, a pass result is returned affirming the Input's compliance with privacy standards.
Next, as we have defined the PII filter, we integrate our system and custom validator into a Pyramidic
model text.
This model serves to analyze text using our PII filter to flag any PII content.
Demonstrating the seamless integration of custom validators in data processing workflows.
With our validator and model in place, we define the prompt that needs to be passed to the LLM as an
input.
So here as you can see, this prompt defines the analyze the text for personal identifiable information.
And.
it has the text input field from text analysis.
Now that we have defined the necessary input field objects, we will define the guard object that will
enforce our custom PII detection rules on text inputs using a predefined prompt to guide the analysis.
And then we are validating a simple text for PII.
As you can see here, we are passing this dynamic text in the prompt which has a social security number
defined into it and the information with the Parameters and the model maximum token and temperature
is passed to OpenAI for execution.
The guard object basically wraps the entire call to LM, and then validates the output and takes necessary
actions as defined here.
In this case, as.
The prompt has defined an SSN, and if the same assertion.
If the SSN is also present in the output generated by LM, the pi filter should fail.
And.
It should throw an exception based on our validation criteria.
Let's run this example.
And Check the output.
As you can see, the validation failed for filled with errors because the test contains PII.
Now if I just mask this information and run the program again.
The validator should move the control to pass result.
As you can see here.
This is the prompt that the guardrail AI framework has prepared along
With the output object, wherein we define the description and the format to be executed.
The filtered or validator to be executed.
This is our input text, and the raw LLM output contains the information of shown with masked social
security number and hence the output validated is passed.
There is no exception here.
So the custom validators like my PII filter or any other filter for that matter, we define.
Shows us how we can make rules that check our data just the way we need.
It helps us keeping our data safe and meets specific requirements, making sure everything is in order.