Safety & Risk Properties

These properties answer the question: is something going wrong? They detect harmful inputs, sensitive data leaking into outputs, the model refusing to respond, and technical failures - the issues that need to be caught before they reach your users.

---

Input Safety

The Input Safety property assesses the potential risks associated with input data. Scored from 0 to 1, it quantifies the likelihood that an input is safe to process without introducing harmful or manipulative content. It uses a Deepchecks-built classification model to identify security threats including jailbreak attempts, illegitimate requests, and prompt manipulation techniques.

Examples

---

PII Risk

The PII Risk property indicates the presence of Personally Identifiable Information (PII) in the output text. This property ranges from 0 to 1, where 0 signifies no risk and 1 indicates high risk. It uses a trained Named Entity Recognition model to identify risky entities.

Risky entities

Examples

---

Toxicity

The Toxicity property measures how harmful or offensive a text is. It uses a RoBERTa model trained on the Jigsaw Toxic Comment Classification Challenge datasets, producing scores from 0 (not toxic) to 1 (very toxic).

Examples

---

Avoidance

The Avoidance property categorizes whether an LLM explicitly avoided answering a question, without providing other information or asking for clarifications.

Categories

Examples

Handling non-valid avoidance

Desirable avoidance - Before addressing avoidance cases, assess whether the avoidance was actually desirable:

• RAG use case - You may want the LLM to avoid answering when no relevant context is retrieved. In this case, the issue is likely poor retrieval quality, not the model itself. Use Deepchecks' RAG properties to monitor retrieval.
• Alignment-based avoidance - Avoidance is expected when inputs conflict with the model's alignment (requests for harmful content, jailbreak attempts). Use Input Safety and Toxicity properties to track these cases.

Undesirable avoidance - When the model is expected to respond but mistakenly refuses:

• Domain mismatch - Update the system prompt to explicitly include the domains the model should cover.
• Technical error avoidance - If avoidance is caused by backend failures or timeouts, investigate system logs to fix the underlying issue.

---

Error Detection

The Error Detection property classifies whether an LLM interaction's output is a valid response, a system/tool/API error, or empty. Unlike Avoidance, which detects when the model chooses not to answer, Error Detection identifies cases where the system failed to produce a response due to technical issues.

This property uses LLM calls for calculation.

Categories

Examples

Handling errors and empty outputs

1. Error outputs - Investigate the underlying technical failure: check connectivity, API keys/quotas, data formats, and system logs.
2. Empty outputs - May indicate silent pipeline failures. Verify the LLM call completed and the response was captured correctly.