Expert systems and knowledge bases have a terrible record of failure. Industry statistics suggest that most implemented systems fail within just two years. A lot of these failed systems belong to companies who looked to these “expert” knowledge bases for assistance because they realized that there’s some kind of inherent value in the knowledge they’ve accumulated about their products and services. They’re right but the sad fact is that industry statistics suggest that there have been far more failures than successes.

One of the problems is that companies don’t understand how to appropriately value their knowledge even though they realize that there’s some inherent value to it. They have questions like, “How do I gather knowledge together into some usable format?” “How do I maintain the knowledge so that it doesn’t get old?” “How can I leverage our knowledge to increase corporate revenue?” …or the big one… “How do I get people to use it?”

This series of articles explores these areas and more, to help you get started with an expert knowledge base in your company. Most importantly, once the knowledge base is introduced, I’ll help you understand how to get buy-in and maintain it so that it’s still running and used two years later.

What is an expert knowledge base?

Before answering that question, you have to understand the difference between knowledge and data, and the way each is stored, accessed, and used.

For our discussions, a database is a storage place for data, which consists of facts (i.e., raw data), definitions and assumptions. Spreadsheets represent the simplest types of databases and contain functionality to view and manipulate that data. For example, spreadsheet programs like Microsoft Excel accumulate, store and manipulate data, which can then allow intelligent conclusions, projections, and sometimes knowledge to be drawn from.

Relational databases including Microsoft SQL Server, Oracle, IBM DB2, and Domino (to name but a few) can amass and store huge quantities of data of every conceivable type, but are relatively slow when attempting to manage small, fast-changing data sets. When managing very large databases, data warehouses such as Wonderware InSQL, which are based on top of specific databases like SQL Server, can effectively accumulate and store huge amounts of quickly changing data (like 105 points changing at 10-3 seconds) taken from the machinery and processes on factory floors.

Regardless of what kind of database you use; and regardless of how much or what kind of data you can gather and manipulate, that data will never represent “knowledge.”

Knowledge is defined as:
The fact or condition of knowing, or having direct cognition of something with familiarity gained through experience or association.

Knowledge is the ability to understand and use the relationships of data and information (which could be defined as groups of similar or related data) in a meaningful way, and to be able to add to existing knowledge through a learning process. To bridge the gap from a database to a knowledge base, you have to assemble the knowledge and enter it into a database for storage and retrieval, program the intelligence that holds it all together, appropriately and properly select it when queried, and finally display it correctly upon demand. These systems of parts are called Knowledge Bases and are also referred to as, Expert Systems, or Expert Knowledge Bases.

The phrase, “expert system,” was coined in 1956 by John McCarthy, assistant mathematics professor at Dartmouth University. It was (then) defined to require as the main components: A knowledge base, an inference mechanism, and a user interface.

In regard to inference mechanisms, this is best explained by an expert in the field. The following excerpt is taken from the article, “Knowledge Base Sets Expert Systems Apart”, by Donald A. Coggan:
“…An inference mechanism consists of algorithms and the rules that relate the knowledge in a knowledge base. In reality, an inference mechanism or its twin brother, the inference engine, is an intimidating illusion that has emerged from the world of computer jargon. An inference mechanism is just a higher level programming language used to facilitate the development of an expert system in the same way that Lotus 1-2-3 and QuattroPro were higher level languages used to develop sophisticated spreadsheets. Today, one would never think of creating a spreadsheet without using a spreadsheet program. Similarly, one would not contemplate building a[n] expert system without using an inference mechanism…”

The article goes on to explain the complexities that can be added to the user interface and the inference mechanism to achieve something approaching apparent intelligence.

Generally speaking, most companies aren’t looking for a full-blown expert system containing heuristic algorithms designed with LISP programming. These sorts of systems can cost hundreds of millions of dollars to develop and have an extremely narrow band of usefulness and purpose, usually focusing on knowledge that spans different genres and establishing linking relationships between dissimilar knowledge objects in much the same manner as neurons are cross-linked in a brain.

Is this how commercial expert knowledge bases are built? Well, yes and no. Most knowledge bases don’t have the level of detail built into the inference mechanisms and user interfaces which simulates intelligence and draws conclusions. Commercial expert systems however, do incorporate some intelligence so that the knowledge objects returned, based upon a specific search string, are closely related to that search string in some appropriate manner. Additionally, the expert knowledge base should learn about what’s being asked for and position the knowledge requested or used more frequently to a higher place on the list of knowledge objects returned from similar searches.

So, what’s a knowledge object?

A knowledge object is generally defined as:
“A piece of knowledge which may be represented in a number of forms that contributes to the researcher’s information pool on a specific subject. Furthermore, the contribution to that pool can be either considered positive or negative, but the requirement is that the piece of knowledge must be related, relevant, and pertinent to the pool.”

For example, when providing a technical support expert knowledge base of solutions for customer issues, each knowledge object in the database must meet a minimum of three criteria to be useful to the customer (or researcher). The first is, “Does the issue discussed within the returned knowledge object match the issue that I am having?” The second criterion is, “Is the cause of the issue the same cause as I am having?” The third criterion of a knowledge object within this particular situation is, providing a solution or resolution to the issue based on the agreed cause.

The form of the knowledge object can vary. For example, ServiceWare Technologies breaks its knowledge objects down into the discrete components of issue, cause, resolution, or any component that makes sense to the specific application. One of the advantages with this method of knowledge creation is that common components used in more than one knowledge object can be reused without having to author new ones, such as a single solution applying to several issues.

Another advantage includes not having to read through a (sometimes large) document or technical paper to understand if the issues (or and one of them) addressed by the document applies to the issue being sought. In systems like this, these types of documents can be available through links in the returned knowledge, should the user need more detailed information.

A disadvantage of this approach to knowledge object creation is that complex conditions may not be easily represented in the issue component, which is where the search is conducted. For example, if there’s an identical error message between two or more product combinations with entirely different causes and solutions, how can you, as the knowledge author, represent which solution path matches customer issues without making them read through all of the issues, causes and resolutions containing that error message?

Document-oriented knowledge objects are used by systems like those from Kanisa and Primus Knowledge Solutions amongst others. Most expert systems that use this technology use a spider to read and access all the documents on a corporate intranet and present them to a common interface via some inference mechanism. More common expert systems like this are search engines such as, Google, Alta Vista, and Ask Jeeves, which return a variety of information and knowledge based on word searches of web pages throughout the Internet.

The greatest advantage of using document-based knowledge objects is that many companies already have this knowledge in an existing document format so it doesn’t need to be re-authored. You just have to locate it when a query specific to the contents of the document is conducted.

The greatest disadvantage of document-oriented expert knowledge bases is authoring and maintaining these documents, so that the knowledge in them does not get stale. Industry analysis has shown that if users either don’t find a solution, or locate an incorrect solution three times in a row, they will stop using the expert system more than 80% of the time, even though they know that they could save a great deal of time using it if the expert system contained correct solutions! Knowledge objects of this type can require a tremendous amount of resources just to keep them current with new solutions -- as new product releases or technology changes obsolete old information and knowledge.

Figure 1 shows the difference between the two types of knowledge objects.

The type of knowledge objects used by your business can vary greatly depending upon many factors including: your intended use of the knowledge objects, the business model in which that the knowledge object will be used, the sophistication of the knowledge being sought and displayed, and the type of audience for which the knowledge is intended. Companies with slowly changing product lines and/or already employing a staff of authors and subject matter experts will benefit from document style expert systems because much of the knowledge already exists. In most cases, the main purpose of the expert system is to pool or access that knowledge from the many possible locations and provide a single interface to that knowledge.

Companies with a great deal of mixed knowledge media and/or needing to re-author or review every existing support document, and white paper will find the component approach to expert systems gives them a tremendous authoring staff efficiency ratio (authoring headcount vs. topics authored and published over a given time period).

Simply understanding the basic facts in this article will go a long way toward helping you decide how to choose and implement an expert system in your support organization, and will give you some idea of what’s involved to keep it running. If it isn’t carefully planned, an expert system can die of “knowledge rot” or consume an inordinate amount of unplanned resources.

Upcoming articles will focus on why you should use an expert system, how to design and pitch the project to increase your chances of getting it passed, vendor selection criteria, successful implementation tips and tricks, staffing, payback, how to pre-load the database to get the maximum efficiency out of the staff, and most importantly, tricks and techniques for keeping it healthy.

Rich Clark is the Senior Knowledge Engineer for Invensys Wonderware. He has published numerous technical articles, tech notes, and white papers on a wide range of subjects using Wonderware products including: ODBC and database usage, SPC, time functions, and more. He currently is responsible for the content, usability, and health, and ongoing success of the Wonderware Expert Knowledge Base.