The base framework comes with a variety of transforms, trainers, utility apis for loading varies forms of data (e.g. csv's, tsv's) to build custom machine learning models trained with your own data.
Using the API you can build a variety of models for scenarios like Sentiment analysis (classification), forecasting, recommendation and also leverage pre-built Tensorflow models for scenarios like image classification.
The samples repo provided shows you a variety of scenarios with ML.NET.
https://github.com/dotnet/machinelearning-samples
@zamalek, would love to learn how we can improve the API to make this stand out :).
ML.NET only has what's in the box, it's turn-key. You guys have an explicit ResNet18 assembly, as one example. While this is incredibly useful, it is not appropriate to call such a library a framework.
A possible improvement would be:
ML.NET is a machine learning API which is aimed at providing turn-key models for infusing ML...
If you wanted it to classify as a framework, you'd have to provide something like Tensorflow does: a way to develop new and novel models.
That's just my opinion, but a few people seem to agree.
It does not lower the value of ML.NET to clearly state that it does not allow building and training tensorflow models, it actually prevents annoyance at having to dig around and figure it out from lack of examples. It should be stated in the readme.md before the installation section.
I'll add that there is very little point in coming onto HN and looking for the community's feedback if you're going to ignore it.
"End-to-end", "workflow", "across X, Y, Z, A", "scenarios". I'd just started to forget that language, but there it is. (The "local dialect" at Microsoft strikes again)
I think the target use case for ML.NET is really putting existing machine learning models into production in .NET. That's not limited to deep learning (it supports "traditional" ML models like logistic regression out of the box), but a first-party wrapper for tensorflow models is useful (which previously required vectorizing everything by hand and passing to TensorflowSharp)
Training vanilla models is "nice to have" but the real value is in putting trained models into production.
Generally speaking, the ML.NET API still needs a lot of work. I think they're partway through switching from a "LearningPipeline" API to a "Data/Transformer/Estimator" API, but some of the documentation refer to the former, some to the latter, some new methods still require legacy classes, the naming conventions aren't clear and not all of it is strongly-typed so you won't know until runtime whether you've passed the correct Transform/Estimator, on the whole it's a bit confusing.
That being said, it still hasn't hit 1.0, so I think the team is aware that the API needs further work. If they standardize 1.0 on the Data/Transformer/Estimator, blow away the legacy classes and update the documentation, it will be a pretty nice framework for production.
this should be exactly the first sentence in the git repository. to confirm the original commenter: this API is mostly for deploying networks, not so much for training/developing new models etc
In startupdiscuss' sense, ML.net would allow building own models if it offers building-blocks, abstractions, and other facilities, for examples, vectors, matrices, tensors, linear algebraic operations, computation-graph, etc that allow building them.
Not that I have done too much ML stuff beyond experimenting, it seems to be Accord.NET is a lot more abstracted compared to TensorFlow...
ML.NET is also extensible, which means we can absorb other leading deep learning frameworks like TensorFlow and Accord.NET through one consistent API providing a uniform way to do ML in .NET.
Here's a link to the samples: https://github.com/dotnet/machinelearning-samples