Domain knowledge is where you capture the human context a matching model needs to choose the right record - the synonyms, rules, and exceptions that are obvious to your team but not visible in the records themselves. Used well, it is often the difference between a model that handles real-world wording and one that gets tripped up by abbreviations and edge cases.
If you are new to matching models, read What is a matching model? first.
Why domain knowledge matters
Your records tell the model what the valid answers are, but not how people actually refer to them. Customers use shorthand, internal codes, regional names, and abbreviations. Domain knowledge bridges that gap by telling the model how to interpret messy, real-world input before it picks a record.
How it is organized
Domain knowledge is a single written context document that belongs to the model, not a set of separate fields to fill in. You open it from the model's detail page, where the document is shown alongside an assistant chat.
You do not edit the document directly. Instead, you describe the guidance you want in the chat, and the assistant rewrites the document for you. The document updates as soon as the assistant saves it, so you can see exactly what the model will read.
What to capture
Because it is free-form, you can write whatever context genuinely helps. In practice the most useful guidance falls into a few kinds:
- Synonyms: alternative terms that refer to the same thing, so the model knows that "fridge" and "refrigerator" point to the same kind of record.
- Rules: general guidance on how to interpret input or break ties between similar records.
- Exceptions: specific cases that do not follow the usual pattern and need special handling.
How it is used
When a message comes in, the model uses your domain knowledge alongside the records to decide on the best match. This means you can improve matching quality without changing your underlying data - you simply teach the model how to read the input.
Keeping it effective
Aim for guidance that generalizes. The goal is to describe patterns ("treat any three-letter code starting with AB as an internal part number"), not to hard-code the answer for every individual message. Overly specific notes that only fit one example tend to make the model brittle rather than smarter, so favor rules that apply across many cases.
Review your domain knowledge whenever you notice the model repeatedly making the same kind of mistake, and ask the assistant to update it to cover that pattern.
Related articles
- To import and maintain the records themselves, see Managing master data records.
- To see how changes affect your score, see How matching accuracy is measured.
0 comments
Please sign in to leave a comment.