LLM Evaluation Frameworks Compared: DeepEval, RAGAS, Promptfoo — and Where Human Review Still Matters

What does an LLM evaluation framework actually do?

An LLM evaluation framework runs your application against a set of test inputs and scores each output on defined metrics. It fails the run when a score drops below a threshold. It replaces manual spot-checking with something a pipeline can gate on.

LLM evaluation is the practice of measuring output quality against defined criteria rather than eyeballing samples. The service version of that work is LLM evaluation services.

3 mechanisms do the scoring. Statistical metrics compare output to a reference string, while model-graded metrics send it to a judge model with a rubric. Custom assertions let you write your own rule, in code or natural language.

The judge model does most of the work in practice. DeepEval’s docs describe G-Eval as using “LLM-as-a-judge with chain-of-thoughts (CoT) to evaluate LLM outputs based on ANY custom criteria”. Promptfoo calls its equivalent llm-rubric its “general-purpose grader for ‘LLM as a judge’ evaluation”.

Your eval is only as good as the rubric you write for the judge.

Which metrics do DeepEval, RAGAS and Promptfoo support?

DeepEval supports the widest built-in metric set of the 3, including hallucination and toxicity as dedicated metrics. RAGAS matches it on the RAG metrics but ships neither of those. Promptfoo covers fewer again: no context precision, and no standalone hallucination or toxicity metric.

Every entry below comes from the project’s own documentation, checked on 20 October 2026.

2 entries in that table need more than a tick or a cross.

Promptfoo covers toxicity through its moderation assertion, which calls an external service such as OpenAI moderation or Meta LlamaGuard. That is a different dependency from a self-contained metric, so it affects your cost and latency.

RAGAS removed AspectCritic in v0.4, according to its migration guide, pointing users at a decorator-based custom metric instead. Its general-purpose metrics page still documents the old class, so check which API version you are on.

DeepEval has its own version of trap. Its metrics documentation now carries a breaking change: all metric scores are higher-the-better. Thresholds written against the old direction will silently invert.

DeepEval vs RAGAS vs Promptfoo: how do they compare?

The 3 differ most on authoring language and CI integration. DeepEval is closest to a unit-testing tool, RAGAS is the most research-oriented, and Promptfoo is the only one configured in YAML.

DeepEval’s CI documentation states it “plugs into pytest via assert_test() and the deepeval test run command”. Its docs name AI engineers, data scientists and QA.

Promptfoo’s CLI documentation says eval “will return exit code 100 when there is at least 1 test case failure”. That makes it the simplest of the 3 to wire into a gate.

2 ownership changes landed this year. Promptfoo announced on 9 March 2026 that it had agreed to be acquired by OpenAI, stating it “will remain open source”. That post still calls closing conditional, while the repo README now reads “Promptfoo is now part of OpenAI”.

RAGAS moved to a new GitHub organisation, and its licence now carries a Vibrant Labs copyright. Both kept their licences, so neither change affects what you can do with the code.

How do you choose a framework for your stack?

Choose on authoring language and pipeline fit first, because metric coverage is close enough that it rarely decides. A Python team gating on pytest wants DeepEval; a team comparing prompts across models in YAML wants Promptfoo.

3 questions settle most cases.

• What language do your tests live in? A Python stack opens all 3. A JavaScript or mixed stack points to Promptfoo, with DeepEval’s less complete TypeScript SDK as the fallback.
• Is retrieval your main risk? If answers come from a RAG pipeline, you need context precision and recall. DeepEval and RAGAS both ship them; Promptfoo covers recall but has no direct precision equivalent.
• Does the eval need to block a merge? DeepEval and Promptfoo both document this path. RAGAS publishes no official CI recipe, so you would wire it up yourself.

Nothing stops you running 2. Teams commonly use RAGAS to tune retrieval during development and Promptfoo or DeepEval as the gate in CI.

The tool is the smallest decision here. The thresholds you agree on matter more.

Where do automated metrics fail?

Automated metrics fail wherever correctness depends on context the metric cannot see. They score the text in front of them, not whether that text is right for your users, your domain or your legal obligations.

They also cannot tell you how the surrounding product behaves. That is a separate job: you have to test how the whole LLM-powered system behaves, including retrieval, tools and the application around the model.

LLM-as-a-judge bias

Judge models are not neutral measuring instruments, and the frameworks say so. Promptfoo’s LLM-as-a-judge guide states the tradeoff plainly: “judges have biases, add latency, and can be manipulated.”

Non-determinism compounds it. DeepEval’s docs warn that G-Eval “is NOT deterministic”, and that “some test cases will sit right on a metric’s threshold and flip between passing and failing across runs”.

RAGAS says the same of its own metrics: LLM-based ones “can be somewhat non-deterministic as the LLM might not always return the same result for the same input”.

There is also a configuration trap. Promptfoo’s llm-rubric page warns that without a threshold set, “a result like { pass: true, score: 0 } will pass”.

Golden sets that go stale

Reference-based metrics are only as current as the references behind them. Promptfoo lists “Requires known correct answers” as a stated limitation of context-recall, and context recall in RAGAS “always requires a reference”.

That dependency breaks quietly. When a policy changes or a product fact is updated, the golden answer still passes while the system under test has moved on. The suite reports green on an answer that is now wrong.

Grounding metrics have a related blind spot. DeepEval’s faithfulness documentation notes that “a real-world truth absent from the retrieved text still counts as unfaithful”. The metric measures agreement with retrieved context, not with reality.

Domain and policy rules a metric can’t see

No built-in metric knows your regulatory position, your refund policy or what your legal team will not sign off. A response can score well on faithfulness, relevancy and toxicity while still breaching a rule that exists only in your organisation.

Promptfoo’s context-faithfulness page lists its own limits: “Depends on judging LLM quality”, “May miss implicit claims” and “Performance degrades with very long contexts”. Those are the conditions most enterprise deployments run in.

This is the gap human review exists to close. The useful question is which judgments a person has to make, once scoring is automated.

How do you combine automated scoring with human review? (QA Madness approach)

Combine them by letting automation produce the volume and a QA engineer own the verdict. Automated scoring covers hundreds of prompt variants; a person decides what the borderline ones mean.

At QA Madness, LLM evaluation services follow 5 steps.

• Golden answers agreed with the client. For each scenario we define, in writing, what a good answer looks like, before any scoring runs.
• Scoring per criterion. Each response scores on accuracy, groundedness, completeness, safety and tone, rather than one pass or fail.
• LLM-as-a-judge for scale. A judge model grades the full variant set — the only practical way to cover hundreds of prompts per scenario.
• QA engineer sign-off on every judgment call. No model grades its own output unchecked. Where a score is borderline or a criterion subjective, an engineer reviews and signs off.
• Re-running evals after a model or prompt change. When the model, system prompt or retrieval logic changes, affected scenarios run again. Last month’s passing suite says nothing about this release.

At QA Madness, that sign-off is the rule, not an escalation path.

The split between the 2 layers matters.

FAQ

What are the best LLM evaluation frameworks in 2026?

DeepEval, RAGAS and Promptfoo are the 3 most widely used open-source options. DeepEval has the broadest built-in metric set and pytest integration, RAGAS focuses on retrieval quality, and Promptfoo is the easiest to wire into CI. Pick on language and pipeline fit, since metric coverage is close.

DeepEval vs RAGAS — which one should I use?

Use DeepEval if you want evals that run as unit tests under pytest and gate a build, with hallucination and toxicity metrics included. Use RAGAS if your main risk is retrieval quality and you want depth on context precision and recall. Both are Python and Apache-2.0, so running both is realistic.

How do you evaluate LLM outputs without ground truth?

Use reference-free metrics and a judge model with an explicit rubric. Faithfulness scores the answer against retrieved context rather than a correct answer, and custom judges like DeepEval’s GEval or Promptfoo’s llm-rubric grade against criteria you write. Accuracy against external facts still needs a human.

Is LLM-as-a-judge reliable?

Reliable enough for scale, not for final sign-off. Promptfoo’s documentation says judges “have biases, add latency, and can be manipulated”, and DeepEval warns its judge metrics are not deterministic. Use them for volume, set explicit thresholds, and let an engineer adjudicate borderline results — our what to look for in an AI testing partner checklist covers what to ask.

QA Madness provides independent software testing services, including LLM and AI product evaluation, for SaaS companies and software vendors across the UK, Europe and North America.

Automated metrics tell you a score. We tell you whether the answer is good enough to ship. Check our LLM evaluation services.