Technical LLM evaluation becomes difficult exactly where fluent output stops being enough. A generated patch may compile but break an existing workflow. A SQL query may execute but double-count revenue. A coding agent may report success while leaving the repository in a failing state. A rubric can look precise while two experienced reviewers interpret it differently.
The evaluation system therefore has to test more than the final response. It must define the task, control the environment, inspect outcomes and traces, combine the right graders, use technical experts for consequential judgment, and turn disagreement into better instructions. This guide explains how to structure that system for coding, SQL, database, data-pipeline, analytics, and technical agent programs.
Need a technical evaluation pilot? Datrick supports bounded coding, SQL, data, analytics, rubric, reference-answer, model-output review, calibration, adjudication, and quality-operations programs.
What technical LLM evaluation must establish
A useful evaluation answers a bounded decision. It may compare two models, validate a new agent release, determine whether a task family is ready for production, qualify contributors, improve a rubric, or measure whether a model can perform work under realistic constraints. The first step is to write that decision and identify who is authorized to act on the result.
Do not begin with a broad goal such as "measure coding quality." Define the users, languages, repositories, schemas, tool permissions, task families, expected outcomes, failure costs, and release decision. A benchmark that does not represent the intended work can produce a precise score that answers the wrong question.
| Layer | Question it answers | Required evidence |
|---|---|---|
| Task specification | What work is the system expected to complete? | Inputs, constraints, tools, environment, success criteria, prohibited behavior, and escalation rules. |
| Evaluation set | Does the sample represent real operating conditions? | Common cases, difficult cases, failures, ambiguous requests, risk categories, and protected holdout tasks. |
| Execution environment | Can the result be reproduced safely? | Pinned dependencies, schema and data state, tool versions, permissions, timeouts, logs, and reset behavior. |
| Graders | How is success measured? | Executable checks, state checks, rubric criteria, references, human review rules, thresholds, and grader versions. |
| Calibration | Do reviewers apply the standard consistently? | Worked examples, independent sample decisions, disagreements, adjudication, and revised guidance. |
| Quality operations | Can the program detect drift and correct it? | Acceptance, rework, disagreement, error taxonomy, escalation, turnaround, and rubric-change records. |
| Decision record | What changed because of the evaluation? | Baseline, comparison, limitations, unresolved risks, authorized decision, and follow-up checks. |
Use three grader types for different jobs
No single grader should carry every quality decision. Anthropic's published guidance for agent evaluations separates code-based, model-based, and human graders, with coding tasks commonly using executable tests for correctness and a rubric for broader code quality. OpenAI's Evals interface likewise treats test criteria, data-source structure, runs, and graders as explicit parts of an evaluation. The operating implication is straightforward: choose the most reliable grader for each claim instead of asking one judge for a universal score.
| Grader | Best use | Primary limitation | Technical example |
|---|---|---|---|
| Executable or deterministic | Claims with a verifiable state or rule. | Can miss valid alternatives or qualitative defects. | Tests pass, expected rows exist, forbidden files are unchanged, query stays read-only, schema matches. |
| Model-based | Repeatable rubric criteria across open-ended outputs. | Non-deterministic and capable of sharing the evaluated model's blind spots. | Assess explanation quality, compare two patches, classify failure type, check a response against a written rubric. |
| Human technical expert | Domain judgment, ambiguity, high-risk errors, and calibration. | Slower, more expensive, and inconsistent without a managed review process. | Review whether a migration plan is safe, a SQL assumption is defensible, or an agent used an unacceptable shortcut. |
Automated checks should verify what can be verified. Human experts should define and review what requires professional judgment. Model-based graders can then scale criteria that have been made explicit and calibrated. A model judge should not silently become the source of truth for a technical standard that humans have never agreed.
For further technical context, see Anthropic's guide to evaluating AI agents and the OpenAI Evals API reference.
How to evaluate coding LLMs and coding agents
A coding evaluation should run in a controlled repository and environment. The model or agent receives the task, available tools, repository state, and constraints. The harness records the complete attempt, including tool calls and final repository state. The graders then inspect both what changed and how the result was reached.
Define behavior before implementation style
Specify the user-visible or system-visible behavior that must change, the behavior that must remain unchanged, prohibited shortcuts, and the evidence required for completion. Do not make the reference patch the only acceptable answer when multiple implementations can satisfy the contract.
Separate fail-to-pass from pass-to-pass checks
New tests should fail before the correct change and pass afterward. Existing tests should continue to pass. This distinction exposes patches that satisfy the narrow task by breaking unrelated behavior. Add static analysis, security checks, type checks, lint rules, or performance limits only where they represent a real acceptance condition.
Inspect the trajectory, not only the final message
Review whether the agent read relevant context, changed authorized files, interpreted command output correctly, ran appropriate checks, recovered from failures, and reported evidence accurately. An agent that says "all tests pass" when tests were never run has failed even if the final prose is convincing.
Review engineering quality separately
Passing tests do not establish maintainability, security, appropriate scope, useful error handling, or respect for existing architecture. Apply a bounded rubric to these dimensions and require the reviewer to cite evidence from the patch or trace. Avoid vague criteria such as "good code" that cannot be adjudicated.
How to evaluate text-to-SQL models and data agents
Text-to-SQL evaluation needs a controlled database, representative schemas, realistic data, explicit access boundaries, and questions that reflect how users actually ask for information. Exact string matching is a weak primary grader because different queries can produce the same correct result, while a syntactically valid query can return the wrong business answer.
| Dimension | What to verify | Common plausible failure |
|---|---|---|
| Result correctness | Returned rows and aggregates match the intended question. | The query executes but answers a different interpretation. |
| Join logic | Keys, cardinality, direction, and fan-out are correct. | A many-to-many join silently duplicates revenue or activity. |
| Filters and scope | Status, tenant, geography, product, and time boundaries are applied. | Cancelled records or another tenant's data are included. |
| Nulls and duplicates | Missing values and duplicate records follow the business rule. | Null handling removes valid records or inflates a count. |
| Time semantics | Timezone, fiscal period, effective date, and late-arriving data are handled. | A monthly KPI shifts because UTC and local dates are mixed. |
| Permissions | The query uses allowed tables, columns, rows, and operations. | The result is correct but obtained through unauthorized data access. |
| Performance risk | Scan size, predicates, indexes, recursion, and concurrency are reasonable. | A correct query creates unacceptable warehouse or production load. |
| Ambiguity behavior | The system asks, states assumptions, or follows an authorized default. | The model invents the definition of active customer or revenue. |
Use execution-based checks against known result sets where possible, but retain technical review for business semantics and operational risk. A query can return the expected sample result for the wrong reason, especially when the sample is small. Include counterexamples, empty sets, duplicate keys, boundary dates, and adversarial schema names to expose brittle reasoning.
Design rubrics that can be calibrated and adjudicated
A rubric should describe observable evidence, severity, and decision boundaries. Each criterion needs to say what the reviewer inspects, what qualifies as pass or failure, how partial performance is handled, and which cases must be escalated. Keep correctness separate from explanation quality, style, safety, and efficiency so one strong dimension does not hide a critical failure in another.
- Draft from real work. Use accepted and failed examples, production incidents, reviewer questions, and task-owner expectations.
- Test independently. Have qualified reviewers score the same sample without discussing their decisions first.
- Classify disagreement. Separate reviewer error, rubric ambiguity, missing context, multiple valid answers, and genuinely borderline cases.
- Adjudicate with authority. Route unresolved cases to the person authorized to define the program standard.
- Revise and version. Update criteria and examples, record the decision, and decide whether previous work needs re-review.
- Monitor drift. Sample ongoing work and watch disagreement, rework, and error categories as the task mix changes.
Reviewer agreement is not the same as correctness. Reviewers can consistently apply a bad rubric. Pair agreement measures with expert adjudication, executable evidence, and periodic challenge tasks designed to expose blind spots.
Build representative evaluation tasks without contaminating the test
Start from real task families, then create a distribution that covers routine work, hard work, ambiguous requests, incomplete context, safety boundaries, known historical failures, and cases where the correct action is to ask or stop. Preserve a protected holdout set for release decisions. If model developers, prompt authors, or contributors repeatedly see the complete test bank, the evaluation can become a memory test rather than a capability measure.
Record task provenance, permissions, sensitive-data treatment, version, expected skills, known limitations, and whether the item may have appeared in training or public benchmarks. Synthetic variations can broaden coverage, but a technical expert should verify that they remain coherent and preserve the intended difficulty.
Managed human evaluation for coding and SQL programs
A managed evaluation team is more than a list of available engineers. The program needs contributor matching, access controls, onboarding, calibration, queue ownership, review, escalation, feedback, versioned instructions, and delivery reporting. Without those controls, adding more reviewers can increase inconsistency faster than capacity.
Datrick's fit is technical evaluation work that benefits from practical judgment across software, SQL, databases, data pipelines, BI, analytics, migrations, debugging, and operating workflows. Generic high-volume annotation that does not require this reasoning is not the primary service.
A responsible pilot sequence
- Select one bounded task family and name the program owner and quality decision owner.
- Review instructions, examples, rubric, environment, security, expected volume, and contributor profile.
- Run a small calibration sample with independent decisions and documented questions.
- Adjudicate disagreement and revise the task, rubric, examples, or contributor guidance.
- Deliver a controlled pilot with first-pass review, quality checks, escalation, and visible queue status.
- Close with acceptance, rework, disagreement, error taxonomy, turnaround, limitations, and a written recommendation.
The pilot should be allowed to conclude that the task is not ready to scale. Unclear instructions, unstable environments, insufficient source data, weak reference answers, or an unowned quality decision are program risks, not reasons to manufacture throughput.
Warning signs in a technical evaluation proposal
- One overall score combines correctness, style, safety, and usefulness without showing critical failures.
- The evaluation checks only the final response and ignores repository, database, tool, or environment state.
- Exact-match grading rejects semantically correct SQL or valid alternative implementations.
- An LLM judge is used at scale before comparison with trusted human technical decisions.
- Reviewers receive credentials or titles but no task-specific calibration sample.
- Disagreement is averaged away instead of classified and adjudicated.
- Benchmark tasks are public, repeatedly exposed, or too similar to training examples.
- The program reports completed units but not acceptance, rework, error categories, or rubric changes.
- No one is authorized to resolve ambiguous definitions of correctness.
- The vendor promises a quality target before reviewing the task, baseline, and operating constraints.
Frequently asked questions
What is technical LLM evaluation?
Technical LLM evaluation measures whether a model or agent produces correct, useful, and operationally responsible work in domains such as software engineering, SQL, databases, data pipelines, analytics, and technical workflows. It combines task design, executable checks, model-based graders where appropriate, human expert review, calibration, and adjudication.
How do you evaluate coding LLMs?
Evaluate coding LLMs in a controlled repository and runtime using tests for required behavior, regression checks for existing behavior, static analysis where useful, and technical review of the patch and execution trace. The evaluation should also check constraint compliance, tool use, security, maintainability, and whether the claimed result matches the final repository state.
How do you evaluate text-to-SQL models?
Evaluate text-to-SQL models against a controlled schema and dataset. Check execution success, result correctness, filters, joins, grouping, null and duplicate behavior, date and timezone logic, permissions, performance risk, and the assumptions made when the request is ambiguous. Exact query matching alone is insufficient because different SQL statements can be semantically equivalent.
When do you need human experts instead of only an LLM-as-a-judge?
Use human experts when correctness depends on domain context, multiple solutions may be valid, the rubric is new or ambiguous, errors carry operational risk, or a model-based grader has not been calibrated against trusted human decisions. Model-based graders can help scale repeatable criteria, but they should not silently define the quality standard they are meant to measure.
How does a managed LLM evaluation pilot work?
A managed pilot begins with one bounded task family, representative examples, contributor requirements, a draft rubric, security controls, and an authorized decision owner. A calibration sample is reviewed and adjudicated before broader delivery. The pilot closes with quality findings, disagreement patterns, rubric changes, delivery evidence, and a recommendation to expand, revise, or stop.
Start with one task family and a visible quality decision. Datrick can review the task, contributor profile, rubric, reference answers, environment, security controls, calibration method, review plan, and pilot evidence before recurring delivery is proposed.