Curated by T Ashok @ash_thiru

Summary

This article is curated from SIX articles as a quick primer on AI. Starting with a glossary on AI, it delves into tacit knowledge as codified via ML  and understanding the difference between ML & AI. A quick peek into deep learning and challenges of explaining the patterns ending with a interesting piece AI written by an AI program.

---

Glossary of terminology in AI

Here is an easy article “A Simple, yet Technical Glossary of Terminology in AI” that provides simple glossary of terms, abbreviations, and concepts related to the field and sub-fields of artificial intelligence. Based on technical definitions by pioneers and leaders in AI.

ML & Polanyi’s paradox

“Explicit knowledge is formal, codified, and can be readily explained to people and captured in a computer program. But tacit knowledge, a concept first introduced in the 1950s by scientist and philosopher Michael Polanyi, is the kind of knowledge we’re often not aware we have, and is therefore difficult to transfer to another person, let alone capture in a computer program. Machine learning has enabled AI to get around one of its biggest obstacles, the so-called Polanyi’s paradox.” Read more in this article ”What Machine Learning Can and Cannot Do“

ML & AI – The difference (1)

There’s much confusion surrounding AI and ML. Some people refer to AI and ML as synonyms and use them interchangeably, while others use them as separate, parallel technologies. In many cases, the people speaking and writing about the technology don’t know the difference between AI and ML. In others, they intentionally ignore those differences to create hype and excitement for marketing and sales purposes.” This article  “Why the difference between AI and machine learning matters” attempts to disambiguate the jargon and myths surrounding AI.

ML & AI – The difference (2)

“Unfortunately, some tech organizations are deceiving customers by proclaiming using AI on their technologies while not being clear about their products’ limits. There’s still a lot of confusion within the public and the media regarding what truly is artificial intelligence, and what truly is machine learning. Often the terms are being used as synonyms, in other cases, these are being used as discrete, parallel advancements, while others are taking advantage of the trend to create hype and excitement, as to increase sales and revenue.” says Roberto Irliondo in his article “Machine Learning vs. AI, Important Differences Between Them”.

Explaining how patterns are connected

Deep learning is good at finding patterns in reams of data, but can’t explain how they’re connected. Turing Award winner Yoshua Bengio wants to change that, read about this is this article “An AI Pioneer Wants His Algorithms to Understand the ‘Why’“

Chapter on AI written by a AI program

Here is an interesting excerpt from an ‘autobiographical’ chapter written by an AI program “This chapter on the future of Artificial Intelligence was written by Artificial Intelligence”, excerpted from the book “The Tech Whispererer”.

---

Summary

What it takes to “Build with quality” ? Girish Elchuri outlines that it takes a good modern micro-services architecture, a robust design that is modular, adopting a zero trust programming mentality and documenting specifications & design to enabling good test cases.

The video of this “nano learning” smartbits video is available here.

---

When we are developing a product, we all know that apart from the functional requirements, the quality requirements are also equally important. It is important that the product works as per the functions and also as per the quality, and that must start from architecture. You should have an architecture which is as per the current trends going with the micro-services so that it becomes much easier to test it out for each service independently.

Then we look at the design. You need to have a robust design, preferably in a modular way which will simplify the process of testing because it is always easy to test a small portion than a big monotonous thing. That is the second thing you need to look at; having a design which is very modular so that you can do a plug and play much easily including testing.

The third thing that you would look at is what I call a zero-trust programming. When you are developing or programming, you don’t trust anything. For example, even if you are getting parameters from your own functions, you don’t trust them, you just verify them once again. Basically, the way to do programming is to do a lot of validation of the parameters, validation of the context and whole lot of other things and when you know everything is right, then go into the functionality. This way, you are catching a lot of errors that are possible, upfront rather than in the logic and kind of having the runtime issues.

After that, you have to also make sure that you put enough effort to write the functional specs and design documents, because that is one aspect that people always ignore. Primarily, if you have a good functional specs and design documents, it becomes that much easy for the testing/quality team to design the test cases. So, I would say that you should have a holistic approach to quality rather than a very narrow focus of testing it post product development and then suffer a lot.

click to video

---