In the , building Machine Learning models was a skill only data scientists with knowledge of Python could master. However, low-code AI platforms have made things much easier now.
Anyone can now directly make a model, link it to data, and publish it as a web service with just a few clicks. Marketers can now develop customer segmentation models, user support teams can implement chatbots, and product managers can automate the process of predicting sales without having to write code.
Even so, this simplicity has its downsides.
A False Start at Scale
When a mid-sized e-commerce company introduced its first machine learning model, it went for the quickest route: a low-code platform. The data team quickly built a product recommendation model with Microsoft Azure ML Designer. There was no need for coding or a complicated setup, and the model was up and running in only a few days.
When staged, it did well, recommending relevant products and maintaining user interest. However, when 100,000 people used the app, it faced problems. Response times tripled. Recommendations were only shown twice, or they did not appear at all. Eventually, the system crashed.
The issue wasn’t the model that was being used. It was the platform.
Azure ML Designer and AWS SageMaker Canvas are designed to operate fast. Thanks to their easy-to-use drag-and-drop tools, anyone can use machine learning. However, the simplicity that makes them easy to work with also covers their weaknesses. Tools that start as simple prototypes fail when they are put into high-traffic production, and this happens due to their structure.
The Illusion of Simplicity
Low-code AI tools are promoted to people who are not technology experts. They take care of the complex parts of data preparation, feature creation, training the model, and using it. Azure ML Designer makes it very quickly possible for users to import data, build a model pipeline, and deploy the pipeline as a web service.
However, having an abstract idea is both positive and negative.
Resource Management: Limited and Invisible
Most low-code platforms run models on pre-set compute environments. The amount of CPU, GPU, and memory that users can access is not adjustable. These limits work well in most cases, but they become a problem when there is a surge in traffic.
An educational technology platform using AWS SageMaker Canvas created a model that could classify student responses as they were submitted. During testing, it performed perfectly. Yet, as the number of users reached 50,000, the model’s API endpoint failed. It was found that the model was being run on a basic compute instance, and the only solution to upgrade it was to rebuild all the workflows.
State Management: Hidden but Dangerous
Because low-code platforms keep the model state between sessions, they are fast for testing but can be risky in real-life use.
A chatbot for retail was created in Azure ML Designer so that user data would be maintained during each session. While testing, I felt that the experience was made just for me. However, in the production environment, users started receiving messages that were meant for someone else. The issue? It stored information about the user’s session, so each user would be treated as a continuation of the one before.
Limited Monitoring: Blindfolded at Scale
Low-code systems give basic results, such as accuracy, AUC, or F1 score, but these are measures for testing, not for running the system. It is only after incidents that teams discover that they cannot track what is essential in the production environment.
A logistics startup implemented a demand forecasting model using Azure ML Designer to help with route optimization. All was good until the holidays arrived, and the requests increased. Customers complained of slow responses, but the team could not see how long the API took to respond or find the cause of the errors. The model could not be opened up to see how it worked.
Scalable vs. Non-Scalable Low-Code Pipeline (Image by author)
Why Low-Code Models Have Trouble Handling Large Projects
Low-code AI systems cannot be scaled, as they lack the key components of strong machine learning systems. They are popular because they are fast, but this comes with a price: the loss of control.
1. Resource Limits Become Bottlenecks
Low-code models are used in environments that have set limits on computing resources. As time passes and more people use them, the system slows down or even crashes. If a model has to deal with a lot of traffic, these constraints will likely cause significant problems.
2. Hidden State Creates Unpredictability
State management is usually not something you must consider in low-code platforms. The values of variables are not lost from one session to another for the user. It is suitable for testing, but it becomes disorganised once multiple users employ the system simultaneously.
3. Poor Observability Blocks Debugging
Low-code platforms give basic information (such as accuracy and F1 score) but do not support monitoring the production environment. Teams cannot see API latency, how resources are used, or how the data is input. It is not possible to detect the issues that arise.
Low-Code AI Scaling Risks – A Layered View (Image by author)
A list of factors to consider when making low-code models scalable
Low-code does not automatically mean the work is easy, especially if you want to grow. It is essential to remember Scalability from the beginning when making an ML system with low-code tools.
1. Think about scalability when you first start designing the system.
- You can use services that provide auto-scaling, such as Azure Kubernetes Service in Azure ML and SageMaker Pipelines in AWS.
- Avoid default compute environments. Go for instances that can handle more memory and CPU as needed.
2. Isolate State Management
- To use session-based models like chatbots, ensure user data is cleared after every session.
- Ensure that web services handle each request independently, so they do not pass on information accidentally.
3. Watch production numbers as well as model numbers.
- Monitor your API’s response time, the number of requests that fail, and the resources the application uses.
- Use PSI and KS-Score to find out when the inputs to your system are not standard.
- Focus on the business’s results, not only on the technical numbers (conversion rates and sales impact).
4. Implement Load Balancing and Auto-Scaling
- Place your models as managed endpoints with the help of load balancers (Azure Kubernetes or AWS ELB).
- You can set auto-scaling guidelines depending on CPU load, number of requests, or latency.
5. Version and Test Models Continuously
- Make sure that every model is given a new version every time it is changed. Before releasing a new version to the public, it should be checked in staging.
- Perform A/B testing to check how the model works without upsetting the users.
When Low-Code Models Work Well
- Low-code tools do not have any significant flaws. They are powerful for:
- Rapid prototyping means giving priority to speed over stable results.
- Analytics that are done inside the system, where the potential for failure is minimal.
- Simple software is valuable in schools since it speeds up the learning process.
A group of people at a healthcare startup built a model using AWS SageMaker Canvas to catch medical billing errors. The model was created just for internal reporting, so it didn’t need to scale up and could easily be used. It was a perfect case for using low-code.
Conclusion
Low-code AI platforms provide instant intelligence, as they do not require any coding. However, when the business grows, its faults are revealed. Some issues are insufficient resources, information seeping out, and limited visibility. These issues cannot be solved just by making a few clicks. They are architectural issues.
When beginning a low-code AI project, consider whether it will be used as a prototype or a marketable product. If the latter, low-code should only be your initial tool, not the final solution.
Source link
#Automation #Trap #LowCode #Models #Fail #Scale
