A language model can produce a fluent answer even when it is uncertain. Token probabilities help describe uncertainty during generation, but they can be misleading at the answer level because many different strings can express the same meaning.
Consider a question whose correct answer is Paris. A model might generate Paris, The answer is Paris, and France's capital is Paris. These strings differ, yet they represent the same answer. Treating them as three unrelated outcomes exaggerates the apparent uncertainty.
Semantic entropy addresses this problem by measuring uncertainty over meanings rather than exact strings. The basic workflow is to generate several answers, group answers that are semantically equivalent, estimate the probability mass of each group, and calculate entropy over those groups.
This article explains that mental model, shows a small numerical example, and covers the practical choices and failure modes that matter when using semantic entropy as an LLM uncertainty signal.
Start with uncertainty over answers, not wording
Suppose an LLM answers the same factual question six times:
1. Paris
2. The capital is Paris.
3. Paris, France.
4. Lyon
5. It is Paris.
6. Lyon, France.At the string level, several responses are unique. At the meaning level, there are only two important answer groups:
Group A: Paris meaning -> 4 samples
Group B: Lyon meaning -> 2 samplesIf we use sample frequencies as a simple estimate of group probabilities:
p(Paris meaning) = 4 / 6 = 2/3
p(Lyon meaning) = 2 / 6 = 1/3The entropy of these semantic groups is:
H = -sum p(g) * ln p(g)so:
H = -[(2/3) ln(2/3) + (1/3) ln(1/3)]
≈ 0.637 natsIf all six generations expressed the same answer, the empirical semantic entropy would be zero. If probability mass were spread evenly across many incompatible meanings, entropy would be higher.
The important shift is simple: variation in wording is not the same as variation in belief.
Why token entropy answers a different question
An autoregressive LLM predicts one token at a time. At each position it produces a probability distribution over possible next tokens. Entropy over that distribution describes local uncertainty about the next token.
But local token uncertainty can be high while semantic uncertainty is low. For example, these prefixes can lead to different tokens while preserving the same answer:
"Paris"
"The answer"
"France's capital"Conversely, a model can generate one answer with high token-level confidence while being systematically wrong. Confidence is not correctness.
Semantic entropy therefore does not replace token probabilities. It aggregates uncertainty at a different level: whether repeated generations support one meaning or several incompatible meanings.
That makes it potentially useful for tasks where the application cares about the final proposition, such as question answering, summarization of a specific fact, or extracting a conclusion from text.
Build semantic groups before computing entropy
The difficult part is not the entropy formula. It is deciding whether two generations mean the same thing for the task.
For a simple factual question, equivalence may be straightforward:
"Paris"
"The answer is Paris"For richer answers, equivalence becomes conditional on context. Consider:
A: The service failed because the database timed out.
B: A database timeout caused the service failure.
C: The service failed after a database timeout.A and B make the same causal claim. C only states temporal order and does not necessarily claim causation. A grouping method that merges all three loses an important distinction.
This is why semantic grouping should be designed around the question being evaluated. Two responses are equivalent only if their differences do not change the answer that matters for that task.
Possible grouping mechanisms include task-specific normalization, a natural-language inference model, another language model used as a judge, or human annotation. Each introduces its own errors and cost.
Estimate group probability carefully
The six-sample example used frequency counts because they are easy to understand:
estimated p(group) = samples in group / total samplesThis empirical estimator has an obvious limitation: with few samples, rare meanings may never appear. Ten identical generations do not prove that the model assigns zero probability to every alternative meaning.
Some semantic-entropy methods use sequence likelihoods from the generating model to estimate probability mass rather than relying only on counts. That can use more information from each generation, but it introduces additional implementation choices around sequence scoring, length effects, and normalization.
For application engineering, keep the estimator explicit. Do not report a number called semantic_entropy without documenting how generations were sampled, how meanings were grouped, and how group probabilities were calculated. Those choices define what the number means.
Sampling settings are part of the measurement
Semantic entropy relies on observing alternative generations, so decoding configuration directly affects the estimate.
If generation is nearly deterministic, repeated calls may return the same answer even when plausible alternatives exist. If sampling is extremely broad, the model may produce low-probability oddities that inflate apparent uncertainty.
Temperature, truncation methods such as top-p sampling, maximum output length, and prompt wording can all change which answers are observed. Therefore, compare semantic-entropy values only under a controlled evaluation protocol unless you have established that the protocols are comparable.
A practical evaluation record should include at least:
model version
prompt template
sampling parameters
number of generations
semantic grouping method
probability estimatorWithout this context, a threshold learned in one experiment may not transfer to production traffic or a new model version.
Use semantic entropy as a signal, not a truth detector
High semantic entropy can indicate that a model’s sampled answers disagree in meaning. That is useful, but it does not tell you which answer is correct.
Low semantic entropy is also not proof of correctness. A model can consistently repeat the same misconception. If all generations confidently say Lyon when the correct answer is Paris, semantic entropy can be low while factual error is high.
This distinction is essential when building abstention or escalation systems. Semantic entropy can help identify cases worth checking, but correctness still requires evidence such as labeled evaluation data, retrieval from trusted sources, deterministic validation, or human review depending on the task.
A useful mental model is:
semantic entropy -> disagreement signal
not
semantic entropy -> correctness probabilityDo not convert entropy directly into statements such as “the answer is 90% correct” unless a separate calibration study supports that interpretation for the specific system and data distribution.
Choose thresholds from downstream costs
Suppose a support assistant can either answer automatically or send a case to a human. A team might escalate when semantic entropy exceeds a threshold.
The threshold should not be chosen because a particular entropy value looks mathematically large. It should be selected from validation data according to the costs of the decision.
For example, evaluate several thresholds and measure:
fraction of cases escalated
error rate among auto-answered cases
important errors missed by the threshold
latency and generation costIf human review is expensive, the system may tolerate more uncertainty before escalating. If a wrong automated answer is costly, a lower threshold may be appropriate.
The useful threshold can also differ by task. Short factual questions and open-ended troubleshooting answers do not necessarily produce comparable entropy distributions.
Account for generation and grouping cost
A single LLM response requires one generation. Semantic entropy normally requires multiple generations plus semantic grouping. That makes it more expensive and slower than using one response alone.
If grouping uses another model, the cost grows further. Some work can be parallelized, so latency does not necessarily increase in direct proportion to the number of samples, but total inference work still matters.
This creates a practical trade-off. Semantic entropy can be valuable for high-impact decisions where uncertainty detection justifies extra compute. It may be excessive for low-risk, high-volume tasks where a cheaper signal performs well enough.
A common architecture is to use inexpensive checks first and reserve multi-sample uncertainty estimation for cases that remain ambiguous. Whether that cascade helps depends on the application’s error costs and traffic distribution.
Watch for common failure modes
Too few generations produce unstable group frequencies. A semantic meaning that appears once in five samples can look important or disappear entirely in another run.
Bad semantic grouping can dominate the result. Merging contradictory answers artificially lowers entropy; splitting paraphrases artificially raises it.
Uncontrolled decoding changes make historical thresholds unreliable. Changing temperature or model version can shift the entropy distribution even if the product task is unchanged.
Open-ended tasks may contain many valid answers. High semantic diversity can then reflect legitimate creativity rather than dangerous uncertainty. Define equivalence around the task’s required decision, not around whether entire responses are identical.
Consistent hallucinations can produce low entropy. Always remember that agreement among samples is not external verification.
When semantic entropy is useful
Semantic entropy is a good candidate when an application needs an answer-level uncertainty signal, multiple generations are affordable, and semantic equivalence can be defined reasonably well. It is especially relevant when surface-form variation would make string-level disagreement misleading.
A simpler method is preferable when outputs can be validated directly. If an LLM generates a value that can be checked against a schema, calculator, compiler, database constraint, or trusted source, direct validation often provides a clearer signal than sampling-based uncertainty.
Likewise, if latency permits only one generation, semantic entropy in its multi-sample form may not fit the serving path.
Conclusion
Semantic entropy separates two kinds of variation that ordinary text comparison mixes together: different ways to say the same thing and genuinely different answers. Generate several responses, group them by task-relevant meaning, estimate the probability mass of each group, and compute entropy over those groups.
The formula is simple; the measurement protocol is not. Sampling settings, sample count, semantic grouping, and probability estimation all shape the result. Most importantly, low semantic entropy means the sampled answers agree in meaning. It does not mean they are correct.
Use semantic entropy as one uncertainty signal, validate it on the decisions your application actually makes, and prefer direct verification whenever the task offers a cheaper and stronger check.