The DCE Help-Desk Assistant
Project Overview
The DCE Help-Desk project aims to leverage knowledge-base technology
to usefully and profitably augment existing customer services.
The goal of the project is to build a
help-desk assistant, capable of automatically answering a proportion of
customer questions which would otherwise have been phoned in to a normal
help-desk. The Help-Desk Assistant complements existing technologies for
customer support -- in particular on-line manuals and case-bases of
example problems+solutions -- by generating
answers on-the-fly from a
structured representation (the knowledge base)
about the domain, rather than reciting opaque paragraphs of text.
By using a structured representation, the Assistant
can customize answers to the end-user's specific situation and
level of expertise, thus
enabling end-users to self-answer some of their own questions rather than
phone in a query. The challenge with this technology is to overcome the high
cost of building such representations in the first place.
We are addressing that challenge
with a component-based approach to knowledge base construction. Our
resulting prototype suggests this technology can be applied for customer
support in a financially profitable way.
This project has a two-year duration, and is sponsored by the Digital
(Customer Services Division) and the Texas
Advanced Technology Program. It is being conducted by the
Knowledge-Based Systems Group at Univ. Texas at Austin. The project
began mid-1994.
Quick References:
The best text overview of the project is given on this Web page.
There is also a recent slide presentation summarizing the work
available
here.
A recently submitted paper describing the
composition machinery in the knowledge base, the research foundation
of the project, is available
here.
Pointers to additional publications, illustrations and working notes are
given below. Our group's home page is
here.
The Customer Service Problem
As computing technology becomes more complex, there is an increasing
burden being placed on customer service help-desks. Customer queries are
becoming both more frequent and more complex, requiring more help-desk
personnel with high training to answer. At the same time, customers
are less willing to pay for such services, due to expectations that
service is implicitly part of software purchase, and unwillingness to
pay for help with problems due to code bugs.
Two ways of easing this burden are to speed up the time it takes a
help-desk to answer a query, and to enable customers to self-answer
some of their
own queries. Technologies which can assist in this include:
- Manuals - have the advantage that the customer can use them
directly. But: they are often overwhelming, only give answers in
general terms (ie. not customized to the user), and only answer the
questions that the manuals' authors anticipated at the time the
manuals were written.
- Case-Bases + Search Engines - Large databases of
problem-solution cases, stored as ascii text, have proved extremely
useful for customer support. Given a new problem, a solution to a similar
old problem may be found and applied. However, case-bases too can be hard to
search, and although customized, they are customized for someone else's problem
(the old problem) rather than the current new user, requiring expertise
to appropriately adapt the old solution to the current new problem.
- Knowledge-Base Technology - By representing knowledge
in a structured form which the computer can reason with (rather than
ascii text), a system can generate answer's to users' questions.
Such answers can be customized to the user's problem and level of
expertise, and hence be usable by customers directly, thus off-loading
work from help-desks. In addition, they can answer questions involving
reasoning (eg. ``how do I...?'' questions). The limitation of this approach
is that knowledge-bases are difficult to build.
This project focuses on this third technology, to explore the
extent to which knowledge-based question answering can contribute to
easing in customer services. Our claim is that the knowledge-based approach
can have a strong, financially viable place in customer support
by filling the `niche' role of answering a proportion of novice questions
which customers would otherwise phone a help-desk with. This technology
can thus help to both reduce load on help-desks and improve customer
satisfaction with direct responses to problems.
As an application goal, we are constructing a prototype system
capable of answering novice users' questions about a particular
sub-domain of computing, namely DCE (OSF's implementation of a
distributed computing environment). Customers' questions are
answered directly through a WWW interface to the question-answering
software. As a research goal, we are developing
better methods for constructing such knowledge bases, based on
assembling them from a library of reusable components.
As with many projects with large knowledge-bases, our goal is that
the knowledge-base be constructed from modular, reusable components.
The knowledge-base should be multifunctional or `task neutral', ie.
can be used to support a variety of problem-solving activities.
Domain concepts (eg. stored as frames) should be constructable by
composing components together rather than spelling out the details
of each by hand. Similarly, abstractions of domain concepts should
be generatable by removing components; composition provides the `seams'
by which a specific concept can be teased apart in meaningful ways.
The underlying representation we are using is based on conceptual graphs.
A `component' is a conceptual graph, and `composition' is the process of
unification (joining) of conceptual graphs together. This approach
allows us to be built complex representations solely from simple components,
and takes account of interactions between properties of each
component. This allows novel concepts and situations (eg. a DCE user's
specific network) to be represented on-the-fly, and allows
abstractions to be generated by reversing this process.
We have applied this method to the three central representational
structures used in the KB, namely concepts, scripts and actions
(see "The Knowledge Base", below). A more detailed slide presentation
of the composition mechanism is available by
clicking
here
(in postscript, May 1995), and we have recently submitted two papers,
"Building Domain Representations from Components" and
"A Compositional Approach to Representing Planning Operators"
for publication. Also, an informal series of
working notes discusses these issues in more detail.
Application Software
The system consists of two parts: the DCE Knowledge Base, which contains
a structured representation of distributed computing concepts, and
the Knowledge Delivery Software (KDS), which draw on information in the
knowledge base to construct answers to users' questions.
The Knowledge Base
The knowledge base uses an extended frame-based representation scheme.
Each unit of knowledge in the KB represents a DCE concept (eg. "server",
"endpoint", "principal" etc.) and the unit contains a list of statements
about that concept and its relationships with other concepts.
Units are organised into an inheritance hierarchy and
so can inherit properties from their more general units.
The DCE ontology can be loosely viewed as containing three types of
knowledge:
- DCE concepts: The basic concepts in DCE, the building blocks
for describing DCE networks and their behaviours.
eg. "client", "password", "ticket".
- Scripts: Stereotyped sequences of events which often occur
in a DCE network (eg. "authorization", "authentication", "binding",
"RPC").
These are described in terms of the DCE concepts above.
- Actions: Events which can change the state of a DCE network,
eg. "logon", "modify ACL", "run program".
The Knowledge Delivery Software
The knowledge delivery software draws on information in the knowledge
base to answer user's questions. There are three classes of answer which
are processed.
- Information Retreival: Involving the selective extraction
and customisation of knowledge from the KB. eg. "describe authentication",
"who can modify an ACL?", "what is the advertiser?".
- Diagnosis: Involving the interactive search for explanations
of error conditions which may have arisen. The KB contains a representation
of errors associated with different DCE activities, and their possible causes.
Through a sequence of questions and answers from the user, the system
searches for possible explanations of the user's problem.
- Planning: To answer ""How do I...?" questions. This involves
search for a sequence of actions which will achieve a users' goal. This
draws on the representation of actions in the KB, including representation
of their effects, constraints and preconditions.
In addition, having a representation of DCE concepts, including the
English words used to describe them, enables us to automatically
hypertextise on-line documents (eg. email messages, manuals),
including at run-time. This presents a powerful means for cross-referencing
the Knowledge Delivery Software functions with other on-line text
information.
WWW-Based User Interface
Description
The system is interfaced through the WWW.
Interaction with the system is mixture of usage of on-line manuals
and the knowledge delivery software:
- Manuals are automatically hypertextized by the system,
and can be browsed by the user. DCE concepts are highlighted, and
clicking on them takes the user to a system-generated description of
that concept, as follows:
- Knowledge Delivery Software (KDS): The user's selected concept
becomes the topic for the KDS. The system presents a summary
of the topic: its definition, generalizations, related concepts,
and cross-references back to other parts of the manual. Most importantly,
it also lists a set of questions which the user can ask about the
concept. Clicking on a question starts the question-answering software,
generating a customised reply for the user.
Thus the user may browse the manual, click on a concept to get a
description of it, then ask the KDS questions about it, read the
automatically generated reply, then return
back to the manual, then click on another concept etc.
"Screendumps" (HTML-dumps)
The following are snapshots of the system. Note:
- They are inert, ie. they are not interfaced to the
KDS software itself, but instead are "screendumps" of the system.
Clicking on the hot-spots will simply return you to this page, rather than
allowing diagogue to continue.
- They are not mock-ups, but are HTML pages saved during the
usage of the system (and with the hot-spot behaviour changed).
The snapshots are as follows:
-
On-line Manual Page The text here is from the manual,
automatically hypertextized by the KDS. This would be a typical
entry point into the system. Clicking on an item takes you to
the KDS-generated summary of that item (Note: here, it takes you back
to this page).
-
KDS Interface This summarizes the item the user clicked
on. The list of questions acts as the interface to the KDS software.
Clicking on a question causes the system to generate an answer,
typically involving interaction with the user. In this example, the user
is viewing information about the topic "binding event".
- Question Answering
-
Descriptive Questions In this first example, the user has
clicked on
"Describe binding-event", and then told the system (
HTML forms, not shown) to customise the explanation to his/her
network consisting of a
client (called "Mosaic" running on the machine "Tortoise")
trying to bind to a server (called "the WWW Server", running on
the machine "Zippy") (Click
here
to see customisation).
The system then selectively extracts
relevant facts from the KB, customised them, and then converted
them to Natural Language using schema-based methods (Click
here
to see the resulting description).
-
Planning Questions In the second example, the user has
asked "How do I change the minimum password length for my
organization?".
The KDS has searched for an action which can achieve the goal,
and then searched for other actions which can achieve that
action's preconditions. The sequence of actions is again converted
to text and presented to the user (again customised to the
user's organization "students" and length 6).
(Click
here to see the generated plan).
An older
slide
presentation from Nov 1994 is also available.
Plans and Research Goals
Our general research goals underlying this work are a reaction to the
common "disposable expert system" methodology, in which expert
systems are constructed with just a single task in mind, used,
and eventually become obsolete and discarded. Our goal is to
develop knowledge representation and reasoning techniques which
will achieve multifunctionality (the same underlying knowledge-base
driving several applications), and ultimately greater longevity and
reusability of knowledge.
A fundamental requirement for this is the construction of
a representation from components. Our work involves extending
the traditional notion of knowledge-base component and composition
(as described earlier), to adequately meet the requirements
of modularity and reuse, and avoid the knowledge base becoming
an "amorphous mass" of facts as it grows.
Throughout, we are aiming to achieve:
- Extent: Attempting to represent the `deep' knowledge on which
task-specific functions are based. For example, the simple
medical diagnosis rule:
"if patient has high temperature then he/she has flu'" is supported
by `deeper' knowledge of why that relationship holds.
It is this type of knowledge we wish to include in our
representation.
- Generality of Knowledge:
Raising the level of abstraction of knowledge where possible.
We try to represent domain-specific concepts
as a special case of more general concepts. For example,
in DCE: "reboot server" is a special case of "reboot", which
itself is a special case of "restart". By doing this, general
knowledge about "restart" (say) can be applied to other events
as well as "reboot server", gaining leverage and reusability of
knowledge.
- Generality of Application:
Defining the functions of the knowledge delivery software in
domain-general terms. Thus, rather than defining a module for handling
"describe authorization" questions, we instead define a module
for handling "describe process" questions. In this way, the module
should then be able to perform on all process questions.
The specific end products of this research,
which we are currently in the process of constructing, are:
- A library of representational components
suitable for describing (among other things) computing systems,
- a knowledge-base about distributed computing
formed from composition
of these components, and
- knowledge delivery software, supported by the KB, which will
answer users' questions about specific aspects of DCE.
Pointers to Related WWW Sites
- DEC -
Home Page.
-
Project Pilgrim -
(Univ. Massachusetts) "Pilgrim is building a fully-functional
DC environment by developing s/w layers on OSF DCE
to unite incompatible collections of computer systems."
-
Open Software Foundation -
Home Page.
-
DCE in Higher Education - Includes collection of
pointers to general DCE info sources.
Also there are a number of
related KB projects underway in other organizations.
Back to KBS Group Home Page
pclark@cs.utexas.edu