• 开源镜像
  • 开源沙龙
  • 媛宝
  • 猿帅
  • 注册
  • 登录
  • 息壤开源生活方式平台
  • 加入我们

开源日报

  • 2019年3月3日:开源日报第353期

    3 3 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《色彩 ColorUI》
    今日推荐英文原文:《Why deadlines and sprints are bad for you》

    今日推荐开源项目:《色彩 ColorUI》传送门:GitHub链接
    推荐理由:一个小程序 UI 组件库,最大的特点是鲜明的颜色。这已经是这个库的 2.0 版本了,增加了更多的配色,如果你正在寻找一些具有鲜明颜色的组件的话它会是一个好的选择。不过它升上 2.0 的时日尚早,在线文档还没有编写完成,如果想要寻找文档的话只能去它提供的 demo 中学习了。
    今日推荐英文原文:《Why deadlines and sprints are bad for you》作者:Antti
    原文链接:https://medium.com/@niant/why-deadlines-and-sprints-are-bad-for-you-7ee87be5d0f0
    推荐理由:赶 DDL 是一种动机,但是也是一种危害

    Why deadlines and sprints are bad for you


    The development team’s capabilities for battling deadlines are fairly restricted

    In a software development project, it’s important to find a suitable process for the project. A good process helps developers, managers, customers and users. A great process should improve the day-to-day life for everyone involved and help avoid generating problems or health issues.

    In this article, I’m mainly focusing on fairly long agile projects that continue over multiple years, though these principles or opinions may apply to shorter projects as well.

    Roles in the team

    A software project team typically consists of a mix of software developers, UX designers, graphic designers and a product owner. The roles can be roughly split in two: development and product management. Product management steers the development team towards building the “right stuff” at the correct time and attempts to ensure the continued relevance of the product. The development team, on the other hand, decides how to build the “right stuff” and how to deliver it. In addition to this, the development team is responsible for ensuring the software is usable and for validating the overall quality of the product.

    In short:
    • Product management: What should we build? When should we build it?
    • Development: How should we build it? How should we deliver it?

    Sprints create deadlines for short cycles

    During recent years, agile development has been rising in popularity. It also made SCRUM famous as a process method, so much so that some use it as a synonym for agile development.

    One of the key elements in SCRUM is sprints. A sprint is a time-boxed iteration of development (usually lasting from one to three weeks), during which the team focuses on a set of tasks planned at the start of the sprint. At the sprint planning, the team takes the highest priority items from the backlog (work queue mostly managed by product management), plans them, and commits to an amount of work they think they can deliver. At the end of the sprint, there’s usually a review meeting about what was done.

    This system generates multiple short deadlines for the project. In essence, sprints force deadlines into people’s everyday work regardless of the length of the project.

    This commitment to sprints generates multiple problems. In order to commit to the amount of work, the team now needs to assess, for instance, the following factors:
    • How much effort goes into each task?
    • Is someone going to be on a personal leave during this time?
    • Is everyone 100 percent committed to project-related work or are there some other + responsibilities on the side? Training? This week or always?
    • How many sick days are there going to be in the sprint?
    • How many bugs is the team going to come across during the sprint? How difficult will they be + to solve?
    • Is someone leaving or joining the team?
    • Are there any company events during the sprint?
    • Are national holidays going to affect the sprint?
    • Are there any hardware issues going to come up?
    While these assessments can be made easier with statistics: “Generally, we get this much work done per sprint”, and so forth. The bottom line is this: There’s a wide range of variables that cause the output to vary over different sprints. Sometimes you hit the goal and sometimes you don’t. But you do have a goal, a deadline.

    Some think that sprint commitment is not necessary (disregarding SCRUM process to some extent) and that sprint should not be thought as a deadline. I like the idea in theory, but in practice, people end up confusing sprints to deadlines regardless of the intention. Especially when sprint commitment is supposed to be an instrumental part of the SCRUM process by default.

    Even the semantic idea of the word “sprint” is ill-advised for a long project. It suggests a mentality of a 100-meter sprint running to do whatever it takes to get to the finish line as fast as possible. A long software project is more accurately compared to a 50-kilometer run that is won with a steady pace, and during which overexertion at any midpoint ruins the whole run or sends you to a hospital. In long projects, people might not even know where the finish line is. Sprint seems more like a marketing term that shouldn’t be used as a term for a method of working in the first place.

    Deadlines in human health

    Deadlines can have multiple effects on humans. Especially when they are closing in. Some of them include health risks such as increased stress, loss of brain cells, lessening creativity, digestion issues, headaches, etc. When deadlines are closing in, the human body may eventually feel threat to its survival and trigger the fight or flight response. (Source: Psychology Today, The Dark Side of Deadlines)

    Other effects include motivational enticement. There are studies that show deadlines can have a positive effect on work motivation. I would argue that there are other more worthwhile and less damaging motivational enticements in existence as well. Just to list a few to get you started:
    • Creating an awesome product
    • Delivering good quality
    • Improving people’s lives
    • Helping people with their problems
    • Making people happy Deadlines can even undermine the motivation generated by other motivational enticements. (Source: Psychology Today, How deadlines can be murder on motivation)

      Additionally, the stress caused by deadlines “sets up a vicious feedback loop and keeps a person dependent on deadlines like a caffeine junkie reaching for their morning cup of joe.” For some people, meeting a deadline gives such an adrenaline rush that next time they may put off a task until they get physical symptoms of the fight or flight response. (Source: Psychology Today, The Dark Side of Deadlines)

    Deadlines in software projects

    How many times have you heard these explanations before?
    • We had to skip tests…
    • We had to add technical debt…
    • We could not fix the code…
    • We had to do it quickly…
    • We couldn’t design it properly…
    • We had to take a shortcut…
    Too often these sentences end with …because we didn’t have enough time. Why didn’t people have time? There’s probably multiple reasons, but in the end, it often comes back to deadlines, right?

    People will try to cut corners, produce lower quality and take risks while disregarding their own health to meet deadlines. (Source: ISHN, Deadlines can erode safety and promote risk-taking)

    The deadline is closing in and we’re late, now what?

    As mentioned earlier, the variables often lead to unpredictability and the project ends up missing the deadline. So what can be done now?
    • Cut corners (lowers quality)
    • Work overtime
    • Skip or forbid team other responsibilities like training
    • Forbid personal leave
    • Reduce the number of features
    • Refine the feature scope
    • Hire more team members
    • Move the deadline
    Cutting corners usually ends up damaging product quality and generating loads of technical debt. This type of debt has a very high interest rate, and the project will have to pay it sooner or later. The worst case scenario is that it causes bugs in the production environment, which can be extremely costly.

    Making people work overtime or denying leave (essentially meaning rest), on the other hand, might lead to a range of health issues and other problems in life management.

    Denying or skipping other responsibilities, such as employee training, is another form, a more slowly moving type of technical debt: It will eventually result in people with outdated skills and a project that will not benefit from new skills.

    The development team’s capabilities for battling deadlines are fairly restricted
    In simple terms:

    The tools the development team has for combatting the deadline are unsustainable:
    • Cutting corners (essentially lowering quality)
    • Working overtime
    • Skipping training or other responsibilities
    Product management controls the only sustainable options:
    • Reducing the number of features
    • Refining the feature scope
    • Hiring more team members
    • Moving the deadline
    The above categorization means that management could resort to the unsustainable options as well, if required. I believe that it is far better if management makes that choice knowingly rather than have individuals within the team make this choice on their own. These individual responses to deadlines are exactly at the core of the issue: they generate invisible problems that jump at you unpredictably.

    Well, what choice do we have?

    Instead of SCRUM, there’s another similar process called Kanban (Lean development) that does not have the concept of sprints and time-boxing, because in Kanban, they are considered a waste.

    In Kanban, there’s only the “stuff” to be done, and the development team should do it in the order prioritized by product management. It’s a very continuous process that fits naturally into long development projects. There is no need to use time on discussing commitments, dates, deadlines or anything related to sprints. More importantly, the system does not generate deadlines or deadline-like systems so the stress of having deadlines is removed. Rather, when a task gets done, the development team takes the next task from the top of the backlog and so on.

    The Kanban (Lean) process removes a number of unnatural things that SCRUM, in turn, entails.
    For instance:
    • What happens when a sprint is completed early?
    • What happens when a sprint is not completed in time?
    • What happens when bugs emerge during a sprint?
    • What if we can’t plan enough at a sprint planning?
    • What if we plan too much at sprint planning?
    • What if we want to release before the end of the sprint?
    • What happens if product management really wants to re-prioritize during a sprint?
    • What happens if everything is not ready for development at the start of the sprint?
    These questions can be answered with more processes or steps and guidance. In Kanban however, many of the questions are not even applicable because they are not necessary in order for us to get the project done — it’s just noise.

    Conclusion

    Deadlines have a lot of negative impacts on human health, but some say they are a must-have for work motivation and for project organization. I argue that there are other motivational enticements and other ways to organize projects than deadlines and sprints. This takes me to my main argument, which is that the negative impacts of deadlines and sprints outweigh the positive impacts.

    SCRUM as a popular agile framework brings us a bunch of deadlines to our day-to-day life in form of sprints. Teams end up committing into sprint content, with no sustainable tools to manage it. Some say sprint commitment is not necessary, and a sprint should not be thought as a deadline. I’m inclined to agree, but then again, I ask you this: Why have it in the first place?

    Sprints and time-boxing add a lot of artificial noise to a project. That noise has few major undesirable side-effects, the biggest ones being the possible life-threatening health issues and unsustainable teams and projects. In the end, there are other ways to work (like Kanban) that do not have this noise and give more flexibility in return, too.

    If the stakeholders and product owners are not ready to pull the plug on deadlines, product management might be left to play with them on some level. Development teams should not be dealing with deadlines, since they don’t possess the tools to manage them. Rather, the team should focus on the delivery of the tasks and make sure they are delivered in the order that product management sees fit. One could think of it as a layer of protection for the development team. In this case, a team might need to give out estimates on how long each task takes, but that’s still very different from committing to a deadline.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 2019年3月2日:开源日报第352期

    2 3 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《路线图 Nodejs-Developer-Roadmap》
    今日推荐英文原文:《How to PyTorch in Production》

    今日推荐开源项目:《路线图 Nodejs-Developer-Roadmap》传送门:GitHub链接
    推荐理由:相信大家都有看过前端或者后台的学习路线图之类的 Roadmap 了,这次要介绍的是一个关于 Node.js 的路线图,推荐给那些想要学习 Node.js 的朋友或者不知道自己下一步应该学习什么的朋友,其中包括了 web 框架,实时通信,数据库和设计模式等几个大方面。不过别忘了,路线图只是一个指引的作用,自己学会了解什么时候什么工具最适合才是最重要的。
    今日推荐英文原文:《How to PyTorch in Production》作者:Taras Matsyk
    原文链接:https://towardsdatascience.com/how-to-pytorch-in-production-743cb6aac9d4
    推荐理由:如何避免使用 PyTorch 的时候犯下一些常见错误

    How to PyTorch in Production

    ML is fun, ML is popular, ML is everywhere. Most of the companies use either TensorFlow or PyTorch. There are some oldfags who prefer caffe, for instance. Mostly it’s all about Google vs Facebook battle.

    Most of my experience goes to PyTorch, even though most of the tutorials and online tutorials use TensofFlow (or hopefully bare numpy). Currently, at Lalafo (AI-driven classified), we are having fun with PyTorch. No, really, we tried caffe, it is awesome unless you have not spent a few days on installing it already. Even better, PyTorch is 1.0 now, we were using it from 0.3 and it was dead simple and robust. Ahhh.. maybe a few tweaks here, a few tweaks there. Most of the issues were easy to fix and did not cause any problems for us. Walk in the park, really.

    Here, I want to share the most common 5 mistakes for using PyTorch in production. Thinking about using a CPU? Multithreading? Using more GPU memory? We’ve gone through it. Now let me guide you too.

    Mistake #1 — Storing dynamic graph during in the inference mode

    If you have used TensorFlow back in the days, you are probably aware of the key difference between TF and PT — static and dynamic graphs. It was extremely hard to debug TFlow due to rebuilding graph every time your model has changed. It took time, efforts and your hope away too. Of course, TensorFlow is better now.

    Overall, to make debugging easier ML frameworks use dynamic graphs which are related to so-called Variables in PyTorch. Every variable you use links to the previous variable building relationships for back-propagation.

    Here is how it looks in practice:

    In most of cases, you want to optimize all computations after the model has been trained. If you look at the torch interface, there are a lot of options, especially in optimization. A lot of confusion caused by eval mode, detach and no_grad methods. Let me clarify how they work. After the model is trained and deployed here are things you care about: Speed, Speed and CUDA Out of Memory exception
    .

    To speed up pytorch model you need to switch it into eval mode. It notifies all layers to use batchnorm and dropout layers in inference mode (simply saying deactivation dropouts). Now, there is a detach method which cuts variable from its computational graph. It’s useful when you are building model from scratch but not very when you want to reuse State of Art mdoel. A more global solution would be to wrap forward in torch.no_grad context which reduces memory consumptions by not storing graph links in results. It saves memory, simplifies computations thus – you get more speed and less memory used. Bingo!

    Mistake #2 — Not enabling cudnn optimization algorithms

    There is a lot of boolean flags you can set in nn.Module, the one you must be aware of stored in cudnn namespace. To enable cudnn optimization use cudnn.benchmark = True. To make sure cudnn does look for optimal algorithms, enable it by setting cudnn.enabled = True. NVIDIA does a lot of magic for you in terms of optimization which you could benefit from.

    Please be aware your data must be on GPU and model input size should not vary. The more variety in shape of data — the fewer optimizations can be done. To normalize data you can pre-process images, for instance. Overall, be creative, but not too much.

    Mistake #3 — Re-using JIT-compilation

    PyTorch provides an easy way to optimize and reuse your models from different languages (read Python-To-Cpp). You might be more creative and inject your model in other languages if you are brave enough (I am not, CUDA: Out of memory is my motto)

    JIT-compilation allows optimizing computational graph if input does not change in shape. What it means is if your data does not vary too much (see Mistake #2) JIT is a way to go. To be honest, it did not make a huge difference comparing to no_grad and cudnn mentioned above, but it might. This is only the first version and has huge potential.

    Please be aware that it does not work if you have conditions in your model which is a common case in RNNs.

    Full documentation can be found on pytorch.org/docs/stable/jit

    Mistake #4 — Trying to scale using CPU instances

    GPUs are expensive, as VMs in the cloud. Even if you check AWS one instance will cost you around 100$/day (the lowest price is 0.7$/h) Reference: aws.amazon.com/ec2/pricing/on-demand/. Another useful cheatsheet I use is www.ec2instances.info Every person who graduated from 3d grade could think: “Ok, what if I buy 5 CPU instances instead of 1 GPU”. Everyone who has tried to run NN model on CPU knows this is a dead end. Yes, you could optimize a model for CPU, however in the end it still will be slower than a GPU one. I strongly recommend to relax and forget about this idea, trust me.

    Mistake #5 — Processing vectors instead of matrices

    • cudnn – check
    • no_grad – check
    • GPU with correct version of CUDA – check
    • JIT-compilation – check
    Everything is ready, what else can be done?

    Now it’s time to use a bit of math. If you remember how most of NN are trained using so-called Tensor(s). Tensor is an N-dimensional array or multi-linear geometric vectors mathematically speaking. What you could do is to group inputs (if you have a luxury to) into tensors or matrix and feed it into your model. For instance, using an array of images as a matrix sent to PyTorch. Performance gain equals to the number of objects passed simultaneously.

    This is an obvious solution but few people actually using it as most of the time objects are processed one by one and it might be a bit hard to set up such flow architecturally. Do not worry, you’ll make it!

    What’s next?

    There are definitely more tips on how to optimize models in PyTorch. I will continue posting on our experience using Facebook kid in the wild. What about you, what are your tips to achieve better performance on inference?
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 2019年3月1日:开源日报第351期

    1 3 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《workshop frontend-bootcamp》
    今日推荐英文原文:《A Beginner’s Guide to Machine Learning》

    今日推荐开源项目:《workshop frontend-bootcamp》传送门:GitHub链接
    推荐理由:一个关于 web 基础知识的 workshop。第一天介绍了基础知识——新手可以从这里开始学习,有经验的人也可以借此巩固知识;第二天则涉及到应用程序之类的稍稍复杂的主题。项目中也提供了不少的 demo,如果在这之前有过一些关于 web 开发的经验的话,能够从中学到更多的东西。
    今日推荐英文原文:《A Beginner’s Guide to Machine Learning》作者:Shaurya Bhandari
    原文链接:https://blog.usejournal.com/a-beginners-guide-to-machine-learning-5f20f884d574
    推荐理由:用简单的方法介绍机器学习,适合那些需要重温机器学习或者是想要介绍和学习机器学习的人

    A Beginner’s Guide to Machine Learning

    (Easy, plain English explanations accompanied by the math, code, and real-life problem examples)
    “Karma of humans is Artificial Intelligence”

    Who should read this?

    • Technical people who wish to revisit machine learning quickly.
    • Non-technical people who want an introduction to machine learning but have no idea about where to start with.
    • Anybody who thinks machine learning is “hard.”

    Why Machine Learning?

    Artificial Intelligence will shape our future more powerfully than any other innovation, this century. The rate of acceleration of AI is already astonishing. After two AI winters over the past four decades, rapidly growing volumes and varieties of available data, computational processing that is cheaper and more powerful, and affordable data storage, the game is now changing.

    In this post, you will explore core machine learning concepts and algorithms behind all the technology that powers much of our day-to-day lives. By the end of this, you would be able to describe how it functions at the conceptual level and be equipped with the tools to start building similar models and applications yourself.

    Prerequisites to start with machine learning?

    To understand the concepts presented, it is recommended that one meets the following prerequisites:
    • In-depth knowledge of intro-level algebra: One should be comfortable with variables and coefficients, linear equations, calculus and understanding of graphs.
    • Proficiency in programming basics, and some experience coding in Python: No prior experience with machine learning is required, but one should feel comfortable reading and writing Python code that contains basic programming constructs, such as function definitions/invocations, lists, dictionaries, loops, and conditional expressions.
    • Basic knowledge of the following Python libraries:
    1. NumPy
    2. Pandas
    3. SciKit-Learn
    4. SciPy
    5. Matplotlib (and/or Seaborn)

    The Semantic Tree:

    Artificial intelligence is the study of agents that perceive the world around them, form plans, and make decisions to achieve their goals.

    Machine learning is a subfield of artificial intelligence. Its goal is to enable computers to learn on their own. A machine’s learning algorithm enables it to identify patterns in observed data, build models that explain the world, and predict things without having explicit pre-programmed rules and models.

    The semantic tree

    What is Machine Learning?

    Arthur Samuel described machine learning as: “The field of study that gives computers the ability to learn without being explicitly programmed.” This is an older, informal definition which now holds little meaning.
    Tom Mitchell provides a more modern definition: “A computer program is said to learn from experience E with respect to some class of tasks T and performance measure P, if its performance at tasks in T, as measured by P, improves with experience E.”

    In simpler terms, Machine learning is the idea that there are generic algorithms that can tell you something interesting about a set of data without you having to write any custom code which is specific to a problem. Instead of writing code, you feed data to the generic algorithm and it builds its own logic based on the data.

    You can think of machine learning algorithms as falling into one of the three categories ——— Supervised Learning and Unsupervised Learning and Reinforcement Learning.
    • Supervised Learning: A supervised learning algorithm takes labeled data and creates a model that can make predictions given new data. This can be either a classification problem or a regression problem.
    • Unsupervised Learning: Unsupervised learning is when we are dealing with data that has not been labeled or categorized. The goal is to find patterns and create structure in data in order to derive meaning. Two forms of unsupervised learning are clustering and dimensionality reduction.
    • Reinforcement Learning: Reinforcement learning uses a reward system and trial-and-error in order to maximize the long-term reward.

    The workflow in machine learning

    Roadmap to begin with Machine Learning:

    1. The place to start is to learn (and/or) revise linear algebra. MIT has provided an amazing open course on linear algebra. This should introduce you to all the core concepts of linear algebra, and you should pay particular attention to vectors, matrix multiplication, determinants, and Eigenvector decomposition — all of which play pretty heavily as the cogs that make machine learning algorithms work.
    2. After that, calculus should be your next focus. Here you should be most interested in learning and understanding the meaning of derivatives, and how we can use them for optimization. You should make sure to get through all topics in Single Variable Calculus and (at least) sections 1 and 2 of Multivariable Calculus.
    3. Get thorough with Python libraries used in machine learning, mainly Numpy, Pandas, Matplotlib and SKLearn. Machine learning without all these, what I like to call ‘Tools’ would be quite tough.
    4. Get coding! It’s always advised to implement all algorithms from scratch in Python before using the premade models in SciKit – Learn, as it gives you a better and in-depth knowledge of how it works. I personally did the algorithms in the following order of growing complexity, but you may start off anywhere :
    • Linear Regression
    • Logistic Regression
    • Naive Bayes Classifier
    • K – Nearest Neighbors (KNN)
    • K – Means
    • Support Vector Machine (SVM)
    • Decision Trees
    • Random Forests
    • Gradient Boosting

    Algorithm Implementation Roadmap:

    1. Get data to work on. There are millions of data sets available on the internet, catering to even the weirdest of your needs. Kaggle and UCI are great resources to look out for data sets. One can also generate her/his own data as I have done in a few of my algorithm implementations.
    2. Choosing an algorithm(s). Once you have the data in a good place to work with it, you can start trying different algorithms. The image below is a rough guide. (From SKLearn’s documentation)

    At this stage, I highly recommend you to go through the short theory of each algorithm that I have uploaded on my Github with each implementation. You can also go through Joel Grus’s Github, where he has documented all the implementations from his book, “Data Science from Scratch”.
    1. Visualise the data! Python has various libraries such as Matplotlib and Seaborn that help us plot the data and then the final result, to help us get a better intuition of your data and what you will be doing. (and of course, makes the model look fancy!)

    2. Tune the algorithm. All the models that we implement, have tons of buttons and knobs to play around with, better known as hyper-parameters. The learning rate, the k value, etc. all can be changed to get the best possible model.

    3. Evaluate the model. The Python library, SKLearn provides a lot of tools to evaluate your model and check for metrics such as accuracy, f1 score, precision etc.

    Side notes:

    • Once you get familiar with a few algorithms and concepts, jump into one short term project(s) that isn’t super complex (to begin with).
    • Don’t be afraid to fail. The majority of your time, in the beginning, will be spent trying to figure out the math, or how and why an error popped up. But, tenacity is key.
    • These small models are a sandbox for learning a lot by failing — so make use of it and give everything a try, even if it doesn’t really make sense to someone else. If it makes sense to you, it might turn out to be the best fit model.
    • Helpful resources to get started with Python:

    https://www.python-course.eu/index.php
    Learning Python the hard way (book)

    • Helpful resources for the math used in machine learning:
    https://ocw.mit.edu/courses/mathematics/18-06-linear-algebra-spring-2010/video-lectures
    https://ocw.mit.edu/courses/mathematics/18-01-single-variable-calculus-fall-2006/video-lectures
    https://ocw.mit.edu/courses/mathematics/18-02sc-multivariable-calculus-fall-2010/index.htm
    Math4ML (book)
    Elements of Statistical Learning (book)
    • The best way to go around Python libraries is either through Datacamp courses or directly through their official documentation.
    • If you really wish to dive deep into machine learning then I would recommend you to start with any one of the following :
    Andrew Ng’s Machine Learning course on Coursera (free, easier)
    CS-229 course by Stanford University (free, relatively tougher, complex math)
    All that I discussed above can be found on my Github, in the Machine-Learning repository. All the algorithms are systematically arranged, with both implementations from scratch and using SciKit-Learn. The data sets used are provided with each and also there is a short theory report about how the algorithms work, along with a real-life example.

    I personally decided to get thorough with machine learning first before starting off with Deep Learning and I advise you to do the same, it is not necessary to go with the herd, just because Deep Learning is the new, hot topic in the industry.

    Feel free to point out any mistakes you find, constructive criticism does no harm.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 2019年2月28日:开源日报第350期

    28 2 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《自动格式 cleave.js》
    今日推荐英文原文:《What are the limits of deep learning?》

    今日推荐开源项目:《自动格式 cleave.js》传送门:GitHub链接
    推荐理由:想必在输入框里输入日期时间电话这些已经是司空见惯的事情了,但是日期有日期的格式电话有电话的格式,让用户自己输入格式又略显麻烦,这个时候这个 JS 库就能帮上忙了。这个库能够帮你为输入框附加自动的格式,你只需要实现确定好输入框中内容的格式,就能让用户输入时自动根据这个格式输入——当然,格式由这个库来补足。他们的官网上提供了很多 demo,如果刚好有这方面的需要的话,这会是个不错的选择。

    今日推荐英文原文:《What are the limits of deep learning?》作者:Proceedings of the National Academy of Sciences
    原文链接:https://medium.com/proceedings-of-the-national-academy-of-sciences/what-are-the-limits-of-deep-learning-e866a1d024f7
    推荐理由:在长久的人生中,我终于意识到,深度学习是有局限的,所以……

    What are the limits of deep learning?

    The much-ballyhooed artificial intelligence approach boasts impressive feats but still falls short of human brainpower. Researchers are determined to figure out what’s missing.

    There’s no mistaking the image: It’s a banana — a big, ripe, bright-yellow banana. Yet the artificial intelligence (AI) identifies it as a toaster, even though it was trained with the same powerful and oft-publicized deep-learning techniques that have produced a white-hot revolution in driverless cars, speech understanding, and a multitude of other AI applications. That means the AI was shown several thousand photos of bananas, slugs, snails, and similar-looking objects, like so many flash cards, and then drilled on the answers until it had the classification down cold. And yet this advanced system was quite easily confused — all it took was a little day-glow sticker, digitally pasted in one corner of the image.

    Apparent shortcomings in deep-learning approaches have raised concerns among researchers and the general public as technologies such as driverless cars, which use deep-learning techniques to navigate, get involved in well-publicized mishaps. Image credit: Shutterstock.com/MONOPOLY919.

    This example of what deep-learning researchers call an “adversarial attack,” discovered by the Google Brain team in Mountain View, CA, highlights just how far AI still has to go before it remotely approaches human capabilities. “I initially thought that adversarial examples were just an annoyance,” says Geoffrey Hinton, a computer scientist at the University of Toronto and one of the pioneers of deep learning. “But I now think they’re probably quite profound. They tell us that we’re doing something wrong.”

    That’s a widely shared sentiment among AI practitioners, any of whom can easily rattle off a long list of deep learning’s drawbacks. In addition to its vulnerability to spoofing, for example, there is its gross inefficiency. “For a child to learn to recognize a cow,” says Hinton, “it’s not like their mother needs to say ‘cow’ 10,000 times” — a number that’s often required for deep-learning systems. Humans generally learn new concepts from just one or two examples.

    Then there’s the opacity problem. Once a deep-learning system has been trained, it’s not always clear how it’s making its decisions. “In many contexts that’s just not acceptable, even if it gets the right answer,” says David Cox, a computational neuroscientist who heads the MIT-IBM Watson AI Lab in Cambridge, MA. Suppose a bank uses AI to evaluate your credit-worthiness and then denies you a loan: “In many states there are laws that say you have to explain why,” he says.

    And perhaps most importantly, there’s the lack of common sense. Deep-learning systems may be wizards at recognizing patterns in the pixels, but they can’t understand what the patterns mean, much less reason about them. “It’s not clear to me that current systems would be able to see that sofas and chairs are for sitting,” says Greg Wayne, an AI researcher at DeepMind, a London-based subsidiary of Google’s parent company, Alphabet.

    Increasingly, such frailties are raising concerns about AI among the wider public, as well — especially as driverless cars, which use similar deep-learning techniques to navigate, get involved in well-publicized mishaps and fatalities. “People have started to say, ‘Maybe there is a problem’,” says Gary Marcus, a cognitive scientist at New York University and one of deep learning’s most vocal skeptics. Until the past year or so, he says, “there had been a feeling that deep learning was magic. Now people are realizing that it’s not magic.”

    Still, there’s no denying that deep learning is an incredibly powerful tool — one that’s made it routine to deploy applications such as face and voice recognition that were all but impossible just a decade ago. “So I have a hard time imagining that deep learning will go away at this point,” Cox says. “It is much more likely that we will modify it, or augment it.”

    Brain Wars

    Today’s deep-learning revolution has its roots in the “brain wars” of the 1980s when advocates of two different approaches to AI were talking right past each other.

    On one side was an approach — now called “good old-fashioned AI” — that had dominated the field since the 1950s. Also known as symbolic AI, it used mathematical symbols to represent objects and the relationship between objects. Coupled with extensive knowledge bases built by humans, such systems proved to be impressively good at reasoning and reaching conclusions about domains such as medicine. But by the 1980s, it was also becoming clear that symbolic AI was impressively bad at dealing with the fluidity of symbols, concepts, and reasoning in real life.

    In response to these shortcomings, rebel researchers began advocating for artificial neural networks, or connectionist AI, the precursors of today’s deep-learning systems. The idea in any such system is to process signals by sending them through a network of simulated nodes: analogs of neurons in the human brain. The signals pass from node to node along connections, or links: analogs of the synaptic junctions between neurons. And learning, as in the real brain, is a matter of adjusting the “weights” that amplify or damp the signals carried by each connection.

    In practice, most networks arrange the nodes as a series of layers that are roughly analogous to different processing centers in the cortex. So a network specialized for, say, images would have a layer of input nodes that respond to individual pixels in somewhat the same way that rod and cone cells respond to light hitting the retina. Once activated, these nodes propagate their activation levels through the weighted connections to other nodes in the next level, which combine the incoming signals and are activated (or not) in turn. This continues until the signals reach an output layer of nodes, where the pattern of activation provides an answer — asserting, for example, that the input image was the number “9.” And if that answer is wrong — say that the input image was a “0” — a “backpropagation” algorithm works its way back down through the layers, adjusting the weights for a better outcome the next time.

    By the end of the 1980s, such neural networks had turned out to be much better than symbolic AI at dealing with noisy or ambiguous input. Yet the standoff between the two approaches still wasn’t resolved — mainly because the AI systems that could fit into the computers of the time were so limited. It was impossible to know for sure what those systems were capable of.

    Power Boost

    “Neural network” models of AI process signals by sending them through a network of nodes analogous to neurons. Signals pass from node to node along links, analogs of the synaptic junctions between neurons. “Learning” improves the outcome by adjusting the weights that amplify or damp the signals each link carries. Nodes are typically arranged in a series of layers that are roughly analogous to different processing centers in the cortex. Today’s computers can handle “deep-learning” networks with dozens of layers. Image credit: Lucy Reading-Ikkanda (artist).

    That understanding began to advance only in the 2000s, with the advent of computers that were orders of magnitude more powerful and social media sites offering a tsunami of images, sounds, and other training data. Among the first to seize this opportunity was
    “These challenges are real, but they’re not a dead end.” — Matthew Botvinick
    Hinton, coauthor of the backpropagation algorithm and a leader of the 1980s-era connectionist movement. By mid-decade, he and his students were training networks that were not just far bigger than before. They were considerably deeper, with the number of layers increasing from one or two to about half a dozen. (Commercial networks today often use more than 100.)

    In 2009, Hinton and two of his graduate students showed that this kind of “deep learning” could recognize speech better than any other known method. In 2012, Hinton and two other students published experiments showing that deep neural networks could be much better than standard vision systems at recognizing images. “We almost halved the error rates,” he says. With that double whammy in speech and image recognition, the revolution in deep-learning applications took off — as did researchers’ efforts to improve the technique.

    One early priority was to expand the ways that deep-learning systems could be trained, says Matthew Botvinick, who in 2015 took leave from his neuroscience group at Princeton to do a year’s sabbatical at DeepMind and never left. Both the speech- and image-recognition systems used what’s called supervised learning, he says: “That means for every picture, there is a right answer — say, ‘cat’ — and if the network is wrong, you tell it what the right answer is.” The network then uses the backpropagation algorithm to improve its next guess.

    Supervised learning works great, says Botvinick — if you just happen to have a few hundred thousand carefully labeled training examples lying around. That’s not often the case, to put it mildly. And it simply doesn’t work for tasks such as playing a video game where there are no right or wrong answers — just strategies that succeed or fail.

    For those situations — and indeed, for much of life in the real world — you need reinforcement learning, Botvinick explains. For example, a reinforcement learning system playing a video game learns to seek rewards (find some treasure) and avoid punishments (lose money).

    The first successful implementation of reinforcement learning on a deep neural network came in 2015 when a group at DeepMind trained a network to play classic Atari 2600 arcade games. “The network would take in images of the screen during a game,” says Botvinick, who joined the company just afterward, “and at the output end were layers that specified an action, like how to move the joystick.” The network’s play equaled or surpassed that of human Atari players, he says. And in 2016, DeepMind researchers used a more elaborate version of the same approach with AlphaGo — a network that mastered the complex board game Go — and beat the world-champion human player.

    Beyond Deep Learning

    Unfortunately, neither of these milestones solved the fundamental problems of deep learning. The Atari system, for example, had to play thousands of rounds to master a game that most human players can learn in minutes. And even then, the network had no way to understand or reason about on-screen objects such as paddles. So Hinton’s question remains as valid as ever: What’s missing?

    Maybe nothing. Maybe all that’s required is more connections, more layers, and more sophisticated methods of training. After all, as Botvinick points out, it’s been shown that neural networks are mathematically equivalent to a universal computer, which means there is no computation they cannot perform — at least in principle, if you can ever find the right connection weights.

    But in practice, those caveats can be killers — one big reason why there is a growing feeling in the field that deep learning’s shortcomings require some fundamentally new ideas.

    One solution is simply to expand the scope of the training data. In an article published in May 2018, for example, Botvinick’s DeepMind group studied what happens when a network is trained on more than one task. They found that as long as the network has enough “recurrent” connections running backward from later layers to earlier ones — a feature that allows the network to remember what it’s doing from one instant to the next — it will automatically draw on the lessons it learned from earlier tasks to learn new ones faster. This is at least an embryonic form of human-style “meta-learning,” or learning to learn, which is a big part of our ability to master things quickly.

    A more radical possibility is to give up trying to tackle the problem at hand by training just one big network and instead have multiple networks work in tandem. In June 2018, the DeepMind team published an example they call the Generative Query Network architecture, which harnesses two different networks to learn its way around complex virtual environments with no human input. One, dubbed the representation network, essentially uses standard image-recognition learning to identify what’s visible to the AI at any given instant. The generation network, meanwhile, learns to take the first network’s output and produce a kind of 3D model of the entire environment — in effect, making predictions about the objects and features the AI doesn’t see. For example, if a table only has three legs visible, the model will include a fourth leg with the same size, shape, and color.

    These predictions, in turn, allow the system to learn quite a bit faster than with standard deep-learning methods, says Botvinick. “An agent that is trying to predict things gets feedback automatically on every time-step, since it gets to see how its predictions turned out.” So it can constantly update its models to make them better. Better still, the learning is self-supervised: the researchers don’t have to label anything in the environment for it to work or even provide rewards and punishments.

    An even more radical approach is to quit asking the networks to learn everything from scratch for every problem. The blank-slate approach does leave the networks free to discover ways of representing objects and actions that researchers might never have thought of, as well as some totally unexpected game-playing strategies. But humans never start with a blank slate: for almost any task, they can bank on at least some prior knowledge that they’ve learned through experience or that was hardwired into their brains by evolution.

    Infants, for example, seem to be born with many hardwired “inductive biases” that prime them to absorb certain core concepts at a prodigious rate. By the age of 2 months, they are already beginning to master the principles of intuitive physics, which includes the notion that objects exist, that they tend to move along continuous paths, and that when they touch they don’t just pass through each other. Those same infants are also beginning to learn the basics of intuitive psychology, which includes an ability to recognize faces and a realization that the world contains agents that move and act on their own.

    Having this kind of built-in inductive biasing would presumably help deep neural networks learn just as rapidly, which is why many researchers in the field are now making it a priority. Within just the past 1 or 2 years, in fact, the field has seen a lot of excitement over a potentially powerful approach known as the graph network. “These are deep-learning systems that have an innate bias toward representing things as objects and relations,” says Botvinick.

    For example, certain objects such as paws, tail, and whiskers might all belong to a larger object (cat) with the relationship is-a-part-of. Likewise, Ball A and Block B might have the mutual relationship is-next-to, the Earth would have the relationship is-in-orbit-around the Sun, and so on through a huge range of other examples — any of which could be represented as an abstract graph in which the nodes correspond to objects and the links to relationships.

    A graph network, then, is a neural network that takes such a graph as input — as opposed to raw pixels or sound waves — then learns to reason about and predict how objects and their relationships evolve over time. (In some applications, a separate, standard image-recognition network might be used to analyze a scene and pick out the objects in the first place.)

    The graph-network approach has already demonstrated rapid learning and human-level mastery of a variety of applications, including complex video games. If it continues to develop as researchers hope, it could ease deep learning’s 10,000-cow problem by making training much faster and more efficient. And it could make the networks far less vulnerable to adversarial attacks simply because a system that represents things as objects, as opposed to patterns of pixels, isn’t going to be so easily thrown off by a little noise or an extraneous sticker.

    Fundamental progress isn’t going to be easy or fast in any of these areas, Botvinick acknowledges. But even so, he believes that the sky’s the limit. “These challenges are real,” he says, “but they’re not a dead end.”
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
←上一页
1 … 171 172 173 174 175 … 262
下一页→

Proudly powered by WordPress