PANOPTES
panoptes-e86ef9e3

calib·HumanEval/24

humaneval-calibprobe · code

This is one (task, candidate response) pair flowing through the full PANOPTES pipeline. Each section below is a stage of the analysis: the task itself, the candidate solution being evaluated, every judge's score + rationale, the sampling-pass dispersion that captures within-judge noise, and the uncertainty-quantification metrics computed on top.

mean score
0.800
inter-judge spread
0.000
judges polled
2
sampling draws
20
1. the task

The function signature + docstring presented to both the model under test and to every judge. The entry-point name was obfuscated from largest_divisor to fn_5759fc1500 so the judges can't pattern-match a memorized HumanEval solution.



def fn_5759fc1500(n: int) -> int:
    """ For a given number n, find the largest number that divides n evenly, smaller than n
    >>> fn_5759fc1500(15)
    5
    """
2. the candidate response judged

The full solution every judge is grading. For these runs the candidate is the reference solution prepended with the task signature so it parses as a complete program.



def fn_5759fc1500(n: int) -> int:
    """ For a given number n, find the largest number that divides n evenly, smaller than n
    >>> fn_5759fc1500(15)
    5
    """
    for i in reversed(range(n)):
        if n % i == 0:
            return i
3a. point-pass scores (temperature 0)

One call per judge at temperature=0. This is the "best single guess" each judge has. Disagreement here is structural. The judges literally see this candidate differently.

claude-sonnet
0.800
$0.0088
gpt-4o
0.800
$0.0036
3b. sampling-pass dispersion (temperature 1)

n draws per judge at temperature=1. Dots are individual draws; vertical bar is the mean; shaded band is ±1σ. Wide band = the judge is uncertain even with itself; narrow band = it's consistent.

4. uncertainty quantification

Three statistical methods computed on top of the raw scores above. Each one tells you something different about how much to trust the headline number.

semantic-entropy
claude-sonnet
H = 0.325/ log 102.303
2 semantic clusters via bidirectional NLI
entropy as fraction of max
cluster sizes
c1=9 · c2=1
semantic-entropy
gpt-4o
H = 1.280/ log 102.303
4 semantic clusters via bidirectional NLI
entropy as fraction of max
cluster sizes
c1=2 · c2=4 · c3=3 · c4=1

How to read these: self-consistency = does the judge agree with itself when resampled? Narrower CI means more consistent. Semantic entropy = do the judge's rationales cluster into one meaning, or several? Higher entropy means the judge is internally conflicted about why. Decomposition = how much of the total variance comes from within-judge sampling noise (aleatoric, hard to fix) vs between-judge disagreement (epistemic, fixable by calling more judges).

5. judge rationales

The natural-language explanation each judge gave alongside its score. These are produced via tool-use structured output, so the score and the rationale are guaranteed to come from the same forward pass.

claude-sonnet
score 0.800 · 1826 tokens · 5235ms

The solution correctly iterates from n-1 down to 1 (via `reversed(range(n))`) and returns the first divisor found, which is the largest divisor smaller than n. For n=15, it returns 5 (correct). For most positive integers > 1, this works correctly. However, there are edge cases: (1) n=1: `range(1)` is [0], and `1 % 0` raises a ZeroDivisionError. (2) n=0: `range(0)` is empty, function returns None. (3) n=prime (e.g., n=7): returns 1, which is correct. The ZeroDivisionError for n=1 is a real bug, though n=1 is a degenerate case (no divisor smaller than 1 exists, so behavior is arguably undefined). The solution is otherwise clean and idiomatic.

gpt-4o
score 0.800 · 941 tokens · 1069ms

The candidate solution correctly implements the task of finding the largest number that divides n evenly and is smaller than n. It uses a loop to iterate from n-1 down to 1, checking for divisibility. This approach is correct and will return the expected result for positive integers greater than 1. However, the solution does not handle edge cases such as n = 0 or n = 1, where the behavior is undefined or could lead to a division by zero error. Additionally, the solution could be more efficient by iterating only up to n//2, as no number greater than n//2 can be a divisor of n other than n itself. Despite these minor issues, the solution is mostly correct for typical inputs.