NeMo Evaluator

repository·main·Indexed 43 days ago

https://github.com/nvidia-nemo/evaluator

An LLM evaluation framework designed for high-scale benchmarking. NeMo Evaluator version 0.4.0 provides benchmark environments, pluggable solvers, a local interceptor proxy for traffic management, sandboxed code execution, and multi-format reporting. It supports various solver types including simple, harbor, tool_calling, openclaw, and gym_delegation, with execution backends ranging from local Docker sandboxes to AWS ECS Fargate and SLURM clusters.

Tokens
82.4K
Snippets
272
Records
347
Agent score
55%

What's inside NeMo Evaluator

  1. Overview of NeMo Evaluator

    main
    NeMo Evaluator is an LLM evaluation framework designed for managing benchmark environments, utilizing pluggable solvers, and generating multi-format reports. It provides a unified registry for various evaluation sources including built-in benchmarks, NeMo Skills, Gym remotes, lm-eval tasks, and VLMEvalKit datasets.
  2. Compare NeMo Evaluator deployment options

    main

    NeMo Evaluator supports multiple deployment environments depending on your scale, infrastructure, and whether you need regression gating. Use the following matrix to select the appropriate setup:

    EnvironmentShardingLive ServeRegression GateEffort
    Local DeploymentManual via env varsnel servenel compareMinimal
    Docker ComposePer-container env varsdocker-compose serviceScriptLow
    SLURMnel eval run with executor confignel servesbatch chainMedium
    KubernetesIndexed JobDeployment + ServiceCI pipelineMedium
    Ray@ray.remote tasksN/AScriptMedium
    GitLab CICI variables per jobN/Aregression:check stageLow
  3. Understand the NeMo Evaluator Architecture

    main

    NeMo Evaluator is a modular evaluation framework designed to decouple benchmarks, inference strategies (solvers), and execution environments (executors).

    Key architectural layers include:

    • CLI (nel): The entry point for running, reporting, and validating evaluations.
    • Environments: Abstractions for different benchmark sources (built-in, Gym, Skills, lm-eval, etc.).
    • Engine: The core eval_loop that orchestrates the interaction between solvers and environments.
    • Solvers: Pluggable inference strategies that define how a model responds to a task.
    • Orchestration & Executors: Manages where the evaluation runs (Local, Docker, or SLURM) and how models are deployed (vLLM, SGLang, etc.).
    • Sandbox: Provides isolated execution environments for individual problems to ensure safety and reproducibility.
  4. Integrate NeMo Evaluator with NeMo Gym

    main

    NeMo Evaluator can be integrated with NeMo Gym in three distinct modes depending on your workflow:

    1. Serve (Evaluator -> Gym): Use nel serve to host NEL benchmarks as a live server that Gym training loops can consume via a native protocol.
    2. Export (Evaluator -> Gym): Export benchmark data to JSONL files for batch rollout collection using ng_collect_rollouts without requiring a live server.
    3. Consume (Gym -> Evaluator): Use GymEnvironment to evaluate a model against a remote environment running a nel serve endpoint.

    Before running evaluation examples, ensure your model environment variables are set:

    export NEMO_MODEL_URL="https://integrate.api.nvidia.com/v1/chat/completions"
    export NEMO_MODEL_ID="nvidia/nemotron-3-super-120b-a12b"
    export NVIDIA_API_KEY="your-api-key-here"
    export NEMO_MODEL_URL="https://integrate.api.nvidia.com/v1/chat/completions"
    export NEMO_MODEL_ID="nvidia/nemotron-3-super-120b-a12b"
    export NVIDIA_API_KEY="your-api-key-here"
  5. Compare Container mode vs Native mode observability

    main

    Container mode is useful for running existing harnesses through a unified interface, but it has observability limitations because the container adapter does not decompose the harness. The harness owns the model call, meaning you get aggregate scores and response stats from interceptors, but you lose granular data.

    Use Native mode (e.g., NeMo Skills Integration) if you require:

    • Per-request trajectories
    • Failure categorization
    • n_repeats with pass@k support
    • Bootstrap CI
    • Scoring details per individual sample
  6. How `nel compare` performs statistical model comparisons

    main

    Instead of comparing simple averages, nel compare uses a paired statistical test (McNemar's exact binomial test) to determine if a change in model performance is real or noise.

    It works by:

    1. Pairing results by (problem_idx, repeat) across the baseline and candidate runs.
    2. Classifying pairs as regressions (correct $\rightarrow$ incorrect), improvements (incorrect $\rightarrow$ correct), or unchanged.
    3. Testing if the number of regressions is statistically significant using McNemar's test, which focuses on discordant pairs (where models disagree) rather than overall accuracy.

    This approach is more sensitive to targeted regressions because it controls for problem difficulty by measuring behavior changes on the exact same inputs.

    nel compare ./results/baseline ./results/candidate
  7. Security and Lifecycle Notes for ecs-sandbox-region

    main

    Security

    • Egress: The ECS task security group allows all egress to support ECR pulls, S3, and DockerHub.
    • Ingress: Inbound traffic is restricted to ssh_tunnel_sshd_port and only from the CIDRs specified in orchestrator_allowed_cidrs. The module explicitly rejects 0.0.0.0/0 for security.

    Lifecycle and Rotation

    • S3 Buckets: Uses bucket_prefix for unique global naming. force_destroy = true is enabled to allow terraform destroy to clean up even if objects exist.
    • Secrets: recovery_window_in_days = 0 is used so secrets are deleted immediately upon destruction.
    • Docker Hub Credentials: The secret_string for Docker Hub is wrapped in lifecycle { ignore_changes } to prevent subsequent applies from overwriting manual rotations. To rotate credentials via Terraform, use: terraform apply -replace=...aws_secretsmanager_secret_version.dockerhub
  8. Use scoring primitives for benchmark development

    main

    NeMo Evaluator provides a set of reusable scoring primitives in the scoring/ package. These functions are designed to be used within a benchmark defined via the @scorer decorator. All primitives accept a ScorerInput object as their primary argument.

    Key modules include:

    • scoring/text.py: Text comparison (exact_match, fuzzy_match).
    • scoring/pattern.py: Pattern extraction (multichoice_regex, answer_line, numeric_match).
    • scoring/code_execution.py: Sandboxed execution (code_sandbox).
    • scoring/judge.py: LLM-as-judge logic (needs_judge, judge_score).
    • scoring/json_schema.py: Structured validation (extract_json, validate_json_schema).
  9. Use extended benchmark environments via URI schemes

    main

    NeMo Evaluator (NEL) supports resolving benchmarks from external sources using specific URI schemes and namespace prefixes. This allows you to run benchmarks from lm-evaluation-harness, NeMo Skills, VLMEvalKit, or remote servers.

    | Syntax | Source | Example |
    |--------|--------|---------|
    | `nel eval run --bench <name>` | Built-in registry | `nel eval run --bench mmlu` |
    | `nel eval run --bench lm-eval://<task>` | lm-evaluation-harness | `nel eval run --bench lm-eval://aime25` |
    | `nel eval run --bench skills://<name>` | NeMo Skills | `nel eval run --bench skills://mmlu-pro` |
    | `nel eval run --bench vlmevalkit://<dataset>` | VLMEvalKit | `nel eval run --bench vlmevalkit://MMBench_DEV_EN` |
    | `nel eval run --bench gym://<host:port>` | Remote Gym server | `nel eval run --bench gym://localhost:9090` |
    | `nel eval run --bench harbor://<suite>@<version>` | Harbor task registry | `nel eval run --bench harbor://swebench-verified@1.0` |
    | `nel eval run --bench container://<image>#<task>` | Legacy container | `nel eval run --bench container://nvcr.io/image#task` |
  10. Key Features of NeMo Evaluator

    main

    NeMo Evaluator provides several core capabilities for LLM evaluation:

    • Unified Environment Registry: Everything (benchmarks, skills, gym remotes, etc.) resolves through a single registry.
    • Rapid Benchmark Definition: Use @benchmark and @scorer decorators to define complete benchmarks in under 10 lines of Python.
    • Pluggable Solvers: Swap inference strategies per benchmark via configuration using solvers like simple, harbor, tool_calling, gym_delegation, or openclaw.
    • Flexible Execution Backends: Run evaluations locally, in Docker, or on SLURM clusters with automatic model deployment.
    • Resilience: Features per-benchmark checkpointing and failure isolation. You can resume partially completed suites using the --resume flag.
    • Statistical Analysis: Compare runs using McNemar's exact test, paired flip analysis, and confidence intervals.
    • Quality Gates: Gate releases using per-benchmark policy thresholds.
    • Built-in Benchmarks: Includes 17 benchmarks such as MMLU, MMLU-Pro, MATH-500, GPQA, GSM8K, HumanEval, and more.
  11. Use the tool_calling solver for observable agentic loops

    main

    The tool_calling solver allows NeMo Evaluator (NEL) to drive the agentic loop itself, providing full observability into model calls, tool calls, and conversation turns. This is an alternative to delegated solvers like gym_delegation or harbor, which are opaque to NEL.

    Using Gym HTTP Tools

    To use a Gym Resource Server, set resource_service to the service providing the tools. NEL discovers tools via /openapi.json and dispatches calls via POST /{tool_name}.

    Using Sandbox Tools (NEL as the Agent)

    By setting sandbox_tools: true, NEL provides a canonical set of tools that execute inside a configured sandbox (e.g., Docker). Available tools include:

    • bash: Execute shell commands.
    • file_read: Read file contents.
    • file_write: Write file contents.
    • str_replace_editor: View or make targeted replacements in files.

    Key Configuration Options

    • sandbox_tools: true: Enables the four sandbox tools. Requires a sandbox config.
    • response_mode: sandbox_artifact: The answer is the sandbox state (e.g., a git patch) rather than the last model message. Useful for SWE-bench.
    • max_turns: Maximum model call rounds. If reached, the solver returns error: "max_turns_exhausted".
    • tool_timeout: Per-tool-call timeout in seconds (default: 180).
    • max_output_chars: Truncation limit for tool output fed back to the model (default: 16384).
    benchmarks:
      - name: swebench-multilingual
        solver:
          type: tool_calling
          service: model
          resource_service: tools
          max_turns: 50
  12. How config composition works in NeMo Evaluator

    main

    NeMo Evaluator (NEL) uses Hydra-style config composition to allow for reusable fragments, base-config inheritance, and self-referencing interpolation. This is opt-in via the defaults: key at the top of your YAML configuration.

    Core Concepts

    • defaults: list: Defines which config fragments or base configs to load and merge.
    • _base_: Used within a defaults: list to inherit from an existing complete configuration. Inheritance can be chained (e.g., Grandparent $\rightarrow$ Parent $\rightarrow$ Child).
    • _self_: A special entry in the defaults: list that determines where the current config's body is placed in the merge order. If omitted, it defaults to the last position, giving the current config the highest priority.
    • Config Groups: Fragments are organized into directories that map to top-level keys in the final configuration. For example, a fragment at services/nemotron_fp8.yaml will be merged into the services: key.
    defaults:
      - _base_: 24_slurm_swebench_verified_super
    
    benchmarks:
      - name: harbor://swebench-verified@1.0
        max_concurrent: 30
        solver:
          agent: mini-swe-agent
          agent_kwargs: { max_iterations: 30 }
        sandbox: { concurrency: 30 }
    
    output:
      dir: ./eval_results/swebench-verified-miniswe