automated knowledge refinement for rule-based formulation expert system
TRANSCRIPT
At pH 2, the low MW terpolymer beads released
10% of their loaded insulin after 100 minutes,
compared with a 5% loss from the intermediate
and high MW beads. This indicated that at this
pH there was not a burst release of insulin from
the polymer beads. The remaining insulin was
released at pH 7.4 and the release rate was a
function of polymer MW. An increase in MW
resulted in a reduction in the rate of insulin re-
lease from the polymer beads. At this pH, most
of the insulin was released from the low MW
beads after two hours, followed by the interme-
diate beads after four hours and the high MW
beads after eight hours.
These release profiles indicate that the number
of pseudo crosslinks produced by entanglement
increased as the polymer MW increased (Fig. 3).
As MW increased, there was a concomitant
decrease in the free space available for solute
and water diffusion, giving rise to a diffusion-
controlled system. In addition to network for-
mation, the authors suggested that the high
MW polymer bead might be exhibiting a glassy-
to-rubbery phase transition upon water pen-
etration, which results in a swelling controlled
system. Thus, a combination of diffusion and
swelling controlled release might account for
the observed release of insulin from the high
MW polymers. For the intermediate polymers,
insulin release was a combination of dissolu-
tion, swelling and diffusion mechanisms. The
increased rate of release for the low MW poly-
mers was accounted for by disintegration.
At acidic pH and body temperature, the poly-
mer beads were insoluble and therefore no (or
insignificant) quantities of drug would be re-
leased into the stomach. As such, these polym-
eric beads may be very useful vehicles for the
delivery of peptides and proteins to the gas-
trointestinal tract. The rapid release of insulin
from the low MW beads at pH 7.4 indicates that
these could be used to target the small intestine
and the intermediate and high MW beads
could be employed in targeting the large intes-
tine. However, colonic drug delivery would re-
quire the development of a system that would
inhibit drug release until the colon was reached.
The widespread use of such a delivery system
will ultimately depend on finding suitable selec-
tive enhancers for intestinal absorption.
PROFILEAutomated knowledgerefinement for rule-basedformulation expert system
Susan M. Craw and Robin A. BoswellThe School of Computer and Mathematical SciencesThe Robert Gordon UniversityAberdeen, UK AB25 1HGe-mail: [email protected]
Raymond C. RoweAstraZenecaAlderley ParkMacclesfieldUK SK10 2NAe-mail: [email protected]
In all cases of product formulation — whether it
be for tablets, capsules, parenterals or any one
of the numerous other dosage forms — the
process is generically the same. It begins with
the presentation of some form of product speci-
fication and ends with the generation of one or
more formulations that fulfil the requirements.
Often, the specification has potentially conflict-
ing requirements and it is left to the highly
skilled and experienced formulator to balance
these and produce the optimum compromise
formulation.
Expert systems, of which several exist in
pharmaceutical product formulation1, are
therefore an attractive option for companies
who wish to retain human expertise. It is com-
mon for the expertise to be represented as ex-
plicit knowledge, encapsulated as rules of the
form, IF [conditions] THEN [conclusion], where
the knowledge in the conclusion can be de-
duced if facts satisfying the conditions are
already known to be true. Such systems solve
problems as follows: they are presented with
facts describing the situation relevant to the
problem to be solved and systematically fire
those rules, whose conditions are satisfied until
some final conclusion is deduced. The devel-
oper’s goal is to build a system that consistently
produces correct answers to the problems it is
set, in the domain for which it has been con-
structed; such as in tablet formulation.
An important research topic in this area is
the development of knowledge refinement
tools, which automatically monitor the prob-
lem-solving performance of a system and sug-
gest repairs to existing knowledge or new
knowledge that should be acquired with the
goal of improving the accuracy of the answers
provided by the system. Refinement tools react
to evidence that a system is faulty (typically
through the use of examples when the expert
disagrees with the solution provided
by the system) by exploring possible causes in
the knowledge and suggesting repairs to cor-
rect this behaviour. This Profile describes one
such refinement, KRUST, and shows how it
can be applied to a tablet formulation expert
system.
KRUSTKRUST is an automatic refinement tool devel-
oped at the Robert Gordon University (Aberdeen,
UK)2,3. Figure 1 shows the process followed by
KRUST.
PSTT Vol. 2, No. 9 September 1999 monitorprofile
383
Figure 1. The knowledge refinement cycle as implemented in KRUST.
Pharmaceutical Science & Technology Today
Faulty knowledge base
Wrongly solvedexample
Testingexamples
Blame allocation
FaultsRefinement generation
RepairsConsistency filter
Consistent repairs
Refined knowledge bases
Best refinedknowledge base
Refinement implementation
Selection
E1E2E3E4 • • •En
1461-5347/99/$ – see front matter ©1999 Elsevier Science Ltd. All rights reserved. PII: S1461-5347(99)00182-0
Blame allocation explores the rules that were
applied for a particular wrongly solved example.
In addition, it also investigates rules that were
not applied for reasons such as failure to satisfy
the conditions of the rule, but these rules con-
tribute to the deduction of the correct solution.
The outcome of blame allocation is to identify
error-causing rules that should be prevented
from being applied, or, conversely, target rules
that did not participate in the solution but may
be usefully applied.
Refinement generation investigates changes
to the knowledge in error-causing rules that
would prevent the rule being applied for the
particular wrongly solved example. For instance,
it may add further constraints to the conditions
of the rule by strengthening an existing re-
quirement or adding a new condition. It also
proposes changes to target rules that allow
them to be applied to the wrongly solved exam-
ple. For instance, it may weaken, or even re-
move, the condition that is currently not satis-
fied and so prevent application of the rule.
Other refinements that may be proposed in-
clude the removal of a rule, or learning a new
rule from a set of related examples that are
currently wrongly solved.
Repair implementation actually implements
the proposed refinements as changes in copies
of the knowledge-based system. In addition to
these three main steps, a refinement tool must
manage the set of proposed refinements and
refined knowledge bases and then select which of
the refined knowledge bases is the one that pro-
vides the most satisfactory repair. In practice,
there are many potential repairs and KRUST ap-
plies selection methods at several stages of the
Blame–Generate–Implement refinement cycle.
ApplicationThe applications used were three versions of a tab-
let formulation expert system implemented in the
Product Formulation Expert System Shell (PFES;
Logica UK Ltd, London, UK). The system and the
shell have been fully described elsewhere1. Three
versions of the expert system were used.
• TFS-1A – an initial version corresponding to
an early stage in development. This con-
tained bugs and produced faulty tablet
formulations.
• TFS-1B – a manually debugged version of
TFS-1A, which produced correct formu-
lations during its period of use.
• TFS-2 – a manually updated version of TFS-
1B resulting from a paradigm shift in the
policy for tablet formulation.
Two series of experiments were performed. The
first involved TFS-1A as the system to be refined
and TFS-1B was the oracle producing the current
answers. It should be noted that the oracle is nor-
mally a human expert, whose feedback is the in-
put to the refinement process. Here, a later version
of the expert system was used to correct an earlier
version of the system. The second experiment
saw TFS-1B as the system to be refined and TFS-2
as the oracle producing the correct answers. In
the first series of experiments, KRUST refined
TFS-1A, which contained three types of fault.
monitor profile PSTT Vol. 2, No. 9 September 1999
384
Figure 2. The sequence of events in the identification and repair of the wrong filler fault in the original version of the tablet formation expert system. The rules are expressed in LISP format.
Pharmaceutical Science & Technology Today
Problem
Fault
DatabaseMAX-LEVEL of CALCIUM PHOSPHATE = ?
Rule: remove excessive fillersIf: <FILLER> is on FILLER-MENU and
CONCENTRATION of <FILLER> is GREATER-THAN MAX-LEVEL of <FILLER>
Then: remove <FILLER> from FILLER-MENU
Filler MenuCALCIUM PHOSPHATECALCIUM CARBONATE
DatabaseMAX-LEVEL of CALCIUMPHOSPHATE…?
KRUST seeks to prevent calcium phosphate from being selected for the filler menu by supplying a missing value for the maximum value for calcium phosphate in TFS-1B.
TFS-1A says TFS-1B says:Filler = Calcium phosphate Filler = Calcium carbonate
Repair
Rule: get insoluble fillerIf: REQD-FILLER SOLUBILITY has
value INSOLUBLE and <FILLER> is on FILLER-MENU and <FILLER> is insoluble
Then: refine FILLER to be <FILLER>
Rule: remove excessive fillersIf: <FILLER> is on FILLER-MENU and
CONCENTRATION of <FILLER> is GREATER-THAN MAX-LEVEL of <FILLER>
Then: remove <FILLER> from FILLER-MENU
Because its maximum level is missing from the database, calcium phosphate is NOT removed from the menu as it should be, and TFS-1A chooses it in preference to calcium carbonate.
• Wrong filler examples were caused by
a missing database entry in TFS-1A – this
was accidentally omitted in the original
knowledge acquisition. The knowledge
was repaired by learning the required data-
base entry, the maximum level of the filler
to be used, and adding it to the knowl-
edge. The sequence of events is illustrated in
Fig. 2.
• Wrong binder quantity examples were
caused by TFS-1A using the incorrect rule:
IF [Binder present in formulation] THEN [Setlevel to be 0.04].The rule was corrected by learning that the
level should be 0.02 and not 0.04.
• Multiple specification fault examples con-
tained many discrepancies between the
expert and TFS formulations. KRUST discov-
ered that all of these discrepancies origi-
nated from an error in the calculation of the
target tablet weight. The rule containing the
incorrect formula for target tablet weight
was identified and the rule was corrected by
learning a new formula.
The repairs that KRUST suggested for the
‘wrong filler’ and ‘wrong binder level faults’
coincided exactly with the manual updates
in TFS-1B. For the third type of fault, KRUST
learned a new formula that was competitive
with the original formula and the formula for
high values of dose in a new TFS-1B rule4.
In the experiments to refine TFS-1B, at the
outset KRUST was given some additional knowl-
edge concerning the paradigm shift: it was told
that the excipients were grouped into classes
and that those in certain classes were to be pre-
ferred to those in subsequent classes. KRUST
was able to refine TFS-1B by adding one or
more conditions to the selection rules5.
ConclusionsThe main finding is that KRUST was successful
in repairing real faults in a real expert system
from real evidence. There was experience of ap-
plying KRUST to corrupted versions of bench-
mark knowledge bases and simple theories, but
this was the first experience of historical ver-
sions of an industrial expert system.
Originally, the tablet formulation expert had
described the faults in the bug-containing TFS-
1A as: ‘one is easy to find’, ‘another will test
your system’, and ‘I don’t expect you to find the
third fault!’ KRUST successfully debugged TFS-
1A automatically from wrongly solved exam-
ples. All three faults were found by KRUST, two
were fixed automatically and a competitive for-
mula was chosen to repair the remaining fault.
More importantly, KRUST successfully refined
TFS-1B, thereby achieving the maintenance de-
manded by a change in formulation policy. KRUST
induced new conditions and rules by incorpo-
rating knowledge about the newly introduced
categories for excipients. The tablet formulation
expert agreed with the new knowledge added
to the knowledge base, and approved the for-
mulations produced by the refined knowledge
base.
This experience confirmed the applicability of
automated knowledge refinement for mainte-
nance tasks, as well as the more traditional de-
bugging roles. It also highlighted the differ-
ences when refining a design system in solution
synthesis applications; it had previously only
been used to refine systems where the task had
been to select from a list of possible hypotheses.
Clearly, KRUST can be directly applied to other
formulation expert systems with similar prob-
lem solving approaches to the one used here.
References1 Rowe, R.C. and Roberts, R.J. (1998) Intelligent
Software for Product Formulation,Taylor and Francis,
London, UK
2 Craw, S. and Sleeman, D. (1995) Expert Systems
with Applications 8, 343–349
3 Craw, S. (1996) Int. J. Human – Computer Studies
44, 245–256
4 Boswell, R., Craw, S. and Rowe, R.C. (1997) in
Proceedings of the European Knowledge Acquisition Workshop
(EKAW97) (Plaza, E. and Benjamins, R., eds),
pp. 49–64, Springer, Saint Feliu de Guixols, Spain
5 Craw, S., Boswell, R. and Rowe, R.C. (1997)
Proc. 9th IEEE International Tools with Artificial
Intelligence (TAI’97), pp. 446–453, IEEE Press,
Newport Beach, CA, USA
PSTT Vol. 2, No. 9 September 1999 monitorprofile
385
About the Profiles section of Monitor …
We welcome contributions for the Profiles series, which gives a commentary onpromising lines of research and new technologies in drug development. Articles shouldprovide an accurate summary of the essential facts together with an expert commentaryto provide a perspective.
Brief outlines of proposed articles should be directed to the Monitor Editor (see contactdetails on page 381). Articles for publication in Monitor are subject to peer review andoccasionally may be rejected or, as is more often the case, authors may be asked torevise their contribution. The Monitor Editor also reserves the right to edit articles after acceptance.