# No Python, No PhD: Train Real ML Models in C# with ML.NET (Regression, Classification, Clustering) > Source: > Published: 2026-09-17 19:08:04+00:00 Mattrx ran its predictive features on a Python scikit-learn microservice for two years. We replaced it with **ML.NET running in-process** inside the existing .NET 9 app — and trained real regression, classification, and clustering models in C# with no separate service, no second language in production, and no implementing gradient descent by hand. If you're a .NET team that "does ML" by shipping a Python sidecar, you're paying a tax most teams never question: a second runtime, a second deploy pipeline, a second on-call surface, a cross-process hop on every prediction, and a data contract that drifts between two languages. For **classical** ML — regression, classification, clustering — you usually don't need any of it. | Dimension | Before (Python sidecar) | After (ML.NET in-process) | |---|---|---| | Languages in production | C# **and** Python | **C# only** | | Deploy pipelines | 2 | **1** | | Prediction path | HTTP to Flask -> scikit-learn | **in-memory call** | | Prediction p95 | 45 ms | **2.8 ms** | | Model artifact | pickle in a container image | **2 MB .zip, loaded by the app** | | On-call surface | app + ML service | **app only** | | Infra cost | +$160/mo for the ML service | **$0 (decommissioned)** | The reason .NET teams reach for Python isn't the models — it's a belief that "real ML needs Python and a math background." For deep-learning research, fair. For the bread-and-butter business ML that 90% of products ship — *predict a number, predict a category, group similar things* — it's not true. **You don't implement algorithms; you compose a pipeline.** You describe `data -> transforms -> trainer -> metrics`, call `Fit()`, call `Evaluate()`. You never write gradient descent, a tree split, or a k-means iteration. The skill that matters is **data preparation and honest evaluation** — and that's language-agnostic. ``` js var pipeline = ml.Transforms.Categorical.OneHotEncoding("ChannelEnc", "Channel") .Append(ml.Transforms.Categorical.OneHotEncoding("VerticalEnc", "Vertical")) .Append(ml.Transforms.Concatenate("Features", "Impressions", "Week1Clicks", "AudienceSize", "ChannelEnc", "VerticalEnc")) .Append(ml.Transforms.NormalizeMinMax("Features")) .Append(ml.Regression.Trainers.FastTree(labelColumnName: "Label", featureColumnName: "Features")); ITransformer model = pipeline.Fit(split.TrainSet); var metrics = ml.Regression.Evaluate(model.Transform(split.TestSet)); ``` `FastTree` is the gradient-boosted tree trainer — you just *select* it. **Result:** R² **0.78**, RMSE **41** on campaigns averaging ~600 conversions. Same accuracy band as the old scikit-learn model, now with no service to call. The catch every real churn model hits: **class imbalance**. Most tenants don't churn, so a model that always predicts "no" looks 94% accurate and is useless. Evaluate on AUC / precision / recall — **never** raw accuracy. ``` js var m = ml.BinaryClassification.Evaluate(model.Transform(split.TestSet)); // AUC, PositivePrecision, PositiveRecall, F1 // CS can only call ~30 tenants/week -> tune the threshold for PRECISION: bool flag = prediction.Probability >= 0.62; // from the PR curve, not 0.5 ``` **Result:** AUC **0.86**, precision **0.71** at the threshold CS actually works. The weekly at-risk list is model-ranked instead of a brittle `if`. ``` js var pipeline = ml.Transforms.Concatenate("Features", "CampaignsPerMonth", "AvgAudienceSize", "ReportDownloads", "SeatUtilization", "ApiCallsPerDay") .Append(ml.Transforms.NormalizeMinMax("Features")) // critical: k-means is scale-sensitive .Append(ml.Clustering.Trainers.KMeans("Features", numberOfClusters: 5)); ``` **Result:** **5 clusters**, silhouette **0.52** — distinct enough the product team named them ("power users," "dormant SMBs," "report-only"). The old size-based SQL never surfaced "report-only," a high-churn group hiding inside "enterprise." A trained `ITransformer` is not thread-safe to predict from directly. Use `PredictionEnginePool` — thread-safe, fast, hot-reloadable: ``` builder.Services.AddPredictionEnginePool() .FromFile(modelName: "churn", filePath: "Models/churn.zip", watchForChanges: true); ``` The nightly retrain job trains, evaluates, and **gates** on a metric floor before swapping the file — never ship a regression: ``` if (auc >= 0.80) ml.Model.Save(model, trainSet.Schema, "Models/churn.zip"); // pool hot-reloads ``` **Result:** prediction p95 **45 ms -> 2.8 ms**, zero-downtime model promotion. Catching one leaked feature (a `final_invoice_flag` that only existed *after* churn) dropped offline AUC from a too-good **0.97** to an honest **0.86** — and the honest model is the one that works on live tenants. Every feature must be knowable at prediction time. A suspiciously high AUC is a leak until proven otherwise. Deep learning, transformers, LLMs, computer vision belong in Python (or an API) — ML.NET can consume an ONNX model but won't train a state-of-the-art net. If your data scientists live in Python daily, don't fight that. ML.NET wins when the **engineering team** owns the model and the problem is classical. **Classical ML is data engineering with an evaluation step — pick the language your app is already in.** Regression, classification, and clustering are `data -> transforms -> trainer -> metrics`. ML.NET gives a .NET team all four in C#, in-process, with no second runtime to operate. The full guide has the before/after architecture diagrams, every pipeline in full, the trainer cheat-sheet, the pre-ship checklist, and the aggregate Mattrx metrics: [https://prepstack.co.in/blog/no-python-no-phd-train-ml-models-csharp-mlnet](https://prepstack.co.in/blog/no-python-no-phd-train-ml-models-csharp-mlnet) *Originally published on [PrepStack](https://prepstack.co.in/blog/no-python-no-phd-train-ml-models-csharp-mlnet).*