Downloaded 17 times
Uploaded byWithTheBest
What Every Software Engineer Should Know About Machine Learning - Peter Norvig
The document discusses key concepts in machine learning that every software engineer should understand, emphasizing the transformation of applications through technologies like visual recognition and the challenges faced with non-modularity, lack of tooling, and privacy concerns. It contrasts traditional software with machine learning, highlighting issues such as nonstationarity and feedback loops. The importance of scalable oversight and safe exploration in developing machine learning systems is also mentioned.
More Related Content
Similar to What Every Software Engineer Should Know About Machine Learning - Peter Norvig
![[REPORT PREVIEW] The Customer Experience of AI](https://cdn.slidesharecdn.com/ss_thumbnails/slideshare-cx-of-ai-171116034109-thumbnail.jpg?width=640&height=640&fit=bounds)
![5G Explained! A High Level Overview [Introduction]](https://cdn.slidesharecdn.com/ss_thumbnails/5gexplainedahighleveloverview-260119165306-cc137a3e-thumbnail.jpg?width=640&height=640&fit=bounds)
What Every Software Engineer Should Know About Machine Learning - Peter Norvig
- 1. Peter Norvig What Every SoftwareEngineer Should Know About Machine Learning
- 2. “How can wereinvent it knowing that software can play such an important role.”
- 6. “How can wereinvent it knowing that machine learning can play such an important role.”
- 7.
- 8.
- 12.
- 13.
- 14.
- 17.
- 18. Human: Three differenttypes of pizza on top of a stove. Machine: Two pizzas sitting on top of a stove.
- 19. A couple of giraffe standing nextto each other
- 20. A reflectio n of a dogin a side view mirror
- 21.
- 23.
- 24.
- 25. Google Now Time oftravel: 23 minutes by bicycle event = ExtractEvent(email.body) trip = Travel(current.location, event.location, event.time) CreateAlert(trip)
- 26.
- 27.
- 29. Privacy and SecurityPrivacy,Security, Fairness
- 30.
- 31.
- 32. Build / Test/ Release Cycles
- 34.
- 35.
- 36.
- 37.
- 38.
- 39. “the worst …except all the others that have been tried”
Editor's Notes
- #3 Marc Andressen said that software is eating the (business) world.
- #4 We see it in the fortunes of these once-dominant companies.
- #5 Now replaced with these software-driven competitors. Other companies: wal-mart, FedEx – are software networks that happen to have physical assets.
- #6 But we see a lot of companies recently driven by machine learning technology. How is machine learning different from other software?
- #7 But we see a lot of companies recently driven by machine learning technology. How is machine learning different from other software?
- #10 This a typical inexpensive digital camera (or smart phone). It can detect faces with a green square. How was that done? Engineers analyzed the problem of finding faces and laboriously wrote code that said something like look first for vertical bright bands in an image that might be noses then look for horizontal dark bands that might be eyes, then looks for other general patterns associated with faces, including a certain range of skin shades They could afford to spend a few weeks or even a few months of engineer timefiddling with the code on this problem, because it was the only identification problem the camera had to do. This is Google Photos. It doesn’t just detect faces? It detects everything. It knows about hundreds of thousands of categories, objects, locations, adjectives, etc. Here it automatically classified my recent photos, making up category names.
- #11 Not just flowers, but clematis. Note it got one wrong.
- #12 We can even learn abstract concepts
- #14 Programmer defines problem and solution Solution in form of explicit “if-then” rules Bugs occur when rules are wrong Plagued by complexity
- #15 Programmer defines model, Data defines solution With enough data, generalizes well Bugs occur when model is poor fit or data is lacking Still plagued by complexity, but in different ways
- #25 “Easy” to launch with some good results Hard to make improvements
- #27 sands of time --- nonstationarity
- #28 Altering behavior of the very users the system relies on :
- #31 Everything changes over time Standard test cycle: pass tests and be done
- #32 Harder than code dependencies; no automated tools System B uses some raw data, but also uses a score computed by System A. But the System A engineers periodically change their scoring algorithm, perhaps without even knowing that System B is consuming the scores. Feature A was incorrectly logged from 9/14 to 9/17. Feature B started 10/7. feature C logging format changed. Feature D is not available in production, so a substitute features D′ If feature Z is used, extra memory requiredy. Feature Q precludes the use of feature R because of latency constraints.
- #33 Harder than code dependencies; no automated tools System B uses some raw data, but also uses a score computed by System A. But the System A engineers periodically change their scoring algorithm, perhaps without even knowing that System B is consuming the scores. Feature A was incorrectly logged from 9/14 to 9/17. Feature B started 10/7. feature C logging format changed. Feature D is not available in production, so a substitute features D′ If feature Z is used, extra memory requiredy. Feature Q precludes the use of feature R because of latency constraints.
- #35 Everything changes over time Standard test cycle: pass tests and be done
- #37 Everything changes over time Standard test cycle: pass tests and be done
- #38 Everything changes over time Standard test cycle: pass tests and be done
- #39 Everything changes over time Standard test cycle: pass tests and be done