The tooling landscape

A disclosure before the map: this chapter does not rank anything, and that is a deliberate departure from the norm.

Search for "best LLM evaluation tools" and the top results are, with striking consistency, published by the tools being compared. One vendor's comparison ranks itself first overall and its own open-source framework as the strongest framework available. A competitor publishes a page titled "<That vendor> alternatives". These pages are not dishonest, and the claims in them are usually defensible. But they are marketing documents, and they are the primary published material on this topic.

So: descriptions, categories, and the questions worth asking. No ranking, no recommendation, no scoring table.

The categories are more useful than the names

Most confusion about eval tooling comes from comparing tools that do different jobs. There are four, and they overlap only at the edges.

1. Benchmark harnesses (Layer A)

For running standardised academic benchmarks against models. Not for evaluating your application.

EleutherAI lm-evaluation-harness is the reference implementation. If you need an MMLU number comparable to a published MMLU number, this is how it was produced. Broad task coverage, and the de facto standard for open-model evaluation.

HuggingFace lighteval is a lighter, backend-agnostic pipeline built over the same foundations, common in leaderboard-style work.

Reach for these when you are evaluating a base model, publishing a model, or reproducing a published score. Not when you are evaluating a product.

2. Application eval frameworks (Layer B)

Libraries you write your own evals in. This is where most product teams belong.

Inspect (UK AI Security Institute) decomposes evaluation into dataset → Task → Solver → Scorer, with multi-turn and agent workflows, sandboxed execution (Docker built in, Kubernetes and Proxmox adapters), a VS Code log viewer and a web viewer, and a broad model layer covering the major APIs plus local vLLM, Ollama, and llama.cpp. Inspect Evals ships a large catalogue of prebuilt evaluations. It is the de facto standard for frontier safety work and is used by AI safety institutes and labs, which shows in the design: strong on sandboxing, agents, and reproducibility.

promptfoo is a YAML-configured CLI and library for prompt and model comparison and red-teaming. Fast time-to-first-result, strong multi-model comparison, and a substantial built-in attack suite, reported at over 500 vectors in the open-source version.

DeepEval is a pytest-flavoured framework with wide metric coverage across RAG, agents, and multi-turn, from Confident AI, which also sells the hosted platform.

RAGAS began as the RAG metric library and supplied most of the vocabulary in the RAG chapter. By 2026 it had extended to agentic workflows, text-to-SQL, and multimodal metrics.

Finding: OpenAI Evals is being retired. Deprecation was announced 3 June 2026; existing evals become read-only on 31 October 2026 and the dashboard and API shut down on 30 November 2026. Agent Builder and the Prompts API are on the same timeline. OpenAI's own migration guide points users at promptfoo.

This is a useful currency check on any guide you read: material still recommending OpenAI Evals as a going concern was written before June 2026 or has not been maintained.

Source: OpenAI deprecations

3. Observability platforms with evaluation (Layers B and C)

Trace collection first, evaluation built on top. If your primary need is "see what happened in production and score a sample of it", this category fits better than a framework.

• Langfuse: open-source tracing with evaluation; self-hostable, which decides it for many teams with data-residency constraints.
• Arize Phoenix: open-source tracing and evaluation, from a team with deep ML-observability background.
• LangSmith: the tightest integration with LangChain and LangGraph; a strong fit if you are already in that ecosystem and less compelling if you are not.
• Braintrust: evaluation-first platform with a prompt playground and CI integration.
• W&B Weave: evaluation and tracing inside Weights & Biases, natural where experiment tracking already lives.
• Evidently: from the ML monitoring tradition; drift and data-quality monitoring alongside LLM evaluation.
• MLflow: general experiment tracking with LLM evaluation added; often the path of least resistance where it is already deployed.

The category is converging: everyone is adding everyone else's features, and differentiation is increasingly about hosting model, price, and which ecosystem you are already in rather than capability.

4. Hand-rolled

Still extremely common among serious teams, and not a sign of immaturity.

A pytest suite, a dataset in the repository, a scorer module, and results in a table is a complete and defensible eval system. Teams choose it because the eval logic is the domain knowledge, and because frameworks impose a metric vocabulary that may not fit. The interesting part is your criteria, not the runner.

What teams hand-roll most often, even when they use a platform:

• The annotation interface. Almost universal. A single-screen custom viewer beats every generic tool, and it is an afternoon's work with an AI coding assistant.
• Domain-specific graders. Nobody's library knows your business rules.
• The judge prompt. Off-the-shelf judge metrics are the thing the judge chapter most warns against.
• Trace mining and sampling. Your stratification logic is yours.

How to choose, without a ranking

Questions that actually discriminate, roughly in order of how much they narrow the field:

Where can your data live? Self-hosted or EU-hosted requirements eliminate most of the category immediately and are non-negotiable when they apply. Ask this first.

Do you need tracing, or evaluation, or both? If you have no production observability, a platform that gives you traces plus evaluation is better value than a framework plus a tracing project.

What language is your stack? Most of this ecosystem is Python-first. A TypeScript team has genuinely fewer options and should check rather than assume.

Do you need sandboxed execution? Coding or computer-use agents need isolated environments. Inspect has this built in; most platforms do not.

Who writes the evals? If domain experts label and engineers implement, weight annotation UX heavily. If engineers do both, a library in the repository may be all you need.

What is the exit cost? Datasets and results in an open format that you can export are worth more than any single feature, because this ecosystem is young and you will change your mind.

A note on the metric libraries

Every framework ships prebuilt metrics: faithfulness, answer relevancy, correctness, hallucination, toxicity. They are the fastest way to get numbers on a dashboard.

Treat them as a starting vocabulary, not a measurement. A prebuilt metric encodes somebody else's definition of the property, tuned on somebody else's data. It has not been validated against your labels, and unvalidated judge metrics have unknown sign.

Prebuilt metrics are genuinely useful for exploration and for the first week. They are not a substitute for the alignment measurement, and the convenience of having them pre-made is precisely what makes teams skip it.

Common mistake: Choosing the platform first. The tool decision is downstream of knowing what you are measuring, and what you are measuring comes from error analysis. Teams that pick a platform first end up using its default metrics, because those are the ones already wired up, which is how a team ends up reporting faithfulness for a product whose problem was retrieval recall.