Model Evaluation - lesson 6 | HackIndia Skills

Key point

One honest result

Your result should tell a reviewer what you tested, how you tested it, what you compared against, and what still fails.

Do not write only “95% accurate”. A good result is specific enough that another builder can understand the test without asking you on WhatsApp.

What to include

For this track, your model evaluation section needs six items: dataset, split method, baseline, confusion matrix, key metric, and one limitation.

This is what internship reviewers look for. They want to know if your model works outside the few examples you showed in the demo.

Your to-do

Write the section

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Name the dataset and say how many rows or files you used.
State the split method, such as 80/20 random split or train/validation by date.
Mention the baseline score before your model score.
Add the confusion matrix numbers, not just a screenshot.
Choose one key metric and explain why it matters for your use case.
End with one limitation that could change the result.

0 of 6 done

Example

Project description example

Use this as a plain project README or demo script section. Replace the values with your own numbers.

The limitation is not an apology. It shows that you know where your test is weak.

Model evaluation

Dataset: 2,000 labelled support messages from our college helpdesk sample. Labels were spam and not_spam.

Split method: 80/20 random split with a fixed seed. Train: 1,600 messages. Validation: 400 messages.

Baseline: Majority-class baseline predicted every message as not_spam. Baseline accuracy was 72%.

Model result: Logistic regression with TF-IDF reached 89% accuracy on the validation set.

Confusion matrix on validation set:
- True spam predicted spam: 82
- True spam predicted not_spam: 30
- True not_spam predicted spam: 14
- True not_spam predicted not_spam: 274

Key metric: Recall for spam was 73%. We chose recall because missing spam lets bad messages reach users.

Limitation: The data came from one college-style helpdesk sample, so the result may not hold for messages from other campuses, languages, or festivals when message patterns change.

Common mistake

Do not overclaim

A validation result is not proof that your model will work for every user in India. It only supports the dataset and split you used.

Avoid lines like “works perfectly”, “detects all fraud”, or “ready for production”. Write what your test actually showed.

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to turn your metrics into a clean paragraph. But paste the numbers yourself and check every claim it adds.

AI often makes the result sound stronger than your test. Delete claims about real-world performance, production readiness, or users you did not test.

Prompt:
Write a short, honest model evaluation section for my hackathon README.
Use only these facts. Do not add claims.
Dataset: [describe]
Split: [describe]
Baseline: [score]
Model: [score]
Confusion matrix: [numbers]
Key metric: [metric and why]
Limitation: [limitation]