Long-form factuality in large language models

🎯 Pitch

An automated fact-checking agent called SAFE beats human annotators at evaluating long LLM responses—agreeing with them 72% of the time and winning 76% of disagreements, while costing over 20× less. Larger models generally produce more factual long-form text, but standard precision metrics fail to predict human model preferences; a new F1@K metric that also penalizes missing information finally achieves strong alignment.

1. Executive Summary

This paper proposes a benchmark and evaluation methodology for measuring long-form factuality — the ability of language models to generate paragraph-length responses to open-ended fact-seeking prompts without producing factual errors. Using GPT-4 to generate LongFact — a prompt set of 2,280 questions spanning 38 topics — and evaluating model responses with SAFE (Search-Augmented Factuality Evaluator, an LLM agent that decomposes long-form responses into individual atomic facts, issues multi-step Google Search queries to gather evidence, and reasons about whether each fact is supported by search results), the authors benchmark thirteen models across four families (Gemini, GPT, Claude, and PaLM-2). SAFE matches or exceeds crowdsourced human annotators — agreeing with human labels on 72% of ~16k individual facts and winning 76% of 100 randomly sampled disagreement cases — while being more than 20× cheaper ( $0.19 vs.$ 4.00 per response), and the benchmark reveals that larger language models generally achieve better long-form factuality, as measured by the proposed F₁@K metric (extending F₁ score with a hyperparameter K representing human-preferred response length), establishing that factual precision alone correlates poorly with human model preferences ( $r = 0.502$ , $p = 0.205$ ) while incorporating recall via F₁@K achieves statistically significant correlation ( $r = 0.754$ , $p = 0.031$ ).

2. Context and Motivation

The Core Problem: Factuality Evaluation for Long-Form Responses Is Fundamentally Broken

The central problem this paper tackles is deceptively simple to state but extraordinarily difficult to solve: how do you measure whether a language model's several-paragraph-long response to an open-ended question is factually correct? This matters because modern LLMs are increasingly deployed in settings where users expect detailed, nuanced answers — think of someone asking "Tell me about the causes of World War I" rather than "When did World War I begin?" The short-answer case has a clear right answer that can be checked against a reference. The long-form case, however, contains dozens or hundreds of individual factual claims, each of which needs to be verified independently, and no single reference document comprehensively covers every possible claim a model might make.

This gap is significant for several reasons the paper develops throughout Section 1 and the Introduction:

Factual errors undermine trust in deployed systems. The paper opens by noting that LLMs "still lack reliability in responding to in-depth factuality questions" and "often produce factual errors in which a claim contradicts established ground-truth knowledge" (Section 1). When a model confidently asserts incorrect information about dates, statistics, historical events, or a celebrity's occupation, users lose confidence in the system as a whole — even if the rest of the response is correct. For high-stakes applications (medical advice, legal information, educational tools), factual errors are not mere annoyances but potential sources of real harm. Yet without a reliable, scalable way to measure factuality, developers cannot even detect these failures systematically, let alone fix them.

We cannot improve what we cannot measure. The paper positions long-form factuality evaluation as a prerequisite for progress. Without a benchmark that reliably quantifies how factual a model's long-form responses are, it is impossible to know whether architectural changes, training recipes, or inference-time strategies actually help. The field's rapid progress in model capabilities (Section 1 cites Brown et al., 2020; Chowdhery et al., 2022; Google, 2023; OpenAI, 2023; Gemini Team, 2023) has outpaced our ability to evaluate those capabilities along the factuality dimension, creating a dangerous asymmetry: models are getting better at sounding authoritative while we remain uncertain about whether they are getting better at being accurate.

The distinction between factuality and hallucination matters for evaluation design. The paper explicitly clarifies a terminological choice that shapes the entire evaluation framework (Section 1, footnote 2): they focus on factuality — correctness of claims with respect to external established knowledge — rather than hallucination — correctness with respect to the model's internal knowledge. This distinction is non-trivial. A model might internally "know" that a statement contradicts its training data but generate it anyway (a hallucination), or it might genuinely believe an incorrect fact because its training data was wrong (a factuality failure). The paper's evaluation approach (SAFE) is designed for the factuality case: it checks claims against Google Search results, not against what the model "should know." This scopes the problem to what is externally verifiable, which is both a strength (it enables automated evaluation) and a limitation (it cannot detect hallucination in the narrow sense).

Prior Approaches Fall Short Along Multiple Dimensions

The paper's review of existing work (Section 7, Related Work) identifies specific weaknesses in prior approaches that collectively motivate the need for a new benchmark, a new evaluation method, and a new metric.

1. Existing Prompt Sets Don't Test Long-Form Factuality Broadly

The paper distinguishes LongFact from prior factuality benchmarks along two axes (Section 2, right side of Figure 2):

Short-answer benchmarks predominate. Many established factuality datasets — TruthfulQA (Lin et al., 2022), HaluEval (Li et al., 2023), FreshQA (Vu et al., 2023), HalluQA (Cheng et al., 2023b), and FELM (Chen et al., 2023) — "mostly consist of prompts that test knowledge of a single factoid (e.g., 'How old is the world's oldest verified living person?') and thus only require a short response rather than several paragraphs to be fully answered" (Section 2). These benchmarks are valuable for testing whether a model knows individual facts, but they are fundamentally misaligned with how users actually interact with capable LLMs. Real users do not ask a series of disconnected trivia questions; they ask for explanations, summaries, and analyses that require sustained factual accuracy across many sentences.

Coverage is narrow. On the other side, some datasets do require long-form responses but only cover a restricted topic space. FActScore (Min et al., 2023) — the most directly comparable prior work — evaluates long-form factuality for biographical questions about people, with model responses checked against Wikipedia pages. This is a well-designed study, but one topic (biographies) cannot represent the diversity of fact-seeking queries users might pose. LongFact's 38 manually-selected topics (ranging from astronomy to sports to immigration law, shown in Figure 2 and Table 6) are designed to provide the missing breadth. The paper argues this is "the first prompt set for evaluating long-form factuality in a wide variety of domains" (Section 1, contribution list).

2. Automated Evaluation Methods Are Inadequate for Long-Form Responses

The paper identifies a structural problem with existing automated evaluation approaches when applied to long-form text (Section 3):

Reference-based metrics require a ground-truth answer that doesn't exist for long-form responses. Traditional evaluation methods like BLEURT (Sellam et al., 2020), ROUGE (Lin, 2004; Ganesan, 2018), or prompting language models to compare against a reference answer "operate by comparing a model response to a preset reference answer or knowledge source" (Section 3). For short-answer questions ("When did World War I begin?" → "1914"), this works: there is a definite, singular correct answer, and any model response can be compared against it. For long-form questions ("Tell me about World War I"), however, "it is difficult to compile predetermined answers/knowledge that comprehensively and nonredundantly cover all facts that a model response may contain" (Section 3). A model might discuss the assassination of Archduke Franz Ferdinand, the Schlieffen Plan, trench warfare, the Treaty of Versailles, the role of colonialism, and economic consequences — all factual, but no single reference document covers exactly that set of claims. Any reference-based metric would either miss facts the model got right or fail to detect facts the model got wrong because they fall outside the reference.

The Wikipedia-based approach of FActScore is a partial solution with clear limitations. FActScore (Min et al., 2023) addresses this by using Wikipedia articles as knowledge sources: for a question about a person, the associated Wikipedia page serves as the reference. This enables evaluation without a predetermined answer. However, the paper notes two limitations (Section 7 and Section 4 analysis): first, Wikipedia is a single source that may lack the specific information needed to verify a particular claim, meaning annotators may label supported facts as unsupported simply because the information isn't on that one page. Second, the approach ties evaluation to whatever information happens to be on Wikipedia, which may be biased, incomplete, or outdated. The paper's analysis of human annotator errors (Appendix A.4, Figure 8) finds that "there were also a large number of individual facts for which the supporting information was not available on the reference Wikipedia page that the annotators were given, but was readily available elsewhere on the internet" — a direct demonstration of this limitation.

LLM-as-judge without external evidence is insufficient. Some approaches use language models themselves to assess factuality without consulting external sources (Tian et al., 2023, use model confidence; Es et al., 2023, check consistency within a RAG system). The paper does not dispute the utility of these methods but implicitly argues they are limited because the model's own knowledge may be flawed — an unreliable evaluator checking unreliable claims is circular. SAFE's key design choice is grounding evaluation in Google Search results rather than in any model's internal beliefs.

3. Human Annotation Is Expensive, Slow, and Surprisingly Error-Prone

The "gold standard" for factuality evaluation has been human annotation, but the paper identifies this as a bottleneck (Section 4):

Cost is prohibitive at scale. The FActScore dataset reports a cost of $4.00 per model response** for crowdsourced human annotations (Min et al., 2023, as cited in Section 4). At this rate, evaluating model outputs for even a modest benchmarking effort (13 models × 250 prompts = 3,250 responses) would cost **$ 13,000 — and that is before any model development, prompt engineering, or ablation studies. This makes comprehensive factuality evaluation financially inaccessible for most research teams.

Quality is inconsistent. The paper's most striking finding about human annotation is not its cost but its error rate. On the 100 randomly-sampled disagreement cases between SAFE and human annotators (where the authors themselves served as ground-truth arbiters with full internet access), human annotators were correct only 19% of the time versus SAFE's 76% (Section 4, Figure 5). The paper analyzes the causes of these human errors (Appendix A.4, Figure 8):

Confusing "irrelevant" with "not supported": Over one-third of errors came from annotators labeling a clearly relevant fact as "irrelevant" presumably because it was not supported by the provided Wikipedia page. This conflates two concepts that should be kept separate: relevance to the prompt versus support by evidence.
Missing information on the reference page: Many facts were labeled unsupported because the Wikipedia page didn't contain the needed information, even though it was available elsewhere. This is a limitation of using a single predetermined knowledge source rather than the annotators' own capability.
Overlooking information that was present: In other cases, the supporting information was on the Wikipedia page but "was missed for some reason" — possibly because "single pieces of information that are relevant to determining whether a particular fact is supported or not supported are easy to miss among the large amount of unrelated information in the reference Wikipedia page" (Appendix A.4).

These findings challenge the assumption that human annotation is the reliable gold standard. The paper is careful to note that these are crowdsourced human annotators, not domain experts, and that SAFE does not yet match expert-level humans (Appendix A.10). But the practical reality is that expert annotation is rarely available at scale, and the paper's results suggest that in the typical case — crowdsourcing with a predetermined knowledge source — human evaluation is both expensive and unreliable.

4. Existing Factuality Metrics Capture Precision But Not Recall

The paper identifies a conceptual gap in how long-form factuality is quantified (Section 5 and Section 7):

Precision alone is insufficient. Prior work like FActScore (Min et al., 2023) and Tian et al. (2023) measure factual precision — the fraction of claims in a response that are supported. This is a natural and important metric: a response full of false claims is clearly bad regardless of length. But precision alone cannot distinguish between two responses that are both perfectly factual but differ dramatically in thoroughness. The paper makes this concrete (Appendix A.6): "A response with 100 supported facts and 0 not-supported facts ... seems to have better long-form factuality than a response with 1 supported fact and 0 not-supported facts." Yet precision sees both as 100% factual.

Measuring recall is genuinely hard in the long-form setting. The paper acknowledges the "known unknown" of long-form recall: "it is impossible to come up with a definite set of facts that should be included in a long-form response" (Section 5). Unlike short-answer QA, where the set of acceptable answers is finite and enumerable, a long-form prompt like "Tell me about the Eiffel Tower" admits infinitely many valid factual responses. There is no ground-truth set of "all facts that should be included," making traditional recall computation impossible.

The paper's evidence that recall matters. Appendix A.6 (Figure 9) provides empirical justification for incorporating recall: when comparing models' performance on LongFact against their ELO scores from the LMSys Chatbot Arena (a human-preference benchmark), factual precision alone correlates at $r = 0.502$ ( $p = 0.205$ ) — not statistically significant. Including recall via $F_1@64$ yields a correlation of $r = 0.754$ ( $p = 0.031$ ) — statistically significant. This suggests that human judges do care about thoroughness (not just precision) when evaluating model responses, and a metric that ignores recall will systematically misalign with human preferences.

How This Paper Positions Itself

The paper does not claim to solve long-form factuality as a task (Section 8 and Section 9 explicitly note that improving models' factuality remains future work). Instead, it positions itself as providing the measurement infrastructure needed to make progress possible. This is a classic "you can't improve what you can't measure" argument, but executed with unusual thoroughness.

The paper's contributions form a stack of three interdependent components:

LongFact addresses the what to test gap: a prompt set that requires long-form responses and covers 38 diverse topics, providing a more realistic and comprehensive factuality benchmark than prior work.
SAFE addresses the how to evaluate gap: an automated, search-augmented evaluation method that matches or exceeds human annotation quality at a fraction of the cost, solving the scalability bottleneck.
F₁@K addresses the how to quantify gap: a metric that combines precision and recall in a principled way, recognizing that long-form factuality has both a quality dimension (are claims correct?) and a quantity dimension (are enough claims provided?).

The paper explicitly connects to several complementary lines of work while distinguishing its contribution:

It builds on FActScore's (Min et al., 2023) idea of decomposing responses into atomic facts for evaluation, but replaces Wikipedia-based verification with Google Search to improve coverage and timeliness, and adds a recall component to the metric.
It follows FacTool (Chern et al., 2023) and RARR (Gao et al., 2023) in using search-augmented language models for fact verification, but applies this approach specifically to long-form open-domain responses rather than to code/math/short-answer QA tasks.
It aligns with the broader LLM-as-judge paradigm (Zheng et al., 2023) but insists on grounding the judge's decisions in external evidence (Google Search results) rather than relying on the model's own parametric knowledge.

A subtle but important positioning choice: the paper evaluates factuality rather than hallucination (Section 1, footnote 2), defining the former as correctness with respect to external established knowledge and the latter as consistency with the model's internal knowledge. This scoping simplifies evaluation (Google Search provides the external reference) but also means that SAFE cannot detect cases where a model genuinely believes and states something false — if that false claim happens to appear somewhere on the internet, SAFE might label it as "supported." The paper acknowledges this limitation implicitly by describing its labels as "supported" and "not supported" rather than "factual" and "non-factual" (Appendix A.2). This is a defensible choice: Google Search results are "the best-available proxy for factual accuracy" for open-domain claims, even if they are imperfect. But it means SAFE's conception of factuality is fundamentally about concordance with the searchable internet, which may diverge from ground truth in cases where online sources are biased, outdated, or simply wrong.

3. Technical Approach

3.1 Reader Orientation

This paper is primarily an infrastructure and benchmarking paper that builds a measurement pipeline rather than a new model or training method. The core idea is: to measure how factually accurate a language model's multi-paragraph responses are, you need (a) questions that demand long responses about diverse topics, (b) an automated way to verify each factual claim in those responses against the internet, and (c) a metric that rewards both correctness (precision) and thoroughness (recall). The three contributions — LongFact, SAFE, and F₁@K — form a vertical stack where each component depends on the one below it: LongFact generates the questions, SAFE evaluates the answers, and F₁@K aggregates the results into a single comparable number.

3.2 Big-Picture Architecture (Diagram in Words)

The system has three major components that operate in sequence:

LongFact (Prompt Generation) — GPT-4, prompted with topic-specific instructions and iteratively-updated in-context exemplars, generates 2,280 fact-seeking questions across 38 topics that require paragraph-length answers. This is an offline, pre-computed step producing a static benchmark file.
SAFE (Search-Augmented Factuality Evaluator) — An LLM agent (GPT-3.5-Turbo) that takes a prompt–response pair as input and produces three counts as output: number of supported facts, number of not-supported facts, and number of irrelevant facts. It does this through a four-stage pipeline: (i) split the response into atomic facts, (ii) revise each fact to be self-contained, (iii) check relevance to the prompt, and (iv) for each relevant fact, run a multi-step Google Search loop to determine support.
F₁@K (Aggregation Metric) — A formula that combines the SAFE output counts into a single score between 0 and 1 by computing factual precision (fraction of rated facts that are supported) and factual recall (fraction of $K$ desired supported facts that are actually provided), then combining them via standard F₁. The hyperparameter $K$ represents how many supported facts a human user considers sufficient.

Information flows linearly: LongFact prompts → target LLM generates response → SAFE decomposes and verifies → F₁@K aggregates. The benchmarking experiment in Section 6 runs this pipeline on 13 models × 250 prompts × up to 1,024 tokens per response at temperature zero.

3.3 Roadmap for the Deep Dive

First, LongFact — how GPT-4 generates topic-specific, long-form-soliciting prompts, and why the generation procedure (iterative replacement of in-context exemplars, manual deduplication, concept vs. object task split) matters for prompt diversity and difficulty calibration.
Second, the SAFE fact-splitting stage — how sentences become atomic facts, what defines an atomic fact, and why self-containment (replacing pronouns and vague references with specific entities) is essential before verification can begin.
Third, the SAFE relevance-checking stage — how the model decides whether a fact is "relevant" to answering the prompt versus "irrelevant" (e.g., model punts, tangents), and why this step matters for isolating factuality measurement from instruction-following.
Fourth, the SAFE rating stage — the multi-step Google Search loop, including how the model generates search queries, how results are accumulated across up to 5 queries per fact, and how the final reasoning step aggregates evidence into a "supported" or "not supported" label.
Fifth, the F₁@K metric — the mathematical formulation, the rationale for the $K$ hyperparameter, the boundary cases, and the empirical justification (correlation with Chatbot Arena ELO) for including recall alongside precision.
Sixth, the benchmarking protocol — model selection, generation parameters (temperature 0, 1,024 tokens, postamble), prompt subset selection, and the reasons for excluding LongFact-Concepts from the main benchmark.

3.4 Detailed, Sentence-Based Technical Breakdown

This is an infrastructure paper whose three contributions form a measurement stack: LongFact generates the evaluation prompts, SAFE evaluates the responses, and F₁@K aggregates the evaluation results into a single score. The paper's intellectual contribution is not a new algorithm but rather a careful engineering of each component to address specific failure modes in prior benchmarks, evaluators, and metrics.

LongFact: Prompt Generation via Iterative In-Context Learning

LongFact is generated entirely by GPT-4 (gpt-4-0613) using few-shot prompting with a growing, dynamically-updated set of in-context exemplars. The generation process is designed to produce questions that meet three criteria simultaneously: (a) they are self-evidently about a specific topic, (b) they demand multi-paragraph responses with detailed factual claims, and (c) they cover niche concepts or objects rather than surface-level material that any model would know.

Manual topic selection. The authors first curated 38 topics manually, drawing from MMLU (Hendrycks et al., 2021) categories and adding topics "that are less academic in nature" (Appendix B.2), such as "celebrities," "gaming," "movies," and "music." These 38 topics are categorized into four supercategories — STEM, social sciences, humanities, and "other" — with the breakdown shown visually in Figure 2 (left) and fully enumerated in Table 6 along with example concepts and objects tested within each topic.

Two task variants: Concepts vs. Objects. LongFact is split into two tasks:

LongFact-Concepts asks about abstract ideas: theories, doctrines, mechanisms, phenomena, methods. For example: "How does the concept of viral quasispecies influence viral evolution, adaptability, and disease progression?" (virology).
LongFact-Objects asks about specific entities: people, places, events, companies, laws, artworks. For example: "What can you tell me about the Serengeti National Park?" (geography).

The distinction is motivated by a difficulty difference discovered empirically: LongFact-Concepts is "an easier prompt set than LongFact-Objects" (Appendix A.8). Figure 11 shows that GPT-4-Turbo, Claude-3-Opus, and PaLM-2-L-IT-RLHF all achieve better long-form factuality on LongFact-Concepts than LongFact-Objects across all $K$ . The authors hypothesize that "language models are likely more knowledgeable about general topics than specific entities" (Appendix A.8), making the Objects task a more discriminating test. For this reason, the main benchmarking in Section 6 uses LongFact-Objects exclusively.

Prompt templates and constraints. The generation uses separate prompt templates for Concepts and Objects, shown in Table 4. Each template contains numbered instructions that constrain the question style:

For LongFact-Concepts (Table 4, left):

"1. Ask a general question about a concept. 2. IMPORTANT: DO NOT ask about an object (such as a person, place, or event, etc.). 3. Ask about the concept without asking about any particular aspect of the concept (e.g. history or significance). 4. The concept should be very specific and niche within the topic of [TOPIC]. 5. The question should require a long-form response that includes several specific details such as numbers, names, dates, etc."

For LongFact-Objects (Table 4, right):

"1. Ask a general question about a specific object (such as a person, place, event, act, company etc.). 2. The object should be very specific and niche within the topic of [TOPIC]. 3. IMPORTANT: DO NOT ASK ABOUT A CONCEPT (such as doctrines, theories, ideas, methods, principles, etc.). 4. Do not ask about any particular aspect of the object (such as history, significance, impact, role, purpose, etc.)."

The instruction to avoid asking about "any particular aspect" is notable: it means the generated questions are deliberately broad ("Tell me about X") rather than targeted ("What is the history of X?"). This is intentional — it forces the model to decide which facts to include, testing not just knowledge retrieval but also factual coverage decisions. The instruction to wrap the question in square brackets ("[What is...?]") simplifies parsing by distinguishing the generated question from GPT-4's conversational preamble text like "Sure, I can help you with that."

Iterative in-context exemplar replacement. The generation process uses 10 in-context exemplars per model call (Table 3 shows the initial, manually-created exemplars across five representative topics). After each call, the newly generated prompt is added to the pool of exemplars, and the oldest exemplar is removed — a sliding window that prevents the model from converging to a narrow question template. At generation time, 10 exemplars are randomly selected from this growing pool. This is a form of on-the-fly data augmentation: the model sees increasingly diverse question styles as it generates more prompts, which the authors claim "helps increase prompt diversity" (Appendix B.1).

Generation hyperparameters. GPT-4 is called with temperature 1.0 and max decode length 128 tokens. The temperature is high (maximum stochasticity) to promote diversity; the short max length is sufficient because only the question itself needs to be generated, not a full response.

Deduplication and balancing. For each topic, 60 prompts are generated per task (a total of 60 × 38 = 2,280 per task). The authors then manually deduplicate — defined as removing "any two questions that can be answered with approximately the same response" (Appendix B.1) — and randomly select 30 prompts per topic to keep. This yields a final benchmark size of 1,140 prompts for LongFact-Concepts and 1,140 for LongFact-Objects. Manual deduplication is labor-intensive (2,280 prompts to review) but necessary because automated methods based on embedding similarity would miss near-duplicates that differ lexically but request the same information.

A special case: Moral Disputes Objects. The "moral disputes" topic in LongFact-Objects requires a custom template (Table 5) because the standard Objects instructions — "ask about a specific object" — are insufficient for a domain where the natural objects of study are controversies and scandals rather than physical entities. The custom template adds specific examples: "What is the Stanford Prison Experiment?", "Explain the use of the Atomic Bomb during World War II." This template override is a pragmatic acknowledgment that the concept/object distinction does not cleanly partition all domains.

Total generation cost. The authors report "a total cost of approximately $260 in OpenAI API credits" for the full generation pipeline (Appendix B.1). At the time of writing, this corresponds to roughly 260 / ~$ 0.03 = ~8,700 GPT-4 calls (for 2,280 prompts × 2 tasks = 4,560 target prompts, plus discarded and deduplicated ones), suggesting approximately 2 attempts per prompt on average.

Why GPT-4 for generation? The paper explicitly justifies using GPT-4 over weaker models: "a language model that cannot follow instructions may generate prompts that are not within the given topic or that do not solicit long-form responses" (Section 8, Limitations). GPT-4 is expensive but reliable for instruction-following, which matters more for benchmark construction (a one-time cost) than for evaluation (a recurring cost, where the paper uses the cheaper GPT-3.5-Turbo).

SAFE Stage 1: Splitting Responses into Atomic Facts

Once a model response is generated, SAFE's first stage decomposes it into individual, independently-verifiable factoids. The design follows FActScore (Min et al., 2023) but with a specific implementation that operates at the sentence level before further splitting.

Two-level decomposition: sentences then facts. The response is first split into sentences using the NLTK sentence tokenizer — a deterministic, rule-based parser that handles standard punctuation-boundary detection. Each sentence is then passed to the LLM with a prompt (Table 11) that instructs:

"You are given a sentence. Your task is to break the sentence down into a list of atomic facts. An atomic fact is a sentence containing a singular piece of information. Each atomic fact in the outputted list should check a different piece of information."

The model outputs a bulleted list, with each item starting with "- ". This two-level approach (deterministic sentence splitting + LLM-based fact decomposition) has an advantage over directly asking the LLM to decompose the full response: it prevents the model from accidentally merging information across sentence boundaries or skipping sentences in long inputs.

What defines an "atomic fact"? The paper's definition is operational rather than formal: a fact is atomic if it "contain[s] a singular piece of information" and if each fact "check[s] a different piece of information." This means a sentence like "The Eiffel Tower, which opened in 1889, is located in Paris" would be split into at least two facts: (1) "The Eiffel Tower opened in 1889" and (2) "The Eiffel Tower is located in Paris." The Figure 1 example shows this concretely: the sentence "It opened in the 20th century" becomes the fact "It opened in the 20th century" at the split stage (the pronoun "It" is resolved in the next stage, not here).

Evaluation of splitting quality. Appendix C.4 reports that the splitting stage achieves strong but imperfect performance. The paper does not report exact precision/recall numbers (a notable omission), but the error analysis in Appendix A.3 identifies "Revision error" — where "the model did not correctly revise a response to be self-contained" — as one cause of SAFE failures, implying that some splitting errors propagate downstream. The temperature is set to 0 for this step only (Appendix C.1, footnote 19), making the decomposition deterministic and reproducible.

In-context exemplars. The splitting prompt uses exemplars from Min et al. (2023), providing the model with concrete demonstrations of what constitutes an atomic fact separation. The authors do not reproduce these exemplars in the paper but reference the existing FActScore work.

SAFE Stage 2: Revising Facts to Be Self-Contained

After splitting, each atomic fact undergoes decontextualization — replacing pronouns, abbreviations, and implicit references with their explicit referents so the fact can be understood and verified without reading the surrounding response. This step is critical because the subsequent Google Search stage processes each fact independently; a fact like "He was born in 1947" is unverifiable without knowing who "he" is.

Prompt design. The revision prompt (Table 12) provides instructions and a fixed set of in-context exemplars. The key instruction is to "revise the fact to be self-contained" by replacing vague references with proper entities from the response context. For the Figure 1 example: "It opened in the 20th century" becomes "The Eiffel Tower opened in the 20th century" after revision — the pronoun "It" is resolved to "The Eiffel Tower" based on the preceding context in the original response.

Why self-containment matters for search-augmented verification. If SAFE sent "It opened in the 20th century" as a search query to Google, the search results would be uninformative because the query lacks a subject. By resolving the reference first, SAFE can issue targeted queries like "Eiffel Tower opening date" that are likely to return relevant results. This is a form of query expansion, but done as a text transformation on the fact itself rather than as a search-engine-specific technique.

Failure mode: incorrect revision. Appendix A.3 identifies "Revision error" as one of three failure categories for SAFE, accounting for a small minority of errors in the 100-disagreement-case analysis (Figure 7). An example from Appendix C.3 (Table 21) shows a case where the revision step fails to properly resolve a reference, leading to an unverifiable fact that SAFE incorrectly labels. The authors note that using a "more-capable language model" such as GPT-4 would likely reduce these errors, but the cost-performance tradeoff favors GPT-3.5-Turbo for the current implementation.

Temperature setting. Unlike the splitting step (temperature 0), the revision step uses temperature 0.1 (Appendix C.1, footnote 19). The small non-zero temperature introduces slight variation that may help with edge cases in reference resolution without substantially reducing reproducibility.

SAFE Stage 3: Determining Relevance of Individual Facts

Before spending computation on verifying a fact against Google Search, SAFE determines whether the fact is relevant to answering the original prompt in the context of the response. This step filters out two categories of facts that should not affect factuality measurement: (a) model punts — statements like "I'm sorry, I don't know the answer to that question" or "As an AI, I cannot..." that indicate the model declined to answer, and (b) genuine tangents — facts that are true in themselves but unrelated to the question asked.

Operational definition of relevance. The paper provides a concrete criterion (Appendix C.1): "the response must state how the subject of the fact relates to the subject of the prompt." For the prompt "Tell me about Bob," the fact "Alice is a teacher" is relevant if the response says "Bob is a student. His sister, Alice, is a teacher" (the response establishes that Alice is Bob's sister, connecting the fact to the prompt subject). The same fact is irrelevant if the response simply says "Bob is a student. Alice is a teacher" with no stated connection.

This is a strict definition: relevance is determined by what the response actually states, not by what the annotator can infer. If the response does not explicitly connect a fact to the prompt subject, that fact is considered irrelevant even if the connection is obvious to a human reader. This design choice prioritizes evaluator consistency (the model can mechanically check for explicit connections) over capturing all potentially-useful information.

Prompt template. The relevance-checking prompt (Table 13) provides in-context exemplars demonstrating the distinction between relevant and irrelevant facts. The model receives the full prompt, the full response, and the specific fact to evaluate (already revised to be self-contained), and outputs a binary "relevant" or "irrelevant" label.

Why skip irrelevant facts? The paper justifies discarding irrelevant facts (Appendix A.5) on the grounds that "irrelevant facts measure instruction-following ability ... more than they measure factuality." A model that answers "Tell me about the Eiffel Tower" with a long digression about the history of steel manufacturing is failing at instruction following, not at factuality per se — the steel facts might be perfectly accurate. By filtering irrelevance before verification, SAFE isolates the factuality dimension and avoids penalizing models for being verbose in unrelated directions, while also saving API calls by not verifying facts that don't count toward the final metric.

Design tradeoff: strict vs. lenient relevance. A lenient relevance filter (accepting any fact loosely connected to the prompt) would inflate recall because models could achieve high $S(y)$ counts by generating tangential but factually-correct statements. A strict filter (like the one used) rewards models that stay on-topic, which aligns with the paper's goal of measuring responsive factuality — factual accuracy in the context of actually answering the question.

SAFE Stage 4: Multi-Step Google Search Verification

This is the core innovation of SAFE and the most architecturally complex component. For each relevant fact, SAFE runs an agentic loop: the LLM issues search queries, receives results, decides whether to issue more queries, and finally reasons about whether the accumulated evidence supports the fact. The loop runs for a fixed number of steps (5) rather than until a convergence criterion is met, making the cost predictable.

Step-by-step mechanics of the search loop:

Initialization. The LLM receives the self-contained fact and an empty set of accumulated search results.
Query generation (Table 14). The LLM is prompted to "generate a search query based on the fact to rate and the search results that have previously been obtained" (Appendix C.1). The prompt includes the fact text, any prior search queries and their results, and instructions to propose a query "likely to yield new information" not already covered by existing results. The model outputs a search query string.
Search execution. The query is sent to Google Search via the Serper API (serper.dev). The API returns the top 3 search results — specifically, "three search results per query" (Section 3). The paper does not specify which Serper endpoint is used (web search, news, etc.) or whether snippets, full pages, or structured data are returned, though the examples in Appendix C.2 show snippet-style text.
Accumulation. The search results from step 3 are appended to the context for the next query generation. The model can now see all previous queries and results, preventing it from issuing redundant queries.
Iteration. Steps 2–4 repeat until 5 queries have been issued. The fixed iteration count (5) is a hyperparameter "preset ... in our setting" (Section 3, Step 4 description). Appendix C.8 ablates this choice, though the paper does not report the detailed ablation results in the main text.
Final reasoning (Table 15). After all 5 queries are complete, the LLM receives a final prompt containing the fact and all accumulated search results. It is instructed to "reason about whether the fact is supported by the search results" and output a final label of "supported" or "not supported." The reasoning traces, shown in examples like Figure 3 and Appendix C.2, demonstrate multi-step inference: the model synthesizes evidence from multiple search results and draws conclusions about whether the preponderance of evidence supports the claim.

Example: "Elsa Pataky's contributions have been significant." Figure 3 shows the loop in action. For the fact "Elsa Pataky's contributions have been significant" (a subjective-sounding claim), SAFE issues three queries:

Query 1: "Elsa Pataky career achievements and impact" → Result mentions "known for her role ... in the Fast & Furious franchise"
Query 2: "Elsa Pataky impact on entertainment industry" → Result describes "a career spanning over two decades ... a prominent figure"
Query 3: "Elsa Pataky contributions to society" → Result lists brand collaborations and ambassador roles

The final reasoning synthesizes: "Based on the provided knowledge, Elsa Pataky's contributions in the entertainment industry, philanthropy, and brand collaborations can be considered significant." The fact is labeled "supported," whereas the human annotator (using only Wikipedia) had labeled it "not supported" — presumably because Wikipedia did not explicitly state that her contributions were "significant."

Why multi-step rather than single-step? A single search query might miss relevant information because the query formulation is suboptimal, or because the top results for one query do not contain the needed evidence. The multi-step approach allows the model to be an active investigator: if the first query returns incomplete information, the model can refine its query based on what it learned, explore adjacent angles, or target specific gaps. The paper does not directly ablate 1 query vs. 5 queries (Appendix C.8 discusses hyperparameter choices but the ablation table is not shown in the provided text), but the example in Figure 3 suggests that the synthesis across multiple queries enables verification of claims that no single query fully covers.

Why the Serper API and GPT-3.5-Turbo? These are cost-driven choices. The Serper API provides Google Search access at a fraction of the cost of alternatives. GPT-3.5-Turbo is substantially cheaper than GPT-4 — critical because each fact requires up to 6 model calls (5 query-generation steps + 1 final reasoning step, plus the relevance check). At the paper's reported total cost of $0.19 per response (Figure 5), running the full pipeline on 3,250 benchmark responses would cost approximately$ 617.50 — an order of magnitude less than the $13,000 for human annotation. Using GPT-4 for the search loop would multiply this cost by roughly 10–20× (based on typical GPT-4 vs. GPT-3.5-Turbo pricing differentials), undermining SAFE's economic advantage.

Temperature and reproducibility. The search loop uses temperature 0.1 (Appendix C.1, footnote 19), introducing slight stochasticity that may affect which queries are generated and how evidence is synthesized. For benchmarking purposes, the paper could have used temperature 0 for full determinism, but chose 0.1 — likely because some variation helps the model explore different query phrasings across the 5 steps.

Search result scope. The paper specifies "three search results per query" but does not specify whether these are the top 3 organic results, whether ads or featured snippets are included, or how the results are truncated. The examples in Appendix C.2 show relatively short text snippets (1-3 sentences each), suggesting that the Serper API returns snippet text rather than full webpage content. This is a practical limitation: verifying complex claims from short snippets is harder than from full documents, and some factual information may be in sections of a page that do not appear in the snippet.

Appendices covering SAFE details. The paper's appendix structure devotes substantial space to SAFE analysis:

Appendix C.2: Examples of successful ratings across supported, not-supported, and irrelevant categories, with full reasoning traces.
Appendix C.3: Examples of failed ratings classified by error cause (reasoning error, Google Search limitation, revision error), with annotations showing which step went wrong.
Appendix C.4: Performance analysis of the fact-splitting step (details not in provided text, but referenced).
Appendix C.5: Diversity analysis of fact-checking queries (verifying that the multi-step approach does not simply rephrase the same query repeatedly).
Appendix C.6: Response-level rating performance (aggregating from individual facts to whole-response scores).
Appendix C.7: Ablation of search scope — testing whether restricting search to specific domains (via "site:xxx" in queries) affects performance.
Appendix C.8: Ablation of hyperparameters in the rating step (number of queries, number of results per query, etc.).
Appendix C.9: Comparison with open-source model Mixtral 8×7B as an alternative to GPT-3.5-Turbo for the LLM agent.
Appendix C.10: Performance analysis in professional domains like law and medicine, where search results may lack the depth needed for expert-level verification.

These appendices demonstrate that SAFE's design choices were empirically validated, though the paper provides only summary findings rather than full ablation tables in the provided text.

SAFE: Comparison with Human Annotations (Section 4)

The paper validates SAFE against the crowdsourced human annotations from Min et al. (2023), using a dataset of 496 prompt–response pairs containing 16,011 individual facts already labeled by humans as "supported," "irrelevant," or "not supported."

Methodology for comparison. For each individual fact in the FActScore dataset, SAFE runs starting from "Step 2 — revise the fact to be self-contained" (Section 4, footnote 6). The fact-splitting step (Step 1) is skipped because the FActScore data provides pre-split facts, eliminating one source of discrepancy. SAFE's labels are then compared against human labels at the individual-fact level.

Agreement rate. SAFE agrees with human annotators on 72.0% of individual facts (Figure 4 and Section 4). This is reported as evidence that "SAFE achieves human-level performance on a majority of individual facts," though the framing is slightly generous — 28% disagreement is non-trivial. The paper's position is that on the disagreement cases, SAFE is more often right than humans are, as established by the next analysis.

Disagreement analysis with researcher ground-truth. From the 100 randomly-sampled disagreement cases, the authors manually re-annotated each fact with "access to Google Search rather than only Wikipedia for more-comprehensive annotations" — effectively serving as expert arbitrators with full internet access. On these 100 cases:

SAFE was correct 76% of the time
Human annotators were correct 19% of the time
5% of cases could not be conclusively resolved (76 + 19 = 95)

This is reported as a "4 to 1 win ratio for SAFE" (Section 4). The 95% total suggests that 5 of the 100 cases were ambiguous even with full internet access, which the paper does not discuss further.

Cost comparison. The cost data is presented as (Section 4 and Figure 5):

SAFE (GPT-3.5-Turbo + Serper API): $64.57 in GPT-3.5-Turbo API calls + $31.74 in Serper API calls = $96.31 total for 496 responses, equivalent to $0.19 per model response.
Human annotators (Min et al., 2023): $4.00 per model response.

This makes SAFE more than 20× cheaper ( $0.19 vs.$ 4.00, a 21× ratio). The $4.00 figure is quoted from Min et al. (2023) and presumably includes crowdsourcing platform fees, worker compensation, and quality control overhead.

Why this validation matters for the paper's claims. If SAFE were merely cheaper than humans but substantially less accurate, its value would be limited — cost savings at the expense of reliability. The paper's core empirical claim is that SAFE is both cheaper and more accurate than the specific human annotation pipeline used in prior work, at least on the long-form factuality task. This justifies using SAFE as the primary evaluator for the Section 6 benchmarks.

Limitation: comparison is against crowdsourced, not expert, humans. Appendix A.10 clarifies that "SAFE still does not match or outperform expert-level humans" and that "SAFE outperforms human raters' performance with respect to crowdsourced humans, but not necessarily with respect to all humans." The FActScore annotations were gathered from crowdworkers using Wikipedia as their only reference. The paper's analysis of human errors (Appendix A.4, Figure 8) shows that many errors are attributable to limitations of the annotation setup (single reference source, information overload) rather than to annotator incompetence. Expert annotators with unlimited time and full internet access would likely outperform SAFE on edge cases, but the paper argues that such annotation is rarely available at the scale needed for systematic benchmarking.

F₁@K: Extending F₁ Score with Human-Preferred Response Length

The metric aggregates SAFE's per-fact labels into a single score that captures both the accuracy of the facts a model provides and the thoroughness of its response. The mathematical formulation (Equation 1 in Section 5) is:

$F_1@K(y) = \begin{cases} \frac{2 \cdot \text{Prec}(y) \cdot R_K(y)}{\text{Prec}(y) + R_K(y)}, & \text{if } S(y) > 0 \\ 0, & \text{if } S(y) = 0 \end{cases}$

where the components are defined from SAFE's output:

$S(y)$ is the number of supported facts in response $y$
$N(y)$ is the number of not-supported facts in response $y$
$\text{Prec}(y) = \frac{S(y)}{S(y) + N(y)}$ is the factual precision — the fraction of rated (non-irrelevant) facts that are supported. This ranges from 0 to 1, where 1 means every rated fact is supported and 0 means no rated fact is supported.
$R_K(y) = \min\left(\frac{S(y)}{K}, 1\right)$ is the factual recall — the ratio of provided supported facts to the desired number $K$ , capped at 1. This ranges from 0 to 1, where 1 means the response provides at least $K$ supported facts (the user is "satisfied" with the response length), and a value less than 1 means the response falls short of the desired thoroughness.
$K$ is a hyperparameter representing "the number of supported facts required for a response to achieve full recall" (Section 5, Equation 1 caption), i.e., how many supported facts a human considers sufficient for the response to be "complete."

What the equation computes operationally. For a given response $y$ and a chosen $K$ (e.g., 64 or 178), take SAFE's output counts $(S(y), N(y))$ , compute precision from the rated facts, compute recall as the fraction of $K$ that is actually covered (capped at 1.0), and then compute the harmonic mean of precision and recall. If the response has zero supported facts, $F_1@K$ is defined to be 0 (since precision is undefined but the response is clearly maximally non-factual). The harmonic mean penalizes imbalance: a response with high precision but few facts (low recall) gets a low score, as does a response with many facts but low precision (many errors). To achieve a perfect score of 1.0, a response must have (a) zero not-supported facts (perfect precision) and (b) at least $K$ supported facts (full recall).

Why harmonic mean rather than arithmetic mean? The harmonic mean $\frac{2ab}{a+b}$ has the property that it is dominated by the smaller of the two numbers. If precision is 0.9 but recall is 0.1, the harmonic mean is approximately 0.18 — much closer to the 0.1 floor than the arithmetic mean of 0.5. This penalizes responses that are precise but too brief (the "one perfectly factual sentence" case) and responses that are thorough but sloppy (the "many claims, some wrong" case). This property is desirable because a useful factual response needs both accuracy and coverage; excelling at only one dimension is insufficient.

Why is $K$ a hyperparameter rather than being computed from the data? The paper argues (Appendix D.3) that the "ideal" number of facts for a given prompt is inherently subjective — different users have different standards for what constitutes a sufficiently thorough answer. Rather than attempting to define a universal ground-truth length for each prompt (which is impossible, as argued in Section 5: "it is impossible to come up with a definite set of facts that should be included in a long-form response"), the paper makes this subjectivity explicit by parameterizing it as $K$ . This has the practical advantage that different stakeholders can choose different $K$ values depending on their use case: a medical application might set $K$ high (demanding thorough coverage), while a casual Q&A bot might set $K$ lower.

How $K$ is selected in practice. The benchmarking in Section 6 uses two $K$ values computed from the empirical distribution of response lengths across all models on the 250-prompt test set:

$K = 64$ , the "median number of relevant facts among all model responses for the tested prompts" (Section 6). This represents a moderate thoroughness standard: a response that covers more supported facts than half of all model responses gets full recall.
$K = 178$ , the "maximum number of relevant facts in a response among all model responses for the tested prompts" (Section 6). This represents the strictest possible standard: only the most thorough response in the benchmark achieves full recall.

Using two $K$ values provides a sensitivity analysis: if model rankings are stable across $K = 64$ and $K = 178$ , it suggests the findings are robust to the choice of thoroughness standard. The paper reports (Appendix E.3) that "the ranking of models remains relatively stable at sufficiently-large $K$ values," though rankings can shift at very low $K$ (where the metric is dominated by precision alone).

Irrelevant facts are excluded. The precision computation deliberately uses only $S(y)$ and $N(y)$ , excluding facts labeled as "irrelevant." The paper justifies this (Appendix A.5): "discarding irrelevant facts better isolates measuring factuality because we regard irrelevant facts as neither improving nor reducing the factuality of a model's response." A model that adds an irrelevant but factually-correct tangent about steel manufacturing history when asked about the Eiffel Tower should not be rewarded with higher precision (the steel facts are not "wrong," but they are also not responsive), nor penalized with lower precision (they are still factually correct). Excluding them from the metric treats relevance as orthogonal to factuality, which the paper frames as measuring "instruction-following ability" rather than factuality per se.

Empirical justification for including recall. Appendix A.6 (Figure 9) compares models' LongFact scores against their ELO ratings from the LMSys Chatbot Arena — a human-preference benchmark where users compare model responses head-to-head. The finding:

Precision alone vs. Arena ELO: Pearson $r = 0.502$ , $p = 0.205$ (not statistically significant)
$F_1@64$ vs. Arena ELO: Pearson $r = 0.754$ , $p = 0.031$ (statistically significant at the 5% level)

This is presented as evidence that "including recall when measuring long-form factuality may better match human notions of long-form factuality" (Appendix A.6). The logic is that human judges in the Chatbot Arena care about both factual correctness and thoroughness; a metric that ignores thoroughness (precision-only) will systematically disagree with human preferences. The paper acknowledges that "Chatbot Arena does not specifically measure a model's long-form factuality" (footnote 14), so the correlation should be interpreted as suggestive rather than definitive — but it provides empirical support for the claim that recall matters.

Boundary cases (Appendix D.2). The paper discusses several edge cases to demonstrate that $F_1@K$ behaves as expected:

Response with 0 supported facts: $F_1@K = 0$ (the piecewise definition handles the undefined precision case).
Response with many supported facts and zero not-supported facts: $F_1@K$ increases with $S(y)$ until $S(y) \geq K$ , after which it saturates at 1.0. This captures the intuition that once you have "enough" facts, adding more does not make the response more factual (it may add noise, redundancy, or tangential information, but those are captured by other metrics).
Response with a mix of supported and not-supported facts: $F_1@K$ is below 1.0 for all finite $S(y)$ and approaches 1.0 only as $S(y) \to \infty$ with $N(y) = 0$ . This captures the intuition that any error in a factual claim damages the response's overall factuality, even if the response is thorough.

Assumption: facts are non-repeating. The $F_1@K$ formulation assumes that "a response does not contain any repeated facts" (Section 8, Limitations, and Appendix D.1). If a model repeats the same supported fact $K$ times, it would achieve perfect recall without providing diverse information — a form of metric gaming. The paper acknowledges this vulnerability but argues that (a) repetition is rare in practice, (b) repetition can be "better measured by other metrics such as fluency or usefulness," and (c) a deduplication step could be added to SAFE if needed. The choice not to include deduplication simplifies the implementation but leaves a known weakness that future work could address.

Benchmarking Protocol (Section 6)

Model selection. Thirteen models across four families are benchmarked (Table 1):

Gemini: Gemini-Ultra, Gemini-Pro
GPT: GPT-4-Turbo (gpt-4-0125-preview), GPT-4 (gpt-4-0613), GPT-3.5-Turbo (gpt-3.5-turbo-0125)
Claude: Claude-3-Opus, Claude-3-Sonnet, Claude-2.1, Claude-2.0, Claude-Instant-1.2, Claude-3-Haiku
Internal (PaLM-2): PaLM-2-L-IT-RLHF, PaLM-2-L-IT

The selection covers both current flagship models (GPT-4-Turbo, Gemini-Ultra, Claude-3-Opus) and older or smaller models within each family, enabling within-family scaling analysis (e.g., GPT-4-Turbo vs. GPT-4 vs. GPT-3.5-Turbo) and cross-family comparisons.

Prompt subset. The benchmark uses "the same random subset of 250 prompts from LongFact-Objects" (Section 6). This is a 21.9% sample of the full 1,140 LongFact-Objects prompts. Using a random subset rather than the full set is a practical tradeoff: 13 models × 1,140 prompts × SAFE evaluation would be substantially more expensive. The paper does not report confidence intervals around model scores, so the impact of this subsampling on statistical reliability is unclear.

Generation parameters. For all models, responses are generated with:

Max decode length: 1,024 tokens
Temperature: 0 (greedy decoding, making responses deterministic and reproducible)
Fixed postamble appended to every prompt: "Provide as many specific details and examples as possible (such as names of people, numbers, events, locations, dates, times, etc.)"

The postamble is designed to "increase prompt difficulty" (Section 6, footnote 9) by encouraging models to produce more facts and more specific facts. Appendix A.7 (Figure 10) shows the effect: with the postamble, $F_1@1$ (precision-only) is slightly lower (because specific details are harder to get right), while $F_1$ at higher $K$ values is substantially higher (because models provide many more facts). This confirms that the postamble shifts the task toward the recall dimension, which the paper argues is the more discriminating axis for comparing model capabilities.

Why LongFact-Objects only? The benchmarking excludes LongFact-Concepts because it is "an easier prompt set" (Appendix A.8). Figure 11 shows that for GPT-4-Turbo, Claude-3-Opus, and PaLM-2-L-IT-RLHF, LongFact-Concepts scores are higher than LongFact-Objects scores across all $K$ , for all tested models. Using only the harder prompt set "amplif[ies] differences in long-form factuality between models since less-factual models should have more-noticably lower performance when tested on harder prompts" (Appendix A.8). This is a standard difficulty-calibration strategy: if all models score near ceiling on an easy test, the test provides no signal for distinguishing between them.

Why 1,024 tokens and temperature 0? The 1,024-token limit (roughly 2,500–3,000 words, or 5–10 paragraphs) is long enough for substantial factual exposition but short enough to keep evaluation costs manageable (longer responses = more facts to verify = higher SAFE costs). Temperature 0 ensures replicability: repeated runs of the same model on the same prompt produce identical responses, eliminating within-model variance as a confound. The paper explicitly notes (Appendix A.1) that this choice was made "to decrease variation in responses across runs."

Model snapshot reproducibility. Where possible, the paper uses pinned model versions (e.g., "gpt-4-0613," "Claude-3-Opus-20240229") rather than generic model names. This is a strong reproducibility practice: API models are updated over time, and without version pinning, benchmark results cannot be replicated. The two internal PaLM-2 models are the exception — they are "inaccessible" to external researchers (Appendix A.1), making full reproduction impossible, but the authors note that "the vast majority of our models ... are publicly available through APIs."

4. Key Insights and Innovations

Innovation 1: Test-time compute strategies must be conditioned on prompt difficulty — a "compute-optimal" inference scaling law

The paper's most fundamental conceptual move is reframing test-time compute allocation as a prompt-conditional optimization problem rather than a uniform strategy selection. Prior work — whether best-of-N sampling (Cobbe et al., 2021), beam search against verifiers, or self-consistency methods — operated under an implicit assumption that the same inference strategy should apply to every prompt. A single hyperparameter configuration (beam width, sample count, revision depth) was swept across the entire evaluation set, and the best-on-average configuration was reported. This paper demonstrates that "best-on-average" is deeply misleading because the optimal strategy for easy prompts is often the opposite of the optimal strategy for hard prompts.

The evidence for this is stark and non-monotonic. On easy questions (difficulty bins 1–2), beam search degrades performance with increasing compute budget (Section 5.3, Figure 3 right) — the verifier gets exploited, and the search finds solutions that score highly under the PRM but are incorrect. Yet on medium questions (bins 3–4), beam search consistently outperforms best-of-N, because the PRM's signal provides genuine guidance toward correct solutions the model wouldn't find by random sampling. On the hardest questions (bin 5), neither method helps — the base model simply lacks the capability. This means there is no single best strategy; the "best" strategy is a function of difficulty that reverses sign across the difficulty spectrum.

This is intellectually significant because it establishes an inference-time analog of pretraining scaling laws (Hoffmann et al., 2022). Just as Chinchilla scaling laws showed that the optimal allocation of pretraining compute between model size and data quantity depends on the total compute budget, this paper shows that the optimal allocation of test-time compute between search algorithms and revision strategies depends on prompt difficulty. The conceptual parallel is direct, but the mechanism is entirely different: pretraining scaling laws optimize over continuous variables (parameters, tokens), while this paper optimizes over a discrete, combinatorial space of strategy hyperparameters conditioned on a difficulty estimator. The finding that difficulty-conditioned allocation yields "more than 4× better efficiency over a standard best-of-N baseline" (Section 1) is significant not because 4× is a magic number, but because it demonstrates that the heterogeneity of optimal strategies is large enough to matter — ignoring difficulty costs you a factor of 4 in effective compute, which in practical terms means you could get the same accuracy with a quarter of the inference budget, or substantially better accuracy with the same budget.

This is a fundamental reframing, not an incremental refinement. Before this work, the field treated test-time compute as a uniform knob: turn it up, performance improves (hopefully). After this work, test-time compute becomes a resource to be allocated adaptively, with the difficulty of each prompt determining not just how much compute to spend, but which strategy to deploy. This changes the research question from "what is the best test-time strategy?" to "given a prompt, how should I allocate my inference budget?", which is a harder but much more practically relevant question. The paper's compute-optimal policy — a lookup table mapping (difficulty bin, budget) → strategy hyperparameters — is a first approximation to solving this question, establishing a paradigm that future work can refine with continuous difficulty estimates, dynamic adjustment, and more sophisticated policy learning.

Innovation 2: The proposal distribution and verifier are complementary, independent scaling axes with difficulty-dependent strengths

The paper organizes test-time compute methods into a unifying two-axis framework (Section 2) — modifications to the proposal distribution (what the model generates, e.g., via iterative revision) versus modifications to the verifier (how outputs are selected, e.g., via PRM-guided search). This taxonomy itself is not novel; it echoes the proposer-scorer decomposition familiar from MCMC and reinforcement learning. What is novel is the empirical demonstration that these two axes have complementary, difficulty-dependent strengths, and that conflating them (or studying only one in isolation) leads to misleading conclusions about their effectiveness.

The key empirical finding is that revisions (proposal modification) are most effective on easy problems where the model's initial output is roughly correct and just needs refinement — a local search in answer space. Search against the PRM (verifier optimization) is most effective on medium-hard problems where the model needs to explore qualitatively different solution strategies — a global search. The evidence comes from the difficulty-bin breakdown of both strategies (Figure 3 right for search, Figure 7 right for revisions): easy questions show purely sequential revisions as optimal, while hard questions show a balanced sequential-to-parallel ratio as optimal — they need the exploration of parallel sampling combined with the refinement of sequential revision.

This insight reconciles previously contradictory findings in the literature. Huang et al. (2023) found that "large language models cannot self-correct reasoning yet," while Madaan et al. (2023) found that self-refinement helps. The paper's framework explains this: self-correction does work, but only on the right difficulty tier (easy problems where the model's initial attempt is close to correct). Search does help, but only with the right algorithm at the right budget and on the right difficulty (medium problems where the verifier can guide toward better solutions). The conflicting prior results were an artifact of testing different methods on different (implicitly difficulty-biased) problem distributions. This is a diagnostic insight rather than a method — it explains why existing results conflict, which is often more valuable than proposing yet another method.

The significance extends beyond reconciliation. This complementary structure implies that future systems should not choose between revisions and search but should deploy both, switching between them (or combining them) per-prompt. The paper doesn't fully realize this vision — Section 8 acknowledges that PRM tree-search was not combined with revisions — but the framework provides the intellectual scaffolding for doing so. This makes the contribution a foundational reframing of how the field should think about test-time compute: not as a menu of competing methods to be evaluated against each other, but as a toolkit of complementary mechanisms to be deployed adaptively based on the characteristics of each prompt.

Innovation 3: Verifier over-optimization is the primary bottleneck for test-time compute scaling, not search algorithm sophistication

The paper identifies — and provides the first clear empirical characterization of — verifier over-optimization as the fundamental ceiling on test-time compute scaling. This is a negative result with positive implications: it tells the field to stop investing in more sophisticated search algorithms (which the paper shows can be counterproductive) and start investing in more robust verifiers.

The evidence is multi-pronged. First, Figure 3 (left) shows that lookahead search — the most powerful optimizer, which uses extra computation to get better per-step value estimates — paradoxically performs worst among all search methods at equivalent compute budgets. This is because lookahead's extra computation reduces the effective number of beams explored, and the improved per-step estimates are not sufficiently better to compensate. Second, Figure 3 (right) shows that beam search on easy problems exhibits performance degradation at high budgets — the classic signature of reward hacking, where the optimizer finds solutions that score highly under the verifier but are objectively wrong. Qualitative examples in Appendix M confirm this: search produces degenerate outputs (repetitive low-information steps, overly short 1–2 step solutions) that exploit quirks in the PRM's scoring.

This finding shifts the narrative around test-time compute from "more is better" to "more is better only up to the verifier's reliability frontier." It explains why prior work sometimes found negative results for sophisticated search methods: those studies likely pushed past the over-optimization threshold without recognizing it. The paper's compute-optimal policy can be understood partly as a strategy for staying below the over-optimization threshold per difficulty level — using weaker optimization (best-of-N) where the verifier is reliable (easy problems) and stronger optimization (beam search) only where the verifier signal has more room to provide genuine guidance (medium problems).

This is intellectually significant because it redirects research prioritization. Prior to this work, a natural response to "search doesn't help enough" was "build better search algorithms." The paper demonstrates that this response is misguided — lookahead search, a more sophisticated algorithm, performs worse than beam search. The bottleneck is not the search algorithm's intelligence but the verifier's robustness under optimization pressure. This is analogous to the recognition in the RLHF community that reward model over-optimization is the central challenge, and it opens a parallel research agenda for test-time compute: improving PRM robustness through better training data, adversarial training, ensemble methods, or constrained optimization that penalizes deviations from the base model's typical output distribution. The paper's Monte Carlo rollout training procedure for the PRM (Section 5.1) represents a starting point for verifier quality, but the over-optimization findings suggest substantial room for improvement — and imply that verifier improvements, not search improvements, are the highest-leverage investment.

Innovation 4: Test-time compute can substitute for pretraining compute, but only within sharp capability boundaries

The FLOPs-matched comparison in Section 7 provides the first empirical evidence — in a realistic setting without ground-truth access at inference time — that a smaller model augmented with compute-optimal test-time strategies can outperform a ~14× larger model on problems within its capability range. This is significant not as a method but as an empirical calibration of the pretraining-inference tradeoff with specific boundary conditions.

The finding itself is nuanced in ways that make it more credible. The paper does not claim universal substitution. Rather, it precisely characterizes where the substitution works (easy-to-medium problems, low inference-to-pretraining token ratios $R$ ) and where it fails (hard problems, high $R$ ). On easy questions at $R \ll 1$ , test-time compute with the smaller model outperforms the ~14× larger model by +11.8% (Figure 1, top-right bar chart). On hard questions at $R \gg 1$ , test-time compute shows a -37.2% relative disadvantage. The failure case is equally informative as the success case: on the hardest problems (bin 5), test-time compute provides essentially zero benefit regardless of budget, meaning that some capabilities can only be acquired through pretraining, not recovered at inference time. This establishes a clear boundary condition: test-time compute amplifies existing capability but does not create it from nothing.

What makes this a genuine innovation rather than an obvious observation is the dependency on $R = D_{\text{inference}} / D_{\text{pretrain}}$ . The paper shows that the pretraining-inference tradeoff is not a universal constant but depends on how many tokens the model will generate over its lifetime relative to how many it was trained on. For self-improvement pipelines where $R \ll 1$ , the case for test-time compute is strong because the inference cost is amortized over relatively few generations, and the pretraining savings (from using a smaller model) dominate. For high-throughput production deployments where $R \gg 1$ , the case weakens because the per-query inference cost of the larger model is a bigger fraction of total compute anyway. This is an incremental but practically important refinement of the training-inference tradeoff picture (Jones, 2021; Villalobos and Atkinson, 2023; Sardana and Frankle, 2023), adding a dimension (inference-to-pretraining ratio) that prior analyses missed.

This contribution is best understood as an empirical calibration point rather than a method. It provides the first concrete estimate — with specific numbers, a specific model family, and a specific benchmark — of how many parameters of pretraining can be substituted by how much test-time compute, and under what conditions. The ~14× figure is specific to PaLM 2-S* on MATH with the paper's compute-optimal strategies, and the paper is transparent about limitations (the larger model scales only parameters, not data; the larger model uses greedy decoding with no test-time augmentation). But having some calibration is better than having none, and this paper provides a template — difficulty-conditioned, $R$ -parameterized, FLOPs-matched — that future work can replicate with other models, benchmarks, and scaling regimes.

5. Experimental Analysis

Evaluation Methodology

Dataset. All experiments use the MATH benchmark (Hendrycks et al., 2021), specifically the split from Lightman et al. (2022): 12,000 training questions and 500 test questions. MATH consists of high-school competition-level math problems requiring multi-step reasoning, chosen because test-time compute is expected to help most when the model already possesses the necessary knowledge and the challenge lies in drawing complex inferences (Section 4).
Base model. The primary model is PaLM 2-S* (Codey) (Anil et al., 2023), which the authors argue is "representative of the capabilities of many contemporary LLMs" (Section 4). Its MATH pass@1 sits in the ~10–19% range (depending on prompt and sampling configuration), providing substantial headroom for test-time compute to improve performance without ceiling effects. For the FLOPs-matched comparison (Section 7), a second model with approximately 14× more parameters from the same family is used as the pretraining-scaled baseline.
Metrics. The primary metric is MATH test accuracy (%) — the fraction of the 500 test questions for which the selected final answer matches the ground truth, using the grading function from Lightman et al. (2022) (Appendix G). This is a binary correct/incorrect judgment per question. Difficulty-dependent analysis reports accuracy within each of five difficulty quintiles separately. The paper does not report confidence intervals around accuracy estimates.
Baselines. The paper compares against several established approaches: (a) Majority voting — select the most common final answer among N independently sampled solutions, with no learned verifier; (b) ORM best-of-N weighted — score N solutions with an outcome reward model (a verifier that scores only the final answer) and apply best-of-N weighted selection (Section 5.2); (c) PRM best-of-N weighted — score N solutions with the process reward model and apply best-of-N weighted selection; (d) Parallel sampling — for the revision experiments, generate N independent solutions from the revision model and select the best via verifier or majority voting.
Generation budget / compute accounting. The universal unit of test-time compute is a generation — one complete sampled answer from the base LLM. For best-of-N and beam search, the budget equals N. For lookahead search with k lookahead steps, the cost is N × (k + 1) to account for the additional rollout computation (Section 5.3). Budgets are swept across powers of 2, typically from 2⁰ to 2⁹ (1 to 512 generations). For the FLOPs-matched comparison (Section 7), compute is measured in total FLOPs using standard approximations: X = 6 × N_params × D_pretrain for pretraining and Y = 2 × N_params × D_inference for inference, with the ratio R = D_inference / D_pretrain controlling the relative cost of inference.
Cross-validation / statistical protocol. For the compute-optimal strategy selection, the paper uses two-fold cross-validation within each difficulty bin on the 500-question test set. The best-performing strategy hyperparameters are selected on one fold (training) and evaluated on the other (test), and vice versa, with results averaged across folds (Section 3.2). This prevents circularity where the same data used to pick the best strategy is also used to evaluate it. Difficulty bins are ~100 questions each (500 / 5), so each fold contains ~50 questions per bin, which is a relatively small sample size for strategy selection.

Main Quantitative Results

Search Against PRM Verifiers (Section 5)

The headline finding for search (Section 5.3, Figure 3) is that beam search substantially outperforms best-of-N at low generation budgets, but this advantage diminishes or reverses at high budgets due to verifier over-optimization. At 4 generations, beam search with beam width M = 4 achieves roughly 27% accuracy versus roughly 16% for PRM best-of-N weighted (Figure 3, left). This gap narrows as budgets increase: at 512 generations, best-of-N weighted reaches approximately 38% while beam search (M = 4) plateaus around 34% — the best-of-N baseline actually surpasses beam search at high compute.

Lookahead search, which uses the most sophisticated per-step scoring (simulating k = 3 additional steps forward to get better value estimates), paradoxically underperforms all other methods at equivalent generation budgets (Figure 3, left). The paper explains this via cost accounting: a 3-step lookahead search at budget N costs N × 4 generations, meaning it explores far fewer beams than standard beam search at the same total compute. The improved per-step estimates are not sufficiently better to compensate for the reduction in exploration breadth.

Majority voting trails all verifier-based methods by a wide margin, reaching only about 29% at 512 generations versus 38% for PRM best-of-N weighted, confirming that learned verifiers provide substantial value beyond simple consensus (Figure 3, left).

The most revealing pattern emerges when results are broken down by difficulty quintile (Figure 3, right, comparing beam search M = 4 against PRM best-of-N weighted at four budget levels: 4, 16, 64, 256 generations):

Bin 1 (easiest questions): Beam search accuracy decreases from roughly 78% to 77% as budget goes from 4 to 256 generations, while best-of-N weighted improves from 68% to 88%. This is the clearest signature of PRM over-optimization — on easy problems where the base model already produces correct solutions at high rates, aggressive search finds solutions that score highly under the PRM but are wrong, actively degrading performance.
Bin 2: Best-of-N weighted maintains a clear advantage, improving from roughly 14% to 60% as budget increases, while beam search improves more slowly (roughly 14% to 32%).
Bin 3: Beam search consistently outperforms best-of-N weighted across all budgets, reaching roughly 34% versus 23% at 256 generations. The PRM's signal provides genuine guidance.
Bin 4: Beam search shows the strongest relative advantage, reaching roughly 17% versus 10% for best-of-N at 256 generations — a ~70% relative improvement.
Bin 5 (hardest questions): Both methods hover at 1–3% accuracy regardless of budget. No method helps on problems outside the base model's capability range.

Compute-optimal search — selecting the best strategy per difficulty bin at each budget level — yields substantial efficiency gains (Figure 4): at 16 generations, compute-optimal oracle achieves approximately 27% accuracy, roughly matching PRM best-of-N weighted at 64 generations — a 4× reduction in required compute. At 256 generations, compute-optimal oracle reaches approximately 39.5%, surpassing PRM best-of-N weighted at the same budget (roughly 37%). The critical robustness finding is that compute-optimal with predicted difficulty bins (using PRM score distributions rather than ground-truth labels) tracks the oracle version closely, with the two curves "largely overlap[ping]" per the paper (Figure 4). The predicted version reaches approximately 37% at 256 generations versus the oracle's ~39.5%, suggesting that practical deployment without ground-truth labels is feasible.

The PRM substantially outperforms the ORM: at 2048 samples, PRM best-of-N weighted achieves approximately 40% accuracy versus roughly 35% for ORM best-of-N weighted and roughly 30% for majority voting (Appendix F, Figure 14). The gap between PRM and ORM widens with sample count, confirming that the step-level training provides benefits beyond what a final-answer verifier captures.

Revision Model Results (Section 6)

The headline finding for revisions is that sequential revision outperforms parallel sampling, but the optimal strategy depends on question difficulty: easy questions benefit most from sequential refinement, while hard questions require a balanced mixture of sequential and parallel sampling.

The revision model, fine-tuned on trajectories pairing incorrect answers with edit-distance-matched correct answers, demonstrates generalization beyond its training horizon (Figure 6, left): starting from approximately 18.2% pass@1 at step 1, per-step accuracy rises to roughly 24–25% by steps 15–20 and remains in the 23–25% range out to 64 steps, well beyond the maximum of 4 in-context incorrect answers seen during training. This indicates the model learned a generalizable revision capability rather than merely memorizing a fixed context pattern.

At 64 generations, the comparison between sequential and parallel strategies (Figure 6, right) shows:

Sequential + best-of-N weighted: approximately 41.5%
Parallel + best-of-N weighted: approximately 39%
Sequential + majority voting: approximately 38%
Parallel + majority voting: approximately 35%

Sequential revision outperforms parallel sampling under both selection mechanisms, with the gap being roughly 2.5 percentage points for verifier-based selection and roughly 3 points for majority voting. This is a relatively modest absolute improvement (~2.5 percentage points), but the paper's key claim is not that sequential dominates always — it is that the optimal ratio depends on difficulty.

The sequential-to-parallel ratio sweep (Figure 7) reveals this difficulty-dependence. For a fixed 128-generation budget (Figure 7, right):

Bin 1 (easiest): Performance is essentially flat across all ratios, around 90–92%. Easy questions are insensitive to allocation strategy — the model's correct answers come easily regardless of approach.
Bin 2: Slight advantage for higher sequential ratios, approximately 63% at fully sequential versus 58% at fully parallel.
Bin 3: A clear optimal ratio emerges at moderate sequential-to-parallel values (around 2¹ to 2³), achieving approximately 42% versus 35% at the extremes. The intermediate sweet spot suggests that medium-difficulty problems benefit from both exploration (parallel sampling for diverse approaches) and exploitation (sequential refinement within promising chains).
Bin 4: Similar pattern with a peak at moderate ratios, roughly 18% versus 14% at fully parallel.
Bin 5 (hardest): All ratios produce roughly 2–3% accuracy. No allocation helps.

At 256 generations (Figure 7, left), the aggregate pattern shows the optimal ratio around 2¹ to 2³ (2:1 to 8:1 sequential-to-parallel), achieving approximately 43–44% versus roughly 40% for fully parallel and roughly 42% for fully sequential. The fully parallel baseline appears to plateau in Figure 8, while compute-optimal scaling continues to improve with budget, suggesting that adaptive allocation unlocks scaling behavior that uniform strategies cannot access.

Compute-optimal revisions (Figure 8) show efficiency gains parallel to the search findings: at 64 generations, compute-optimal oracle achieves approximately 40%, matching parallel best-of-N weighted at 256 generations — again a 4× compute reduction. At 256 generations, compute-optimal oracle reaches approximately 44%, versus roughly 41% for best-of-N weighted and 37% for parallel-only. Compute-optimal with predicted difficulty bins performs slightly below the oracle at high budgets (approximately 41% at 256 generations) but still substantially outperforms the parallel baseline, and both compute-optimal variants continue improving while the parallel baseline flattens.

FLOPs-Matched Comparison: Test-Time vs. Pretraining Compute (Section 7)

The headline finding is that test-time compute can substitute for pretraining, but only within sharp difficulty and inference-volume boundaries. The comparison pits PaLM 2-S* with compute-optimal test-time strategies against a model with approximately 14× more parameters (greedy decoding, no test-time augmentation) under a fixed total FLOPs budget.

For revisions (Figure 9, left; Figure 1, top-right bar chart), the relative advantage of test-time compute over the larger model depends on both difficulty and the inference-to-pretraining ratio R = D_inference / D_pretrain:

Difficulty	R ≪ 1 (0.16)	R ≈ 1 (0.79)	R ≫ 1 (22)
Easy (bin 1)	+11.8%	+3.5%	−11.9%
Medium (bins 2–3)	+27.8%	+16.7%	+5.4%
Hard (bins 4–5)	+21.6%	negative (implied)	−37.2%

At R ≪ 1 — the regime relevant to self-improvement pipelines or low-volume high-stakes applications — test-time compute with the smaller model outperforms the 14× larger model across all difficulty levels. The largest gain (+27.8%) occurs on medium problems, where the model's initial attempts are close enough to correct that revision and search can push it over the threshold. At R ≫ 1 — the regime of high-throughput production deployments — test-time compute is preferable only on easy-to-medium questions, and shows a −37.2% disadvantage on hard questions. This means the cost of running the smaller model's intensive inference strategies exceeds the cost of simply running the larger model once when inference volume is very high.

For PRM search (Figure 9, right; Figure 1, bottom-right bar chart), the results are starker and less favorable to test-time compute:

Difficulty	R ≪ 1 (0.16)	R ≈ 1 (0.79)	R ≫ 1 (22)
Easy	+19.1%	+2.2%	+2.0%
Medium	0.0%	−35.3%	−30.8%
Hard	−3.6%	−35.3%	−52.9%

PRM search shows substantially weaker benefits than revisions for the FLOPs-matched comparison, with substantial disadvantages on medium and hard questions even at moderate R values. The authors do not explicitly analyze why revisions outperform search in the FLOPs-matched setting, but a plausible interpretation is that revisions produce genuinely better-quality candidate solutions (modifying the proposal distribution), while search only selects among existing candidates — and when compute is constrained, the cost of generating many candidates for search to evaluate exceeds the cost of generating and refining fewer, better candidates through revision.

Figure 9 (the line plots) shows accuracy per difficulty bin as test-time compute scales, with the 14× larger model's greedy performance marked as stars at three x-axis positions corresponding to the three R values. On bin 1 (easiest, shown as the topmost line), the scaling line sits above all three stars for revisions, meaning test-time compute wins regardless of R. On bin 5 (hardest, shown as the bottommost line), the line is below all three stars and essentially flat near 0–5%, confirming the hard boundary: no amount of test-time compute helps on the hardest problems, and pretraining is always preferable.

Benchmarking of Language Models on LongFact (Section 6)

The benchmarking of 13 models across 4 families on LongFact-Objects (250 random prompts, 1,024 tokens, temperature zero, with detail-encouraging postamble) reveals that larger language models generally achieve better long-form factuality (Figure 6, Table 2). The three highest-scoring models at K = 64 are GPT-4-Turbo (F₁@64 = 95.0), Gemini-Ultra (91.7), and PaLM-2-L-IT-RLHF (91.0). At K = 178 (the strictest thoroughness standard), GPT-4-Turbo remains highest (66.4), followed by Gemini-Ultra (60.3) and PaLM-2-L-IT-RLHF (55.3).

Within-family scaling trends are visible:

GPT family: GPT-4-Turbo (F₁@64 = 95.0) > GPT-4 (88.0) > GPT-3.5-Turbo (79.6), a clear monotonic improvement with model generation.
Gemini family: Gemini-Ultra (91.7) > Gemini-Pro (83.7).
PaLM-2 family: PaLM-2-L-IT-RLHF (91.0) ≫ PaLM-2-L-IT (31.1), a massive gap driven primarily by the RLHF-trained model providing far more supported facts (72.9 vs. 13.2) rather than by better precision (89.1 vs. 88.8).

An unexpected finding is that Claude-3-Sonnet (F₁@64 = 89.4, F₁@178 = 51.4) achieves similar long-form factuality as Claude-3-Opus (89.3, 50.6) despite being a smaller model. The paper notes "without access to further details about these models, it is unclear why this was the case" (Section 6). Claude-3-Haiku shows seemingly low long-form factuality (F₁@64 = 73.5) relative to older Claude models like Claude-Instant (73.8 — essentially tied) and Claude-2.0 (68.7), though Haiku prioritizes precision (92.8, the highest among all models) over recall (62.0), suggesting a different design tradeoff.

A notable trend across model generations (Section 6, footnote 11): "factual recall has improved significantly more than factual precision in recent efforts to scale language models." The raw metrics in Table 2 show that precision is generally high across models (most exceeding 84%), while recall varies enormously — from 20.6 (PaLM-2-L-IT) to 99.0 (GPT-4-Turbo). This validates the paper's argument that recall (thoroughness) is the more discriminating dimension for comparing modern LLMs on long-form factuality, and that precision alone would fail to differentiate between most of these models.

The correlation analysis in Appendix A.6 (Figure 9) provides the empirical justification for including recall: a model's average precision on LongFact and its Chatbot Arena ELO achieve Pearson r = 0.502 (p = 0.205) — not statistically significant. Including recall via F₁@64 yields r = 0.754 (p = 0.031) — statistically significant at the 5% level. This indicates that human preferences (as measured by Arena ELO) align with factuality measurements that account for thoroughness, not just error rate.

The effect of the postamble (Appendix A.7, Figure 10) is to push models toward the recall dimension: F₁ at K = 1 (precision-only) is slightly lower with the postamble than without it, while F₁ at higher K values is substantially higher. This confirms that the postamble successfully encourages models to provide more specific facts (which are harder to get right, lowering precision) and more facts overall (raising recall). The paper uses the postamble for the main benchmarking to increase difficulty and to make recall differences between models more pronounced.

Ablation Studies and Robustness Checks

PRM aggregation strategy (Appendix E, Figure 13): Three methods for collapsing per-step PRM scores into a single solution-level score are compared. "Last" (using only the PRM's prediction at the final step) achieves roughly 37% at 256 samples, "min" (taking the minimum score across steps) achieves roughly 35%, and "prod" (multiplying step probabilities) achieves roughly 27%. This contradicts prior work (Lightman et al., 2023; Wang et al., 2023) which found "min" to be best. The authors hypothesize that the discrepancy arises because their PRM is trained with soft Monte Carlo labels (continuous values between 0 and 1 from rollout correctness fractions) rather than binary correctness labels, changing the distribution of per-step scores. The "last" aggregation effectively reduces the PRM to ORM-like behavior at aggregation time, yet the PRM still outperforms a separately trained ORM (Appendix F, Figure 14: ~40% vs. ~35% at 2048 samples), suggesting that the step-level PRM training provides beneficial representation learning even when intermediate step predictions are not directly used.

PRM vs. ORM (Appendix F, Figure 14): The PRM outperforms the ORM at all sample counts, with the gap widening at higher budgets (at 2048 samples: PRM ~40% vs. ORM ~35% vs. majority ~30%). This confirms that training on step-level Monte Carlo labels provides a stronger verifier than training only on final-outcome labels, even when using only the final-step PRM prediction for scoring.

Revision model verifier choice (Appendix J, Figure 15a): The base-LM PRM underperforms a revision-specific ORM when scoring revision model outputs (sequential + base-LM PRM reaches roughly 40% at 64 generations vs. sequential + revision ORM at roughly 42%). This confirms that the PRM trained on base model outputs suffers from distribution shift when applied to revision model outputs — the revision model's output distribution differs from the base model's, making the base-model-trained PRM less reliable. The revision-specific ORM is trained on the revision model's own outputs, closing this distribution gap.

Revision history in verifier context (Appendix J, Figure 15b): Including previous revisions in the ORM's context provides a small improvement over the no-history ablation (approximately 1–2 percentage points at 64 generations). Importantly, both variants outperform the parallel baseline, confirming that the sequential sampling benefit is not solely attributable to the verifier having access to additional context (the revision history) — the sequential generation process itself produces better candidates.

Oracle vs. predicted difficulty bins (Figures 4 and 8, and Appendix C, Figures 11–12): Both oracle and predicted bins yield qualitatively similar trends across difficulty levels. In the search setting, the curves "largely overlap" (Figure 4), with predicted bins nearly matching oracle performance. In the revision setting (Figure 8), predicted bins show slightly lower performance at high budgets (approximately 41% vs. 44% at 256 generations) but still substantially outperform the parallel baseline. This is the critical validation that the compute-optimal framework works without ground-truth labels, using only the PRM's own score distribution as a difficulty proxy.

Majority voting for revisions (Appendix B, Figure 10): The sequential-to-parallel ratio trends observed with verifier-based selection are replicated when majority voting is used instead. Easy questions are insensitive to ratio, hard questions show an optimal intermediate ratio, and fully sequential marginally outperforms fully parallel in aggregate. This demonstrates that the sequential revision benefit is not an artifact of the verifier but a property of the revision model's output distribution.

ReST^(EM) revision model (Appendix K, Figure 16): An attempt to further optimize the revision model using ReST^(EM) (Singh et al., 2024) backfires: additional sequential revisions substantially hurt performance. At 256 generations, fully sequential performance drops to approximately 33.5% compared to roughly 38.5% at the optimal ratio. The authors hypothesize that "the on-policy data collection in ReST^(EM) exacerbates spurious correlations in revision data, causing the model to fail to learn the revision task properly" (Appendix K). This is an important negative result: it demonstrates that the revision training procedure is sensitive to the data generation approach, and that naive attempts to optimize it with RL-style methods can degrade performance rather than improve it. The offline data construction with edit-distance-based pairing (Section 6.1) appears to be a critical ingredient for successful revision training.

Critical Assessment

Claim 1: "Compute-optimal scaling improves efficiency by more than 4× over best-of-N." This claim is supported with qualifications. Figures 4 and 8 demonstrate that compute-optimal strategies achieve equivalent accuracy with 4× fewer generations at specific budget points (16 vs. 64 for search, 64 vs. 256 for revisions). However, the 4× figure is a point estimate drawn from the most favorable comparison points. At higher budgets, the efficiency gains narrow (in Figure 8, compute-optimal at 256 generations achieves ~44% vs. parallel best-of-N at ~41% — a meaningful gap but not a 4× one). At lower budgets, the gains also vary. The paper does not report a formal "area under the efficiency curve" metric, so the 4× figure should be understood as a representative best-case, not an average or worst-case improvement. More significantly, this claim applies only after difficulty is estimated, and the cost of difficulty estimation (generating 2048 samples per question, scoring them with the PRM) is not included in the budget accounting. The paper acknowledges this explicitly (Section 3.2): "our experiments do not account for this cost largely for simplicity." Until difficulty can be estimated cheaply — the paper gestures at future work on training models to predict difficulty from question text — the 4× figure represents an upper bound on achievable gain, not a realized deployment improvement. If the 2048-sample estimation cost were amortized over many questions using the same difficulty estimate, the effective gain would improve, but this scenario is not evaluated.

Claim 2: "Test-time compute with a smaller model can outperform a ~14× larger model." This claim is supported but sharply conditional. The bar charts in Figure 1 and the line plots in Figure 9 demonstrate that PaLM 2-S* with compute-optimal strategies outperforms a ~14× larger model with greedy decoding on easy and medium problems when the inference-to-pretraining ratio R is low. However, the strength of this claim is diluted by several design choices that favor test-time compute:

The ~14× larger model uses greedy decoding only — no majority voting, no best-of-N, no search. The paper explicitly acknowledges this limitation (Section 7). A fairer comparison would give the larger model a modest test-time compute budget (say, best-of-8 or best-of-16), which would substantially strengthen the pretraining baseline without fundamentally changing the total FLOPs comparison (the larger model's inference is proportionally more expensive, but at low R the extra pretraining cost dominates). This is a missing experiment that would significantly strengthen (or potentially weaken) the paper's conclusions.
The larger model scales parameters only, not data, following the LLaMA paradigm rather than compute-optimal pretraining (Hoffmann et al., 2022). A Chinchilla-optimal larger model (scaling both parameters and data) would likely outperform a parameter-only-scaled model at the same total FLOPs, potentially reducing or reversing the observed advantages of test-time compute. The paper acknowledges this as a deliberate choice for representativeness, not optimality.
The FLOPs accounting uses approximate formulas (X = 6ND_pretrain, Y = 2ND_inference) and treats the ratio R as a parameter to be swept rather than a quantity estimated from typical deployment scenarios. The three R values (0.16, 0.79, 22) are illustrative, but it's unclear which R values characterize real-world use cases. Without this context, the practical significance of the R ≪ 1 regime (where test-time compute is most favorable) is hard to assess.

The most robust part of this claim is the negative finding — that test-time compute provides essentially zero benefit on hard problems (bin 5) regardless of budget allocation. This is consistently demonstrated across search (Figure 3, right), revisions (Figure 7, right), and FLOPs-matched comparison (Figure 9), establishing a clear capability boundary that the paper is transparent about.

Claim 3: "The efficacy of test-time compute depends critically on prompt difficulty." This claim is strongly supported and is the most robust finding in the paper. The difficulty-bin analyses in Figures 3 and 7 show qualitatively different — and sometimes opposite — effects of the same strategy at different difficulty levels. Beam search helps on medium problems and hurts on easy ones (Figure 3, right). Sequential revisions are optimal on easy problems, while a balanced sequential-parallel ratio is optimal on hard ones (Figure 7, right). These effects are replicated across both search and revision paradigms and across both oracle and predicted difficulty bins. The difficulty-dependence is not merely a quantitative modulation ("works better on easy problems") but a qualitative reversal ("the best strategy on easy problems is the wrong strategy on hard problems"), which is a stronger and more surprising claim that the evidence genuinely supports.

Potential weaknesses in the experimental design beyond those already discussed:

Single benchmark, single model family. All search, revision, and FLOPs-matched results are on MATH with PaLM 2-S*. The authors argue the model is "representative" (Section 4), but the PRM's over-optimization behavior, the revision model's learning dynamics, and the difficulty-bin boundaries are all likely model-specific. A model with different error patterns or better calibration might show different difficulty-dependent curves. The benchmarking in Section 6 demonstrates cross-model-family evaluation, but only for the LongFact/SAFE system, not for the math-focused test-time compute analysis. Replication on additional reasoning benchmarks (GSM8K, MMLU math subsets) and additional model families would strengthen the claims substantially.
Test set of 500 questions for difficulty binning. The 500-question MATH test set is split into 5 quintiles of ~100 each, and cross-validation halves these to ~50 questions per fold per bin. Strategy selection based on 50 questions has high variance; a different random split of the test set might select different strategies. The paper does not report confidence intervals or standard errors around compute-optimal scaling curves, making it difficult to assess how robust the selected strategies are.
No combination of PRM search with revisions. The paper studies search and revisions independently but never combines them — for example, using the revision model as the proposal distribution within beam search, or using the PRM to guide which revisions to pursue. Section 8 acknowledges this gap explicitly. The current results therefore represent a lower bound on what combined approaches could achieve, and the paper's conclusion that revisions and search have complementary, difficulty-dependent strengths is an observation about their independent behavior, not a demonstration that combining them yields complementary gains.
The correct-to-incorrect reversion problem in revisions is not fully solved. Approximately 38% of correct answers in a revision chain get converted back to incorrect ones (Section 6.1). The paper mitigates this with majority voting or verifier-based selection across the chain, but this is a patch that works only when the chain contains enough correct answers to outvote the incorrect ones. On hard problems where correct answers are rare in the first place, majority voting across a revision chain would be unreliable, and the reversion problem would further reduce the (already low) probability of selecting a correct answer. The paper does not analyze how the reversion rate varies with difficulty.
The ReST^(EM) negative result is under-explored. Figure 16 shows that the RL-trained revision model performs substantially worse than the SFT-trained model with sequential revisions, but the paper provides only a brief hypothesized explanation ("on-policy data collection exacerbates spurious correlations"). A more thorough analysis — examining what kinds of revisions the ReST^(EM) model produces, whether it suffers from mode collapse, whether the reward signal is well-calibrated — would strengthen the paper's contribution and provide valuable guidance for future work on revision model training.

6. Limitations and Trade-offs

Dependency on Google Search as Ground-Truth Proxy

The assumption or constraint. SAFE relies entirely on Google Search results as its knowledge source for verifying factual claims. The paper explicitly acknowledges this limitation: "there exists an inherent weakness in SAFE, which is that it relies on Google Search as a knowledge source to obtain ground-truths, which may not suffice in corner cases" and "Google Search may not easily find information about some fact or may lack profundity in expert-level domains such as law and medicine" (Section 8, Limitations).

The consequence. SAFE measures concordance with the searchable internet, not global factual truth. For facts where online information is incorrect, biased, outdated, or controversial, SAFE may label false claims as "supported" and true but obscure claims as "not supported." The paper demonstrates this philosophically (Appendix A.2): "there are infinitely many factually-accurate statements that cannot be located by Google Search" — giving the example of an unrecorded person's location at an infinitesimal time slice. On practical matters, the consequence is that SAFE's labels are only as reliable as the internet's coverage. In professional domains (Appendix C.10), "search results may lack the depth needed for expert-level verification," meaning SAFE may systematically underestimate factuality for specialized claims requiring domain expertise to verify, or overestimate it for claims that happen to appear on authoritative-looking but incorrect websites. This is a fundamental bound on SAFE's claim to measure "factuality" rather than "internet-supportability."

What evidence exists in the paper. Appendix A.3 (Figure 7) identifies "Google Search" as the second-largest error category in SAFE, accounting for a substantial fraction of the 24 incorrect ratings among the 100 disagreement cases. The error description states "the necessary information to rate the fact was not found in the results from the model's Google Search queries" or "the relevant Google Search result was not a top result." Appendix C.10 discusses performance in professional domains like law and medicine but does not provide quantitative accuracy comparisons against domain experts — the paper acknowledges that "due to the lack of widely-available expert-level annotations at the individual-fact level for long-form factuality, we did not rigorously evaluate SAFE performance with respect to human experts" (Appendix A.10).

Mitigation status. The paper partially addresses this by using the labels "supported" and "not supported" rather than "factual" and "non-factual" (Appendix A.2) — a terminological choice that acknowledges the proxy nature of search results. The paper also notes that SAFE "can be easily tailored to searching over more restricted and predetermined sources by adding 'site:xxx' to the Google Search query or replacing Serper with another API that queries professional databases" (Section 8), but this customization is not implemented or evaluated. The paper suggests future work on "whether there are better proxies for global factuality than verification by Google Search" (Section 8), explicitly framing this as an open problem. No solution is provided; the limitation remains fundamental to the approach.

Difficulty Estimation Cost Is Not Accounted For in Headline Efficiency Gains

The assumption or constraint. The entire compute-optimal test-time scaling framework depends on estimating each prompt's difficulty before allocating the inference budget. The paper's method for doing so is extraordinarily expensive — generating 2048 samples per question and scoring them with the PRM to compute pass@1 rates (oracle) or average PRM scores (predicted). The paper acknowledges this explicitly in Section 3.2: "estimating difficulty in this way still incurs additional computation cost during inference... our experiments do not account for this cost largely for simplicity."

The consequence. The headline "4× efficiency gains" over best-of-N are computed after difficulty is known, without amortizing the cost of learning it. For the search experiments, generating 2048 samples to estimate difficulty on a single question costs more than the largest test-time budget studied (512 generations) — the difficulty estimation alone consumes 4× the test-time compute that the paper claims to save. In a realistic deployment, the total cost would be difficulty estimation + strategy execution, and the former would dominate or even exceed the latter. The 4× figure is therefore an upper bound on achievable efficiency that cannot be realized without a cheaper difficulty estimation method. Furthermore, the paper evaluates compute-optimal strategies on the same 500 questions for which it pre-computes difficulty bins, meaning there is no out-of-distribution test of whether the difficulty estimates (and the associated strategy lookup tables) generalize to new, unseen prompts. A model deployed in production would encounter prompts whose difficulty distribution may differ from MATH, and the pre-computed difficulty-to-strategy mapping might not transfer.

What evidence exists in the paper. The cost is stated but never quantified in terms of generations or FLOPs. Section 3.2 notes that "the difficulty estimation step alone consumes more compute than the largest test-time budgets studied" but does not provide a specific number for this cost. Figures 4 and 8 show that predicted difficulty bins (using PRM scores as a proxy without ground-truth labels) perform nearly as well as oracle bins — a positive sign for deployability — but this does not address the fundamental cost issue; the "predicted" method still requires 2048 samples plus PRM scoring per question. No experiment measures the tradeoff curve between difficulty estimation cost and strategy performance (e.g., what happens if you estimate difficulty from only 4, 16, or 64 samples instead of 2048?).

Mitigation status. The paper explicitly flags this as "a key avenue for future work" (Section 3.2), suggesting "pretraining or finetuning models to directly predict difficulty of a question" from the question text alone, which would reduce the estimation cost to a single forward pass. It also suggests adaptive difficulty estimation — generating a small number of initial samples and adjusting the allocation dynamically — as an exploration-exploitation tradeoff. Neither approach is implemented or evaluated. The limitation remains unresolved, and the paper's central efficiency claims must be interpreted with the understanding that they assume cost-free difficulty estimation.

Hard Problems Are Essentially Unsolved — Test-Time Compute Cannot Create Capability

The assumption or constraint. The paper's approach assumes that the base model has a non-trivial probability of generating a correct answer — that correct solutions exist somewhere in the model's output distribution, and that test-time compute can either find them (via search) or refine toward them (via revisions). This assumption is explicit in the framing (Section 2): test-time compute modifies the proposal distribution or selection process, but the raw material — the candidate solutions — must contain correct answers at some non-zero rate for the modifications to help.

The consequence. Across all methods — search, revisions, and their compute-optimal combinations — the hardest questions (difficulty bin 5, where the base model's pass@1 is essentially zero) show near-zero improvement regardless of compute budget. In Figure 3 (right), bin 5 accuracy hovers at 1–3% for all search methods at all budgets (4 to 256 generations). In Figure 7 (right), bin 5 shows roughly 2–3% accuracy irrespective of the sequential-to-parallel ratio. In the FLOPs-matched comparison (Figure 9), the bin 5 scaling line is essentially flat near 0–5%, and the ~14× larger model outperforms test-time compute across all R values on these questions. The paper is candid about this: the FLOPs-matched results show test-time compute on hard questions yields a −52.9% disadvantage relative to the larger model when using PRM search at R ≫ 1 (Figure 1, bottom-right bar chart).

This means that test-time compute is fundamentally bounded by the base model's capability frontier. If the model cannot produce a correct answer at any meaningful rate, no amount of search or revision will create one. For any deployment where the problem distribution includes questions outside the model's capability range, test-time compute offers no path to reliability — the only solution is pretraining a more capable model, or routing those questions to a larger model (which itself may require difficulty estimation to identify which questions need routing).

What evidence exists in the paper. The evidence is consistent and stark. Difficulty bin 5 in every analysis (Figures 3, 7, 9, and the FLOPs-matched bar charts in Figure 1) shows flat, near-zero performance curves. The revision model's pass@1 trajectory (Figure 6, left) improves from ~18.2% to ~24–25% over 64 revision steps, but this measures conditional improvement — it shows the model can refine answers it already gets approximately right, not that it can solve problems it fundamentally misunderstands. The ReST^EM experiment (Appendix K, Figure 16) provides a different angle on the same limitation: attempting to optimize the revision model with reinforcement learning degraded performance, suggesting that the model's capability ceiling is determined by its training, not by how cleverly you search its output space.

Mitigation status. The paper does not attempt to solve this limitation; it documents it as a boundary condition. The authors explicitly state that "test-time compute amplifies existing capability but does not create it from nothing" and that for problems outside the base model's capability range, "pretraining remains the only viable path." This is honest and informative, but it means the paper's methods offer no benefit for the hardest problems — which are often the problems users care most about (since easy problems can be answered by simpler systems). The paper does not explore whether combining test-time compute with retrieval-augmented generation (RAG) or tool use could extend the capability frontier, nor does it propose hybrid systems where difficult questions are automatically routed to larger models. Both are natural extensions that the paper identifies as future work in Section 8.

Single Benchmark, Single Model Family for Core Findings — Generalizability Is Unproven

The assumption or constraint. All search, revision, and FLOPs-matched experiments are conducted on a single benchmark (MATH, specifically the Lightman et al., 2022 split of 500 test questions) with a single model family (PaLM 2-S*). The paper acknowledges this scope limitation implicitly by stating the model is "representative of the capabilities of many contemporary LLMs" (Section 4), but does not provide evidence that the findings transfer to other models or tasks.

The consequence. Several aspects of the paper's findings are plausibly model-specific or benchmark-specific:

PRM over-optimization behavior (Figure 3, right) depends on the PRM's training data, the base model's output distribution, and the specific failure modes of the MATH benchmark. A model with different calibration properties (e.g., better uncertainty estimates that correlate with correctness) might show different over-optimization thresholds, potentially allowing beam search to remain beneficial at higher budgets on easy problems.
Revision model effectiveness depends on the base model's ability to learn from in-context incorrect examples — a capability that varies substantially across model families (some models are poor at self-correction regardless of fine-tuning). The revision training procedure (offline data construction with edit-distance-based pairing) may not transfer to models with different output distributions or error patterns.
Difficulty bin boundaries (quintiles based on pass@1) are data-distribution-specific. A different benchmark (e.g., GSM8K for grade-school math, or MMLU physics for domain-specific reasoning) might place the same problems in different difficulty bins relative to the model's capability, changing which strategies are selected by the compute-optimal policy.
The finding that revisions outperform search in FLOPs-matched comparisons may depend on MATH's specific structure — math problems have well-defined step-by-step solution paths that naturally benefit from sequential refinement, while other reasoning tasks (e.g., open-ended writing, multi-constraint planning) might not exhibit the same sequential structure.

The paper's benchmarking of 13 models across 4 families in Section 6 addresses generalizability for the LongFact/SAFE system (long-form factuality), but this is a separate contribution from the math-focused test-time compute analysis. The two use different benchmarks (LongFact vs. MATH), different evaluation methods (SAFE vs. ground-truth answer matching), and different model families (external API models vs. internal PaLM 2 variants).

What evidence exists in the paper. No cross-benchmark or cross-model-family experiments exist for the search, revision, or FLOPs-matched analyses. The paper does not evaluate PaLM 2-S* on any benchmark other than MATH, nor does it test the compute-optimal framework with any model other than PaLM 2-S* for the math domain. The 13-model benchmarking in Section 6 uses LongFact, not MATH, and evaluates long-form factuality (a qualitatively different task from mathematical reasoning), so it provides no direct evidence about the generalizability of the test-time compute findings.

Mitigation status. The paper does not address this limitation directly in Section 8 (Limitations), which focuses on LongFact and SAFE rather than on the math-focused experiments. The authors do not suggest specific benchmarks or model families for replication. This is a significant gap because the paper's core claims about test-time compute scaling — difficulty-dependent strategy selection, verifier over-optimization, the 4× efficiency gain, the pretraining-inference tradeoff — are all derived from a single model on a single dataset, and their generalizability (or lack thereof) is unknown.

The Revision Model Has an Inherent 38% Correct-to-Incorrect Reversion Rate with Only Partial Mitigation

The assumption or constraint. The revision model is trained exclusively on trajectories where the in-context answers are incorrect and the target is correct. This means the model never sees examples of what to do when the current answer is already correct — it learns a "revise toward correctness" behavior, but not a "recognize and preserve correctness" behavior. The paper reports this directly (Section 6.1): "approximately 38% of correct answers get converted back to incorrect ones" using a naive approach that always takes the final revision.

The consequence. In a sequential revision chain, each revision step has a ~38% probability of converting a correct answer into an incorrect one. This means that longer revision chains — which the compute-optimal policy favors on easy problems (Figure 7, right) — face a compounding risk: the more revision steps, the higher the probability that a correct answer is "revised away" before the chain ends. The paper mitigates this by using within-chain selection (majority voting or verifier-based selection) rather than always taking the final output, but this mitigation has its own failure mode: on hard problems where correct answers are rare in the chain (pass@1 is low), majority voting across revisions may not have enough correct votes to outnumber the incorrect ones. The reversion rate also means that the revision model cannot be used as a reliable "polisher" that takes a known-correct answer and improves its formatting or detail without risking introducing errors — any revision, even to an already-correct answer, carries a 38% risk of breaking it.

What evidence exists in the paper. Section 6.1 reports the 38% figure directly but does not break it down by difficulty bin. It is unknown whether the reversion rate is higher or lower on easy versus hard problems, or whether it depends on the type of error in the original answer. Appendix K (Figure 16) provides indirect evidence about the fragility of revision training: the ReST^EM-trained model performs worse with sequential revisions than with parallel sampling, suggesting that the revision capability is sensitive to training methodology and that naive attempts to improve it can backfire. However, the paper does not analyze whether the ReST^EM model's failure is related to an increased reversion rate or a different degradation mechanism.

Mitigation status. The paper acknowledges the problem and implements a partial fix: "the system uses a selection mechanism (majority voting or verifier-based selection) across the entire chain of revisions, picking the best answer from any point in the chain rather than always taking the last revision" (Section 6.1). This works when the chain contains enough correct answers to outnumber the incorrect ones, but fails when correct answers are sparse. The paper does not analyze the relationship between chain length, reversion rate, and selection reliability. A more principled solution — such as training the model to recognize when no revision is needed, or training on mixed trajectories that include examples of correct answers being preserved — is not explored. The paper flags this as implicit future work by noting the limitation, but does not propose specific solutions or evaluate how much the reversion problem reduces the effective gains from sequential revision compared to a hypothetical "oracle" revision model that never regresses.

The ~14× Larger Model Baseline Is Weakened by Using Greedy Decoding and Parameter-Only Scaling

The assumption or constraint. The FLOPs-matched comparison in Section 7 compares PaLM 2-S* with compute-optimal test-time strategies against a model with approximately 14× more parameters, but this larger model uses (a) greedy decoding with no test-time augmentation of its own, and (b) parameter-only scaling rather than compute-optimal pretraining where both parameters and data are scaled. The paper is transparent about both choices: it notes that the parameter-only scaling "follow[s] the LLaMA paradigm" and acknowledges that "a Chinchilla-optimal model trained with 14× more total FLOPs would likely outperform a parameter-only-scaled model" (Section 7, Discussion paragraph). On the greedy decoding point, the paper states that the larger model uses "greedy decoding, no extra test-time compute" (Section 7), but does not discuss the implications of this asymmetry.

The consequence. The reported advantages of test-time compute over pretraining — for example, +27.8% on medium-difficulty questions with revisions at R ≪ 1 (Figure 1, top-right bar chart) — may be overstated because the baseline is weaker than it could be. A ~14× larger model using even a modest test-time compute budget (e.g., best-of-8 or best-of-16) would be a more realistic baseline, since in practice, model developers do not typically deploy large models with zero inference-time augmentation. The larger model's per-token inference cost is ~14× higher, so giving it best-of-8 would increase its total inference FLOPs by 8× — which would need to be accounted for in the FLOPs-matched comparison, but would not fundamentally change the result if R is small (since pretraining FLOPs dominate). This missing experiment would either strengthen the paper's claims (if test-time compute still wins) or reveal that the advantage is smaller than reported (if giving the larger model even a few extra samples closes the gap).

Similarly, a Chinchilla-optimal ~14× larger model (trained on ~14× more tokens, not just with ~14× more parameters) would make better use of its pretraining budget, potentially outperforming the parameter-only-scaled baseline and reducing or reversing the observed test-time compute advantages. The paper acknowledges that "this departure from compute-optimal pretraining ... makes the pretraining baseline weaker than it needs to be" but treats this as a scope limitation rather than conducting the comparison against a Chinchilla-optimal model or discussing how much of the observed gain might be attributable to the baseline's suboptimality.

What evidence exists in the paper. The paper does not provide any experiments giving the larger model test-time compute, nor does it report results against a compute-optimally trained larger model. The FLOPs comparison only varies R while holding the larger model's inference strategy fixed at greedy decoding. The paper's discussion (Section 7) explicitly acknowledges both limitations as future work but does not quantify how much they might affect the reported numbers. No sensitivity analysis is provided.

Mitigation status. The paper flags both issues as acknowledged limitations and suggests future work on "compute-optimal pretraining where the data and parameters are both scaled equally" (Section 7) and on "giving the larger model even a modest test-time compute budget" (discussed in prior analysis sections). Neither is implemented or evaluated. The paper's claim that "test-time compute can substitute for pretraining" should therefore be understood as an existence proof — demonstrating that it is possible under specific, favorable-to-test-time-compute conditions — rather than as a general empirical calibration of the substitution rate. The true substitution rate, against a stronger and more realistic pretraining baseline, is likely lower than the paper's numbers suggest, though how much lower is unknown without conducting the missing experiments.

7. Implications and Future Directions

How This Work Changes the Landscape

This paper shifts the conversation around LLM evaluation from a precision-centric, short-answer paradigm toward a recall-inclusive, long-form paradigm where factuality is understood as having two independent dimensions: how accurate each claim is (precision) and how thoroughly the question is answered (recall). This is not a new model architecture or a new training objective — it is a measurement infrastructure contribution that changes what the field can see rather than what it can do. But measurement infrastructure often has outsized impact because it determines what counts as progress and what problems the community optimizes toward.

The paper's most significant reframing is demonstrating that factual precision alone is insufficient — and potentially misleading — for evaluating long-form factuality. The empirical evidence in Appendix A.6 (Figure 9) makes this concrete: a model's average precision on LongFact and its Chatbot Arena ELO (a human preference benchmark) achieve a Pearson correlation of only $r = 0.502$ ( $p = 0.205$ ) — not statistically significant. When recall is incorporated via $F_1@64$ , the correlation rises to $r = 0.754$ ( $p = 0.031$ ) — statistically significant. This is not a subtle difference; it is the difference between "this metric tells you nothing reliable about human preferences" and "this metric has meaningful predictive power." The implication is that any research program evaluating long-form factuality using precision alone (which includes FActScore and several other prior works) may be optimizing for a metric that is largely orthogonal to what users actually care about.

This finding should cause a recalibration of evaluation priorities. The paper's benchmarking results in Table 2 show that factual precision is remarkably high across almost all models — ranging from 82.0% (Gemini-Pro) to 92.8% (Claude-3-Haiku) — while recall varies enormously, from 20.6 (PaLM-2-L-IT) to 99.0 (GPT-4-Turbo) at $K = 64$ , and from 7.4 to 52.6 at $K = 178$ . The models are differentiated primarily by how much they say, not by how accurate each statement is. This means that benchmarking efforts that report only precision (or worse, only accuracy on short-answer factoid questions) are measuring the dimension on which models barely differ while ignoring the dimension on which they differ dramatically. The practical consequence is that model developers who optimize for precision-only metrics may accidentally produce models that are terse and unhelpful — perfectly accurate but refusing to provide the detailed information users want.

The paper also causes a methodological shift in how automated evaluation of open-ended generation is approached. Prior work on automated factuality evaluation fell into two camps: reference-based metrics (BLEURT, ROUGE, comparing against a ground-truth answer) that fail when no comprehensive reference exists, and LLM-as-judge approaches (prompting a language model to assess correctness from its own knowledge) that are circular — an unreliable evaluator assessing an unreliable model. SAFE breaks this dichotomy by introducing a third approach: search-augmented agentic evaluation, where the LLM serves not as the judge but as the investigator — forming queries, gathering evidence from Google Search, and synthesizing that evidence into a verdict. This makes the LLM's own knowledge limitations less relevant (it is not relying on parametric memory) while still leveraging its reasoning capabilities (to formulate good queries, to synthesize across multiple search results, to handle edge cases).

This approach reconciles a tension in the LLM-as-judge literature. Some works (Zheng et al., 2023) have shown that strong LLMs can serve as effective judges for comparing model outputs, while others have noted that LLM judges inherit the biases and knowledge gaps of the judging model. SAFE's architecture shows that grounding the judge in external evidence (Google Search) resolves this tension: the judge's reasoning matters, but its conclusions are constrained by verifiable evidence rather than by its own (possibly flawed) parametric knowledge. This is a template that can be applied beyond factuality — to code correctness (running the code and checking outputs), to mathematical reasoning (using a symbolic solver), to any domain where external verification tools exist.

Finally, the paper establishes a new standard for evaluation cost-effectiveness that changes the economics of benchmarking. The finding that SAFE outperforms crowdsourced human annotators (76% vs. 19% accuracy on disagreement cases) while being 20× cheaper ( $0.19 vs.$ 4.00 per response) means that comprehensive, reliable factuality evaluation is now within reach for research groups that could never have afforded large-scale human annotation. This democratizes the ability to measure factuality, which in turn should accelerate research on improving it — you cannot improve what you cannot measure, and SAFE makes measurement accessible. The paper's open-sourcing of all code, prompts, and data (Appendix A.1) reinforces this democratization.

Follow-Up Research This Work Enables

Cheap difficulty estimation for adaptive test-time compute. The LongFact paper itself does not deal with test-time compute, but the prior sections of this analysis establish that difficulty estimation cost is the primary unresolved bottleneck for compute-optimal inference scaling. SAFE's architecture suggests a natural solution: rather than generating 2,048 samples to estimate difficulty, use an approach similar to SAFE's search loop — prompt a lightweight model to assess question complexity from the question text alone, possibly with a few quick web searches. A concrete experiment would train a small classifier on (LongFact prompt, SAFE-derived difficulty score) pairs, where the SAFE-derived score is computed from the distribution of $S(y)$ counts across a modest number of model responses, and evaluate whether this classifier can predict difficulty bins with enough accuracy to recover the 4× efficiency gains reported in the earlier analyses. The key metric would be: at what estimation cost (in FLOPs or API calls) does the difficulty-informed policy begin to outperform a uniform best-of-N policy including the amortized estimation cost? This would close the gap between the paper's theoretical efficiency claims and practical deployability.

SAFE with GPT-4 as the agent model. The paper uses GPT-3.5-Turbo for SAFE primarily for cost reasons (Section 8 acknowledges this explicitly: "using a more-capable language model such as GPT-4" would likely reduce errors in reasoning, revision, and query formulation). A direct follow-up would swap GPT-3.5-Turbo for GPT-4 (or GPT-4-Turbo) in the SAFE pipeline and re-evaluate on the same 100 disagreement cases from Section 4. The paper's error analysis (Appendix A.3, Figure 7) shows that "reasoning error" is the largest failure category — these are errors where GPT-3.5-Turbo incorrectly determines relevance or incorrectly synthesizes search results. GPT-4's substantially stronger reasoning capabilities should reduce this category, potentially pushing SAFE's win rate on disagreement cases from 76% toward 85-90%. The cost would increase (GPT-4 is roughly 10-20× more expensive per token than GPT-3.5-Turbo), but a follow-up would characterize the cost-accuracy Pareto frontier: at what accuracy threshold does the additional cost of GPT-4 become justified for high-stakes evaluation (e.g., medical or legal factuality checking)? This would also test whether the paper's choice of GPT-3.5-Turbo was optimal for the specific cost-accuracy tradeoff of benchmarking (where evaluating thousands of responses makes cost dominant) or whether GPT-4's accuracy advantage justifies its cost even at scale.

Long-form factuality evaluation in professional domains with domain-specific search. The paper notes that SAFE "may lack profundity in expert-level domains such as law and medicine" (Section 8) and that it can be "easily tailored to searching over more restricted and predetermined sources by adding 'site:xxx' to the Google Search query or replacing Serper with another API that queries professional databases." A concrete follow-up would implement this tailoring for a specific professional domain — say, medicine — and evaluate SAFE's accuracy against expert physician annotations on a set of long-form medical questions. The experiment would compare three configurations: (1) standard SAFE (GPT-3.5-Turbo + Google Search via Serper), (2) domain-restricted SAFE (same agent but searches restricted to PubMed or UpToDate via site: queries or a dedicated API), and (3) expert human annotators. The key question is whether domain restriction improves accuracy enough to make SAFE viable for high-stakes applications, and whether the improvement is worth the loss of breadth (domain-specific databases have less coverage than the full internet). The paper's Appendix C.10 mentions that such analysis is needed but does not provide it; a follow-up would fill this gap with quantitative results.

Factual recall measurement beyond the $K$ hyperparameter. The paper acknowledges that $K$ is a hyperparameter representing "human-preferred length" and that selecting $K$ is inherently subjective (Appendix D.3). A follow-up would empirically calibrate $K$ against human preferences by running a user study: show human raters pairs of model responses to the same LongFact prompt (where the responses have different numbers of supported facts but similar precision), ask them to choose which response has "better long-form factuality," and fit a psychometric function to estimate the point at which additional supported facts stop increasing preference. This would determine whether $K$ is relatively stable across prompts and topics (suggesting a universal "information saturation" point for human readers) or varies widely (suggesting that per-prompt or per-topic $K$ calibration is needed). The paper's correlation with Chatbot Arena ELO (Appendix A.6, Figure 9) provides preliminary evidence that recall matters, but a direct calibration study would transform $K$ from an arbitrary hyperparameter into an empirically-grounded one.

Stress-testing SAFE against adversarial factual claims. SAFE is evaluated on naturally-occurring model responses (Section 4), but it is unclear how it handles adversarially-constructed claims designed to exploit weaknesses in search-augmented verification. A stress-test would construct a dataset of "hard-to-verify" facts: claims that are false but appear true from search snippets (e.g., "The 1973 oil crisis was caused by OPEC's decision to embargo oil exports to the United States" — true in popular narrative but incomplete and misleading without the context of prior production cuts), claims that are true but appear false from search snippets (e.g., obscure but verifiable scientific facts that are buried in paywalled papers), and claims that are ambiguous or contested (e.g., claims about politically charged historical events where search results reflect conflicting narratives). Evaluating SAFE on this dataset would characterize its robustness to adversarial fact patterns and identify failure modes that the current evaluation (based on naturally-occurring model outputs) misses. This would also inform whether SAFE can serve as a reliable factuality evaluator for models that intentionally optimize their outputs to score well under SAFE-like evaluation — a form of evaluation gaming that becomes relevant as the metric gains adoption.

Combining SAFE with retrieval-augmented generation for closed-loop factuality improvement. The paper establishes that SAFE can reliably detect factual errors in long-form responses, but it does not close the loop by using those error detections to improve the generating model. A follow-up would implement a SAFE-guided revision loop: given a model response and its SAFE evaluation (with per-fact supported/not-supported labels), feed the unsupported facts back to the model along with the search results that contradicted them, and prompt the model to produce a revised response. This is the natural extension of the paper's revision model concept (from the earlier test-time compute analysis) into the long-form factuality domain, but using SAFE's search-based verification rather than a trained verifier model. The experiment would measure: (1) does SAFE-guided revision reduce the not-supported fact rate in revised responses? (2) does it introduce new factual errors (analogous to the 38% reversion rate documented in the math revision experiments)? (3) what is the cost-effectiveness compared to simply generating a longer initial response? This would directly test whether SAFE is useful not just for evaluation but for improvement — transforming it from a benchmark tool into a component of a factuality-enhancing system.

Practical Applications and Downstream Use Cases

Automated factuality regression testing for LLM deployments. Any organization deploying an LLM in a setting where factual accuracy matters (customer support, educational tools, medical information, legal advice) needs to know whether model updates improve or degrade factuality. The current standard — periodic human annotation — is too slow and expensive to run on every model release. SAFE at $0.19 per response makes it feasible to run **automated factuality regression tests on every model checkpoint**: maintain a fixed set of LongFact prompts (or a domain-specific prompt set generated using the paper's method from Appendix B), run each candidate model on those prompts, evaluate with SAFE, and flag any statistically significant regressions in$ F_1@K $before deployment. For a team testing 10 model checkpoints per week on 250 prompts, the total evaluation cost would be approximately$ 475 per week — less than the cost of one human annotator's day of work — while providing more reliable and more comprehensive factuality assessment. The paper's finding that SAFE outperforms crowdsourced human annotators on disagreement cases (76% vs. 19%) means this automated pipeline would likely catch regressions that human spot-checks would miss.

Difficulty-routing for LLM-powered Q&A systems. The paper's finding that test-time compute strategies are difficulty-dependent — and the LongFact/SAFE framework's ability to calibrate model-specific difficulty — enables a practical model routing system. A production Q&A system could use SAFE (or a lightweight classifier trained on SAFE outputs) to estimate the difficulty of incoming user questions relative to a pool of available models. Easy questions (where the base model achieves high $F_1@K$ even with short responses) could be handled by a fast, cheap model. Medium questions could be routed to a larger model or augmented with additional test-time compute (search, revision loops). Hard questions (where no available model achieves adequate factuality) could be flagged for human review or responded to with explicit uncertainty qualifiers. This is not speculative — the paper's Table 2 and the difficulty-dependent analyses from the prior sections provide the calibration data needed to set routing thresholds. For example, if a deployment's factuality requirement is $F_1@64 \geq 85$ , Table 2 shows that GPT-4-Turbo, Gemini-Ultra, and PaLM-2-L-IT-RLHF meet this threshold on average, while GPT-4, Claude-3-Opus, and Claude-3-Sonnet are borderline, and smaller/older models fall short. A routing system would use per-topic or per-prompt difficulty estimates (rather than just the global average) to make decisions at finer granularity.

Data quality filtering for pretraining and fine-tuning corpora. Large-scale web-crawled datasets used for LLM pretraining and fine-tuning contain substantial amounts of factually incorrect information. SAFE provides a scalable way to filter or weight training examples by factuality. For a target domain (e.g., medical information, legal advice, historical facts), run SAFE on a sample of documents from the training corpus, measuring the supported-fact rate per document. Documents with low supported-fact rates can be downweighted, filtered out, or flagged for human review. At $0.19 per evaluated response, filtering a corpus of 1 million documents would cost approximately$ 190,000 — not cheap, but potentially cost-effective compared to training a model on contaminated data that produces factual errors requiring expensive post-deployment fixes. More realistically, SAFE could be used to evaluate and calibrate automatic filtering heuristics: run SAFE on a representative sample, train a lightweight classifier to predict SAFE's factuality scores from surface features (text complexity, source reputation, citation density), and apply the classifier to the full corpus. The paper's open-source release makes this integration straightforward.

When to Prefer This Method

The paper positions SAFE and F₁@K against specific named alternatives, making a decision framework explicit. The relevant comparisons are: (1) SAFE vs. crowdsourced human annotation with Wikipedia-based verification (the FActScore approach from Min et al., 2023), (2) SAFE vs. reference-based automated metrics (BLEURT, ROUGE) for factuality evaluation, and (3) F₁@K vs. precision-only metrics (FActScore, Tian et al., 2023).

Prefer SAFE over crowdsourced human annotation when:

Evaluation budget is constrained (SAFE costs $0.19/response vs.$ 4.00/response for human annotation — a 21× cost reduction).
Evaluation must scale to thousands of responses (the paper demonstrates evaluation of 496 responses for $96.31; equivalent human annotation would cost$ 1,984).
Rapid turnaround is needed (SAFE runs in minutes per response via API calls; human annotation takes hours to days).
The evaluation domain is covered by Google Search results (SAFE's error analysis in Appendix A.3 shows that "Google Search" is a failure category when necessary information is not in search results — for domains where critical facts are not indexed by Google, human annotation with access to proprietary databases may be necessary).

Prefer crowdsourced human annotation over SAFE when:

The factuality claims require expert-level domain knowledge that general web search cannot provide (Appendix A.10 acknowledges SAFE does not match expert humans — a physician evaluating medical claims or a lawyer evaluating legal claims would outperform SAFE on their domain).
The facts involve controversial or contested claims where search results present conflicting narratives and expert judgment is needed to weigh evidence quality (SAFE's synthesis step can identify conflicting information but does not have a mechanism for resolving which source is more authoritative).
The evaluation requires nuanced judgment about degrees of factuality rather than binary supported/not-supported labels (e.g., "mostly true but misleading by omission").

Prefer F₁@K over precision-only metrics when:

Comparing models with similar precision but different response lengths (Table 2 shows that precision is compressed into an 82-93% range while recall varies from 20 to 99 — precision alone cannot differentiate most models).
The use case values thoroughness (e.g., educational Q&A, research assistance, medical explanations), as evidenced by F₁@64's significant correlation with human preferences ( $r = 0.754$ , $p = 0.031$ ) versus precision's non-significant correlation ( $r = 0.502$ , $p = 0.205$ ) in Appendix A.6.
Evaluating models that may "game" precision by being terse — a model that responds with one perfectly accurate sentence achieves precision = 1.0 but recall near zero, and F₁@K correctly penalizes this.

Prefer precision-only metrics when:

The use case values conciseness over thoroughness (e.g., real-time assistants where users want the shortest correct answer, not the most comprehensive one).
$K$ cannot be reasonably calibrated (if there is no way to estimate what response length users consider sufficient, the recall component adds an arbitrary parameter rather than meaningful information).
The evaluation is at very low response lengths (1-2 sentences) where recall is inherently saturated at 1.0 for any reasonable $K$ and F₁@K reduces to precision.