The Intelligent Application of Machine Learning in Defence

The rapid and dislocating advances in large language models (LLMs) and foundation models over the past three years has dominated the AI and machine learning agenda. I'm not here to debate whether these data and compute driven advances could irreversibly disrupt the world of work as we know it, if algorithms with weights and biases applied can become sentient, or indeed if Bayesian optimisation is a gateway drug to Artificial General Intelligence (AGI). Instead, the purpose of this article is to step aside from the rhetoric and explore what the intelligent application of machine learning looks like for a use case in the domain of Defence and National Security; and explore why language and words matter, why domain expertise matters as much as data, and why working out what you want to achieve is equally important as what tools you choose to select.

It isn’t the intention of this article to dismiss LLMs; and regardless of where you sit on the AI boomer/doomer scale, as a general-purpose tool to enhance routine productivity they are showing substantial promise notwithstanding the potential downsides of any widely adopted, but poorly understood technology that routinely hallucinates. But much of Defence and National Security is unique and outside of routine business process there isn’t much of the general purpose about it.

Foundation Models

To start with language and LLMs. The term foundation model comes from an attempt by the new generation of generative AI companies to appear like their models are a foundational technology upon which a new generation of tools and businesses will be built.  And they (the companies backed with unprecedented levels of investment) could well be right, although I'm not sure the journey will be quite so exponential as their investors might hope.  A cynic might suggest that the only way for capital to get a return on its investment would be to reduce the money companies spend on people to fund an increase in investment in AI.

Companies building foundation models need huge (think of the internet and its associated data as a measure of scale) labelled or self-supervised learning derived data sets, and massive neural networks with millions/billions/trillions of parameters which are the values applied to the algorithms. It's brute force AI.  They are impossible to understand or explain. Alongside these data sets of almost incomprehensible size this approach also needs substantial computer processing capacity and with that the power to run it. Data scientists will tell you that all models are wrong, but some are useful. But to determine how wrong a model is it must show its workings and declare its uncertainty. This is often boiled down to a F-score or F-measure which is a measure of predictive performance. A great means of measuring scientific results but translating an F-score of for example 0.6 (60%) into the real world requires a great deal more, certainly more than a "chain of reasoning" generated by the same models that are telling you the score. Think glass box rather than back box AI. There is a trade-off in foundation models between explainability, trust, speed and accuracy.  Now, all the emphasis in the world of foundation models is on speed and catching the eye, resulting in minimising the attention paid to trust, explainability and accuracy. 

The Customer and their Problems

If the drivers for foundation model usage are massive, labelled or self-supervised learning derived data sets and computing power, then what is appropriate when these components don't exist? Theoretically the principles of a foundation model can be applied to a use case or an environment where there might be no data at all (it hasn't been seen before) or no labelled data (the process of labelling data accurately for the application of machine learning is a challenge in and of itself) but how do you reconcile the inherent risk attached? 

This is where the intelligent application of machine learning becomes more appropriate, starting with the problem.  As has been acknowledged ad infinitum Defence and National Security offers a particular, often peculiar and idiosyncratic challenge at odds with most other walks of life. The stakes are generally higher, the uncertainty and ambiguity are off the scale, and every scenario is likely to be unusual if not unique. For these reasons the humans at the centre of the enterprise tend to be thoughtful, considered and have a mastery of assessing risk and reward at pace. Speed and tempo are essential factors in decision making, especially when trying to operate at a faster pace than your adversary. But it's not pure speed, it's a relative concept which is why the word tempo is so important. Time has different values for a sonar operator working in anti-submarine warfare to a fast jet or drone pilot.  Shaving 30 seconds off the decision-making cycle for the former will make little difference, doing it for the latter could be immense. It's why understanding the workflow of human operators is the first step in understanding how to apply machine learning intelligently. Workflows that have been developed from a combination of hard-won experience and organisational intelligence passed down through the generations. And they tend to accelerate in maturity very rapidly during conflict as the hard feedback loops are so rapid and existential. Understanding the workflow gives a sense of where machine learning could add value, give back time and help make more effective decisions.  

Mission Appropriate Machine Learning

Machine learning, a sub-set of AI, focuses on learning patterns from data and then making predictions without having to be explicitly programmed for each task. It learns from one data set and then applies that learning to new, unseen data sets. Most of the maths underpinning machine learning pre-dates LLMs, by decades in some instances. There are a huge number of different model types to choose from depending on what outcome is needed, the system it must operate in and how it will be used by the operator. The application of machine learning to a live stream of mission data, an area we specialise in, is like tap dancing on a Swiss ball whilst someone is trying to distract you - inherently unstable and prone to unpredictable fluctuations in the environment and with a noisy background. In these instances, big and complex does not equate to good - it's far more effective and useful to break the problem down into bite size chunks and apply a smaller, more performant and explainable model to each step. If a big and complex model powered by data and computing power doesn't work, then it's difficult to diagnose why that is the case. If one part of your model architecture comprising many smaller models working together isn’t performing, then you can fine tune and refine it in isolation confident there won't be unintended consequences elsewhere.

Don't forget LLMs have their mysterious performance, hallucinations and inexplicability as a feature as much as a bug. And when we think about updating and upgrading software every 24 hours in a wartime scenario then having a modular model architecture harnessed by robust and production grade engineering makes that possible. 

Data is another essential component of machine learning. It’s often used as an excuse... “Once we have all of our data in good order then we can really accelerate our adoption of AI”. The chances are your data will never be in good order and that you are collecting new data at a rate that means it becomes a Sisyphean task. Think back to LLMs which rely on huge, labelled data sets. There might be no data at all for what you are looking for, therefore you are asking your model to search for anomalous data that it hasn’t seen before as it has nothing to learn from. You can’t take a data driven approach. This is where taking a step back from the data science is helpful. Domain and problem understanding means you can mitigate for a limited amount of data. How do you encode the domain and environment; is there a difference in propagation in winter or summer, deep water or shallow? What are the underlying characteristics of features of the signals you are looking for and how are they different from the noise; how many components are there that build up a signature and what are they? Careful scoping of both the domain and the fundamental, rather than superficial problem, should dictate the most appropriate way to tackle problems that could use machine learning as part of the solution.

Don’t Over-Index on the Model

At Mind Foundry, our product teams are made up of 60% machine learning engineers, 30% machine learning researchers and 10% product design (how you make machine learning usable). The model/algorithm is only an ingredient in the deployable solution. Adopting and integrating that model in a workflow is an engineering and human factors problem not a model performance one.

Depending on which source you use between 75-90% of AI pilots fail to deliver. One of the key reasons is an over-indexation on the model and an under-appreciation of the amount of engineering and design effort required to integrate and maintain; the closer to the edge and the more challenging the use case, the more these factors become critical to success. Tracking and repairing model drift isn’t a nice to have. A federated architecture to ensure common standards across all models of a similar type can’t be an afterthought. General Omar Bradley is reputed to have said that amateurs talk about strategy and professionals talk logistics. In the world of AI, amateurs talk about models and professionals talk about problems, integration and maintenance.

Think big but start by solving small problems. A hammer is a great tool but not if you want to screw something in. Autonomy is a great concept, but despite what some would tell you there are no shortcuts to autonomous systems that don’t come with substantial downside risk. Intelligent adoption of machine learning is the start of the journey towards automation, and it starts with automating the parts of the system and process that are appropriate.