← trajectories

Can a decoding method that measures novelty in a …

Title truncated in the source doc — replace with the full research question.

Pairwise preference

rlhf-pairwise.json

Two candidate continuations from one state, with an ordering.

1/10

File metadata

_format:option-b-pairwise-preference
_note:DPO / reward-model shaped. Each pair is a REAL preference event, not a synthesized one: `rejected` is the proposal the agent actually emitted, `chosen` is the proposal it actually emitted after the researcher's critique, and `critique` is the researcher's verb…
pair_id
p01-derisk-before-build
synthetic_rejected
false
prompt
Propose the first GPU experiment.
principle
De-risk the single load-bearing assumption before building the method that depends on it — and make the de-risking artifact human-inspectable, not a summary statistic.
margin
strong

context

Opening turn of the project. The researcher wants to know whether hidden-representation novelty can improve Pass@k. Literature check found no prior work using residual-stream novelty as the diversity signal. The researcher has specified: fork when the model reaches a new thinking point; R1-Distill-Qwen-1.5B on math; scope is just 'compare normal pass@k with this new method'. No experiments have run yet.

rejected

action:propose_tier1
title:Idea-Novelty Decoding vs. standard Pass@k (R1-Distill-1.5B, math)
gpu_type:H100
summary:Full method in one run. (1) Idea-boundary detection: windowed mean of the last-layer hidden state at layer L; declare a boundary when cosine drift crosses a threshold. (2) Novelty-steered forking: keep an idea memory bank of hidden signatures; at each boundary…

chosen

action:propose_tier1
title:Validate hidden-state idea-boundary detection (R1-Distill-1.5B)
gpu_type:A100-80GB
summary:Test only the assumption the method rests on: when the residual-stream representation shifts, has the model actually moved to a new idea? Generate traces saving residual-stream states, compute the windowed cosine-drift change-point signal. Primary deliverable…

critique

can we actually first test if this is a reasonable way to detect idea boundaries? maybe if we can see a side by side of the tokens outputted and whether there is an idea happening right now. lets do the forking after we derisk the first idea boundaries

downstream_evidence

The de-risking run returned F1=0.474 (P=0.37) — a real but noisy signal. Had the full method run first, a null Pass@k result would have been uninterpretable: broken detector, or good detector and bad forking?