Defining the Evaluation Task
The EvalTask is the central configuration that defines what to evaluate and how to parse responses. It's the most important component to configure correctly as it determines the structure of your entire evaluation.
Overview
EvalTask supports two main evaluation scenarios:
- Judge LLM Responses: Evaluate responses from another LLM (prompt + response evaluation)
- Judge Text Content: Evaluate arbitrary text content (response-only evaluation)
Quick Setup
Arguments
Define columns (prompt_columns and response_columns)
Control which columns judges see during evaluation:
Template Variable System:
MetaEvaluator uses a template-based system where your prompt.md files can include placeholders like {column_name} that get automatically replaced with actual data. The available variables correspond to your prompt_columns and response_columns.
CSV Data:
Configuration:
Example prompt.md:
## Instructions:
Evaluate the LLM response for helpfulness.
## Context:
User Input: {user_input}
System Instruction: {system_instruction}
## Response to Evaluate:
{llm_output}
Formatted prompt given to Judge:
CSV Data:
Configuration:
Example prompt.md:
Formatted prompt given to Judge:
Task Schemas (task_schemas)
The task_schemas dictionary maps task names to their allowed outcomes:
Classification Tasks: Use a list of strings for predefined outcomes
- Minimum 2 outcomes required
- Judges must choose from these exact options
- Examples: sentiment, safety, relevance ratings
Free-form Tasks: Use None for open-ended responses
- No restrictions on judge responses
- Examples: explanations, detailed feedback
Add Free-form Tasks for Context and Explainability
Include explanation fields to understand judge reasoning:
Multi-label Tasks (pick several)
Some tasks require selecting several labels at once for a single field (e.g. a
response can be both hateful and insults). Wrap the outcomes in a
MultiLabelSchema to declare a multi-label task:
A multi-label task's value is a fixed-length ordered vector with one slot per
declared outcome. Each slot holds either that outcome's own name (selected) or the
reserved sentinel "FALSE" (not selected). For the example above, a response that is
hateful and sexual (but not insulting or violent) is stored as:
Key rules:
- Outcome order is load-bearing — it defines slot order and is preserved through serialization, judging, storage, and export.
outcomesmust contain at least 2 values, and the exact string"FALSE"is reserved (it marks a not-selected slot) and cannot be declared as an outcome.- "Nothing applies" is fully defined — an all-
"FALSE"vector, never an empty/missing value. - Answering methods: multi-label supports only
structuredandinstructor. Directanswering_method="xml"raises an error, and XML is excluded from the fallback sequence (its scalar-only path cannot carry the ordered vector). - In the annotation interface, a multi-label task renders as a checkbox group; the number-key shortcut toggles a slot instead of replacing the selection.
Scoring multi-label tasks (see the Scoring guide for details):
- Score with
ClassificationScorerviatask_strategy="single". The vector is binarized positionally (sloti→ 1 if it holds outcomei's name, else 0) into a per-slot indicator vector. - For F1, precision, and recall,
ClassificationScorer.averagemust be"macro"(per-label, recommended) or"samples"(per-item overlap). The global default"binary"is rejected. Accuracy ignoresaverageand works with its default."macro"is required for a mixed single-class + multi-labelmultitaskconfiguration using an averaged metric. AltTestScorerscores the native name vector unchanged (routes to jaccard).CohensKappaScorerdoes not support multi-label tasks and raises a clear error — κ has no valid averaging axis over a sparse multi-label vector. UseClassificationScorerorAltTestScorerinstead.
Required Tasks (required_tasks)
The required_tasks parameter controls which tasks must be completed for a valid annotation or judge response.
Default Behavior (when required_tasks is not specified):
- All classification tasks (non-
Noneschemas) are required - All free-form tasks (
Noneschemas) are not required
Impact on Annotation Interface:
In the annotation interface, required fields are marked with a red asterisk (*) and must be filled before the annotation is auto-saved.
Impact on Judge Results:
For judge evaluations, only the required tasks need to be successfully parsed for a result to be marked as successful.
Answer Parsing Methods (answering_method)
Three parsing methods with different trade-offs:
Pros: Most reliable, cleanest parsing, best model support
Cons: Newer feature, not supported by all models
Best for: Production use with modern models
Fallback sequence (when structured_outputs_fallback=True): structured → instructor → xml
Pros: Good compatibility, structured validation
Cons: Additional dependency, model-specific implementation
Best for: When you need structured outputs with older models
Fallback sequence (when structured_outputs_fallback=True): instructor → structured → xml
Enable Fallback for Production
Always enable fallback to maximise Judge completion.
Skip Function to Filter Data Rows (skip_function)
Skip Function Serialization
Currently, skip functions are not saved when EvalTask is serialized/deserialized. When loading a saved project:
Annotation Prompt for Human Interface (annotation_prompt)
Customize the prompt shown to human annotators: