DecisionFormer has two confidence fields. Check which one you are thresholding.

#ai #python #machinelearning

A probability vector goes in. Two objects come out with a field named confidence. One says 0.442. The other says 0.800.

Before adjusting a review threshold, I would check which object produced the number.

DecisionFormer is a newly released library for turning supported language-model backbones into decision models. Its release explains a useful distinction: the response’s confidence can describe how concentrated the option distribution is. While tracing the code, I found a second distinction worth keeping in an integration test: offline prediction records use the top option probability for their confidence field. [1–3]

Computed from one synthetic probability vector and checked against the pinned source. These are scores, not model benchmark results.

Follow the object, not just the key 🔎

I inspected commit 05a520d of the public repository. In formats.py, PromptFormat.answer constructs the answer object used by the System One response format. It delegates the confidence calculation to the selected prompt format. For a D3-style choice, that is one minus normalized entropy. [2]

In inference.py, the batched prediction-record construction stores probabilities[best] as confidence. The calibration metrics in metrics.py also use the predicted class’s probability. [3, 4]

These are different contracts serving different purposes. A threshold copied from an offline prediction file into a response consumer can silently change meaning, even when the key has the same spelling. This source check concerns choice questions at the pinned revision; it is not a claim that every response type has the same fields.

Work through one vector

Use probabilities 0.80, 0.15, 0.05. The largest option probability is plainly 0.80.

Entropy measures the spread of the whole distribution:

H(p) = −Σ pᵢ ln(pᵢ)

For three options, the maximum entropy is ln(3). D3 confidence divides by that maximum and subtracts from one:

confidence = 1 − H(p) / ln(3)

The result is about 0.442142. AutoJev-style choice confidence instead rescales the largest probability relative to uniform chance, giving 0.700000. The offline record’s top-probability value is 0.800000.

Here is the arithmetic without loading a model:

import math
p = [0.80, 0.15, 0.05]
n = len(p)
h = -math.fsum(x * math.log(x) for x in p if x > 0)
d3 = 1 - h / math.log(n)
autojev_choice = (max(p) - 1 / n) / (1 - 1 / n)
print(f"D3 response: {d3:.6f}")
print(f"AutoJev choice response: {autojev_choice:.6f}")
print(f"Offline prediction: {max(p):.6f}")

D3 response: 0.442142
AutoJev choice response: 0.700000
Offline prediction: 0.800000

I checked this calculation against the actual pure confidence method extracted from the pinned source, including uniform, concentrated and single-option boundary cases. No model weights or inference were involved. ✅

The threshold that changes its mind

Suppose a consumer accepts a decision when confidence >= 0.7. That is an illustrative rule, not a recommended production threshold.

With this vector, the offline prediction record passes. The D3 response does not. Nothing about the model’s probabilities changed; the consumer applied the same cutoff to two different quantities.

Even within entropy confidence, the number of options matters. Keeping the top probability at 0.8 gives about 0.278 for [0.8, 0.2], but about 0.517 for [0.8, 0.05, 0.05, 0.05, 0.05]. Both the remaining spread and the normalization changed. A confidence threshold is not automatically portable across task schemas. ⚠️

There is another trap: a concentrated distribution can still confidently choose the wrong answer. Entropy does not compare predictions with labels, so it cannot establish calibration by itself. The library’s metrics correctly need labeled examples to calculate accuracy, negative log likelihood, Brier score and expected calibration error. [4]

Make the boundary explicit

In an application, I would preserve the full probability vector and record which response format produced it. I would name the derived values explicitly—top_probability and distribution_concentration—inside my own data model, then test the threshold against a frozen example like this one.

That does not require changing the library’s public API. It requires refusing to let a familiar field name stand in for a definition.

Temperature scaling is a separate part of the story. DecisionFormer fits temperatures on calibration data; the release describes keeping that data separate from training. That workflow is a design choice to inspect and validate on your own labeled task, not a guarantee that a score will stay calibrated after the deployment population changes. [1, 4]

My result here is a source-level integration check. I did not train a decision model, measure its accuracy, or reproduce the project’s serving benchmarks. The practical payoff is smaller and immediately usable: know which confidence you are putting a threshold on. 💡