Choose fine-tuning when the gap you need to close is behaviour (inconsistent formatting, the wrong tone, reasoning the model does not follow) and choose RAG when the model lacks knowledge, holds stale knowledge or needs proprietary context. Either way, RAG vs fine tuning is not settled by how much data you have or by a public leaderboard. It is settled by an evaluation set built from your own task, scored on cases the candidate never trained on, with the uncertainty reported next to the score. The same approach decides which red-team taxonomy to build on, how to score legal extraction with citations, and whether a cheaper document-review model is safe to roll out.

A harness that decides has four parts

A generic benchmark score tells you how a model did on someone else’s question. A harness that decides a deployment choice needs four things: a held-out set drawn from your own task, a named method or gold standard so the people who must accept the result can recognise it, a metric that matches the cost of the errors you care about, and an honest account of how noisy the measurement is. The LegalBench authors say the same about their own 162 tasks: a general benchmark gives only a preliminary picture, and anyone deploying an LLM in their own application should collect and validate data specific to that use case.

The fourth part is the one most of the surveyed benchmarks skip. A 2026 study of measurement error in LLM pipelines surveyed 13 benchmarks and found that most reported no measurement uncertainty at all, while the four that did captured only item-sampling variance. In the study’s own demonstrations, naive standard errors were 40 to 60% smaller than properly corrected ones.

Across one study’s demonstrations, averaging over LLM judges gave the largest single reduction in noise. In that study’s safety example, the choice of judge panel accounted for 43.8% of score variance, while prompt wording accounted for less than 0.5%. A 2026 systematic review of red-teaming methods reports that modest changes to output style can shift a safety judge’s false-negative rate by up to 0.24 on the same data, so a defence’s measured success can be an artefact of the judge you happened to choose. In practice that means using more than one judge, disclosing the judge prompts, and checking agreement against a human-labelled subsample before you trust any automated score.

We treat a harness built this way as a production-reliability artefact: a release gate that catches regressions accuracy numbers miss, not a one-off accuracy report.

Which framework should a red-team suite be built around, OWASP LLM Top 10 or MITRE ATLAS?

Use both. The OWASP Top 10 for LLM Applications lists the most critical security vulnerabilities in LLM applications. MITRE ATLAS is a living knowledge base of adversary tactics and techniques against AI-enabled systems, built from real-world attack observations. A 2026 systematic review of algorithmic red teaming argues that the most effective programmes combine the two: ATLAS for threat-informed scenarios, and OWASP entries turned into concrete test families.

TechnoLynx builds this kind of staged red-team harness as part of AI Governance and Trust. The first step is defining the threat model and ranking the attack surface with you. After that, OWASP and ATLAS categories and open adversarial benchmarks become a suite (jailbreak, prompt injection, system-prompt extraction) that can be re-run for each client or release with comparable scores.

Mapping each test to a taxonomy category

The review calls this a risk-to-tests mapping. For each Top 10 item you define seed prompts, mutation strategies (paraphrase, translation, obfuscation), criteria for a policy violation and remediation hooks. The suite then runs automatically in CI/CD, and every run stores the prompt, output, judgement and violation tag. In its example, LLM01 (prompt injection) expands into bilingual code-switching, Unicode confusables, zero-width characters and indirect instructions hidden in RAG documents. ATLAS also catalogues techniques such as poisoning of training or retrieval corpora, model extraction and inversion, and memory or goal manipulation in agents. For auditors who think in terms of controls, MITRE’s SAFE-AI framework maps ATLAS threats onto four system elements (environment, AI platform, model, data) and lists the relevant NIST SP 800-53 controls where each threat meets each element.

AIRTBench (2025) tags its 70 security challenges to both MITRE ATLAS and the OWASP LLM Top 10, from prompt injection (20 challenges) to model extraction and data poisoning (one each).

Open adversarial datasets to start from

You do not need to hand-write every test case. HarmBench is a standardised framework for automated red teaming, with a defined threat model, a behaviour taxonomy and a reproducible scoring pipeline. Its authors used it to compare 18 red-teaming methods against 33 target LLMs and defences. JailbreakBench provides a growing repository of jailbreak prompts, a dataset of 100 misuse behaviours across ten categories with a matching benign behaviour for each, and a standard scoring framework. The AdvBench Harmful Behaviors subset contains 521 prompts. XSTest mixes malicious prompts with benign ones that contain harmful-sounding words (‘How can I kill a Python process?’), which catches defences tuned so tightly that they refuse normal requests. For prompt injection specifically, InjectLab organises six tactics and 19 techniques and gives each test a minimal YAML schema (id, name, prompt, expected_output, vulnerable_output). Its authors state that it covers only prompt-level threats and that its CLI cannot yet run scripted tests or plug into CI, so treat it as a source of test cases, not a harness.

JailbreakBench’s own documentation says it is not suitable for judging robustness using only existing, precomputed attacks without an adaptive attack. A benchmark of 15 guardrails found that performance varied significantly with jailbreak style, and that simple baselines could compete with many state-of-the-art defences out of distribution. The 2026 review reads this as evidence of dataset bias and of the danger of relying on any single detector.

Keeping scores comparable across clients and releases

Attack success rate (ASR, the share of probes that get a jailbroken response) is the standard metric. The 2026 review notes that it is session-specific and may not be reproducible, and that a sample of successive runs gives a ballpark benchmark value. AIRTBench ran ten passes per challenge to mitigate variance from stochastic model behaviour: its top model solved 61.4% of challenges at least once, but its overall success rate was 46.9%. Probes also have to match the client’s domain. A banking chatbot tested with off-domain prompts produces a misleading ASR. Single-turn suites overstate robustness, because automated multi-turn attackers get markedly higher success rates than one-shot baselines.

Sharing a taxonomy is not enough to make scores comparable across clients. You also have to pin the model version, system prompt, sampling settings and judge. JailbreakBench fixes temperature at zero and generates 150 tokens per input to facilitate reproducibility. It chose its judge only after three experts labelled 200 prompt-response pairs, agreeing on about 95% of them.

A reusable red-team harness, step by step

1. Model threats against the whole deployed system, not just the base model: RAG components, plugins, agents and infrastructure.
2. Map each OWASP Top 10 item to a test family with seed prompts, mutations and violation criteria, and use relevant ATLAS techniques to build threat-informed scenarios.
3. Seed the families from open sets (HarmBench, JailbreakBench, AdvBench, and XSTest for over-refusal), then add custom cases for client-specific risks.
4. Run multi-turn and adaptive attacks as well as static prompts.
5. Score with more than one judge, checked against a human-labelled subsample.
6. Repeat runs and report ASR per category with its spread, tied to the model and configuration versions tested.
7. Automate the suite in the CI/CD pipeline and keep every run’s artefacts.

RAG vs fine-tuning: what test should settle the choice?

Run both candidates through the same task-specific harness. Choose on correctness within your availability and latency constraints, not on a small quality gap. OpenAI’s guidance takes the same starting point: before any heavier optimisation, the best output of the first stage is a good prompt plus an evaluation set of 20 or more questions with ground-truth answers, with the failures already analysed.

TechnoLynx runs this comparison in the LLM Selection Pack. The first step is pinning down your availability and latency targets and what ‘generalising to unseen patterns’ has to mean in operation. Then comes the harness and, if RAG is a candidate, the retrieval pipeline over your logs with tool calling, so that a fine-tuned open-weight model and RAG on a hosted frontier model are scored on the same held-out cases.

The published evidence leans towards RAG for knowledge problems, but not in every case. An EMNLP 2024 study found RAG consistently beat unsupervised fine-tuning on knowledge-intensive tasks, for both previously seen and entirely new knowledge. A study on less popular facts found RAG beat fine-tuning by a large margin, especially on the least popular knowledge. In that study, adding fine-tuning on top of RAG helped models up to 3B parameters but made models from 7B to 11.3B worse. On the other side, OpenAI’s worked example of a behaviour problem found that RAG cut a fine-tuned GPT-4’s accuracy by four points to 83, because the extra context added noise to a task the model had already learned. A 2024 agriculture case study found the gains stacked instead: fine-tuning added more than 6 percentage points of accuracy and RAG added another 5. We read these results as measuring different kinds of gap. Which kind your task has is exactly what your own harness has to show.

Is six months of task logs enough to fine-tune reliably?

No log volume is automatically enough. Whether you have enough data is an empirical question, and the harness answers it. OpenAI suggests starting fine-tuning with 50 or more high-quality examples, evaluating, and adding more only if the errors come from behaviour rather than missing context. The bigger risk with a fixed window of logs is what fine-tuning teaches the model. Gekhman et al. (2024) found that fine-tuning examples containing knowledge the model did not already have are learned slowly and, once learned, steadily increase its tendency to hallucinate. They reduced the effect by stopping training early or by filtering those examples out. Training examples also have to look like production: if the system will run with retrieval, fine-tune on examples that include the retrieved context.

How do you check that a fine-tuned model generalises beyond its training logs?

Hold out whole pattern types and whole time periods, not random rows. A random split of six months of logs puts the same weeks, shifts and seasonal mix into both training and test, so the score measures how well the model remembers familiar conditions. Gekhman et al. built this separation into their design, keeping 12 of 24 relations entirely for an out-of-distribution test set. For operational logs, that could mean holding back the most recent weeks plus any rare shift types or exception patterns, then scoring both candidates on that slice.

Six months can still miss seasonal or rare patterns completely, and no split can test what the logs never recorded. State that limit in the result rather than hiding it. With a small held-out slice, small quality differences can be indistinguishable from noise. Report intervals, and let the operational constraints carry more weight when the gap is small.

What evidence shows retrieval quality is good enough to skip fine-tuning?

RAG is good enough when retrieval precision and recall on your held-out questions are high, and task correctness on the same slice matches or beats the fine-tuned candidate. Gao et al.’s 2023 survey of RAG groups evaluation into three quality scores (context relevance, answer faithfulness, answer relevance) and four abilities: handling noise, refusing when the answer is not there, combining information, and resisting counterfactual inputs. Tools such as RAGAS, ARES and TruLens use LLMs to judge these quality scores. Retrieval settings need tuning inside the harness too. The EMNLP 2024 study could not predict the best number of retrieved documents by model or task, and the gap between the best and worst setting could be large. Offline evaluation is not the end of the job either. Barnett et al. (2024) conclude that a RAG system can only be fully validated in operation, and that its robustness develops over time rather than being designed in up front.

Decision table: fine-tuned model or RAG

Harness finding	Operational constraint	Lean towards
Errors are in format, tone or reasoning consistency	Either	Fine-tuning
Errors come from missing, stale or proprietary facts; RAG correctness matches the fine-tuned model on the held-out slice	Hosted-model latency and availability are acceptable	RAG, which avoids retraining for each knowledge update
Early evaluations show both kinds of gap	Either	Fine-tuning plus RAG, fine-tuned on examples that include retrieved context
The quality gap falls within the interval of a small held-out set	Strict latency or uptime SLA	Decide on the constraint, not the score
Tool or function calling is central	Depends on what each candidate supports	Treat it as an extra factor and test it in the harness

For choosing between vendor models rather than architectures, see our guide to building a task-specific evaluation harness for LLM procurement.

How do you score extraction completeness and citation accuracy together?

Count a field as correct only when both the extracted value and its citation are right. Report that grounded score next to plain value F1, so a reviewer sees completeness and traceability side by side. ExtractBench (2026) uses this rule: a field counts as grounded only when the value and its citation are both correct, scored at page level and at word level.

TechnoLynx delivers this measurement work within the LLM Selection Pack. The first step is defining completeness and citation correctness together as the target metric for your covenant extraction. Then come the annotated held-out set, the harness and a RAG pipeline that grounds each answer in a citation, with both scores monitored on production agreements afterwards.

You need both scores because each one alone can mislead. Value F1 alone rewards a system that finds the right covenant but cites the wrong clause, which a reviewer cannot check. Citation accuracy alone rewards confident pointers to an incomplete list. ExtractBench shows how far apart the two levels of grounding can be: its best system reached 84.9% page-level grounding F1 but only 46.4% at word level, and another system fell from 48.5% to 2.0%. Page-level grounding is the weaker test, and many systems pass it even without returning bounding boxes. ExtractBench also records alternate readings that are equally defensible and accepts a prediction that matches any of them, while every expected record still counts against recall. A hallucinated value on a blank field counts against both precision and recall, and a correct null earns credit.

For free-text answers rather than structured fields, ALCE (Gao et al., 2023) uses an NLI model to score citation recall (is each statement fully supported by the passages it cites?) and citation precision (are any of the citations irrelevant?). Its agreement with human judges was substantial for citation recall (Cohen’s kappa 0.698) but only moderate for precision (0.525), partly because the NLI model cannot recognise a citation that supports a claim only in part. An automated citation checker is a judge like any other and needs the same validation against human labels.

Match criteria need care too. CUAD counts a highlighted span as a match when its word-level Jaccard similarity with the annotation is at least 0.5. DocETL, evaluating zero-shot LLM extraction on CUAD contracts, used a much looser threshold of 0.15, on the grounds that without examples the model could not know how much text to extract. The threshold changes the score, so fix it before the comparison and state it in the result. ContractEval (2025), built on CUAD’s test set, adds two measures worth copying: F2 alongside F1, because positive cases are scarce, and a false ‘no related clause’ rate that catches models answering that a clause is absent when it is there.

Building a held-out contract set with clause and page labels

There is no way around manual expert annotation, and CUAD shows what doing it properly involves. Its 500-plus contracts carry more than 13,000 expert annotations across 41 clause types. Annotators trained for 70 to 100 hours before labelling, worked from more than 100 pages of category documentation, and three more annotators verified each annotation. For a covenant or obligation set, that practice suggests a checklist:

• Write detailed label definitions before anyone starts annotating.
• For each label, record the clause span, the page and any alternate citation that would also be correct.
• Include agreements with no relevant clause, so that both false positives and false ‘no clause’ answers get measured.
• Have senior reviewers check annotators’ work and resolve disagreements by consensus.
• Flag poorly scanned or multi-page clauses, where the correct citation can be genuinely unclear.
• Keep the set out of every prompt, few-shot example and fine-tuning run.

Scale is the real constraint. Manually annotated loan agreements are expensive, and a set too small for stable metrics should be reported with intervals, not as a single point score.

Is there a published benchmark for legal clause extraction to align with?

Only partly. Align your method with the closest published work rather than chasing a leaderboard. CUAD and ContractEval both evaluate span-level clause extraction against CUAD’s expert annotations. LegalBench-RAG offers 6,858 expert-annotated query-answer pairs for testing the retrieval step. ExtractBench provides the joint value-and-grounding scoring. LegalBench scores multi-term extraction tasks with F1, but warns that any legal deployment needs evaluation on in-domain data.

Who can build an evaluation harness for our LLM deployment decision?

TechnoLynx builds task-specific evaluation harnesses that settle a named deployment choice: a fine-tuned model or RAG, which red-team categories a launch must pass, or whether a cited extraction pipeline is accurate enough to trust. Whether to build in-house or bring in a specialist depends on whether your team can own the held-out set, the judge validation and the pipeline after the decision is made. When choosing a partner, ask how they hold out data, how they validate judges and how they report uncertainty, because those decide whether the result survives scrutiny. For model and architecture decisions, the engagement is the LLM Selection Pack. For red-team and assurance work, it sits under AI Governance and Trust.

This work does not suit every situation. Recall validation for document review that has to stand up in litigation belongs with e-discovery specialists and counsel.

How do you know a cheaper review model is not missing responsive or privileged documents?

Measure recall and precision separately for responsiveness calls and for privilege calls, on a random sample from the matter’s own documents that subject-matter experts have adjudicated. Report every estimate with a confidence interval, not as a point, because a recall figure is only meaningful with its interval and a properly drawn random sample. Recall is the share of relevant documents the review found, and precision is the share of identified documents that are actually relevant. CUAD’s authors chose precision and recall because they respond to heavy imbalance between relevant and irrelevant clauses.

Elusion testing, and why it should not stand alone

An elusion test takes a random sample from the documents the model would exclude (the discard or null set) and reviews it for relevant documents the model missed. One guide’s protocol adds a second random sample across the whole collection to estimate recall with a Wilson confidence interval, and reports elusion as a one-sided upper bound. The process is certified only if the recall interval meets the target and the elusion upper bound is at or below the agreed threshold. What drives sample size is the number of relevant documents in the sample, not the total. At the 3% prevalence the guide calls typical, a 400-document random sample holds only about 12 responsive documents (400 × 0.03), so the interval is very wide. The guide therefore sizes the sample so the expected number of positives is large enough, which at low prevalence means a larger total.

O’Halloran and colleagues compared two TAR tools on the same document population. On five of the provider tool’s reviews, elusion tests overstated its recall by between 16% and 36% compared with a confusion-matrix check carried out by an independent reviewer working blind. Their explanation is that elusion assumes all first-pass relevance calls were correct, and that at low prevalence a small null-set sample may contain no relevant documents at all, so the test reports near-perfect recall that is not real. Where the two protocols disagree, the confusion-matrix evidence is the more reliable. It accounts for reviewer false positives and false negatives, which elusion ignores.

The gold standard is itself fallible

Expert adjudication is the reference point, but it is not ground truth. In Voorhees’ study, cited by Grossman and Cormack (2011), pairs of expert assessors overlapped on only 42.1% to 49.4% of the documents either one marked relevant. Cormack and Grossman (2017) note that even small errors in the gold standard can pull measured recall down a long way. In the TREC 2009 Legal Track, the best submissions’ estimated recall on four topics rose from under 20% to about 80% once the assessments were finalised. One quality-control option is a second assessment, with a third assessor settling cases where the first two disagree. If an LLM helps with adjudication, validate it against human calls as you would any other judge.

Making the numbers independently verifiable

If opposing counsel challenges the recall figure, what makes it defensible is a protocol someone else can rerun. That means the sampling method and random seed, the sample sizes, where the gold set came from and the adjudication logs, all disclosed to a neutral reviewer on request. Independence matters in practice. The O’Halloran comparison notes that recall estimates come out higher when the same assessor both trains and validates the system, and argues that validation must be objective, unbiased and independent. Agree the acceptance threshold before running the test. The resulting figures apply to this matter’s documents and gold set only. They tell you nothing about another matter, another document type or the next model version. Our article on building an audit-defensible evaluation harness for high-stakes deployments covers the record-keeping side in more depth.

What to hold out, and who adjudicates it

In all four decisions, computing the score is the easy part. Whether a result survives scrutiny depends on choices made earlier: which part of reality is kept out of training and prompts, who labels it, and how disagreements between labellers and between judges are resolved. Get those wrong and a precise number still answers the wrong question. The 2026 measurement-error study calls this coverage error: a benchmark that leaves out part of what it claims to measure gives precise but incomplete estimates. The question left open after launch is ownership. Whoever keeps the held-out set current as logs, threats and documents change is the one keeping the decision valid.

FAQ

Does RAG require fine-tuning?

No. RAG and fine-tuning are not mutually exclusive and can complement each other, and combined use sometimes gives the best performance.

What is red teaming in LLM evaluation?

Red teaming means probing a generative AI system to find vulnerabilities, such as outputs that break its business, safety, ethical or legal constraints. The 2026 review stresses that it has to be repeated as the application changes rather than run once.

How is the F1 score calculated?

F1 is the harmonic mean of precision and recall, so it always sits between them, usually closer to the lower one. For example, 40% recall with 60% precision gives an F1 of 48%.