AI · LESSON 22 / 25 · English
Evaluating AI Systems
Ask: good at what, for whom, and under which conditions?
Content reviewed: 22 October 2026 · தமிழில் படிக்க ↗
Understand it in plain language
Evaluation starts with a task, a representative test set, and an error definition. Classification may need precision and recall rather than accuracy alone. Generative systems also need checks for factual support, relevance, task completion, and harmful failures. An LLM judge can assist a process but should be calibrated against human review and checked for bias; it is not an unquestionable ground truth.
How the AI approach works
Evaluation turns a claim into a testable question. Define the task, intended users, allowed inputs, desired outputs, and consequential errors before choosing a metric. Separate development examples from final held-out evaluation. Preserve a stable regression set, while adding newly discovered failures without quietly turning the final test into another tuning set.
For classification, accuracy counts all correct predictions. Precision = TP/(TP+FP) asks how many predicted positives were correct; recall = TP/(TP+FN) asks how many actual positives were found. F1 combines precision and recall, but still hides different error costs and subgroup patterns. Thresholds change the tradeoff. For regression, absolute and squared error emphasize mistakes differently; compare with a meaningful baseline.
Generative evaluation needs a rubric: correctness, evidence support, relevance, completeness, instruction adherence, and acceptable handling of uncertainty. For RAG, assess retrieval and answer faithfulness separately. For agents, verify actual task state and side effects, not just the final message. LLM judges can help scale review, but require calibration against human judgments and checks for order, style, and language bias.
Report denominators, task coverage, and uncertainty. A result from ten easy examples is weaker evidence than representative repeated testing. Slice English, Tamil, code-mixed inputs, rare intents, missing evidence, and tool failures. Combine offline tests with monitored deployment evidence; neither is a permanent certificate of quality.
Break the idea into steps
- Create representative normal, difficult, Tamil, and mixed-language cases.
- Choose metrics and thresholds before comparing candidate systems.
- Review individual failures and test changes against a fixed regression set.
Worked example: connect the method to the task
A payment classifier has TP = 8, FP = 2, FN = 4. Precision is 8/10 = 0.80; recall is 8/12 ≈ 0.667. A higher decision threshold may reduce false alarms but can miss more real payment cases. Choose based on the support process, then validate the choice on held-out examples.
For a policy assistant, use questions with supported answers, questions with no answer in the sources, and conflicting policies. Review whether each citation supports the claim. For an access-restoration agent, verify the account state after the action.
Algorithm experiment: predict, change, explain
These synthetic counts calculate precision and recall. Increase false negatives while keeping the other counts fixed and explain which metric changes. This is a metric calculation, not a trained classifier.
tp, fp, fn = 8, 2, 4
precision = tp / (tp + fp)
recall = tp / (tp + fn)
print("precision:", round(precision, 2))
print("recall:", round(recall, 2))Predict first, then reveal the checked output
precision: 0.8 recall: 0.67
Change one thing. Run it again.
Run this small, self-contained experiment in standard Python. No package installation or paid API is required. Change the suggested variable and explain the effect on the method before applying it to real data.
Let the editor finish loading, load this example, then press Run.
The free editor uses OneCompiler, an external service. Code you run is sent there. Do not enter passwords, API keys, or private student data. If an example is sent before the editor is ready, wait and load it again.
Apply the idea: check your reasoning
Think before revealing the answer
Two assistants have the same average score. What else would you compare?
Reveal the answer and reasoning
Inspect important slices, failure severity, uncertainty handling, source support, latency, cost, and task completion. Equal averages can hide very different risks and user experiences.
A common mistake: A single benchmark average can hide important language, subgroup, and safety failures.
Before you move on
- Explain the main idea without repeating the technical label.
- Identify the approach, its assumptions, and the evidence needed to trust the result.
- Complete the challenge, then compare your reasoning with the answer.
Sources & a deeper next step
The refresh uses primary papers and official documentation. These optional links are in English; you can understand this lesson without reading them first. Product versions and availability can change.