How Weave guardrails work
Weave guardrails use inline Weave Scorers to assess the input from a user or the output from an LLM and adjust the LLM’s responses in real time. You can configure custom scorers or use built-in scorers to assess content for a variety of purposes. This guide demonstrates how to use both types of scorers as guardrails. If you want to passively score production traffic without modifying your application’s control flow, use monitors instead. Unlike monitors, guardrails require code changes because they affect your application’s control flow. However, every scorer result from guardrails is automatically stored in Weave’s database, so your guardrails also function as monitors without any extra configuration. You can analyze historical scorer results regardless of how they were originally used.The Weave TypeScript SDK does not support the tools required to set up guardrails.
Optimize your Weave guardrail performance
Because guardrails can interrupt your application’s control flow and change the course of its responses, they can negatively impact performance if they’re too complex. For optimal performance, we recommend:- Keeping guardrail logic simple and fast
- Caching common results
- Avoiding heavy external API calls
- Initializing guardrails outside of your main functions to avoid repeated initialization costs
- Your scorers load ML models
- You’re using local LLMs where latency is critical
- Your scorers maintain network connections
- You have high-traffic applications
Example: Create a guardrail using a built-in moderation scorer
The following example sends user prompts to OpenAI’s GPT-4o mini model. The model’s response is then passed to Weave’s OpenAI’s moderation API to assess whether the LLM’s response contains harmful or toxic content. The model’s response is passed to the guardrail function (generate_safe_response()) where uses the OpenAIModerationScorer to check the LLM’s original response. The function’s logic then checks OpenAI’s assessment response for a boolean in the passed field, which determines how the application responds.
{output} is accurate based on {ground_truth}.” See prompt variables for more information.
Example: Create a guardrail using a custom scorer
The following example creates a custom guardrail that detects personally identifiable information (PII) in LLM responses, such as email addresses, phone numbers, or social security numbers. This prevents sensitive information from being exposed in generated content. The function generate_safe_response applies the custom PIIDetectionScorer.Integrate Weave with AWS Bedrock Guardrails
TheBedrockGuardrailScorer uses AWS Bedrock Guardrails to detect and filter content based on configured policies.
Before setting up a Bedrock Guardrails integration, you need:
- An AWS account with Bedrock access
- A configured guardrail in the AWS Bedrock console
- The
boto3Python package
bedrock_runtime_kwargs parameter.
For an example of how to create a guardrail in AWS Bedrock, see the Bedrock guardrails notebook.
The following example checks text generation against AWS Bedrock Guardrails policies before returning results to users: