Njàngat IA

It combines representative examples, explicit scoring rules, and analysis of mistakes. A successful API response or a polished demonstration does not establish that the system performs the intended task reliably.

Takeaway yu am solo

• Set acceptance criteria before testing.
• Keep a held-out evaluation set.
• Measure content, workflow outcomes, and failure handling separately.

Write the acceptance criteria first. Specify the input, expected output, tolerable errors, response-time constraints, and conditions that should cause the system to abstain or escalate. Include a simple baseline to show whether added complexity provides a practical benefit. Build separate development and evaluation sets. Development examples support iteration; a held-out set tests choices after they are made. Repeatedly tuning on the final test set turns it into another development set. Record versions so a changed score can be traced to changed data, prompts, models, or scoring. Use metrics appropriate to the task. A classifier needs class-specific error analysis; a summarizer needs checks of factual consistency and coverage; an agent needs verification of completed actions and unintended side effects. Include difficult cases rather than only typical inputs. Review results with uncertainty and consequences in mind. A rare failure may matter more than many harmless wording differences. Repeat a stochastic task enough to understand variation, and document where the evaluation does not represent actual use. Evaluation supports a decision; it does not eliminate uncertainty.

1. Prepare an invented invoice with subtotal 80, tax 8, and total 88, plus another invoice where the total is absent.
2. Score field extraction and arithmetic consistency separately. Require an explicit missing value for the second document.
3. Add a case with an unrelated number near the total label to check whether the system invents a convenient answer.

The exercise defines correctness beyond merely returning well-formed JSON.