Projects

Open projects, published as I measure them

Three areas every team shipping LLMs runs into: evaluation, fine-tuning and serving, and reinforcement learning. Each project builds on work I’ve done in production and rebuilds it in public, with code and numbers anyone can reproduce. Open models run on a single 24 GB GPU.

Results are added as they are measured, with methods and confidence intervals, including where my approach loses. Each project becomes a full case study when it ships.

  1. 01

    Evaluating LLM applications before they ship

    How do you know an LLM system is ready for production? An open evaluation suite for retrieval, tool use, and safety that compares models and designs on quality, failures, latency, and cost.

    Builds onthe RAG and tool-using systems I’ve shipped, where access control, audit logging, and release evaluation were requirements.

    Approach

    • Three workloads on one fictional company: question answering over its documents (RAG), multi-step tasks using tools and a SQL database, and adversarial cases (prompt injection, out-of-scope requests, and other users’ data).
    • About 50 hand-written cases per workload, with reference answers, kept separate from anything used to tune prompts.
    • Two designs compared: rules written in the prompt, and checks enforced in code (retrieval filters, permission-checked tools, output validation).
    • Run across Claude, GPT, Gemini, and one open model served locally, 3 runs each.

    What gets measured

    • Answer correctness, and whether each answer is supported by the retrieved text
    • Tool-task success and policy violations, read from logs instead of judged by an LLM
    • How closely the LLM judge agrees with my own labels on a sample
    • p50 / p95 latency and cost per request
    • 95% confidence intervals on every score

    What gets published

    • Public repo that reproduces every number with one command
    • Results table and write-up
    • Short walkthrough of failure cases
    • Python
    • LangGraph
    • OpenTelemetry
    • SQLite
    • vLLM
  2. 02

    Fine-tuning and serving small open models

    When does a fine-tuned small open model beat prompting a frontier API? Measured on quality, latency, and cost, on one 24 GB GPU.

    Builds onmy production fine-tuning work: SFT and LoRA for open-source LLMs, contrastive embedding models, and transformer classifiers taken from 78% to 89% accuracy.

    Approach

    • Three task types where teams usually prompt a frontier API: structured extraction to JSON, tool calling, and classification.
    • LoRA and QLoRA fine-tuning of Qwen, Llama, and Gemma models in the 4–12B range, with held-out test sets that are never used for training.
    • Served with vLLM as LoRA adapters, in BF16, and quantized (AWQ, plus GPTQ or FP8), then load-tested at 1 to 32 concurrent users.
    • A general-skills check before and after fine-tuning, to catch regressions.

    What gets measured

    • Task accuracy against a frontier API on the same test sets
    • How much training data each task needs
    • Quality after quantization
    • Time to first token, p95 latency, and throughput
    • Cost per 1,000 requests, with the assumptions stated

    What gets published

    • Adapters with model cards on Hugging Face
    • Training and evaluation datasets
    • Train, serve, and load-test scripts
    • Write-up
    • TRL
    • LoRA / QLoRA
    • vLLM
    • AWQ
    • Qwen · Llama · Gemma
  3. 03

    Reinforcement learning for reasoning and instruction following

    Can reinforcement learning (GRPO) make a small open model reason and follow instructions better than supervised fine-tuning alone, and how does the model learn to game the reward?

    Builds onmy production fine-tuning work: SFT and LoRA training pipelines with evaluation built in, taken one step further from supervised learning to reinforcement learning.

    Approach

    • Two general skills where a program can check the answer: math reasoning (reward for the correct final answer) and following instructions with checkable rules such as length limits, required formats, and keywords.
    • A 3–4B open instruct model trained with GRPO and LoRA, compared against the prompted base model and supervised fine-tuning alone, across 3 seeds.
    • Scored on standard held-out test sets (GSM8K test, MATH-500, and IFEval) that are never used for training.
    • Runs on one 24 GB GPU, with vLLM generating the training samples.

    What gets measured

    • Benchmark accuracy for each method, with confidence intervals
    • A general-skills check, to see whether gains on one skill cost another
    • Reward curves, answer length, and training cost compared with supervised fine-tuning
    • Reward hacking: what the model learned that earned reward without being right, and how it was closed

    What gets published

    • Repo and training configs
    • Models on Hugging Face
    • Write-up
    • TRL
    • GRPO
    • LoRA
    • vLLM
    • Qwen