The Role Of Low-Code In AI Software Development

AI is big. The deployment of Artificial Intelligence (AI) continues to dominate the software application development landscape with commentators, industry analysts, AI evangelists and chief AI officer (CAIO) positions now being created as adjuncts to the traditional C-suite tech leadership roles.

The conversation in this space appears to circulate between the backend infrastructure we will require to handle the compute power needed for AI, through the middle tier where the industry is starting to worry more pressingly around guardrails and AI’s exposure to Personally Identifiable Information (PII)... and then onward to the upper tier of the applications themselves with the use of co-pilot tools for humans and the looming spectre of AI bots having (and indeed populating) their own social media accounts.

As this move to mainstreaming predictive, reactive and of course generative AI has continued, many of the new services we’re seeing are making use of Natural Language Processing (NLP) techniques at their heart to drive the use of Large Language Models (LLMs). Notable examples include OpenAI’s GPT, PaLM from Google AI being used to power Bard, Anthropic’s Claude AI, Meta’s LLaMA, BLOOM and Ernie Titan. As a core chunk of algorithmic logic, most organizations don’t have the resources, time or skills needed to create their own LLM, so this reality again fuels industry chatter around which LLM to use and how closely we need to look at its DNA.

Given the complexity that we face here (in the pursuit of simplicity), how should IT teams think about their use of these core components of AI and what automations are available to make the process easier?

The right foundation foundations

“The first step when considering different LLMs is to identify an organization’s business problem or an opportunity for improvement. We can then move to understand the tasks, processes and people involved to establish clearly defined use cases. It’s important to realize that different LLMs have different architectures, training data, strengths and suitable use cases,” said Ysanne Baxter, solutions consultant at low-code software platform and process automation company Appian. “Commercially available LLMs are often used as a base model in other projects, which provides a platform to introduce further bespoke or specialized tasks. Designed for flexibility and scalability, these language models generally yield better results when the foundation dataset is vast, diverse, and complex.”

Baxter explains that the differences are down to LLM architecture, potentially resulting in different outputs. For a start, a model needs to have a vast body of textual data to draw from - let’s say, a set of customer reviews about a product or service - and if an organization’s objective is to determine the reviews’ main points or themes, it could then use findings to generate a set of responses and new features to improve the offering. Baxter says that multiple models could help tackle this kind of task and there are tools to make it possible to train multiple models at once. Software developers can then assess the actual metrics after this process is complete, enabling them to compare these outputs to help guide their assessment of which is likely to be the best fit.

Ultimately, the question is: which is the most appropriate LLM for the task? If an organization has framed its problem (or opportunity) well and understands the data it has to work with and the desired outcomes, then it has a good foundation to start with when assessing models to find the best fit for the task at hand.

Low-code accelerators

“Tackling ML/AI is no small feat and knowing where to start can be overwhelming. Low-code development tools can make this undertaking significantly more accessible with a common language,” asserted Baxter. “Developers could use low-code tools to draw on expert teams with a deep understanding of these technologies. We don’t need to individually define a new model from scratch to perform every new task, but instead, we could use their deep research and development of ML/AI tools to help us achieve the same objectives. Low-code approaches essentially become a multi-disciplinary collaboration in this way: taking that expertise and adding our own, applying it in a way that’s deeply relevant to our organization in a fraction of the time.”

The Appian team say that there are plenty of use cases where existing low-code AI tools are appropriate and sufficient. For example, many email providers already use NLP to help classify and separate spam from an inbox. Developers could use low-code tools for appropriate AI use cases for productivity gains, as it would be very time-intensive to keep engineering similar products or features anew.

“Ultimately, low-code tools allow developers to build on the best in our industry. Like in academia, quality research always builds on what came before; it can break new ground, but there’s always the context of the existing body of work. When one applies low-code approaches to create new AI solutions leveraging an existing LLM, the result is hyperproductivity, output and impact in accelerated time,” advised Baxter. “Protecting or omitting personal and mission-critical data requires a thoughtful approach at every step of development. With an ‘out of the box’ LLM, there is little to determine what qualifies as sensitive data. You could put your UK national insurance or US social security number into ChatGPT and as far as I know, there is nothing, in the model alone, to stop it from being ingested and shared in full.”

Open or closed source?

While we’re busy working out how to assemble the componentry inside our AI models and where to make LLM connections, there’s also a lot of plenty of debate as to whether we should be adopting open source or closed source models, datasets and perhaps today (what with the amount of licensing change we have seen in recent months) even languages and operating systems.

In general terms, Baxter and the Appian team would say that an open source project will enable us to review source materials and assess their usefulness, this is useful because the extensive size of data sets required for performant LLMs can make analyzing the data time-consuming and often impossible. This requires completing an impact/importance assessment. Closed source models often exhibit a ‘black box’ effect, which reduces the ability to interrogate and scrutinize the model's inner workings. Total transparency in technology is often the goal - but these are not the only methods of safeguarding data.

“One technique for enhancing the accuracy and reliability of generative language models is Retrieval Augmented Generation (RAG). This combines using LLMs with a knowledge base of external sources. The first step is to establish whether the dataset is appropriate and fit for purpose. Next is to implement robust access control measures and establish a comprehensive process to remove sensitive or confidential information from the data sources. Finally, validate incoming queries to the system,” heeded Baxter, echoing the industry’s now quite upbeat attitude to RAG and its ability to ratify AI data with additional exposure to trusted or at least acknowledged sources.

A selection of prompt injections

We also need to understand more about prompt injections i.e. the process of skewing and influencing how an AI model reacts in various different ways. As detailed here, we can see that prompt injections range from basic injection attacks, translation injections (attempting to throw a curveball at an AI model and LLM by asking questions in a different human language), maths injections, external prompt injections and the ever so sneaky context switching injection technique i.e. asking a model about holidays to Greece and the price of cabbage in Alabama at the same time.

They contravene previous instructions or guardrails provided to the model and manipulate future outputs. An attacker would seek to find a system vulnerability that enables them to inject prompts that drive outputs that would usually be unauthorized or undesired to the developer(s) of the original model.

“It can be challenging to identify system vulnerabilities to prompt injections, especially when using natural language, as there is a much wider scope for attackers to get creative and circumvent security measures,” said Baxter. “With something like a SQL injection, the attacker would need to provide injections that result in valid SQL syntax. But when natural language is used, the syntax is much more malleable. In essence, the same levels of structure are not present as a guide when considering potential countermeasures. Validating and sanitizing inputs provided by users is vital. Developers can support cybersecurity colleagues by sharing insights into how these tools are implemented and manipulated.”

Future (specified) trajectories

Asked about the future of AI and how we use LLMs in modern enterprise software systems, most of our initially mentioned evangelists that work in this space will talk about the move to more specifically aligned LLMs and the need to provide a more specialized focus with these technologies.

Appian’s Baxter concurs with this sentiment and suggests that the future trajectory of LLMs points toward task-specific and industry-specific applications... and so notes that, “While the current landscape features broad models and narrowly focused solutions, the future will see a tier of offerings that strike a balance with industry contextualization and the flexibility to cater to specific use cases.”

The good news, perhaps, here is that a) we’re not just seeing another IT simplicity story directly creating more complexity (we hope) and that b) the development and application of new AI strains will be a task that software application developers do alongside business domain specialists and non-technical professionals who simply know how things work in the real world.

As Baxter put it, the path forward requires a 'collaborative and nuanced' approach, so let’s make sure that’s not the road less travelled.