> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Handling Errors Troubleshooting and Edge Cases Part 3
> Guidance for handling Bedrock safety blocks, reducing hallucinations, validating outputs, improving observability, and operationalizing model integrations for production
This guide shows patterns to handle safety responses, reduce hallucinations, validate model outputs, and improve observability when calling Amazon Bedrock (for example via an `InvokeModel` or `Converse` call). It preserves the original diagrams and shows practical code examples and operational guidance so you can move from prototype to production-ready AI systems.
Best practice: treat model responses as untrusted inputs. Validate outputs, emit metrics for observability, and avoid logging sensitive user data directly. Use redaction or hashing if you must persist prompts for diagnostics.
## Detecting safety blocks (guardrails)
When Bedrock's safety/guardrail checks block a request, the response will indicate that the request was blocked. Your application should detect this and handle it gracefully—both for user experience and observability.
Example: a robust Python handler that detects a block, logs for diagnostics (without raw PII), and returns a concise user-facing message:
```python theme={null}
import logging
logger = logging.getLogger(__name__)
def handle_bedrock_response(response, prompt=None):
"""
Handle a Bedrock response that may include a safety/block indicator.
Args:
response (dict): The response returned by Bedrock (InvokeModel or Converse).
prompt (str, optional): The user prompt sent to Bedrock (used for logging).
Returns:
str: A safe message for the end user, or the model output.
"""
# Example: check for a blocked / safety response
if response.get("blocked", False):
# Log for monitoring/troubleshooting — avoid logging raw PII in production!
logger.warning("Guardrail triggered for prompt: %s", prompt or "")
# Return a concise, non-specific message to the end user
return "Sorry, I can't help with that request. Please try rephrasing."
# Normal flow: return the model's output (adjust key to match your integration)
return response.get("output")
```
What to do when a response is blocked:
* Return a concise, non-specific message to the user (avoid exposing guardrail internals).
* Log the event with enough context for diagnostics, but do not persist raw prompts or PII in plain text.
* Emit metrics so you can monitor guardrail frequency by route, user population, or department — this helps triage and policy tuning.
Avoid logging raw prompts or other sensitive user data to plain logs. Consider redaction, hashing, or other privacy-preserving strategies before writing prompts to logs or telemetry.
## Addressing hallucinations and improving grounding
Hallucinations often stem from insufficient or ambiguous context, or prompts that give the model too much freedom. Treat prompts as precise instructions: include relevant context, explicit constraints, and the expected output format. When appropriate, ask the model to supply evidence, citations, or a confidence statement to enable downstream verification.
### Key mitigation strategies
* Use Retrieval-Augmented Generation (RAG) to ground answers in your documents. When supplying retrieved chunks, instruct the model to rely primarily on those chunks rather than its pre-trained knowledge.
* Require explicit fallback behavior: ask the model to say "I don't know" if it cannot verify the answer.
* Ask for source citations and display provenance and confidence where useful.
* Validate output formats (for example, ensure returned JSON is valid and conforms to your schema).
* Always sanitize and validate model outputs before use in downstream systems.
You can summarize recommended mitigations in a quick reference table:
| Strategy | When to use | Example / Notes |
| -: | - | - |
| RAG (grounding) | Factual Q\&A, knowledge-bases | Retrieve top-k document chunks and include them in prompt; instruct model to cite the chunk id. |
| Explicit fallback | When correctness matters | Prompt: "If you cannot verify, respond `I don't know`." |
| Output schema validation | Structured responses (JSON, CSV) | Validate with `jsonschema` or another validator before using the response. |
| Citation & provenance | Auditability & UX | Ask model to include source links or chunk IDs with each claim. |
| Sanitize & filter | Security-sensitive outputs | Escape/encode inputs for downstream usage (SQL, shell, HTML). |
### Example: validate JSON output against a schema (Python)
```python theme={null}
import json
from jsonschema import validate, ValidationError
schema = {
"type": "object",
"properties": {
"name": {"type": "string"},
"age": {"type": "integer"}
},
"required": ["name", "age"]
}
def validate_model_json(output_text: str):
try:
data = json.loads(output_text)
except json.JSONDecodeError:
raise ValueError("Model did not return valid JSON")
try:
validate(instance=data, schema=schema)
except ValidationError as e:
raise ValueError(f"JSON schema validation failed: {e.message}")
return data
```
## Observability, monitoring, and resilience
Operationalizing a model-backed service requires instrumentation and resilient client-side logic.
Instrumentation checklist:
* Emit metrics: prompt size, response size, latency, success/error counts, guardrail triggers, retrieved chunk counts (RAG), and throttling/backoff events.
* Track retrieved chunk counts to understand context size vs. latency and token usage.
* Log structured events for guardrail triggers with anonymized/hashed context for triage.
* Implement retries with exponential backoff for transient errors; detect and surface throttling (rate limit) responses so clients can back off elegantly.
Resilience patterns:
* Circuit breakers or client-side rate limiting for protecting downstream services.
* Timeouts and safe defaults for partial or malformed responses.
* Health checks and synthetic tests to validate end-to-end retrieval + generation pipelines.
## Putting it together
When you measure and monitor the signals above, you can iterate on prompt design, retrieval quality, and mitigation policies. That improves reliability and user experience, reduces operational risks, and helps you gain trust across stakeholders.
## Summary
Failures are a normal part of GenAI applications: safety blocks, API failures, throttling, malformed outputs, and hallucinations will occur. Build systems that:
* Detect and handle guardrail blocks gracefully.
* Validate and sanitize model outputs before they reach downstream systems.
* Emit metrics and logs (with privacy-preserving practices) for monitoring and triage.
* Use retries/backoff for transient failures and surface meaningful messages to users.
These practices help you move from prototype to production-ready AI applications with greater reliability and trust.
## Links and references
* [Amazon Bedrock documentation](https://docs.aws.amazon.com/bedrock/)
* jsonschema (Python): [https://pypi.org/project/jsonschema/](https://pypi.org/project/jsonschema/)
* Observability patterns for distributed systems: [https://martinfowler.com/articles/monitoring.html](https://martinfowler.com/articles/monitoring.html)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.