Fine-tuning adapts a pretrained AI model to a narrower task by training it further on your own examples, and LoRA (low-rank adaptation) is a popular method that does this cheaply by training small add-on weight matrices instead of the whole model. The most common mistakes are fine-tuning when a better prompt would do, training on messy data, and skipping evaluation.
What are fine-tuning and LoRA, briefly?
A base model such as Llama, Mistral or Qwen has general knowledge and general habits. Fine-tuning shows it hundreds or thousands of input and output pairs so it learns a specific style, format or task. Full fine-tuning updates every parameter, which needs serious GPU memory and time.
LoRA, described in a 2021 research paper from Microsoft, freezes the original weights and trains small low-rank matrices alongside them. The result is an adapter file that is often a tiny fraction of the model’s size. You can keep one base model and swap adapters for different clients or tasks. QLoRA goes further by loading the base model in 4-bit precision, which lets people tune fairly large models on a single consumer or workstation GPU.
Hosted options exist too. OpenAI, Google and other providers let you upload training data and fine-tune selected models through their platforms, without managing hardware yourself.
Mistake 1: fine-tuning before trying prompts and retrieval
Many teams reach for fine-tuning because it sounds like the serious option. In practice, a large share of marketing needs are met by clear prompts with good examples, or by retrieval-augmented generation (RAG), where the model reads relevant documents at the moment it answers.
A useful rule: fine-tuning teaches form, retrieval supplies facts. If you want the model to know this month’s product prices, fine-tuning is the wrong tool, because the knowledge freezes at training time and goes stale. If you want it to always write product copy in a particular structure and voice, fine-tuning can help.
Mistake 2: training on data nobody cleaned
A fine-tuned model copies whatever patterns sit in its training set, including the bad ones. Typical problems in marketing datasets:
- Old copy that mentions discontinued products or expired offers.
- Inconsistent formatting, so the model learns no clear structure.
- Duplicates that overweight a few examples.
- Text written by many authors with different standards.
- Personal data, such as customer names inside support transcripts, that should never be baked into weights.
Small, curated datasets usually beat large, noisy ones. A few hundred carefully chosen examples that represent exactly what you want can outperform thousands scraped from an archive.
A data review checklist
- Remove anything you would not publish today.
- Standardise the input format so every example looks the same.
- Strip or replace personal information.
- Hold back a separate test set the model never sees in training.
- Have a person read a random sample before training starts.
Mistake 3: no evaluation, only impressions
The classic failure is training a model, trying five prompts, liking the answers and declaring success. That tells you very little. You need a fixed test set and a way to score outputs, whether by human rating, rule-based checks (length, banned words, required fields) or a comparison against the base model with a good prompt.
Overfitting is the specific danger. A model trained too long on a small set may reproduce training examples nearly word for word, or lose general abilities it had before. Watching validation loss during training and testing on unseen inputs catches this.
Mistake 4: wrong settings for LoRA
LoRA has a few hyperparameters that matter: the rank (often written r), the scaling factor alpha, which layers receive adapters, the learning rate and the number of epochs. Copying settings from a random tutorial built for a different model size or task leads to weak or unstable results.
Libraries such as Hugging Face PEFT and tools like Axolotl or Unsloth come with sensible defaults, and those defaults are a reasonable place to start. Change one setting at a time and record the result, otherwise you cannot tell what helped.
Mistake 5: ignoring licensing and deployment
Open-weight models come with licences that differ. Some permit broad commercial use, others carry restrictions or attribution rules. Check the licence of the exact base model version before building a client product on it.
Deployment is often an afterthought. A fine-tuned adapter needs somewhere to run, with predictable cost and latency. Serving tools such as vLLM support loading LoRA adapters, and several cloud providers host custom models, but someone has to own monitoring, updates and rollbacks.
How Alien Road applies fine-tuning and LoRA
In a typical engagement, discovery starts by asking whether fine-tuning is needed at all. We first build the best prompt-plus-retrieval version of the task and measure it. Only when that baseline still misses on style or format consistency do we consider training.
If training goes ahead, setup centres on the dataset. We work with the client to select approved examples, clean them, remove personal data and split off a test set. A small LoRA run on an open-weight model, or a hosted fine-tune, comes next, with settings and data versions logged.
Measurement compares three versions on the same test set: the base model with a plain prompt, the base model with the best prompt, and the tuned model. Reviewers score outputs blind, without knowing which version wrote which. Reporting to the client shows those scores, the cost of running each option and a recommendation, which sometimes is to stay with prompting.
When is fine-tuning clearly worth it?
It earns its place when a task is narrow, repeated at high volume and judged on consistency. Examples include classifying incoming leads into fixed categories, rewriting product data into a strict template, or producing short ad lines in a very specific brand voice. In such cases, a small tuned model can also be cheaper and faster to run than a large general one.
It is rarely worth it for broad creative work, fast-changing facts or tasks you perform a few times a month.
Where to start this week
Write down the single task you think needs fine-tuning. Build the strongest prompt you can for it, with three good examples, and run it on 30 real inputs. Score the results honestly.
If more than a few outputs fail on format or voice, start collecting a clean dataset of approved examples. Aim for quality over size, set aside a test set, and only then plan a small LoRA experiment.
Keep reading: AI Optimization · AI Optimization