4 ms·

If you're doing anything ML related your best bet is to niche down and solve a very narrow problem for a specific industry / market segment. Building generic AI

by m_ke 7y ago

If you're doing anything ML related your best bet is to niche down and solve a very narrow problem for a specific industry / market segment. Building generic AI tooling sounds great but rarely solves anyones problems.

gk1 7y ago
Agreed. One of the possible differentiators I list in the article is being an "end-to-end solution." It's going to be a long while before AWS builds AI for accounting, or for optimizing industrial operations, or for... you get it.
- generatorguy 7y ago
  I have yet to hear of an example of a factory or plant using AI for optimizing industrial operations. Anybody known of any?
  - mttddd 7y ago
    I imagine there are some, a lot of factory operation optimization uses heavy operations research which isnt a huge jump to some sort of AI/ML
  - digsy 7y ago
    https://nordcloud.com/10-examples-of-ai-in-manufacturing-to-inspire-your-smart-factory/ https://nordcloud.com/10-examples-of-ai-in-manufacturing-to-...
lostmsu 7y ago
Interesting, as I went down this route: made a niche ML product, and did not open source. As it is a framework-level library, I also think quite a bit of time will pass before AWS or Azure will even notice the opportunity, because you need to be technical to see it. Actually, Azure already has ML.NET, but it is about classical machine learning, and their own deep learning product, CNTK, lost the marketing fight with TensorFlow and PyTorch. Which is where I come in :)
mlthoughts2018 7y ago
As an ML practitioner in a large ecommerce company, I totally agree. When I evaluate third party tools, 99% have no use at all for me. Things like Algolia or Rekognition or Clarifai. Even Sagemaker and Fargate are mostly not useful to me as my company can easily operate its own k8s platform. Open source tools for model building are great and a small team of engineers can write whatever odds & ends that aren’t covered, or make scalable implementations. Notebook platforms like Databricks are similarly useless. A notebook is not a frontend to a cluster and notebooks are universally poor development environments even for the very tasks they are advertised. The main thing that matters for ML development is how quickly & easily you can put an arbitrary container or VM into a deployment environment. You’re always going to need to rapidly change your container or VM, have common ancestors that get specialized to support GPU training or some web server application layer. Making the shortest possible distance between the definition of this environment and deployment of it is the whole game. The type of tools I’m willing to pay for are specialized database engines, rapid data annotation tools, and specialized hardware environments. I have no time for some “platform” tool for data provenance, notebook environments, model tracking, model-as-a-service APIs like Rekognition, or anything where I upload data and get back a model.
- ordx 7y ago
  How do you train your models? With Databricks (which is just a nice notebook UI for Apache Spark) I don't have to spend time setting up VMs and libraries for the distributed training.
  - mlthoughts2018 7y ago
    Your first sentence seems unrelated to your second sentence, but it seems like you think they are related? Any platform that advertises something like you don’t have to spend time defining your training environment, whether it’s Databricks or an out of the box deep learning VM on GCP, is a liability waiting to happen. You always need to define your own training environment, especially because you’ll almost always need specific (likely pinned) versions of all your dependencies, including system dependencies, to manage model training as part of a production life cycle. Very often you also need e.g. custom compiled TensorFlow, custom GPU settings or drivers, etc. It’s very foolish to base that environment on whatever comes out of the box. Spark also is not universally useful. For training small models many times, like a workload that trains hundreds of small models all day (this was a production use case I had before that my company pilot tested with Databricks), the overhead of Py4J connector is insanely bad. It’s a really terrible paradigm for Python software, meanwhile Scala is a miserable ecosystem for production machine learning models. On top of all this, Spark MLib has huge gaps in functionality and whole classes of problems (e.g. large scale MCMC inference) are not solvable in a way in Spark that is seriously comparable to other tools like STAN & pymc running on not-Spark with simple multiprocessing.

by m_ke 7y ago

gk1 7y ago

Agreed. One of the possible differentiators I list in the article is being an "end-to-end solution." It's going to be a long while before AWS builds AI for accounting, or for optimizing industrial operations, or for... you get it.

generatorguy 7y ago
I have yet to hear of an example of a factory or plant using AI for optimizing industrial operations. Anybody known of any?
- mttddd 7y ago
  I imagine there are some, a lot of factory operation optimization uses heavy operations research which isnt a huge jump to some sort of AI/ML
- digsy 7y ago
  https://nordcloud.com/10-examples-of-ai-in-manufacturing-to-inspire-your-smart-factory/ https://nordcloud.com/10-examples-of-ai-in-manufacturing-to-...

lostmsu 7y ago

Interesting, as I went down this route: made a niche ML product, and did not open source. As it is a framework-level library, I also think quite a bit of time will pass before AWS or Azure will even notice the opportunity, because you need to be technical to see it. Actually, Azure already has ML.NET, but it is about classical machine learning, and their own deep learning product, CNTK, lost the marketing fight with TensorFlow and PyTorch. Which is where I come in :)

mlthoughts2018 7y ago

As an ML practitioner in a large ecommerce company, I totally agree. When I evaluate third party tools, 99% have no use at all for me. Things like Algolia or Rekognition or Clarifai. Even Sagemaker and Fargate are mostly not useful to me as my company can easily operate its own k8s platform. Open source tools for model building are great and a small team of engineers can write whatever odds & ends that aren’t covered, or make scalable implementations. Notebook platforms like Databricks are similarly useless. A notebook is not a frontend to a cluster and notebooks are universally poor development environments even for the very tasks they are advertised. The main thing that matters for ML development is how quickly & easily you can put an arbitrary container or VM into a deployment environment. You’re always going to need to rapidly change your container or VM, have common ancestors that get specialized to support GPU training or some web server application layer. Making the shortest possible distance between the definition of this environment and deployment of it is the whole game. The type of tools I’m willing to pay for are specialized database engines, rapid data annotation tools, and specialized hardware environments. I have no time for some “platform” tool for data provenance, notebook environments, model tracking, model-as-a-service APIs like Rekognition, or anything where I upload data and get back a model.

ordx 7y ago
How do you train your models? With Databricks (which is just a nice notebook UI for Apache Spark) I don't have to spend time setting up VMs and libraries for the distributed training.
- mlthoughts2018 7y ago
  Your first sentence seems unrelated to your second sentence, but it seems like you think they are related? Any platform that advertises something like you don’t have to spend time defining your training environment, whether it’s Databricks or an out of the box deep learning VM on GCP, is a liability waiting to happen. You always need to define your own training environment, especially because you’ll almost always need specific (likely pinned) versions of all your dependencies, including system dependencies, to manage model training as part of a production life cycle. Very often you also need e.g. custom compiled TensorFlow, custom GPU settings or drivers, etc. It’s very foolish to base that environment on whatever comes out of the box. Spark also is not universally useful. For training small models many times, like a workload that trains hundreds of small models all day (this was a production use case I had before that my company pilot tested with Databricks), the overhead of Py4J connector is insanely bad. It’s a really terrible paradigm for Python software, meanwhile Scala is a miserable ecosystem for production machine learning models. On top of all this, Spark MLib has huge gaps in functionality and whole classes of problems (e.g. large scale MCMC inference) are not solvable in a way in Spark that is seriously comparable to other tools like STAN & pymc running on not-Spark with simple multiprocessing.