This is a two week sprint project done as part of the Redwood Research internship. Hasan was the main IC and proposed the project, Caspar supervised.

TL;DR

We made two conceptual reasoning evals from internal data within Redwood Research: commenting on Google Docs, and replying to Slack threads. Models see a real Google Doc or part of a Slack thread and write 20 short comments in response (50-70 words). These are graded against target human-written points, extracted from the comments on the doc and from the remainder of the Slack thread respectively. The benchmark contains ~360 tasks with ~1200 target points to match.

We find that generally more capable models perform better on our benchmark. RedwoodBench has 0.79 correlation with ECI (measured on 13 models). We find that Opus 5.5 improves on RedwoodBench with added reasoning effort (from 4.4% at low effort to 8.1% at max effort).

We are happy to share our pipeline with other AI safety orgs to build their own evals from similar data. 

Motivation

Improving models’ conceptual reasoning capabilities is one path to making transformative AI go well. See these posts for detailed discussion about this. Building benchmarks to measure these capabilities is highly leveraged: they let labs iterate training methods more effectively to improve models’ conceptual reasoning; the benchmarks can function as a leaderboard to incentivise progress (e.g. CRI); the benchmarks can be used to elicit models to improve their conceptual reasoning and could also reduce risks from models sandbagging on these tasks.

Earlier benchmarks, such as TASTE and LMCA, involve collecting human labels over model outputs. Building such benchmarks can be quite time-consuming, and off-distribution versus real usage. Existing conceptual reasoning data such as publicly available blog posts provides a potential source of ground truth, but it is often unclear how to turn the raw data into a measurable benchmark. A recent benchmark, CommentBench, measures models’ abilities to write high-quality comments to AI safety forum posts, using comments on those posts as a source of ground truth. As part of the CommentBench pipeline, the authors calibrate a LLM-judge to reliably measure when a model-written comment contains a human-written point. We modify this pipeline to turn Google Docs and Slack threads into conceptual reasoning evals, using human-written points as the source of ground truth.

Building Benchmarks from Internal Org Data

Figure 1: RedwoodBench-Comments and RedwoodBench-Slack task design

RedwoodBench consists of two main settings built from Google Docs and Slack threads shared within Redwood Research: RedwoodBench-Comments, and RedwoodBench-Slack. In RedwoodBench-Comments, models write comments in response to a Google Doc tab. In RedwoodBench-Slack, models write comments as replies to a Slack thread. The models are then graded on how many target points they mention from the actual human comments and replies in both cases. 

In each benchmark, the model writes 20 comments in response to its initial context, and is graded on how many target points exist within those comments.

Task Construction Pipeline

We construct tasks from the following pipeline:

1. Gather: We gather documents and threads from the last 1 year shared in Redwood’s Slack.
2. Filter sources: We keep only documents and threads that contain sufficiently conceptual discussion.
3. Extract points: We pull out the individual points researchers made in comments, replies or doc bodies.
4. Filter points: We keep points that count as conceptual progress and are attainable from the context the model will see.
5. Generate. The model writes 20 comments in response to its task. In RedwoodBench-Slack, we cut each thread at up to 3 points.
6. Score. The “matcher” (Opus 5.5) compares the model's comments against each target point.

Our pipeline does not filter comments based on correctness, though we believe the target points are generally strong. 

Scoring Task Outputs

For each task, we use an LLM-grader (the matcher) to compare each model-written comment against each of the target points. We also use a LLM-grader to count the number of distinct points that each model-written comment contains. We report two metrics:

• Recall: (number of distinct target points matched)/ (total number of target points for that document)
• Precision: (number of distinct target points matched)/ (total number of points made over the model’s comments)

We use the matcher prompt from CommentBench, with Opus 5.5, and validate it on each of our settings (RedwoodBench-Comments, and RedwoodBench-Slack). The matcher outputs a score between 0.00 and 1.00. We use a threshold of 0.80 to define a match, which corresponds to “most of the value of the human’s point exists in the model’s point” in the rubric. We find that this matcher transfers well to our settings (see appendix for validation stats).

For overall benchmark performance, we average recall performance in RedwoodBench-Comments, and RedwoodBench-Slack.  

Performance on RedwoodBench Tracks General Capabilities

Figure 2: RedwoodBench recall against Epoch Capabilities Index for 13 models. All models are measured at the maximum available reasoning effort. Error bars are 95% bootstrap CIs over documents and threads. (Pearson r=0.79)

We measure performance over 13 Anthropic and OpenAI models covering a range of capability. Models that perform better on Epoch’s Capabilities Index perform better on RedwoodBench (r=0.79). 

Earlier Comments Match Target Points More Often

Figure 3: Earlier comments have better precision. We elicit models to write 100 comments per task in RedwoodBench-Comments, using high reasoning effort. We bucket model-written comments based on their position in the output list, and grade each bucket on the percentage of comments within that bucket that match a target point. 

Figure 4: Recall against number of comments in RedwoodBench-Comments, when elicited to write 100 comments.

We see match rate slow down as models produce more comments, though a few models show continued progress at 100 comments. This might be driven by some non-obvious points from human comments. Over a diverse set of runs and elicitation experiments, 53% of RedwoodBench-Comments target points are matched by at least one run.

Stronger Models Can Identify Model-Written Comments That Match Target Points

Figure 5: RedwoodBench-Comments-Discrimination performance against ECI

We use the model-written comments generated by a wide range of models and prompts to create a comment discrimination eval (RedwoodBench-Comments-Discrimination, drawn from model outputs on RedwoodBench-Comments). The eval consists of 970 pairs of model-written comments. Each pair contains 1 comment that matched a target point and 1 comment that did not match a target point. Both comments in a pair come from the same model and prompt, at a nearby position in the list (out of 100). The discriminating model has to identify which comment matches a target point, seeing only the doc and pair of comments in context. We see performance on this eval correlate strongly with ECI (r=0.92). 

Elicitation

Figure 6: Opus 5.5 RedwoodBench recall (mean of RedwoodBench-comments and RedwoodBench-Slack), at high reasoning effort, for 8 prompt variants. The full prompt, with in-context examples, mentioning Redwood and mentioning human imitation scores best at 6.9%, though the CIs overlap.

We investigate how 3 contextual items impact performance on the benchmark:

1. Including in-context examples of good comments
2. Informing the model the doc/ thread is from Redwood Research
3. Informing the model it is graded on human imitation

Whilst these effects are not significant, we find that for Opus 5.5, which performs overall best on our benchmark, the combination of these items improves performance (as one might expect on priors).

Opus 5.5 and Sonnet 5.5 Perform Better With Added Reasoning Effort

Figure 7: Recall on RedwoodBench-Comments and RedwoodBench-Slack for varying reasoning efforts. Opus 5.5 and Sonnet 5.5 improve in performance with added reasoning effort in RedwoodBench-Comments. Opus 5.5 improves from 5.9% at low effort to 9.6% at max effort. Sonnet 5.5 improves from 2.9% at low effort to 8.4% at max effort, though does not improve from low-high effort. In RedwoodBench-Slack, Opus 5.5 improves from 2.9% to 6.7%. 

Qualitative Impressions of Model-Written Comments

When reading Opus 5.5’s comments that did not match target points, we saw they often failed by making obvious or tangential points, rather than clearly wrong points. It was often clearer to see comments’ weakness when assessing based on “would a human (from the distribution reading the doc) bring this up?” rather than “is the comment good?” Collecting human feedback data (scores, preferences, replies to comments) over model-written comments would be useful to make more concrete conclusions.

Discussion

We think other AI safety orgs can build similar evals from their own internal data with only a small amount of extra labour. Internal data is usually private, so these benchmarks would typically stay inside each org unless they choose to share them. Collectively, though, these evals could be used as a held-out benchmark for important conceptual reasoning capabilities.

If you'd like to access the pipeline, please submit this form (sharing with other AI safety orgs): https://forms.gle/8Rc8Mfyp8HLsELFb6 . 

Limitations

• Positives-only grading: we grade models on the number of human-written points they mention, and do not penalise for weak model-written comments. Collecting human feedback over model-written comments could help build higher quality rubrics for these tasks.
• Human imitation vs genuine strength: whilst we believe the comments are generally high-quality, and we filter out very simple comments, the benchmark does not directly grade “comment quality” and uses human imitation as a proxy.
• Limited elicitation effort: a more thorough and targeted attempt at elicitation could improve performance. 

Appendix

Matcher validation

We validated Opus 5.5 as a matcher in RedwoodBench-Comments and RedwoodBench-Slack. In each case, Hasan rated pairs of (model-written comment, target point) from 0.0 to 1.0 before seeing Opus 5.5’s score.

• RedwoodBench-Comments: over 20 samples, where the matcher rated the comment >=0.8 (i.e. a match), Hasan rated 16 of these comments >=0.7 (80%)
• RedwoodBench-Slack: over 24 samples, where the matcher rated the comment >=0.8 (i.e. a match), Hasan rated 21 of these comments >=0.7 (88%)

Point-counting validation

One might be concerned that models pack in multiple points into each comment. Hasan labelled the number of points per comment in a sample of 55 comments, we saw 22 comments that had 1 point, 26 that had 2 points and 7 that had 3 points. It was often unclear whether to classify a comment as 1 or 2 points. Nonetheless, Opus 5.5 with the first prompt we tried performed well here.

Using this prompt, from a sample of ~14k comments per model at high reasoning effort, we see some variation across models (1.2 to 2.0 points per comment on average). Generally, we see OpenAI models pack more points per comment than Anthropic models, with the GPT-5.6 series generally writing more points per comment than the GPT-6 series. This packing in points behaviour can be viewed as a form of reward hacking.

Task Filtering

We filtered docs and Slack threads based on three main reasons:

1. Not sufficiently conceptual (doc content or comments)
   1. For example, we excluded comments on empirical AI safety research drafts.
   2. We included drafts of empirical project proposals, though these are considered borderline on this filter
2. Drafts of blog post released online before the latest knowledge cutoff
   1. This was to reduce the effect of pre-training contamination.
3. Contains sensitive information

Hasan labelled 50 docs to keep/ filter. Our final filtering pipeline on RedwoodBench-Comments:

And 55 threads for RedwoodBench-Slack:

Self-preference Check

We check whether models prefer their own text. We run 6 models as matchers against each other's outputs to RedwoodBench-Comments. We subtract each model’s overall bias (mean(recall over all models as a matcher) - mean(opus 5.5’s as matchers recall over all models)) since a model could be too lenient to all models and we don’t want to measure this. We then assess whether that model as a matcher rates its own comments more highly than other matchers do. We find that models are not biased to prefer their own text in a way that impacts headline results.

Many-comments structure

The task structure of outputting many (20-100) short comments, and being graded against a range of human comments tackles many of the tricky aspects with grading free-form text. Compared to free-form output, it is much more controlled: there is a length constraint implied by n_comments x words_per_comment, and versus length-constrained, free-form output, the concern of models “packing in points” is less of an issue as models output 1-2 points per comment. With optimisation pressure applied, it would be unsurprising for them to pack points into each comment, though this could be constrained using the point-counting grader. 

The setup also tackles some of the key difficulties with conceptual reasoning evaluations. In particular, humans often disagree on a correct answer which makes finding agreement difficult (e.g. in TASTE) - this is less of an issue here since models are scored against comments from many researchers with differing opinions. Also, there are often many considerations that one could point out in response to conceptual position pieces. By giving the model enough output space to mention a large number of independent considerations, “failure to mention a point” is more clearly a failure of the model rather than of the task structure.