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.

Deepchecks' Built-in Properties

Grounded in Context

When it comes to generative AI one of the most concerning problems is Hallucinations. In order to avoid this kind of mistake we would want to make sure that all factual claims by our LLM are entailed by trusted sources of truth, in most cases, documentation about the relevant topic.

The Grounded in Context Score is a measure of how well the LLM output is grounded in the provided context (a concatenation of the input, information retrieval, full prompt and chat history), ranging from 0 (not grounded) to 1 (fully grounded). Specifically, this property separately validates that each factual statement in the output is entailed by the provided context.

A single significant ungrounded detail in the output is often enough to result in a low score.

Examples

Explainability Highlighting

In the Data Screen, you can click on a property while viewing an interaction to see all ungrounded statements in the output:

Handling Low Grounded in Context Scores

A low Grounded in Context score can result from application design issues or data modeling problems within Deepchecks. Below are several common mitigation strategies:

1. Prompting - When using an external data source, ensure the model relies on it rather than its internal knowledge, which may be outdated or inaccurate. Clearly instruct the LLM to base its answer strictly on the provided information and to refrain from responding if the necessary information is missing.
2. Model Choice - If improving prompting does not resolve the issue, the model itself may struggle with instruction adherence. Consider upgrading to a model that is better at following complex instructions.

👍

Ensuring Complete Context for Grounding Evaluation

• The Grounding Evaluation assesses all factual elements of the output and verifies that they are supported by the available data fields: Full Prompt, Input, Information Retrieval, and History. If any crucial information is missing from the system, it will likely result in a low Grounded in Context score.
• For example, if only the Input and Information Retrieval are provided, but the Prompt (which was not uploaded to Deepchecks) includes an instruction to append references to additional resources, the Grounding Evaluation may classify these references as hallucinations.

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

Retrieval Relevance

The Retrieval Relevance property is way of measuring the quality of the Information Retrieval (IR) performed as part of a RAG pipeline. Specifically, it measures the relevancy of a retrieved document to the user input, with a score ranging from 0 (not relevant) to 1 (very relevant).

The property calculation is based on several models and steps. In the first step the retrieved document is divided into meaningful chunks, then each chunk's relevance is evaluated using both a semantic evaluator and a lexical evaluator. In the final step the scores per chunk are aggregated into a final score.

Explainability Highlighting

In the Data Screen, you can click on a property while viewing an interaction to see the most relevant paragraphs in the retrieved documents:

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 Data Screen, you can click on a property while viewing an interaction to see the sentences in the outputs that received the lowest scores:

Avoided Answer

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.

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

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.

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

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. 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.

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.

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

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).

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.

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

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

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.