Logprobs and Confidence: Model Preference Does Not Equal Answer Trustworthiness

At each position, a language model outputs not a single token but a complete probability distribution: given the preceding token sequence, every candidate token in the vocabulary has a conditional probability. To assess the likelihood of an entire candidate sequence x₁…xₙ, the most natural approach is to multiply the conditional probabilities at each position together:

P(x₁…xₙ) = P(x₁) × P(x₂ | x₁) × … × P(xₙ | x₁…xₙ₋₁)

This expression is formally correct, but computing it directly causes problems. Each factor is a number less than 1; once the sequence is even slightly long, the product shrinks so quickly that it reaches a magnitude that computer floating-point numbers cannot represent, underflows, and the score becomes 0, making different candidate sequences incomparable from then on. The multiplicative form is also inconvenient for incremental accumulation: any change requires recomputing the entire chain.

Taking the natural logarithm solves both problems at once. The logarithm turns multiplication into addition:

log P(x₁…xₙ) = Σₜ₌₁ⁿ log P(xₜ | x<t)

Here P is the probability the model assigns to an event, log is the natural logarithm, xₜ is the token at position t, x<t is the prefix before it, n is the total number of tokens in the sequence, and t is the summation position index. Thus the input to the sequence logprob is the token probability at each position under the established prefix, and the output is a log score for the entire candidate sequence that can be added and compared. Probability always lies between 0 and 1, so each term log P(xₜ | x<t) is no greater than 0: the closer the total logprob is to 0, the higher the generation probabilities of the tokens in the sequence overall, and the stronger the model's relative preference for the entire sequence; the more negative the logprob, the lower the model considers the probability of tokens at certain positions.

The value of the logarithm ends there: it stably turns the product of many small probabilities into additive, comparable scores, mitigates floating-point underflow, and lets different candidates be ranked on the same scale. It is not responsible for judging whether content is true or false. A high logprob only means the model prefers this token sequence more; it does not imply that it is more factually correct—preference and correctness are two different questions: the former is answered by score ranking, and the latter requires factual evidence outside the model.

A multi-token answer does not have a single probability in the model; there are only conditional logprobs for the token at each position. To turn these into “the confidence of this answer,” you must aggregate: the input to answer aggregation is the logprobs of multiple tokens, and the output can be a sum, an average, the weakest position, or a task-specific score. Different aggregation methods imply different assumptions, and each has its own shortcomings.

The sum simply adds all token scores. Since each term is no greater than 0, the more tokens there are, the more the sum is penalized, and the score decreases monotonically with length; this means the sum naturally favors short sequences, and a long correct answer may lose to a short incorrect answer. The average divides the total score by the number of tokens, canceling out the length effect, but it may obscure a critical token: what really determines correctness in a sentence is often just one low-probability token, such as the word in the answer that carries the core fact or a negation, while the other tokens all have high probabilities; after averaging, that danger signal is diluted and the entire sentence still looks trustworthy. The weakest position takes the minimum token logprob in the entire sentence, zeroes in on this danger point, but it is insensitive to the overall probability of the rest of the sentence.

No aggregation method is inherently correct. The right approach is to first define the task unit and candidate specification: determine whether the smallest unit to score is a token, a label, or a whole sentence, and determine whether the candidate set is controlled labels or free text; then use a validation set to measure the actual performance of different aggregation methods on that task before choosing one. For classification tasks, controlled labels have only a few fixed options, so it is better to compare the complete token-sequence score of each label rather than only the score of a single token; for free-text generation, the same meaning has multiple semantically equivalent expressions, and texts such as “the answer is sunny” and “sunny” are written differently but mean the same thing, yet their scores may differ greatly. At this point, the limits of a single string score become especially obvious—using the score of a specific string to represent “answer confidence” is itself untenable.

The goal of a language model is to reproduce the statistical regularities of its training data, not to verify facts. It is entirely possible for it to fluently say something false with a very high logprob. Therefore, the input for factual diagnosis should include both the model's high-scoring answer and independent evidence, and the output should separate the two judgments—"language preference" and "factual correctness"—rather than using a single score to represent both at once.

At least three mechanisms independently push logprob higher, even when the proposition itself is false. The first is training frequency: common statements that appear repeatedly in training data—including widely circulated false claims—naturally have high probability. The second is prompt suggestion: the wording of the question and clues given in the context can steer the model toward a certain answer; even if that answer contradicts the facts, the model will follow the suggestion and give high-scoring output. The third is fluency patterns: sentences that conform to grammatical habits and connect smoothly with the surrounding text naturally have high probability, and "smooth-sounding" and "correct" are two different things.

Conversely, rare but correct answers can receive low scores: a correct but obscure name, or an accurate but uncommon phrasing, can have low logprob because they appear less often in training data. So logprob measures the model's language preference, not the truth value of a proposition, and cannot be used as a fact verifier. To use logprob for factual judgment, you must introduce evidence from outside the model: retrieve external materials, call tools to verify, or have a person verify the facts about the world. When independent evidence disagrees with the model score, facts should follow the evidence, not the score.

For “confidence 0.8” to be a statement with empirical meaning, one must answer a question: among all predictions labeled 0.8, in the long run are about 80% actually correct? Calibration solves exactly this. The input to calibration is the model’s raw scores and true labels on independent data, and the output is a mapping from scores to empirical accuracy.

The approach is to put predictions with similar scores into the same bucket and compute the true accuracy in each bucket. If the average score of the samples in a bucket is 0.8, then in the long run about eight out of ten predictions in that bucket should be correct; a bucket with an average score of 0.6 should be about six out of ten correct. If a bucket is actually only half correct, it means the model is overconfident in this range, and its scores need to be mapped back to a lower empirical frequency rather than being used literally.

The mapping can be fit on an independent calibration set using methods such as temperature scaling and isotonic regression. One boundary to remember here is: the fitted mapping holds only for the target task and that data distribution. If any of the model version, prompt wording, or input distribution changes, the original mapping may become invalid and must be recalibrated with new data. Calibration translates “the number given by the model” into “the frequency that actually occurs,” but it does not change the model’s knowledge, nor does it verify any fact—it only ensures that, when the distribution is unchanged, the statistical meaning of the score is consistent with the true accuracy.

After calibration, the system must still do something when facing low-confidence samples: answering anyway may be wrong, while refusing to answer across the board wastes its capability. Selective prediction addresses exactly this decision. Its inputs are calibrated scores, error costs, and coverage requirements; its output is a specific action: answer automatically, supplement retrieval, escalate, clarify, or refuse to answer.

The core mechanism is the threshold. Set a bar on the score: samples above the threshold are answered directly by the model; samples below it are sent down a safer fallback path, such as answering after supplemental retrieval, escalating to a stronger model, asking the user for clarification, or routing to human handling. The higher the threshold, the more low-score samples are sent to safe fallback, so overall system risk is usually lower, but coverage declines accordingly—fewer samples can be handled automatically, and product usability suffers.

Therefore, the threshold cannot be chosen by accuracy alone. Whether it is worth refusing to answer must consider both error cost and coverage: for high-cost tasks it is worth setting the threshold high, preferring more refusals and more human handoffs; for low-cost tasks you can relax the threshold to preserve the share handled automatically. The coverage–risk curve and business cost are the basis for choosing the threshold; looking only at “accuracy goes up after refusal” will miss the cost brought by a collapse in coverage.

“Yes” and “No” may look like just two tokens, but in practice you cannot assume you can read the score at a single position. The inputs for API verification must be the tokenizer actually used, the complete text of the candidate labels, and the position information returned by the API; the output is the complete sequence score for each canonical label. Skipping this step means the comparison is built on the wrong comparability basis.

Three situations break the single-token assumption. The first is tokenization: a label may be split into multiple tokens, for example a label containing a space or a string not present in the vocabulary. “No” may be a single token, while “is not” may be split into two. The second is shared prefixes: when multiple candidates share the same prefix, the score for the prefix part is the same for all candidates; what actually distinguishes them is the token after the prefix. Comparing only the score at the starting position mistakes the shared part for a difference. The third is whitespace and formatting: the token text returned by the API may have a leading space. The same word at different positions may correspond to different tokens, directly affecting which score belongs to which label.

The API return values themselves also have two pitfalls. If a token is absent from the top-k list, it only means it did not make the top k; this does not mean its probability is zero. To obtain its score, you must explicitly request it or recompute it. Raw logprobs across models also have no common scale: different vocabularies, different tokenization methods, and different training distributions mean that a −1.2 from model A and a −1.2 from model B do not represent the same thing and cannot be directly compared. The correct approach is always: use the actual tokenizer to fully tokenize the candidate label, aggregate the scores across the entire sequence, and confirm that the API returns the required positions and candidate set.

For an answer consisting of two tokens, if the conditional probabilities of the two tokens are 0.8 and 0.25 respectively, what is the joint probability of the entire answer? The inputs of the manual calculation are these two conditional probabilities, and the outputs are four numbers: the joint probability, total logprob, average logprob, and geometric mean probability. They describe the preference for the same sequence but serve different purposes.

First, multiply the conditional probabilities autoregressively: P = 0.8 × 0.25 = 0.20. Second, take the natural logarithm of each probability: log 0.8 ≈ −0.223, log 0.25 ≈ −1.386, and add them to get total logprob ≈ −1.609. Third, verify the interchange: take exp of the total logprob, exp(−1.609) ≈ 0.20, recovering the original joint probability. Then divide the total logprob by the token count 2 to get average logprob −0.805; take exp of that, exp(−0.805) ≈ 0.447, which is the geometric mean probability—an equal-weight representative value of the two tokens' individual probabilities.

For the same sequence, different aggregation methods yield different numbers and also represent different preferences. Total logprob −1.609 measures the preference for the entire sequence, but since each term is non-positive, it favors short sequences. Average logprob −0.805 measures average fluency, but may mask some critical low-probability token. Minimum token logprob −1.386 corresponds exactly to that 0.25 token, directly exposing the weakest position, but it is noisy and easily affected by fluctuations of a single token.

These numbers all describe “how much the model prefers this sequence,” not “how correct the answer is,” and cannot be conflated with accuracy. Before comparing candidates, you must first define the task unit: label classification and free text should not share an unvalidated aggregation formula; otherwise, no matter how accurate the manual calculation is, the ruler used for comparison is wrong.

API returns only local probabilities at each position; it is several layers away from “what the system should do.” The decision chain turns token logprob into auditable actions: inputs include token logprobs, task units, calibration data, and business cost, and outputs are automatic answering or fallback actions.

The chain is divided into three stages. The first stage is sequence or semantic aggregation: scattered token logprobs are aggregated by task unit into scores for candidate answers; classification tasks aggregate the full label sequence, and free text aggregates by semantic unit. The second stage is independent calibration: independent calibration data is used to map aggregated scores to empirical accuracy, making 0.8 really mean about eight out of ten correct. The third stage is risk threshold decision-making: error cost and coverage are combined to decide between automatic answering and supplementary retrieval, escalation, clarification, or handoff to a human.

From left to right, the entire chain is: token logprob → sequence aggregation → task calibration → risk threshold → system action. Logprob is only a raw signal; aggregation, calibration, and cost thresholds together determine executable actions. Therefore, if any layer in the chain changes—changing model, prompt, aggregation method, or threshold—the entire chain must be replayed, revalidating the output of every layer. Never present raw local probabilities directly as confidence: unaggregated and uncalibrated token scores are neither the accuracy of the answer nor a decision basis on which the system can act.

“Yes” is one token, “No answer” is two tokens, directly comparing the first-token scores of the two is obviously unfair. The input for candidate comparison is a shared prompt and multiple complete labels; the output is the conditional logprob of each label's entire sequence. The method is: fix the prompt shared by all candidates, then use teacher forcing to accumulate token by token—feed the candidate label token by token, record the log probability of each token conditioned on “shared prompt + already provided prefix”, and accumulate until the end of the label. You cannot only read the first token, because candidates may share a prefix; nor can you treat candidates that do not appear in the API top-k as probability 0.

Written out as a formula:

score(c) = Σₜ₌₁..|c| log p(cₜ | prompt, c<t)

Where c is a complete candidate label, |c| is its number of tokens, cₜ is the t-th candidate token, c<t is the prefix of the candidate that has already been provided, prompt is the prompt shared by all candidates, p is the token probability under the current condition, and score(c) is the total logprob of the entire candidate. Each candidate is calculated in this way, so comparisons are based on the same prompt and the same accumulation method.

Length is still a problem: if the task allows expressions of different lengths, the sum will favor shorter labels. In that case either prescribe canonical labels in advance so all candidates have the same length, or use length normalization and confirm on a validation set that the correction is effective. Once the tokenizer changes, segmentation, sequence length, and normalization space all change, and all scores must be recomputed. Across models it is even more thoroughgoing: different tokenizers leave raw scores without a common scale, so when doing model routing, you should calibrate each model separately and then compare calibrated expected risk, rather than directly comparing average logprob.

In free-form generation, the same meaning can be written as many different strings: “the French capital,” “Paris,” and “Paris, the capital of France” appear to be three answers but are actually one meaning. If we do not merge them, when the model samples multiple times, the probability will be spread across many synonymous expressions; each string individually has a very low score, and the signal that “the model thinks the answer is Paris” is diluted. Semantic aggregation aims to solve this problem: its input is the strings from multiple generations and a task equivalence judge, and its output is meaning clusters and the cumulative probability of each cluster.

The approach is to first use an equivalence judge to cluster the strings into meaning clusters, then sum the probabilities of all expressions within each cluster to obtain a distribution over clusters—this distribution is closer to the true uncertainty of the task. Different tasks require different judges:

For math problems, parse the candidates and perform algebraic simplification to recognize equivalent forms; for code problems, merge by test behavior, so two implementations that pass the same set of tests count as the same cluster; for factual question answering, perform entity normalization and entailment judgment, grouping aliases and abbreviations into the same entity; for open-ended advice, we can only rely on semantic clustering, and cluster boundaries are inherently subjective.

The judge itself can make mistakes: erroneous merging combines different meanings into one cluster, erroneous splitting separates synonymous expressions into two clusters, alias normalization can also lose details, and incomplete tests likewise lead to merging errors. Therefore, clustering results must be validated with human annotations; only after confirming that the merge and split boundaries align with the task semantics do cluster probabilities become meaningful.

Raising the threshold from −1.2 to −0.5 does not necessarily make the system safer; it may simply answer less. To judge the effect of a threshold change, you need coverage-risk analysis: input the calibrated scores, true labels, and action costs on a validation set, and output the coverage, accepted error rate, and expected cost at each threshold.

The way to draw the curve is sorted expansion. On the validation set, sort samples by calibrated score from high to low, then gradually expand the automatically answered set starting from the highest-scoring samples; at each coverage point calculate the error rate among the answered samples, and connect them to obtain the coverage-risk curve. The curve directly answers the threshold question: raising the threshold usually lowers coverage, but risk does not necessarily decrease monotonically; if templated hallucinations happen to be mixed into the high-score region, the curve will rise there, exposing a calibration failure on that slice—score ordering has not pushed risk to the low-score end. Conversely, if raising the threshold only lowers coverage without lowering risk, this indicates that score ordering or calibration has failed on that slice.

Product decisions cannot pursue accuracy alone; they must compare expected cost. The expected cost at threshold τ is:

E[cost(τ)] = Cerr × P(incorrect and accepted) + Cabstain × P(abstain) + Cverify × P(escalation verification)

Here E[cost(τ)] is the average business cost at threshold τ, and τ is the automatic acceptance threshold; Cerr, Cabstain, and Cverify are the costs of one incorrect acceptance, one abstention, and one escalation verification, respectively; P is the empirical probability of the corresponding action event on the validation set. All terms must be computed over the same evaluation period and task slice; costs across slices are not comparable.

Different slices must be plotted separately because the risk structures differ: for short answers and long answers, aggregated scores are affected by length, so they should be normalized and calibrated separately; for common domains and new domains, there is distribution shift, and the model tends to be overconfident in new domains, so it should first retrieve or hand off to humans; for low-loss and high-loss errors, even if the error rate is the same, the business costs are completely different, so different thresholds should be adopted; when the model or prompt version changes, the score scale may shift as a whole, requiring version-level replay and recalibration.

Post-launch monitoring likewise cannot look only at a single average: you need to record scores, actions, final labels, and slices; monitoring only the average logprob cannot detect localized miscalibration on a particular language, task, or answer length. True labels often arrive with delay, so you can first monitor drift in the score distribution and abstention rate, but these signals can only trigger investigation, not replace accuracy feedback.

From raw output to verifiable practice, the entire causal chain can be connected link by link.

At each position, the model outputs only token probabilities. These probabilities need to be combined into a score across the entire sequence; taking logarithms turns products into sums, so the sequence score becomes additive and comparable. But length and tokenization directly affect this score: the longer the sequence and the more fragmented the tokenization, the lower the sum; the choice of aggregation is therefore not a detail but part of what determines the meaning of the score.

The aggregated score still expresses only language preference, not correctness. Calibration on independent data is needed to map the score to the actual frequency of correctness, before 0.8 acquires the empirical meaning of “about eight out of ten correct.” With calibrated scores, threshold decisions begin to make sense: raising the threshold trades coverage for risk; lowering the threshold trades risk for coverage.

Finally, the entire chain is built on a specific distribution. Once the model, prompt, or input distribution changes, the assumptions in each link may fail; the chain must be continuously recalibrated with new data so it does not silently break at some link.