Deep Learning Is Eating Software
petewarden.com
Deep Learning Is Eating Software
1–10 of 17 posts
Re: Deep Learning Is Eating Software
#2Deep learning is certainly eating conferences, funding and PhDs. And that wasn't a bad thing until everyone got focused on generating another random architecture that yields another 2% improvement on their favorite dataset so their paper gets through.
Re: Deep Learning Is Eating Software
#3Deep learning is certainly eating conferences, funding and PhDs. And that wasn't a bad thing until everyone got focused on generating another random architecture that yields another 2% improvement on their favorite dataset so their paper gets through.
>> another 2% improvement
2% is HUGE at this point, at least on the datasets that I am familiar with - ImageNet, MS-Coco, PascalVOC etc. And at this point, any modifications or strategies that gets you the 2% improvement is noteworthy, and I know that people in my team are looking forwards to techniques that will give us these improvements.
Re: Deep Learning Is Eating Software
#4Sure. Can we see an example of Deep Learning used to create a regular CRUD app?
Re: Deep Learning Is Eating Software
#5Sure. Can we see an example of Deep Learning used to create a regular CRUD app?
I wouldn't be surprised to see deep learning optimize a GraphQL backend by indexing and caching queries as needed.
Re: Deep Learning Is Eating Software
#6Deep learning is certainly eating conferences, funding and PhDs. And that wasn't a bad thing until everyone got focused on generating another random architecture that yields another 2% improvement on their favorite dataset so their paper gets through.
>> another 2% improvement 2% is HUGE at this point, at least on the datasets that I am familiar with - ImageNet, MS-Coco, PascalVOC etc. And at this point, any modifications or strategies that gets you the 2% improvement is noteworthy, and I know that people in my team are looking forwards to techniques that will give us these improvements.
> 2% is HUGE at this point
Hell, on MNIST 0.14% is huge. Geff Hinton created an entire new architecture to get 0.25% error, which is far better than the baseline 0.39% error [1].
To be fair, he did reduce the error by 35%.
Re: Deep Learning Is Eating Software
#7Sure. Can we see an example of Deep Learning used to create a regular CRUD app?
I wouldn't be surprised to see deep learning optimize a GraphQL backend by indexing and caching queries as needed.
Indexing and caching is optimization. Who did the real job, that was being optimized?
If my account balance is $5, and I buy that yummy Cheese Swirls for $2, I expect the balance to be $3 afterward. Deep Learning will not help, or frankly it can only make this simple calculation wrong. So... no, deep learning is not eating software. BTW deep learning IS software, so this is all just headline-grabbing.
Re: Deep Learning Is Eating Software
#8Earlier quoted context omitted.
I wouldn't be surprised to see deep learning optimize a GraphQL backend by indexing and caching queries as needed.
Indexing and caching is optimization. Who did the real job, that was being optimized? If my account balance is $5, and I buy that yummy Cheese Swirls for $2, I expect the balance to be $3 afterward. Deep Learning will not help, or frankly it can only make this simple calculation wrong. So... no, deep learning is not eating software. BTW deep learning IS software, so this is all just headline-grabbing.
Deep learning will allow software to infer how your comment maps to a CRUD operation, and instead of having someone code up a backend and think through a schema, it'll happen on the fly.
So yes, I suspect deep learning (or ML more generally) will eat up a lot of the CRUD, glue code, and repetetive data-pipeline related crap I deal with daily.
I yearn for the day when I can tell my db "store this" and "give me that" without having to think of the umpteen* data stores that back it all.
* No joke. We have a real-time feed, a few warehouses, and external data sources we need to wrangle to build applications. From my perspective, some statistical machine could easily do that with a bit of human help.
If you think we should rearchitect our infrastructure, your right! But doesn't that seem like something a computer could be good at?
Re: Deep Learning Is Eating Software
#9Deep learning is certainly eating conferences, funding and PhDs. And that wasn't a bad thing until everyone got focused on generating another random architecture that yields another 2% improvement on their favorite dataset so their paper gets through.
>> another 2% improvement 2% is HUGE at this point, at least on the datasets that I am familiar with - ImageNet, MS-Coco, PascalVOC etc. And at this point, any modifications or strategies that gets you the 2% improvement is noteworthy, and I know that people in my team are looking forwards to techniques that will give us these improvements.
Exactly my point. The "huge" improvement is perceived as important although has no real impact on advancing the field and solving core real issues.
Re: Deep Learning Is Eating Software
#10Some of my work is related to traditional BI tools and not one day goes with me hearing someone, specially the management, talk about applying machine learning in some way.
Now while I can see some aspects which can be improved by usage of ML many don't tend to understand the implication of such systems. A good example came last year. On the BI system there existed 200+ reports with an average user having access to maybe 20 reports based on their department - finance, sales etc. There was a big push from the management to "improve" user experience with ML. Build a recommendation system they said. There was no cost benefit analysis done for using a complex ML based recommendation system on 20 reports - It sounded cool and in line with the hype.
Then there is the question of user involvement. While I believe there is surely a case to made for stuff which involves software engineers, like the ones mentioned in the post - search ranking, data center energy usage etc. But things which require non-software engineers is a bit doubtful. This is because as the post puts it - "This doesn’t require the same technical skills as traditional programming, but it does need a deep knowledge of the problem domain. " And engineers cannot be expected to have deep knowledge of every function. If they get too drunk on the ML kool aid, and some of them do, the end result will be mess.