ML-platform: the common good or better not (AI column)

I saw it. curious My colleagues on the ML platform. I love both ML and platform engineering, and there was a combo, so I couldn't pass up this issue of Yellow AI Club Talks. It involves two people: Daniil Gavrilov – Lead, Head of the Research Team

• Mikhail Chebakov - Guest, Head of ML Platform Development

Here are the main interview ideas 1. ML Platform Philosophy Michael introduced the concept of the ideal ML platform through the metaphor of sewerage – it should be invisible to work, but critical to function. The platform should encapsulate the operating costs associated with scaling, providing resources, monitoring and ensuring fault tolerance, allowing developers to focus on the core work. 2. Evolution of the platform The development of the ML platform in T-Bank began with a classic problem – a cluster of servers with SSH access, which ceased to cope with the growing needs of teams. The first solution was the introduction of a simple orchestrator, which increased the utilization of servers. 3. The most important function According to Mikhail, the key feature of the platform was the ability to manage data – creating folders accessible from anywhere in the cluster, with automatic backup. This feature allows teams to easily process non-standard data, generate intermediate artifacts, and transfer work between clusters. 4. Problems with user experience Misha gave an example of a feature where users asked to add folders to organize their work. The guys thought and came up with the most general system of organization of work through labels - the solution turned out to be technically correct. Through label filtering, it was possible to make any representations, but it was not user friendly from the point of discovery of this feature, as well as further in the process of use. As a result, Mikhail stressed the importance of creating an intuitive interface where functionality can be found without studying documentation. 5. Resistance to the Platform Many developers prefer to work through SSH because of the sense of control, process transparency and compatibility with most open-source projects. However, this approach creates problems with reproducibility, data loss and scaling. 6. Three Key ML Platform Domains

• Engineering experience Interactive work of one developer with a minimum feedback cycle
• Production conveyors Automation of established processes with an emphasis on reproducibility
• Deployment and operation Ensuring the effectiveness and usefulness of ready-made solutions 7. Design principles The basic principle is to make the right ways simple and the wrong ones difficult. This prevents errors and guides users towards optimal solutions. 8. Methods for assessing effectiveness Basic metrics: number of users, teams, retention Regular surveys and satisfaction measurements Dogfood – using the platform for its own internal platform development tasks Close interaction with teams in co-development mode 9. Diversity of ML Directions The platform serves ten different areas: R&D, RecSys, CV, image generation, LLMs, applied NLP, antifraud, risk scoring, speech recognition and synthesis. Each direction has unique requirements for data, reproducibility and equipment. 10. Vision of the future Mikhail sees the ideal future of the platform in the full playback of the experience with SSH servers, but with the advantages of a platform approach – all the necessary functions should be available out of the box without the need to study documentation.

The key challenge is that the platform development team works as a “second derivative” of the product – they create tools for the technologies that are then used to build the products. This requires constant monitoring of industrial trends and advanced functional development.

#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops #DistributedSystems