What are Built-in Properties?

The Deepchecks platform includes a comprehensive collection of proprietary models of various types, built for enabling an accurate, nuanced, and scalable evaluation pipeline. They employ various techniques, and have undergone rigorous benchmarking on real-world data, showcasing superior performance relative to well-known alternatives, including the use of LLMs as a judge.

A few examples for these techniques are Avoided Answer which is a classification model trained on curated data, and Grounded in Context for hallucination detection, which utilizes a complex multi-step, multi-model approach, using Small Language Models (and no LLM API usage required, nor any additional costs). Check out the various Built-in Properties for more details about each.

Properties Explainability

Many properties feature explainability upon click that offer insights about the assigned scores.

🗄️ Retrieval Use-Case Properties

Explore the specialized properties for evaluating the retrieval step in a RAG pipeline, crucial for shaping output quality. For a detailed guide on document classification and retrieval properties, click here.

🤖 Agent Evaluation Use-Case Properties

Dive into the key properties used to assess agent performance across dynamic tasks and interactions. For an in-depth look at agent evaluation and its core properties, click here.

Relevance & Accuracy Properties

Relevance

The Relevance property is a measure of how relevant the LLM output is to the input given to it, ranging from 0 (not relevant) to 1 (very relevant). It is useful mainly for evaluating use-cases such as Question Answering, where the LLM is expected to answer given questions.

The property is calculated by passing the user input and the LLM output to a model trained on the GLUE QNLI dataset. Unlike the Grounded in Context property, which compares the LLM output to the provided context, the Relevance property compares the LLM output to the user input given to the LLM.

Examples

Expected Output Similarity

The “Expected Output Similarity” metric assesses the similarity of a generated output to a reference output, providing a direct evaluation of its accuracy against a ground truth. This metric, scored from 1 to 5, determines whether the generated output includes the main arguments of the reference output.

To accomplish this, several large language model (LLM) judges break both the generated and reference outputs into self-contained propositions, evaluating the precision and recall of the generated content. The judges' evaluations are then aggregated into a unified score.

This property is evaluated only if an expected_output is supplied, offering an additional metric alongside Deepchecks’ intrinsic evaluation to assess output quality.

This property uses LLM calls for calculation

Handling Low Expected Output Similarity Scores

Low Expected Output Similarity scores indicate minimal overlap between generated outputs and reference ground truth outputs. Consider these possibilities and solutions:

1. Multiple Valid Solutions - Especially for Generation tasks, various outputs may correctly fulfill the instructions. Evaluate whether strict adherence to reference outputs is necessary.
2. Alignment Techniques:
   1. Prompt Adjustment - Identify pattern differences between generated and reference outputs, then modify prompts to guide the model toward reference-like responses. Use Deepchecks Version Comparison features to iteratively refine prompts and converge toward the reference distribution.
   2. In-Context Learning - Provide the model with example input-output pairs to demonstrate expected behavior patterns. This approach, also known as Few-Shot Prompting, helps the model generalize to new cases.
   3. Training - Consider this more resource-intensive option only when other approaches prove insufficient. With adequate annotated data, create separate training and evaluation datasets to fine-tune a model and measure improvement. Such a solution requires you work with either an open-source or a closed-source platforms with fine-tuning capabilities (GPT-4o for instance).

Examples

Completeness

The Completeness property evaluates whether the output fully addresses all components of the original request, providing a comprehensive solution. An output is considered complete if it eliminates the need for follow-up questions, effectively solving the initial request in its entirety. Scoring for this property ranges from 1 to 5, with 1 indicating low completeness and 5 indicating a thorough and comprehensive response.

This property uses LLM calls for calculation

Intent Fulfillment

The Intent Fulfillment property is closely related to Completeness, but is specifically designed for multi-turn settings, like chat. Like Completeness, it evaluates how accurately the output follows the instructions provided by the user. However, Intent Fulfillment also reviews the entire conversation history to identify any previous user instructions that remain relevant to the current turn.

Scoring ranges from 1 to 5, with 1 indicating low adherence to user instructions and 5 representing precise and thorough fulfillment. A high score reflects a response that fully satisfies - or at least addresses - each and every relevant user requests.

This property is calculated using LLM calls.

Handling Low Completeness Scores

Mitigating Completeness failures is a very similar task to attending problems in Instruction Fulfillment. We recommend using the suggested strategies above, starting with Prompting and escalating to Model Choice if needed.

Instruction Fulfillment

The Instruction Fulfillment property assesses how accurately the output adheres to the specified instructions or requirements in the input. An output is deemed successful in this regard if it precisely and comprehensively follows the given directions. Specifically, the Instruction Fulfillment property serves as a valuable metric for evaluating how effectively an AI assistant follows system instructions in multi-turn scenarios, such as those encountered by a tool-using chatbot.

Scoring ranges from 1 to 5, where 1 indicates a low adherence to instructions, and 5 signifies a precise and thorough alignment with the provided guidelines. A high score reflects a response that fully meets the expectations and eliminates ambiguity regarding the requirement fulfillment.

This property uses LLM calls for calculation

Handling Low Instruction Fulfillment Scores

Low Instruction Fulfillment scores often result from application design and architectural choices. Below are some common mitigation strategies:

1. Prompting
   1. Simplicity – LLMs perform better when complex tasks are broken down by a human or another LLM acting as a planner. Defining a series of simpler tasks can significantly enhance the model's performance
   2. Explicitness – Ensure all instructions are explicitly stated. Avoid implicit requirements and clearly specify expectations.
2. Model Choice – Some models are better at instruction following than others, a capability evaluated in benchmarks such as LLMBar and InFoBench. Stay up to date with new benchmarks that assess instruction adherence, and experiment with different models to find a cost-effective solution for your use case.

Coverage

Coverage is a metric for evaluating how effectively a language model preserves essential information when generating summaries or condensed outputs. While the goal of summarization is to create shorter, more digestible content, maintaining the core information from the source material is paramount.

The Coverage Score quantifies how comprehensively an LLM's output captures the key topics in the input text, scored on a scale from 0 (low coverage) to 1 (high coverage). It is calculated by extracting main topics from the source text, identifying which of these elements are present in the output, and finally computing the ratio of preserved information to total essential information.

Therefore, a low score means that the summary covers a low ratio of the main topics in the input text.

This property uses LLM calls for calculation

Examples

Handling Low Coverage Scores

Low Coverage scores typically stem from application design and architectural choices. Below are some common mitigation strategies:

1. Prompting - Ideally, the issue arises from the LLM failing to identify and prioritize key information in the article. In this case, improving Coverage should not come at the expense of Conciseness. To address this, explicitly instruct the model to extract and summarize the most important details. If the problem persists, you may need to adjust the prompt to modify the balance between Coverage and Conciseness.
2. Model Choice - If there is still potential to improve Coverage without compromising Conciseness, consider experimenting with different models. Some models may be better suited for accurately identifying and summarizing key arguments while maintaining a well-balanced summary.

👍

Monitoring the Coverage / Conciseness Balance

• Deepchecks also provides a Conciseness property that can be used to ensure that new versions lead to acceptable changes in the overall Conciseness score.

Information Quality & Conciseness Properties

Information Density

In various LLM use-cases, such as text generation, question-answering, and summarization, it's crucial to assess whether the model's outputs actually convey information, and how concisely they do it. For instance, we'd want to measure how often our QA agent requests additional information or provides verbose or indirect answers.

An information-dense output typically consists of readable factual sentences, instructions, or suggestions (illustrated by the first two examples below). In contrast, low information-density is characterized by requests for additional information, incomprehensible text, or evasive responses (illustrated by the last two examples below).

The Information Density Score is a measure of how information-dense the LLM output is, ranging from 0 (low density) to 1 (high density). It is calculated by evaluating each statement in the output individually. These individual scores are then averaged, representing the overall information density of the output.

Examples

Explainability Highlighting

In the Interactions Screen, you can click on a property while viewing an interaction to see the sentences in the outputs that received the lowest scores:

Compression Ratio

The Compression Ratio property measures how much shorter is the output is compared to the input. It's calculated by dividing the size of the input by the size of the output.

Reading Ease

A score calculated based on the Flesch reading-ease, calculated for each text sample. The score typically ranges from 0 (very hard to read, requires intense concentration) to 100 (very easy to read) for English text, though in theory the score can range from -inf to 206.835 for arbitrary strings.

Fluency

The Fluency property is a score between 0 and 1 representing how “well” the input text is written, or how close it is to being a sample of fluent English text. A value of 0 represents very poorly written text, while 1 represents perfectly written English. The property uses a bert-based model, trained on a corpus containing examples for fluent and non-fluent samples.

Examples

Formality

The Formality model returns a measure of how formal the input text is. The model was trained to predict for English sentences, whether they are formal or informal, where a score of 0 represents very informal text, and a score of 1 very formal text. The model uses the roberta-base architecture, and was trained on GYAFC from Rao and Tetreault, 2018 and online formality corpus from Pavlick and Tetreault, 2016.

Examples

Sentiment

The sentiment, ranging from -1 to 1 measures the emotion expressed in a given text, as measured by the TextBlob sentiment analysis model.

Examples

Safety & Security Properties

Input Safety

The "Input Safety" property assesses the potential risks associated with input data, providing an evaluation of the input's security and integrity. Scored on a scale from 0 to 1, this metric quantifies the likelihood that an input is safe to process without introducing harmful or manipulative content. It employs a Deepchecks-built classification model to identify various types of security threats, including sophisticated jailbreak attempts, illegitimate requests, and complex 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. The property utilizes a trained Named Entity Recognition model to identify risky entities and multiplies the output confidence score by the risk factor. If multiple entities are found in the text, we take the highest score after multiplying it by the risk factor.

Risky Entities

Below is a list of the entities we examine during property calculation, along with the assigned risk factor for each entity.

Examples

Toxicity

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

Examples

Avoided Answer

this property has been deprecated, and replaced by 'Avoidance'

The Avoided Answer property calculates the probability (0 to 1) of how likely it is that the LLM explicitly, or “on purpose”, avoided answering the question or user request. The property will return high probabilities for answers in which the model is avoiding answering the question for some reason, says that it can’t answer or says it doesn’t know the answer.

We tested this property on the Do-Not-Answer dataset. We extracted 193 examples where the model provided answers (negatives) and 193 examples where the model avoided answering (positives). Our model achieved a ROC-AUC score of 0.99 on this dataset.

Examples

Handling High Avoided Answer Scores

1. Desirable Avoidance – Before addressing low Avoided Answer scores, it’s important to assess whether the avoidance was actually desirable. Consider the following scenarios:
   1. RAG Use Case – In retrieval-augmented generation (RAG), you may want the LLM to avoid answering questions if no relevant information is provided in the context, ensuring it relies primarily on external data sources. In such cases, the issue is likely due to missing context rather than the model itself. To address this, evaluate retrieval quality and the comprehensiveness of your external data sources. Deepchecks’ retrieval properties can help monitor such cases.
   2. Alignment-Based Avoidance – Avoidance is expected when an input conflicts with the model’s alignment, such as requests for private information, harmful content, or jailbreak attempts. Deepchecks’ safety properties (e.g., Input Safety, Toxicity, PII Risk) can help track and manage these scenarios.
2. Undesirable Avoidance – This occurs when the model is expected to respond but - misinterpreting the prompt or content - mistakenly decides it should not comply. To mitigate this, identify specific instructions or content that trigger such avoidances and adjust the prompt accordingly, explicitly defining the expected behavior.

Avoidance

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

Avoidance Categories

Avoided Answer - Missing Knowledge

The model refuses because it cannot find the necessary information within the provided context. This is common in Retrieval-Augmented Generation (RAG) systems where the model is restricted to specific data sources.

Avoided Answer - Policy

The model refuses because the request violates safety alignments, ethical standards, or internal operational policies (e.g., PII, toxicity, or hostile content).

Avoided Answer - Other

A generic refusal where the model declines to answer without explicitly citing missing context or a specific policy violation.

Error

The system failed to generate a text response due to a technical bug or code exception.

Valid

The model provided a response that addresses the prompt.

Note: This implies the model did not exclusively avoid the question. Even if the response contains some hesitation or partial avoidance, it is classified as "Valid" as long as it provides other information, clarifications, or a direct answer.

Examples

Handling non-valid Avoidance Categories

1. Desirable Avoidance – Before addressing avoidance cases, it’s important to assess whether the avoidance was actually desirable. Consider the following scenarios:
   1. RAG Use Case – In retrieval-augmented generation (RAG), you may want the LLM to avoid answering questions if no relevant information is provided in the context, ensuring it relies primarily on external data sources. In such cases, the issue is likely due to missing context rather than the model itself. To address this, evaluate retrieval quality and the comprehensiveness of your external data sources. Deepchecks’ retrieval properties can help monitor such cases.
   2. Alignment-Based Avoidance – Avoidance is expected when an input conflicts with the model’s alignment, such as requests for private information, harmful content, or jailbreak attempts. Deepchecks’ safety properties (e.g., Input Safety, Toxicity, PII Risk) can help track and manage these scenarios.
2. Undesirable Avoidance - examples and mitigations:

   1. Domain Mismatch (Outdated Scope)

      Scenario: The system prompt restricts the model to a specific topic (e.g., "only gardening"), causing it to refuse valid questions in newly added domains (e.g., "appliances").

      Mitigation: Update the system prompt to explicitly include the new domains.

   2. Technical Error Avoidance

      Scenario: The model provides a fallback refusal because of a backend failure, timeout, or retrieval error.

      Mitigation: Analyze system error logs to fix the underlying stability issue.

Output Type & Structure Properties

Content Type

The Content type property indicates the type of the output text. It can be 'json', 'sql' or 'other'.
The types 'json' or 'sql' means the output is valid, according to the indicated type.
'other' is any text that is not a valid 'json' nor 'sql'.

Invalid Links

The Invalid Links property represents the ratio of the number of links in the text that are invalid links, divided by the total number of links. A valid link is a link that returns a 200 OK HTML status when sent a HTTP HEAD request. For text without links, the property will always return 0 (all links valid).