Guard object serves as the central interface for guardrails.
AI framework.
When initialized, its seeds with a rail specification that outlines the rules and standards the AI's
output must meet.
The guard object is employed to operate the guardrails.
AI engine.
Managing the input prompts, wrapping around LLM calls, and maintaining a log of call history for reference
and analysis.
With this context in mind, let's delve into the flow of using a guard for output validation.
The first step will be creating a guard object.
You can start by defining the output to validate.
There are three options that can be chosen based on the requirements rail specification or using a Pydantic
model for data validation or a simple string validation.
The next step would be preparing the lm callable function with the necessary prompt and instruction
that needs to be validated.
Finally, after selecting the output type prompts an instruction that needs to be validated.
Initialize the guard with the relevant specifications.
Once the guard object is initialized, the next step would be invoking the guard object.
This step involves the guard performing following actions.
Here, the guard calls the large language model API with the provided prompts and instructions.
The LM processes the request and returns the output.
The guard validates Lmm's output against the chosen
Simultaneously, details of the operations are logged for record keeping and potential debugging.
The outcome of validation could be valid or invalid if the output is valid.
It's ready for use if the output is not valid.
The guard checks a specified on fail action, which can be one of the following.
Risk in which the guard object requests the LM to generate the output again, or filter or fix, which
means automatically correct the output.
Refrain or to not perform any operation or no OP, that means no operation.
Likely similar to refrain indicating no action will be taken.
Finally, depending on the validation On and on.
Fail actions.
The resulting output is returned.
Guard framework includes two essential flows calling and validating, with built in mechanisms for error
handling and retries.
Creating a resilient I application process.
Let's look at the call flow.
The first step in leveraging the guardrails I is to wrap your LLM with guardrails.
Validating its output against a Rel specification.
This is done by instantiating a guard and calling it with your desired LLM function.
This method returns a tuple containing both the raw output from the LLM and validated output.
Ensuring you have the data you need in both in its original Format and the refined format.
This approach ensures that every call to your LLM is screened through guardrails.
Validating the output in real time and ensuring it adheres to your standards.
The second flow is validate flow.
For scenarios where you prefer direct control over the LLM, or wish to apply guardrails as a Post-processor.
Guard validate offers a flexible solution.
It applies the rail specification to the Llms output.
After the fact.
You can even specify the number of risks, allowing guardrails to automatically adjust queries to LLM
for better output, or set it to zero to keep it purely as a validation step.
The guard object gracefully handles the errors, so understanding that errors are part of any API interaction.
Guardrails has implemented a robust error handling and retry mechanism when.
Encountering errors like API connection error.
API error.
Try again.
Timeout rate limit error or service unavailable error.
Guardrails automatically retries the request using exponential backoff.
This process continues until a maximum wait time is reached, ensuring that temporary issues don't halt
your application's functionality.
In cases where an error falls outside of the predefined retrieval errors, guardrails raises an exception
designed to aid in troubleshooting.
This ensures that developers are informed of the root cause.
Facilitating a quicker resolution to any issues encountered.