Evaluating AI With Confidence in 2026: Early Evals, Custom Metrics, and the FAGI Workflow

TL;DR: Evaluating AI with confidence in 2026

If you only read one row: the evaluation layer is one set of templates wired into four deployment shapes. Confidence is the property of a system where a CI score predicts a runtime score and a runtime block maps back to a CI regression.

Watch the webinar

In this session, Rishav walks through how early-stage evaluation during dataset prep and prompt iteration helps you build more reliable GenAI systems. The companion guide below distills the workflow into a 2026 reference: which metrics, which layer they belong in, and how to wire them in real code.

What you will learn from this webinar

The session covers five concrete topics tied to the 2026 evaluation workflow:

1. Why early evaluation is critical to catching issues before deployment, and how to wire a regression suite to the dataset-prep stage so a bad chunk or a noisy prompt is caught before a model swap.
2. How to run multi-modal evaluations across text, image, audio, and structured outputs without a custom scoring stack per modality.
3. How to set up custom metrics tailored to a use case using a structured judge wrapper and worked examples, validated against a small human-labeled set.
4. How to use user feedback and error localization to improve performance after release, turning vague low scores into fixable token-level and phrase-level bugs.
5. How to bring engineering discipline into AI development: version every prompt and config, run a regression suite on every change, fail the pipeline on threshold drops, and wire offline scores to runtime guardrails.

The webinar is aimed at AI engineers, ML practitioners, and product teams who want to ship faster without sacrificing reliability.

The four-layer evaluation stack

A confident evaluation workflow has four layers and the same templates flow through all of them.

The four rows are not four separate tools. They are the same evaluator templates in four deployment shapes. That single property is what “confidence” means in this guide: a CI score predicts a runtime score, and a runtime block maps cleanly back to a CI regression.

Five evaluator families to score

A 2026 evaluation suite covers five metric families.

1. Deterministic metrics

Deterministic metrics compare model output to a ground truth using a fixed algorithm: BLEU, ROUGE, exact match, F1, code-execution accuracy. They are fast (milliseconds), cheap, and reproducible. They fail on open-ended generation where many surface forms are correct. Use them where they apply: math, code, structured extraction, classification.

2. LLM-as-judge

A stronger model scores the output against a rubric. Use cases: faithfulness, helpfulness, conciseness, safety, custom rubrics. Three calibration practices keep judges honest:

• Use a stronger or different model than the system under test to avoid self-preference bias.
• Use explicit rubrics with numeric scales and worked examples in the prompt to reduce position and verbosity bias.
• Validate the judge on a small human-labeled set (50 to 200 examples) before running at scale.

3. RAG metrics

Context relevance (chunks match the query), context recall (all relevant chunks retrieved), context precision (no junk chunks), faithfulness (output supported by chunks), answer relevance (response addresses the question), answer correctness (final answer is right). The RAG metric family is the second-most common source of regressions after prompt changes because retrievers drift silently.

4. Agent metrics

Task adherence (did the agent complete the task), tool-call accuracy (did the agent call the right tools with valid arguments), trajectory quality (did the agent take a reasonable path), step efficiency (did the agent finish in a reasonable number of steps), refusal correctness (did the agent refuse when it should).

5. Safety and user signals

Toxicity, PII leakage, prompt injection, jailbreak, off-policy detection. Plus user signals: thumbs up/down rate, escalation rate, deflection rate, conversation length. The user-signal layer closes the loop between offline scores and lived behavior.

A worked example: text faithfulness from notebook to runtime

The whole workflow fits in three blocks.

Offline: one-line evaluator on a held-out case

import os
from fi.evals import evaluate

os.environ["FI_API_KEY"] = "fi-..."
os.environ["FI_SECRET_KEY"] = "fi-secret-..."

context = (
    "The Apollo 11 mission landed Neil Armstrong and Buzz Aldrin "
    "on the Moon on July 20, 1969."
)
output = "Neil Armstrong walked on the Moon in 1969 during Apollo 11."

result = evaluate(
    eval_templates="faithfulness",
    inputs={"output": output, "context": context},
    model_name="turing_flash",
)

print(result.eval_results[0].metrics[0].value)
print(result.eval_results[0].reason)

The same template is faithfulness. The same call signature is evaluate(eval_templates=..., inputs=..., model_name=...). The same response object surfaces a score and a reason.

CI: the same call inside a pytest

from fi.evals import evaluate

def test_apollo_answer_is_faithful():
    context = (
        "The Apollo 11 mission landed Neil Armstrong and Buzz Aldrin "
        "on the Moon on July 20, 1969."
    )
    output = "Neil Armstrong walked on the Moon in 1969 during Apollo 11."
    result = evaluate(
        eval_templates="faithfulness",
        inputs={"output": output, "context": context},
        model_name="turing_flash",
    )
    score = result.eval_results[0].metrics[0].value
    assert score >= 0.8, result.eval_results[0].reason

Wire this test to the CI gate. A pull request that drops faithfulness below the threshold fails before merge.

Runtime: the same template as an inline guardrail

from fi_instrumentation import register, FITracer
from fi.evals import evaluate

tracer = FITracer(register(project_name="apollo-bot"))

def call_my_llm(question: str, context: str) -> str:
    # Replace with the application's own model call.
    return "Neil Armstrong walked on the Moon in 1969 during Apollo 11."

@tracer.chain
def answer(question: str, context: str) -> str:
    response = call_my_llm(question, context)
    result = evaluate(
        eval_templates="faithfulness",
        inputs={"output": response, "context": context},
        model_name="turing_flash",
    )
    score = result.eval_results[0].metrics[0].value
    if score < 0.7:
        return "I can only answer based on the provided documents."
    return response

Same template, same call, but now wired into an OpenInference span via traceAI (Apache 2.0). The score lands on the production trace, so a low-score event in the dashboard maps back to the exact CI test case.

Custom metrics: when the catalog is not enough

Some rubrics are domain-specific (an “is this a legally compliant disclosure” check, a “does the agent confirm the correct billing address” check). Wrap them in CustomLLMJudge.

from fi.evals.metrics import CustomLLMJudge
from fi.evals.llm import LiteLLMProvider

# Pick any LiteLLM-supported judge model string (e.g. "gpt-4o", "gpt-5-2025-08-07").
JUDGE_MODEL = "gpt-4o"

judge = CustomLLMJudge(
    name="legal_disclosure_check",
    rubric=(
        "Score 1 if the response includes the mandated disclosure text. "
        "Score 0 otherwise. Examples below.\n\n"
        "EXAMPLE 1\nResponse: 'This is not legal advice.'\nScore: 1\n\n"
        "EXAMPLE 2\nResponse: 'You should sue them.'\nScore: 0\n"
    ),
    provider=LiteLLMProvider(model=JUDGE_MODEL),
)

result = judge.evaluate(
    inputs={"output": "This is general information, not legal advice."}
)
print(result.score, result.reason)

The rubric is locked in code. Drop the same judge into pytest, the inline guardrail, and the trace evaluator. Validate it on a 50-example human-labeled set; recalibrate quarterly.

Where Future AGI sits in the eval landscape

In the direct evaluation niche (LLM eval, agent eval, RAG eval, judge calibration, error localization), Future AGI is built for this workflow specifically. Four reasons it lands at the top of an evaluation-first stack:

1. One template runs in four layers. evaluate(eval_templates="faithfulness", ...) works in pytest, in inline guardrails, on traces, and in batch jobs without a rewrite.
2. Apache 2.0 across the eval stack. ai-evaluation (github.com/future-agi/ai-evaluation/blob/main/LICENSE) and traceAI (github.com/future-agi/traceAI/blob/main/LICENSE) are Apache 2.0, so a self-hosted runtime never has a license surprise.
3. Tuned judge models. The turing model family (turing_flash, turing_small, turing_large) is tuned for evaluation, not chat. Cloud latencies are roughly 1 to 2 seconds for turing_flash, 2 to 3 seconds for turing_small, 3 to 5 seconds for turing_large per the published docs.
4. The runtime gateway is BYOK. The Agent Command Center at /platform/monitor/command-center sits in front of model providers so guardrails, routing, and cost controls run on the same templates.

Other options have different strengths: open-source eval-only libraries like lm-evaluation-harness are excellent for academic benchmarks; OpenAI Evals is a clean offline harness for OpenAI models; vendor-specific tracing tools (Arize, Datadog LLM Obs) cover observability without the eval-template layer. The Future AGI advantage is that one set of evaluator templates flows through all four layers without a rewrite.

Common failure modes to avoid

1. Different evaluators in CI than in runtime. A CI score does not predict a runtime score, so confidence is illusory.
2. An uncalibrated judge. A judge model with no human-validated baseline produces convincing but wrong scores.
3. No threshold in CI. Without an assertion, the eval is a chart, not a gate.
4. Inline evaluators on the wrong latency tier. A 5-second judge on every user request is a denial-of-service against your own product. Use turing_flash class for inline guardrails.
5. No error localization. A single low score buries the actionable signal in a noisy average.

Pre-flight checklist before you ship

• Held-out set with 200 to 5000 examples per headline metric family.
• A locked rubric per custom metric, validated against a 50-example human-labeled set.
• CI assertion on every headline metric with a defined threshold.
• Inline guardrail on faithfulness, hallucination, and safety on the user-facing path.
• traceAI spans on every production call with evaluator scores attached.
• A dashboard query that maps a low-score trace back to a CI test case.
• A weekly review of error-localization output to feed the next round of prompt and retriever changes.

Further reading

• LLM evaluation in 2026: metrics, methods, and tools: the metric catalog this guide compresses.
• What is LLM evaluation in 2026: the precise definition and the deployment layers.
• Best LLM evaluation tools 2026: vendor-by-vendor comparison.
• Build an LLM evaluation framework: the in-house build path.
• Open-source AI evaluation library: the ai-evaluation walkthrough.

Primary sources

• Future AGI ai-evaluation repo and license: github.com/future-agi/ai-evaluation and LICENSE
• Future AGI traceAI repo and license: github.com/future-agi/traceAI and LICENSE
• Future AGI cloud evals and turing latency docs: docs.futureagi.com/docs/sdk/evals/cloud-evals
• Future AGI instrumentation reference: docs.futureagi.com/docs/observe
• OpenInference semantic conventions: github.com/Arize-ai/openinference
• OpenTelemetry tracing API: opentelemetry.io/docs/concepts/signals/traces
• BLEU paper: aclanthology.org/P02-1040
• ROUGE paper: aclanthology.org/W04-1013
• LM Evaluation Harness: github.com/EleutherAI/lm-evaluation-harness
• OpenAI Evals: github.com/openai/evals

Ready to wire evaluators into your stack? Start with the Future AGI docs, or book a walkthrough with our team.