LLM Evaluation Frameworks in Production: Comparing Promptfoo, DeepEval, Ragas, and Inspect Architecture, Metric Calibration, and Quality Gate Economics

Testing large language model applications in production requires shifting from deterministic software unit tests to probabilistic evaluation harnesses. Traditional software engineering relies on binary assertions (assert output == expected), but generative models exhibit non-deterministic outputs, variable token distributions, and nuanced semantic drift across prompt revisions, model updates, and temperature configurations.

To prevent regressions and quantify system capabilities before deployment, teams rely on dedicated LLM evaluation frameworks. Four open-source tools have emerged as primary architectural choices across production engineering and safety research: Promptfoo, DeepEval, Ragas, and the UK AI Security Institute's Inspect AI.

Each framework represents a distinct architectural paradigm designed for different lifecycle stages: declarative configuration-driven regression testing, Pytest-native unit evaluation, retrieval-augmented generation (RAG) component scoring, and sandboxed multi-turn agent evaluation.

The Evaluation Architecture Spectrum

| Feature / Dimension | Promptfoo | DeepEval | Ragas | UK AISI Inspect | | :--- | :--- | :--- | :--- | :--- | | Primary Design Paradigm | Declarative YAML / CLI | Pytest-native Python harness | Python library for RAG components | Research-grade Agent/Model harness | | Core Abstraction | Providers + Prompts + Asserts | Test Cases + Custom Metrics | Datasets + Component Metrics | Datasets + Solvers + Scorers | | Execution Model | Node.js / TypeScript / Python CLI | Python test runner (Pytest plugin) | Python async batch runner | Python async pipeline / CLI | | Primary Strength | Prompt iteration & red-teaming | CI/CD test gates & G-Eval metrics | Reference-free RAG triage | Multi-step agent & security eval | | LLM-as-a-Judge Mechanism | Built-in model grading prompts | G-Eval (Chain-of-Thought + Probabilities) | Decomposition + NLI entailment | Declarative model scorers & rubrics | | Deterministic Metrics | Regex, JSON schema, webhook, latency | Exact match, Levenshtein, JSON schema | BLEU, ROUGE, semantic similarity | Exact match, regex, custom code | | Sandboxing Support | Shell commands / local execution | Local Python environment | Local Python environment | Built-in Docker, Podman, Kubernetes | | Synthetic Data Generation | Adversarial red-team probe generation | Single & multi-turn test case synthesis | Query evolution over document graphs | Dataset generation via custom scripts |

1. Promptfoo: Declarative Matrix Testing and Red-Teaming

Promptfoo is architected around a declarative YAML configuration model optimized for rapid prompt engineering, cross-model benchmarking, and adversarial vulnerability scanning.

Execution Architecture

Promptfoo separates configuration from implementation logic. A single promptfooconfig.yaml file defines three orthogonal dimensions that form an evaluation matrix:

1. Prompts: One or more system and user prompt templates containing variable placeholders.
2. Providers: Target LLM endpoints (such as OpenAI, Anthropic, Bedrock, Ollama, or local HTTP APIs).
3. Tests: Input variables paired with declarative assertions.

When executed via promptfoo eval, the engine generates the Cartesian product of prompts, providers, and test cases, executing API requests concurrently with built-in rate-limiting and response caching.

# promptfooconfig.yaml
description: "Customer Support Intent Routing Gate"
prompts:
  - "file://prompts/v1_router.json"
  - "file://prompts/v2_router.json"
providers:
  - id: openai:gpt-4o-mini
    config:
      temperature: 0.0
  - id: anthropic:claude-3-5-haiku-20241022
tests:
  - vars:
      query: "I want to return an unopened laptop I received yesterday."
    assert:
      - type: is-json
        value:
          required: ["intent", "confidence"]
      - type: javascript
        value: "JSON.parse(output).intent === 'returns'"
      - type: llm-rubric
        value: "Ensure the response classifies the intent accurately without escalating."
      - type: cost
        threshold: 0.002
      - type: latency
        threshold: 1200

Deterministic Assertions and Red-Teaming Engine

Promptfoo emphasizes fast, low-cost deterministic assertions before invoking judge models. Built-in assertion types include regex matching, JSON schema validation, Levenshtein distance, webhook triggers, and Python/JavaScript expression hooks.

Additionally, Promptfoo includes an automated dynamic red-teaming module that probes endpoints for OWASP LLM Top 10 vulnerabilities, including prompt injection, jailbreaks, PII leakage, and SQL injection bypasses, generating specialized adversarial test suites without requiring manual prompt crafting.

2. DeepEval: Pytest-Native Unit Testing and G-Eval

Developed by Confident AI, DeepEval bridges the gap between machine learning evaluation and standard Python software testing practices. It integrates directly with pytest, allowing engineering teams to run LLM test suites within their existing continuous integration pipelines.

The G-Eval Scoring Architecture

DeepEval standardizes custom evaluation using G-Eval (Liu et al., 2023), a framework that employs Large Language Models with Chain-of-Thought (CoT) reasoning to grade outputs based on natural language criteria.

Traditional LLM-as-a-judge approaches prompt a model for a discrete score (e.g., 1 to 5), which often suffers from high variance and integer discretization bias. G-Eval resolves this through a four-stage process:

1. Criteria Definition: The user specifies the target property (e.g., technical accuracy, conciseness).
2. Evaluation Steps Generation: An LLM automatically expands the criteria into explicit, sequential evaluation steps.
3. Chain-of-Thought Evaluation: The judge LLM evaluates the target output against each step, generating reasoning trajectories.
4. Probability Weighting: Rather than parsing the raw text integer, the framework extracts the log probabilities of the numerical rating tokens ($p(s_i)$) from the judge model's output logits to calculate a continuous expected score:

$$\text{Score} = \sum_{i=1}^{N} s_i \cdot p(s_i)$$

This continuous formulation significantly improves correlation with human judgment on benchmarks like SummEval ($r=0.514$ Spearman correlation).

import pytest
from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import GEval, HallucinationMetric
from deepeval.test_case import LLMTestCaseParams

def test_financial_summary():
    input_text = "Summarize Q3 earnings: Revenue grew 12% to $4.2B, but operating margin declined from 24% to 19% due to GPU capex."
    actual_output = "In Q3, revenue expanded 12% reaching $4.2B. Operating margins contracted to 19% driven by GPU infrastructure investments."
    context = [
        "Q3 financial release: Revenue $4.2B (up 12% YoY). Operating margin 19% vs 24% prior year due to hardware procurement."
    ]

    metric_geval = GEval(
        name="Financial Precision",
        criteria="Evaluate if all financial percentages, absolute values, and margin drivers match the input context exactly.",
        evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT, LLMTestCaseParams.INPUT],
        threshold=0.85
    )
    
    test_case = LLMTestCase(
        input=input_text,
        actual_output=actual_output,
        context=context
    )
    
    assert_test(test_case, [metric_geval])

3. Ragas: Component-Level RAG Evaluation

Ragas (Es et al., 2023) focuses specifically on isolating failure modes within Retrieval-Augmented Generation architectures. In a RAG pipeline, downstream errors stem from two distinct sources: retrieval failures (irrelevant, noisy, or incomplete context) and generation failures (hallucination or instruction non-adherence).

Ragas decouples these components through four core reference-free metrics:

                          ┌──────────────────────────┐
                          │       User Query         │
                          └─────────────┬────────────┘
                                        │
                 ┌──────────────────────┴──────────────────────┐
                 │                                             │
                 ▼                                             ▼
     ┌───────────────────────┐                     ┌───────────────────────┐
     │   Retrieved Context   │                     │    Generated Answer   │
     └───────────┬───────────┘                     └───────────┬───────────┘
                 │                                             │
                 │ ◄─────── Context Precision ───────────────► │
                 │ ◄─────── Context Recall (w/ Ground Truth) ─►│
                 │                                             │
                 └─────────────► Faithfulness ────────────────►│
                                 Answer Relevancy ─────────────┘

1. Faithfulness (Groundedness)

Measures the proportion of factual claims in the generated response that can be directly inferred from the retrieved context.

• Mechanism: An LLM decomposes the answer $S(q)$ into discrete atomic statements: $S(q) = \{s_1, s_2, \dots, s_n\}$. Each statement $s_i$ is evaluated against context $C$ via Natural Language Inference (NLI) entailment:

$$\text{Faithfulness} = \frac{|\{s_i \in S(q) : C \models s_i\}|}{|S(q)|}$$

2. Answer Relevancy

Evaluates whether the output directly addresses the initial user query without incorporating extraneous information.

• Mechanism: The framework generates $k$ synthetic questions $\{q_1, \dots, q_k\}$ from the output $a(q)$ using an LLM, embeds them alongside the original query $q$ via a sentence embedding model $E(\cdot)$, and computes average cosine similarity:

$$\text{Answer Relevancy} = \frac{1}{k} \sum_{i=1}^{k} \frac{E(q) \cdot E(q_i)}{\|E(q)\| \|E(q_i)\|}$$

3. Context Precision and Recall

• Context Precision: Evaluates whether relevant signal chunks are ranked at the top of the retrieved context window rather than buried beneath noise.
• Context Recall: Measures whether all claims in a ground-truth reference answer are present across the retrieved text chunks.

4. UK AISI Inspect: Research-Grade Agent and Capability Sandboxing

Developed by the UK AI Security Institute (AISI), Inspect AI was designed for evaluating frontier model capabilities, cybersecurity proficiency, autonomous tool use, and safety alignment.

Core Primitives: Datasets, Solvers, and Scorers

Inspect abandons simplistic single-turn prompts in favor of composable execution pipelines:

• Dataset: Iterables of structured evaluation samples containing input prompts, target answers, and metadata.
• Solver: Multi-step state machines that govern how the model interacts with tools, executes shell commands, inspects web pages, and reasons through problems. Solvers can wrap full multi-agent architectures.
• Scorer: Evaluation functions that inspect the final solver state, conversation transcripts, and execution outputs to produce structured metrics.

from inspect_ai import Task, task
from inspect_ai.dataset import json_dataset
from inspect_ai.scorer import model_graded_fact
from inspect_ai.solver import (
    chain_of_thought,
    generate,
    use_tools,
    system_message
)
from inspect_ai.tool import bash, python

@task
def bash_agent_evaluation():
    return Task(
        dataset=json_dataset("cyber_challenges.json"),
        plan=[
            system_message("You are an autonomous vulnerability analyst. Solve the objective in the sandbox."),
            use_tools([bash(timeout=60), python()]),
            chain_of_thought(),
            generate()
        ],
        scorer=model_graded_fact(),
        sandbox="docker"
    )

Deterministic Sandboxed Execution

Unlike application-layer eval tools, Inspect natively integrates sandboxed execution environments via Docker, Podman, and Kubernetes clusters. When evaluating coding agents or vulnerability identification systems, the model interacts directly with isolated virtual networks and filesystems. Inspect tracks execution logs, token budgets, and environment state changes across thousands of parallel evaluations.

Mitigating LLM-as-a-Judge Biases

When deploying model-based grading in production CI/CD pipelines, teams must account for systematic biases documented in research:

1. Position Bias: Models tend to prefer the first or last option in pairwise comparisons. Mitigation requires bidirectional swapping: evaluate $(A, B)$ and $(B, A)$, assigning points only when ranking is invariant to position.
2. Verbosity Bias: Judges consistently assign higher scores to longer, structurally elaborate answers regardless of factual density. Mitigation requires length-penalized scoring rubrics or character-normalized evaluation prompts.
3. Self-Preference Bias: Models evaluate responses generated by their own family or architecture higher than competitor models. Mitigation requires using independent neutral judges (e.g., using open-weight evaluation models like Prometheus 2 or cross-model judge ensembles).

CI/CD Quality Gate Economics

Running comprehensive LLM evaluations on every pull request introduces significant latency and API costs. Production pipelines implement tiered evaluation strategies:

[ Git Push / PR Opened ]
         │
         ▼
┌─────────────────────────────────┐
│ Tier 1: Deterministic Gates     │  Latency: < 5s
│ - Regex & JSON Schema           │  Cost: $0.00
│ - AST Syntax & Format Checks    │
└────────┬────────────────────────┘
         │ (Pass)
         ▼
┌─────────────────────────────────┐
│ Tier 2: Lightweight Model Gates │  Latency: 15s - 30s
│ - Promptfoo / DeepEval GEval    │  Cost: ~$0.05 / run
│ - Small Judge (GPT-4o-mini /    │  Sample: 20-50 critical golden queries
│   Claude 3.5 Haiku)             │
└────────┬────────────────────────┘
         │ (Pass)
         ▼
┌─────────────────────────────────┐
│ Tier 3: Comprehensive Evals     │  Latency: 5m - 30m
│ - Ragas RAG Triaging            │  Cost: ~$1.50 - $10.00 / run
│ - Inspect Sandboxed Agents      │  Trigger: Nightly / Pre-Release Staging
│ - Full Synthetic Benchmark Suite│
└─────────────────────────────────┘

1. Tier 1 (Commit-Level): Run deterministic assertions (regex, JSON Schema validation, embedding cosine distance) via Promptfoo CLI. Executes locally in seconds at zero token cost.
2. Tier 2 (PR-Level Quality Gate): Run DeepEval or Promptfoo over a curated golden dataset of 50 high-priority test cases using cost-effective judge models (e.g., GPT-4o-mini or Claude 3.5 Haiku) with parallel asynchronous workers.
3. Tier 3 (Pre-Release / Staging): Run full end-to-end Ragas component evaluations, Inspect agent benchmarks in sandboxed containers, and adversarial red-teaming suites prior to production artifact promotion.

Sources

• Liu, Y., Iter, D., Xu, Y., Wang, S., Xu, R., & Zhu, C. (2023). G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. arXiv:2303.16634
• Es, S., James, J., Espinosa-Anke, L., & Schockaert, S. (2023). Ragas: Automated Evaluation of Retrieval Augmented Generation. arXiv:2309.15217
• Confident AI. DeepEval: The Open-Source LLM Evaluation Framework. GitHub Repository
• Promptfoo. Test and Secure LLM Applications. GitHub Repository
• UK AI Security Institute (AISI). Inspect AI: A Framework for Large Language Model Evaluations. GitHub Repository
• UK AI Security Institute (AISI). Announcing Inspect Evals. AISI Research Notes