Skip to content
← Back to blog
fine-tuningArticle

Does your AI need construction terminology training?

The person preparing a project manager’s weekly report keeps fixing the same AI mistake: an unanswered question appears as completed work. When office shorthand causes the confusion, a glossary or better context is worth trying first. Fine-tuning becomes worth considering when the errors persist and experienced staff can show what the notes actually mean.

Author

Syntalith

Published Updated 5 min read

How an open question becomes completed work

Suppose an employee at a construction company writes: “Pending clarification: scope of work at the entrance. Question sent to subcontractor; awaiting reply.” The status means the question remains open.

The AI puts this item under “Completed” in the report and summarizes it as “Entrance scope clarified.” Someone familiar with the note spots the mistake immediately. Sending the question did not resolve it. They have to reopen the note and correct the report before the project manager relies on it. When this happens repeatedly, checking the summary can become a substantial part of preparing it.

There is enough information in this note to establish that the question is still open. An experienced reviewer can explain exactly what the model got wrong. A note containing only a location and an internal abbreviation used differently by separate teams presents another problem. Without knowing the author or project, even that reviewer may need to ask what it means. Training a model will not supply the missing information.

What to fix before fine-tuning

For an unfamiliar abbreviation, start by giving the AI its definition. A glossary may be sufficient when employees use shorthand consistently. If the notes follow a regular pattern, a simple rule assigning a category is also worth considering. Some records leave little room for interpretation.

When the meaning depends on the project, the model needs that context. The application could supply the relevant definition with the note or retrieve it from company documents. This matters when two teams use the same letters differently. A buyer needs to understand how the proposed system will identify the project a note belongs to. Teaching a single meaning could reinforce an assumption that is wrong for part of the business.

Scanned documents need a separate look. Optical character recognition, or OCR, converts text in scans and images into text software can read. It can miss a word or misread a character. If the page says “not closed” but the extracted text says “closed,” the error occurred before the model interpreted the sentence. Comparing the extracted text with the original page helps expose that problem. Otherwise, the company could pay to adapt a model when document extraction needs the attention.

These alternatives can be compared using the notes employees already correct. The useful question is what resolved each mistake: supplying a definition, finding the project context, or repairing the text read from a scan. The errors that remain provide a better basis for deciding whether to try fine-tuning.

What fine-tuning can teach

Fine-tuning adds training to an existing model using examples of the responses you want. For this task, an experienced employee identifies the appropriate category and shows how a short summary should preserve the note’s meaning. The aim is to improve how the model handles recurring writing patterns, including different ways of expressing the same thing.

Google describes supervised fine-tuning as learning from labeled examples and lists classification among its uses. It recommends starting with better instructions, then considering fine-tuning to address recurring errors. It also emphasizes the quality of the labels. This is guidance for adapting Google’s models; it does not establish the improvement a particular construction company will get. Source: Google Cloud documentation.

A task with reasonably stable meanings is a more useful candidate. The team agrees on what separates an unanswered question from a resolved one, and the same distinction appears across its notes. If category definitions change with every report, the first discussion should be about what the report’s reader needs to know.

Individual project facts will still change daily. A model that correctly understands “awaiting reply” needs a later message to learn that the reply has arrived. Access to current records remains a separate part of the application. Fine-tuning cannot replace checking the latest project information.

Will the improvement matter to the office?

Someone who reads these notes and uses the reports should help assess the result. They can distinguish awkward wording from an error that sends them back through correspondence. In the subcontractor example, the question needs to remain open in the report, with the fact that a reply is pending preserved. A more polished sentence containing the same mistake offers little help.

Before rollout, compare the adapted model with the glossary and other simpler approaches on notes from separate projects that were not used for training. That shows how well it handles another team’s writing. The comparison should also reveal which notes still need a person’s clarification. A system that appears to settle every ambiguity may simply create more confident errors for the reviewer to catch.

Agree on who will review recurring mistakes after launch. New shorthand or a change in how employees write notes may call for a glossary update or further adaptation. That maintenance belongs in the comparison with the work currently spent on manual corrections. Our article on fine-tuning for support ticket routing discusses the related question of keeping categories consistent.

Working with Syntalith

Syntalith builds AI applications and adapts models. For an office repeatedly correcting the same kinds of notes, we propose starting with those corrections. We examine what a glossary or access to project context resolves, then compare that approach with model adaptation where errors remain. We connect the selected approach to a specific office report so the team can judge how much review work is still required. The comparison may support further training or show that a simpler solution is sufficient.

For an initial conversation, describe the report you prepare, who reviews it, and the mistake they keep fixing. You do not need a completed specification or confidential project files before that discussion. We can agree later on how to work with examples. See Syntalith’s pricing page for offer information.

Match a model to the task you need it to perform

Describe where your current AI falls short. We will compare model customization options, data requirements and the cost of running the resulting system.

Private LLMs and fine-tuning
Discuss a custom model