AI Eval Pipelines: PromptFoo + DeepEval for QA Engineers

QA engineers are being handed LLM apps to test, and the job is no longer “does the button work.” When a model gives a different answer every run, a passing assert on the happy path means nothing. What actually catches regressions is an AI eval pipeline: a repeatable set of checks that scores answers for correctness, hallucination, and retrieval quality, then fails your CI build when the score drops. In this guide I walk through the two tools I reach for first, PromptFoo and DeepEval, and the QASkills pack I’m shipping to make the whole thing a 20-minute setup instead of a two-week project.

Table of Contents

• Why QA Owns the AI Eval Pipeline Now
• The Anatomy of an AI Eval Pipeline
• PromptFoo vs DeepEval: Two Tools, Two Shapes
• The QASkills AI Eval Pack I’m Shipping
• Building a PromptFoo Eval Pipeline
• Building a DeepEval Eval Pipeline
• What to Actually Measure: A Metric Cheat Sheet
• India Context: AI QA Is the Fastest Route to a Raise
• Common Traps I See Teams Fall Into
• Key Takeaways
• FAQ

Why QA Owns the AI Eval Pipeline Now

For years, “AI testing” meant verifying that a model endpoint returns HTTP 200 and a non-empty string. That is not testing. A model can return garbage with total confidence, and your smoke test will still pass. The moment a team ships a RAG chatbot or an AI agent into production, the real risk shifts to things a status code cannot see:

• Hallucination: the model invents a refund policy that does not exist in your knowledge base.
• Retrieval drift: the vector index pulls the wrong chunk, so the answer is confident and wrong.
• Prompt regression: someone tweaks the system prompt and answer quality silently drops 12%.
• Agent missteps: the agent calls the wrong tool, or calls the right tool with the wrong argument.

This is exactly the territory QA engineers already know how to defend: you need test data, you need a threshold, and you need it wired into CI so a bad change cannot merge silently. The only new part is the assertion. Instead of assert page.get_by_text("Order confirmed").is_visible(), you write an assertion that says “this answer is at least 80% faithful to the retrieval context.” That is an AI eval pipeline, and it is the fastest-growing slice of QA work right now.

The numbers back this up. PromptFoo sits at 24,258 GitHub stars with 2.28 million npm downloads in the last 30 days. DeepEval sits at 17,607 stars and 5.78 million PyPI downloads in the same window. These are not niche tools anymore. They are the pytest and Playwright of the LLM era, and a QA engineer who can run both has a real edge in the hiring market.

The Anatomy of an AI Eval Pipeline

Before you open either tool, it helps to know the five parts every AI eval pipeline needs. Skip one and you build a dashboard, not a gate.

1. Golden dataset: a fixed set of inputs with expected outputs and retrieval context. Treat it like a versioned test fixture, not an afterthought.
2. Metric selection: pick the four to six scores that map to a failure mode you care about: hallucination, irrelevance, wrong tool call.
3. Thresholds: the pass line for each metric. Set it from your observed low-water mark, not from a single lucky run.
4. CI gating: a command that runs the eval and exits non-zero on a miss, so a bad prompt or model swap blocks the merge.
5. Triage and reporting: when a score drops, you need to know which case failed and why, not just “the number went down.”

If you have all five, you have an AI eval pipeline. If you only have a metric dashboard someone checks once a month, you have a decoration. Everything in the next two sections maps back to these five stages.

PromptFoo vs DeepEval: Two Tools, Two Shapes

Both tools do LLM evaluation, but they feel completely different under the fingers. Pick based on what your team already uses.

PromptFoo: Config-First, Red-Teaming Native

PromptFoo is a Node.js CLI and library. You describe your eval in a YAML file (promptfooconfig.yaml), point it at providers, list your test cases, and add assertions. It shines at:

• Model comparison: run the same prompts across OpenAI, Anthropic, Azure, Bedrock, and a local Ollama model side by side.
• Red teaming: a built-in vulnerability scanner that generates adversarial prompts and produces a security report.
• CI/CD gates: a single promptfoo eval command you drop into GitHub Actions.
• Code scanning and PR review: flag LLM security and compliance issues before merge.

PromptFoo is now part of OpenAI but remains open source and MIT-licensed. It requires Node.js 22.22.0 or newer, with Node 24 LTS recommended. Everything runs locally by default, which matters if your test data is sensitive.

DeepEval: Python, Pytest-Style, Metric Library

DeepEval is the Python answer, and it deliberately feels like pytest. You write test files, import metrics, and run deepeval test run. Its strength is the breadth of ready-made metrics:

• RAG metrics: faithfulness, answer relevancy, contextual precision, contextual recall, contextual relevancy.
• Agentic metrics: task completion, tool correctness, argument correctness, step efficiency, plan adherence.
• Safety metrics: hallucination, bias, toxicity, and JSON correctness.
• Multi-turn metrics: knowledge retention, conversation completeness, role adherence.

DeepEval integrates with LangChain, LangGraph, Pydantic AI, CrewAI, OpenAI Agents, LlamaIndex, Google ADK, and more. It also plugs into Confident AI for shared reports and production observability.

The Short Version

Here is the decision rule I give teams:

You should pick PromptFoo if	You should pick DeepEval if
Your stack is TypeScript/Node	Your stack is Python
You need red teaming and model comparison	You need 30+ research-backed metrics out of the box
You want config-driven evals with no code	You want pytest-style tests your SDETs already know
You test prompts and model selection	You test RAG pipelines and agent trajectories

Most serious AI QA teams I talk to end up running both: PromptFoo for prompt regression and red teaming, DeepEval for metric-heavy RAG and agent evals. They are complementary, not competing.

One more nuance worth stating plainly: the two tools grade differently. PromptFoo leans on assertions and rubrics you write yourself, while DeepEval ships research-backed metrics like G-Eval that score against a criteria string you define. That distinction matters when you have to defend a score to a skeptical engineering manager. A named metric with a published methodology behind it carries more weight than a rubric you typed at 9pm.

The QASkills AI Eval Pack I’m Shipping

Here is the honest problem: both tools have excellent docs, but a QA engineer staring at a blank promptfooconfig.yaml for the first time does not know which of DeepEval’s 30 metrics to enable, what threshold to set, or how to wire it into CI. That setup time is the gap I built QASkills to close.

QASkills is a directory of AI skills for QA engineers. It is live today with 50 skills, installed through npx @qaskills/cli add. The new AI eval pipeline pack gives you a ready-made workflow instead of a blank page:

1. PromptFoo starter config: a promptfooconfig.yaml with providers pre-wired, a starter test set, and sensible asserts for factuality and context adherence.
2. DeepEval metric presets: a curated subset (faithfulness, answer relevancy, hallucination, task completion) with thresholds set for a support-chatbot default.
3. CI hook templates: GitHub Actions and GitLab CI snippets that fail the build when a score drops below threshold.
4. A seed dataset: 25 golden input/output/context triples so you are not inventing test data on day one.
5. A triage checklist: what to do when each metric fails, so a red eval does not dead-end in “the score went down.”

The point of the pack is not to replace the tools. It is to remove the first two weeks of head-scratching so you get to the part that matters: judging whether your AI feature is actually getting better or worse with each change.

Building a PromptFoo AI Eval Pipeline

PromptFoo’s flow is: install, init, edit a YAML config, run, view. Here is the whole thing.

Install and scaffold

npm install -g promptfoo
promptfoo init --example getting-started
export OPENAI_API_KEY=sk-...

A minimal config

# promptfooconfig.yaml
prompts:
  - "You are a support agent for an e-commerce site.\n\nQuestion: {{question}}\n\nAnswer:"

providers:
  - id: openai:gpt-4o
  - id: anthropic:claude-sonnet-4-5

tests:
  - vars:
      question: "What is your refund policy?"
    assert:
      - type: contains
        value: "30 days"
      - type: llm-rubric
        value: "The answer must not invent a policy that is not stated in the context."
  - vars:
      question: "Do you ship internationally?"
    assert:
      - type: contains
        value: "yes"
      - type: llm-rubric
        value: "Answer must stay grounded in the provided retrieval context."

Two things stand out. The providers block runs the same prompt against both GPT-4o and Claude Sonnet so you can compare quality in one pass. The assert block mixes deterministic checks (contains) with an llm-rubric that uses a judge model to score the answer against a rubric you wrote in plain English.

Run it and wire it to CI

promptfoo eval
promptfoo view

The view command opens a local web UI with a side-by-side matrix. To make it a gate, add it to a GitHub Actions job:

# .github/workflows/eval.yml
- name: Run LLM evals
  run: npx promptfoo@latest eval --max-concurrency 2

If any assertion fails, promptfoo eval exits non-zero and your PR gets blocked. That is the moment the eval stops being a nice-to-have and becomes a real quality gate. PromptFoo also has a red teaming mode that generates adversarial inputs worth running against any customer-facing prompt before you ship. For the security angle specifically, I wrote a full walkthrough on prompt injection testing that pairs well with this.

Building a DeepEval AI Eval Pipeline

DeepEval is the path a Python SDET will feel at home with inside ten minutes, because it borrows pytest’s shape. Install it, write a test file, run it.

Install

pip install -U deepeval

A RAG faithfulness check

# test_rag.py
from deepeval import assert_test
from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric
from deepeval.test_case import LLMTestCase

def test_support_answer_is_grounded():
    faithfulness = FaithfulnessMetric(threshold=0.7)
    relevancy = AnswerRelevancyMetric(threshold=0.7)
    test_case = LLMTestCase(
        input="What if these shoes don't fit?",
        actual_output="You have 30 days to return them for a full refund.",
        retrieval_context=["All customers get a 30-day full refund, no restocking fee."],
    )
    assert_test(test_case, [faithfulness, relevancy])

Run it with:

deepeval test run test_rag.py

FaithfulnessMetric checks that the actual output is grounded in the retrieval context. It penalizes hallucinated details. AnswerRelevancyMetric checks the output actually answers the question. Both return a score from 0 to 1, and threshold=0.7 is the pass line. The assert_test helper turns a metric miss into a real test failure, so your existing pytest CI just works.

Going deeper: agent trajectories

When you test an agent rather than a single answer, DeepEval’s TaskCompletionMetric evaluates the whole trajectory, every tool call and handoff, instead of just the final string:

from deepeval.metrics import TaskCompletionMetric

for golden in dataset.evals_iterator(metrics=[TaskCompletionMetric()]):
    agent.invoke({"messages": [{"role": "user", "content": golden.input}]})

This is the part that separates “I checked the response” from “I checked whether the agent actually completed the task.” If you want a full metric-by-metric reference for DeepEval, I have a complete guide on evaluating LLM outputs, plus a DeepEval vs Ragas comparison if you are still deciding between frameworks.

What to Actually Measure: A Metric Cheat Sheet

The single biggest mistake I see is enabling every metric and then drowning in scores nobody understands. Start with a tight set, mapped to the failure mode you care about. Here is the cheat sheet I hand to teams.

For RAG apps (chatbots, search, support agents)

• Faithfulness: is the answer grounded in the retrieved context? Catches hallucination.
• Answer relevancy: does the answer address the question? Catches rambling.
• Contextual precision: are the relevant chunks ranked at the top of retrieval? Catches retrieval drift.
• Contextual recall: did retrieval surface everything it should have? Catches missing context.

DeepEval also bundles a RAGAS metric that averages answer relevancy, faithfulness, contextual precision, and contextual recall into one number. Use it as a headline trend line, but keep the individual scores too. A composite hides which of the four is actually drifting.

For AI agents

• Task completion: did the agent finish the goal?
• Tool correctness: did it call the right tool?
• Argument correctness: did it pass the right arguments to that tool?
• Step efficiency: did it waste turns on unnecessary calls?

For safety and compliance (run on every customer-facing release)

• Hallucination: factual correctness against provided context.
• Bias and toxicity: DeepEval ships these as standalone metrics.
• JSON correctness: does the output match the schema your API contract expects?
• Prompt alignment: does the output follow the instructions in your prompt template?

My rule of thumb: four to six metrics maximum per pipeline. Any more and you spend your week tuning thresholds instead of shipping. Every metric here has a named source and threshold guidance in the DeepEval docs and the PromptFoo docs, so start from their defaults rather than inventing your own.

India Context: AI QA Is the Fastest Route to a Raise

I see the job descriptions every week. Two years ago, “AI” on an SDET posting meant “you should know a bit about ChatGPT.” Today the same companies want QA engineers who can build an eval pipeline, run red teaming, and gate an AI release in CI. That is a concrete, testable skill, and it is in short supply.

The market split is real. A manual tester who can only click through an LLM chatbot earns the same as any manual tester. An SDET who can stand up a PromptFoo or DeepEval gate, write a faithfulness threshold, and explain why a score dropped is interviewing at a different level entirely: typically ₹20 to ₹40 LPA in Bengaluru and Hyderabad product companies, versus the ₹8 to ₹15 LPA band a service-company automation role still pays. The gap is not the tools; it is the judgment of what to measure and where the threshold goes.

If you are a tester reading this and want to move into AI QA, the fastest path is: learn one eval framework end to end, put a working pipeline on GitHub, and add it to your résumé. That one artifact does more for your credibility than a hundred “AI-aware” keywords. The Testing Academy has a structured track for exactly this transition, and the QASkills eval pack is meant to be the hands-on project that gets you there. I also tell testers to stop waiting for permission to learn this. Both tools are free and open source, the docs are public, and a working eval pipeline on GitHub is a portfolio piece no hiring manager can ignore.

Common Traps I See Teams Fall Into

Building the pipeline is easy. Building one that actually catches regressions is where teams slip. These are the five traps I hit or watch others hit.

Trap 1: Grading with an expensive judge model on every commit

LLM-as-a-judge metrics call another model to score your output. Run GPT-4o as the judge on a 500-case suite every commit and your CI bill becomes the story. Fix: cache results, run the full suite nightly, and keep a 20-case smoke eval on every commit.

Trap 2: Thresholds set from one lucky run

If you set threshold=0.7 because your first run scored 0.72, the next prompt tweak will fail you for noise. Fix: run the eval five times, take the low-water mark, and set the threshold a few points below it. You want to catch regressions, not coin flips.

Trap 3: Testing in a vacuum

An eval with two test cases tells you nothing. A seed dataset of 25 golden triples is the minimum to feel a real regression. The QASkills pack ships with exactly that seed set for a support-chatbot scenario so you can swap in your own data fast.

Trap 4: Ignoring red teaming until after launch

Security testing is not a post-launch chore. PromptFoo’s red team mode and DeepEval’s hallucination and bias metrics should run on every release candidate, not after the incident. The cost of a prompt injection reaching customers is a brand story, not a Jira ticket. My AI observability guide covers what to watch once the app is live, and the eval pipeline is the pre-launch half of the same discipline.

Trap 5: Treating the eval as a one-time migration

Teams build the pipeline during a big AI push, then let it rot. An eval is only as good as its dataset. When your product adds a feature, a new knowledge source, or a new tool for the agent to call, the golden set has to grow with it. I review my eval datasets every sprint. A stale eval is a false sense of security with extra steps.

Key Takeaways

• An AI eval pipeline replaces “it returned 200” with scored assertions on correctness, hallucination, and retrieval, wired into CI.
• PromptFoo (0.122.0, 24K+ stars) is config-first and red-teaming native; DeepEval (4.1.8, 17.6K stars) is pytest-style with 30+ research-backed metrics.
• Pick by stack: TypeScript and red teaming favor PromptFoo; Python and RAG/agent trajectories favor DeepEval. Many teams run both.
• Measure four to six metrics maximum, mapped to a failure mode, not all 30 at once.
• The QASkills AI eval pack ships starter configs, metric presets, CI hooks, and a seed dataset so your first pipeline is a 20-minute job.

FAQ

Do I need to be a machine learning engineer to build an AI eval pipeline?

No. If you can write a pytest suite or a YAML config, you can build one. The metrics are pre-built; your job is picking the right ones and setting a sensible threshold.

PromptFoo or DeepEval: Which Should I Learn First?

Match your stack. Python and RAG/agent testing point to DeepEval. TypeScript, model comparison, or red teaming point to PromptFoo. If you have to pick one to start, pick the one your current team’s code is written in.

How many test cases do I need before evals are trustworthy?

Start with 25 golden triples (input, expected, context). Below that, a single bad case swings your pass rate 4% and you will chase noise instead of regressions.

Can these run in CI, or are they only for local use?

Both run in CI. promptfoo eval and deepeval test run both exit non-zero on failure, so a GitHub Actions or GitLab CI job can block a bad merge the same way your Playwright suite does.

Will LLM grading make my test suite flaky?

It can, if your threshold is too close to your average score. Use a judge model that is stable for your use case, cache results, and set the threshold below your observed low-water mark so you catch real drops, not noise.