prev

next

out of 9

Published on

26-Jun-2016View

215Download

2

Embed Size (px)

Transcript

Expert Systems With Applications, Vol. 6, pp. 87-95, 1993 0957--4174/93 $5.00 + .00 Printed in the USA. 1993 Petllamon Press Ltd.

Case-Based Learning for Knowledge-Based Optimization Modeling System: UNIK-CASE

JAE KYU LEE AND MIN YONG KIM

Korea Advanced Institute of Science and Technology, Cheongryang, Soul, Korea

Abstract--This article explores how the previously built optimization models can be used as a medium for automatic learning. To explain the learning process, we describe the target representation of common modeling knowledge base in UNIK.OPT and the representations of specific optimization model cases. Both are represented in frames. The common modeling knowledge is represented by the potential iinkability between attributes and in~ces, attributes and blocks of terms, and blocks of terms and constraints. There are also no fixed indices on blocks of terms and constraint sets. Therefore, the learning process includes the addition of new frames, generalization of linkability, generalization of attribute's role (constant or variable), and context identification in terms of period, time units, usage, perspectives, and so forth. To realize the learning process, the UNIK-CASE is under development as a front end of the modeling system UNIK-OPT.

1. INTRODUCTION

THIS ARTICLE EXPLORES how the previously built op- timization models can provide knowledge to the knowledge base, which is shared in aiding the formu- lation processes of multiple optimization models. For this purpose, a case-based learner, UNIK-CASE, (Lee & Kim, 1990) is developed as a front-end learning me- dia of knowledge-based optimization model formulator UNIK-OPT (Lee & Kim, 1992). The previously built models may be used for two purposes: case-based rea- soning and case-based learning. In case-based reason- ing, the previous models are used directly to build a similar model as depicted in Figure l(a). This approach to model formulation has been suggested by some re- searchers. Vellore, Sen, and Vinze (1990) proposed a case-based planning approach; Liang (1989) and Liang and Konsynski (1990) discussed issues related to mod- eling by analogy; and Binbasioglu (1990) investigated the process-based analogy approach.

On the other hand, in the case-based learning framework the cases are not used directly. Instead, the relevant information from the cases are integrated into the knowledge base via the addition of new knowledge, generalization, and inconsistency resolution, as de- picted in Figure 1 (b). This article pursues the case-based learning framework. In practice, both approaches may be adopted together complementarily.

Requests for reprints should be sent to Jae Kyu Lee, Department of Management Science, Korean Advanced Institute of Science and Technology, 207-43, Cheongryangri-dong, Dongdaemun-gu, Seoul 130-012, Korea.

87

For literature about the concepts and techniques on case-based reasoning refer to Kolodner, Simpson, and Sycara (1985), Kolodner (1991), and Riesbeck and Schank (1989). For review on the applications of case- based reasoning on various domains, see Slade (1991). An interesting application of case-based learning to computer programming can also be found in Williams (1988).

Because the target knowledge base in UNIK-OPT is tailored to optimization modeling support, we need to contrast the case-based learning process by UNIK- CASE with the formulation reasoning by UNIK=OPT. This issue is described in Section 2. Section 3 shows the representation of specific linear programming models, while Section 4 illustrates the representation of a common modeling knowledge base. Section 5 pre- sents three learning frameworks with examples: addi- tion of new knowledge, generalization, and context identification. Section 6 describes the development of a prototype and its application to refinery.

2. CONTRAST OF CASE-BASED LEARNING AND FORMULATION REASONING

PROCESS

2.1. Relationships

To understand the role of UNIK-CASE, we need to understand the role of UNIK-OPT and their mutual relationships. This relationship is depicted in Figure 2.

Note that case-based learning is not the only channel of knowledge acquisition. Domain knowledge and modeling structure knowledge that is not included in

88 J. K. Lee and M. Y. Kim

Reasoning

(a) Case-based Reasoning

Reasoning

I Machine Learner

(b) Case-based Learning

FIGURE 1. Case-based reasoning vs. case-based learning.

the cases may also be learned via the conventional knowledge acquisition system. This kind of knowledge acquisition system is particularly necessary when we do not have a sufficient number of cases. The output of UNIK-CASE is the input knowledge to UNIK-OPT. Because the output from UNIK-OPT has the same syntactic structure as the input of UNIK-CASE, the specific linear programming (LP) model cases gener- ated by other companies in the same industry may be used for learning. More reliable cases may be generated from previously built models in other modeling pack- ages by transforming the syntax to that of UNIK-CASE. To help explain the UNIK-CASE, we will describe the UNIK-OPT first. At this stage of research, we limit the scope of optimization to linear programming.

2.2. UNIK-OPT

To describe the rationale of the knowledge represen- tation that is adopted in UNIK-OPT, the architecture

and formulation reasoning process of UNIK-OPT should be reviewed. The key purposes of UNIK-OPT are as follows: 1. Specify the LP model formulations as a subset of

the knowledge base and a model builder's problem definition.

2. Achieve model independence from the knowledge base and data base. By achieving the model inde- pendence, multiple LP models can maintain their consistency independently of changes made in the knowledge base.

3. Make the tool UNIK-OPT domain independent. Let the stored knowledge determine the application domain. To fulfiU the objectives, UNIK-OPT uses three views

(optionally four views) of model representation as de- picted in Figure 3: semantic view, notational view (modeling language view optionally), and tabular view.

Semantic view represents the LP model in frames and includes the semantic information about variables, coefficients, indices, terms, constraints, and specific formulated models. The semantic view of the model can be syntactically transformed into the notational view--the view usually used in the Operations Re- search (OR) textbooks. The notational view can be further reclassified into aggregate and individual equa- tional forms. In a sense, the notational view is a kind of canonical representation of most modeling languages such as GAMS (Brooke, Kendrick, & Meevaus, 1988), PLATFORM (Palmer, 1984), and SML (Geoffrion, 1988). The last view is the tabular view, which is an input format for a specific solver such as MPSX or MINOS. Because transforming the modeling language to the tabular view has been the topic of many re- searches on modeling languages, it will not be discussed in this article.

To formulate the semantic view of a specific model, a model builder uses the common modeling knowledge base as depicted in Figure 4. The common modeling knowledge base comprises the modeling structure knowledge and domain knowledge. The modeling structure knowledge is the component that needs to be learned from a variety of cases. An example knowledge representation is shown in Section 4.

A specific LP model formulated using the modeling knowledge base consists of the relevant modeling knowledge (retrieved from the common modeling knowledge base) and user's problem definition, which a model builder has interactively provided during the formulation process. An example knowledge represen- tation is shown in Section 3.

3. REPRESENTATION OF MODEL CASES

3.1. Two Example Notational LP Models

To illustrate the representation of specific LP model cases, let us see two examples of the notational LP

Case-Based Learning for Optimization Models 89

I Specific h ~ Cased-based Formulation I J Specific I Model ~! Learning by Reaaonlng by LP

UNIK-CASE UNIK-OPT

~1 Knowledge Knowledge Engineers/ ,- Acquisition Domain I System Experts

4

I , i UNIK-CASE ,~1

I" "1

UNIK-OPT

FIGURE 2. Contrast of case-based leaming and formulation reasoning process.

"1

I Semantic-level Model Formulation

Modeling Language View

Semantic View

J Transformation [

I Transformation I

Tabular View

Aggregate Notation Individual Equation ~ Notational coefficients

Numeric coefficients

FIGURE 3. Four modeling views.

90 J. K. Lee and M. Y. Kim

Specific Semantic Model

..i" Syntactic Transformer L [ Data L _ r~ l Manager~

[ @

Knwledgel" ~

~ ][Spec,fIc/' ISemantIc ' II,-o,,,/ Model ~ Model ~-~ Model

[ / Definition/ I I FormuIatrl I [ Definitior :u~ d;elr I I ~ [

FIGURE 4. Architecture of UNIK-OPT.

models: (a) a monthly production and inventory model and (b) a long-term material supply contract model.

Xo ,+Iu -~- I i ,=s i t i~ I , tET (3) J

3.1. I. Notations. i: product; j: facility; t: month;

Xo,: production amount of product i, produced by facility j during month t;

lit: inventory of product i at the end of month t; co: unit production cost of product i at facility j," a~j: unit processing time of product i at facility j,' bj,: capacity of facilityj for month t; &,: sales estimate of product i for month t.

Xot, Ii, >-- 0 for all i, j, t. (4)

In the above model, the objective is to minimize the total production costs, and the constraints are the production capacity and the monthly balance in pro- duction, inventory, and sales.

3.1.3. Annual Product Mix Model for 1992.

min ~ coXij,9z (5) 6 3.1.2. Monthly Product Mix Model for 1992.

min Z coXij, /it S.t. Z aoXijt -- 0 for all i, j. (8)

Case-Based Learning for Optimization Models 91

The symbols used in models (5)-(8) are the same as the monthly model except the month t is replaced by the year 1992. In this model, we do not need to consider the monthly inventory stated in (3). Instead, the in- ventory leftover at the end of the year is considered in (7).

3.2. Semantic Representation of Specific LP Model

The semantic view of the specific LP model case is structured as in Figure 5. The model includes the fol- lowing information: 1. Semantics of indices that describe, for example,

products, materials, facilities, and time units. 2. Linkages of indices with attributes. 3. Classification of attributes on whether they are de-

cision variables or coefficients. 4. Indexed blocks of terms (BOTs). BOT denotes a set

of terms that share the same summation sign. 5. Indices associated with constraints. 6. BOTs associated with objective function.

The case model has an one-to-one mapping with the mathematical notation of the LP model. Note that there are indices on constraints, blocks of terms, coef- ficients, and decision variables.

OBJECTIVE

LP_MODEL

has

ha. / I ~ ha.

OPERATOR

haa ( DECISION

FIGURE 5. Structure of specific LP model.

hae

An illustrative semantic model of (1)-(4) can be represented in frames as follows. First, the overall structure of model is shown in (9).

{ {MONTHLY_PRODUCTION._INVENTOR Y _MODEL

is_a: LP_MODEL objective: (MIN PRODUCTION_COST) constraints: PRODUCTION_CAPACITY

PRODUCTION...SALES __BALANCE}}

(9)

The PRODUCTION_CAPACITY constraint in (9) can be further represented by an operator and a set of BOTs with the index slot named for_each in (10). Note that there is also the "context" slot. This kind of me- taknowledge is necessary to resolve the inconsistencies between multiple constraints that axe associated with the same set of BOTs.

{ {PRODUCTION_CAPACITY_INDEXED i~ a: INDEXED_CONSTRAINT operator. LE LHS: (+ PROCESSING_TIME._BOT) RHS: (+ FACILITY_CAPACITY._BOT) for._each: FACILITY TIME_UNIT context: (TIME__UNIT MONTH)}}

(1o)

The PROCESSING_TIME_.BOT in (10)can be further represented by a pair of coefficient and decision with the index slot named sum...index in (11).

{ {PROCESSING_TIME_BOT is_a: INDEXED__BOT coefficient: UNIT...PROCESSING_TIME decision: PRODUCTION_AMOUNT sum_index: PRODUCT} }

( l l)

The attribute (decision or coefficient) in (11) can be linked with indices as in (12).

{ {PRODUCTION_.AMOUNT_WITH _JNDEX_ifl

is_a: INDEXED_.ATTRIBUTE attribute: PRODUCTION_AMOUNT index: PRODUCT FACILITY MONTH symbol: X(i, j, t) da*~ ~vailability: no}}

(12)

According to the value of the data._availability slot, the attribute is treated as either a variable or a coeffi- cient. In this case, the indexed attribute PRODUC- TION_-4MOUNT_WITH_.JNDEX_ijt is treated as a variable because the data are not available.

92 J. K. Lee and M. Y. Kim

Finally, the index in (12) can be represented as (13).

{ {PRODUCT (13) is_a: INDEX symbol: i linked_attributes:PRODUCTION_AMOUNT

UNIT_..PROCESSING_TIME} }

4. REPRESENTATION OF COMMON MODELING KNOWLEDGE BASE

As mentioned in Section 2, the common modeling knowledge base consists of the domain knowledge and modeling structure knowledge. The term "common" means that multiple users and models can share the knowledge base in a bounded environment such as a plant, a company, or an industry. For instance, the domain knowledge is concerned with products, raw materials, facilities, and time units, which are mostly used as indices of LP models. This information may be provided directly by knowledge engineers rather than by machine learning from the cases.

The structure of the modeling knowledge is shown in Figure 6. At the top level, there are potential objec-

fives and index-free constraints. The potential objective is composed of index-free blocks of terms, while the index-free constraint is composed of blocks of terms and an operator (, or =). The index-free BOT can be represented by a pair of coefficient and decision. The constraint network effectively represents the rela- tionships between the constraints and index-free BOTs. The decision, coefficient, and index-free constraints have potentially linkable indices. Figure 7 shows an illustrative constraint network generated from the two models described in Section 3.

5. CASE-BASED LEARNING FRAMEWORK

The case-based learning and formulation reasoning processes fill the gap between a specific LP model and a common modeling knowledge base. Roughly speak- ing, the formulation reasoning is a specialization pro- cess while the case-based learning is a generalization process. Thus, the two processes have opposite direc- tionality. In the case-based learning process, there are three key operations: addition of new knowledge, gen- eralization of cases, and context identification between inconsistent constraints.

OBJECTIVE CONSTRAINT

ha has

BLOCK-OF OPERATOR

has has

Iinkable

COEFFICIENT DECISION

Index

INDEX

FIGURE 6. Structure of modeling knowledge base.

Case-Based Learning for Optimization Models 93

_COST_BOT

_AMOUNT

UNIT_COST _COST_BOT

.Z t-1

SALES AMOUNT_I

SALES ~OLUUE n

PROFIT_BOT

UNIT_PROCESSING _TIME

Q : attribute

~ ) : index-free BOT

D : a constraint

_SOT

_TIME_BOT

FIGURE 7. Constr...