The following are notes on the practical implementation of an AI (LLM) agent into an existing control system. The intention of the agent is to act as the 'glue' between input events and an output 'investigation'. The agent will use tools to obtain and interpret process data, design information and test functions.
Notes on Local LLM's:
LLMs do not know, how to say 'they do not know', if they are unsure. Rather an LLM will approximate an answer based on similar knowledge / patterns.
Small LLMs e.g. below 3B parameters are not sufficient for tool use as they generally loose context midway through a response.
The more parameters of a model, the more knowledge (generally).Â
High quantisation (e.g. fewer bits) results in less consistent the outputs.
Offer a playbook to refer to. e.g. what the input means, what the tools do precisely (including inputs and outputs). How sub and finals steps during tool use should be identified. The inputs should also inducate how the agent should resopond.
Request the exact format of input and output for consistency.
Tool Use:
Need to use a model that is trained in tool use. A generic model won't work or give strange results.
Try to limit the use of many tool calls as the model may get confused. Design the tools so only one or two tools are called and there is linkage back to the original query etc. Also note the full message thread / contect needs to be checked to ensure all the information is captured and not lost (FIFO style) for small models.
RAG / CAG:
Where possible avoid for small installations, and control system tool use. Provide the information as part of the request to reduce complexity.
Design the tools for easy 'chain' use by the agent. E.g. the input event, links to the tool, the tool response links to the original input and also links to any other tool use etc.