Case study · AI & LLMs · 3 min read

LLM Risk Register Benchmark

A reproducible benchmark that tests whether large language models can draft a project risk register from real planning documents.

Role: Co-author with Kruthik Jadhav · research code and data pipeline
Who: Co-authored with Kruthik Jadhav
Stack: Python, LLM evaluation, Prompt engineering, Reproducible research

Code on GitHub (opens in a new tab)

Pipeline from source documents to scored results. Only planning documents reach the models. The human register is held out.

456unit tests, all run offline
21real projects in the corpus
3 × 3models by prompting strategies
3ways of evaluating the output

Problem

This is the code and data behind a paper we're preparing for an IEEE conference: "Evaluating Large Language Models for Automated Risk Register Generation from Project Documentation: A Benchmark Study."

We compare three LLMs from different providers, each with three prompting strategies (zero-shot, few-shot and structured reasoning).

Risk registers are written by hand from long planning documents. It's slow work, and it's tempting to hand it to an LLM. But nobody has a clear answer to how complete those AI-drafted registers are, or which kinds of risk they tend to miss or make up.

To test that fairly you need real projects where both the planning documents and a human-written risk register are public. The corpus is 21 such projects: 18 World Bank Project Appraisal Documents and 3 UK government business cases in the Five Case Model format.

What I did

A Python pipeline that extracts text from the source PDFs, audits the corpus for leakage, runs the model and prompt grid, matches generated risks against the human register, and computes metrics and figures.
Three evaluation methods: semantic matching against the ground truth (recall, precision, coverage), expert Likert ratings with Fleiss' kappa, and an LLM-as-judge pass that is supplementary only.
A tooling layer around the expensive part: an environment check before any spend, a cost estimate that makes no API calls, batch submission for two of the providers, and a builder for blinded rater packets.

Decisions along the way

A strict no-leakage rule: Models only ever see the planning documents. The human register is ground truth and is kept out of the input. An audit script flags leakage with a FAIL/WARN/PASS result, and tests check that leakage-sensitive paths stay gitignored.
Tests where mistakes would quietly spoil the results: The 456 unit tests stub the embedding model, the PDF reader and all three model APIs, so the suite runs offline with no keys or spend. Coverage is concentrated where the project has actually had bugs, including a permanent regression test for a scoring bug where a boolean was being read as an integer.
A validated matching threshold: Semantic matching needs a cut-off for "same risk". Rather than picking one by eye, the threshold was chosen with a sweep against a hand-labelled set, and that sweep logic is tested too.
Guards on the run itself: Raw outputs are append-only, and the run driver has a cost guard that estimates spend before anything is sent, so the full grid stays within the project budget.

Stack

Language: Python 3.11+, pinned dependencies
Matching: Sentence-transformer embeddings
Models: Three LLMs via their providers' APIs
Analysis: Fleiss' kappa, matplotlib figures
Testing: unittest, 456 tests, fully offline

What I found

Most of the work in an evaluation is making sure you aren't fooling yourself. That means keeping the answers away from the model and checking it stays that way.
Cheap offline tests pay for themselves when every real run costs money.
Writing the methodology down and freezing it before running anything makes later decisions much easier to defend.

What I'd do next

Recruit the human raters for the expert-rating part of the study.
Run the batch code path against the live APIs, not only mocked responses.

Limitations

The corpus (21 of 21 projects) and the pipeline are complete and unit-tested. The run driver has been pre-flighted end to end with stubbed providers.
Results aren't shown here while the paper is being prepared for submission. The expert-rating part of the study needs recruited human raters.
The batch code path is tested against mocked provider responses only. It hasn't been run against a live API.