Paper · 2026-02-02 · cs.LG, cs.AI
Probability-Entropy Calibration: An Elastic Indicator for Adaptive Fine-tuning
RankTuner reweights each token's supervised fine-tuning loss by a Relative Scale (p_t * s(H_t))^-K. It combines the target token's rank with a bound on the expected rank from output entropy, so under-learned tokens count more. Author-reported: Qwen3-8B MATH-OAI Pass@1 rises from 65.14 to 72.38 (best baseline DFT 70.92).
Token loss reweightingCross-entropy lossfine-tuningtoken-weightingmath-reasoningcode-generation
arXivPDFCodeMarkdown15 min read
AI-compiled by claude-haiku-5-5 on 2026-11-09, not yet reviewed by a human. Every claim cites its source; check it when a detail matters.
In plain words
Fine-tuning nudges a language model toward the right answer one token at a time. Many recent methods give each token a weight based on one number: how likely the model already thought the correct token was, or how unsure the model was about the next word. The paper argues that either number alone misleads. A filler word can look important only because the model is unsure, and a word with several acceptable synonyms can look wrong when it is not.
RankTuner combines both signals by comparing two ranks: where the correct token sits in the model's ordered list of candidates, and where a typical guess would land given how spread out the model's predictions are. Tokens the model is behind on, relative to how hard that position is, get a larger weight. Tokens that are uncertain anyway get a smaller one. The authors apply it to math reasoning and code. Their math gains are clear on most benchmarks, but the code results are mixed, and every number on this page is the authors' own.
TL;DR
RankTuner is a token-weighted cross-entropy loss for supervised fine-tuning. Each token's loss is multiplied by a Relative Scale built from the ground-truth probability and a rank-based bound on the entropy of the output distribution §4.5 alg. 1. The authors report better math Pass@1 than SFT, DFT, TALR, OverTone and EAFT on two backbones, best or near-best on most but not all benchmark and metric pairs tab. 2. On Qwen2.5-Coder-3B it does not beat the original model on HumanEval tab. 13, and the RL extension is untested §4.5 app. B.7.
Problem
Token-level reweighting in SFT usually uses one signal. Probability-dominant weights use the ground-truth probability, and entropy-dominant weights use the predictive entropy §1 §3.1. The authors argue that each misreads some tokens. Entropy-dominant weights up-weight high-uncertainty filler such as "umm", and probability-dominant weights over-penalise interchangeable words such as "essentially" §3.2 fig. 1. In their noise-insertion test, both baselines surface injected noise much more often than RankTuner does tab. 1.
Probability-dominant and entropy-dominant weights are also hard to compare directly, because probability and entropy live on different scales §4. The paper's answer is to express both through rank quantities, which share a unit §4.1 §4.3.
Method
Setting. A weighted NLL objective is written as the sum over tokens of w_t times the negative log-probability of the target token §2.1. SFT uses w_t = 1. RankTuner keeps the same loss and multiplies w_t by a per-token scale S_t eq. 11 alg. 1. For math, the paper sets w_t = p_t as the starting weight §4.5 app. B.6. For general and code tasks it uses w_t = 1 app. B.6 app. C.8.
Rank and expected rank. R_t is the rank of the ground-truth token when the vocabulary is sorted by probability §4.1. The expected rank E[R_t] is the expected number of guesses when guessing from the model's distribution, the sum over ranks i of i times the i-th largest probability eq. 1 §2.3.
Relative Rank Indicator. The indicator is I_t = g(f(R_t) - f(E[R_t])), with f(x) = 1 / log2(x + 1) and g(x) = 2^x eq. 2 §4.1. It is 1 when R_t equals E[R_t], falls as R_t grows, and rises with E[R_t] §4.1 fig. 2. The paper says the particular f and g are chosen for stability and a closed form, not as an optimum, and that other monotone pairs give similar results §4.1 app. C.5.
Bounds that replace probability and entropy. Two bounds link rank quantities to p_t and H_t. The first is R_t <= 1 / p_t eq. 4 app. A.1. The second is E[R_t] >= s(H_t), where s(H_t) = (1/4) * 2^H_t + 1 if H_t >= 2, and s(H_t) = 2 - p_max,t otherwise eq. 5 app. A.2. Entropy here is in bits (log base 2) app. A.2 app. B.1. The paper shows empirically that both bounds are tight on Qwen3-8B chain-of-thought tokens §4.3 fig. 2 fig. 3 app. B.5.
Power-law form. Applying the Cauchy mean value theorem to f and log2 gives f(R_t) - f(E[R_t]) = -K(xi_t) * (log2 R_t - log2 E[R_t]) for some xi_t between R_t and E[R_t] eq. 6 §4.4 app. A.3. Here K(xi) = xi / ((xi + 1) * [log2(xi + 1)]^2), which is positive eq. 6. Therefore I_t = (E[R_t] / R_t)^K(xi_t) eq. 7. The paper says K is about 0.5 for typical reasoning tokens, where R and E[R] are small, and that K falls for high-uncertainty positions §4.4 app. A.4.
Surrogates and the Relative Scale. Replacing R_t by 1/p_t and E[R_t] by s(H_t) gives the surrogate competence (p_t * s(H_t))^K(xi_t) eq. 8. The indicator is at least this surrogate eq. 9 app. A.5. The training weight is the inverse of the indicator, the Relative Scale S_t = I_t^-1 eq. 10 §4.5:
- S_t ≈ (p_t * s(H_t))^(-K(xi_t)), with xi_t = max(R_t, s(H_t)) eq. 10 app. B.1;
- K(xi_t) is simplified to [log2(xi_t + 1)]^-2 by dropping the factor xi / (xi + 1) "for simplicity and training stability" §4.5 app. B.1.
The modified token weight is w~_t = w_t * S_t eq. 11 §4.5.
Training step. Algorithm 1 is a standard SFT loop. For each batch, it runs the model, computes p_t, R_t, H_t, s(H_t), xi_t, K(xi_t), S_t and w~_t for each token, and takes gradient steps on the mean of w~_t times the token loss alg. 1 app. B.1. The algorithm does not define the token loss, so it is taken as the NLL from §2.1. The paper says the extra cost is O(|V|) per token, the same order as the cross-entropy itself, with O(1) extra scalars per token app. B.2.
# RankTuner-weighted SFT loss for one batch [alg. 1] [app. B.1]
# logits: (N, V) at N supervised positions; targets: (N,)
# base_weights: p_t for math, ones for code [§4.5] [app. C.8]
# Output: scalar loss
def ranktuner_loss(logits, targets, base_weights):
# Token NLL l_t = -log p_t [§2.1]
nll = cross_entropy(logits, targets) # (N,)
# Ground-truth probability p_t [§2.1]
gt_prob = exp(-nll) # (N,)
# Rank R_t: count of logits >= the target's logit, target included [§4.1]
gt_rank = count(logits >= logits[targets]) # (N,)
# Output distribution over the full vocabulary [§2.2]
probs = softmax(logits) # (N, V)
# Top probability p_max,t [§4.5] [eq. 5]
max_prob = max(probs, axis=-1) # (N,)
# Entropy H_t in bits over the full vocabulary [app. B.1]
entropy = -sum(probs * log2(probs), axis=-1) # (N,)
# Lower bound s(H_t) on the expected rank E[R_t] [eq. 5]
bound = where(entropy >= 2, 0.25 * 2 ** entropy + 1, 2 - max_prob)
# Clamped argument xi_t = max(R_t, s(H_t)) [app. B.1]
xi = maximum(gt_rank, bound) # (N,)
# Exponent K(xi_t) = [log2(xi_t + 1)]^-2, simplified form [§4.5]
k_xi = 1 / log2(xi + 1) ** 2 # (N,)
# Relative Scale S_t = (p_t * s(H_t))^-K(xi_t) [eq. 10]
scale = (gt_prob * bound) ** (-k_xi) # (N,)
# Token weight w~_t = w_t * S_t [eq. 11]
weights = base_weights * scale # (N,)
# Weighted token loss, averaged over the N tokens [app. B.1]
return mean(weights * nll)Pseudocode notes. The loop runs over batches alg. 1. The code treats the scale as a constant with respect to the parameters; see Paper vs code. The pseudocode above follows the paper, not the code's exact arithmetic.
Hyperparameters
| Name | Value | Where | Notes |
|---|---|---|---|
| optimizer | AdamW | §5.1 | betas, weight decay and gradient clipping not stated |
| learning rate | 5e-5 | §5.1 README.md | same for all models |
| LR schedule | cosine decay, warm-up ratio 0.1 | §5.1 sft_trainer.yaml | warm-up length in steps is ratio times total steps fsdp_general_trainer.py |
| global batch size | 256 | §5.1 README.md | |
| micro-batch size per GPU | not stated | §5.1 | code example uses 8 README.md |
| max input length | 2048 tokens | §5.1 README.md | |
| epochs | not stated | §5.1 | code example uses 1 README.md |
| betas, weight decay, grad clip | not stated | §5.1 | code defaults (0.9, 0.95), 0.01 and 1.0 sft_trainer.yaml; applies to the general trainer fsdp_general_trainer.py |
| training data | NuminaMath-CoT, first 10k | §5.1 | conflicts with code, see Paper vs code |
| base models (main) | Qwen2.5-Math-7B, Qwen3-8B | §5.1 | cross-architecture in tab. 9 |
| hardware | four NVIDIA A800 80GB | §5.1 | |
| framework | verl | §5.1 | |
| eval sampling | 16 samples, temperature 1.0, top-p 1.0, max 4096 tokens | §5.1 app. C.3 | Pass@k uses the combinatorial estimator app. C.3 |
| K(xi) | [log2(xi + 1)]^-2 | §4.5 app. B.1 | paper uses the simplified form in training |
| xi | max(R_t, s(H_t)) | app. B.1 app. C.6 | default; other means in app. C.6 |
| base weight w_t | p_t (math), 1 (general, code) | §4.5 app. B.6 app. C.8 | |
| EAFT K (top-K entropy) | K = 20, ln K approximated as 3 | app. C.2 | baseline setting |
| TALR floor | w_min = 0.01 | app. C.2 | baseline setting |
| Alpha Power alpha | 0.5 | §5.4 | ablation baseline, loss (1 - p^alpha) / alpha |
| Entropy Reg alpha | 0.02 | §5.4 | ablation baseline |
| training K, observed | converges to about 0.9 | app. C.7 | reported as a training-time observation |
Results
Author-reported. Setup: NuminaMath-CoT, first 10k training instances; evaluated on MATH-OAI (called Math500 in §5.1), Minerva Math, OlympiadBench, AIME24 and AMC23 §5.1 tab. 2. Values are percentages tab. 2. The paper reports no seeds, repeats or variance §5 app. C.
Main math results tab. 2:
| Model | Method | MATH-OAI P@1 | MATH-OAI P@16 | Minerva P@1 | Minerva P@16 | OlympiadBench P@1 | OlympiadBench P@16 | AIME24 P@1 | AIME24 P@16 | AMC23 P@1 | AMC23 P@16 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Qwen2.5-Math-7B | Original | 31.79 | 87.80 | 7.63 | 42.28 | 9.49 | 47.85 | 6.25 | 23.33 | 20.47 | 85.00 |
| Qwen2.5-Math-7B | SFT | 53.52 | 88.20 | 17.74 | 50.00 | 19.14 | 55.11 | 2.08 | 10.00 | 24.53 | 82.50 |
| Qwen2.5-Math-7B | EAFT | 53.94 | 87.40 | 20.24 | 59.19 | 18.96 | 54.37 | 2.50 | 10.00 | 24.22 | 67.50 |
| Qwen2.5-Math-7B | OverTone | 47.00 | 87.80 | 18.89 | 51.47 | 16.02 | 51.56 | 2.50 | 20.00 | 25.16 | 75.00 |
| Qwen2.5-Math-7B | DFT | 69.15 | 85.00 | 26.06 | 40.07 | 32.62 | 54.81 | 4.17 | 16.67 | 41.09 | 72.50 |
| Qwen2.5-Math-7B | TALR | 68.83 | 87.40 | 35.68 | 60.29 | 32.87 | 57.78 | 6.67 | 16.67 | 43.44 | 77.50 |
| Qwen2.5-Math-7B | RankTuner | 68.60 | 88.80 | 33.30 | 59.56 | 32.89 | 62.07 | 7.08 | 23.33 | 44.53 | 82.50 |
| Qwen3-8B | Original | 65.14 | 87.40 | 31.39 | 48.53 | 27.19 | 51.11 | 6.04 | 26.67 | 35.62 | 75.00 |
| Qwen3-8B | SFT | 54.83 | 88.60 | 21.42 | 54.04 | 20.13 | 53.33 | 2.71 | 16.67 | 26.25 | 67.50 |
| Qwen3-8B | EAFT | 55.23 | 90.20 | 23.85 | 63.60 | 19.97 | 52.59 | 3.33 | 13.33 | 28.75 | 80.00 |
| Qwen3-8B | OverTone | 35.58 | 82.80 | 17.78 | 57.35 | 11.43 | 44.74 | 1.25 | 13.33 | 16.72 | 67.50 |
| Qwen3-8B | DFT | 70.92 | 86.00 | 32.42 | 47.79 | 35.07 | 58.22 | 8.75 | 16.67 | 45.78 | 75.00 |
| Qwen3-8B | TALR | 70.12 | 89.40 | 40.46 | 61.03 | 34.38 | 60.00 | 7.29 | 26.67 | 43.75 | 80.00 |
| Qwen3-8B | RankTuner | 72.38 | 90.20 | 38.26 | 65.44 | 36.25 | 64.00 | 10.21 | 26.67 | 46.56 | 85.00 |
Source: tab. 2. The paper's Delta rows compare against the Original model and against the best non-RankTuner baseline in each block tab. 2.
Points the table shows and the text does not stress:
- On Qwen2.5-Math-7B, MATH-OAI Pass@1 is 68.60 for RankTuner and 69.15 for DFT, so DFT is higher there tab. 2.
- On Qwen2.5-Math-7B, Minerva Pass@1 is 33.30 for RankTuner and 35.68 for TALR tab. 2.
- The AIME24 Pass@16 of RankTuner equals the Original model on both backbones (23.33 and 26.67) tab. 2 §5.2.
- The AIME24 and AMC23 test sets have 30 and 40 problems in the released data, so single-point gaps there are a few problems [raw data: math_evaluation/data/aime24/test.jsonl, math_evaluation/data/amc23/test.jsonl].
Diagnostic on noise tab. 1 (the paper marks these as lower-is-better; the token columns are precision and recall of the top 10% of tokens, and the sequence column is the hit rate at 10% app. B.3):
| Method | Token precision@10% | Token recall@10% | Sequence hit@10% |
|---|---|---|---|
| Entropy-dominant | 4.54% | 55.33% | 77% |
| Prob-dominant | 3.25% | 39.65% | 77% |
| RankTuner | 2.16% | 26.39% | 9% |
Out-of-distribution tab. 3. Qwen2.5-Math-7B, Pass@1, temperature 0.8, 16 samples, max 3072 tokens §5.3:
| Benchmark | Original | SFT | DFT | EAFT | TALR | RankTuner |
|---|---|---|---|---|---|---|
| ARC-C | 13.46 | 42.30 | 26.50 | 48.57 | 52.54 | 53.58 |
| GPQA | 7.86 | 25.00 | 27.90 | 25.63 | 29.29 | 29.64 |
Other backbones tab. 9. The paper reports Qwen2.5-Math-1.5B, Qwen3-4B and Llama-3.1-8B with the same baselines. RankTuner is not best everywhere. For example, on Qwen2.5-Math-1.5B MATH-OAI Pass@1 it reports 62.00 against 62.94 for TALR tab. 9. The paper notes a few small regressions app. C.4.
Code generation tab. 13. HumanEval and HumanEval+, Pass@1 and Pass@10, with general-task weights w_t = 1 app. C.8:
| Model | Method | HumanEval P@1 | HumanEval P@10 | HumanEval+ P@1 | HumanEval+ P@10 |
|---|---|---|---|---|---|
| Qwen2.5-Coder-3B | Original | 51.34 | 69.05 | 41.66 | 58.62 |
| Qwen2.5-Coder-3B | SFT | 40.91 | 53.81 | 34.82 | 47.03 |
| Qwen2.5-Coder-3B | DFT | 36.29 | 42.93 | 31.70 | 38.13 |
| Qwen2.5-Coder-3B | EAFT | 39.65 | 48.78 | 34.52 | 43.87 |
| Qwen2.5-Coder-3B | TALR | 36.22 | 43.07 | 34.41 | 41.72 |
| Qwen2.5-Coder-3B | RankTuner (w_t = 1) | 41.78 | 55.31 | 35.71 | 48.70 |
| Qwen2.5-Coder-7B | Original | 61.06 | 77.78 | 54.49 | 71.13 |
| Qwen2.5-Coder-7B | SFT | 61.95 | 76.86 | 55.01 | 69.80 |
| Qwen2.5-Coder-7B | DFT | 57.40 | 69.08 | 50.65 | 63.55 |
| Qwen2.5-Coder-7B | EAFT | 59.37 | 70.45 | 56.10 | 70.05 |
| Qwen2.5-Coder-7B | TALR | 58.56 | 67.89 | 52.94 | 62.08 |
| Qwen2.5-Coder-7B | RankTuner (w_t = 1) | 62.72 | 78.56 | 55.76 | 71.96 |
On the 3B model, the original model is the best row on every column tab. 13. The paper reads this as limited capacity app. C.8.
Ablations fig. 4 (values only in the figure; not transcribed here). On AIME24 Pass@k for Qwen2.5-Math-7B, removing the probability term keeps Pass@1 about the same but weakens gains at larger k, and removing the entropy term degrades all k. The paper says both terms matter §5.4 fig. 4. Its dynamic K(xi_t) beats fixed exponents K = 0.5, 0.9 and 1.0 on five math benchmarks; the average Pass@1 is 37.28 for the dynamic version, against 34.66, 27.40 and 23.67 tab. 12 app. C.7.
Inference-time entropy §5.5 fig. 4. On AIME24 with Qwen2.5-Math-7B, the paper reports OverTone with the highest inference entropy, DFT with the largest collapse, and RankTuner closest to the original model. These are the paper's qualitative readings of its figure.
Paper vs code
Official repository: LvAoAo/Ranktuner_VERL, linked from the abstract. The owner
name is not one of the paper's authors. The card uses it on the basis of that
link. The clone is at commit 111c55de1ed5cc9a3bedee74f383eddc2a651ffe. It contains a
vendored copy of verl (Apache-2.0) and math_evaluation/ (MIT); the root has no
LICENSE file.
The loss is in verl/verl/trainer/compute_loss.py, and the trainer selects it
when trainer.loss_type is ranktuner fsdp_general_trainer.py.
Matches the paper:
- Bounds on s(H_t): threshold of 2 bits, 0.25 * 2^H + 1 above it, and 1 + (1 - p_max) below it compute_loss.py eq. 5.
- xi = max(R, s(H)) and K = [log2(xi + 1)]^-2 compute_loss.py §4.5.
- Scale (p * s)^-K multiplied by p_t compute_loss.py eq. 10.
- Learning rate 5e-5, batch 256, max length 2048 and one epoch in the example command README.md.
Differs from the paper:
- Training data size. The paper uses the first 10k NuminaMath-CoT examples §5.1. The README's data step passes
--train_end 100000README.md, and the default of 0 means no limit numina_cot.py. The evaluated checkpoint isglobal_step_390README.md. At batch 256, 390 steps is about 99.8k sequences, so the example run is about 100k examples. The paper's 10k is not confirmed by this code. - Base weight is fixed to p_t.
compute_loss.pymultiplies every token bygt_probcompute_loss.py, with no option for w_t = 1. The paper uses w_t = 1 for code app. C.8. The repository has no switch for it, so this loss alone does not reproduce the code-generation setting. - The scale is a constant for the gradient. The scale is computed under
torch.no_grad()compute_loss.py compute_loss.py. Gradients flow only through the per-token cross-entropy. The paper does not state whether S_t is differentiated. - Normalisation. The paper writes the loss as 1/T times the sum over tokens alg. 1. The code computes a mean over valid tokens per micro-batch compute_loss.py and then divides by the number of micro-batches and multiplies by the data-parallel size fsdp_general_trainer.py fsdp_general_trainer.py. The
num_items_in_batchargument, which would give a global token mean, is commented out fsdp_general_trainer.py. Micro-batches with different token counts are weighted differently from the paper's formula. - Floors not in the paper. The product p_t * s(H_t) is floored at 1e-6 compute_loss.py. xi is floored at 1 compute_loss.py; this has no effect, because both R and s are at least 1. Inside the entropy log, 1.19e-7 (fp32 epsilon) is added to the log-probabilities compute_loss.py.
- Entropy base. The main text does not give a log base §2.2. The appendix uses bits app. B.1. The code computes entropy in nats and divides by ln 2 compute_loss.py, so it matches the appendix.
- Ties in rank. The code counts all tokens whose logit is at least the target's logit, so ties count against the target compute_loss.py. The paper does not say how ties are ranked.
- Name collision. The variable
expected_rankin the code holds s(H_t), the lower bound, not E[R_t] compute_loss.py. The code never computes E[R_t]. - Optimizer defaults. The paper does not state betas, weight decay or gradient clipping. The code defaults are betas (0.9, 0.95), weight decay 0.01 and clip 1.0 sft_trainer.yaml. These are defaults, not reported settings.
- Memory. The paper says memory equals SFT app. B.2. The code converts logits to float32 compute_loss.py and creates several tokens-by-vocabulary temporaries for the rank and entropy compute_loss.py compute_loss.py compute_loss.py. This is more than the paper's O(1) per-token extra.
- Baselines. The paper says its baselines are re-implementations in its unified weighted-NLL framework, not the original code. OverTone is approximated as a discrete reweighting app. C.2. Compare baseline numbers with that in mind.
No further discrepancies were found in the code paths for the Relative Scale.
Pitfalls
- Entropy must be in bits. Eq. 5 uses 2^H, so H has to be in log base 2 eq. 5 app. A.2. Section 2.2 gives no base, and the appendix and code use bits app. B.1 compute_loss.py.
- K(1) differs between analysis and implementation. The main analysis says K is about 0.5 for typical tokens §4.4 app. A.4. The implemented K = [log2(xi + 1)]^-2 is 1.0 at xi = 1 eq. 10 alg. 1. Anyone implementing the Cauchy-based K from Section 4.4 gets different weights from the paper's training code.
- The xi choice and the dropped factor. The paper compares alternative means for xi only app. C.6. Dropping the factor xi / (xi + 1) is stated as a choice for simplicity and stability §4.5; no ablation of it is reported.
- Numerical floors. The 1e-6 floor on p_t * s(H_t) and the eps in the entropy are not in the paper compute_loss.py compute_loss.py. For tokens with very small p_t, the floor sets the weight.
- Large weights for rare tokens. The scale (p s)^-K grows as p_t falls. The code caps it by flooring p_t * s at 1e-6 compute_loss.py. The paper states no cap §4.5.
- Normalisation across micro-batches. The paper's 1/T is not tied to a micro-batch. The code averages per micro-batch alg. 1 fsdp_general_trainer.py. The paper does not say how it normalised across micro-batches §5.1.
- The RL extension is not validated. The paper describes an illustrative form for PPO and GRPO token ratios but leaves it untested §4.5 app. B.7.
- Math-only evidence for the strongest claims. The OOD results are on two benchmarks with one backbone tab. 3 §5.3. Code results are mixed tab. 13.
- No variance reported. Runs, seeds and confidence intervals are not stated §5 app. C. AIME24 and AMC23 differences are a few problems.
- Training data size is unclear. The paper says 10k examples; the example command and checkpoint imply about 100k §5.1 README.md README.md. Confirm which one a reproduction used.
- Code-task weights. The paper's code results use w_t = 1 app. C.8. This repository's only loss uses p_t compute_loss.py. Set the base weight yourself when reproducing code results.
- Stop-gradient choice. The code detaches the scale compute_loss.py. Whether the paper intends this is not stated.
- Tie handling. Equal logits count against the target compute_loss.py. This affects R_t and therefore xi.
- Memory. Plan for several tokens-by-vocabulary float32 temporaries in the reference implementation compute_loss.py compute_loss.py.
Lineage
- Builds on: the guessing-problem view of expected number of guesses §2.3, and the rank-based discounting f in the Relative Rank Indicator, which the paper attributes to ranking metrics §4.1. The Cauchy mean value theorem step is standard analysis §4.4 app. A.3.
- Compared against: OverTone, DFT, TALR and EAFT, all reimplemented in the paper's framework app. C.2. EAFT is arXiv:2601.02151, as cited in the paper's reference list. Also Alpha Power and Entropy Regularisation loss shapes §5.4.
- Related RL methods: PPO and GRPO are named as the RL-style setting the paper does not validate §4.5.
- Superseded by: not stated in this card's sources.
Source and license
Adapted from “Probability-Entropy Calibration: An Elastic Indicator for Adaptive Fine-tuning” by Wenhao Yu, Shaohang Wei, Jiahong Liu, Yifan Li, Minda Hu, Aiwei Liu, Hao Zhang, Irwin King (arXiv:2602.01745), used under CC BY 4.0. Changes: condensed and restructured for implementation, with tables, equations and algorithms taken from the paper and its code, each cited to its source. Not affiliated with or endorsed by the authors. Code citations refer to https://github.com/LvAoAo/Ranktuner_VERL at commit 111c55de1ed5 (Apache-2.0 (verl/); MIT (math_evaluation/); no LICENSE at repo root). Any quoted code is shown under that license.