How do we set up Galileo Evaluate to run prompt/model regression tests in CI before deploy?

Most teams only discover prompt or model regressions after users do—conversion drops, support tickets spike, or an agent suddenly starts taking the wrong tool actions. Galileo Evaluate is built to stop that pattern by turning your golden test sets into a CI gate, so every change to prompts, models, or retrieval logic is regression-tested before deploy.

Quick Answer: You set up Galileo Evaluate for CI by (1) instrumenting your app and creating a golden test set, (2) wiring that test set into your CI pipeline via the Evaluate API/SDK, (3) defining quality thresholds on evaluator scores, and (4) failing the build if those thresholds are breached—so only “green” prompt/model combos ship.

---

The Quick Overview

• What It Is: A CI-integrated regression test harness for LLM prompts and models, powered by Galileo Evaluate and Luna/Luna‑2 evaluation models.
• Who It Is For: Teams shipping RAG systems, agents, and LLM apps who need to catch hallucinations, prompt injections, and quality regressions before they hit production.
• Core Problem Solved: Prevents silent regressions when you change prompts, swap models, tweak RAG, or update tools—by enforcing eval-driven quality gates in CI instead of relying on manual spot checks or live traffic.

---

How It Works

At a high level, you treat your LLM system like any other critical service: you create test fixtures, you define pass/fail criteria, and you wire those tests into CI so bad behavior never makes it to production. The difference with Galileo is that the “assertions” are not brittle regex checks—they’re eval scores from purpose-built evaluators (e.g., correctness, hallucination, safety, tool selection quality) that run at scale and low cost via Luna‑2.

Here’s the basic flow:

1. Create your golden test set in Evaluate:
   Capture real sessions (or synthetic scenarios), turn them into test cases, and attach ground-truth labels or reference answers. This becomes your canonical “does the system still behave?” dataset.

2. Attach evaluators and thresholds:
   Use Galileo’s Evaluation Engine (20+ out-of-the-box evaluators plus custom ones) to score each output. Define thresholds (e.g., hallucination score ≤ 0.1; correctness ≥ 0.9) that represent “ship/no-ship” criteria for your app.

3. Automate runs in CI and fail on regressions:
   Use Galileo’s API/SDK to run the test set whenever a change lands—on PR, pre-merge, or pre-deploy. CI parses the eval results, compares them to your thresholds and previous baselines, and fails the pipeline if quality regresses.

---

Step‑by‑Step: Setting Up Galileo Evaluate for CI Regression Tests

1. Instrument your app and capture traces

Before you can regression-test, you need representative traffic:

• Integrate Galileo during development:

  • Use the SDK or API to log:
    • Inputs (user query, context, tool state)
    • Model selection and parameters
    • Outputs (final answer, tool calls, intermediate steps)
    • Latency and cost per trace
  • For agents, make sure you’re logging sessions → traces → spans (tool calls, routing decisions, intermediate LLM steps).

• Select high-value scenarios:

  • Critical flows: e.g., “apply_for_loan”, “dispute_transaction”, “update_policy”.
  • Known failure modes: hallucinations, PII leaks, tool misuse, policy drift.
  • Edge cases: ambiguous queries, adversarial prompts, long contexts.

These traces become candidates for your golden test set.

2. Build a golden test set in Evaluate

Inside Galileo Evaluate:

1. Create a dataset/test set:

   • Import captured traces via API/SDK or from logs you’ve already ingested.
   • For each test case, define:
     • Input(s) (prompt, retrieved docs, tool state).
     • Expected behavior (reference answer, allowed tools, policies).

2. Add ground truth and labels:

   • Reference answers for correctness.
   • Boolean or categorical labels (e.g., “contains PII?”, “tool selection correct?”, “policy compliant?”).
   • Mark scenarios that must never regress (e.g., regulatory or safety-critical flows).

3. Version the test set:

   • Treat it like code. When you add new cases, bump the version.
   • Keep older versions to compare behavior across releases.

This test set is what your CI job will run every time a prompt/model change is proposed.

3. Configure evaluators (metrics) for your use case

Use Galileo’s Evaluation Engine to define what “good” means:

• Choose out-of-the-box evaluators (recommended to start):

  • RAG-specific:
    • Answer groundedness / hallucination
    • Context relevance & utilization
  • Agent-specific:
    • Tool selection quality
    • Tool call correctness
    • Step-level reasoning quality
  • Safety & security:
    • Toxicity, hate/harassment
    • PII detection
    • Prompt injection and jailbreak attempts
    • Policy adherence
  • General quality:
    • Correctness (vs reference)
    • Consistency, fluency, completeness

• Add custom evaluators where needed:

  • Describe your requirement in natural language (e.g., “Does the agent always offer a repayment plan when the user is overdue?”).
  • Galileo can generate an LLM-as-judge evaluator from that description.
  • Improve it via CLHF/few-shot examples from SME annotations and live feedback.
  • Distill it into a Luna or Luna‑2 evaluator so it’s cheap and fast enough to run on every CI run and, later, in production.

• Define thresholds and weights:

  • Example regression gate:
    • correctness_score ≥ 0.9
    • hallucination_score ≤ 0.05
    • tool_selection_score ≥ 0.95
    • safety_violation_rate = 0
  • For each test set, store these thresholds alongside the configuration so CI can fetch and enforce them.

4. Hook Evaluate into your CI pipeline

You can use any CI system (GitHub Actions, GitLab CI, Jenkins, CircleCI, etc.). The core pattern is:

1. Create an API token/service account

   • Scoped to run eval jobs and read results.
   • Store it as a secret in your CI environment.

2. Define a CI job that calls Galileo:

   High-level steps in the job:

   • Fetch the current test set and evaluator config (by ID/version).
   • Execute the LLM flow under test for all cases (using the branch’s code, prompts, and model choices).
   • Send the inputs/outputs to Galileo Evaluate for scoring.
   • Poll for completion and retrieve aggregate scores.
   • Compare scores vs thresholds and fail if any metric regresses.

   Conceptual pseudo-code:

   # 1. Run your app's regression harness to produce raw outputs
   python run_llm_regression.py \
     --test-set-id=$TEST_SET_ID \
     --model=$CANDIDATE_MODEL \
     --prompt-version=$PROMPT_VERSION \
     --output-path=outputs.json
   
   # 2. Upload to Galileo Evaluate
   galileo-cli eval run \
     --test-set-id $TEST_SET_ID \
     --config-id $EVAL_CONFIG_ID \
     --inputs-outputs-file outputs.json \
     --run-name "CI-$GIT_COMMIT" \
     --out eval_results.json
   
   # 3. Parse results and enforce thresholds
   python enforce_thresholds.py eval_results.json
   

   In enforce_thresholds.py, you’d:

   • Read aggregate metrics (e.g., mean correctness, max hallucination score).
   • Compare against your defined criteria.
   • Exit non-zero if any condition fails (CI fails the build).

3. When the job runs:

   • On every PR that changes:
     • Prompt templates
     • Model configuration (e.g., switching from gpt-4.1-mini to a new version)
     • Retrieval or tool selection logic
   • Or as a pre-deploy gate on main.

5. Treat eval results as your CI signal, not just a dashboard

The whole point is to replace “does it look good in a demo?” with “does it pass our quality contract?”:

• Block merges on failure:

  • Use CI’s branch protection to require the “Galileo Evaluate Regression” job to pass.
  • If hallucination rates spike, or tool correctness drops below threshold, the PR cannot be merged.

• Inspect failures in Galileo:

  • Drill into the failed run:
    • See which test cases failed.
    • View traces (sessions → traces → spans), latency, and cost.
    • Compare candidate vs baseline outputs side by side.
  • Iterate on prompts, retrieval, or tool routing until the run passes.

• Promote configs into production guardrails:

  • Once you trust a custom evaluator in CI, promote it into Protect as a guardrail policy.
  • The same eval that failed your CI now:
    • Scores every production trace in < 200ms.
    • Triggers actions: block, redact, override, or webhook.
    • Runs at 97% lower cost than heavy LLM judges, using Luna‑2.

This is the eval-to-guardrail lifecycle in action: regression tests in CI become real-time guardrails in production.

---

Example CI Workflow

A typical end-to-end flow for a RAG or agent service might look like:

1. Developer updates a retrieval prompt or swaps a base model.
2. Opens a PR with those changes.
3. CI runs:
   • Unit tests and integration tests.
   • Galileo Evaluate Regression Job:
     • Replays golden test set using the new code.
     • Sends outputs to Galileo’s Evaluation Engine.
     • Gets scores for:
       • Correctness vs reference answers.
       • Hallucination/groundedness.
       • Tool selection quality (for agents).
       • Safety and PII.
     • Compares to last passing baseline and predefined thresholds.
4. If any metric regresses beyond your allowed tolerance:
   • CI job fails.
   • PR is blocked.
   • Developer inspects failing cases in Galileo, fixes prompts or logic, reruns.
5. Once passing:
   • PR merges.
   • Same evaluators can be deployed via Protect to guard 100% of production traffic.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Golden Test Sets in Evaluate	Stores and versions representative LLM/agent scenarios with ground truth.	Gives you a stable regression target so you can detect subtle behavior drift.
Evaluation Engine + Luna‑2	Runs 20+ built-in and custom evals with compact models at low latency/cost.	Enables CI to run rich evals on every change, not just occasional samples.
Eval-to-Guardrail Lifecycle	Promotes evaluators from CI testing into production guardrails in Protect.	Ensures the same rules that block a bad release also block bad runtime actions.

---

Ideal Use Cases

• Best for RAG systems: Because they’re especially vulnerable to hallucinations, context misuse, and retrieval bugs every time you change indexing, embeddings, or prompts. Evaluate lets you lock in groundedness and correctness before rollout.
• Best for multi-step agents: Because tool selection and action correctness can drift with small prompt changes. Galileo can regression-test tool decisions and reasoning chains, then turn those into guardrails that control tool access and escalation paths.

---

Limitations & Considerations

• Initial test set coverage:
  If your golden test set is too small or not representative, CI won’t catch all regressions. Plan to expand it over time using Signals (from production) and SME feedback to cover new failure modes.
• Evaluator fit for your domain:
  Generic evaluators might not fully capture domain-specific correctness (e.g., legal, medical, financial nuance). Invest in domain-tuned custom evaluators and CLHF with SME-labeled examples to tighten precision.

---

Pricing & Plans

Galileo’s pricing is designed so you can run Evaluate in CI and guardrail 100% of production traffic without exploding costs. Exact pricing depends on volume (traces per month), deployment model, and support level, but the pattern is:

• Team / Growth: Best for product teams piloting RAG or agents that need CI regression testing and initial guardrails, typically in a SaaS deployment.
• Enterprise: Best for large organizations needing high-volume CI runs, 100% traffic coverage in production, VPC or on‑prem deployment, SSO, SOC 2 Type II posture, HIPAA-ready infrastructure, and dedicated support.

To get specifics for your volume and deployment model, talk with Galileo’s sales/solutions team.

---

Frequently Asked Questions

How do we choose which scenarios to include in our Galileo Evaluate CI test set?

Short Answer: Start with high-impact, high-risk flows—critical user journeys and known failure modes—then expand coverage using production signals over time.

Details:
Seed your golden test set with:

• Mission-critical workflows (e.g., loan applications, account updates, policy advice).
• Past incidents (where hallucinations, PII leaks, or bad tool calls occurred).
• Edge cases and adversarial prompts.

As you run in production, use Signals to detect new failure patterns (“unknown unknowns”), then convert those patterns into new test cases and evaluators. The test set should be a living asset that mirrors how users and attackers actually behave.

---

How strict should our CI thresholds be when using Galileo Evaluate?

Short Answer: Start with thresholds that match your current baseline, then tighten them as you gain confidence and improve prompts/models.

Details:
Initial thresholds should reflect “no worse than today”:

• Run your current production configuration against the golden test set.
• Record baseline scores for correctness, hallucination, and safety.
• Set CI to fail only when:
  • A metric falls below baseline by more than a small tolerance (e.g., −2% correctness).
  • Any safety-critical metric (like PII leak rate) is non-zero.

Over time, as you tune prompts and add better evaluators, you can ratchet thresholds upward to drive continuous quality improvement, while still preventing regressions.

---

Summary

Setting up Galileo Evaluate to run prompt/model regression tests in CI before deploy is how you stop flying blind. You turn real traces into a golden test set, attach evaluators that measure correctness, hallucination, safety, and agent behavior, and wire those into your CI system as hard gates. Every change to prompts, models, or retrieval is now judged against your quality contract—using Luna‑powered evaluators that are cheap and fast enough to run on every commit. And once you trust those evaluators, you promote them into Protect so the same rules that block a bad build also intercept bad actions in production.

---

Next Step

Get Started