Skip to main content
An eval suite is a reusable manifest. It describes what to run, how to render prompts, how to preprocess rows, how to extract model outputs, and which Python grader should score each sample or task batch. This page covers the manifest surface. For the end-to-end run flow, start with Run evals. For Python scoring contracts, see Write Python eval graders.

Manifest shape

Every suite version stores one manifest.
Manifest limits:

Task types

type labels the task for humans and downstream reporting. Scoring is not hardcoded by task type. The Python grader determines the actual metric behavior. Supported task labels: Use metadata on tasks and runs for your own experiment identifiers. Metadata keys may be up to 64 characters and values up to 512 characters.

Uploaded datasets

Use uploaded files for controlled, reproducible datasets. Upload them through /files with purpose=evals, then reference the file ID in the task.
format can be jsonl or csv. If you omit it, the gateway infers the format from the uploaded filename. JSONL rows must be objects:
eval.jsonl
CSV files use the first row as headers:
eval.csv

Hugging Face datasets

Use Hugging Face when your eval should run from a public or preconfigured private dataset. The gateway loads rows from the Hugging Face datasets server.
Fields: Private Hugging Face datasets require a Hugging Face token configured for the gateway environment. The token is not supplied in the eval manifest. Contact MKA1 if your team needs access to private or gated Hugging Face datasets.

Hugging Face json and csv builders

For path: "json" or path: "csv", provide data_files. Only HTTP(S) URLs are allowed, and local/private network hosts are rejected.
You can also put data_files under dataset_kwargs.data_files.

Templates

prompt_template and target_template render with values from the current dataset row.
Template behavior: Missing values render as an empty string. Objects and arrays render as JSON.

Few-shot examples

Few-shot examples are rendered before the evaluated prompt. Use num_fewshot for lm-eval style manifests, or the expanded fewshot object when you need more control.
Expanded form:
Few-shot fields: The current row is excluded when few-shot examples are drawn from the same in-memory row list.

Python preprocessors

Use preprocessors to normalize dataset rows before prompt rendering. They run in the Python sandbox with the same file scoping rules as graders.
Contracts: Preprocessors may return: If preprocessing fails, the run fails before sample execution for that task.

Output extraction

Output extraction turns raw model text into extracted_output. The grader receives both sample["output_text"] and sample["extracted_output"]. Examples:
Regex patterns are checked for safety. Very large regex inputs and excessive match counts are capped.

Metrics

Metrics declare which score keys should be aggregated. Python graders produce the score values.
Fields: If a per-sample grader returns a single float, MKA1 stores it under the grader metric_id, which defaults to score. If a per-sample task omits metrics, MKA1 adds a default metric for that metric_id. Aggregate batch graders can provide final task metrics through grade_batch.

Generation settings

Run-level generation controls candidate model calls. It includes normalized Responses fields, lm-eval aliases, provider passthrough fields, and eval execution controls.
Normalized fields: Provider passthrough fields: Provider passthrough is only sent to OpenAI-compatible non-OpenAI upstreams. Real OpenAI upstreams receive only supported fields. Execution controls:

Example: multiple-choice Hugging Face task

Example: few-shot task with a separate training split

Versioning guidance

Create a new suite version when you change any behavior that affects results:
  • Dataset file or Hugging Face path/config/split.
  • Prompt, target, few-shot, preprocessing, or output extraction.
  • Metric IDs or aggregation behavior.
  • Python grader source or file ID.
Store run-specific choices on the run:
  • Candidate models.
  • Judge model.
  • Embedding model.
  • Generation settings.
  • Concurrency and sample caps.
This keeps the suite reusable while preserving exactly what each run executed.