Module 4 · Lesson 5 of 5
Checking the answer before it is shown
Check before you show
Plain code checks every answer before the user sees it, and a failed check has a planned next step.
Scene 1 of 4 · The model answers
The page needs the answer in JSON, a strict data format; this time the model sends broken JSON.
- Language model — healthy
- Answer checks — healthy — checking
- User — healthy
| Code check |
|---|
| Valid JSON |
| No phone number but the support line |
| Under 200 words |
- The model answers. The page needs the answer in JSON, a strict data format; this time the model sends broken JSON.
- Code checks it. Plain code runs 3 checks: valid JSON, no phone number but the support line, and under 200 words.
- Ask once more. The JSON check failed, so the app sends the request to the model again rather than show a broken page.
- Then show it. The second answer passes every check, and only then does the user see it.
- Now you try. Pick an answer the model sent, and see which check catches it. For example: "No phone number but the support line" fails, so the app will block the answer and show a safe message. The response to each failure is decided in advance, so an answer that fails a check does not reach the page.
Scene 1 of 4: The model answers. The page needs the answer in JSON, a strict data format; this time the model sends broken JSON.
Key points
- Checks run between the model and the user.
- Code checks are fast and cheap: format, private data, length.
- Each failed check has a planned response.
- A model-based check can add more, but keep the code checks too.
A model can write something false, unsafe or in the wrong format. (A check on what goes into a model or on its answer, such as a format check or a search for private data.) are checks that run on the answer before the user sees it.
Some are plain code: is the answer valid (A plain-text format for data, such as {"id": 42, "name": "Asha"}. Most web APIs send and receive it.), does it include a phone number it should not, is it under the length limit?
Others use a second model to look for problems. That is slower and can itself be wrong, so keep the code checks too. A check catches only what it was written for, so some bad answers still get through.
In system design: Put cheap code checks on every answer, and decide in advance what happens when a check fails.