AI evals as the new compute: How to build evaluation architectures first in contract AI development (2026)

The article "AI evals are becoming the new compute bottleneck," published on the Hugging Face Blog on April 29, 2026, cleanly articulated what practitioners have been experiencing firsthand. The core thesis—that compute resources for evaluation will be depleted sooner than those for model training—is something many developers recognize immediately after deploying agents or RAG into production.

In custom AI development, evaluations were historically relegated to the final stages following the flow of "build a working PoC → client review → production rollout." In 2026, however, failing to design evaluations from the very first week of a project guarantees that the system will break after reaching production. This article outlines the architectural steps to incorporate Evals into custom AI development right from the start.

Why evaluations are becoming the new compute

Summarizing the Hugging Face analysis, the structural dynamics making evaluations a bottleneck are as follows:

Because evaluations scale as a multiplicative explosion of models, prompts, and test cases, organizations releasing agent updates weekly often see evaluation costs eclipse production inference costs within just a few weeks.

This is distinct from the issue discussed in "AI benchmarks are broken" regarding public benchmarks failing to reflect reality; rather, it is an infrastructure challenge for continuously running domain-specific evaluations internally.

Four steps to designing evaluations upfront in custom AI development

When our team delivers custom AI development, we define the following four steps in order during the requirements definition phase:

Step 1. Reverse-engineer evaluation metrics from business KPIs

Rather than discussing accuracy in the abstract, tie metrics directly to business KPIs. For a customer support RAG system, for example, the structure looks like this:

Relying exclusively on LLM-as-a-judge leads to instability, so incorporating 100 to 300 human-reviewed samples for critical KPIs is standard best practice.

Step 2. Build a golden dataset of 100 to 500 domain examples

Rather than relying on external benchmarks, extract golden test cases from authentic customer query logs. It is vital to intentionally incorporate edge cases—such as typos, multiple concurrent questions, and implicit assumptions—as 80% of post-release incidents originate in these edge areas.

# evals/golden_set.py（イメージ）
test_cases = [
    {
        "query": "パスワード再発行のメールが届かないんですけど",
        "expected_intent": "password_reset_help",
        "expected_citations": ["faq/password-reset.md"],
        "tags": ["typo", "frequent"]
    },
    # ... 100〜500 件
]

Tagging these cases makes it possible to diagnose issues instantly after launch, such as identifying that "accuracy dropped only on inputs containing typos."

Step 3. Embed evaluation pipelines into CI

Integrate evaluations into the deployment workflow. Using tools like GitHub Actions alongside Langfuse, Phoenix, or promptfoo, run evaluations on every pull request and automatically block merges when scores fall below agreed thresholds.

# .github/workflows/eval.yml の抜粋
name: AI Evals
on: [pull_request]
jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx promptfoo eval --config evals/config.yaml
      - run: npx promptfoo eval --output evals/results.json
      - name: Check thresholds
        run: |
          jq '.summary.passRate' evals/results.json | \
            awk '{ exit ($1 < 0.85) }'

As detailed in Observability in AI Development with Langfuse, comparing evaluation results and production logs within the same platform enables early detection of drift, such as when an 88% benchmark score drops to 72% in live production.

Step 4. Secure evaluation budgets during initial architecture design

An easily overlooked oversight is failing to include cloud costs for evaluation in project estimates. In custom development projects, we recommend using the following ranges as benchmarks:

Unless this expense is billed from day one as part of ongoing operations, teams run into a post-launch deadlock where they cannot ship releases because they cannot afford to run evaluations.

Defining phase completion criteria with an evaluation-driven approach

When structuring an AI project into PoC, main development, and operational phases, defining completion criteria not as "it works," but as "it meets agreed thresholds across defined evaluation metrics" eliminates subjectivity from phase transitions.

• PoC completion criteria: Step 1 evaluation metrics and Step 2 golden dataset are formally agreed upon with the client (not merely having a working prototype).
• Main development completion criteria: The Step 3 CI eval pipeline passes and maintains threshold scores through deployment.
• Operations phase deliverables: Monthly evaluation reports and an established remediation loop when thresholds are breached.

Framing scopes this way directly links the volume of golden test cases, the number of evaluation dimensions, and the ratio of human review to project workload, providing clear justification for cost estimates. In other words, even for the same RAG implementation, a project with 3 evaluation metrics is completely different from one with 12, and project scope cannot be meaningfully evaluated without deciding these upfront.

Answering the question, "How will we operate the system after introducing AI?" by baking in an evaluation-driven operational framework from the start allows you to present the initiative to clients as an AI investment backed by quantifiable metrics. This directly aligns with the AI governance points covered in MCP and AAIF Governance, reflecting a preferred design pattern where evaluations and governance run on the same operational foundation.

Evaluation tool selection reference table

As of 2026, the four most practical evaluation tools for custom development are as follows:

The lowest-risk progression is to start by running CI with promptfoo, then layer on Langfuse as the production footprint grows.

Summary: Building evaluations first by default

Whether you embrace the mindset of "building evaluations first" fundamentally determines the success rate of custom AI projects. As Hugging Face highlighted, evaluation costs are an unavoidable structural expense; factoring them into project estimates and operations from the beginning ultimately delivers a cheaper, faster, and safer outcome.

Issues such as "the PoC worked, but we are afraid to deploy to production" and "we cannot detect whether the model is drifting in production" are almost always symptoms of lacking evaluation metrics and a golden dataset. The process begins by reviewing existing query logs and identifying what needs to be measured before a release can be cleared. Because the architecture varies entirely based on domain characteristics, the number of metrics, and the feasible extent of human review, please share your current challenges with us via our inquiry form.