This blog is all about the automatic generation of narratives from data. It looks at what it means to generate stories, reports, tweets, powerpoint, email, etc. all based on a substrate of data. My focus is on the current state of the technology and the implications and opportunities it presents for news, media organizations, audience, and businesses that sit on large data repositories.

Wednesday, March 14, 2012

The Problem with Expert Systems or Why We Configure Our Authoring Engine

When Narrative Science works with clients, our standard engagement model is to take data as the starting point and sample documents as the target and then configure our authoring engine to transform the former into the latter. Our interactions are focused on working with clients to capture editorial goals, structure and voice in order to best configure the Narrative Science authoring engine to meet their needs.

Occasionally, an organization will ask us of why we don’t simply license the technology to them and let their own team do all of the work. While this type of engagement is on both our business and technology road maps, we have some very specific reasons for not doing so at this point. In large part, these are lessons learned from the field of Artificial Intelligence and the painful history of Rule-Based Expert System shells.

With that in mind, we thought it might be useful to hit on the high points of this history in order to help everyone understand why working with us still involves talking with people.

Expert Systems

The idea behind Rule Based Expert Systems is a straightforward one.

Step one: Start with an engine that will take rules, if-then rules in particular, and run those rules from some start some state to a conclusion.

Step two: For any given subject area, write down all the rules that an expert would use to solve problems in that space. Often these rules are expressed as a decision tree.

Step three: Write down all of the baseline facts that are true (and relevant) in the subject domain so the system has access to basic information about the world.

Step four: Give the system some new facts that will trigger rules and let it run to conclusion.

Now you have an expert system. In fact you have a classic rule-based expert system.

But given how easy this is, why don’t we have a million of these? Why doesn’t this blindingly simple and intuitive model work?

Certainly, the idea works, to a point. The reasoning is built on a centuries old foundation of logic. We all know the example:

All men are mortal. Rule: If (man ?X) (mortal ?X)
Socrates is a man. Fact: (man Socrates)
Socrates is mortal. New fact: (mortal Socrates)

You have a rule and a fact. These combine to create a conclusion. Works every time. If I have the rule and assert the first fact, I can now infer the new fact with certainty. There are nuances related to negation, lack of knowledge inferences, uncertainty, and whether knowledge bases are monotonic, but the core notion is clear.

And certainly the engines work. They just look at the facts on the left hand side of the rule and, if they are true (in the data) then assert the resulting facts on the right hand side as true.

And it’s not the horsepower. Even with a huge corpus of rules, today we have machines fast enough to figure out in real time what routes you could take from wherever you are to my office, by walking, using public transportation, or driving. Surely they can muscle through some rules. In fact, even in the early days of expert systems the horsepower was there for the rule sets they had.

Yet, even though the rules work and the engines work and the machines work, rules-based expert systems have been utter failures. Why is this the case? In particular, the problem is the product of a striking mismatch between the rules the machine needs to do its reasoning and our ability to map our understanding of the world onto them. It is a problem with knowledge engineering.

In the early days of Rule-Based Expert Systems, the people who built the systems wrote the rules. Researchers in Artificial Intelligence would ramp into new domains of practice and craft the rules needed for their systems to run. Now and again, they might take short cuts (why have a rule based system do your math when you can escape into the underlying programming language that can do it faster) but, in general, they were able to capture the knowledge needed to solve simple problems in limited domains on a regular basis.

Take, for example, MYCIN, a diagnostic expert system in the realm of medicine, had on the order of 500 rules crafted by researchers working with physicians. They had the expected structure with a little bit of probability:

IF the infection is primary-bacteremia
AND the site of the culture is one of the sterile sites
AND the suspected portal of entry is the gastrointestinal tract
THEN there is suggestive evidence (0.7) that the infection is bacteriod.

MYCIN had an accuracy rate of about 65%. Not all that bad when compared to the 80% accuracy rate of physicians who are specialists in diagnosing infections. This seemed promising, so researchers decided that they should commercialize this work. But in order to build these systems at scale, in order to have a software solution rather than a consulting firm, someone other than the researchers would have to write the rules.

This gave rise to a powerful battle plan. Rather than have researchers write the rules, everyone decided to have domain experts write them. Why not turn these systems into platforms or shells that end users, the customers who were buying these platforms, could use to configure their own systems? Given the early successes, this seemed like a plan that was not only viable, but also obvious. So why didn’t work? Why don’t we have complete penetration of expert systems in all aspects of business and personal decision-making?

It just turns out that it is really hard to write down the rules. It’s even hard to write down the facts. But that aside, most people with genuine expertise in an area often have intense difficulty introspecting on that expertise and reducing processes that are second nature to them down to an explicit rule set. It is particularly hard when those rules start interacting and end up creating a decision tree in which the conditions associated with each branch have to be explicit enough for a machine to calculate and run.

It gets worse when the rules are being written by multiple experts who may not even agree on the specific values associated with the these descriptions. And once the rules are written, they can really only be changed by people who do agree; people with a shared and now codified ontology.

No matter what, the rules get complex, the decision tree gets deep and broad and the special cases flourish. And in the end, you are at 65% accuracy. And even when you get the rules mostly right, any change in one can have effects that will cascade through the entire collection, requiring a complete reworking of the rule base.

All of this flows from a basic misunderstanding – a confusion between domain expertise and rule writing expertise. Not all experts can describe what they do to other people let alone describe it at a level of detail that can be transformed into machine executable rules. In fact, one could argue (and we do) that the nature of expertise is such that the vast array of assumptions that an expert uses when performing his or her work has to remain implicit if they are going to be able to think at all. Teasing out these implicit assumptions is a task that actually requires some level of skill and trying to do so without any background in knowledge engineering is painful and frustrating at best.

This problem, often called the knowledge engineering bottleneck resulted in the downfall of not only expert systems, but also led to a decades long dry spell in work in Artificial Intelligence that we are only now coming out of.

What We Do and Why We’re Different

As I mentioned earlier, the Narrative Science Authoring Engine is not an expert system. But it is unquestionably an Artificial Intelligence system. It uses knowledge of both domains of interest (sports, finance, politics, logistics, etc.) and writing (journalism, client communication, performance reporting, etc.) to create the stories it produces. It also has a layer of analysis that it applies to the data it processes that, for many writers, was never even close to being part of their core expertise. This kind of expertise is simply not in the skill set of most writers and trying to impose it on them is not what we ever want to ask our clients to do.

Because of this, we currently configure the engine in house. Of course this configuration is performed by an editorial staff with expertise in the areas in which they are working. But they are writers who have done considerable work introspecting on their own skills in an effort to transform themselves into not just writers, but meta-writers. As a result, they have skills that are based on a foundation of a deep understanding of their craft. Skills that also include the ability to talk with other writers, in particular our clients’ editorial staff, and transform those conversations into configurations that capture the right tone, structure, analysis, and language.

And once these configurations are complete, the resulting installations can write stories instantaneously at tremendous scale with exceptional quality.

As we move forward, we are mapping these skills onto tools that make the process of configuring the engine more transparent, more fluid and in line with the traditional task of actually writing a story. As we refine these tools for our own use, we will begin to roll them out to clients so that they can become meta-writers as well. But we will only do so when we are confident that the stories the system produces stay at the quality level that we strive for as a company.

So, at some point in the foreseeable future, we will provide clients with a pure software solution, but only after we have mapped our own skills in knowledge engineering onto tools in the same way that we have mapped writing skills onto the core engine. In the meantime, when you work with us, you still have to talk with people!

No comments:

Post a Comment

About Me

I am one of the founders and CTO of Narrative Science, a company that automatically generates narratives from data. The company's technology transforms data into stories that capture and give voice to the insights hidden in the numbers.
Based on ideas coming out of Northwestern University, our authoring engine allows us to craft the data analysis, rhetorical structure, voice and language that go into the generation of high quality and insightful narratives. Once configured, the system is then able to generate stories at scale without any further human intervention.
Our goal is to find the insight hidden in the data with the idea that stories are the bridge between numbers and knowing.