How innovations from the fields of AI and Machine Learning can be transferred.
After a two-year break due to corona, minds mastering machines (m3), a conference on machine learning and artificial intelligence, was able to return to presence this year. We were also present at Haus der Wirtschaft in Karlsruhe from June 1 to 3, the third participation of our colleagues at the event. In the following article, Hendrik Hilleckes and Axel Bohnet each present three talks, which are a mix of concrete use cases, practical tips and future topics.
AI at the Crime Scene
m3 conference came to a close on the second day with an exciting presentation entitled “AI at the Crime Scene” by Martin Schiele. And although we had only hoped for an insight into a completely different use case, the topic ended up being of astonishing relevance to the world of logistics. That’s often the way it is in the field of machine learning or optimization: solutions to certain problems can be transferred relatively easily to completely different use cases. This is where the term “transfer learning” comes from. Here, models that have already been trained are used as a basis for another problem case and trained to the end with its training data. In the presented use case, the task was to recognize fibers, blood, glass, sand or skin on high-resolution images.
For this purpose, many test images were manually annotated. Subsequently, an existing machine learning model was further trained with these images (transfer learning). After several iteration stages, it can now already recognize the learned objects very well. The method presented in this talk is also interesting for our counting app. Because here, too, we can use Transfer Learning to recognize several objects of the same type (pipes, tree trunks, racks, vehicles, …) on one image and count them automatically. In this way, we can capture large quantities of objects automatically and in a matter of seconds, and in turn make sense of the number for downstream processes such as loading.
Data Mesh is a buzzword in the field of Big Data. Matthias Niehoff’s presentation explained what exactly it means. Even if it is marketed differently in the media, data mesh is not a technology, but rather a way of thinking or an organizational approach. The classic data infrastructure of the last decades was based on a central data warehouse, which then feeds analytical tools with data.
The source systems are connected via very individual ETL processes (“extract-transform-load”). A central data team takes care of the entire process. This team is very knowledgeable about data management, but usually has no interest in the actual data. As a result, the ramp-up of a new data source is often very time-consuming. The data team is overloaded, there is no standard and the project team that is supposed to provide the data does not have the knowledge or even interest in doing so.
Data Mesh is now a different organizational approach with four core principles. The goal is to provide a self-service platform for the project teams, on which they can then make their data available. For each data set, there is a product owner from the project team. This is because the data should be viewed as a product for other teams. So the core metrics for evaluating a data set should shift away from technical to product-oriented metrics. It should be more important whether a dataset is used and how satisfied users are than the size of the database and the interval of updates. Central governance policies can then be mapped onto the central platform. There should be a catalog of data sets where project teams can quickly identify responsible owners and potential legal or security issues. In summary, the topic of data mesh once again shows that the field of AI cannot be mapped with classic software development and architecture.
In the discussion about artificial intelligence, it is often forgotten that it also enables completely new attack possibilities on systems. On the so-called ATLAS Thread Map, 39 different attack scenarios are listed. In Mirko Ross’ presentation, some of them were outlined and addressed. Of course, some of them are more likely than others. Sensitivity to this issue is also more pronounced in the government sector than in industry. Nonetheless, any company using machine learning should give it some thought. After all, an attack is not always easy to detect. And in some circumstances, the company may not even be attacked directly, but rather bring “poisoned” models or data sets into the company. It is very popular to use pre-trained models in other domains via transfer learning. Here, very close attention must be paid to ensure that the model does not discriminate against certain groups of people, for example. Often these things happen unknowingly in the industry, but it is also conceivable that a malicious actor could gradually edit popular open source datasets or models so that the products derived from them act accordingly.
There are many more examples of machine learning models being tricked. However, this is currently (still?) mostly taking place in the academic field. In the media, though, there are already many reports about successful deceptions of image recognition models. The classic is the panda bear, which is recognized as an ostrich. An image of a turtle can also be manipulated so that the model recognizes it as a rifle. For leogistics as a software provider, it is therefore enormously important that we explain how machine learning models arrive at their results and where their limits are.