Machine learning portfolio projects: three briefs with evaluation plans
Build an ML portfolio with three practical project briefs covering prediction, document search and image classification, with baselines and clear deliverables.
A useful machine learning portfolio project shows a complete decision: what problem you chose, which data you could use, how you tested the result, and where it fails. Start with one project you can reproduce and explain. These are suggested briefs, not completed SchoolWhool experiments or guaranteed routes to an interview.
1. Predict demand with a time-based evaluation
Question: Can historical observations help predict demand in a later period?
Choose a public time-stamped dataset with permission to redistribute it, or document how a reviewer can download it. Define exactly what is predicted and how far ahead. Begin with a baseline that repeats the previous comparable period; compare a small regression model against it.
Keep later observations out of the training period. Think about what information would actually be available at prediction time: a feature calculated using tomorrow's demand makes today's prediction invalid. Record the date boundaries and evaluate on more than one period where feasible.
Deliverables: A data dictionary, a reproducible training command, a comparison with the baseline, and a chart of errors over time. Explain which conditions produce the largest misses and what those misses would mean to someone planning resources.
Useful extension: Package the prediction in a small API with input validation. This connects modelling to skills discussed on the machine learning engineer career page.
2. Search a document collection and show the evidence
Question: Can someone find the passage that answers a question in a small public document collection?
Start with a search-only baseline. Create your own evaluation set of questions, relevant passages and questions with no answer in the collection. Keep a separate set for evaluating changes after development. Compare keyword retrieval with another retrieval method before adding generated answers.
If you add a language model, inspect retrieval quality and answer quality separately. A plausible answer can still cite the wrong passage. Include conflicting passages, outdated information, and requests the collection cannot support. Report the proportion of your evaluation questions with a relevant result, and describe how you judged relevance.
Deliverables: A source manifest, example queries, evaluation results, a small demo, and a failure log. Include response time and the cost of your actual experiment if you measured it; do not project savings you have not observed.
Useful extension: Add source dates and show which document version each answer used. Compare the resulting work with LLM engineer job requirements. SchoolWhool's LLMs and generative AI syllabus is a planned track, not a completed video course.
3. Classify images and investigate the mistakes
Question: Can a small classifier distinguish a few well-defined categories under realistic conditions?
Use images with clear reuse permissions. Document the label definitions and remove accidental duplicates across your splits. If several images show the same object or come from the same session, consider keeping that group together when splitting so evaluation does not merely test recognition of near-duplicates.
Compare a simple baseline with your chosen model. Inspect a confusion matrix and examples of incorrect predictions. Test relevant variations such as lighting and background, and describe which conditions your dataset does not cover.
Deliverables: A dataset statement, setup instructions, evaluation script, labelled error examples and a short demo. Explain when the tool should refuse to give a confident answer.
Useful extension: Test performance on a separately collected, permitted image set. Use computer vision postings to identify which engineering skills you still need to demonstrate.
A review checklist for every project
| Question | Evidence to include |
|---|---|
| Can someone reproduce it? | Dependencies, commands, data access instructions and random seeds where applicable |
| Is the comparison fair? | The baseline and the same evaluation examples for each approach |
| Could evaluation data influence training? | Split rules and preprocessing fitted only on training data |
| What fails? | Concrete errors and the limits of your conclusions |
| What did you contribute? | Your changes distinguished from tutorials, libraries and generated code |
| Can someone use it? | A demo or documented interface with valid example inputs |
Review scikit-learn's guidance on leakage and preprocessing before interpreting scores. Keep a final evaluation set out of repeated development decisions; Google's dataset split guide explains why.
Put the project on your résumé
Write the task, your contribution, the evaluation and a limitation. Use measured results only. An honest bullet might say: “Built a document-search demo with a labelled evaluation set and compared retrieval methods; documented failures on unsupported questions.” Add numbers only after running and recording the experiment.
If you need the foundations first, follow how to learn AI from scratch. When you are ready to apply, connect the project's actual evidence to the requirements using the résumé tailoring guide.