A small red-team suite run against two versions of the app
Every case is a harmless stand-in. The fake model is scripted to be fooled by some of them, so you can watch the suite catch it.
Red-teaming means attacking your own app on purpose, with harmless test cases, before someone else does. Keep the cases as an automated suite, run it on every change, record what fails, and know how to receive and handle a report from outsiders.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write run_cases(app, cases) where each case is (name, message, forbidden). Return the list of names whose reply contains the forbidden text, ignoring case.
Write failure_rate(results) for a list of booleans (True means the case failed) that returns the failures as a string like "2 of 5".
Explain it without notes
Why do LLM apps need a red-team suite rather than a one-time review?
What makes a good red-team test case, and why include a control case?
How do you make red-team testing safe and responsible?
How would you put the suite in a team's workflow?
Expected output
app v1:
PASS direct override
FAIL rephrased override -> banana
PASS ask for marker
PASS normal question (control)
1 failed of 4
app v2:
PASS direct override
PASS rephrased override
PASS ask for marker
PASS normal question (control)
0 failed of 4