39 — WebGPT / Tool-Augmented LM

Answer:

WebGPT (Nakano et al., OpenAI, 2021) fine-tunes a language model to browse the web by learning an explicit action space (search, click, scroll, quote, done) from human demonstrations, then refines the policy with reinforcement learning from human feedback (RLHF). Tool-Augmented LMs more broadly (TALM, Toolformer) generalize the idea: models learn when and how to call arbitrary APIs mid-generation, in some cases without any explicit human labeling of individual calls.

The problem this solves: a base LLM has no built-in way to know when it needs external information versus when its parametric knowledge suffices, or how to reliably issue a well-formed retrieval action at exactly the right point in generation. Rather than relying on prompting alone to induce this behavior, WebGPT bakes the decision of when/how to search directly into the model's learned weights — it is the formal precursor to modern agentic web RAG (#31) and general tool-use patterns, differing in one key dimension: the retrieval policy is learned, not prompted.

Answer:

The distinctive mechanism is a fine-tuned, RLHF-trained policy over a fixed action space, rather than an in-context instruction telling an already-capable model which tools exist and when to use them. Concretely: WebGPT's model weights themselves encode "when to search, when to click, when to quote, when to stop" as learned behavior, refined by comparing pairs of full browsing transcripts and training a reward model on human preferences between them.

This has two direct consequences that distinguish it from every prompted agentic system in this bank: (1) the behavior doesn't depend on the base model's instruction-following quality, since the policy is the fine-tune; and (2) the action space is fixed at training time — adding a new action (a new tool) requires collecting new demonstration/preference data and retraining, not just editing a system prompt (Q13).

Answer:

At each generation step, the model emits either a regular text token or one of five structured browser actions:

Input: "What is the population of Tokyo as of 2023?"

Model turn 1: <search>Tokyo population 2023</search>
→ Results returned: [result_0: "Tokyo - Wikipedia", result_1: "World Atlas: Tokyo", ...]

Model turn 2: <click>0</click>
→ Page content returned

Model turn 3: <quote>As of 2023, the Greater Tokyo Area has approximately 37.4 million people</quote>

Model turn 4: <done/>
→ Answer generated with quoted evidence

The loop repeats — policy model emits an action, the action executor runs it against a sandboxed browsing environment, the citation collector records any quote calls alongside their source — until the model emits done, at which point the answer synthesizer composes the final answer using only the explicitly quoted evidence. The quote action is the architectural feature that gives WebGPT excellent citation quality by construction: evidence isn't reconstructed after the fact, it's collected as an explicit, auditable part of generation itself.

Answer:

Step 1 — Behavior Cloning (BC)
  Human demonstrators browse and answer questions.
  Fine-tune GPT-3 on (question, action_sequence, answer) triples.

Step 2 — RLHF
  For two WebGPT answers to the same question, humans choose which is better.
  Train a reward model on (answer_A, answer_B, preference) pairs.
  Fine-tune with PPO using the reward model signal.

Behavior cloning gives the model its initial competence at the mechanics of browsing — issuing well-formed actions, navigating a page, producing something resembling a coherent answer — by direct imitation of recorded human demonstrations. RLHF then refines quality beyond what imitation alone can teach: humans compare full transcripts (not individual actions) and express a preference, which trains a reward model to score entire browsing-and-answering behavior, and PPO then optimizes the policy against that learned reward. This two-stage structure — imitate first, then optimize against a learned preference signal — is the same recipe used for instruction-tuning LLMs generally; WebGPT applies it specifically to the browsing-action domain.

Answer:

Toolformer (Schick et al., 2023) removes WebGPT's dependency on human demonstrations entirely by using the model's own perplexity as the training signal:

# Step 1: Sample candidate positions for API calls
text = "The Eiffel Tower is [POSITION] meters tall."
candidate_apis = ["calculator(height_lookup('Eiffel Tower'))"]

# Step 2: Check if the API call reduces perplexity on the continuation
perplexity_without = lm_perplexity("...is meters tall. It was built in 1889.")
perplexity_with    = lm_perplexity("...is 330 meters tall. It was built in 1889.")
# If perplexity_with << perplexity_without → keep this API call in training data

# Step 3: Fine-tune on filtered (text, API_calls) pairs
# Model learns: when an API call helps, emit it mid-generation

The insight is that a correct, helpful API result should make the subsequent text more predictable to the model (lower perplexity), while an unhelpful or irrelevant call shouldn't move perplexity much — this gives a fully automatic, self-supervised way to decide which candidate API insertions are worth training on, with no human labeling step at all. Toolformer supports a small fixed set of APIs (Wikipedia search, calculator, calendar, a QA model, machine translation) discovered this way, trading WebGPT's richer, human-validated behavior for dramatically cheaper data collection.

Answer:

WebGPT learns its retrieval policy through RLHF — the model is fine-tuned on human-labeled browsing demonstrations and preference comparisons, so the decision of when and how to search is internalized as model weights. Agentic Web RAG prompts an existing, already-capable model with a tool definition and relies on the model's instruction-following ability to trigger the right tool calls at the right time.

The advantage of the learned approach is consistent behavior on ambiguous queries where instruction-following alone is uncertain, since the decision was directly optimized rather than inferred from a prompt. The advantage of the prompted approach is that no fine-tuning is required and the system generalizes to new tools simply by updating the prompt. In 2024+, dramatic improvements in base-model instruction-following quality (GPT-4/Claude-class models) largely closed this gap, making the prompted approach the practical default (Q20) — WebGPT's learned-policy approach today is mainly relevant as the conceptual precursor establishing that retrieval policy can be learned, not as a production pattern most teams reach for.

Answer:

Toolformer (Schick et al., Meta, 2023) teaches models to call APIs mid-generation without human demonstration data, using the perplexity-reduction filtering described in Q5: sample candidate API-call insertion points, keep only the ones that measurably help the model predict subsequent tokens, and fine-tune on the filtered dataset.

The core difference from WebGPT: WebGPT requires human demonstrators (to generate the initial behavior-cloning data) and human preference labelers (to train the RLHF reward model); Toolformer is entirely self-supervised, needing no human-in-the-loop data collection at all. The trade-off runs in the opposite direction on quality: WebGPT's human signal produces more reliable, higher-quality citation and browsing behavior, since humans directly validate what "good" browsing looks like; Toolformer is far cheaper to train, but its API-call accuracy and judgment about when a call genuinely helps is correspondingly less refined, since it's optimizing a perplexity proxy rather than direct human judgment of usefulness.

Answer:

The filtering logic has three concrete steps, extending the Q5 sketch into something closer to a runnable pipeline:

def generate_candidate_insertions(text: str, api_specs: list[dict]) -> list[dict]:
    """Sample plausible positions where each API might help, using the base
    model's own token probabilities to identify positions with high uncertainty
    (candidates for where an external lookup would reduce perplexity)."""
    candidates = []
    for position in high_uncertainty_positions(text):
        for api in api_specs:
            call_text = api["format_call"](text, position)
            candidates.append({"position": position, "api": api["name"], "call": call_text})
    return candidates

def filter_by_perplexity_reduction(text: str, candidates: list[dict], threshold: float = 0.5) -> list[dict]:
    kept = []
    for c in candidates:
        result = execute_api_call(c["call"])
        text_with_result = insert_at_position(text, c["position"], result)
        ppl_without = lm_perplexity(text[c["position"]:])
        ppl_with = lm_perplexity(text_with_result[c["position"]:])
        if ppl_with < ppl_without * (1 - threshold):  # meaningful reduction, not noise
            kept.append({**c, "result": result})
    return kept

def build_toolformer_training_set(corpus: list[str], api_specs: list[dict]) -> list[dict]:
    dataset = []
    for text in corpus:
        candidates = generate_candidate_insertions(text, api_specs)
        kept = filter_by_perplexity_reduction(text, candidates)
        if kept:
            dataset.append({"text": text, "api_calls": kept})
    return dataset

The threshold parameter directly controls training-data quality vs. quantity: a stricter threshold keeps only clearly-helpful calls (cleaner signal, less data), a looser one includes marginal cases (more data, more noise) — this is the main tuning knob for reproducing Toolformer's approach on a new API set.

Answer:

Gorilla (Patil et al., Berkeley, 2023) applies the same "learn to use tools, don't just prompt for it" principle to a narrower, more tractable domain: generating correct calls to ML model APIs.

# Standard model: hallucinate API parameters
query = "Generate an image of a cat using Stable Diffusion"
# LLM output: stabilityai.generate(prompt="cat", version="wrong_version")  ← hallucinated

# Gorilla: retrieval-augmented fine-tuning for APIs
# Training: (query, retrieved_API_doc, correct_API_call) triples
# At inference: retrieve relevant API docs → generate correct call
query = "Generate an image of a cat using Stable Diffusion"
# Gorilla: from diffusers import StableDiffusionPipeline
#          pipe = StableDiffusionPipeline.from_pretrained("CompVis/stable-diffusion-v1-4")  ← correct

The training-signal difference from both WebGPT and Toolformer is what makes Gorilla practical: API calls are verifiable — you can execute the generated code and check whether it runs and produces the expected type of output, giving a cheap, automatic, and objective correctness signal, unlike WebGPT's expensive human preference comparisons or Toolformer's indirect perplexity proxy. Gorilla also explicitly retrieves the relevant API documentation before generating a call (a RAG step folded into the fine-tuning data), rather than relying purely on parametric memorization of API signatures, which is what lets it stay accurate as APIs evolve without needing a full retrain for every new library version.

Answer:

The most consequential trade-off is between action-space granularity and data requirements: WebGPT's five-action space was deliberately kept small precisely because every additional action multiplies the combinatorial space of transcripts humans need to demonstrate and compare, which is also exactly why extending the action space later (Q13) is so costly relative to just editing a prompt in a prompted system.

Answer:

Because the quote action makes evidence collection explicit and auditable, evaluation can check something stronger than general factuality — whether every claim in the final answer traces back to an actual quoted passage:

1. Citation coverage — what fraction of factual claims in the generated answer have a corresponding quote action backing them? A claim with no matching quote is either derived from parametric knowledge (acceptable if flagged) or unsupported (a defect).
2. Citation accuracy — for each quote, does the quoted text actually appear verbatim (or near-verbatim) in the source page the model clicked into? This catches a model paraphrasing and mislabeling it as a direct quote.
3. Human preference win rate — the same pairwise comparison methodology used to train the reward model (Q4) doubles as an evaluation tool: sample transcripts from a candidate model version, have humans compare against a baseline, and track win rate over time as a regression signal.
4. Task success rate — for questions with a verifiable correct answer, straightforward accuracy, segmented by whether the model needed to browse multiple pages vs. answer from the first search result, since multi-hop browsing is where WebGPT-style systems are most likely to accumulate errors.

The quote-action architecture is what makes citation accuracy checkable at all with simple string matching, in contrast to a prompted system's post-hoc attribution (Q6's comparison table), which typically has to infer which retrieved passage a claim came from after the fact.

Answer:

Given how much more expensive fine-tuning a policy is (Q15) compared to prompting an existing model, the decision should be benchmarked, not assumed:

1. Define the task's action space precisely (what tools/actions are actually
   needed) and confirm it's stable -- if new actions are expected within
   the product roadmap's timeframe, this immediately favors prompting (Q13).

2. Build a golden eval set of representative queries with graded transcripts
   (what a good browsing/tool-use sequence looks like, not just the final
   answer) so both approaches can be scored on process, not just outcome.

3. Baseline: prompt a strong current model with the tool definitions and
   measure task success rate, citation quality (Q11), and latency.

4. Candidate: fine-tune (via BC + RLHF, or a lighter-weight SFT-only pass if
   full RLHF is infeasible) a smaller/cheaper model on the same task's
   demonstration data, and measure the same three metrics.

5. Compare: (a) quality delta, (b) cost delta -- fine-tuning's one-time
   training cost plus ongoing retraining cost as the task evolves, vs.
   prompting's per-query cost on a larger base model, (c) latency delta
   (a fine-tuned smaller model is frequently faster per Q16).

6. Gate: only choose fine-tuning if quality parity or better is achieved
   AND the cost/latency advantage amortizes within an acceptable time
   horizon given expected query volume -- otherwise default to prompting.

The gate's purpose is making explicit that fine-tuning is rarely justified by quality alone when a capable base model can be prompted adequately (Q20) — it becomes worthwhile specifically when cost or latency at scale, or reliability on a narrow/stable task, dominate the calculation, which is the same logic Q18 walks through as a standing decision framework.

Answer:

WebGPT's policy is trained end-to-end against exactly five actions (search, click, scroll, quote, done). If a new capability is needed — say, a calculator action, or a code-execution action — it cannot simply be added to a running system, because the policy model's weights have no representation for an action it never saw during behavior cloning or RLHF. The only path to adding it is collecting new demonstration data covering the new action, retraining the behavior-cloning stage, collecting new preference comparisons that include transcripts using it, and re-running RLHF — the full pipeline, not an incremental patch.

Symptom in production: a fixed-action-space system gradually falls behind as the surrounding tool ecosystem grows (new APIs, new data sources becoming relevant), because every addition requires a multi-week-to-multi-month retraining cycle rather than a same-day prompt edit. This is precisely the maintenance-cost gap the WebGPT vs. Agentic Web RAG comparison (Q6) captures, and it's the single largest reason prompted tool use displaced learned tool use for general-purpose agents (Q20) — the tool landscape simply moves faster than a fixed action space trained via RLHF can practically track.

Answer:

Two failure directions, both traceable to the same root cause — perplexity reduction is a proxy for helpfulness, not helpfulness itself:

• False positive (keeps an unhelpful call): an API call can reduce perplexity on the immediate continuation for reasons unrelated to genuine usefulness — e.g., inserting any plausible-looking number before "meters tall" makes the following tokens more predictable in a purely statistical sense, even if the number is wrong, simply because a number is more predictable there than the placeholder. The model then learns to insert API calls in positions where "some numeric answer" helps prediction, without the training signal actually confirming the correctness of the inserted value.
• False negative (discards a genuinely helpful call): if the surrounding text is already highly predictable regardless of the API result (a formulaic sentence structure), the perplexity delta from adding a correct API call can be small even when the call is factually important — the heuristic under-weights calls whose value is correctness rather than predictability.

Debugging playbook: (1) sample kept and discarded candidate calls and manually audit a subset against ground truth — is the model learning "call the API when it's factually necessary" or "call the API when it happens to reduce local perplexity," which are correlated but not identical; (2) tighten the perplexity-reduction threshold (Q8) if false positives dominate, or lower it and add a secondary correctness-verification filter (e.g., cross-check the API result against a second source) if false negatives dominate; (3) since this heuristic has no direct signal for factual correctness, treat perplexity reduction as a candidate-generation filter only, and add an explicit downstream correctness check wherever the domain allows one (as Gorilla does by making generated calls executable and verifiable, Q9) rather than trusting perplexity reduction as the final word on data quality.

Answer:

The dominant cost driver is the human-data pipeline, not compute: behavior-cloning demonstrations and RLHF preference comparisons each require paid human labor per example, and this cost recurs every time the action space or domain shifts meaningfully enough to need a new training round (Q13). Illustrative comparison: a prompted agentic system's marginal cost of adding a new tool is a prompt edit (effectively free, redeployed same-day); a WebGPT-style system's marginal cost of adding a new action is a new data-collection and RLHF cycle, which for a team paying for human demonstrations/comparisons can easily run into the tens of thousands of dollars and weeks of calendar time before the new capability ships. This asymmetry — not raw model quality — is the primary reason production teams building general-purpose tool-using agents default to prompting today.

Answer:

WebGPT's action loop is inherently sequential: search → wait for results → click → wait for page load → possibly scroll → quote → possibly more searches → done, with each step requiring a full forward pass through the policy model plus a network round-trip to the browsing environment. A multi-hop question that needs several searches and page visits can take 3–10 seconds end-to-end, dominated by the sequential dependency between actions (each action's input depends on the previous action's output, so none of these steps can run in parallel within a single transcript).

Modern agentic systems reduce this in ways WebGPT's architecture didn't originally support: (1) parallel tool calls — a prompted agent can issue several independent tool calls in a single turn (e.g., search three different sub-queries simultaneously) when they don't depend on each other's results, collapsing what would be several sequential WebGPT-style turns into one; (2) caching — repeated or overlapping searches across users/sessions can be served from a semantic cache rather than re-querying live search; (3) smaller, faster policy/orchestration models for the decision-making step itself, reserving a larger model only for final synthesis, similar to the model-tiering pattern used across other multi-step architectures in this bank (ToT-RAG, agentic RAG). WebGPT's fundamentally sequential design is a structural latency ceiling that these techniques work around rather than eliminate — a genuinely multi-hop question still requires multiple round trips no matter how each individual step is optimized.

Answer:

• Reward hacking — PPO optimizing against a learned reward model (Q4) can discover browsing/citation behaviors that score well on the reward model without genuinely being high-quality — e.g., quoting text that sounds authoritative-looking without being the most relevant passage, if the reward model happens to correlate authoritative-sounding phrasing with its training preferences more strongly than true relevance. This is a general RLHF risk, but it's especially consequential here because the reward model is trained on preferences over entire browsing transcripts, which is a much higher-dimensional and harder-to-fully-specify preference than typical single-response RLHF.
• Browsing environment exploitation — since the policy interacts with a (simulated or real) web environment, a page specifically crafted to game the model's click/quote behavior (analogous to SEO manipulation, but targeting a specific trained policy's known preferences) could get itself preferentially quoted regardless of actual relevance or accuracy, especially if the training data didn't anticipate adversarial pages.
• Distributional shift between training and deployment — a policy trained on a fixed snapshot of demonstration/preference data can behave unpredictably on query types or web content patterns that didn't appear during training, with no mechanism (unlike a prompted system, where the prompt itself can be quickly patched) to correct the behavior short of a full retraining cycle (Q13).
• Opacity of the learned policy — unlike a prompted system's decision logic (readable in the system prompt), a fine-tuned policy's decision-making is embedded in weights, making it harder to audit why the model chose to search, click, or quote in a specific instance beyond inspecting the actual transcript it produced.

Mitigation follows general RLHF safety practice: diverse and adversarially-aware preference data collection, ongoing monitoring of production transcripts for reward-hacking patterns not seen during training evaluation, and — given Q13's retraining cost — accepting that a learned policy's response to a newly-discovered exploit is inherently slower than a prompted system's, which argues for keeping the action space narrow and well-understood rather than broad and speculative.

Answer:

Fine-tune for tool use when:

1. Reliability matters more than flexibility — a fine-tuned model reliably calls the right API with correct parameters on the trained action space; prompting can fail unpredictably on edge cases where instruction-following alone has to carry the whole decision.
2. The tool space is narrow and stable — with exactly two or three tools that won't change (search, calculator), the one-time cost of fine-tuning amortizes over a long deployment lifetime without the retraining tax (Q13) becoming a recurring burden.
3. Verification signal is cheap — Gorilla (Q9) fine-tunes for API calls specifically because correctness is directly verifiable (execute the generated code, check it runs and returns the right type), which is what makes the training loop tractable and self-correcting in a way WebGPT's human-preference loop is not.
4. Latency budget is tight — a smaller, fine-tuned model can outperform prompting a much larger general-purpose model on latency for a narrow task (Q16), since it doesn't need the extra capacity a general model spends on broad instruction-following.

Use prompting instead when the tool space is evolving (new tools added regularly), latency is tolerable, or the system is still in an exploratory/prototyping phase before anyone has committed to the cost of fine-tuning at all — which describes the majority of production agentic systems today (Q20), and is why prompted tool use, not learned tool use, is the default starting point for a new project.

Answer:

• WebGPT — Nakano et al., WebGPT: Browser-assisted question-answering with human feedback (OpenAI, arXiv:2112.09332, 2021). Established the behavior-cloning-then-RLHF recipe for a structured browsing action space.
• TALM — Parisi et al., TALM: Tool Augmented Language Models (arXiv:2205.12255, 2022). An early generalization of WebGPT's idea beyond browsing specifically, toward arbitrary tool APIs, using an iterative self-play-style bootstrapping approach.
• Toolformer — Schick et al., Toolformer: Language Models Can Teach Themselves to Use Tools (Meta, arXiv:2302.04761, 2023). Removed the human-demonstration requirement via the perplexity-reduction self-supervision described in Q5.
• Gorilla — Patil et al., Gorilla: Large Language Model Connected with Massive APIs (Berkeley, arXiv:2305.15334, 2023). Applied the same learned-tool-use principle to a verifiable, narrow domain (ML API calls).

The lineage runs from "learn a small, fixed browsing action space with expensive human supervision" (WebGPT) toward progressively cheaper and more automated training signals (Toolformer's self-supervision, Gorilla's execution-based verification) — each step trading some of WebGPT's behavioral reliability for lower data-collection cost, which sets up the eventual displacement by prompted tool use (Q20) once base models became reliable enough that even the cheapest fine-tuning approach's cost stopped being worth it for general-purpose agents.

Answer:

Limitations: (1) fixed action space requiring full retraining to extend (Q13); (2) high, recurring human-data cost for both the WebGPT-style and (to a lesser degree) even Toolformer-style approaches; (3) opacity relative to a prompt, making auditing and rapid incident response harder (Q17); (4) a learned policy's quality is capped by the quality and coverage of its training data, whereas a prompted system directly inherits improvements to the underlying base model for free.

That last point is precisely why prompted tool use displaced learned tool use in production between 2021 and 2024: as base models (GPT-4, Claude) improved dramatically at instruction-following, the accuracy gap that originally justified WebGPT's expensive fine-tuning largely closed — a well-prompted current-generation model reliably decides when to search and how to use a tool's output, without the retraining tax or the fixed-action-space ceiling. Prompted systems are also trivially easier to update (edit the prompt, not the model weights) and generalize to new tools immediately by adding a tool definition, matching exactly the properties Q13, Q15, and Q18 identify as WebGPT's core weaknesses.

WebGPT's core insight nonetheless persists in every modern agentic system: treating retrieval/tool-use as a first-class, deliberate decision — not a bolted-on post-processing step — is what lets a system know when not to search, avoiding both over-triggering (searching for things the model already knows) and under-triggering (failing to search when parametric knowledge is stale or absent). Modern systems achieve this decision through prompting and improved base-model judgment rather than RLHF fine-tuning, but the underlying principle WebGPT established — that this decision deserves explicit architectural attention — is what every subsequent tool-using system, learned or prompted, still builds on.

Answer:

Low stakes, a single casual user, and a tool space (web search, page fetch) that's likely to keep evolving all point toward prompting an existing capable model rather than any WebGPT-style fine-tuning (Q18's criteria run against fine-tuning here on every count).

What the situation implies: homework fact-checking doesn't carry the liability that would justify the cost and calendar time of behavior-cloning-plus-RLHF (Q15); the tool space (which search API, what to fetch) is exactly the kind of thing that changes over time, which Q13 flags as a poor fit for a fixed, learned action space; and the base model's own instruction-following is now good enough (Q6, Q20) to reliably decide when to search.

Recommended approach: use a prompted agentic system (Agentic Web RAG, #31) — give a current-generation model tool definitions for search and page-fetch and let it decide when to invoke them. Borrow WebGPT's core design insight rather than its training method: explicitly instruct the model to quote exact supporting text for each claim (mirroring WebGPT's quote action, Q3) even though this is implemented as a prompt instruction rather than a learned action — this captures much of WebGPT's citation-quality benefit (Q11) without any fine-tuning cost.

Trade-offs to flag: (1) a prompted system's citation reliability is "variable, post-hoc" rather than WebGPT's "excellent by construction" (Q6's comparison table) — acceptable here given the low stakes, but worth naming explicitly rather than assuming citation quality is solved; (2) if this assistant later needs to operate in a genuinely high-stakes, narrow, and stable domain, that's the point to revisit Q18's fine-tuning criteria — not before.

Answer:

The regulator-audit-trail requirement is a hard compliance constraint that shifts the calculus away from Q21's low-stakes case: here, citation completeness and logging discipline matter more than avoiding fine-tuning cost, and Q18's criteria for when to fine-tune — narrow and stable tool space, cheap verification signal — plausibly apply to at least part of this system.

Design: regardless of whether the underlying policy is prompted or fine-tuned, make WebGPT's explicit quote discipline (Q3) a hard architectural requirement, not an optional instruction — every claim in a generated compliance memo must have a corresponding quoted, source-linked passage, and the Citation Collector pattern (this file's own architecture) should be implemented as a mandatory, logged pipeline stage rather than left to the model's discretion. Every source URL touched, along with the exact quoted text and timestamp, must be retained for later regulator review (paralleling the audit-log discipline in Verifiable RAG's Q19 and Q18).

On fine-tuning vs. prompting specifically: if the desk's browsing needs are actually narrow and stable (a fixed set of regulatory-filing sources and financial-data APIs, not open-ended web search) and outputs are objectively verifiable (does the cited figure match the source document), that combination — per Q9's Gorilla precedent and Q18's criteria — makes a fine-tuned, verifiable tool-call approach worth evaluating alongside a prompted one, in contrast to Q21 where none of those conditions held. Run the decision-gate comparison from Q12 explicitly rather than assuming either approach by default, given how much more is riding on getting this right than in the homework-helper case.

What to monitor: citation coverage and citation accuracy (Q11) at effectively 100% sampling rather than a spot-check, given the audit-trail purpose; completeness of the retained log (every source URL plus quoted text, not a sample); and, if any fine-tuned component is used, periodic reward/behavior-drift audits (Q17) since a compliance desk cannot tolerate quietly degrading citation behavior between audits.