Check Which Evidence Supports an AI Answer

In one sentence

The study asks whether checking an answer against each source of evidence can help correct unsupported claims. Imagine asking what is visible in a picture while a bark is heard in accompanying audio. The bark should not, by itself, support a claim that a dog appears in the image. This is a hypothetical illustration, not a reported test case. The authors’ method, OmniConfess, first saves the AI model’s answer. It then removes one evidence channel, such as the audio, and checks how strongly the model still favors each small piece of that same answer. Keeping the answer fixed makes the comparisons about the evidence rather than about a newly worded answer. The method uses those comparisons to adjust a short judgment or select parts of a longer answer for revision. It requires no additional model training.

Key concepts

• Evidence channels: The question may come with separate sources, such as text, an image and audio. Which source is relevant depends on what the question asks.
• Frozen candidate: OmniConfess keeps the first answer unchanged while checking it under different evidence conditions. Otherwise, changes in wording could blur the comparison.
• Token-level rescoring: The method checks small pieces of the saved answer, called tokens, to see how removing one channel changes the model’s preference for them.
• Confession-guided correction: Those changes form a record of the answer’s dependence on each channel. The method uses it to adjust a judgment or choose passages of a longer answer to rewrite.

A concrete example

Hypothetical example: A reviewer asks an AI system, “What is visible in this image?” The image does not establish that a dog is present, but its accompanying audio contains a bark. If the answer says a dog is visible, the reviewer should not treat the bark alone as visual evidence. OmniConfess is designed to check whether that part of the answer depends on the irrelevant audio channel; this example is not a measured result.

What the researchers measured

The authors built OmniHalluBench from 3,540 selected examples in six existing datasets. On the image-grounded PHD judgment task using Qwen2.5-Omni-7B, they report an F1 score of 89.60 for OmniConfess and 71.68 for the unmodified base model. F1 combines how often a “Yes” prediction is right with how often the model finds cases whose answer is “Yes”; it is a benchmark score, not a count of correct answers. The authors report that OmniConfess outperformed the compared methods across all six datasets and reported metrics on this default model. Results for other model backbones are reported separately and should not be assumed identical.

Why it matters

An answer can sound plausible while drawing on a source that does not answer the question. The authors’ approach makes that dependence part of the correction process, rather than checking only the finished wording.

Where it might help

The authors study evidence-grounded judgments and longer answers across text, image, audio and video tasks. A possible use is reviewing which source appears to support a particular claim before deciding whether to keep it. Evidence dependence does not itself prove that the claim is correct.

Impact across sectors

• Possible use, not a tested deployment: A media team reviewing audio-visual descriptions could separate what a clip shows from what its soundtrack suggests.
• Possible use, not a tested deployment: A biomedical literature team could examine whether an answer about an abstract relies on the supplied text rather than an unsupported assumption.
• Possible use, not a tested deployment: A document-answering team could inspect claims against retrieved passages before sharing an answer.

Where the evidence stops

The authors say that reliance on the relevant evidence does not guarantee a correct interpretation: a model can observe an image accurately yet make an unsupported subjective judgment. Local revision can also leave an error in the candidate answer’s interpretation intact. They show that a single-reference wording score can penalize a valid paraphrase, and report that checking separate evidence channels adds inference time on some tasks. The benchmark draws from existing datasets and retains examples selected for difficulty; the described human check covers candidates near the selection cutoff, not the entire benchmark. Its free-form factual-accuracy score uses a model judge and the authors’ reference-based prompt. General PtoP note: this source is an arXiv preprint, and benchmark findings are not evidence of a workplace deployment.

In one sentence

The study asks whether someone who controls part of an AI service can steer its answer while the answer is still taking shape. The authors found that this was possible in their tested setting. Imagine a question that gives no evidence for choosing between two demographic groups: the sound answer is to say there is not enough information. The tested model starts with masked-out words and repeatedly fills them in before fixing an answer. An attacker who can alter the model’s temporary internal activity watches how likely it is to choose one group, then adjusts the alteration on the next pass. The authors call this closed-loop activation steering: ‘activation’ means temporary internal activity, and ‘closed-loop’ means each adjustment responds to a new reading. The model’s stored settings and the user’s question stay unchanged. The attacker needs access inside the service; an ordinary user sending questions does not have the access assumed here.

Key concepts

• A diffusion language model builds an answer through repeated passes over masked-out positions, rather than fixing each word as soon as it is first predicted.
• Targeted bias injection is the authors’ attack: it pushes an ambiguous answer toward an attacker-chosen demographic option when abstaining is correct.
• A feedback controller checks the changing likelihood of that option and adjusts the strength of the same internal nudge during answer generation.
• A target–comparator gap counts how often the model picks the chosen option minus how often it picks the other demographic option. A larger gap means a stronger tilt toward the chosen option, not better accuracy.
• An invalid-output rate counts responses that fail the authors’ strict rule requiring an answer letter at the start. Those responses remain in the reported totals.

A concrete example

Hypothetical illustration, not a result: A website helper is asked which of two applicants should get an interview, but is given no qualifications. It should say there is not enough information. In the paper’s threat setting, a compromised part of the service could instead nudge an unfinished answer toward one applicant’s demographic group.

What the researchers measured

In the authors’ Black-target, ambiguous BBQ multiple-choice test on LLaDA-8B-Instruct, their feedback intervention during answer generation—called decode-time proportional–integral steering—raised the target–comparator gap from 1.8 to 16.7 percentage points. The gap measures the difference between rates of choosing the attacker’s designated demographic option and the other demographic option. The intervention produced 7.8% invalid outputs under the authors’ strict answer-letter rule, versus 0% without steering. A constant-strength intervention using the same direction and injection sites reached a gap of 3.5 percentage points and produced 20.8% invalid outputs. That constant matched the feedback method’s average strength over the steps that fix tokens, not its total strength over the full run. In the authors’ separate SocialStigmaQA test on LLaDA-8B-Instruct, the feedback method raised selection of annotated stigmatizing answers from 17.6% to 58.1%; its strict-parser invalid-output rate was 17.4%. Results on other tested models were mixed: on Dream-7B the measured shift did not establish a lead over the comparison methods, while on LLaDA-MoE the tested constant-strength method had the larger gap.

Why it matters

The authors’ attack changes temporary activity during answer generation, leaving the stored model settings and the question untouched. Their finding suggests that checks limited to those two things could miss a change introduced by the running service. That is an implication of the tested attack, not evidence that a particular deployed service has been compromised.

Where it might help

A possible use of the findings is to include the running service—not only its stored model and question-handling code—when designing checks for biased answers. The paper tests an attack in controlled multiple-choice tasks, not an audit procedure deployed in an organization.

Impact across sectors

• Possible use in hiring: a team could check whether an AI screening helper abstains when a question lacks qualifications, rather than treating its answer as evidence about applicants.
• Possible use in education: staff considering a student-facing question helper could examine answers to underspecified questions in the running service. This was not tested in schools.
• Possible use in healthcare: teams considering a patient-information helper could ask how changes to the service might affect answers that lack enough information. This was not tested in healthcare.

Where the evidence stops

The authors chose controller settings using 100 items that were also in the 400-item primary evaluation pool; they also report results after removing those items. Several settings for other targets were selected using evaluation items. Their tasks ask for multiple-choice answers read from an answer-letter probability; free-form generation was not tested. In SocialStigmaQA, calibration and evaluation shared question templates, and answers also shifted on prompts without the tested race descriptions. The authors therefore describe that finding as transfer of answer control, not a mechanism specific to racial stigma. Answer order and the rule used to read outputs affect some measured results. Some other demographic-target runs had high invalid-output rates and were reported as failures. The authors’ mathematical account assumes a simplified response before the answer is fixed. Their reverse-direction test began with a near-zero gap and does not establish a way to correct substantial existing bias. Independent reproduction currently requires outputs and fitted directions stored outside the manuscript checkout. The source is an arXiv preprint dated 05 Oct 2026; as a general PtoP note, a preprint should not be taken to imply peer review.

In one sentence

The study asks whether an image can be certified as authentic relative to a known set of image generators—not whether its true origin can be read from its pixels. Imagine checking a suspect photograph by asking each available generator to make a copy from it. The authors use inversion, a process that searches for an input that would make a generator recreate the image. If any copy is faithful, their method abstains and returns that copy as evidence that synthetic origin is plausible. It issues a certificate only when every tested generator fails the reconstruction test. Each certificate is tied to the generators and thresholds used at the time.

Key concepts

• Inversion works backward through an image generator: given a picture, it seeks an input that would let that generator reproduce it.
• The A-index combines comparisons of fine details, layout, visual appearance and depicted content between the image and its reconstruction. A faithful reconstruction receives a low score.
• Calibration sets a separate decision threshold for each generator using generated examples. The authors also set a stricter security threshold using examples altered by a specified attack.
• Abstention means the method withholds an authenticity certificate. It does not declare that the image is fake.
• A certificate is relative to the tested generators. A new or inaccessible generator can change what the method is able to certify.

A concrete example

Hypothetical illustration: an editor checks a disputed street photo. If one tested generator makes a close reconstruction, the tool returns that reconstruction and withholds a certificate. If none does, it may issue a certificate relative to that particular generator set. Neither outcome, by itself, establishes who took the photo.

What the researchers measured

In the authors’ image evaluation, the method was calibrated to limit false certificates—generated images certified as authentic—to 1% for the five tested configurations: SD2.1, SD3 Medium, SD3.5 Medium, FLUX.1 Dev, and FLUX.1 Dev with the Realism LoRA adapter. At that operating point, the authors report that most comparison detectors certified almost no authentic images. In a separate study of 3,000 unverified Reddit images, 1,116 exceeded the SD2.1 threshold, while 55 to 79 exceeded thresholds for the four newer configurations. Crucially, those Reddit counts came from applying different thresholds to the same SD3 Medium reconstruction scores; they do not compare reconstructions made by each named generator.

Why it matters

The authors distinguish a question their method can test—whether specified generators faithfully reconstruct an image—from the harder question of where that image actually came from. That distinction lets the method withhold an answer when reconstruction makes an authenticity claim uncertain.

Where it might help

A possible use is a slower, human-reviewed check of a flagged image, rather than automatic screening of an entire feed. This is an application suggested by the authors’ setting, not a deployment demonstrated by the study.

Impact across sectors

• Hypothetical newsroom use: an image-verification desk could review a reconstruction before deciding what further reporting is needed.
• Hypothetical platform use: a moderation team could reserve this computationally costly check for flagged images and treat abstention as a reason to investigate, not as a fake label.
• Hypothetical legal use: an evidence reviewer could record the generator set and calibration date alongside a check, without treating its certificate as proof that a camera captured the image.

Where the evidence stops

The authors say a certificate is not proof of origin: private or otherwise untested generators remain outside its scope. The attack-calibrated threshold covers the bounded attacks evaluated, not arbitrary edits, larger searches or stronger optimization. Thresholds have sampling error and need recalibration as generators or covered attacks change. The method takes 11.67 seconds per image per generator on the hardware the authors used. The Reddit collection is keyword-driven and does not represent internet images generally. Their preliminary video study covers only the visual content of 100 videos, averages sampled frames, and has no calibrated video-specific threshold; it does not establish a direct numerical improvement over the video detectors. Caption errors can also affect reconstruction scores. The authors caution that output warrants human review and should not be the sole basis for consequential decisions. General PtoP note: this arXiv source is a preprint, not evidence of peer review.

In one sentence

The authors ask whether a written description of a recurring text task can become a function that runs locally without calling a large teacher model each time. Their answer is to use the description to generate practice examples, train a small task-specific addition to a shared language model, and package the result for reuse. Imagine an inbox rule that sends an urgent signature request to an immediate pile but leaves a newsletter for later. Rather than writing rules for every possible phrasing, a developer describes the desired sorting; teacher models produce example messages and answers for training. The build happens through a hosted service, which receives the specification and uses teacher services. Later inputs can run through the packaged function locally without those teachers.

Key concepts

• A specification is a written description of what the function should do, such as how to sort incoming messages.
• Teacher models generate input-and-answer pairs from that description. These synthetic examples provide the training material, rather than serving as proof that every generated answer is right.
• An adapter is a small set of adjustable model settings. Training changes the adapter for one task while the shared interpreter—the language model that processes inputs—stays fixed.
• Compilation is the build step that creates the reusable function. In this system it takes longer than the earlier fast compiler, but the resulting function does not need teacher calls for each new input.
• Semantic correctness asks whether an output follows the written task, not whether its wording or formatting exactly matches one reference answer.

A concrete example

Hypothetical illustration: a team specifies that messages requesting a signature today should be marked urgent and newsletters should be marked for later. After compiling that instruction, the team could give the local function a newly worded message and inspect its category. This example is not a reported test of inbox use.

What the researchers measured

On FuzzyBench-Hard, the authors report a mean semantic-correctness score of 0.836 for compile by training, versus 0.224 for the earlier PAW fast compiler. The score is the fraction of outputs a language-model judge deemed correct under the task specification, even when formatting differed from a reference answer. FuzzyBench-Hard was selected because the fast compiler had produced no exact matches there; that does not mean it had no semantically correct answers. The authors report that the higher-scoring approach took roughly a minute to compile rather than seconds for the fast compiler. These are benchmark findings, separate from the application demonstrations.

Why it matters

For a narrow task that recurs often, the paper presents a different division of work: use large teacher models while building the function, then use a smaller shared model for later calls. The authors also show how separately compiled functions can be combined with ordinary code, while keeping exact operations such as retrieval and branch control outside those functions.

Where it might help

The authors demonstrate compiled functions in a multi-site website helper, a language-controlled character and a two-way writing-style translator. These are application demonstrations, not systematic user studies or evidence that the approach works in every setting.

Impact across sectors

• Possible use in education: a course team could explore a website helper for recurring student questions. The paper demonstrates a course-site helper, but does not report a systematic study of student outcomes.
• Possible use in website support: a site owner could explore combining compiled decisions with ordinary code that retrieves links and facts. The paper demonstrates such a combination; performance on a new site is not established.
• Possible use in creative tools: a developer could explore turning written motion requests into validated character actions, as in the authors’ avatar demo. That demo is not evidence of general reliability for other actions.

Where the evidence stops

The authors say teacher-generated examples may inherit teacher errors. They advise validating outputs or retaining deterministic control paths where correctness must be guaranteed. They also say their application evidence focuses on composition and structured execution, with systematic user studies left for future work. The benchmark is a subset selected using the fast compiler’s exact-match failures, and the paper’s separate supervision sweeps use development specifications; neither should be read as a result for all tasks or deployments. General PtoP note: this arXiv source is a preprint, not a claim of peer review.

In one sentence

The study asks whether a language model can benefit from learning to anticipate groups of text pieces as well as the next individual piece. The authors’ NCP-ArchPreview model does both. Imagine a sentence about booking a train ticket: one training path predicts its next small piece of text, while another works with an internal representation of several pieces together. That representation is learned by the model; it is not necessarily a phrase a person could read. The model feeds its group-level prediction back into the path that generates text. The authors trained an 8.9-billion-parameter version using Dolma-3 data and compared it with OLMo-3-7B across two training stages.

Key concepts

• Next-token prediction trains a model to predict the next token, or small piece of text, from what came before.
• Next Concept Prediction adds a training target for the next representation of a group of tokens. It is a training objective, not a claim that the model identifies human-defined concepts.
• A concept vocabulary is a learned collection of internal reference patterns. The authors build it from the model’s own intermediate representations.
• The Concept Module predicts a future group-level representation. The Token Decoder then uses that prediction alongside token-level information to predict text.
• Training loss measures how well the model predicts its training text. A lower loss need not mean a higher score on every separate task.

A concrete example

Hypothetical illustration, not a paper result: when continuing a travel itinerary, a model could use information about the preceding group of text pieces while still choosing its next token one piece at a time. This does not mean its learned group representation has a readable label such as ‘train booking.’

What the researchers measured

For Stage-1 training on Dolma 3 Mix, the authors report that NCP-ArchPreview reached OLMo-3-7B’s final training loss after using 51.3% of its training tokens. Under the reported downstream evaluation, NCP-ArchPreview’s overall macro-average—a summary of the listed task scores, excluding the separate likelihood results—was 49.04 versus 46.59 for OLMo-3-7B, a reported gain of 2.45 points. On GSM8K, a grade-school mathematics question set, the Stage-1 scores were 45.26 and 39.27, respectively; these scores are reported as percentages. For Stage-2 training on Dolma 3 Dolmino, the authors separately report a 0.59-point higher overall macro-average for NCP-ArchPreview than for the Stage-2 OLMo-3-7B model. The Stage-2 code-category average was lower for NCP-ArchPreview: 38.77 versus 39.42, a reported change of −0.65 points. The authors say Stage-2 contains approximately 10% code data. They also tested three Stage-2 NCP-ArchPreview configurations, V1–V3: progressively lower final training losses coincided with progressively worse downstream performance. In a separate early-training comparison over the first 200B tokens, the complete NCP-ArchPreview configuration reduced training loss relative to both the standard and approximately computation-aligned OLMo-3-based baselines. It approached the loss of a parameter-aligned baseline while using 85% of that baseline’s analytical training computation. This is an analytical computation comparison, not a measured reduction in running time or a Stage-2 task score.

Why it matters

The paper separates several trade-offs that a single training score can hide: tokens used to reach a loss level, analytical computation, scores on downstream tasks, and the number of weights changed during adaptation. Those measures answer different practical questions.

Where it might help

The reported comparisons could inform experiments on how to train a language model, adapt its learned representations to a new subject, or test a draft-and-check text-generation method. They do not establish performance in a deployed service.

Impact across sectors

• Possible, not demonstrated in deployment: a language-model development team could compare group-level and token-level training when planning a new model.
• Possible, not demonstrated in deployment: a team adapting a model to programming or mathematics material could investigate the paper’s limited-weight adaptation approach while checking performance on other tasks.
• Possible, not demonstrated in deployment: an inference team could investigate whether group-level information helps its own draft-and-check generation setup.

Where the evidence stops

The authors state that long-context training is not included in this architecture preview. They also report that the link between lower training loss and downstream scores depends on the training stage and task; the Stage-2 configuration comparison makes that caveat concrete. The smaller Stage-2 overall gain and lower code-category score should not be folded into the Stage-1 finding. In the reported code-adaptation experiment, the limited-weight method improved the code average but reduced the general-task average. General PtoP note: this arXiv technical report is a preprint, and benchmark results are not evidence of a tested deployment.

In one sentence

The study asks whether records from an assistant’s everyday tasks can help decide what it learns next. The authors built NeoHorse-1 by further training two language models on records of requests, tool calls and outcomes. An execution harness—the software that gives an assistant its tools and manages its task—also estimated how much model capability each request might need. The authors used those estimates to order training examples, then described using evaluation feedback to choose the next mix of examples. They present this as an initial step toward recursive self-improvement, meaning repeated improvement informed by the system’s own experience, not as proof that improvement continues over repeated cycles.

Key concepts

• Execution records: The authors kept each request with the assistant’s actions, tool responses and outcome, rather than treating the final reply as the whole task.
• Routing signal: The harness estimated a request’s capability demand. The authors used that estimate to order training examples, not the identity of the model that happened to handle the request.
• Curriculum: Recorded examples were presented in stages that introduced higher-demand tasks while retaining some lower-demand tasks later.
• On-policy distillation: A student model generated responses from recorded starting points, and a fixed teacher model supplied feedback on the student’s own generated text.
• Feedback loop: The authors describe using evaluations to shift later training toward weaker areas. Whether gains accumulate over successive loops remains untested.

A concrete example

Hypothetical illustration, not a paper result: A service assistant checks a ticket, consults a tool, then discovers that the ticket was updated. A useful record would keep the request, tool response, revision and final outcome together. A trainer could review that record and decide whether similar tasks deserve more attention.

What the researchers measured

In the authors’ ten-benchmark, text-only evaluation, NeoHorse-1-4B’s macro-average score was 64.87, compared with 58.94 for its Qwen3.5-4B base model. This score is an unweighted average of benchmark scores across agent tasks, tool use, coding and instruction following; it is not a workplace success rate. The authors also report an increase for NeoHorse-1-9B over its own Qwen3.5-9B base model. These findings concern the named NeoHorse-1 models, not the separate NeoHorse-Jev model described in the repository.

Why it matters

For someone managing an assistant, the distinction is between collecting task logs and using them to choose learning material. The authors connect those activities in a proposed evaluation–selection–update loop, while measuring the resulting models on a defined set of tests.

Where it might help

A possible use is to organize recorded assistant tasks for later training or review. The paper evaluates models on text-based tasks; it does not test an organizational rollout of this process.

Impact across sectors

• Possibility, not a tested deployment: A software team could review coding-assistant records for missed test and repair steps.
• Possibility, not a tested deployment: A customer-service team could group tool-using assistant tasks by estimated demand and recorded outcome.
• Possibility, not a tested deployment: An internal operations team could use task records to identify where an assistant needs further training examples.

Where the evidence stops

The authors call this an initial prototype and say the results reflect a single pass of the evaluation–selection–update loop. They have not tested whether gains accumulate over successive iterations or evaluated the broader range of capabilities served by the harness. Their comparisons cover text interfaces, even for models that support other kinds of input. They report screening training candidates against evaluation items to remove overlaps. Some benchmark results were drawn from other models’ official reports rather than measured in the authors’ pipeline; PinchBench and VitaBench were each run once. General PtoP note: this source is an arXiv preprint, not a claim of peer review or deployment performance.