I work in manufacturing. We have an acoustic microscope that scans parts with the goal of identifying internal defects (typically particulate trapped in epoxy bonds). It's pretty hard to define what size/shape/position/number of particles is worthy of failing the device. Our final product test can tell us what product is "good" and "bad" based on electrical measurements, but that test can't be applied at the stage of assembly where we care to identify the defect.
I recently demonstrated a really simple bagged-decision tree model that "predicts" if the scanned part will go on to fail at downstream testing with ~95% certainty. I honestly don't have a whole lot of background in the realm of ML so it's entirely possible that I'm one of those dreaded types that are applying principles without full understanding of them (and yes I do actually feel quite guilty about it).
The results speak for themselves though - $1M/year scrap cost avoided (if the model is approved for production use) in just being able to tell earlier in the line when something has gone wrong. That's on one product, in one factory, in one company that has over 100 factories world-wide.
The experience has prompted me to go back to school to learn this stuff more formally. There is immense value to be found (or rather, waste to be avoided) using ML in complex manufacturing/supply-chain environments.
First, bagged decision trees are a little hard to interpret; what is the advantage of a bagged model vs the plain trees? Are you using a simple majority vote for combination? What are the variances between the different bootstraps?
Second - what do you mean by 95% ? Do you mean that out of 99999 good parts 4999 are thrown away? and one bad one is picked out as bad ?
Third - what is this telling you about your process? Do you have a theory that has evolved from the stats that tells you why parts are failing? This is the real test for me.. If the ML is telling you where it is going wrong (even if it's unavoidable/too expensive to solve) then you've got something real.
Unfortunately my concern would be that as it stands.. you might find that in production your classifier doesn't perform as well as it did in test... My worry has been generated by the fact that this same thing has happened to me !
It sounds like the OP is scanning for internal defects in bonds via impurities being trapped in there. These occur relatively randomly and there's some balancing point where it's just not worth trying to make the production line cleaner vs binning parts that fail some QA criteria. I do similar things with castings, where you simply just get certain voids and porosity in the steel when cast and either you can spend a tonne of money trying to eliminate them or you can spend less money testing the parts and binning those that aren't up to par.
I'd hazard to guess that the 95% is the reduction in how many parts made it through the first test only to be caught later at the more expensive stage. So instead of binning 100 parts a month at that second stage, they now bin 5 parts a month and catch way more early on.
It sounds like the OP is using ML to identify flaws that simply just occur due to imperfections in the manufacturing process. That's life, it happens. You can know that they will occur without necessarily being able to prevent them because maybe there's some dust or other particulates in the air that deposit into the resin occasionally, or maybe the resin begins to cure and leaves hard spots that form bond flaws. There's heaps of possible reasons. It sounds more like the ML is doing classification of 'this too much of a flaw in a local zone' vs 'this has some flaws but it's still good enough to pass', which is how we operate with casting defects. For example, castings have these things called SCRATA comparitor plates, where you literally look at an 'example' tactile plate, look at your cast item, then mentally decide on a purely qualtative aspect which grade of plate it matches. Here [1] are some bad black and white photos of the plates.
This sounds like a pretty standard use of ML to me. No need to feel guilty, this stuff just isn't very difficult from a user's perspective, especially if you use the right libraries. It helps if you maintain a good bookkeeping of your experiments, so you have a good picture of what works and what doesn't.
By the way, control engineering for industry used to be very difficult (but is paid very well), and requires knowledge of systems theory, differential equations, and physics. But with the advent of ML, I suspect that might change; things may get a lot easier.
This is awesome - thank you! I went through a similar exercise described in your link in evaluating the utility of the tool I described above. This is a nice write up of the logic.
In my case the % occurrence of the defect was very high and the False-Positive cost is also very high so my tool could provide value without being too stellar of a model.
Disclaimer: I have no experience implementing any kind of ML.
How easy will it be to update your model if/when the downstream process changes?
At a previous job we had a process that relied heavily on visual inspection from employees. I often considered applying ML to certain inspection steps, but always figured it would be most useful for e.g. final inspection to avoid having to update the models frequently as the processes were updated.
That's an interesting concern that I hadn't considered if I'm understanding you correctly. I'm imagining you could have a situation where a downstream process change helps mitigate the effect of the upstream defect. In that situation your measure of what constitutes good and bad parts will need to change in the ML model.
I think I'm somewhat lucky in that with my product downstream processes are unlikely to change in a significant enough way to warrant "retraining" the model, but I guess that's probably the only way to handle that - retrain in the event of a significant process change. Our product stays fairly stable once it releases to production and the nature of the downstream processes is that they would have very little effect on the perceived severity of the defect at the final electrical test.
My only two misgivings about the program thus far: It is 1) pretty expensive and 2) geared towards working professionals rather than academics, but my employer is helping pay for a good chunk of the degree and I'm more interested in acquiring the skills and tools to go solve problems in industry as opposed to doing research.
Otherwise it has been great thus far. The program was attractive to me because it is somewhat marketed towards those that may not have a software background, but have problems in their industry that could benefit from a "proper" data science treatment. I've been referring to my application of the principles as "Six Sigma for the 21st Century" with managers/directors. I think the vast majority of HN would groan at that term, but it helps communicate the potential value to someone who has no technical background with software whatsoever (think old school manufacturing/operations types): Process improvement for environments with many variables that have practically unknowable inter-dependencies (as is the case with the project described in my original comment).
Hi, I work at a manufacturing startup on pretty much the same exact problem (reducing scrape rates and downtime). I'd love to pick your brain if you have a moment to chat :) my email is mykola@oden.io
I don't understand why this comment is unpopular since the GP is phrased in such a fashion that you only notice that they talking hypothetically if you read it carefully.
I don't think there's anything wrong the GP's achievement or post (it's all interesting stuff) but if something has not yet been implemented, it's worth nothing since there is "many a slip 'tween cup and the lip"
The entire product I built over the last year can be reduced to basic statistics (e.g. ratios, probabilities) but because of the hype train we build "models" and "predict" certain outcomes over a data set.
One of the products the company I work for sells more or less attempts to find duplicate entries in a large, unclean data set with "machine learning."
The value added isn't in the use of ML techniques itself, it's in the hype train that fills the Valley these days: our customers see "Data Science product" and don't get that it's really basic predictive analytics under the hood. I'm not sure the product would actually sell as well as it does without that labeling.
To clarify: the company I work for actually uses ML. I actually work on the data science team at my company. My opinion is that we don't actually need to do these things, as our products are possible to create without the sophistication of even the basic techniques, but that battle was lost before I joined.
It's interesting to me that with all the ML hype, it's still not clear what constitutes ML. A basic k-means or naive Bayes approach will show up in ML textbooks, but those aren't clearly different from "use some statistics to make a prediction".
There's an interesting group of marginal approaches that have existed as-is for years, but have increasingly focused their branding on machine learning as its profile has risen.
> but those aren't clearly different from "use some statistics to make a prediction"
You can reduce 90% of ML to this. Even neural networks are based on statistics.
If I have to draw a line between statistics and ML is that ML learns, it means it can predict things, however statistics only gives you information about the data you have. But for sure statistics and ML overlap a lot.
The best distinction I've found between ML and statistics is the following.
Statistics is about modelling the underlying probability distribution that generates your data. A convergence/generalization/etc result will usually be dependent on this underlying distribution.
ML is when you don't care much about the underlying distribution (modulo regularity assumptions), and your model doesn't even come from the same family at all.
I.e. linear regression is usually statistics, because you often believe the underlying data looks like f(x) ~ f(x0) + f'(x0)(x-x0)). Random forests are machine learning because you don't actually think the real world secretly has a random forest flotaing around.
> A basic k-means or naive Bayes approach will show up in ML textbooks, but those aren't clearly different from "use some statistics to make a prediction".
Ha, sounds like a classification problem! Let's use ML to find the boundary.
Actually there's a very clear definition of what types of problems ML ought be used for, and that category of problem is what defines it. Those familiar with regression (and stats in general) ought to be familiar with it already - it's an issue of relationship of datatype between independent and dependent variable.
In brief, you're going to run up against two types of data - categorical and continuous. (There are facets to this, eg ordinal, but these are really the elemental types of data). The relationship of datatype to independent/dependent variable is what determines what kind of analysis you may conduct.
Categorical Independent vs. Categorical Dependent, for example, is fairly restrictive, as makes logical sense. You may cross-tabulate, you may score likelihood based on previous observation, but obviously, because all of the data involved are non-numeric, there's no chance for regression, ANOVA, etc. Linear Regression is used when both independent and dependent variables are continuous, and cross-category differencing techniques like ANOVA may be used when the independent is categorical and the dependent is continuous.
The part you don't typically learn until grad school is when the independent is continuous and the dependent is categorical, ie, in ML, a classification problem. The standard statistical methods used as foundation for these problems are logistic regression, logit/probit. It's expansion of these methods that lead to ML in the first place.
The value added isn't in the use of ML techniques itself, it's in the hype train that fills the Valley these days: our customers see "Data Science product" and don't get that it's really basic predictive analytics under the hood. I'm not sure the product would actually sell as well as it does without that labeling.
So you are misleading your customers through omission? This is the kind of thing that makes people question anyone stating they are using ML. Those of us actually implementing ML techniques (aka training neural nets and automating processes with data) are met with unnecessary skepticism as a result.
edit: OP clarified his position since this post so take that into account when reading.
No, we actually use ML. We just don't need to, in my opinion, because the problems our products solve are more or less solvable without these techniques.
My point was that using ML, even though we don't need to, "adds value" by virtue of the hype train. We need ML to sell products, not to create them.
I do agree that this sort of arrangement lends itself to supporting skepticism around AI and ML. On the other hand I don't think that's a bad thing.
We use ML/Deep Learning for customer to product recommendations and product to product recommendations. For years we used only algorithms based on basic statistics but we've found places where the machine learned models out perform the simpler models.
So is this like the Amazon "feature" where I buy a coffee table on Amazon, then I get suggested to buy a coffee table EVERY DAY for 3 months. Literally row after row of coffee table? Because there must be a big pool of people who buy 1 coffee table buying more coffee tables immediately after?
It's a hard problem to determine the repeat purchase cadence of a product. At one end of the bell curve you have items re-purchased frequently, e.g. diapers or grocery, and on the other end you have items that are rarely repurchased.
I haven't looked at coffee tables specifically, but I know when I've looked at home products in the past I've been surprised at how frequently people will buy two large items, e.g. TVs or furniture, within a short period. That said, I agree there is room for improvement here. We're constantly running experiments to improve the customer experience, I have faith that in the limit things will improve. Again, we have no shortage of experimental power so if you'd like to join in the experimentation let me know :)
must be the same genius technology that leads Amazon to load up my Prime frontpage with fashion accessories when I've never had any history of searching or buying such, and recommending the same shows "Mozart in the Jungle", "Transparent", "Catastrophe" on Fire TV stick for months even though I've never shown any interest in any of such programming, even after manually "improving recommendations" by clicking "Not Interested".
its amazing that the vaunted Amazon technology is unable to figure out an algorithm that would satisfy a user's deep desire "please stop plastering Jeffrey Tambor's lipstick and mascara covered face on my startup screen, I've gotten tired of looking at it for the past year"
Advertising is trained against ROI, not against what will "seem right" to the user.
Maybe in-market* furniture shoppers tend to spend a lot of money. Maybe furniture is a very profitable category. Even if the system is smart enough to assume there's only a 20% chance that you're in the process of significant furniture purchases, furniture ads may still be a better use of the ad slot than a lower value item where you have an 80% chance of being in-market.
Then why show the same damn coffee table over and over? Maybe that's more likely to return your attention to your furniture purchasing? I have no idea. Most likely, they don't know exactly either. Most likely, that's just what the highest-scoring current algorithm decided.
*The duration of "in-market" varies by category. Some product categories have a long consideration phase. For example car shoppers tend to spend 2-3 months considering alternative brands and models before they spend a few weeks narrowing down on a specific car configuration and exact pricing.
Haha yes, I remember seeing washing machines on my landing page for months after I bought one from Amazon. I mean, how many of them could a person need?
Seriously though, I don't understand why it's so hard to take this effect into account, as there should be a very strong negative correlation between a purchase in a given category and the probability of buying an article from that category in the near future, so even a simple ML algorithm should be able to pick this up easily. Anyone here who can explain why this is difficult?
Obviously the goal of ML in this would be that feeding it enough data about users who buy coffee tables would eventually teach it that you probably don't want another coffee table (because who buys two coffee tables in a row?), but might want to buy say... end tables or other living room furniture in a matching style to the coffee table you just bought.
Theory is that the recommendation engine is built for books. So if you buy a specific type of book, it recommends other books in the similar category. I guess they never got a chance to update it to reflect the fact that Amazon sells more than just books.
I'm late - but that is actually called dynamic remarketing. You look at a certain category of item and then see ads (on amazon or off-site) for other items in that same category. If you actually bought the coffee table on a different device/browser/anywhere else.. then you'll see those ads for a while because they can't recognize that you actually made the purchase already.
It's more like you bought a coffee table and you get coffee beans in the recommendations. Also, you buddy who you are in the same group with gets a coffee table recommendation.
For years we used only algorithms based on basic statistics but we've found places where the machine learned models out perform the simpler models.
This is the right way to approach it. Too many people are looking for "deep" as some sort of silver bullet for an ill defined problem they have. If you can't validate against a simple model trained properly you are already in trouble. Likewise if you don't understand how to evaluate your generalization issues and how/if a simpler model will improve them.
We're a computer vision company, we do a lot of product detection + recognition + search, primarily for retailers, but we've also got revenue in other verticals with large volumes of imagery. My co-founder and I both did our thesis' on computer vision.
In our space, the recent AI / ML advances have made things possible that were simply not realistic before.
That being said, the hype around Deep Learning is getting pretty bad. Several of our competitors have gone out of business (even though they were using the magic of Deep Learning). For example, JustVisual went under a couple of months ago ($20M+ raised) and Slyce ($50M+ raised) is apparently being sold for pennies on the dollar later this month.
Yes, Deep Learning has made some very fundamental advances, but that doesn't mean it's going to make money just as magically!
There's a lot of "DL allows us to do X so we should make a product / service using DL to do X", rather than "We think there's value in something doing Y, what allows us to do Y? <research> DL allows us to do Y better than anything else, lets use DL"
You gave the example of Slyce. Their products are cool, but I can't help but think "is DL the best way to get that end result?" for lots of the things they do.
Can you expand more on "we do a lot of product detection + recognition + search, primarily for retailers" please? Is that something like identifying products in social media images or something?
We have several products, each of which serves different departments within retailers.
The exact things we do depends entirely on which department(s) are licensing it. Basically, anywhere there's a product image (from their own inventory to mobile to social) and we can provide some kind of help, we do. Every department needs totally different things, so it varies quite a bit...but it's all leveraging our core automated detection + recognition + search APIs.
1. Course Recommendations. We use low rank matrix factorization approaches to do recommendations, and are also looking into integrating other information sources (such as your career goals).
2. Search. Results are relevance ranked based on a variety of signals from popularity to learner preferences.
3. Learning. There's a lot of untapped potential here. We have done some research into peer grading de-biasing [1] and worked with folks at Stanford on studying how people learn to code [2].
We recently co-organized a NIPS workshop on ML for Education: http://ml4ed.cc . There's untapped potential in using ML to improve education.
I'm curious, because this is something that I was interested in doing for brick and mortar universities, what aspects do you use to do your recommendations. That is, is it just a x/5 rating per user that is thrown into a latent factor model, or do you do anything else (like dividing course 'grade' vs. opinion along two axes manually?)
Are you just weighing different scores on 2? That would be heuristics more precisely. Not really learning; Unless you update the weights my minimizing some cost function.
At Sumo Logic we do "grep in cloud as a service". We use machine learning to do pattern clustering. Using lines of text to learn printfs they came from.
The primary advantage for customer is easier to use and troubleshoot faster.
This is great. I've been thinking about better ways to search logs for root causes. Splunk is good if you know what you are looking for, but this is exactly what I want to see to show me unexpected things in logs.
just a happy Sumologic user, saying hello and Thanks! Most of your product is great (I am ex splunk user)... The biggest complaint is that I can't cmd+click to open anything in new tabs as everything is so JS crazy front end.
overall the pattern matching stuff is pretty cool. Also, would like a see raw logs around this for when I am trying to debug event grouping errors based on the starting regex.
E.g. With LogReduce you can click on group and see log lines that belongs to it. IS that something that solves your problem, or are you looking for something else.
Feel free to send me an email (it is on my profile).
Here at Matterport, our research team is using deep learning to understand the 3D spaces scanned by our customers. Deep learning is great for a company like ours, where so much of our data is visual in nature and extracting that information in a high-throughput way would have been impossible before the advent of deep learning.
One way we're applying this is automatic creation of panoramic tours. Real estate is a big market for us, and a key differentiator of our product is the ability to create a tour of a home that will play automatically as either a slideshow or a 3D fly-through. The problem is, creating these tours manually takes time, as it requires navigating a 3D model to find the best views of each room. We know these tours add significant value when selling a home, but many of our customers don't have the time to create them. In our research lab we're using deep learning to create tours automatically by identifying different rooms of the house and what views of them tend to be appealing. We are drawing from a training set of roughly a million user-generated views from manually created guided tours, a decent portion of which are labelled with room type.
It's less far along, but we're also looking at semantic segmentation for 3D geometry estimation, deep learning for improved depth data quality, and other applications of deep learning to 3D data. Our customers have scanned about 370,000 buildings, which works out to around 300 million RGBD images of real places.
Interesting. What is your training objective in deciding which view of the room would be the most appealing?
Also, are you looking into generative models for creating new views from different angles based on existing views?
One of my coworkers used basic reinforcement learning to automate a task someone used to have to do manually. We have two data ingestion pipelines. One that we ingest immediately, and a second for our larger customers which is throttled during the day and ingested at night. For the throttled pipeline, we initially had hard coded rate limits, but as we made changes to our infrastructure, the throttle was processing a different amount than it should have been. Sometimes it would process too much, and we would start to see latency build up in our normal pipeline, and other times it processed too little. For a short period of time, we had the hard coded throttle with a Slack command to override the default. This allowed an enginneer to change the rate limit if they saw we were ingesting to little or too much. While this worked, it was common that an engineer wasn't paying attention, and we would process the wrong amount for a period of time. One of my coworkers used extremely basic reinforcement learning to make the throttle dynamic. It looks at the latency of the normal ingestion pipeline, and based on that, decides how high to set the rate limit on the throttled pipeline. Thanks to him, the throttle will automatically process as much as it can, and no one needs to watch it.
The same coworker also used decision trees to analyze query performance. He trained a decision tree on the words contained in the raw SQL query and the query plan. Anyone could then read the decision tree to understand what properties of a query made that query slow. There's been times we're we've noticed some queries having odd behavior going on, such as some queries having unusually high planning time. When something like this happens, we are able to train a decision tree based on the odd behavior we've noticed. We can then read the decision tree to see what queries have the weird behavior.
It sounds like a simple PID loop would be sufficient to solve this problem. You have a control valve and an error signal. No need for anything more complicated.
Readit News
I recently demonstrated a really simple bagged-decision tree model that "predicts" if the scanned part will go on to fail at downstream testing with ~95% certainty. I honestly don't have a whole lot of background in the realm of ML so it's entirely possible that I'm one of those dreaded types that are applying principles without full understanding of them (and yes I do actually feel quite guilty about it).
The results speak for themselves though - $1M/year scrap cost avoided (if the model is approved for production use) in just being able to tell earlier in the line when something has gone wrong. That's on one product, in one factory, in one company that has over 100 factories world-wide.
The experience has prompted me to go back to school to learn this stuff more formally. There is immense value to be found (or rather, waste to be avoided) using ML in complex manufacturing/supply-chain environments.
First, bagged decision trees are a little hard to interpret; what is the advantage of a bagged model vs the plain trees? Are you using a simple majority vote for combination? What are the variances between the different bootstraps?
Second - what do you mean by 95% ? Do you mean that out of 99999 good parts 4999 are thrown away? and one bad one is picked out as bad ?
Third - what is this telling you about your process? Do you have a theory that has evolved from the stats that tells you why parts are failing? This is the real test for me.. If the ML is telling you where it is going wrong (even if it's unavoidable/too expensive to solve) then you've got something real.
Unfortunately my concern would be that as it stands.. you might find that in production your classifier doesn't perform as well as it did in test... My worry has been generated by the fact that this same thing has happened to me !
Several times...
I'd hazard to guess that the 95% is the reduction in how many parts made it through the first test only to be caught later at the more expensive stage. So instead of binning 100 parts a month at that second stage, they now bin 5 parts a month and catch way more early on.
It sounds like the OP is using ML to identify flaws that simply just occur due to imperfections in the manufacturing process. That's life, it happens. You can know that they will occur without necessarily being able to prevent them because maybe there's some dust or other particulates in the air that deposit into the resin occasionally, or maybe the resin begins to cure and leaves hard spots that form bond flaws. There's heaps of possible reasons. It sounds more like the ML is doing classification of 'this too much of a flaw in a local zone' vs 'this has some flaws but it's still good enough to pass', which is how we operate with casting defects. For example, castings have these things called SCRATA comparitor plates, where you literally look at an 'example' tactile plate, look at your cast item, then mentally decide on a purely qualtative aspect which grade of plate it matches. Here [1] are some bad black and white photos of the plates.
[1] http://www.iron-foundry.com/ASTM-A802-steel-castings-surface...
By the way, control engineering for industry used to be very difficult (but is paid very well), and requires knowledge of systems theory, differential equations, and physics. But with the advent of ML, I suspect that might change; things may get a lot easier.
http://blog.mldb.ai/blog/posts/2016/01/ml-meets-economics/http://blog.mldb.ai/blog/posts/2016/04/ml-meets-economics2/
In my case the % occurrence of the defect was very high and the False-Positive cost is also very high so my tool could provide value without being too stellar of a model.
How easy will it be to update your model if/when the downstream process changes?
At a previous job we had a process that relied heavily on visual inspection from employees. I often considered applying ML to certain inspection steps, but always figured it would be most useful for e.g. final inspection to avoid having to update the models frequently as the processes were updated.
I think I'm somewhat lucky in that with my product downstream processes are unlikely to change in a significant enough way to warrant "retraining" the model, but I guess that's probably the only way to handle that - retrain in the event of a significant process change. Our product stays fairly stable once it releases to production and the nature of the downstream processes is that they would have very little effect on the perceived severity of the defect at the final electrical test.
My only two misgivings about the program thus far: It is 1) pretty expensive and 2) geared towards working professionals rather than academics, but my employer is helping pay for a good chunk of the degree and I'm more interested in acquiring the skills and tools to go solve problems in industry as opposed to doing research.
Otherwise it has been great thus far. The program was attractive to me because it is somewhat marketed towards those that may not have a software background, but have problems in their industry that could benefit from a "proper" data science treatment. I've been referring to my application of the principles as "Six Sigma for the 21st Century" with managers/directors. I think the vast majority of HN would groan at that term, but it helps communicate the potential value to someone who has no technical background with software whatsoever (think old school manufacturing/operations types): Process improvement for environments with many variables that have practically unknowable inter-dependencies (as is the case with the project described in my original comment).
I don't think there's anything wrong the GP's achievement or post (it's all interesting stuff) but if something has not yet been implemented, it's worth nothing since there is "many a slip 'tween cup and the lip"
One of the products the company I work for sells more or less attempts to find duplicate entries in a large, unclean data set with "machine learning."
The value added isn't in the use of ML techniques itself, it's in the hype train that fills the Valley these days: our customers see "Data Science product" and don't get that it's really basic predictive analytics under the hood. I'm not sure the product would actually sell as well as it does without that labeling.
To clarify: the company I work for actually uses ML. I actually work on the data science team at my company. My opinion is that we don't actually need to do these things, as our products are possible to create without the sophistication of even the basic techniques, but that battle was lost before I joined.
There's an interesting group of marginal approaches that have existed as-is for years, but have increasingly focused their branding on machine learning as its profile has risen.
You can reduce 90% of ML to this. Even neural networks are based on statistics.
If I have to draw a line between statistics and ML is that ML learns, it means it can predict things, however statistics only gives you information about the data you have. But for sure statistics and ML overlap a lot.
Statistics is about modelling the underlying probability distribution that generates your data. A convergence/generalization/etc result will usually be dependent on this underlying distribution.
ML is when you don't care much about the underlying distribution (modulo regularity assumptions), and your model doesn't even come from the same family at all.
I.e. linear regression is usually statistics, because you often believe the underlying data looks like f(x) ~ f(x0) + f'(x0)(x-x0)). Random forests are machine learning because you don't actually think the real world secretly has a random forest flotaing around.
Ha, sounds like a classification problem! Let's use ML to find the boundary.
Yes, this means ML is "just" statistics - the distinction being that it is automated so you can run it on larger amounts of data quickly.
I thought this was pretty much an accepted definition.
In brief, you're going to run up against two types of data - categorical and continuous. (There are facets to this, eg ordinal, but these are really the elemental types of data). The relationship of datatype to independent/dependent variable is what determines what kind of analysis you may conduct.
Categorical Independent vs. Categorical Dependent, for example, is fairly restrictive, as makes logical sense. You may cross-tabulate, you may score likelihood based on previous observation, but obviously, because all of the data involved are non-numeric, there's no chance for regression, ANOVA, etc. Linear Regression is used when both independent and dependent variables are continuous, and cross-category differencing techniques like ANOVA may be used when the independent is categorical and the dependent is continuous.
The part you don't typically learn until grad school is when the independent is continuous and the dependent is categorical, ie, in ML, a classification problem. The standard statistical methods used as foundation for these problems are logistic regression, logit/probit. It's expansion of these methods that lead to ML in the first place.
So you are misleading your customers through omission? This is the kind of thing that makes people question anyone stating they are using ML. Those of us actually implementing ML techniques (aka training neural nets and automating processes with data) are met with unnecessary skepticism as a result.
edit: OP clarified his position since this post so take that into account when reading.
My point was that using ML, even though we don't need to, "adds value" by virtue of the hype train. We need ML to sell products, not to create them.
I do agree that this sort of arrangement lends itself to supporting skepticism around AI and ML. On the other hand I don't think that's a bad thing.
We use ML/Deep Learning for customer to product recommendations and product to product recommendations. For years we used only algorithms based on basic statistics but we've found places where the machine learned models out perform the simpler models.
Here is our blog post and related GitHub repo: https://aws.amazon.com/blogs/big-data/generating-recommendat...https://github.com/amznlabs/amazon-dsstne
If you are interested in this space, we're always hiring. Shoot me an email ($my_hn_username@amazon.com) or visit https://www.amazon.jobs/en/teams/personalization-and-recomme...
I haven't looked at coffee tables specifically, but I know when I've looked at home products in the past I've been surprised at how frequently people will buy two large items, e.g. TVs or furniture, within a short period. That said, I agree there is room for improvement here. We're constantly running experiments to improve the customer experience, I have faith that in the limit things will improve. Again, we have no shortage of experimental power so if you'd like to join in the experimentation let me know :)
its amazing that the vaunted Amazon technology is unable to figure out an algorithm that would satisfy a user's deep desire "please stop plastering Jeffrey Tambor's lipstick and mascara covered face on my startup screen, I've gotten tired of looking at it for the past year"
Maybe in-market* furniture shoppers tend to spend a lot of money. Maybe furniture is a very profitable category. Even if the system is smart enough to assume there's only a 20% chance that you're in the process of significant furniture purchases, furniture ads may still be a better use of the ad slot than a lower value item where you have an 80% chance of being in-market.
Then why show the same damn coffee table over and over? Maybe that's more likely to return your attention to your furniture purchasing? I have no idea. Most likely, they don't know exactly either. Most likely, that's just what the highest-scoring current algorithm decided.
*The duration of "in-market" varies by category. Some product categories have a long consideration phase. For example car shoppers tend to spend 2-3 months considering alternative brands and models before they spend a few weeks narrowing down on a specific car configuration and exact pricing.
Seriously though, I don't understand why it's so hard to take this effect into account, as there should be a very strong negative correlation between a purchase in a given category and the probability of buying an article from that category in the near future, so even a simple ML algorithm should be able to pick this up easily. Anyone here who can explain why this is difficult?
Not saying it works, but that'd be the goal.
I get suggestions for travel guide books for the same country I visited a year ago for which I purchased a guide book.
I guess this would make more sense.
In our space, the recent AI / ML advances have made things possible that were simply not realistic before.
That being said, the hype around Deep Learning is getting pretty bad. Several of our competitors have gone out of business (even though they were using the magic of Deep Learning). For example, JustVisual went under a couple of months ago ($20M+ raised) and Slyce ($50M+ raised) is apparently being sold for pennies on the dollar later this month.
Yes, Deep Learning has made some very fundamental advances, but that doesn't mean it's going to make money just as magically!
There's a lot of "DL allows us to do X so we should make a product / service using DL to do X", rather than "We think there's value in something doing Y, what allows us to do Y? <research> DL allows us to do Y better than anything else, lets use DL"
You gave the example of Slyce. Their products are cool, but I can't help but think "is DL the best way to get that end result?" for lots of the things they do.
The exact things we do depends entirely on which department(s) are licensing it. Basically, anywhere there's a product image (from their own inventory to mobile to social) and we can provide some kind of help, we do. Every department needs totally different things, so it varies quite a bit...but it's all leveraging our core automated detection + recognition + search APIs.
1. Course Recommendations. We use low rank matrix factorization approaches to do recommendations, and are also looking into integrating other information sources (such as your career goals).
2. Search. Results are relevance ranked based on a variety of signals from popularity to learner preferences.
3. Learning. There's a lot of untapped potential here. We have done some research into peer grading de-biasing [1] and worked with folks at Stanford on studying how people learn to code [2].
We recently co-organized a NIPS workshop on ML for Education: http://ml4ed.cc . There's untapped potential in using ML to improve education.
[1] https://arxiv.org/pdf/1307.2579.pdf
[2] http://jonathan-huang.org/research/pubs/moocshop13/codeweb.h...
The primary advantage for customer is easier to use and troubleshoot faster.
https://www.sumologic.com/resource/featured-videos/demo-sumo...
overall the pattern matching stuff is pretty cool. Also, would like a see raw logs around this for when I am trying to debug event grouping errors based on the starting regex.
E.g. With LogReduce you can click on group and see log lines that belongs to it. IS that something that solves your problem, or are you looking for something else.
Feel free to send me an email (it is on my profile).
Deleted Comment
One way we're applying this is automatic creation of panoramic tours. Real estate is a big market for us, and a key differentiator of our product is the ability to create a tour of a home that will play automatically as either a slideshow or a 3D fly-through. The problem is, creating these tours manually takes time, as it requires navigating a 3D model to find the best views of each room. We know these tours add significant value when selling a home, but many of our customers don't have the time to create them. In our research lab we're using deep learning to create tours automatically by identifying different rooms of the house and what views of them tend to be appealing. We are drawing from a training set of roughly a million user-generated views from manually created guided tours, a decent portion of which are labelled with room type.
It's less far along, but we're also looking at semantic segmentation for 3D geometry estimation, deep learning for improved depth data quality, and other applications of deep learning to 3D data. Our customers have scanned about 370,000 buildings, which works out to around 300 million RGBD images of real places.
The same coworker also used decision trees to analyze query performance. He trained a decision tree on the words contained in the raw SQL query and the query plan. Anyone could then read the decision tree to understand what properties of a query made that query slow. There's been times we're we've noticed some queries having odd behavior going on, such as some queries having unusually high planning time. When something like this happens, we are able to train a decision tree based on the odd behavior we've noticed. We can then read the decision tree to see what queries have the weird behavior.