Small language models are compact AI models that understand and generate text at low cost, and they can replace traditional tools such as keyword rules, regular expressions, spreadsheet formulas and manual tagging for some marketing tasks. Switch when inputs are messy and varied, and keep traditional tools when the task is exact, rare or must be fully explainable.
The question is not “AI or no AI”. Traditional tools are fast, cheap, predictable and auditable. Small models, such as Phi, Gemma, smaller Llama and Qwen variants, or the small tiers of commercial APIs, handle language variation that rules cannot. The best setups often combine both: rules for the clear cases, a model for the rest.
What counts as a traditional tool here?
In marketing operations, “traditional” usually means one of these.
- Keyword and phrase rules: if a search term contains “free” or “jobs”, mark it as irrelevant.
- Regular expressions: extracting order numbers, phone numbers or UTM values from text.
- Spreadsheet logic: VLOOKUP, IF chains and pivot tables for categorisation.
- Classical machine learning: logistic regression or decision trees trained on labelled data.
- Manual work: a person tagging reviews, sorting leads or cleaning a CRM export.
Each has strengths. Rules are transparent and instant. Regex is exact for well-defined patterns. Manual work handles judgment.
When does a small model clearly win?
Language variation
Customers say the same thing a hundred ways. A rule list for “complaint about delivery” never covers “parcel still hasn’t shown up” or Turkish variants with typos. A small model handles that variation without a growing list of exceptions.
Many categories with fuzzy edges
Sorting thousands of blog posts into topics, or search terms into intent groups, involves judgment at the edges. Rules break; a model with a few examples copes better.
Multilingual input
One model can label Turkish, English and German reviews with the same prompt, while rules would need separate lists per language.
Mixed unstructured fields
Free-text job titles, company names or “how did you hear about us” answers vary endlessly. Normalising them is tedious by hand and brittle with formulas.
When should you keep traditional tools?
- Exact patterns: email addresses, VAT numbers, dates and URLs are better extracted with regex; a model may “correct” them.
- Calculations: totals, averages and budget pacing belong in formulas or code, not language models.
- Compliance rules: when a decision must be explainable line by line, such as excluding certain audiences, a written rule is clearer.
- Very small volumes: if ten items arrive per week, a person is faster than building a pipeline.
- Stable, simple categories: if “contains brand name” decides the label correctly, there is no reason to add a model.
How do you compare them fairly?
Run both approaches on the same labelled sample before deciding. A practical method:
- Collect 300 or more real items and have a specialist label them.
- Apply the current rules or process and record agreement with the labels.
- Run a small model with a short prompt and a few examples; record agreement.
- Check where each approach fails; the errors often differ.
- Compare total cost: setup time, running cost, review time and maintenance.
If the rules already agree with the specialist almost all the time, keep them. If the model clearly does better on the cases that matter most, switch, or combine them.
Why is a hybrid setup often best?
Put fast, cheap rules first and send only unclear items to the model. For search terms, a rule can mark exact brand terms and known irrelevant words instantly; the model handles the long tail. For lead routing, rules catch existing customers by email domain; the model reads the free-text message for the rest.
This reduces cost, keeps behaviour predictable for common cases, and limits the number of items where a model error can occur. Low-confidence model outputs can then go to a human queue.
How Alien Road applies small language models alongside traditional tools
In a typical engagement our AI optimisation team audits the client’s existing rules before proposing any model. Discovery collects the current rule sets, spreadsheets and manual tasks: negative keyword lists, lead routing rules, content tagging guidelines, and the time each takes per week.
Setup follows the comparison method above. We label a sample with the client’s specialists, test the current rules and one or two small models, and design a hybrid flow where it helps. Outputs are always validated in code against the allowed labels, and unclear items go to a review queue.
Measurement covers agreement with human labels, hours saved, review queue size and running cost. Monthly reports flag new patterns, for instance a product launch that produces search terms neither the rules nor the model handle well, so the rules and prompts are updated together.
What are the hidden costs of switching?
Models need monitoring. Inputs change: new products, new slang, new competitors. A model that agreed with specialists in March can drift by September. Rules drift too, but their failures are easier to spot. Budget time for a monthly check against fresh samples.
There is also dependency risk. If you rely on an API model, a provider can retire or change it. Keep prompts, examples and test sets stored, so switching to another model is a re-test, not a rebuild.
What about classical machine learning?
Before language models, teams trained classifiers such as logistic regression or gradient-boosted trees on labelled data. These still work well when you have thousands of labelled examples, a stable set of categories and structured inputs, such as predicting lead quality from form fields and firmographics. They are cheap to run and easy to monitor. Small language models are more useful when inputs are free text and labelled data is scarce, because a few examples in a prompt can stand in for a full training set.
Where to start this week
Pick one rule-based process your team maintains by hand, such as the negative keyword list or the lead routing spreadsheet. Pull 200 recent items it handled, and mark the ones it got wrong or that needed manual correction. If the errors are mostly about wording variation, test a small model on just those items; if they are about exact values or calculations, improve the rules instead.
Keep reading: AI Optimization · AI Optimization