Proxy-Logging vs Evaluation-First Platforms | Scorable

Updated: 2026-03-27
By: Ari Heljakka

Short answer

A proxy-logging platform sits in front of your LLM provider, captures every request and response, and gives you dashboards, traces, caching, and basic metrics. An evaluation-first platform makes versioned objectives, managed evaluators, and calibrated judges the primary artifact, and the trace store is a downstream consumer of evaluation results. The two categories are not direct substitutes; one is centered on the call graph, the other on the success criteria that judge it. Mature teams usually run both, with the proxy layer handling traffic and the evaluation layer gating change.

Key facts

• Definition: Two distinct categories of LLM infrastructure: proxy-logging (call interception and trace storage) and evaluation-first (versioned objectives plus calibrated evaluators that gate releases).
• When to use: Proxy-logging when traffic visibility, caching, and per-request metrics are the binding constraint. Evaluation-first when measurable success criteria, regression gates, and judge calibration are the binding constraint.
• Limitations: Proxy-logging tells you what happened; it does not tell you whether what happened was correct. Evaluation-first requires investment in rubrics, calibration sets, and judge maintenance.
• Example: A team uses a proxy layer to track p95 latency and per-tenant cost; the same team uses an evaluation-first layer to block deploys that regress on faithfulness, citation grounding, or tool-call accuracy.

Key takeaways

• The two categories sit at different layers of the stack and answer different questions.
• A proxy that logs every call cannot, by itself, decide whether a release is shippable.
• An evaluation-first platform without trace coverage cannot see anomalies that emerge from production interactions.
• Versioned objectives, normalized to 0 to 1 per dimension, are the artifact that makes regressions detectable across model and prompt changes.
• Both categories are first-class infrastructure; treating either as a side concern leaves regressions undetected.

Definition

A proxy-logging platform is software that intercepts LLM API calls, often by swapping the SDK endpoint for a proxy URL, and records the request, response, model, latency, token counts, and cost for each call. It typically exposes dashboards, search, request replay, response caching, and rate limiting. The unit of work is the request; the source of truth is the trace.

An evaluation-first platform centers the architecture on versioned success criteria. Rubrics, datasets, and evaluators (deterministic checks and calibrated LLM judges) are first-class, queryable, immutable artifacts. Each evaluator produces a normalized score on an independent dimension; scorecards aggregate dimensions into release decisions. The unit of work is the evaluation run; the source of truth is the calibrated evaluator and the dataset it scores against.

These are different layers. A proxy can ingest into an evaluation system, and an evaluation system can post results back to a proxy's metadata, but neither replaces the other.

When this matters

The two categories address different operational pressures. The right framing is to identify which question is binding for your team.

• "What is happening in production right now?" Proxy-logging. Traffic-shape, error rate, latency, cost-by-tenant, prompt-by-prompt token usage. These are observability questions; they answer "what" and "how much."
• "Is this release as good as the last one?" Evaluation-first. Per-dimension scores against a versioned dataset, calibrated against human labels, gated in CI. These answer "is it correct."
• "Why did the user retry this turn?" Both. The trace shows the call graph; the evaluators score whether the response met the objective.
• "Should this deploy ship?" Evaluation-first by construction. A proxy that records every call cannot, by itself, decide whether the model's outputs satisfy the success criteria.

Many teams adopt a proxy first because the value is visible immediately (dashboards light up the day you ship it). Evaluation infrastructure earns its keep on the second or third regression it catches before users do.

How it works

A proxy-logging architecture

Every LLM call routes through the proxy. The proxy:

1. Records the request body, headers, model, and a request ID.
2. Forwards the call to the provider.
3. Captures the response, latency, token counts, and cost.
4. Stores the trace in a backend optimized for high-volume writes and search.
5. Exposes dashboards, alerts, and replay against the trace store.

The trace is the source of truth, and anything downstream (cost reports, anomaly detection, evaluator runs on sampled traces) reads from the trace store.

An evaluation-first architecture

The pipeline starts from objectives:

1. A versioned rubric defines the success criteria for a feature (faithfulness, tone, format, latency, cost).
2. A versioned dataset holds inputs, expected outputs (where applicable), and slice tags. New datasets are immutable snapshots; revisions create new versions.
3. Managed evaluators (deterministic checks and calibrated judges) score outputs against the rubric. Each evaluator has its own version, calibration set, and current agreement metric.
4. A scorecard aggregates per-dimension scores into a release decision. Scores are normalized to 0 to 1 so dimensions compose cleanly.
5. CI runs the scorecard on every prompt, model, or judge change; regressions below the threshold block the deploy.
6. Production traces (from a proxy, OTel collector, or direct instrumentation) are ingested as new candidate inputs; anomaly sampling routes a slice to annotation and back into the dataset.

The trace store is an input rather than the source of truth in this architecture, and the rubric, the dataset, and the evaluator agreement scores carry that role instead.

Example

A team building a research assistant ships a v1 with the following architecture.

Proxy-logging layer. All LLM calls go through a proxy. The team uses dashboards to confirm the rollout, watch p95 latency stay under 2 seconds, and break down cost by feature flag. When a sudden spike in token usage appears, the team uses request search to find that one prompt template is concatenating an unused tool description.

Evaluation-first layer. The team has four objectives: citation grounding, tool-call accuracy, answer relevance, and refusal correctness. Each objective has a rubric and a calibration set of 30 to 80 human-labeled examples. There are six evaluators in total: two deterministic (citation must appear in retrieved docs, JSON schema compliance) and four LLM judges (one per objective, each with its own calibration agreement metric tracked weekly).

CI runs the full scorecard on every prompt change. The team swaps the underlying model from a frontier provider to a smaller, cheaper alternative; the scorecard flags a regression in tool-call accuracy from 0.91 to 0.78. The team revises the system prompt for the new model, reruns the scorecard, and ships when accuracy is back to 0.93.

Neither layer is sufficient alone. The proxy could not have flagged the tool-call accuracy regression (it is a semantic failure, invisible to per-request metrics). The evaluation layer could not have flagged the runaway token usage (it is a traffic-shape issue, invisible to per-evaluation scoring).

Comparison

The two categories of platforms differ on where the source of truth lives and what artifacts are versioned.

Who should not adopt only one category

A team should not adopt only a proxy-logging platform if:

• Releases routinely produce silent quality regressions that show up days later in user complaints.
• Prompt or model changes happen weekly and there is no automated gate that catches semantic regressions.
• Multiple model providers are in rotation and you need apples-to-apples comparison across them.

A team should not adopt only an evaluation-first platform if:

• Real-time traffic visibility, per-tenant cost breakdown, or response caching is operationally critical.
• Inline guardrails in the synchronous path need sub-100 ms decisions on every call.
• Debugging a single misbehaving session requires reconstructing the full call graph, including tool calls and retries.

Where each category is stronger

• Proxy-logging is stronger for high-volume request observability, cost attribution, prompt playgrounds, response caching, traffic shaping, and quick incident triage. Its strength is the call graph and the trace as primary artifact.
• Evaluation-first is stronger for release gating, judge calibration, regression detection, dimensional decomposition of quality, and any system where correctness is judged by criteria that cannot be reduced to a per-request metric. Its strength is versioned objectives that remain stable across model and prompt swaps.

The right choice is rarely "one or the other." It is "which is binding now, and how will the other layer integrate later." Production-derived evaluation works best when trace ingestion is automatic; trace observability is most actionable when evaluation results enrich the trace metadata.

Limitations

• Proxy-logging captures traffic, not correctness. A request that returned 200 and looked plausible can still be wrong. Without an evaluation layer, that wrongness only surfaces through downstream metrics (refunds, churn, escalations).
• Evaluation-first requires upfront investment, but that cost is falling fast. Rubrics, calibration sets, and judge maintenance have historically cost engineering time, and teams that ship the first version of a feature with no evaluation infrastructure usually pay later, in regressions that reach users. The size of that upfront cost is shrinking, though: next-generation automations bootstrap the evaluation setup from the application's own context, generating candidate rubrics, dimensions, and seed datasets instead of asking a team to author them from scratch. That collapses much of the historical "evaluation is too expensive to start" objection. See Bootstrapping AI Evals from Context (Why 'Just Asking Claude' Fails for how this works in practice.
• Both categories drift. Traffic patterns shift; calibration agreement decays as judge models update. Treat both layers as continuously maintained infrastructure, not one-time integrations.
• Inline vs offline. Most evaluation happens offline or asynchronously; sub-100 ms guardrails belong in the synchronous path as deterministic checks. Do not put a hosted judge in your hot path.

Evidence and sources

• OpenTelemetry GenAI semantic conventions for LLM tracing. opentelemetry.io
• BIG-bench: a collaborative benchmark for evaluating LLM capabilities. github.com/google/BIG-bench
• HELM: a holistic framework for evaluating language models. crfm.stanford.edu/helm

FAQ

Can a proxy-logging platform run evaluations?
Yes, in the sense that it can call a scorer on sampled traces and store the result as metadata. What it usually lacks is first-class dataset versioning, judge calibration tracking, and regression gating against a calibrated set. Treat such plugin-style scoring as a stepping stone, not as a substitute for an evaluation-first layer.

Can an evaluation-first platform replace a proxy?
Rarely. Evaluation-first systems ingest traces, but they are not designed for the high-volume, low-latency call interception, caching, and per-request observability that proxies provide.

Do I need both from day one?
No. Start with whichever question is more painful. Most early teams hit observability pain first; evaluation pain shows up after the first or second silent regression. Plan for both, even if you adopt them sequentially.

How do I avoid double-counting metrics across the two layers?
Define one source of truth per metric. Per-request latency and cost live in the proxy; per-evaluation scores live in the evaluation system. The evaluation layer can read latency from the trace as a dimension of the scorecard, but it should not recompute it.

What about open-source tracing standards?
OpenTelemetry's GenAI semantic conventions are the right shared schema for both layers. A proxy that emits OTel spans, an evaluation system that ingests OTel spans, and a tracing backend that stores them give you portability across vendors.