Tutorial

Prompting, references and fine-tuning: what actually changes an AI model?

Before commissioning a custom AI model, distinguish better instructions from training and test whether the extra work solves a repeatable brand problem.

DELA Media2026-10-27

Hand-drawn interface wireframes arranged on paper beside an orange pen.

A supplier offers to train AI on your brand. Before discussing the price, ask what that means in the proposed workflow. It could refer to a reusable prompt, a folder of reference images, a search system that retrieves documents, or a genuine training process. These approaches solve different problems and should have different acceptance criteria.

A clearer description prevents a team from buying infrastructure when a better brief would have been sufficient.

Instructions and examples change the input

Prompting supplies instructions or examples when the model is used. In-context examples can demonstrate an expected tone or output structure without updating the model’s parameters. Google’s fine-tuning and prompt-engineering lesson draws this distinction explicitly.

For a studio, a carefully organised reference pack may already remove substantial ambiguity. Specify approved colour use, the purpose of each example and details that must not be copied. A folder labelled inspiration is less useful than an annotated set that explains what each reference contributes.

Fine-tuning involves additional training

Fine-tuning changes model parameters through further training for a task or domain. Parameter-efficient methods update a smaller set of trainable values instead of changing every parameter. LoRA is one published approach, introduced by Hu and colleagues through low-rank adaptation of large language models.

The name of a training method does not prove it will preserve a particular product or deliver a preferred visual style. Ask the supplier to demonstrate the exact task you care about, with material that was not simply repeated from the training examples.

Define the repeatable problem first

Imagine a brand commissioning dozens of product explanations over time. It might need consistent terminology and section order, or it might need a recurring visual character. Those are different evaluation problems. A model that writes good copy has not thereby demonstrated reliable visual continuity.

Write a one-sentence requirement and a set of failure examples. For copy, incorrect feature names might be disqualifying. For imagery, an altered silhouette might be unacceptable even when the overall style is convincing. Agree those boundaries before evaluating a custom system.

Compare against the simplest workable baseline

Give the existing tool a structured prompt and approved references. Record the time needed to reach an acceptable result. Then compare a proposed custom approach on the same assignment and the same review criteria. Include setup, human review and revision time, not only generation time.

Keep some test tasks separate from the examples used to configure or train the system. If every evaluation example has already shaped the solution, the comparison will tell you less about how it handles the next real brief.

Ask what will be delivered and maintained

A useful handover should identify the model or adapter, supported environment, input requirements, version and evaluation examples. Clarify access to training material, permitted use and who maintains the workflow when its dependencies change. These are project questions to resolve with the supplier, rather than guarantees attached to any technology label.

Prefer a limited pilot if the business need is still uncertain. A custom model becomes worth considering when a repeated task, sufficient suitable material and measurable improvement justify its maintenance. Until then, a well-designed briefing and review process may provide a clearer return than an impressive technical name.

Sources and further reading