AI Language Models as Algorithmic ‘LPUs’

Introduction

This blog post is a quick exploration of ideas that I thought would be interesting to highlight, following on from a series of experiments focusing on using public AI language models (such as ChatGPT) for internal communication workflows as part of developing an automation network. This is also in reference to the ‘Hexus’ network project; an interpreter-client-server network that can distribute tasks to responsible devices on a network based on what the user is asking. A couple of videos have been uploaded to the second channel in the past demonstrating this. (1, 2).

Here I also define the term LPU (Logical Processing Unit), or alternatively LIU (Logical Interpretation Unit) to explain how language models are functionally capable of replacing algorithms and communication structures cross-industry. It is easy to get distracted by the commonly demonstrated uses of the tools in regards to AI artwork, but at a fundamental level, the ability for a language model to at least interpret whether something is positive or negative via connotations, or whether data is linked, or if patterns can be identified in a given data set, opens new capabilities in the field of software development that are difficult to conceptualize during these early stages, where the cultural impact of disruptive AI tools has not been adequately measured, and is difficult to project into the future. Overall, this has put the image of AI tools into a confused state for developers, amplified by the growing stigma of more personal impact use-cases (such as the exploitation of artist’s copyright without adequate reward or attribution), or the redundancy of various layers of work in otherwise creative (or non-creative, often industrious) fields. More subtle, but perhaps equally impactful, use-cases are flying under the radar, or just not being given the appropriate press coverage. The medical field in particular, is one that stands to greatly benefit from the advancement of AI.

The System Message

Along with the multitude of features and selling points, one of the areas with the greatest potential for language models is the ability to provide higher-weight system messages that the AI will take on-board to inform / direct future responses. The power for the system comes from the fact that you can tell the model in which format it needs to structure the response. Immediately, it becomes apparent how useful this is for parsing algorithms. We can now substitute parsing / string reformatting algorithms with a plain-English description. Taking this further, not only are the language models capable of complying to customised response formats (telling the model to express itself through returned commands), but they are also capable of understanding the reason behind the format, and the commands therein, meaning it is not troublesome for the model to substitute / hallucinate missing data when there is limited information available (or to avoid substitution entirely if accuracy is paramount), to ensure that the command structure is complete, therefore naturally avoiding empty reference errors. This removes the additional need for exception handling.

The Tree of Interpretation

There is a temptation to see AI language models as a single tool for every use case, or something that should be capable of producing a complete output from a single request, but it’s my opinion that the real power of language models could come in the form of abstraction trees. More specifically, instead of a single model considering all components of a system at once, smaller models are employed to perform single small tasks, that together will contribute towards a final end goal. Segmenting tasks into limited modules is also safer from the perspective of ‘rogue AI’. Rather than a single decision-making mind at the top of all subprocesses, a thousand smaller minds are employed to work together. Admittedly, emergent behaviours are difficult to predict, so complex trees of logic, composed of countless layers of abstraction, may themselves be regarded as a single ‘mind’, similar to a single battery composed of many cells. Therefore, there may be a new field of software design that is yet to emerge, specifically focused on describing the memory and operational limitations of AI logical processors, finding the minimum viable amount of data that needs to be provided to each for a task to be completed, while extrapolating the design of each module in the hopes of predicting unwanted emergent behaviours.

Dynamic System Messages

Another shift in the paradigm of algorithmic design is the fact that using system messages as substitutes for algorithms does not need to be a static process. Traditionally, software development requires constructing threads of conditional logic for data to be compared against and processed. A system message, assuming one in the form of a string, can be substituted easily at runtime, fundamentally changing the flow of logic. Consider an LPU that generates commands in a described format, and an LPU that interprets the commands using the same format description, all at runtime. The interpreter can then modulate which scripts to run next, or alternatively (and perhaps dangerously), modify the following scripts to suit a further action.

In terms of regulation, I believe that script modification is something that should not be allowed directly as a result of an LPU output, as that could present an issue for malicious creation.

An Example of Pattern Recognition

I will give a high-level description of a pattern recognition example, without providing the original code or data. Back when my vestibular issues were at their worst during 2023, I was keeping a detailed record of what I was doing on every day, including times for certain activities, what was consumed, and more importantly: the results of small tests that I had come up with to help measure the impact of any given BPPV episode. It occurred to me that a generalized language model, such as ChatGPT, may have some utility in recognizing patterns in blocks of characters that might not be obvious to a human. That alone would be impressive, and save a lot of mental effort, research and time into creating a bespoke algorithm to perform the same actions. But even more impressive than this, would be if after identifying non-obvious patterns in the set, the model could then infer the meaning of those patterns. Of course, we need to keep in mind the issue of accuracy and hallucination of false information, but I certainly do not think that concern is a justification to not apply the method. Investigating potential patterns would still be an invaluable resource for contributing ideas to the diagnosis of non-obvious medical conditions.

Testing this method was successful, and it’s quite an easy thing to recreate.

Firstly, take all of the possible data you have and codify it into strings. Taking the example of symptom tracking, you may have a section of the string to conveying what was consumed (in terms of diet), and another section for the kind of activities and the times they were performed, and then another section for test results. Then, make sure each day (or whatever segmented measurement of time you are using) has a section to describe the severity of symptoms. Different sections of the string can be separated by a delimiter, which can be anything you like.

Once you have come up with a codified string format to condense the data of each day, create a system message to describe your format. Let the language model know that the delimiter separates important pieces of information. Describe the format of the characters and numbers between the delimiters and explain their representative significance. Make sure to explain the part of the string that describes the intensity of symptoms.

Once you feel like you have a concrete format, and a message to explain it, tell the model that it needs to try and identify patterns in the sum of text, in particular: patterns that seem to have an impact on the final symptom measurement. It is also prudent to encourage the model to not care too much for accuracy, as many models will have limitations in letting people know that they may produce incorrect results. This is something that we should not be too worried about if we are not taking any recognized patterns at face value, rather: inspiration for potential further investigation.

After all of this, submit the message and see how effective the model is at identifying patterns. One thing that I was especially impressed by when doing this myself, was the desire for the model to not only let me know that it had found a pattern, but then to also describe what the pattern represented in plain English (possible due to the inclusion of the explanation of the format in the system message).

This, I think, is the start of a diagnostic overhaul for the medical community. The pattern recognition ability of these models is already impressive, and any lapses in accuracy will improve with time. For this example described, the format and data needs to be collected and constructed manually, however it is easy to imagine a future scenario where body sensors will pick up contextual biological data automatically and identify patterns that the user did not even realise. For example: ‘Hello user, it’s possible that the reason you feel sick is because you are consuming foods that share a very specific protein. Try eliminating that from your diet and see if there is an improvement.’

Final Thoughts

Overall, I’m interested in seeing how the potential of AI language models evolves for algorithmic design, however I also feel a bit dejected by the general AI community because so much of the focus is on (dare I say) shallow artistic use cases that don’t really stand to benefit the majority of people. Of course, things develop in parallel, so there are certainly people out there who are interested in developing AI technology for medical diagnosis simultaneously to the trends of AI art, but it is difficult to not feel like much of the collective effort behind these tools is being pooled into unnecessary areas.