Data & AI Project
Sentiment Analysis API
Most machine-learning projects stop at a notebook, which is exactly where employers stop being interested. This one goes the rest of the way — train a classifier, wrap it in an API with a latency budget, containerise it and watch it — which is what an ML engineer is actually paid to do.
The brief
Train a model that classifies text sentiment, then serve it over HTTP. It must respond within a stated latency budget, handle bad input, run in a container, and log enough to notice if predictions drift.
What it demonstrates
That you can cross the gap from notebook to production — the single biggest differentiator in junior ML hiring.
What "done" looks like
Build all of these and the project is finished. Anything past that is in the stretch goals.
- A trained classifier with a reported baseline to beat
- A POST endpoint returning label and confidence
- A stated latency budget that is actually met
- Input validation and clear errors
- A Docker image that runs anywhere
- Logging of latency, errors and prediction distribution
How to build it
- 1
Get and inspect the data
Check class balance and text length before modelling. An imbalanced set makes accuracy meaningless.
- 2
Build the baseline
TF-IDF plus logistic regression. Trains in seconds, and is the number every later model has to beat.
- 3
Evaluate properly
Precision, recall and F1 per class on a held-out set. Look at the confusion matrix, not just the headline score.
- 4
Try a transformer
Fine-tune a small pretrained model and compare — on score AND on latency. Report both honestly.
- 5
Wrap it in an API
FastAPI with a typed request and response. Load the model once at startup, never per request.
- 6
Validate and fail well
Reject empty and oversized input with a 4xx and a useful message rather than a stack trace.
- 7
Containerise it
A multi-stage build so the image does not carry the training dependencies into production.
- 8
Add monitoring
Log latency percentiles and the distribution of predictions. Drift is invisible without it.
Once it works
Only after the definition of done is met. Half-finished ambition reads worse than a small finished thing.
- Batch requests to raise throughput and measure the effect
- Quantise the transformer and compare latency against accuracy
- Add a feedback endpoint and a retraining pipeline
Frequently Asked Questions
Should I fine-tune a transformer or use a simple model?
Build the simple baseline first — TF-IDF with logistic regression trains in seconds and is often within a few points of a transformer on straightforward sentiment. Then fine-tune, and report both. Showing you measured the trade-off is worth more than the higher score.
What latency should I target?
State a budget and meet it — 100ms at the 95th percentile is a reasonable target for a small model on CPU. A transformer may not fit that without batching or quantisation, and discovering that yourself is the most valuable part of the project.
What should I monitor?
Latency, error rate, and the distribution of inputs and predictions. A model degrades silently as the world changes, so watching what goes in matters as much as watching whether the service is up.