ProbeGen: Multi-Domain Probe Generation

Updated 11 July 2026

ProbeGen is a term for diverse methods that construct probes to expose latent properties in systems such as neural networks, executable programs, and text models.
Approaches include deep linear generators for weight space learning, whitebox LLM-in-the-loop methods for counterexample search, and robust canary probes for memorization auditing.
Each method uses targeted probe construction and optimization to reveal system behaviors while mitigating issues like overfitting and measurement artifacts.

Searching arXiv for the referenced ProbeGen papers and closely related entries. ProbeGen is a name used for several technically distinct methods on arXiv. In one line of work, it denotes Deep Linear Probe Generators for weight space learning, where a shared deep linear generator produces probes that are passed through trained neural networks to infer undocumented model properties such as training dataset or generalization error (Kahana et al., 2024). In another, it denotes a whitebox, LLM-in-the-loop method for finding counterexamples that disprove the functional equivalence of executable programs by iteratively generating probes with execution feedback (Allamanis et al., 5 Feb 2025). A third usage presents a practical blueprint for robust canary memorization probes in a text-dominant, LoRA-tuned autoregressive testbed, emphasizing full-span secret NLL, span-localised decomposition, behavioural exact-recall, and decoy probes (Fan et al., 30 Jun 2026). The shared motif is probe generation, but the objects being probed, the optimization loops, and the epistemic goals differ substantially.

1. Terminological scope and research domains

The term ProbeGen is therefore not a single standardized framework, but a reused label across at least three research settings. The following summary organizes the usages appearing in the cited arXiv records.

Usage of ProbeGen	Domain	Core objective
Deep Linear Probe Generators	Weight space learning	Predict undocumented properties of trained neural networks
ProbeGen	Program equivalence and code LLM evaluation	Find counterexamples that disprove functional equivalence
ProbeGen blueprint	Memorization auditing	Make canary memorization verdicts robust to probe choice

The first usage arises in weight space learning, where direct learning from raw parameters is difficult because the weight vector is extremely high dimensional and internal neuron permutations create symmetries that standard raw-weight architectures do not handle naturally. The second usage addresses code evaluation, where manually written unit tests are often inadequate and a single counterexample can be more informative than a broader but incomplete suite of expected outputs. The third usage concerns memorization auditing, where a fixed prefix-window mean-NLL probe can disagree with full-span secret NLL or greedy exact-recall, and therefore requires more robust probe design (Kahana et al., 2024).

A plausible implication is that ProbeGen functions as a family resemblance term rather than a unified formalism: each instance constructs probes to expose latent properties of a system, but the probe semantics differ across neural function space, executable program behavior, and autoregressive sequence likelihoods.

2. Deep Linear Probe Generators in weight space learning

In "Deep Linear Probe Generators for Weight Space Learning" (Kahana et al., 2024), ProbeGen is introduced as a modification to probing-based weight space learning. The starting problem is: given a population of trained neural networks $\{f_m\}$ , predict undocumented properties $t_m$ about each model without access to the model’s original training data and under minimal compute. The paper contrasts two approaches. Direct learning from weights is challenging because the weight vector is extremely high dimensional and because neuron permutation symmetries make functionally identical models appear different in raw parameter tensors. Probing instead represents a model by passing a set of learned inputs through the model and training a predictor on the resulting outputs.

The paper’s central claim is that vanilla probing may overfit because learning each probe independently by latent optimization makes probes highly expressive but unstructured; empirically, learned probes are surprisingly no better than random synthetic probes such as Dead Leaves images. ProbeGen addresses this by adding a shared generator $G_\theta$ that produces all probes from per-probe latent codes $\{z_i\}$ while constraining $G_\theta$ to be deep linear. For probe $i$ , the generated input is

$x_i = G_\theta(z_i),$

and the target model response is $y_i^m = f_m(x_i)$ . Responses over $k$ probes are aggregated into $F_m(G_\theta(Z))$ , and a predictor $t_m$ 0 infers $t_m$ 1.

The generator is a composition of $t_m$ 2 linear layers with optional biases and no nonlinear activations:

$t_m$ 3

For images, $t_m$ 4 is mapped through a stack of transposed convolutional operators to $t_m$ 5; for INR coordinates, $t_m$ 6 is mapped via fully connected layers to $t_m$ 7D coordinates $t_m$ 8 in $t_m$ 9. The training objective is

$G_\theta$ 0

with cross-entropy for dataset attribution and mean squared error for generalization-error regression. Probe codes $G_\theta$ 1, generator parameters $G_\theta$ 2, and predictor parameters $G_\theta$ 3 are optimized jointly by SGD or Adam, and no explicit orthogonality constraints are used.

A key theoretical motivation is invariance: for functionally identical networks produced by permuting internal neurons, $G_\theta$ 4 is unchanged for any input $G_\theta$ 5, so the probing representation is invariant to such permutations. The paper also attributes regularization to the deep linear factorization itself, arguing that stacking linear layers biases probe generation toward lower-complexity and more structured solutions, and that linear convolutional stacks impose locality and multiscale hierarchy that are useful for images.

3. Architecture, efficiency, and empirical results of the weight-space method

The implementation details of the weight-space ProbeGen are explicit. The generator is shared across all probes, with only the latent codes varying per probe. For images, the generator is a transposed-convolutional deep linear generator with no activations; spatial size doubles per layer, channels halve per layer, and a width multiplier of 16 is used. CIFAR10-GS uses 6 transposed convolution layers, and CIFAR10 Wild Park uses 5. For INR coordinates on MNIST and FMNIST INRs, the generator is a fully connected deep linear generator with 2 layers and hidden size 32. The learned latent codes satisfy $G_\theta$ 6. The predictor $G_\theta$ 7 is a 6-layer MLP with hidden size 256. Training uses Adam with learning rate $G_\theta$ 8, batch size 32 models per step, 30 epochs for most datasets, and 150 epochs for CIFAR10-GS; probe counts are $G_\theta$ 9 (Kahana et al., 2024).

The reported efficiency advantage is large. With 128 probes and batch size 64, Neural Graphs requires 63.40B FLOPs on MNIST INRs versus 0.02B for ProbeGen, and 94.56B versus 3.41B on CIFAR10-GS. The paper summarizes this as requiring 30–1000 times fewer FLOPs than graph-based state of the art. The cost model is dominated by $\{z_i\}$ 0 forward passes through the target models, whereas graph-based methods process the entire weight graph with attention or GNN layers.

The main quantitative results are averaged over 5 seeds. With 64 probes, ProbeGen reaches 0.980±0.001 accuracy on MNIST INRs, 0.861±0.004 on FMNIST INRs, 0.956±0.000 Kendall’s $\{z_i\}$ 1 on CIFAR10-GS, and 0.933±0.005 on CIFAR10 Wild Park. These values exceed the listed baselines StatNN, Neural Graphs, and vanilla probing on each of the corresponding tasks. With 128 probes, ProbeGen reaches 0.984±0.001 on MNIST INRs, 0.877±0.003 on FMNIST INRs, 0.957±0.001 on CIFAR10-GS, and 0.932±0.006 on CIFAR10 Wild Park.

The ablations are central to the method’s interpretation. Synthetic random probes perform comparably to vanilla learned probes, which is presented as evidence that vanilla probes overfit and lack structure. ProbeGen surpasses both learned and synthetic baselines. Increasing the number of probes generally improves performance, but ProbeGen often achieves the performance of vanilla probing with 4 times fewer probes. Adding nonlinear activations to the generator increases the generalization gap and reduces performance; removing the generator entirely is even more overfit. Convolutional linear generators consistently outperform fully connected linear stacks of comparable linearity and feature-map scale, suggesting that locality and hierarchy provide useful inductive bias. The paper further reports that ProbeGen probes are more object-centric and interpretable, with partial images revealing digits for INRs and CNN logits sharpening as model accuracy increases.

The stated limitations are also specific. Probing assumes that input and output axes have consistent semantics across models and therefore struggles when models have different class sets or class orders. It does not produce layer-wise or weight-level predictions and is not suited to weight generation or editing tasks. Training requires differentiable forward passes through target models, so larger models such as CLIP or Stable Diffusion still entail nontrivial compute. Performance depends on generator depth, width, and probe count, and overly expressive generators can increase overfitting.

4. ProbeGen as a whitebox method for disproving program equivalence

In "Disproving Program Equivalence with LLMs" (Allamanis et al., 5 Feb 2025), ProbeGen is a whitebox method for searching for counterexamples that disprove the functional equivalence of two or more executable program implementations. The motivation is that manually created unit-test benchmarks for code often miss corner cases, boundary conditions, and implementation-specific oddities. A program may pass all tests yet still be semantically wrong or fragile, and memorization-based or dictionary-lookup solutions may also pass limited tests without solving the intended task.

The formal framing is differential. For deterministic functions $\{z_i\}$ 2, equivalence is defined by

$\{z_i\}$ 3

A counterexample is an input $\{z_i\}$ 4 such that $\{z_i\}$ 5 under the paper’s equality semantics. More generally, for an interface $\{z_i\}$ 6, a probe is a function $\{z_i\}$ 7 such that if there exists $\{z_i\}$ 8 with $\{z_i\}$ 9, then the probe disproves equivalence of $G_\theta$ 0 and $G_\theta$ 1.

The method is explicitly whitebox because the LLM reads the source code of the implementations and receives execution feedback about prior probes. The workflow is iterative: given two or more runnable implementations of an interface, the LLM generates a probe conditioned on source code and probe history; the probe is executed on each implementation; the resulting outputs or exceptions are compared; if any pair diverges, a counterexample has been found; otherwise the outcome is added to the history and another probe is requested. The LLM is prompted to generate a Python generator create_fn_inputs() that yields dicts with "args" and "kwargs" matching the function signature.

The comparison semantics are carefully specified. Floats are equal if math.isclose holds by default parameters, with NaN \equiv NaN. NumPy arrays and Pandas frames use library-provided equality functions. Iterables are compared element-wise up to the first 1,000 elements. Any exception is considered equivalent to any other exception, independent of type and message. Side effects and non-functional properties are ignored, and nondeterminism is assumed absent. Input type constraints are enforced through typeguard, while implicit preconditions are not machine-checked and can later be treated as spurious by the filter.

ProbeGen can also be run as a tree search. The paper defines a generalized success probability $G_\theta$ 2 for node $G_\theta$ 3 under strategy $G_\theta$ 4, recursively applying the intuition of pass@k over combinations of child nodes. Search strategies include Full, Top, Decreasing, Increasing, Halving, and Doubling. The main evaluation uses the Decreasing strategy with $G_\theta$ 5 and depth $G_\theta$ 6, corresponding to at most 21 LLM calls per sample. The paper reports that depth, meaning multi-turn feedback, helps more than widening, but that some widening avoids getting stuck; the Decreasing strategy is described as Pareto-competitive and achieves about 90% success with about 4 times less cost than Full in the search-strategy study.

5. Semantic clustering, evaluation, and limitations in the code-equivalence setting

The program-equivalence ProbeGen is not limited to pairwise disproving. It also defines a semantic clustering procedure for self-consistency over multiple candidate implementations (Allamanis et al., 5 Feb 2025). For each implementation $G_\theta$ 7, the method records a probe outcome signature

$G_\theta$ 8

Two implementations are assigned to different clusters if there exists at least one probe on which their outcomes differ. The clustering algorithm repeatedly selects a pair from the largest current cluster, generates a pairwise probe, applies it to all implementations, and refines clusters by grouping equal outcomes.

This clustering underpins semantic self-consistency. Rather than choosing among multiple code candidates by syntax or unit-test outcomes alone, the method selects one from the largest semantic cluster, with ties broken by averaging pass rates across tied clusters. On LBPP, this improves pass@1 by about 10% relative, from 40.6 to 44.6, when spurious filtering is used. Without filtering, the improvement disappears and pass@1 remains at 40.6, which the paper uses to emphasize the importance of distinguishing meaningful divergences from irrelevant ones.

The evaluation is conducted on the LBPP Python code synthesis benchmark, with about 10k generated samples from various models to increase behavioral diversity. ProbeGen finds that 24.3% of unit-test-passing samples are semantically different from ground truth before filtering. After accounting for filter precision of about 77.1% compared to human judgments, with inter-annotator agreement $G_\theta$ 9, the paper estimates that about 18.7% of unit-test-passing samples are genuinely inequivalent. Unit tests and ProbeGen agree on about 83.3% of outcomes. Unit tests still catch about 12.5% of samples where ProbeGen does not find a counterexample within budget, which is presented as expected under a limited search budget.

The method is compared with property-based testing using Hypothesis for differential testing under a 3 CPU-minute budget per target. The paper states that property-based testing produces many spurious counterexamples when preconditions are weak, illustrating the difficulty of random generation for structured domains and ambiguous specifications. ProbeGen is therefore positioned as guided differential testing rather than as a replacement for formal equivalence checking or for exhaustive specifications.

Several limitations are explicit. ProbeGen may fail on infeasible input domains with undocumented constraints, on decorators or class-only tasks that the function-input harness cannot handle, and on stateful or nondeterministic code. Side effects and environment dependencies are not fully captured. Exceptions are normalized and may therefore hide meaningful distinctions. The LLM-based filter is fallible. The method is sensitive to prompting, and tree search mitigates but does not remove that sensitivity. The paper also notes a guardrail issue: an LLM attempted to disable typeguard, motivating sandboxing and strict runtime policies.

6. ProbeGen as a blueprint for robust canary memorization probes

The third usage appears in "Probe Choice Changes Canary-Memorization Verdicts: Three Post-Hoc Disagreement Case Studies in a Text-Dominant LoRA-Tuned Autoregressive Testbed" (Fan et al., 30 Jun 2026). Here ProbeGen refers to a practical blueprint for robust canary memorization probes in a controlled canary testbed built on Qwen2.5-VL-7B-Instruct with a frozen vision tower. Canary injection uses LoRA on the language tower over modules $i$ 0 with $i$ 1 and $i$ 2, followed by a second benign SFT LoRA with $i$ 3 and $i$ 4 trained with AdamW, peak learning rate $i$ 5, cosine schedule, batch 2 with gradient accumulation 4, maximum sequence length 1024, and 5000 examples per cell-specific step grid.

The paper’s central claim is methodological rather than algorithmic: a fixed prefix-window mean-NLL memorization probe with $i$ 6 can disagree with full-span secret NLL or greedy exact-recall, and therefore can yield false negatives, false positives, or ambiguous verdicts. The canary layout is deterministic. For text canaries, preamble tokens occupy positions 0–9, canary_lit is token 10, the secret canary_hex occupies tokens 11–23, and canary_end is token 24. The canonical fixed window $i$ 7 therefore covers all preamble tokens, the literal marker, and only the first 9 of the 13 hex tokens, omitting the last 4 hex tokens and the suffix.

The paper defines per-token teacher-forced loss $i$ 8 and token-wise delta

$i$ 9

The fixed prefix-window mean-NLL probe is

$x_i = G_\theta(z_i),$ 0

while the full secret-span mean is

$x_i = G_\theta(z_i),$ 1

It also defines greedy exact-recall and sequence-level hit@k, where hit@k estimates the fraction of cases in which the exact secret is recovered among $x_i = G_\theta(z_i),$ 2 outputs.

Three post-hoc disagreement case studies motivate the blueprint. In C3, described as a false negative via window truncation on text canaries under T-bSFT-GUI 5k, $x_i = G_\theta(z_i),$ 3 is flat, but $x_i = G_\theta(z_i),$ 4 is positive across all 3 seeds, and hit@1 drops to 0.88 from baseline 1.00. The per-token profile is flat through positions 0–22, while token 23 spikes to about 0.119, and that token lies outside $x_i = G_\theta(z_i),$ 5. In C4, described as a false positive via non-secret drift under T-bSFT-Safety 5k, $x_i = G_\theta(z_i),$ 6, but about 99% of this mass lies on the preamble; $x_i = G_\theta(z_i),$ 7 and hit@1 remains 1.00. In C5, described as an ambiguous undertrained in-window drop under U-bSFT-GUI 3k on undertrained image canaries, $x_i = G_\theta(z_i),$ 8, the full-span $x_i = G_\theta(z_i),$ 9, and hit@1 remains 0. The paper interprets these as window truncation, non-secret drift, and undertraining confound, respectively.

From these cases, the paper recommends four reporting components before asserting secret-specific memorization: full-span secret NLL and mean; span-localised decomposition across preamble, literal marker, secret, and postamble; behavioural hit@k at $y_i^m = f_m(x_i)$ 0; and decoy probes such as shuffled_hex, wrong_secret, and format_only. It proposes decision rules including a secret-specificity gate, a behavior gate, a preamble drift veto, and undertrained-regime caution. The overarching recommendation is to prefer direct full-span secret evaluations over fixed-window proxies when feasible and to calibrate thresholds such as $y_i^m = f_m(x_i)$ 1, $y_i^m = f_m(x_i)$ 2, $y_i^m = f_m(x_i)$ 3, and $y_i^m = f_m(x_i)$ 4 per backbone and training regimen.

7. Comparative interpretation

Across these three literatures, ProbeGen consistently denotes probe construction as a route to latent property inference, but the form of the latent property changes. In weight space learning, probes are synthetic inputs that elicit functional fingerprints of trained models, and the principal technical issue is regularized probe generation under permutation invariance (Kahana et al., 2024). In program equivalence, probes are executable inputs or call snippets synthesized by a whitebox LLM, and the goal is to expose differential behavior more effectively than manually written tests (Allamanis et al., 5 Feb 2025). In canary memorization auditing, probes are likelihood- and behavior-based measurements over carefully aligned token spans, and the principal concern is avoiding misinterpretation caused by truncation, dilution, and non-secret drift (Fan et al., 30 Jun 2026).

The common theme is that probe design itself determines what can be observed. In the weight-space setting, current probe learning strategies are described as ineffective because unconstrained probe optimization overfits. In the code setting, naive testing misses structured corner cases that source-code-aware probe generation can surface. In the memorization setting, a fixed prefix window can materially change the verdict relative to full-secret and behavioral probes. This suggests a broader methodological lesson: probe generation is not merely an instrumentation detail but part of the substantive hypothesis class of the evaluation.

A plausible implication is that the three ProbeGen usages collectively illustrate a general research pattern in which careful probe parameterization, alignment, and filtering are required to distinguish genuine system properties from artifacts of the measurement process.