2 linked studies on whether the safety layer around an LLM actually works. Part A builds a runtime monitor for generated code. Part B attacks the judges that grade LLM answers.
This is my graduate research at DePaul, led with 2 faculty co-authors and now under review. Both parts poke at the same assumption: that wrapping an LLM in checks makes it safer. Part A wraps a code-writing model in a critic and a fixer, runs everything locally through Ollama, and measures on real benchmarks whether the monitoring helped. Part B trains the other kind of check, preference judges of the sort LLM-as-a-judge pipelines rely on, then hits them with adversarial pairs to see which one breaks first. Both parts found the check itself failing in ways the clean metrics never showed.
A 3-agent runtime monitor for LLM code: a Critic scores each output for hallucination risk, a Fixer rewrites the risky ones, and a reversion gate keeps a rewrite only if it strictly improves. Measured by pass@1 on HumanEval, HumanEval+ and MBPP across 6 open models, with every run tracked in MLflow. The stronger the base model, the more the critic-fixer loop costs it.
Change in pass@1 from adding the monitor, on code that parses cleanly.
Read it top to bottom. On the left are the models and data, all served locally through Ollama with no retraining. The centre spine is the monitoring pipeline in run order: Planner, hybrid Pre-Critic, the Fixer behind a threshold, a reversion gate, Post-Critic and the test. The right shows what each run writes to disk, ending in the headline result. A baseline with no monitoring runs alongside for a clean before-and-after.
Monitoring is not a free win. The two mid-capability models moved by less than 2 points, neither distinguishable from zero. The real damage shows up when the critic false-alarms on a strong model and the fixer rewrites code that was already correct.
The reversion gate throws away 73.4% of the Fixer's rewrites, keeping only strict improvements. The ablation shows problem context and fixer scale drive the gains; the gate mostly protects the downside.
A static AST pass catches syntax errors and undefined names first and sets a floor. The LLM critic can only push the risk score higher, never talk a real defect down to clean.
The old extractor only matched python-tagged fences, so ~54% of Code Llama's valid code was scored as failure. The corrected table keeps the models with clean re-runs and retires the rest.
It reverts 73.4% of the Fixer's rewrites, keeping only strict improvements.
When the critic wrongly flags code a strong model already got right, the fixer can gut it: one slice fell from 92.9% to 50.0%.
The judges here are the checks most LLM pipelines trust: models that pick the better of 2 answers. I trained 3 of them on Anthropic's HH-RLHF human preference data, a logistic regression, an XGBoost, and a fine-tuned DeBERTa transformer in PyTorch, then applied each one zero-shot to LLM-Bar's 419 adversarial pairs to find which judge breaks first.
Paste 2 answers, or load the sample. 2 trained models pick the better one. Watch a padded answer win.
A live map of the build.
Left: the datasets and pretrained models that feed in. Centre: the pipeline in run order. Right: what each stage writes to disk. The amber path is LLM-Bar. It stays out of training and enters only at the stress-test, so nothing a model saw prepared it for that path.
DeBERTa led the clean benchmark at 0.622 AUC and lost the most under attack, 19.3pp.
The most verbose archetype had the lowest human pick rate, 48.9%, below the 50.1% of the shortest.
All 3 models fell below 50% on adversarial pairs. On a forced choice that is systematic inversion.