Text Classification with Fine-Tuned LLMs
classify_review takes a text together with a fine-tuned model, its tokenizer, a device, and a maximum length, and returns a predicted label.
Predicting a Label Before the Run
This article starts from a working experiment rather than from theory. A fine-tuned LLM has already been prepared for spam detection, and a helper function called classify_review uses it to look at a piece of text and return a label. The model is not being asked to write anything. It is being asked to choose one label out of a small set of predefined categories, which here are spam and not spam.
The run you are about to study sends a single message through classify_review and prints whatever label comes back. The two things you can see are the text you pass in and the label printed on the output line. Everything else happens inside the call, so the habit to build is to commit to a guess before reading the explanation.
What do you think happens?
The first test message is a short promotional notice that tries to convince the reader they have been chosen for a reward and should act quickly. Which label should the model return for it: spam or not spam?
Reveal answer
spam
The source reports that the promotional message is labeled spam. The message offers a prize and pushes the reader toward an immediate action, which is the kind of content a spam label is meant to capture.
What Goes Into classify_review
The function takes five arguments. The first is the text to be classified. The second and third are the fine-tuned model and the tokenizer that the model works with. The fourth is the device the computation runs on. The fifth controls the maximum length the input is allowed to have. In the source, this length is set from the training dataset rather than typed as a fixed number.
Because the function is called with these arguments, the call site is where you decide which model, which device, and which length limit are used for a given prediction. The text is the only argument that is meant to change from one message to the next. The rest are settings you choose once for the situation.
Tracing Two Runs Side by Side
The first test case is the promotional message. The source reports that it is labeled spam. The second test case is a short personal note asking whether two people still plan to meet for dinner. Nothing in it offers a prize or asks a stranger for an immediate action. The source reports that the model again makes a correct prediction here, returning the not spam label.
Tracing the two test cases through one call
Two messages are passed to classify_review. The model, tokenizer, device, and length setting are the same in both calls. What differs between the two printed labels?
- 1Hold the fixed arguments constant
The model, tokenizer, device, and maximum length stay the same in both runs, so they cannot explain a difference in the output.
- 2Identify the one argument that changes
The text is the only argument that differs between the two test cases.
- 3Compare the printed labels
The promotional message produces spam, and the dinner-plans message produces not spam. Given the fixed arguments, the difference comes from the text.
The same function returns two different labels for two different texts. The text is the input you control, and the label is the output of the call.
Where a Prediction Can Go Wrong
When a prediction looks wrong, the fastest route to a fix is to narrow down which part of the chain produced the unexpected label. The chain has only a few links: the text you supplied, the arguments that accompany it, the function call itself, and the label that comes back. A mismatch between your expectation and the printed label tells you that at least one of these links is not what you assumed.
Common mistake Changing several arguments at once when a prediction looks wrong
Why it failsIf the model, device, and length change along with the text, you can no longer tell which change caused the new label.
Do this insteadHold every argument except the text constant, and check the exact input that was passed in.
Common mistake Assuming the function returned what you intended to send
Why it failsThe label you see is the output of the call, and a mismatch means some link in the chain differs from what you assumed.
Do this insteadInspect the text that was actually supplied before deciding the model is at fault.
Checking Your Own Prediction
Imagine a new message that is a short personal note asking whether two friends can still meet for lunch on Friday, with no prize, no link, and no request for urgent action. Before looking at the reasoning, predict whether classify_review should return spam or not spam for this text, then state which single argument you would change to test your prediction and which ones you would keep fixed.
Hints
- Compare the new message to the dinner-plans test case in the source, which is labeled not spam.
- Keep the model, tokenizer, device, and maximum length fixed, and vary only the text.
Key Takeaways
classify_reviewtakes a text, a fine-tuned model, its tokenizer, a device, and a maximum length, and returns one predicted label.- The model chooses one label from a predefined set, spam or not spam, rather than generating new text.
- In the source's two test cases, the promotional message is labeled spam and the dinner-plans message is labeled not spam, with the text as the only changing input.
- Predict the label before running the function, then check the prediction against the printed output.
- When a result surprises you, hold every argument except the text constant and inspect the exact input passed in.