When a model keeps getting your domain wrong, the reflex is to reach for something heavy: fine-tuning, a bigger model, a retrieval system. Before any of that, try the cheapest intervention available: write a glossary and put it in the prompt.
Most domain mistakes are vocabulary mistakes. Your company says "account" and means a billing entity; the model assumes a user login. Your team says "release" for a deploy to staging; the model hears a public launch. Every organisation has dozens of these overloaded words, and the model has no way to know which meaning you intend unless you tell it.
A useful glossary is short and specific:
- The term, exactly as it appears in your data and your users' messages.
- A one-line definition, written the way you would explain it to a new hire.
- What it is not, when there is a common confusion. This line often does the most work.
- One example of the term in a real sentence, if the usage is subtle.
Keep it to the terms that actually cause errors. You can find them by reading a sample of failures and noting every place where the output was reasonable under the model's reading but wrong under yours. A dozen well-chosen entries beats a hundred-term dump that the model has to wade through.
Two cautions. First, the glossary is a maintained artifact: when the product renames something, the glossary changes in the same pull request, or it becomes a source of confident errors. Second, test it. Run your eval set with and without the glossary and confirm it helps; occasionally a definition nudges the model in an unintended direction.
If a glossary fixes most of the errors, you have saved yourself a training pipeline. If it does not, you have at least learned precisely which mistakes are about knowledge and which are about something harder, and that makes the next, more expensive choice a better-informed one.