This article opens a new series here on the blog, and it has an ambitious destination: building a vulnerable code detector using transformers, the same technology behind ChatGPT, with everything running on .NET. Machine learning meeting information security, two subjects I love, in a project anyone will be able to follow.
But hold on. The transformer is the final chapter of this story, and starting there would be skipping too many steps. The standard here on the blog is explaining things in the simplest way I can, so that anyone can follow, even someone who has never programmed. So in this first article we go to the foundation of it all: what on earth is machine learning?
And let me answer right away a question every .NET dev asks themselves: "will I need to learn Python?". No. The Python ecosystem is the standard of the field and deserves all the respect, but the .NET world has its own path for machine learning, mature and maintained by Microsoft, and that is the path this whole series will walk. I'll get there at the end of the article.
Regular programming vs. machine learning
All the programming you know works like this: the programmer writes the rules, the computer receives the data, and the output is the answers. A classic example: I write the rule "if the purchase is above $500 and the card is new, block it", the system receives the purchases (data) and produces the decisions (answers).
Machine learning flips the game: you give the computer the data and the answers, and it figures out the rules on its own. I show it thousands of purchases already marked as "fraud" or "legitimate", and the machine learns the patterns that separate one from the other. Patterns that, quite often, no human could write by hand, because they involve dozens of variables combining in subtle ways.
The best analogy I know is teaching a child to recognize a dog. You don't sit down with her and explain "a dog is a four-legged mammal with an elongated snout and a tail". You point: "look, a dog!", "that one is also a dog!", "no, that one is a cat". After a few months of examples, the child recognizes even breeds she has never seen. She didn't memorize rules, she learned the pattern. Machine learning is that, at industrial scale.
The three ways a machine can learn
Supervised learning: the child-and-dog one. You hand over labeled examples ("this is spam", "this is not") and the machine learns to label new examples. Of the three types, it is the champion in the industry: the overwhelming majority of ML systems in production work this way. And it is also the one we will use throughout this series: in the end, the labels will be "vulnerable code" and "safe code".
Unsupervised learning: you hand over the data with no labels at all and ask the machine to find structure in it. "Here are my 10 thousand customers, group the similar ones." You didn't say what to look for, and it discovers that there are, say, four behavior profiles. Useful for exploration, segmentation, anomaly detection.
Reinforcement learning: the machine learns by trial and error, earning a reward when it gets things right. It's like training a dog with treats, and it is how AIs learn to play chess better than any human. Fascinating, but outside our path in this series.
The vocabulary you need (and nothing more)
Four terms, because they will show up in the next articles:
Features: the characteristics the machine looks at. In the fraud example: purchase amount, time of day, age of the card. Choosing good features is half the work in ML.
Model: the result of the learning. It is a file, literally. After seeing thousands of examples, the learned patterns get recorded in that file, and using the model means asking it a question: "and this one, is it fraud?".
Training and testing: you never evaluate the machine with the same examples you used to teach it. You set aside a part of the data it has never seen and measure performance there. It's the final exam with brand-new questions.
Overfitting: villain number one. It's when the model memorizes instead of learning. Think of that student who memorized all the past exams: top grade on the mock test, disaster on the new exam. An overfitted model gets everything right in training and fails badly in the real world. A good part of ML engineering exists to prevent this.
And where does .NET come into this story?
As promised. What few people know is that the .NET world has its own machine learning arsenal, and it truly delivers:
ML.NET is the official machine learning framework for .NET. It trains classification, regression, recommendation and anomaly detection models, all in C#, running locally, without calling anyone's API. Your model becomes a file that your ASP.NET application loads and queries in milliseconds.
TorchSharp is PyTorch (the most used deep learning library in the world) dressed in .NET clothes. When the subject is deep neural networks, it's the one. I use it, actually: there is a neural network trained in C# running in my confidential project, the same one from the previous articles. But that's a subject for another day.
ONNX completes the arsenal. It is an open model format, a kind of "PDF for ML models": train anywhere, export to ONNX, run anywhere, including inside a .NET application. In this series we are going to train and run everything directly in C#, so it stays at the introduction stage, but it's a name worth knowing: it is what usually takes models from research into production.
Being honest, as always: if your goal is cutting-edge ML research, Python remains the center of the universe. But if your goal is to use ML for real inside .NET systems, with deployment, tests and CI done properly, you already have everything at home. And for those who build everything in .NET, not needing a second ecosystem just to run a model is a huge advantage.
Where this series goes
This is just the first step. In the next articles we will move forward little by little: understanding how the models evolved until they reached the transformers, meeting the AIs that were trained to read source code and, in the end, getting our hands dirty and building the vulnerable code detector, all in .NET. The journey continues in the next article: the story of how machines learned to read. See you there.