jump to navigation

Bias and Truth and AI, Oh My October 4, 2017

Posted by Peter Varhol in Machine Learning, Software development, Technology and Culture.
Tags: ,
add a comment

I was just accepted to speak at the Toronto Machine Learning Summit next month, a circumstance that I never thought might happen.  I am not an academic researcher, after all, and while I have jumped back into machine learning after a hiatus of two decades, many more are fundamentally better at it than me.

The topic is Cognitive Bias in AI:  What Can Go Wrong?  It’s rather a follow-on from the presentations I’ve done on bias in software development and testing, but it doesn’t really fit into my usual conferences, so I attempted to cast my net into new waters.  For some reason, the Toronto folks said yes.

But it mostly means that I have to actually write the presentation.  And here is the rub:  We tend to believe that intelligent systems are always correct, and in those rare circumstances where they are not, it is simply the result of a software bug.

No.  A bug is a one-off error that can be corrected in code.  A bias is a systematic adjustment toward a predetermined conclusion that cannot be fixed with a code change.  At the very least the training data and machine learning architecture have to be re-thought.

And we have examples such as these:

If you’re not a white male, artificial intelligence’s use in healthcare could be dangerous.

When artificial intelligence judges a beauty contest, white people win.

But the fundamental question, as we pursue solutions across a wide range of applications, is:  Do we want human decisions, or do we want correct ones?  That’s not to say that all human decisions are incorrect, but only to point out that much of what we decide is colored by our bias.

I’m curious about what AI applications decide about this one.  Do we want to eliminate the bias, or do we want to reflect the values of the data we choose to use?  I hope the former, but the latter may win out, for a variety of reasons.

Advertisements

In the Clutch September 28, 2017

Posted by Peter Varhol in Algorithms, Machine Learning, Software development, Technology and Culture.
Tags: , ,
add a comment

I wrote a little while back about how some people are able to recognize the importance of the right decision or action in a given situation, and respond in a positive fashion.  We often call that delivering in the clutch.  This is as opposed to machine intelligence, which at least right now is not equipped to understand and respond to anything regarding the importance of a particular event in a sequence.

The question is if these systems will ever be able to tell that a particular event has outsized importance, and if they can use this information to um, try harder.

I have no doubt that we will be able to come up with metrics that can inform a machine learning system of a particularly critical event or events.  Taking an example from Moneyball of an at-bat, we can incorporate the inning, score, number of hits, and so on.  In other problem domains, such as application monitoring, we may not yet be collecting the data that we need, but given a little thought and creativity, I’m sure we can do so.

But I have difficulty imagining that machine learning systems will be able to rise to the occasion.  There is simply no mechanism in computer programming for that to happen.  You don’t save your best algorithms for important events; you use them all the time.  For a long-running computation, it may be helpful to add to the server farm, so you can finish more quickly or process more data, but most learning systems won’t be able or equipped to do that.

But code is not intelligence.  Algorithms cannot feel a sense of urgency to perform at the highest level; they are already performing at the highest level of which they are capable.

To be fair, at some indeterminate point in the future, it may be possible for algorithms to detect the need for new code pathways, and call subroutines to make those pathways a reality (or ask for humans to program them).  They may recognize that a particular result is suboptimal, and “ask” for additional data to make it better.  But why would that happen only for critical events?  We would create our systems to do that for any event.

Today, we don’t live in the world of Asimov’s positronic brains and the Three Laws of Robotics.  It will be a while before science is at that point, if ever.

Is this where human achievement can perform better than an algorithm?  Possibly, if we have the requisite human expertise.  There are a number of well-known examples where humans have had to take over when machines failed, some successfully, some unsuccessfully.  But the human has to be there, and has to be equipped professionally and mentally to do so.  That is why I am a strong believer in the human in the loop.

The Human In the Loop September 19, 2017

Posted by Peter Varhol in Software development, Strategy, Technology and Culture.
Tags: ,
1 comment so far

A couple of years ago, I did a presentation entitled “Famous Software Failures”.  It described six events in history where poor quality or untested software caused significant damage, monetary loss, or death.

It was really more about system failures in general, or the interaction between hardware and software.  And ultimately is was about learning from these failures to help prevent future ones.

I mention this because the protagonist in one of these failures passed earlier this year.  Stanislav Petrov, a Soviet military officer who declined to report a launch of five ICBMs from the United States, as reported by their defense systems.  Believing that a real American offensive would involve many more missiles, Lieutenant Colonel Petrov refused to acknowledge the threat as legitimate and contended to his superiors that it was a false alarm (he was reprimanded for his actions, incidentally, and permitted to retire at his then-current rank).  The false alarm had been created by a rare alignment of sunlight on high-altitude clouds above North Dakota.

There is also a novel by Daniel Suarez, entitled Kill Decision, that postulates the rise of autonomous military drones that are empowered to make a decision on an attack without human input and intervention.  Suarez, an outstanding thriller writer, writes graphically and in detail of weapons and battles that we are convinced must be right around the next technology bend, or even here today.

As we move into a world where critical decisions have to be made instantaneously, we cannot underestimate the value of the human in the loop.  Whether the decision is made with a focus on logic (“They wouldn’t launch just five missiles”) or emotion (“I will not be remembered for starting a war”), it puts any decision in a larger and far more real context than a collection of anonymous algorithms.

The human can certainly be wrong, of course.  And no one person should be responsible for a decision that can cause the death of millions of people.  And we may find ourselves outmaneuvered by an adversary who relies successfully on instantaneous, autonomous decisions (as almost happened in Kill Decision).

As algorithms and intelligent systems become faster and better, human decisions aren’t necessarily needed or even desirable in a growing number of split-second situations.  But while they may be pushed to the edges, human decisions should not be pushed entirely off the page.

 

What Brought About our AI Revolution? July 22, 2017

Posted by Peter Varhol in Algorithms, Software development, Software platforms.
Tags: , , ,
add a comment

Circa 1990, I was a computer science graduate student, writing forward-chaining rules in Lisp for AI applications.  We had Symbolics Lisp workstations, but I did most of my coding on my Mac, using ExperList or the wonderful XLisp written by friend and colleague David Betz.

Lisp was convoluted to work with, and in general rules-based systems required that there was an expert available to develop the rules.  It turns out that it’s very difficult for any human expert to described in rules how they got a particular answer.  And those rules generally couldn’t take into account any data that might help it learn and refine over time.

As a result, most rules-based systems fell by the wayside.  While they could work for discrete problems where the steps to a conclusion were clearly defined, they weren’t very useful when the problem domain was ambiguous or there was no clear yes or no answer.

A couple of years later I moved on to working with neural networks.  Neural networks require data for training purposes.  These systems are made up of layered networks of equations (I used mostly fairly simple polynomial expressions, but sometimes the algorithms can get pretty sophisticated) that adapt based on known inputs and outputs.

Neural networks have the advantage of obtaining their expertise through the application of actual data.  However, due to the multiple layers of algorithms, it is usually impossible to determine how the system arrives at the answers it does.

Recently I presented on machine learning at the QUEST Conference in Chicago and at Expo:QA in Spain.  In interacting with the attendees, I realized something.  While some data scientists tend to use more complex algorithms today, the techniques involved in neural networks for machine learning are pretty much the same as they were when I was doing it, now 25 years ago.

So why are we having the explosion in machine learning, AI, and intelligent systems today?  When I was asked that question recently, I realized that there was only one possible answer.

Computing processing speeds continue to follow Moore’s Law (more or less), especially when we’re talking floating point SIMD/parallel processing operations.  Moore’s Law doesn’t directly relate to speed or performance, but there is a strong correlation.  And processors today are now fast enough to execute complex algorithms with data applied in parallel.  Some, like Nvidia, have wonderful GPUs that turn out to work very well with this type of problem.  Others, like Intel, have released an entire processor line dedicated to AI algorithms.

In other words, what has happened is that the hardware caught up to the software.  The software (and mathematical) techniques are fundamentally the same, but now the machine learning systems can run fast enough to actually be useful.

Please Explain to Me Why Uber Isn’t Toast May 5, 2017

Posted by Peter Varhol in Software development, Technology and Culture.
Tags: ,
1 comment so far

Uber is in the process of transforming the taxi industry. In general, that’s a good thing.  Mostly (more on that in a later post).

Everything else about Uber is a very bad thing.

First, it is about professional drivers, not ride sharing. Anyone who hasn’t figured that out by now needs to go directly to jail, and not pass Go.  When was the last time you personally shared your car with strangers, seriously?  This is absolutely not about ride sharing, and you know that, despite the drivel coming out of the company.

Second, it is about treating their drivers as poorly as possible, but keeping them onboard until they can get to driverless vehicles. Its CEO has already told us all how he treats his drivers.  All drivers will be jettisoned at the moment driverless cars become viable.  And, yes again, this is about professional drivers, not ride sharing.

Third, it is about a scofflaw culture that operates illegally, then claims it is misunderstood, or that laws are simply things that get in its way, or something that makes it superior.

Last, it is an employer that celebrates the bro culture, that takes everything that it can from its employees and delivers nothing in return, especially those who are not white, male, and affluent. Especially affluent.  Except for its drivers.  Let’s keep them poor and hungry.  Until the time we cut them all loose.

I realize that none of this is a damnable business problem (sometimes business itself is damned). But it should be, and it will be, in the not-to-distant future.

For you VCs out there, I fully appreciate how Uber is upending an industry. But it is poison as a company and an investment.  Get out if you can; no, get out at any cost.

About Licenses, Certifications, and Tech Jobs April 14, 2017

Posted by Peter Varhol in Education, Software development, Technology and Culture.
Tags: ,
add a comment

As an academic, 25 years ago, I postulated to my students that software developers would require certifications and licenses at some point in time to pursue their craft. I was widely ridiculed at the time, so I would like to revisit that position today.

First, I want people to understand that I have no particular qualifications to write on this topic (that is ironic, based on the sentiment of this post).

We are facing two forces here. One is that innovation comes from at least partly those who have breakthrough ideas, from any field, without necessarily having formal training in that field.  While certainly true in software, I would imagine it true in other professional fields as well.

The second is that we as a society are increasingly depending upon software, and in particular software working correctly. This means we are vitally interested in having people who are working in that field are in some way qualified to do what they do.

And what does that mean? As in other professional fields, it means that we have studied formally, taken tests, and achieved a level of competence that is quantitatively identifiable and measureable.  In other words, we have a degree in the field, and we have passed one or more tests.

In the late 1980s, I worked for a defense contractor who was required to assure the DOD that its employees all had technical degrees. At that time, my MS in applied math qualified in that regard, so I passed muster.  Other long-time employees did not.  Did that make me better than them?  I don’t think so, but it made me more credentialed.

It has gotten worse since then. As we have self-driving cars, high-speed financial trading systems, fly-by-wire aircraft, and a myriad of other essential and safety-critical systems, we feel the need to have a level of confidence in the professionals behind them.  That confidence may be misplaced, but it is backed by a degree and/or certification.

In The Complacent Class, economist Tyler Cowen notes that in the 1950s, five percent of workers required a government-issued license in order to do their jobs, but by 2008, 29 percent did.  At many of the software conferences that I participate in, smart and serious professionals compare professional qualifications and job requirements.  It seems increasingly difficult to obtain employment without these certifications; in fact, I met many mid-career people who feel they need to become certified to continue their careers at a high level.

I don’t know the answer to this. I would like to think that some mixture of educated, certified professionals and unqualified-on-paper but passionate and self-educated people are essential in software.

But. Employers are increasingly looking for people who have credentials, usually those provided by a professional society (at least in software), that say they have studied and passed a test.  The problem is that such a thing may or may not have anything to do with their competence, knowledge, dedication, or ability to deliver on a project or task.

Increasingly, we as a society are not allowing for the mixture of qualified-on-paper and passionate-by-nature. I do believe that is wrong, but we are not willing to take the time and effort to identify those who can seriously contribute from those who have passed a test.

Decisions, Decisions – There’s an Algorithm for That March 20, 2017

Posted by Peter Varhol in Software development, Strategy, Technology and Culture.
Tags: , ,
add a comment

I remember shoveling sh** against the tide. Yes, I taught statistics and decision analysis to university business majors for about 15 years.  It wasn’t so much that they didn’t care as they didn’t want to know.

I had more than one student tell me that it was the job of a manager to make decisions, and numbers didn’t make any difference. Others said, “I make decisions the way they are supposed to be made, by my experience and intuition.  That’s what I’m paid for.”

Well, maybe not too much longer. After a couple of decades of robots performing “pick-and-place” and other manufacturing processes, now machine learning is in the early stages of transforming management.  It will help select job candidates, determine which employees are performing at a high level, and allocate resources between projects, among many other things.

So what’s a manager to do? Well, first, embrace the technology.  Simply, you are not going to win if you fight it.  It is inevitable.

Second, make a real effort to understand it. While computers and calculators were available, I always made my students “do it by hand” the first time around, so they could follow what the calculations were telling them.  You need to know what you are turning your decisions over to.

Third, integrate it into your work processes. By using machine learning to complement your own abilities.  Don’t ignore it, but don’t treat it as gospel either.

There are many philosophical questions at work here. Which is better, your experience or the numbers?  Kahneman says they are about the same, which does not bode well for human decision-making.  And the analysis of the numbers will only get better; can we say the same thing about human decision-making?

Of course, this has implications to the future of management. I’ll explore my thoughts there in a future post.

AI: Neural Nets Win, Functional Programming Loses October 4, 2016

Posted by Peter Varhol in Software development, Software platforms, Uncategorized.
Tags: , , ,
add a comment

Today, we might be considered to be in the heady early days of AI commercialization. We have pretty decent speech recognition, and pattern recognition in general.  We have engines that analyze big data and produce conclusions in real time.  We have recommendations engines; while not perfect, they seem to be to be profitable for ecommerce companies.  And we continue to hear the steady drumbeat of self-driving cars, if not today, then tomorrow.

I did graduate work in AI, in the late 1980s and early 1990s. In most universities at the time, this meant that you spent a lot of time writing Lisp code, that amazing language where everything is a function, and you could manipulate functions in strange and wonderful ways.  You might also play around a bit with Prolog, a streamlined logic language that made logic statements easy, and everything else hard.

Later, toward the end of my aborted pursuit of a doctorate, I discovered neural networks. These were not taught in most universities at the time.  If I were to hazard a guess as to why, I would say that they were both poorly understood and not worthy of serious research.  I used a commercial neural network package to build an algorithm for an electronic wind sensor, and it was actually not nearly as difficult as writing a program from scratch in Lisp.

I am long out of academia, so I can’t say what is happening there today. But in industry, it is clear that neural networks have become the AI approach of choice.  There are tradeoffs of course.  You will never understand the underlying logic of a neural network; ultimately, all you really know is that it works.

As for Lisp, although it is a beautiful language in many ways, I don’t know of anyone using it for commercial applications. Most neural network packages are in C/C++, or they generate C code.

I have a certain distrust of academia. I think it came into full bloom during my doctoral work, in the early 1990s, when a professor stated flatly to the class, “OSI will replace Ethernet in a few years, and when that happens, many of our network problems will be solved.”

Never happened, of course, and the problems were solved anyway, but this tells you what kind of bubble academics live in. We have a specification built by a committee of smart people, almost all academics, and of course it’s going to take over the world.  They failed to see the practical roadblocks involved.

And in AI, neural networks have clearly won the day, and while we can’t necessarily follow the exact chain of logic, they generally do a good job.

Update:  Rather than functional programming, I should have called the latter (traditional) AI technique rules-based.  We used Lisp to create rules that spelled up what to do with combinations of discrete rules.