Pydantic Support
In 0.1.x, Guardrails supported pydantic models with aregister_pydantic decorator. This decorator has been removed in 0.2.x and replaced with the Guard.from_pydantic method. This method takes in a pydantic model and returns a Guard instance that can be used to validate the model.
To migrate from the register_pydantic decorator to the Guard.from_pydantic method, instantiate the model outside of the decorator and pass it into the Guard.from_pydantic method. If you wish to continue using validators defined on the model with Guardrails, you must define them separately and register them with the register_validator decorator.
For example, see the following example migration from a 0.1.x-style rail spec defines a model with the register_pydantic decorator to a 0.2.x-style Guard constructed from a pydantic model:
- 0.1x
- 0.2x
Choice
In 0.1.x, thechoice tag was defined in the following way, and its output placed a choice discriminator on the top level, with another element whose key is the value of the choice, containing the case output:
- 0.1x spec
- 0.1x output
choice tag follows the OpenAPI discriminated union pattern, wherein its output is a single object with a discriminator field nested inside the generated object:
- 0.2x rail spec
- 0.2x pydantic guard
- 0.2x output
choice tag now has a discriminator attribute, which is the name of the field that will be used to determine which case is used. This field is required, and must be a string. Also, the inside of the case tag is implicitly wrapped in an object, so the flight case is no longer wrapped in an object tag.
Changes To Validators
Previously, Validators had avalidate method that accepted the key, value, and entire schema to validate a specific property on that schema. It was also expected to return the full schema after performing validation. In 0.2.x this has been simplified. Now Validator.validate need only accept the value for the property being validated and any metdata necessary for the validation to run. Also rather than returning the schema, validate methods should return a ValidationResult. See the below example to see these differences in practice.
- 0.1x
- 0.2x
Removal Of Script Support
With additional first class support for Pydantic models as described above, support for custom code via the<script> tag is being dropped.
If you were using scripts to make runtime changes to your output schemas, you can simply move this logic to your own code and format it accordingly:
- 0.1x
- 0.2x
__call__ or parse:
- 0.1x
- 0.2x
@register_validator in your own code as shown above in the Pydantic Support section. Custom validators registered in your own code will be picked up by Guardrails when you execute the Guard via __call__ or parse.
String Formatting In Prompts
Previously Guardrails usedf-string’s and str.format to include prompt variables, prompt primitives, and other partials in the prompt sent to the LLM. This necessitated any braces, aka curly brackets, to be escaped with additional braces to prevent its contents from being considered as variable that should be substituted during string formatting.
We now use Template.safe_substitute to avoid this issue completely. This does, however, require a change to how variables are expressed in string arguments such as prompts and instructions. Now instead of expressing a variable for the prompt as {{my_var}}, it should be expressed as ${my_var}.
In addition to this change in variable syntax, we have also started namespacing our prompt primitives. Whereas before you would use one of our built in primitives like so: @complete_json_suffix_v2, they should now be specified as ${gr.complete_json_suffix_v2}.
To highlight these changes in practice, below is the prompt section of a RAIL spec where each tab shows the respective before and after format.
- 0.1x
- 0.2x
Replacing The Old Format With The New
String Variables
To easily find usage of the old format of string variables (i.e.{document} or {{output_schema}}) in your code, you can utilize the below regex:
Find
([{]+)([^}"']*)([}]+)
Replace
${$2}
Prompt Primitives
To easily find usage of the old format of prompt primitives (i.e.@json_suffix_prompt) in your code, you can utilize the below regex:
Find
(^[@])(\w+)
Replace
${gr.$2}
Using Guardrails With LangChain
The changes to string format also effect the Guardrails AI integration with LangChain. Since LangChain supportsf-string’s and jinja2 for templating, and the GuardrailsOutputParser opts for the f-string option, any braces in the prompt must be escaped before instantiating the LangChain PromptTemplate. To make this easy, we added an escape method on our prompt class to handle this for you; you simply need to invoke it when passing the prompt to PromptTemplate like so: