The same code on different machines: building a useful report

Why the code E17 alone is not enough

In the example we compare device families A and B, and the meanings of the codes were chosen for the example. In family A's documentation, code E17 is a connectivity message, while in family B the same code concerns a temperature sensor. Putting every E17 entry into one group would hide that difference. A good report shows connectivity messages from family A and sensor messages from family B separately, with a link to the original records.

If a record holds only E17 and the device family cannot be established, the entry stays open for clarification. One meaning appearing more often in the archive gives no basis for assigning it to this entry. The category describes the content of the message and does not settle the cause of the event, its urgency or what to do with the equipment.

What a simpler change gives, and what training adds

In this count, a lookup table with the device family gives most of the effect for a fraction of the cost. Training makes sense at a larger scale or when the remaining errors are expensive. A wrong category costs more than an entry left open for clarification, because it means correcting a part of the report that looked finished, so we count both results separately.

The set of training examples has to be maintained: when the process, the naming or the base model changes, the evaluation is repeated on the same test set. We put that cost into the quote together with the training itself.

Where a model can help

When the device family and the meaning of the code are known, an ordinary lookup table is enough and no model training is needed. Before you order anything, check whether the export to the report drops the device name, or whether systems use different labels for the same family. A model has work to do when the information appears in descriptions written in different ways, abbreviations, or messages from newer generations of equipment. Google describes supervised tuning of models for specific tasks, including classification. A new meaning of a code in the next generation of equipment goes into the table and the examples, because the model will not learn it on its own.

Where to start

We run the trial on messages and device families not used for customisation, with the documentation and the agreed context. The analyst sees the number of wrong assignments beside the number of entries left for clarification. Descriptions of maintenance events are covered in fine-tuning for maintenance event descriptions. We run model customisation as part of private LLMs, and the application in which the employee sees the result beside its source as part of AI applications. For the free analysis, a few examples of an error that keeps coming back and a note on who corrects it today are enough.