Ec.pdf

Ingenier´ del Conocimiento
ıa

Departamento de Computaci´n
o
Curso 2002-2003

Alumna: Laura M. Castro Souto
Profesoras: Amparo Alonso Betanzos
Bertha Guijarro Berdi˜as
n

´
Indice general

1. La Ingenier´ del Conocimiento
ıa 1
1.1. El conocimiento y su contexto . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. La ingenier´ del conocimiento . . . . . . . . . . . . . . . . . . . . . . .
ıa 2
1.3. Los sistemas basados en el conocimiento . . . . . . . . . . . . . . . . . 3

2. Metodolog´ para la construcciń de SSBBC
ıas o 5
2.1. Diferencias entre la IS y la IC . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Metodolog´ adaptadas de la IS . . . . . . . .
ıas . . . . . . . . . . . . . . 7
2.2.1. Metodolog´ de prototipado r´pido . .
ıa a . . . . . . . . . . . . . . 7
2.2.2. Metodolog´ de desarrollo incremental
ıas . . . . . . . . . . . . . . 8
2.2.3. Metodolog´ en cascada . . . . . . . .
ıas . . . . . . . . . . . . . . 8
2.2.4. Metodolog´ en espiral . . . . . . . . .
ıas . . . . . . . . . . . . . . 8
2.3. Metodolog´ CommonKADS . . . . . . . . . .
ıa . . . . . . . . . . . . . . 10
2.3.1. Nivel de Contexto: ¿Por qu´? . . . . .
e . . . . . . . . . . . . . . 10
2.3.2. Nivel de Concepto: ¿Qu´? . . . . . . .
e . . . . . . . . . . . . . . 12
2.3.3. Nivel de Implementaciń: ¿C´mo? . . .
o o . . . . . . . . . . . . . . 12

3. Modelado del contexto en CommonKADS 13
3.1. El Proceso de Modelado del Contexto . . . . . . . . . . . . . . . . . . . 14
3.1.1. El modelo de Organizaciń . . . . .
o . . . . . . . . . . . . . . . . 15
3.1.2. El modelo de las Tareas . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3. El modelo de los Agentes . . . . . . . . . . . . . . . . . . . . . . 16

4. Descripciń conceptual del conocimiento en CommonKADS
o 17
4.1. El modelo del Conocimiento . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1. Conocimiento del dominio . . . . . . . . . . . . . . . . . . . . . 20
4.1.2. Conocimiento inferencial . . . . . . . . . . . . . . . . . . . . . . 23
4.1.3. Conocimiento de la tarea . . . . . . . . . . . . . . . . . . . . . . 26
4.1.4. ¿Inferencia o Tarea? . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.5. Modelo de Datos (IS) vs. Modelo de Conocimiento (IC) . . . . . 28
4.2. Plantillas de modelos de Conocimiento. Elementos reutilizables . . . . . 29
4.2.1. Tipos de Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3. Construcciń de los modelos de Conocimiento . . . . . . . . . .
o . . . . 30
4.3.1. Identificaciń del Conocimiento . . . . . . . . . . . . . .
o . . . . 31
4.3.2. Especificaciń del Conocimiento . . . . . . . . . . . . . .
o . . . . 31

i

ii

4.3.3. Refinado del Conocimiento . . . . . . . . . . . . . . . . . . . . . 33
4.3.4. Documentaciń del modelo de Conocimiento
o . . . . . . . . . . . 34
4.4. El modelo de Comunicaciń . . . . . . . . . . . . .
o . . . . . . . . . . . 34
4.4.1. Plan de Comunicaciń . . . . . . . . . . . .
o . . . . . . . . . . . 36
4.4.2. Transaciones agente-agente . . . . . . . . . . . . . . . . . . . . . 36
4.4.3. Patrones transaccionales . . . . . . . . . . . . . . . . . . . . . . 38
4.4.4. Tćnicas de validaciń . . . . . . . . . . . .
e o . . . . . . . . . . . 39

5. El modelo de Dise˜ o en CommonKADS
n 41
5.1. Principio de Conservaciń de la Estructura . . . . . . . . . . . . . . . .
o 42
5.2. El modelo de Diseõ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
n 42
5.2.1. Diseõ de la arquitectura del sistema . . . . . . . . . . . . . . .
n 43
5.2.2. Identificaciń de la plataforma de implementaciń . . . . . . . .
o o 45
5.2.3. Especificaciń de los componentes de la arquitectura . . . . . .
o 46
5.2.4. Especificaciń de la aplicaciń en el contexto de la arquitectura
o o 48
5.3. Diseõ de prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
n 48
5.3.1. Prototipado de subsistemas de razonamiento . . . . . . . . . . . 48
5.3.2. Prototipado de interfaces de usuario . . . . . . . . . . . . . . . . 49
5.4. SBCs distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6. Tćnicas para la adquisiciń del conocimiento
e o 51
6.1. Escenarios de adquisiciń del conocimiento . . . . . . . . . .
o . . . . . . 51
6.2. Las entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.1. Entrevistas m´ltiples . . . . . . . . . . . . . . . . . .
u . . . . . . 58
6.3. El an´lisis de protocolos . . . . . . . . . . . . . . . . . . . .
a . . . . . . 59
6.4. Cuestionarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.5. An´lisis del movimiento de ojos . . . . . . . . . . . . . . . .
a . . . . . . 61
6.6. M´todo de observaciń directa . . . . . . . . . . . . . . . . .
e o . . . . . . 62
6.7. Extracciń de curvas cerradas . . . . . . . . . . . . . . . . .
o . . . . . . 62
6.8. Las tćnicas de escalamiento psicol´gico . . . . . . . . . . .
e o . . . . . . 62
6.8.1. Escalamiento multidimensional (EDM ) . . . . . . . . . . . . . . 63
6.8.2. An´lisis de clusters (Clustering) . . . . . . . . . . . .
a . . . . . . 65
6.8.3. Redes ponderadas (Pathfinder ) . . . . . . . . . . . . . . . . . . 68
6.9. La teor´ de constructos personalizados: el Emparrillado . .
ıa . . . . . . 69
6.9.1. Identificaciń de elementos Ei . . . . . . . . . . . . .
o . . . . . . 70
6.9.2. Identificaciń de caracter´
o ısticas cj . . . . . . . . . . . . . . . . . 71
6.9.3. Diseõ de la parrilla . . . . . . . . . . . . . . . . . .
n . . . . . . 71
6.9.4. Formalizaciń . . . . . . . . . . . . . . . . . . . . . .
o . . . . . . 72
6.9.5. An´lisis y estudio de los resultados obtenidos . . . .
a . . . . . . 74
6.10. Tćnicas especiales de adquisiciń de conocimiento en grupo
e o . . . . . . 77
6.10.1. Tormenta de ideas (Brainstorming) . . . . . . . . . . . . . . . . 77
6.10.2. Tćnica nominal de grupo . . . . . . . . . . . . . . .
e . . . . . . 77
6.10.3. M´todo Delphi . . . . . . . . . . . . . . . . . . . . .
e . . . . . . 77

Laura Castro

iii

7. Evaluaciń de los sistemas basados en conocimiento
o 79
7.1. Verificaciń y validaciń . . . . . . . . . . . . . . . . . . . . . . . . . .
o o 82
7.1.1. Sistemas de verificaciń autom´tica . . . . . . . . . . . . . . . .
o a 82
7.1.2. Validaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 84

Apńdices
e 86

A. Ampliaciones 87
A.1. Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Bibliograf´
ıa 93

ıa

Cap´
ıtulo 1

La Ingenier´ del Conocimiento
ıa

En este primer tema estableceremos algunos conceptos b´sicos relacionados con la
a
asignatura que nos ocupa.

1.1. El conocimiento y su contexto
¿Qu´ es el conocimiento? Es dif´ de concretar, pero podemos sin embargo distin-
e ıcil
guir claramente que no es lo mismo que un dato ni tampoco es el mismo concepto que
el de informaciń.
o
Podemos decir que:

Dato Conjunto de seãles, s´
n ımbolos, signos, que llegan a nuestros sentidos,
sin que tengan que tener significado propio.
Informaciń Datos que se agrupan y adquieren un significado que no va
o
impl´
ıcito en ellos, sino que se aprende a manejar.
Conocimiento Conjunto de datos e informaciń que adem´s tiene senti-
o a
do del prop´sito (sirve para algo) y capacidad de generar nuevo
o
conocimiento e informaciń (e incluso acciones).
o

Caracter´
ıstica Ejemplo
Datos Sin interpretar ...-...
Informaciń
o Aãde significado
n S.O.S.
Conocimiento Prop´sito y capacidad
o Alerta, emergencia,
de generaciń
o comenzar un rescate

Cuadro 1.1: Diferencias entre dato, informaciń y conocimiento
o

La definiciń de lo que es conocimiento se hace m´s dif´ ań si consideramos
o a ıcil u
que puede depender del contexto. Obviamente, un f´
ısico y un ajedrecista no tendrń la
a
misma concepciń de lo que es conocimiento referente a sus respectivas actividades.
o

1

2 Apuntes – 1. La Ingenier´ del Conocimiento
ıa

En el caso de la Ingenier´ del Conocimiento1 , esta situaciń se agrava, puesto que
ıa o
su aplicaciń se realiza en dominios muy concretos y diferentes (lo “normal” es distinto
o
en cada caso, por ejemplo, para diversos pacientes en un hospital).

A veces se define el conocimiento como “informaciń sobre la informaciń”, puesto
o o
que hay que tener cierta informaciń sobre la informaciń que se va a manejar para
o o
poder usarla adecuadamente.
La representaciń expl´
o ıcita del conocimiento es clave para distinguir entre sistemas
software cl´sicos y sistemas software basados en conocimiento.
a

Como ya hemos estudiado con anterioridad (ver [2]), se pueden establecer categor´
ıas
en el conocimiento barajado, en relaciń al origen y procedencia del mismo con respecto
o
al experto de quien lo extraemos:

Conocimiento p´ blico, que puede obtenerse directamente a partir
u
de fuentes t´
ıpicas (manuales, libros), comńmente aceptado y univer-
u
salmente reconocido.
Conocimiento semip´ blico, expl´
u ıcito pero no universalmente reco-
nocido ni comńmente aceptado, utilizado casi de forma exclusiva por
u
los especialistas del ´rea concreta.
a
Conocimiento privado, no expl´ ıcito, no universalmente reconocido
ni comńmente aceptado, de marcado carćter heur´
u a ıstico, end´geno
o
de cada uno, fruto de la propia experiencia.

Un sistema de conocimiento pretende familiarizarse con el conocimiento p´blico,
u
implementar el semip´blico y extraer el privado.
u

1.2. La ingenier´ del conocimiento
ıa
Denominamos ingenierá del conocimiento al conjunto de conocimientos y tćnicas
ı e
que permiten aplicar el saber cient´
ıfico a la utilizaciń del conocimiento, entendiendo
o
“conocimiento” como inteligencia o razń natural.
o

Partiendo de la siguiente definiciń de ingenier´ del software 2 (IEEE-99):
o ıa

La IS es la aplicaciń de una aproximaciń sistem´tica, disciplinada y cuan-
o o a
tificable, al desarrollo, funcionamiento y mantenimiento del software (apli-
caciones)

podemos adaptarla a la IC y decir, asimismo, que la IC es la aplicaciń de una
o
aproximaciń sistem´tica, disciplinada y cuantificable, al desarrollo, funcionamiento y
o a
mantenimiento del conocimiento (en aplicaciones, software).
1
En adelante, IC.
2
En adelante, IS.

Laura Castro

1.3. Los sistemas basados en el conocimiento 3

Es por ello que muchas de las metodolog´ utilizadas en el campo de la IS se han
ıas
adaptado a la IC, y que tambiń muchos de los problemas que aparecen en una se
e
reproducen en la otra tambiń. La mayor´ de ellos, como veremos en el tema corres-
e ıa
pondiente, se deben con frecuencia a la especificaciń d´bil de requisitos, a la presencia
o e
de entradas inconsistentes, etc. que dan lugar a diseõs no limpios.
n

Resumiendo, podemos definir la ingenierá del conocimiento como el conjunto de
ı
principios, m´todos, tćnicas y herramientas que permiten la construcciń de sistemas
e e o
computacionales inteligentes.

1.3. Los sistemas basados en el conocimiento
Entendemos por sistema basado en conocimiento 3 un sistema computerizado (soft-
ware) que utiliza y representa expl´
ıcitamente conocimiento sobre un dominio con-
creto para realizar una tarea que requerir´ un experto (de ser realizada por un hu-
ıa
mano), es decir, que es capaz de exportar ese conocimiento a trav´s de los mecanismos
e
apropiados de razonamiento para proporcionar un comportamiento de alto nivel en la
resoluciń de problemas en ese dominio (Guida & Tasso).
o

Las dos caracter´
ısticas clave, tal y como se ha seãlado, son:
n

la representaciń expl´
o ıcita del conocimiento, algo que diferencia a los
SBC de los sistemas software que se construyen en IS
un dominio concreto, algo que los particulariza y diferencia de los
sistemas de IA

A partir de la IA, surgieron una serie de ramas: la rob´tica, los sistemas conexionis-
o
tas, los sistemas expertos,. . . Estos ultimos fueron uno de los logros m´s importantes,
´ a
porque fueron los primeros en enfrentarse a problemas reales utilizando conocimiento
espec´ıfico de pequeõs dominios. No obstante, en los aõs 60 se produjo un retroceso
n n
en su desarrollo debido al aumento de la complejidad de los problemas que se pretend´ ıa
abordar. Aõs m´s tarde, surgir´ la IC.
n a ıa

Los beneficios m´s importantes que aportan los SBCs son:
a

Mayor rapidez en la toma de decisiones
Mayor calidad en la toma de decisiones
Mayor productividad

El desarrollo de un SBC es caro para la empresa: se necesita contratar al menos
un ingeniero de conocimiento, se va a consumir tiempo del experto. . . Si todo ello se
compensa es por estas ventajas competitivas que acabamos de mencionar.

3
A partir de ahora, SBC.

ıa

4 Apuntes – 1. La Ingenier´ del Conocimiento
ıa

Hay varios conceptos que ayudan a distinguir los SBC de software m´s convencional
a
y tambiń de programas de inteligencia artificial:
e
√
La naturaleza m´s bien heur´
a ıstica del conocimiento que contienen (IA,
aõs 50-60).
n
√
La naturaleza altamente espec´
ıfica del conocimiento (Dendral, 1970).
√
La separaciń del conocimiento de c´mo se usa —control— (General
o o
Problem Solver de McCarthy, 1963; Mycin, 1976).

BASE de CONOCIMIENTOS Memoria Activa

−Declarativos
MOTOR DE
−Operativos o de Accion
INFERENCIAS
−Metaconocimiento

explicaciones hechos y datos
y consejos especificos

INTERFAZ DE COMUNICACION, EXPLICACION Y
ADQUISICION DE CONOCIMIENTO

SUBSISTEMA SUBSISTEMA DE SUBSISTEMA DE ADQUISICION
DE USUARIO EXPLICACION DE CONOCIMIENTO

Ingeniero de
Usuario
Conocimiento

Figura 1.1: Esquema de un SBC.

Laura Castro

Cap´
ıtulo 2

Metodolog´ para la construcciń
ıas o
de SSBBC

El ingeniero de conocimiento debe:
√
elicitar
√
estructurar
√
formalizar
√
operacionalizar
toda la informaciń y el conocimiento que estń relacionados con el dominio. Esta
o e ´
no es una tarea trivial, porque el conocimiento no es algo que se pueda observar, la
informaciń procede a menudo de diversas fuentes, se presenta en diferentes formatos,
o
puede incluso ser a veces contradictoria. Es necesario organizar de alguna manera el
trabajo a realizar.
Adem´s, el conocimiento no es s´lo algo dif´ de extraer, sino tambiń un recurso
a o ıcil e
caro; por ello en los ultimos tiempos ha surgido la idea de reutilizaciń del conocimiento.
´ o

2.1. Diferencias entre la IS y la IC
Los ingenieros de conocimiento y los ingenieros de software estuvieron enfrentados
durante mucho tiempo, hasta que se dieron cuenta de no hab´ motivo para la con-
ıa
frontaciń, pues la IS no incluye a los sistemas de IC, ´sta desarrolla su software en
o e
problemas mal estructurados o mal definidos que no son tratables en IS.

En IS el cliente pide lo que quiere; en IC se hacen modelos computacionales de
un ´mbito concreto, se hace un an´lisis exhaustivo de la organizaciń donde vamos a
a a o
aplicar nuestro modelo.
Las especificaciones de requisitos en IS son completas antes de empezar; en IC esto
es casi imposible.
En IC es muy importante la adquisiciń del conocimiento, que adem´s es continua,
o a
es el cuello de botella de todos los sistemas; en IS se adquiere todo lo que se necesita
para funcionar.

5

6 Apuntes – 2. Metodolog´ para la construcci´n de SSBBC
ıas o

PROBLEMA
PROBLEMA DOMINIO DE APLICACION

ANALISIS DEL PROBLEMA
Y DEL DOMINIO

METODOS DE SOLUCION CONOCIMIENTO DEL DOMINIO
E S P ECI F I CACIONES

MODELADO DE
DISEÑO DE LA CONOCIMIENTO
ARQUITECTURA (o desarrollo del sistema vacio)

DISEÑO MODULAR ADQUISICION DE
CONOCIMIENTO
CONSTRUCCION BC

CODIFICACION Y
COMPROBACION DE PROTOTIPO
CADA MODULO

COMPROBACION
Y EVALUACION
ENSAMBLADO DE
MODULOS Y
COMPROBACION
DEL SISTEMA GLOBAL CONSTRUCCION DEL
SISTEMA META

SISTEMA SOFTWARE SISTEMA BASADO
TRADICIONAL EN CONOCIMIENTO

Figura 2.1: IS vs. IC.

Laura Castro

2.2. Metodolog´ adaptadas de la IS
ıas 7

En IC no se trabaja con lenguajes, sino con herramientas, ya que se ha conseguido
que el control, el manejo del conocimiento sea gen´rico (i.e. motores de inferencias).
e

ıas
En esta secciń revisaremos superficialmente algunas de las metodolog´ que la IC
o ıas
ha “heredado” de la IS.

2.2.1. Metodolog´ de prototipado r´pido
ıa a
Esta metodolog´ consiste en adquirir conocimientos y codificar hasta considerar
ıa
que tenemos un modelo lo suficientemente bueno.
Tras una serie de entrevistas con los clientes, usuarios y/o expertos, se intenta ver
si el dominio puede:

◦ tener una parte “central” de la que puedan colgarse las dem´s poste-
a
riormente
◦ tener varias partes que se puedan tratar inicialmente por separado y
comenzar con una de ellas

Si el contexto es favorable, se desarrolla un prototipo r´pido para mostrar al experto,
a
que se ir´ refinando y ampliando.
a
Las ventajas de esta metodolog´ residen en que la rapidez en el desarrollo de
ıa
una primera versiń del sistema motiva al experto (pronto se ve algo operativo), y
o
adem´s ayuda a centrar el desarrollo del conocimiento adem´s de no requerir demasiada
a a
experiencia. No obstante, desde el punto de vista de la IC son m´s importantes las
a
desventajas que se presentan:

dificulta la recogida de requisitos
se sustituye el estudio de especificaciones y el diseõ por la codificaciń
n o
r´pida, lo que origina debilidades
a
el crecimiento incontrolado complica la BC
las interacciones no contempladas entre distintas partes o m´dulos del
o
sistema son fuente de muchos problemas, el modelo crece distorsionado
el c´digo resulta generalmente muy poco y mal estructurado
o
no se produce un an´lisis completo de requisitos
a
no hay una buena documentaciń (o ´sta es nula)
o e
el mantenimiento es prćticamente imposible
a

Esta metodolog´ descuida todo lo que no tiene que ver directamente con el core
ıa
del conocimiento (desarrollo de una IU, comunicaciń con otro software,. . . ), con todo
o
lo que ello conlleva.

ıa

ıas o

2.2.2. Metodolog´ de desarrollo incremental
ıas
Ante el desbordamiento de la metodolog´ de prototipado r´pido, se volvi´ la vista a
ıa a o
la IS y una de las primeras metodolog´ que se adopt´ fue la de desarrollo incremental.
ıas o

Analisis formalizar objetivos

Especificaciones formalizar objetivos
Ajustes del diseño

Diseño prototipos codificacion inicial
Implementacion

Prototipo inicial
Prueba (V&V)

Evaluacion
Mantenimiento

Diseño inicial

Figura 2.2: Esquema de la metodolog´ de desarrollo incremental.
ıa

Aunque por incremental es m´s ordenada (manteniendo a la par algunas de las
a
ventajas del prototipado r´pido, como la pronta obtenciń de un sistema y una buena
a o
comunicaciń con los expertos), esta metodolog´ gira, no obstante, en torno a la imple-
o ıa
mentaciń y aunque logr´ organizar un poco m´s los sistemas, no centraba tampoco la
o o a
atenciń en la captura de requisitos y especificaciones, que ser´ m´s adecuado para un
o ıa a
sistema basado en conocimiento, a la par que no dejaba lugar para una etapa ulterior
de mantenimiento preceptivo.

2.2.3. Metodolog´ en cascada
ıas
Tambiń adaptada de la IS, esta metodolog´ trata de ajustar el alcance de la itera-
e ıa
ciń de desarrollo, que resultaba problem´tico en el caso anterior (ver figura 2.3, p´gina
o a a
11).

A pesar de conseguir reducir los errores al analizar m´s el modelo, el mantenimiento
a
sigue siendo demasiado complejo para un sistema basado en conocimiento.

2.2.4. Metodolog´ en espiral
ıas
De los modelos planos se pas´ al modelo en espiral, que aporta un interesante
o
an´lisis de riesgos, adem´s e plantear las iteraciones como capas en lugar de como
a a
bloques cerrados.
Si bien en IS no se utiliza demasiado porque resulta muy pesado, en IC iba a resolver
m´ltiples cuestiones: los prototipos sucesivos se van refinando y ampliando, se pueden
u
aãdir especificaciones en cada vuelta hasta llegar a concretar finalmente el elemento
n

Laura Castro

ıas 9

de test. Permite situar el mantenimiento en un nivel adecuado gracias al mencionado
an´lisis de riesgos. Cada fase ayuda a completar la anterior, en lugar de s´lo sumar,
a o
que era m´s el enfoque de metodolog´ anteriores, sin que se alteren los fundamentos
a ıas
anteriores.
Fue, pues, uno de los modelos que mejor funcion´, aunque no es demasiado bueno al
o
desarrollar SBC m´s grandes. No obstante, ań quedaban dos cuestiones por solucionar:
a u

∗ la adquisiciń del conocimiento segu´ siendo el cuello de botella
o ıa
∗ la capacidad de explicaciń no estaba realmente presente, ya que co-
o
nocimiento y motivos iban juntos, indivisiblemente

Debido a esto, los propios SBC no ten´ conciencia de sus l´
ıan ımites. Se necesitaba
una metodolog´ que estructurase el conocimiento de una forma m´s adecuada, al
ıa a
fin y al cabo, la verdadera diferencia entre IS e IC es el tratamiento, el manejo del
conocimiento. Todas las metodolog´ empleadas hasta el momento lo encuadraban
ıas
en un lugar o en otro, tratńdolo sin darle un nivel espec´
a ıfico como es imperativo.
Como consecuencia de estos problemas, los SBC eran por aãdidura muy dif´
n ıciles de
mantener, con fases de validaciń muy extensas.
o
Fue primero Newell el que dio la voz de alarma indicando la necesidad de tratar
el conocimiento como algo especial, reflexionando sobre lo que hay que representar y
c´mo se quiere hacerlo, y posteriormente McDermott con su teor´ sobre las “Tareas
o ıa
gen´ricas” segń la que la adquisiciń del conocimiento sigue siempre unos pasos repe-
e u o
titivos, los que impulsar´ el desarrollo de metodolog´ propias de la IC (con ra´
ıan ıas ıces,
claro est´, en las que acabamos de ver). De entre ellas, estudiaremos la metodolog´
a ıa
CommonKADS.

Newell. El nivel de conocimiento

El mayor problema detectado hasta el momento es la no-diferenciaciń de lo que
o
es conocimiento de la representaciń del mismo. La soluciń pasa por aãdir el Nivel
o o n
de Conocimiento, que est´ por encima del nivel simb´lico. En este nivel el sistema se
a o
comporta como un agente que tiene tres vistas:

componentes ≡ objetivos
acciones
cuerpo (conocimientos sobre objetos y acciones)

El medio sobre el que actá es el conocimiento: el agente toma el conocimiento, lo
u
procesa y realiza acciones para conseguir objetivos. Esto permiti´ tambiń abordar las
o e
primeras ideas sobre reutilizaciń del conocimiento: abstraer las tareas gen´ricas para
o e
volver a utilizarlas en sistemas similares.
Una metodolog´ que usa el nivel de conocimiento es KLIC (KBS Life Cycle).
ıa

ıa

ıas o

McDermott. M´todos de limitaciń de roles
e o
Los estudios de McDermott constituyeron los primeros intentos para reutilizar el
m´todo de resoluciń de problemas.
e o
Todos los sistemas ten´ un motor de inferencias separado del conocimiento hasta
ıan
ese momento. McDermott pens´ que el problema de reutilizar el motor era que parte
o
del conocimiento de control deb´ ir codificado en la base de conocimiento. As´ a la
ıa ı,
vez que se met´ conocimiento declarativo nuevo se iba deteriorando el anterior.
ıa
Para evitarlo, McDermott propuso estudiar los m´todos de resoluciń de problemas,
e o
diferencińdolos de la base de conocimientos. Como conclusiń, extrajo que hay familias
a o
de tareas que se pueden resolver por m´todos cuyo conocimiento de control es abstracto
e
y se puede aplicar a distintas instanciaciones de esa tarea. Adem´s, permite definir
a
en qu´ orden hay que adquirir el conocimiento y tambiń c´mo se implementa (al
e e o
ordenarlo, disminu´ ımos la entrop´ y es m´s fćil implementarlo).
ıa a a

2.3. Metodolog´ CommonKADS
ıa
La metodolog´ CommonKADS (Knowledge Analysis and Documentation Sys-
ıa
tem) es una variaciń de la metodolog´ en espiral de la IC, desarrollada en Europa
o ıa
en torno a 1983. Surge de su predecesora, KADS, al serle aãdido un lenguaje de mo-
n
delado conceptual (CML, Conceptual Modell Language), muy parecido a UML, y que
facilita el diseõ del sistema.
n

La metodolog´ CommonKADS es, pues, una metodolog´ estructurada que cubre
ıa ıa
la gestiń del proyecto, el an´lisis de la organizaciń, la ingenier´ del conocimiento y
o a o ıa
del software. Plasma tres de las ideas m´s utilizadas en IS e IC (modelado, reutilizaciń
a o
y gestiń del riesgo) y, siendo la unica que utiliza Orientaciń a Objetos, se organiza
o ´ o
tal y como se puede observar en la figura 2.4 (p´gina 11).
a

Esta divisiń en niveles y modelos permite su desarrollo sin que unos sean inter-
o
dependientes de otros, es decir, permite un gran nivel de desacoplamiento. El conoci-
miento se encuentra as´ perfectamente estructurado y documentado, pues cada modelo
ı
posee una serie de plantillas asociadas.

2.3.1. Nivel de Contexto: ¿Por qu´?
e
Los modelos de este nivel analizan los beneficios, el impacto, la utilidad que tendr´ el
a
SBC que se pretende construir, su viabilidad, etc.

Modelo de Organizaciń Estudia qu´ ´reas de la organizaciń son m´s
o ea o a
susceptibles de sacar provecho de un SBC. Es un estudio profundo de
la organizaciń, del impacto y posibles resultados de la implantaciń
o o
del SBC, espectativas, predisposiciń,. . .
o
Modelo de Tareas Ubicadas las tareas m´s importantes, es el momento
a
de intentar descomponer el/los sistemas en “primitivas” con el fin de

Laura Castro

2.3. Metodolog´ CommonKADS
ıa 11

Analisis del sistema

Especificaciones de requisitos

Diseño

Codificacion

Prueba

Mantenimiento

Figura 2.3: Esquema de la metodolog´ en cascada.
ıa

Modelo de la Modelo de Modelo de
Contexto Organizacion Tareas Agentes

Modelo de Modelo de
Concepto Conocimiento Comunicacion

requisitos requisitos sobre
funcionalidades interacciones
Modelo de
Implementacion Diseño

Figura 2.4: Niveles de la metodolog´ CommonKADS.
ıa

ıa

ıas o

poder abordarlas m´s fćilmente, identificar sus entradas y salidas,
a a
criterios de rendimiento, pre y postcondiciones,. . .
Modelo de Agentes Los agentes son los ejecutores de las tareas de la
organizaciń (ya sean personas f´
o ısicas, sistemas de informaciń, etc.).
o
Se analiza en este modelo qu´ normas se les aplican, plantillas, funcio-
e
nes,. . .

2.3.2. Nivel de Concepto: ¿Qu´?
e
Los modelos de este nivel conforman una descripciń conceptual del conocimiento.
o

Modelo de Conocimiento Explica en detalle qu´ tipos de conocimiento
e
e informaciń tenemos involucrados (naturaleza y estructura). Da una
o
visiń de la estructura del conocimiento independiente de la imple-
o
mentaciń.
o
Modelo de Comunicaciń Disecciona c´mo es la comunicaciń entre agen-
o o o
tes involucrados (conceptualmente).

2.3.3. Nivel de Implementaciń: ¿C´mo?
o o
Este nivel se centra en la manera de llevar a cabo, de realizar de manera concreta, el
sistema: mecanismos computacionales, arquitectura, representaciń del conocimiento
o
m´s adecuada, etc.
a

Modelo de Dise˜ o Usando fundamentalmente el Modelo de Conocimien-
n
to y el Modelo de Comunicaciń, se intentan obtener los requisitos y
o
restricciones prćticas del sistema.
a

Laura Castro

Cap´
ıtulo 3

An´lisis de viabilidad e impacto:
a
modelado del contexto en
CommonKADS

El conocimiento siempre funciona dentro de una organizaciń. En este cap´
o ıtulo,
entre otras cosas, veremos:
√
Por qu´ es necesario modelar el contexto
e
√
El papel de los modelos: Organizaciń, Tareas y Agentes
o
√
Pasos y tćnicas en el an´lisis del conocimiento orientado a las empre-
e a
sas y las instituciones
√
Casos de ejemplo

Razones del modelado del contexto
A menudo es dif´ identificar el uso rentable de tecnolog´ basadas
ıcil ıas
en conocimiento.
El laboratorio es diferente del “mundo real”.
La aceptabilidad de los usuarios es muy importante.
Un sistema s´lo puede funcionar de forma adecuada si est´ propia-
o a
mente integrado a largo plazo en la organizaciń en la que trabaja.
o
Un SBC actá como un agente que coopera con otros, humanos o no,
u
y lleva a cabo una fracciń de las tareas de la organizaciń.
o o
Un SBC es una herramienta de apoyo dentro del proceso general de la
organizaciń, al igual que cualquier sistema de informaciń, en general.
o o

Muchas de estas cuestiones no se ten´ en cuenta en metodolog´ anteriores, lo
ıan ıas
que supone un gran avance.

13

14 Apuntes – 3. Modelado del contexto en CommonKADS

Las metas del modelado del contexto son:

Identificar qu´ cuestiones suponen problemas y cu´les no.
e a
Decidir soluciones y su viabilidad.
Mejorar las tareas y el conocimiento relativo a ´stas.
e
Planificar la necesidad de cambios en la organizaciń.
o

El papel de los SBC se rige por una serie de directrices:

◦ Normalmente los SBCs encajan mejor en proyectos de mejora de la
organizaciń, m´s que en la visiń tradicional de automatizar las tareas
o a o
del experto.
◦ Las tareas son normalmente demasiado complejas y el proyecto se suele
convertir en un fracaso, a ra´ de expectativas poco realistas.
ız
◦ Es mejor usar los SBCs como herramientas de mejora de procesos.
◦ El papel t´
ıpico de los SBCs es el de un asistente interactivo inteligente,
a diferencia de la mayor´ de los sistemas autom´ticos, que son pasivos.
ıa a

3.1. El Proceso de Modelado del Contexto
Los pasos a seguir son:

1. Llevar a cabo un estudio de alcance y viabilidad. Herramienta: Modelo
de Organizaciń (OM).
o
2. Llevar a cabo un estudio de impacto y mejora (para enfocar/am-
pliar/refinar el modelo de la organizaciń). Herramienta: Modelos de
o
Tareas y de Agentes (TM, AM).

Cada estudio consta de una parte de an´lisis y una parte de decisiń constructiva:
a o

1. Estudio del alcance y viabilidad:
a) An´lisis.- Se trata de identificar las ´reas problema/oportunidades
a a
y buscar soluciones potenciales, ubicńdolos en una perspectiva
a
m´s amplia en la organizaciń.
a o
b) S´
ıntesis.- Se trata de estudiar la viabilidad econ´mica, tćnica y
o e
del proyecto, elegir el ´rea (o ´reas) m´s comprometedora y la
a a a
soluciń meta.
o
2. Estudio de impacto y mejoras (para cada ´rea elegida en el paso an-
a
terior):
a) An´lisis.- Se estudian las interrelaciones entre la tarea, los agentes
a
involucrados y el uso de conocimiento para un sistema con ´xito, e
intentando ver qu´ mejoras se pueden lograr.
e

Laura Castro

3.1. El Proceso de Modelado del Contexto 15

b) Diseõ.- Se decide acerca de los cambios en las tareas y las medidas
n
de la organizaciń para asegurar su aceptaciń y la integraciń de
o o o
una soluciń basada en SBC.
o
Como ya hemos visto en el cap´
ıtulo anterior, el nivel contextual aglutina tres mo-
delos:
Estudio de alcance y viabilidad
• Modelo de la Organizaciń (OM) para describir y analizar la or-
o
ganizaciń en sentido amplio
o
Estudio de impacto y mejoras
• Modelo de Tareas (TM) y Modelo de Agentes (AM), m´s centrados
a
y detallados, enfocan las partes relevantes
• TM: tareas y conocimiento relativo a ellas directamente relacio-
nado con el problema a resolver con el SBC
• AM: agentes involucrados en las tareas del TM
Para simplificar este trabajo se dispone de formularios u hojas de trabajo que ayu-
dan en el proceso de modelado:
5 formularios para el OM
2 formularios para el TM
1 formulario para el AM
1 formulario resumen
Estas hojas de trabajo funcionan como “checklist” y como archivo de informaciń,
o
debiendo ser utilizados de forma flexible.

3.1.1. El modelo de Organizaciń
o
Veremos ahora c´mo analizar una organizaciń intensiva en conocimiento:
o o
∗ Describir aspectos de la organizaciń
o
— carpeta de oportunidades/problemas
— contexto de negocio, metas, estrategia
— organizaciń interna
o
√
estructura
√
procesos
√
personas (plantilla, roles funcionales,. . . )
√
potencial y cultura
√
recursos (conocimiento, sistema de soporte, equipos,. . . )
∗ Hacer este trabajo para la organizaciń presente y la futura
o
∗ Comparar y tomar las primeras decisiones de qu´ hacer
e

ıa

16 Apuntes – 3. Modelado del contexto en CommonKADS

Modelo de Organizacion

OM−5
OM−1 OM−2 OM−3 OM−4

Problemas/Oportunidades Descripcion del area elegida

Contexto general Estructura
Procesos Decomposicion detallada
Personal
Cultura y potencial
Recursos
Soluciones potenciales Descripcion a traves de
Conocimiento activos de conocimiento

Figura 3.1: Modelo de la Organizaciń.
o

Se remite a los apńdices para detalle de las plantillas correspondientes a cada paso
e
del an´lisis del Modelo de Organizaciń.
a o

Hasta aqu´ es el an´lisis de los aspectos est´ticos de la organizaciń, los que no se
ı, a a o
supone que vayan a cambiar.

3.1.2. El modelo de las Tareas
El modelo de Tareas describe, utilizando tambiń una serie de plantillas que se
e
adjuntan en los apńdices, las tareas que se determinan componen los procesos de la
e
organizaciń y que fueron esbozadas en algunos apartados referentes al modelo de la
o
Organizaciń.
o

3.1.3. El modelo de los Agentes
Por su parte, el modelo de Agentes detalla el papel, relevancia, conocimiento y
otras caracter´ısticas relativas a los agentes que llevan a cabo o participan en las tareas
identificadas en el modelo de Tareas. De nuevo, remitimos a los apńdices para estudio
e
de las plantillas asociadas.

Laura Castro

Cap´
ıtulo 4

Descripciń conceptual del
o
conocimiento en CommonKADS

Como hemos visto, CommonKADS organiza la aproximaciń a un SBC de la si-
o
guiente forma:

Modelo de la Modelo de Modelo de
Organizacion Tareas Agentes

Modelo de Modelo de
Conocimiento Comunicacion

Modelo de
Diseño

En este cap´
ıtulo nos centraremos en el modelado del Conocimiento.

4.1. El modelo del Conocimiento
Los modelos de Conocimiento son una herramienta especializada para especificar
tareas en dominios intensivos de/en conocimiento.

Un modelo de conocimiento especifica los requisitos de conocimiento y razonamien-
to del sistema futuro. No incluye aspectos de comunicaciń con los usuarios ni con
o
otros agentes software, ni tampoco contiene t´rminos espec´
e ıficos de implementaciń.
o

17

18 Apuntes – 4. Descripciń conceptual del conocimiento en CommonKADS
o

Su estructura es similar a la de los modelos de an´lisis tradicional en ingenier´ del
a ıa
software, siendo un aspecto importante para la reutilizaciń del software.
o

Requisitos y especificaciones
MODELO de interaccion
COMUNICACION

MODELO de ORGANIZACION TAREA MODELO
MODELO de TAREAS INTENSIVA DISEÑO
MODELO de AGENTES en CONOCIMIENTO

MODELO
Tarea seleccionada en estudio de viabilidad CONOCIMIENTO
y desarrollada en modelos de tareas y agentes de razonamiento

El t´rmino conocimiento ya ha sido comentado con anterioridad: lo hab´
e ıamos de-
finido como “informaciń sobre la informaciń”. Un ejemplo de ello podr´ ser, por
o o ıa
ejemplo, en las jerarqu´ superclase-subclase de tipos de objetos, un link entre dos
ıas
clases, que proporciona informaciń sobre la relaciń entre ambas.
o o
El conocimiento se puede utilizar para inferir nueva informaciń, de suerte que no
o
hay realmente una frontera definida entre informaciń y conocimiento.
o

En un SBC, el conocimiento est´ presente como tal en la base de conocimientos.
a
Normalmente, se prefiere tener varias bases de conocimiento, cada una aglutinando
reglas de un tipo determinado, de manera que sea posible su reutilizaciń y tambiń
o e
su correcciń de forma m´s sencilla.
o a

Dentro del modelo del conocimiento, distinguiremos varias categor´ de conoci-
ıas
miento:

Conocimiento de la Tarea ¿Qu´ y c´mo?
e o
Es un conocimiento orientado a la meta y que realiza una descompo-
siciń funcional.
o
Conocimiento Inferencial
Encarna los pasos b´sicos del razonamiento que se pueden hacer en el
a
dominio (en el contexto de un problema) y que se aplican mediante
las tareas.
Conocimiento del Dominio
Aglutina el conocimiento y la informaciń relevantes del dominio es-
o
t´tico, equivaliendo de algń modo al modelo de datos o de objetos en
a u
IS.

Laura Castro

4.1. El modelo del Conocimiento 19

Conocimiento de la Tarea: DIAGNOSIS
(tarea)

Conocimiento Inferencial: HIPOTETIZAR VERIFICAR
(inferencia) (inferencia)

Conocimiento del Dominio: SINTOMA ENFERMEDAD PRUEBA
(tipo) (tipo) (tipo)

Modelo de
Conocimiento

Conocimiento Conocimiento Conocimiento
del Dominio Inferencial de la Tarea

Figura 4.1: Categor´ en el modelo del Conocimiento.
ıas

ıa

o

4.1.1. Conocimiento del dominio
El conocimiento del dominio describe la informaciń est´tica m´s importante y los
o a a
objetos de conocimiento en un determinado dominio.

Tiene dos partes principales:

Esquema del Dominio
Describe la estructura est´tica de la informaciń/conocimiento a trav´s
a o e
de definiciones tipo, siendo comparable al modelo de datos/objetos en
IS. Queda definido a trav´s de los constructos del dominio.
e
Base de Conocimientos
Contiene instancias de los tipos que se especifica en el esquema del
dominio (es decir, conjuntos de instancias de conocimiento), siendo
comparable al contenido de una base de datos.

Modelo de
Conocimiento


Esquema Base de
del Dominio Conocimientos

CONSTRUCTOS

Tipos de
Conceptos Relaciones
Regla

Figura 4.2: Constructos del modelo del Conocimiento.

Constructos en el esquema del dominio
La mayor´ son similares a los de O.O. (especialmente los diagramas de clases):
ıa

Laura Castro


Conceptos Describen un conjunto de objetos o instancias del dominio que
comparten caracter´
ısticas similares (como los objetos en O.O. pero sin
operaciones ni m´todos).
e
Relaciones Como las asociaciones en O.O.
Atributos Valores primitivos. Caracter´
ısticas de los conceptos.
Tipos de reglas Introducen expresiones (no hay equivalente en IS).
Se incluyen, adem´s, otros para cubrir aspectos espec´
a ıficos del modelado SBC.

Conceptos y Atributos
Como hemos dicho, un concepto describe un conjunto de objetos o instancias. Las
caracter´
ısticas de los constructos se definen mediante atributos, que pueden tener un
valor (at´mico) que se define a trav´s de un tipo de valor (definiciń de los valores
o e o
permitidos).
Los conceptos son el punto de comienzo para el modelado del conocimiento.

Relaciones
´
Las relaciones entre conceptos pueden definirse con el constructo relacion o re-
´ ´
lacion binaria (e incluso relacion n-aria) a trav´s de las especificaciones de
e
argumentos.
La cardinalidad se define para cada argumento y su valor por defecto es 1. Es posible
especificar un rol para cada argumento.
La propia relaciń puede tener atributos.
o

coche pertenencia persona NO DIRECCIONAL
0+ 0−1

coche propiedad−de persona DIRECCIONAL

coche persona REIFICACION
(si la relacion tiene atributos
propiedad o participa en otras relaciones)

fecha−adquisicion

Figura 4.3: Relaciones en el modelo del Conocimiento.

El modelado de las reglas
Las reglas son una forma natural y comń de representar el conocimiento simb´lico.
u o
Ahora bien, ¿c´mo representamos dependencias entre conceptos en un modelo de datos
o
tradicional?

ıa

o

Para modelar la construcciń de las reglas se usa el constructo tipo de regla:
o

Es similar a una relaciń, donde antecedente y consecuente no son
o
instancias de conceptos sino expresiones de esas instancias.
Se modela una relaciń entre expresiones acerca de los valores de los
o
atributos.
Se modelan un conjunto de reglas de estructura similar.
Las relaciones no son estrictamente l´gicas, es necesario especificar un
o
s´ ´
ımbolo de conexion entre antecedente y consecuente.

Estructura de tipo de regla

La estructura es sencilla:

<antecedente> <s´mbolo-de-conexiń> <consecuente>
ı o

Su uso flexible permite la representaciń de cualquier tipo de dependencia (tipos
o
m´ltiples para antecedente y consecuente).
u

ESTADO causa
ESTADO
INVISIBLE

dependencia
estado

ESTADO tiene−manifestacion ESTADO
INVISIBLE OBSERVABLE
manifestacion
regla

TIPO−de−REGLA regla−manifestacion
DESCRIPCION "..."
ANTECEDENTE estado−invisible
CONSECUENTE estado−observable
SIMBOLO tiene−manifestacion
END−TIPO−de−REGLA

Figura 4.4: Ejemplos de representaciń de Tipos de Regla.
o

Laura Castro


Base de Conocimientos
Es una particiń conceptual de la BC que contiene instancias de los tipos de cono-
o
cimiento definidos en el esquema del dominio.

Las instancias de los tipos de reglas contienen reglas. Su estructura tiene dos partes:

◦ el slot usa: <tipos-usados>de <esquema>
◦ el slot expresiones: <instancias>

Las instancias pueden representarse formalmente, o bien semiformalmente con el
s´
ımbolo de conexiń separando antecedente y consecuente.
o

BASE−CONOCIMIENTOS
USA ... de ...
... de ...
EXPRESIONES
/* dependientes−estado */
...
/* manifestacion−regla */
...
END−BASE−CONOCIMIENTOS

Figura 4.5: Ejemplo de representaciń de Base de Conocimientos.
o

4.1.2. Conocimiento inferencial
El conocimiento inferencial describe el nivel inferior de descomposiciń funcional.
o
Describe c´mo las estructuras est´ticas del conocimiento del dominio se pueden usar
o a
para realizar el proceso de razonamiento, permitiendo la reutilizaciń del conocimiento.
o

Sus elementos principales se aprecian en la figura 4.6 y son:

Inferencias Relacionadas con el razonamiento, son las unidades b´sicas
a
de procesado de informaciń.
o
Funciones de Transferencia Relativas a la comunicaciń con otros agen-
o
tes (a un nivel muy b´sico, esta cuestiń se trata realmente en el Mo-
a o
delo de Comunicaciń).
o
Roles de Conocimiento Relacionados indirectamente con el conocimien-
to del dominio.

Una inferencia usa el conocimiento de alguna base de conocimiento para derivar
nueva informaciń.
o
Los roles din´micos son las entradas y salidas en tiempo de ejecuciń de las infe-
a o
rencias.

ıa

o

Modelo de
Conocimiento


Roles de Funciones de
Inferencias
Conocimiento Transferencia

Figura 4.6: Elementos del Conocimiento Inferencial.

explicar

ENTRADA SALIDA
INFERENCIA
(rol dinamico) (rol dinamico)

queja hipotesis

Modelo
Causal

(rol estatico)

Figura 4.7: Ejemplo de Inferencia.

Laura Castro


Inferencias

Las inferencias quedan completamente descritas a trav´s de una especificaciń de-
e o
clarativa de propiedades de su E/S. Los procesos internos de la inferencia son una caja
negra.

Rol de Conocimiento

Proporcionan un nombre funcional para elementos dato/conocimiento. Dicho nom-
bre captura el rol del elemento en el proceso de razonamiento, realizando un mapeado
expl´
ıcito a los tipos del dominio.
Los roles din´micos son variantes E/S, mientras que los est´ticos son entradas in-
a a
variantes (una base de datos).

INFERENCIA explicar ROL−CONOCIMIENTO nombre
ROLES TIPO dinamico
ENTRADA ... MAPEADO−DOMINIO visible−estado
SALIDA ... END−ROL−CONOCIMIENTO
ESTATICOS ...
ESPECIFICACION "..."
END_INFERENCIA

Funciones de Transferencia

Las funciones de transferencia transfieren un item de informaciń entre el agente de
o
razonamiento del m´dulo de conocimiento y otro agente del mundo externo (usuario,
o
otro sistema,. . . ).
Desde el punto de vista del modelo de conocimiento es una caja negra: s´lo interesa
o
su nombre y su E/S. La especificaciń detallada de las funciones de transferencia es
o
parte de otro modelo, el de Comunicaciń.
o

Iniciativa Iniciativa
sistema externa
Informaciń externa
o obtener recibir
Informaciń interna
o presentar proporcionar

Cuadro 4.1: Nombres estńdar de las Funciones de Transferencia.
a

Estructura Inferencial

La combinaciń de los diferentes conjuntos de inferencias especifica la capacidad
o
inferencial b´sica del sistema en desarrollo. El conjunto de inferencias se puede presen-
a
tar gr´ficamente en una estructura inferencial, que hace ńfasis en los aspectos
a e
din´micos del flujo de datos (roles est´ticos opcionales).
a a

ıa

o

rol conocimiento
queja
dinamico
funcion de
rol estatico
transferencia
modelo
explicar obtener hecho real
causal

hecho
hipotesis predecir comparar
esperado

modelo
resultado
manifestacion

Figura 4.8: Ejemplo de Mapa Inferencial.

Uso de las Estructuras Inferenciales
Las estructuras inferenciales son representaciones abstractas de los posibles pasos
del proceso de razonamiento, y, como tales, son un veh´ıculo importante de comunicaciń
o
durante el proceso de desarrollo, a pesar de que a menudo puedan ser provisionales.
Suele ser util realizar anotaciones con ejemplos espec´
´ ıficos del dominio.
Las estructuras inferenciales definen las capacidades inferenciales del sistema, el
vocabulario y las dependencias de control, pero no el control en s´ (del que se ocupa el
ı
conocimiento).

Reutilizaciń de inferencias
o
El estado ideal ser´ disponer de un conjunto estńdar de inferencias. Con ese obje-
ıa a
tivo, se recomienda el uso de nombres lo m´s estńdar posibles con el fin de favorecer
a a
la reutilizaciń.
o

4.1.3. Conocimiento de la tarea
El conocimiento de la tarea describe metas (por ejemplo, asesorar la suscripciń o
de una hipoteca, diseãr un ascensor,. . . ) y las estrategias que se pueden utilizar para
n
realizar dichas metas. Esta descripciń sigue un esquema jer´rquico.
o a
Tal y como se puede observar en la figura 4.9, distinguiremos, dentro del conoci-
miento de la tarea, la propia Tarea y por otra parte lo que llamaremos el M´todo de la
e
Tarea.

Tarea
La Tarea define la meta del razonamiento en forma de pares (entrada, salida), con
el fin de especificar qu´ es necesario saber.
e
La diferencia principal con las funciones tradicionales es que los datos manipulados
por la tarea se describen tambiń independientemente del dominio.
e

Laura Castro


Modelo de
Conocimiento


Metodo de
Tarea
la Tarea

Figura 4.9: Elementos del Conocimiento de la Tarea.

El hecho de que la descripciń deba ser independiente del dominio tiene como ob-
o
jetivo la reutilizaciń de las tareas.
o

Una tarea se describe por medio de tres slots:

META Descripciń textual informal.
o
SPEC Describe de manera textual e informal la relaciń entre la entrada
o
y la salida de la tarea.
ROLES

Los roles de E/S se especifican en forma de roles funcionales, como en las inferencias,
pero con algunas diferencias:

no hay roles est´ticos
a
no hay mapeado de los roles en t´rminos espec´
e ıficos del dominio; los
roles de las tares estń linkados a los roles inferenciales
a
cada tarea tiene un m´todo asociado
e

M´todo de la Tarea
e
El M´todo de la Tarea describe c´mo se realiza una tarea mediante su descompo-
e o
siciń en subfunciones. Las subfunciones pueden ser otra tarea, inferencias o funciones
o
de transferencia.
La parte central del m´todo de la tarea se denomina estructura de control y describe
e
el orden de las subfunciones, capturando la estrategia de razonamiento.

Los elementos de la estructura de control son:

ıa

o

explicar

predecir

obtener comparar

Figura 4.10: Ejemplo de esquema de un posible M´todo de la Tarea.
e

◦ llamadas a procedimientos (tareas, inferencias, funciones de transfe-
rencia)
◦ operaciones de roles (asignaciń, suma/resta,. . . )
o
◦ primitivas de control (repetir,. . . )
◦ condiciones
expresiones l´gicas sobre roles
o
condiciones especiales: tiene soluciń y nueva soluciń
o o

4.1.4. ¿Inferencia o Tarea?
Si el comportamiento interno de una funciń1 es importante para explicar el com-
o
portamiento del sistema como un todo, entonces es necesario definir esta funciń como
o
una tarea.
Durante el desarrollo del modelo, es usual manejar estructuras inferenciales provi-
sionales.

4.1.5. Modelo de Datos (IS) vs. Modelo de Conocimiento (IC)
Los Modelos de Datos contienen “datos sobre datos”, ya que en Ingenier´ delıa
Software lo importante son los datos. Sin embargo, la Ingenier´ del Conocimiento se
ıa
centra en el conocimiento, hace ńfasis en el control interno y desarrolla funciones
e
que se describen independientemente del modelo de datos, lo que favorece una mayor
reutilizaciń posterior.
o
1
Donde por funciń podemos entender tanto “tarea” como “inferencia”.
o

Laura Castro

4.2. Plantillas de modelos de Conocimiento. Elementos reutilizables 29

4.2. Plantillas de modelos de Conocimiento.
Elementos reutilizables
En lo que llevamos visto hasta el momento, destacan una serie de puntos clave en
lo que a reutilizaciń se refiere:
o

√
Los modelos de conocimiento pueden ser parcialmente reutilizados en
aplicaciones nuevas.
√
La gu´ principal para la reutilizaciń es el tipo de tarea.
ıa o
√
Existe un cat´logo de plantillas de tareas intensivas en conoci-
a
miento (como los patrones en O.O.).

Los fundamentos de la reusabilidad pasan por no reinventar la rueda cada vez que
nos enfrentamos a un problema, conseguir la m´xima eficiencia coste/tiempo, disminuir
a
la complejidad y asegurar la calidad.

Una plantilla es una combinaciń de elementos del modelo reutilizables:
o

Estructura inferencial (provisional)
Estructura de control t´
ıpica
Esquema del dominio t´
ıpico desde el punto de vista de la tarea

Todo ello es espec´ıfico para el tipo de tarea que describe cada plantilla en par-
ticular. Gracias a estas plantillas este m´todo de modelado soporta el modelado del
e
conocimiento “top-down”.

4.2.1. Tipos de Tareas
El rango de tipos de tareas est´ limitado. Esto es una ventaja de la IC en compa-
a
raciń con los antiguos SSEE.
o
En el trasfondo de esto se encuentran la ciencia cognitiva y la psicolog´
ıa.

La estructura de la descripciń en la plantilla es la siguiente:
o

1. Caracterizaciń general.
o
2. M´todo por defecto.
e
3. Variaciones t´
ıpicas (cambios/ajustes frecuentes).
4. Esquema t´ ıpico del conocimiento del dominio (asunciones sobre las
estructuras del dominio).

ıa

o

Tareas Anal´
ıticas Tareas Sint´ticas
e
Sistemaa Preexiste (aunque no es conocido). No existe ań.
u
Entrada Datos acerca del sistema. Requisitos del sistema que se construir´.
a
Salida Alguna caracter´ ıstica del sistema. Descripciń del sistema construido.
o
Tipos clasificacion´ ˜
diseno
asesoramiento modelado
diagnostico planificacion ´
monitorizacion ´ asignacion´
prediccion´ scheduling

a
Entendemos por sistema un t´rmino abstracto que designa el objeto sobre el que se aplica la
e
tarea. En diagn´stico tćnico, por ejemplo ser´ el artefacto o aparato que est´ siendo diagnosticado.
o e ıa a

Cuadro 4.2: Tareas Anal´
ıticas vs. Tareas Sint´ticas.
e

4.3. Construcciń de los modelos de Conocimiento
o
La metodolog´ CommonKADS enfoca el modelo del conocimiento como un produc-
ıa
to. Esto hace que se forme un cuello de botella por falta de experiencia en el modelado
del conocimiento.
La soluciń, como es fćil de preveer, pasa por modelar, a su vez, el proceso.
o a

No obstante, el modelado es una actividad constructiva para la que no existe una
soluciń correcta ni un camino ´ptimo. As´ pues, lo que se hace es proporcionar una
o o ı
gu´ que funciona bien en la prćtica.
ıa a

El modelado del conocimiento es una forma especializada de especificaciń de re-
o
quisitos en el que se usan, por tanto, principios generales de la IS.

ESTADOS

Identificacion del Familiarizacion con el dominio, lista
Conocimiento potencial de componentes reutilizables

Especificacion del Escoger plantilla de tareas, construir conceptualizacion
Conocimiento inicial, especificacion completa del modelo del dominio

Refinado del Validacion del modelo del conocimiento,
Conocimiento refinado de las bases de conocimiento

Figura 4.11: Gu´ para el modelado del Conocimiento.
ıa

Laura Castro

o 31

4.3.1. Identificaciń del Conocimiento
o
META Estudiar los items de conocimiento, prepararlos para su especificaciń.
o
ENTRADA Tarea intensiva en conocimiento, principales items de conocimiento iden-
tificados, clasificaciń de la tarea de la aplicaciń.
o o
ACTIVIDADES Explorar fuentes de informaciń y estudiar la naturaleza de la ta-
o
rea.
Los factores m´s importantes con respecto a las fuentes de informaciń
a o
son su naturaleza (¿son claras? ¿tienen base te´rica?) y su diversidad
o
(¿son conflictivas? ¿con qu´ factor de riesgo?).
e
Las tćnicas para su exploraciń son las tradicionales: marcado de tex-
e o
tos, entrevistas, etc. El problema principal reside en encontrar un ba-
lance entre aprender sobre el dominio y convertirse en un experto.
Algunas gu´ ıas:
Hablar con la gente que trata a los expertos pero que no son ex-
pertos
Evitar sumergirse en teor´ complicadas y detalladas
ıas
Construir unos cuantos escenarios t´
ıpicos
No pasar demasiado tiempo en esta actividad
Una vez acometidas estas actividades, puede realizarse una valoraciń de resulta-
o
dos, tanto tangibles (listado de fuentes, res´menes de textos, glosario, descripciń
u o
de escenarios), como intangibles (la propia comprensiń).
o
La presencia de una lista de componentes tiene como objetivo allanar el camino
en el manejo de componentes reutilizables en dos dimensiones:

◦ Dimensiń de la Tarea (elegida del tipo asignado en el TM, construir una
o
lista de plantillas)
◦ Dimensiń del Dominio (tipo de dominio, buscar descripciń estńdar)
o o a

4.3.2. Especificaciń del Conocimiento
o
META Completar la especificaciń del conocimiento excepto para los contenidos de
o
los modelos del dominio (que necesitan s´lo contener instancias).
o
ACTIVIDADES
Elegir una plantilla de la tarea Como l´ ınea base de actuaciń, no debemos
o
olvidar que existe una fuerte preferencia por un modelo de conocimiento
basado en aplicaciones ya existentes (por razones de eficacia y calidad ase-
gurada). Los criterios de selecciń son las caracter´
o ısticas de la tarea de la
aplicaciń (naturaleza de las entradas y salidas del sistema, restricciones del
o
contexto. . . ).
Algunas gu´ para la selecciń de plantillas:
ıas o

ıa

o

Preferir las que se usan con m´s frecuencia (por evidencia emp´
a ırica).
Construir una estructura inferencial anotada con ejemplos y un esquema
del dominio.
Si no se ajusta a ninguna plantilla, cuestionar la intensidad en conoci-
miento de la tarea.
Construir una conceptualizaciń inicial del dominio Ha de construirse un
o
esquema del dominio inicial, que tendr´ dos partes:
a
Conceptualizaciń espec´
o ıfica del dominio (que no es probable que cam-
bie).
Conceptualizaciń de m´todos espec´
o e ıficos (s´lo necesaria para resolver
o
ciertos problemas —excepciones a la norma, no demasiado relevantes
en este punto—).
Como “salida” de este paso obtendremos un esquema que debe cubrir al
menos las conceptualizaciones espec´
ıficas del dominio.
Algunas gu´ sobre c´mo actuar:
ıas o
◦ Utilizar en lo posible el modelo de datos existente (usar al menos la
misma terminolog´ en los constructos b´sicos; har´ las cooperaciones
ıa a a
e intercambios futuros m´s sencillos).
a
◦ Limitar el uso del lenguaje de modelo de conocimiento a conceptos,
subtipos y relaciones (concentrarse en los “datos”, de manera similar a
cuando se construye un modelo de clases inicial).
◦ Si no existe modelo de datos disponible, usar tćnicas estńdar de IS
e a
para encontrar conceptos y relaciones.
Especificar las tres categor´ del conocimiento Por ultimo, se termina la
ıas ´
especificaciń completa del dominio, pudiendo enfrentarse de dos maneras:
o
1. Ruta Middle-Out. Es la aproximaciń preferida, empieza con el conoci-
o
miento inferencial. Como precondiciń, la plantilla de la tarea ha de ser
o
una buena aproximaciń de la estructura inferencial.
o
2. Ruta Middle-In. Comienza en paralelo con la descomposiciń de la tarea
o
y el modelado del dominio, por lo que consume m´s tiempo. Es necesario
a
si la plantilla de la tarea es de grano “demasiado grueso”.
La estructura inferencial est´ suficientemente detallada si lo est´ la expli-
a a
caciń que proporciona, o tambiń si es fćil encontrar para cada inferencia
o e a
un tipo de conocimiento del dominio que acté tal y como se espera.
u

Algunas gu´ para especificar el conocimiento de la tarea:
ıas
◦ Empezar con la estructura de control.
◦ No incluir detalles de la memoria de trabajo.
◦ Elegir nombres de roles aclarativos (Modelar es nombrar ).
◦ No incluir roles de conocimiento est´tico.
a

Laura Castro

o 33

◦ En aplicaciones de tiempo real, considerar usar una representaciń al-
o
ternativa al pseudoc´digo (UML).
o
Algunas gu´ para especificar el conocimiento inferencial :
ıas
◦ Comenzar con la representaciń gr´fica.
o a
◦ Elegir los nombres de rol cuidadosamente (carćter din´mico, hip´tesis,
a a o
datos iniciales,. . . ).
◦ Usar un conjunto lo m´s estńdar posible de inferencias.
a a
Algunas gu´ para especificar el conocimiento del dominio:
ıas
◦ Usar como roles est´ticos los tipos del dominio (no tienen que tener la
a
representaciń correcta, esta ser´ una tarea del diseõ).
o a n

4.3.3. Refinado del Conocimiento
El refinado del Conocimiento pasa por:
1. Validaciń del modelo de Conocimiento.
o
2. Rellenar las Bases de Conocimiento.

Validaciń del modelo de Conocimiento
o
La validaciń debe ser interna (verificaciń, ¿es el modelo adecuado?) y externa
o o
(validaciń contra los requisitos del usuario, ¿es correcto el modelo?).
o
Existen diferentes tćnicas de validaciń:
e o
Interna:
• Rutas estructuradas (probar escenarios t´
ıpicos)
• Herramientas software
Externa:
• Suele ser m´s dif´ y/o amplia
a ıcil
• Tćnica principal: simulaciń (prototipos, simulaciń basada en
e o o
papel)
En cuanto al mantenimiento, segń el punto de vista de CommonKADS, no es
u
algo diferente del desarrollo del modelo, pues es algo c´
ıclico. El modelo es como un
repositorio de informaciń; debemos especificar requisitos para obtener herramientas
o
de soporte potentes.

Rellenar las Bases de Conocimiento
El esquema contiene dos tipos de dominios: tipos de informaciń parte de un caso
o
y tipos de informaciń parte de un modelo de conocimiento.
o
La meta es determinar todas las instancias de cada tipo. Las instancias s´lo se ne-
o
cesitan para un escenario.

Algunas gu´ para el rellenado de las bases de conocimiento:
ıas

ıa

o

◦ Rellenar las bases de conocimiento es una forma de validar el esquema
construido.
◦ Normalmente no es posible definir una base de conocimientos correcta
y completa en un primer ciclo.
◦ Las bases de conocimiento necesitan mantenimiento (el conocimiento
cambia con el tiempo).
◦ Tćnicas: incorporar facilidades de ediciń para las bases de cono-
e o
cimiento, trazas, entrevistas estructuradas, aprendizaje autom´tico,
a
mapeado de otras bases de conocimiento.

4.3.4. Documentaciń del modelo de Conocimiento
o
Una vez construido el modelo, se redacta un documento KM-1 (ver apńdices), que
e
contendr´:
a

Especificaciń del modelo de conocimiento.
o
Listado de fuentes de informaciń.
o
Listado de los componentes reusables del modelo.
Escenarios t´
ıpicos del problema que resuelve la aplicaciń.
o
Resultados de validaciń de la simulaciń.
o o
Material de elicitaciń.
o

4.4. El modelo de Comunicaciń
o
El papel del modelo de Comunicaciń es especificar los procesos de transferencia
o
de informaciń/conocimiento. Es, en cierto modo, un control de nivel superior sobre
o
la ejecuciń de la tarea (m´ltiples tareas intensivas en conocimiento). Tareas de comu-
o u
nicaciń adicionales, pueden, adem´s, aãdir facilidades de explicaciń al sistema. Un
o a n o
ejemplo es la interaciń b´sica sistema-usuario.
o a

MODELO de interaccion
COMUNICACION

MODELO de TAREAS TAREA MODELO
MODELO de AGENTES INTENSIVA DISEÑO
en CONOCIMIENTO

MODELO
Detallada en modelos de tareas y agentes CONOCIMIENTO Requisitos y especificaciones
de razonamiento

Figura 4.12: Relaciń del modelo de Comunicaciń con otros modelos.
o o

Laura Castro

o 35

Las “entradas” al modelo de Comunicaciń son:
o

Modelo de Tareas Lista de tareas hoja llevadas a cabo por los agentes
considerados.
Modelo de Conocimiento Funciones de transferencia.
Modelo de Agentes Descripciń de agentes relevantes, capacidades, res-
o
ponsabilidades y restricciones.

Cada vez m´s, los sistemas de informaciń son informaciń + sistema de comuni-
a o o
caciń:
o
√
Aplicaciones distribuidas (telem´tica).
a
√
Organismos virtuales.
√
Sistemas multiagente inteligentes.
√
Manejo de flujos de trabajo.
√
Ingenier´ concurrente.
ıa
√
Manejo e integraciń de la cadena de negocio.
o

El modelado de la informaciń debe cubrir:
o

An´lisis de la organizaciń.
a o
An´lisis de las tareas.
a
An´lisis de actores/agentes (sistemas y humanos).
a

Normalmente, varios actores cooperan en un proceso de negocio o tarea. El modelo
de Comunicaciń se centra en modelar el di´logo entre agentes afrontńdolo mediante
o a a
una aproximaciń semiformal estructurada.
o

Tarea Agente

Plan de Comunicacion Transaccion Especificaciones sobre el
intercambio de Informacion

Estructura de la Tarea

Figura 4.13: Estructura del modelo de Comunicaciń.
o

ıa

o

La aproximaciń por capas al modelado de las comunicaciones consta de tres niveles:
o

Plan de Comunicaciones general.- Gobierna el di´logo completo entre
a
dos agentes.
Transacciones individuales.- Son las que unen dos tareas hoja llevadas
a cabo por dos agentes diferentes.
Especificaciń del intercambio de informaciń.- Detalla la estructu-
o o
ra de las transacciones.

Como se puede ver, pues, las transacciones son el componente clave del modelo
de Comunicaciń. Describen qu´ objetos de informaciń se intercambian, indicando los
o e o
agentes y tareas implicados. Son el bloque de construcciń para el di´logo completo
o a
entre un par de agentes, y tienen una estructura interna.
Haciendo abuso de lenguaje, suele llamarse transacciń incluso a lo que se inter-
o
cambia entre dos tareas llevadas a cabo por diferentes agentes.
A un nivel superior, est´ el plan de comunicaciń, que gobierna el di´logo com-
a o a
pleto entre los agentes, siendo la especificaciń concreta del modelo de Comunicaciń.
o o

4.4.1. Plan de Comunicaciń
o
Generalmente es m´s fćil comenzar por el plan de comunicaciń global. El plan de
a a o
comunicaciń describe completamente el di´logo de alto nivel, siendo sus transacciones
o a
t´
ıpicas: entrada de datos, contestaciń de preguntas, presentaciń de resultados, etc.
o o

Actividades
Para cada agente se confeccionar´ una lista de todas las tareas en las que participa,
a
y para cada tarea se identificar´ el conjunto de transacciones agente-agente asociadas.
a

El resultado se combina en un diagrama de di´logo (DD, ver figura 4.14) que repre-
a
senta las transacciones entre cada par de agentes que se comunican. Se dibuja, pues, un
DD para cada combinaciń de dos agentes que intercambian informaciń, especificando
o o
de esta manera el control sobre las transacciones.

Como alternativa a la notaciń del DD, se puede utilizar tambiń pseudoc´digo
o e o
con primitivas de control especiales: enviar, recibir, llevar a cabo, esperar,
procesar, repetir,. . .

4.4.2. Transaciones agente-agente
El nivel de especificaciń medio del modelo de Comunicaciń est´ encarnado en la
o o a
especificaciń de las transacciones individuales, estructuradas en un n´mero de com-
o u
ponentes.
Tćnicas simples de formulario son utiles aqu´ (ver formulario CM-1 en apńdices).
e ´ ı e

Laura Castro

o 37

Agente A Agente B
(por ejemplo, usuario) (por ejemplo, sistema)

Tarea A1 transaccion 1 Tarea B1
Tarea A2 Tarea B2
. transaccion 2 .
. . .
. . .
Tarea Ax . Tarea By

Dialogo

(las tareas hoja de los agentes
son clave para la construccion del DD)

Figura 4.14: Estructura general de un Diagrama de Di´logo.
a

Las transacciones suelen agruparse tras un unico plan de comunicaciń, salvo en
´ o
sistemas multiagente.

Identificador y
Agentes Nombre
Plan de comunicacion

Transaccion
Objetivo informacion
Restricciones

Especificacion intercambio
informacion

Figura 4.15: Esquema de la estructura de una transacciń (CM-1).
o

Tareas Delegaciń Tareas Adopciń Tareas Intercambio
o o
Request Propose Ask
Require Offer Reply
Order Agree Report
Reject td Reject ta Inform

Cuadro 4.3: Tipos de comunicaciń.
o

ıa

o

Las transacciones tienen, en general, una primera parte informativa y una segunda
parte de “solicitud de acciń” (usualmente un mensaje de delegaciń de tarea). Las
o o
transacciones no s´lo admiten, pues, un contenido, sino tambiń una relaciń preten-
o e o
dida entre dos agentes. Ambos aspectos deben especificarse expl´ ıcitamente.

Los lenguajes de comunicaciń de agentes (ACL) estń inspirados a menudo por la
o a
teor´ del acto del habla, que hace distinciones entre el contenido y el efecto pretendido.
ıa

4.4.3. Patrones transaccionales
Ya por ultimo, nos centraremos en el nivel de detalle del modelo de Comunicaciń,
´ o
que consiste en la especificaciń detallada del mensaje:
o

Su contenido, expresado mediante una declaraciń proposicional (locuciń).
o o
Su intenciń2 , expresada mediante un mensaje escrito (ilocuciń).
o o

Los tipos predefinidos son los ya indicados en la tabla 4.3 (solicitar, exigir,
ordenar, rechazar; proponer, ofrecer, acordar, rechazar; preguntar,
responder, informar y enviar informe).

Cuadro 4.4: Semńtica de algunos tipos de comunicaciń.
a o

request/propose Negociaciń para colaborar
o
require/offer Compromiso condicional
order/agree Efectuar un acuerdo
reject Negarse a efectuar la peticiń
o
ask/reply Preguntar sobre informaciń y recibir respuesta
o
report Informe como consecuencia de un acuerdo previo
inform Acciń informativa independiente
o

Por supuesto, no s´lo es posible enviar mensajes simples, tambiń se pueden formar
o e
cadenas naturales de tipos de mensajes.

El resumen de la especificaciń de los intercambios de informaciń se aglutina en el
o o
formulario CM-2, que s´lo suele ser necesario para patrones de comunicaciń complejos
o o
(es un detalle del CM-1). Su estructura es la siguiente:

◦ Identificador y nombre de la transacciń.
o
◦ Agentes involucrados (emisor, receptor).
◦ Items de informaciń; se componen a su vez de:
o
– rol (objeto central + item soporte3 )
2
Intenciń = prop´sito + cometido.
o o
3
Textos explicativos de material del dominio, trazados de razonamiento, explicaciones porqu´/co-
e
mo.

Laura Castro

o 39

– forma sintćtica (cadenas de datos, diagramas, etc.)
a
– medio (ventana pop-up, interfaz de l´ınea de comandos, interven-
ciń humana. . . )
o
◦ Especificaciń del mensaje.
o
◦ Control del mensaje (es un refinado del control especificado en el plan
de comunicaciń, que usar´ la misma notaciń: diagramas de estado o
o a o
pseudoc´digo).
o

4.4.4. Tćnicas de validaciń
e o
Para validar el modelo de Comunicaciń suelen emplearse walkthroughs en el plan
o
de comunicaciń, para verificar la adecuaciń de la estructura de las transacciones, la
o o
completitud de la lista de items de informaciń y la necesidad de ayuda o explicaciń.
o o
Existen tćnicas m´s formales, como la tćnica Mago de Oz, que se basa en la
e a e
misma idea que el test de Turing. No obstante, su uso es caro pues es una tćnicae
experimental para validar la interacciń que requiere de la construcciń de un software
o o
maqueta.

Gu´ de Nielsen para la usabilidad
ıa

Presentar diagramas simples y naturales.
Hablar el lenguaje del usuario.
Minimizar la carga de memoria del usuario.
Mantener la consistencia de la terminolog´
ıa.
Proporcionar informaciń sobre lo que est´ pasando (retroalimenta-
o a
ciń).
o
Mostrar salidas claramente marcadas desde los estados no deseados.
Ofrecer atajos al usuario experto.

Gu´ para pesar el modelo de Comunicaciń
ıas o

Entradas clave:
→ Tareas hoja del TM.
→ Funciones de transferencia del KM.
Tener en cuenta las capacidades de los agentes (AM).
La formulaciń sintćtica del medio es algo entre el CM y el DM (se
o a
aborda en el CM si existen razones conceptuales para ello).
Decidir sobre la informaciń de soporte (no en DM).
o

ıa

o

Actividades del modelo de Comunicaciń
o
Identificar los objetos de informaciń centrales para ser intercambiados
o
entre agentes.
Identificar las transacciones asociadas.
Dibujar los DD importantes.
Combinar esto en un plan de comunicaciones completo.
Especificar las transacciones individuales (CM-1 y CM-2).
Validar y pesar el modelo.

Laura Castro

Cap´
ıtulo 5

Del an´lisis a la implementaciń: el
a o
modelo de Dise˜ o en
n
CommonKADS

El Diseõ del sistema recibe como entradas:
n
√
El modelo de Conocimiento (requisitos para la resoluciń de proble-
o
mas)
√
El modelo de Comunicaciń (reglas de interacciń)
o o
√
Otros modelos (requisitos “no funcionales”)

Y obtendr´ como salidas la especificaciń de una arquitectura software y el diseõ
a o n
de la aplicaciń dentro de dicha arquitectura.
o

Dominio Aplicacion Sistema Software

Modelos de Analisis

expertos Modelo Conocimiento
arquitectura software
libros Modelo Comunicacion
diseño algoritmos
protocolos
Modelo Tareas Modelo Diseño diseño TDAs
casos
plataforma hardware
estrategias Modelo Agentes
razonamiento
lenguaje implementacion
Modelo Organizacion
tiempo respuesta
requerido

problemas y
oportunidades

Figura 5.1: Del an´lisis al diseõ en CommonKADS.
a n

41

42 Apuntes – 5. El modelo de Diseõ en CommonKADS
n

Entendemos por arquitectura del sistema la descripciń del software en t´rminos de
o e
descomposiciń en subsistemas, seleciń del r´gimen(es) de control y descomposiciń
o o e o
de los subsistemas en m´dulos software.
o
Especificar esta arquitectura es el punto central el proceso de diseõ, y se parte de
n
una serie de arquitecturas de referencia para sistemas basados en CommonKADS.

5.1. Principio de Conservaciń de la Estructura
o
El principio de Conservaciń de la Estructura es el principio central del diseõ
o n
moderno:

“Debe preservarse el contenido y la estructura del modelo de an´lisis durante
a
el diseõ.”
n

Segń esta filosof´ diseãr es “aãdir detalles espec´
u ıa, n n ıficos de implementaciń a los
o
resultados del an´lisis”, preservando la informaciń como nociń clave.
a o o
Esto est´ directamente relacionado con los criterios de calidad del diseõ en general:
a n

√
Minimizar el acoplamiento.
√
Maximizar la cohesiń.
o
√
Transparencia.
√
Mantenimiento.

A estos criterios generales, cuando hablamos de diseõ de SBCs, se aãden los
n n
siguientes:

√
Reusabilidad de elementos de diseõ/c´digo resultante.
n o
√
Mantenimiento y adaptabilidad (el desarrollo en un solo paso es nor-
malmente poco realista, especialmente para sistemas intensivos en co-
nocimiento).
√
Potencia explicativa.
√
Adquisiciń de conocimiento/facilidad para el refinado (el conocimien-
o
to cambia con el tiempo).

5.2. El modelo de Dise˜ o
n
En la construcciń del modelo de Dise˜ o se seguirń los siguientes pasos:
o n a

Laura Castro

5.2. El modelo de Diseõ
n 43

Paso 1 Paso 2 Paso 3 Paso 4

Detalle de la
Diseño de la Especificacion de la especificacion Detalle del diseño
Arquitectura Plataforma hw/sw de la Arquitectura de la Aplicacion

Arquitecturas de Lista de entornos Checklist de Mapeado
referencia de disponibles decisiones predefinido a
CommonKADS arquitecturales arquitectura

Conocimiento de soporte al Diseño en CommonKADS

Figura 5.2: Pasos en la construcciń del modelo de Diseõ.
o n

5.2.1. Dise˜ o de la arquitectura del sistema
n
El primer paso en la construcciń del modelo de Diseõ es, pues, la especificaciń
o n o
de la arquitectura global.

El principio que se sigue es separar la funcionalidad de aspectos de la interfaz, para
lo que, como ya se ha mencionado, se descompone el sistema en subsistemas, se defi-
ne un r´gimen de control global y se descomponen los subsistemas en m´dulos software.
e o

La arquitectura global seguir´ el modelo MVC (Model View Controller ), que fue
a
desarrollado para el diseõ O.O. en lenguaje Smalltalk-80 pero que ha sido adoptado
n
mayoritariamente en el diseõ de software. Este modelo distingue entre los objetos de
n
una aplicaciń y su visualizaciń y define una unidad de control central con r´gimen
o o e
dirigido por eventos. El sistema construido siguiendo esta filosof´ tendr´ tres subsis-
ıa a
temas principales, indicados en la figura 5.3.

Subsistema Modelo de Aplicacion
El modelo de la aplicaciń contiene los datos y funciones de la aplicaciń, esto es,
o o
los objetos del modelo de conocimiento.
Los datos estń presentes en forma de bases de conocimiento y datos din´micos
a a
manipulados durante el razonamiento (por ejemplo, roles din´micos), mientras que las
a
funciones estń representadas por las tares, inferencias y funciones de transferencia.
a

Subsistema Vistas
Este subsistema se encarga de la visualizaciń de los datos y funciones de la apli-
o
caciń, haciendo posible la visualizaciń de la informaciń est´tica y din´mica a los
o o o a a
agentes externos, como el usuario o bien otro sistema software.

ıa

n

entrada

Controlador vistas Vistas
usuario
controlador
maneja entradas proporcionan salida
desde agentes externos a agentes externos
sensores
y funciones internas (IU, query a BD)

invocacion informe de
de funciones resultados

Modelo Aplicacion

funciones de razonamiento
(tareas, inferencias)
esquema(s) del dominio
bases de datos/conocimiento

Figura 5.3: Esquema del Model View Controller.

Es posible tener visualizaciones m´ltiples, agregar la visualizaciń de m´ltiples ob-
u o u
jetos de la aplicaciń, etc.
o
La inclusiń de este subsistema requiere actualizaciń arquitectural o bien meca-
o o
nismos de integraciń, como pueden ser una tabla de mapeos o protocolos de mensajes
o
para notificaciń de cambios en el estado de los objetos.
o

Subsistema Controlador
Es la unidad central de control y comandos. Suele estar dirigido por eventos, pro-
porcionando handlers para eventos tanto externos como internos.
Permite la activaciń de las funciones de la aplicaciń y decide qu´ hacer cuando
o o e
llegan los resultados. Puede definir sus propias vistas de control para proporcionar
informaciń sobre el proceso (por ejemplo, al usuario experto). Suele tener un reloj
o
interno y una agenda, pudiendo tener un comportamiento tipo daemon.

Algunos otros aspectos importantes de la arquitectura MVC, adem´s de haber sido
a
desarrollada en el contexto de la O.O. (de hecho, es una descomposiciń funcional de
o
“objetos”), pasan por darnos cuenta de que su uso no est´ necesariamente restringido
a
a una aproximaciń al diseõ/implementaciń O.O., aunque el paradigma de paso de
o n o
mensajes debe ajustarse bien a los entes de la arquitectura.

A la hora de descomponer el modelo de la aplicaciń en subsistemas debemos tener
o
en cuenta que se debe permitir el diseõ preservando la estructura, as´ como permitir
n ı
la integraciń con otras aproximaciones de la IS.
o

Laura Castro

n 45

Las opciones son dos: una descomposiciń funcional o bien una descomposiciń O.O.
o o
La opciń escogida por CommonKADS es la segunda, ya que se ajusta bien al carćter
o a
declarativo de las especificaciones de los objetos en el modelo de conocimiento (puede
verse una tarea como un objeto) y adem´s simplifica el mapeado con implementaciones
a
O.O. en muchas herramientas.

Este primer paso en la construcciń del modelo de Diseõ queda reflejado en el
o n
modelo DM-1 (ver apńdices).
e

5.2.2. Identificaciń de la plataforma de implementaciń
o o
El segundo paso en la construcciń del modelo de Diseõ es la identificaciń de la
o n o
plataforma de implementaciń.
o

Los requisitos espec´
ıficos del cliente suelen restringir esta selecciń, lo que es una
o
razń para colocarla en un paso temprano dentro del proceso. Hoy en d´ la selecciń
o ıa, o
del software es mucho m´s importante que la del hardware, aunque puede no serlo en
a
el caso de aplicaciones en tiempo real.
En caso de que la selecciń fuese m´s o menos libre, deber´
o a ıamos considerar pos-
ponerla hasta que se finalizase el tercer paso (especificaciń de los componentes de la
o
arquitectura).

Algunos criterios para la selecciń de la plataforma de implementaciń pueden ser:
o o

Existencia de librer´ de clases de objetos “vista” (puede ser necesario
ıas
construir muchos uno mismo en caso contrario).
Formalismo en la representaciń del conocimiento (preferentemente
o
una representaciń declarativa).
o
Existencia de interfaces estńdar con otro software (ODBC, COR-
a
BA,. . . suelen ser necesarias a menudo).
Facilidades para la escritura del lenguaje (un “tecleado d´bil” normal-
e
mente implica m´s trabajo en el mapeado del modelo de an´lisis).
a a
Facilidades de control/protocolos (soporte de paso de mensajes, posi-
bilidad de multi-threading).
Soporte de CommonKADS (extensiń de plataformas dedicadas —
o
por ejemplo, librer´ de objetos—, links con herramientas CASE que
ıas
soporten CommonKADS).

Este segundo paso en la construcciń del modelo de Diseõ queda reflejado en el
o n
e

ıa

n

5.2.3. Especificaciń de los componentes de la arquitectura
o
El tercer paso en la construcciń del modelo de Diseõ es la especificaciń de los
o n o
componentes arquitecturales.

Esta especificaciń consiste en definir los componentes de la arquitectura en m´s
o a
detalle. En particular, se definen las interfaces entre los subsistemas y/o m´dulos de
o
los sistemas, especificando sus componentes.
Se realiza as´ un diseõ general de las utilidades de la arquitectura. Algunas plata-
ı n
formas incorporan una arquitectura CommonKADS en las que las decisiones han sido
predefinidas; esto tiene como ventaja que este paso se hace m´s r´pido y fćil, pero por
a a a
contra destruye la capacidad creativa.

Utilidades del Controlador
El controlador realiza un control dirigido por eventos con un componente central
de control. Puede verse como una implementaciń del modelo de comunicaciń.
o o
Las declaraciones t´
ıpicas son:

∗ Activaciń y finalizaciń de funciones de la aplicaciń.
o o o
∗ Decisiń sobre la posibilidad de que el usuario realice interrupciones
o
para informarse del trazado/contexto.
∗ Posibilidad de abortar funciones.
∗ Manejo de funciones de transferencia/transacciones.
∗ Necesidad o no de procesado concurrente.

Utilidades del Modelo de Aplicaciń
o
∗ Tarea: para los objetos necesitamos definir dos operaciones:
◦ Un m´todo de inicializaciń, para iniciar los valores de la tarea.
e o
◦ Un m´todo de ejecuciń, que invoque al m´todo de la tarea.
e o e
∗ M´todo de la Tarea:
e
◦ Elementos del lenguaje de control (constructos de control).
◦ Declaratividad del lenguaje de control (por ejemplo, en O.O., la
implementaciń natural es una operaciń execute, pero destruye
o o
la naturaleza declarativa; es necesario “objetificar” la estructura
de control).
∗ Inferencias:
◦ Tres operaciones principales: execute, more solutions y has-
solution.
◦ Enlaces a los m´todos de inferencia.
e
∗ M´todos de Inferencia:
e

Laura Castro

n 47

◦ Librer´ de m´todos.
ıa e
◦ Permitir relaciones muchos-a-muchos entre m´todos e inferencias.
e
∗ Funciones de transferencia:
◦ Implementaciń v´ patrones de paso de mensajes.
o ıa
∗ Roles din´micos:
a
◦ Tipos de datos permitidos: elemento, conjunto, lista,. . .
◦ Operaciones de acceso/actualizaciń, selecciń, eliminaciń, aãdir,
o o o n
etc.
∗ Roles est´ticos:
a
◦ Funciones de acceso/consulta.
∗ Modelo del dominio (bases de conocimiento):
◦ Formato representacional.
◦ Funciones de acceso/consulta.
◦ Funciones de modificaciń/an´lisis.
o a
∗ Constructos del dominio:
◦ Simplemente inspeccionar.

Utilidades de las Vistas
∗ Visualizaciones gr´ficas estńdar.
a a
∗ Generaciń de formatos externos (por ejemplo, consultas SQL).
o
∗ Utilidades arquitecturales de actualizaciń de vistas:
o
◦ Tablas de mapeado.
◦ Protocolos de mensajes.

Interfaces de Usuario
∗ Interfaz con el usuario normal:
◦ Considerar utilidades especiales (por ejemplo, generaciń de len-
o
guaje natural).
◦ Uso de visualizaciones espec´
ıficas del dominio (depende del diseõ
n
de la aplicaciń).
o
∗ Interfaz con usuarios expertos:
◦ Interfaz de trazados.
◦ Interfaz de ediciń/refinado para bases de conocimiento.
o

Este tercer paso en la construcciń del modelo de Diseõ queda reflejado en el
o n
e

ıa

n

5.2.4. Especificaciń de la aplicaciń en el contexto
o o
de la arquitectura
El ultimo paso en la construcciń del modelo de Diseõ es la especificaciń del
´ o n o
diseõ en el contexto de la arquitectura. Esta tarea se divide en dos:
n

1. Mapear la informaciń de an´lisis en la arquitectura.- Se necesitan
o a
construir o disponer de herramientas de mapeo (por ejemplo, un API).
La extensiń del mapeo depende de las decisiones que estń ya cons-
o a
truidas en la arquitectura.
2. Aãdir detalles de diseõ.- Debe hacerse el diseõ de la aplicaciń para
n n n o
el controlador:
◦ Su entrada principal es el Modelo de Comunicaciń.o
◦ A menudo es necesario el procedimiento natural.
◦ Como m´ ınimo es necesario un procedimiento de bootstraping.
◦ Otras funciones:
manejo de requisitos de explicaciń
o
control de usuario sobre el proceso de razonamiento
interrupciń del razonamiento/control estrat´gico
o e
permitir escenarios what-if (simulaciń)
o

La especificaciń de la aplicaciń en el contexto de la arquitectura queda reflejado
o o
en el formulario DM-4 (ver apńdices).
e

5.3. Dise˜ o de prototipos
n
El “prototipado r´pido” tiene una mala reputaciń porque este t´rmino ha sido
a o e
empleado para referirse a implementaciones r´pidas y poco cuidadas imposibles de
a
mantener y escalar. No obstante, hoy en d´ est´ considerada como una buena tćnica
ıa a e
para comprobar el grado de comprensiń que se tiene sobre aquello que se desea llegar
o
a contruir.

5.3.1. Prototipado de subsistemas de razonamiento
¿Cuńdo puede ser necesario construir un prototipo del subsistema de razonamien-
a
to?

Cuando contemos con elementos recientemente construidos en el mo-
delo de conocimiento (plantillas nuevas).
Cuando sospechemos de agujeros en el conocimiento del dominio.
En general, para validar y verificar el modelo del dominio:
• validar (¿es el sistema adecuado?)

Laura Castro

5.4. SBCs distribuidos 49

• verificar (¿es adecuado el sistema?)

Adem´s la plataforma de implementaciń debe soportar el prototipado, su cons-
a o
trucciń debe ser cuestiń de d´
o o ıas.

5.3.2. Prototipado de interfaces de usuario
La construcciń de un prototipo de interfaz con el usuario nos brinda la oportunidad
o
de comprobar la interfaz sin necesidad de desarrollar toda su funcionalidad. Puede ser
necesario si el formato de vistas es complejo e incluso para poder construir una interfaz
externa m´s completa.
a

5.4. SBCs distribuidos
Hay varios campos en los que potencialmente ser´ interesante usar una arquitectura
ıa
distribuida a la hora de construir un SBC:

Servicios de razonamiento
El modelo de aplicaciń funciona como un servicio. No es necesaria
o
una interfaz de usuario.
Servidores basados en conocimiento/ontol´gicos
o
Unifican la terminolog´ SSEE. Un ejemplo ser´ el GRASP, un servi-
ıa ıa
dor para piezas de arte.
Servicio de m´todos
e
Un sistema distribuido en forma de un conjunto de m´todos.
e

Y, por supuesto, combinaciones de los mencionados.

ıa

Cap´
ıtulo 6

Tćnicas para la adquisiciń del
e o
conocimiento

Llamamos adquisiciń del conocimiento al proceso de recoger los datos e infor-
o
maciń que necesitamos para construir nuestro SBC.
o
Para ello se utilizan una serie de tćnicas que pueden ser manuales, usualmente m´s
e a
fćiles de usar por parte del ingeniero de conocimiento y m´s fćiles de aceptar por
a a a
el experto aunque m´s costosas en tiempo, semiautom´ticas e incluso completamente
a a
autom´ticas.
a

El problema es que la adquisiciń del conocimiento no es una actividad inmediata.
o
Los propios expertos no son conscientes de su conocimiento y su forma de actuar, que
les resulta complicado verbalizar, pues muchas veces es pragm´tico. Para paliar esto en
a
mayor o menor medida es util elegir, dentro de lo posible, varios expertos, que pueden
´
ser de distintos tipos:

Experto te´rico o acad´mico: posee conocimientos m´s encaminados a
o e a
la parte docente, m´s formales. Suele ser capaz de explicar racional-
a
mente pero est´ poco relacionado en la prćtica.
a a
Experto prćtico: resuelve los problemas d´ a d´ aporta una visiń
a ıa ıa, o
m´s “real” (escenarios). Da soluciones, es un experto tćnico, aplica
a e
algo porque funciona, sin quiz´s tener una explicaciń formal.
a o

Pese a todo, nunca debemos olvidar que existe un componente personal muy im-
portante, que no se puede evitar.

6.1. Escenarios de adquisiciń del conocimiento
o
Hay cuatro escenarios t´
ıpicos de adquisiciń del conocimiento:
o

51

52 Apuntes – 6. Tćnicas para la adquisiciń del conocimiento
e o

SISTEMA EXPERTO

Motor Inferencias
INGENIERO
EXPERTO (conocimento general
CONOCIMIENTO
solucionador de problemas)

Base Conocimientos
(conocimientos
del dominio)

Figura 6.1: Primer escenario de adquisiciń del conocimiento.
o

El escenario 1 (figura 6.1) es el m´s t´
a ıpico.

SISTEMA EXPERTO

Motor Inferencias
PROGRAMA EDITOR
EXPERTO INTELIGENTE (conocimento general

Base Conocimientos
(conocimientos
del dominio)

Figura 6.2: Segundo escenario de adquisiciń del conocimiento.
o

El escenario 2 (figura 6.2) surge de la mente de McCarthy (1968) y su “Advice Ta-
ker”, aunque su mejor trabajo fue teiresias (1976). Consiste en que el experto habla
con el programa en lugar de con el ingeniero de conocimiento (¡que es, obviamente, el
que ha construido el programa!), ayudando de este modo a que se implique y favore-
ciendo la depuraciń. Por supuesto, lo extremadamente complejo es la construcciń del
o o
mencionado sistema/programa interlocutor.

El programa de inducciń —por ejemplo, una red de neuronas— (escenario 3, figura
o
6.3) intenta extraer algń tipo de conocimiento, generalizaciones fundamentalmente,
u
a partir de los datos. Este conocimiento se traducir´ posteriormente al “mundo” del
a
SBC (paso que, por cierto, puede ser no trivial ni directo). La ventaja es que ya es
una tćnica autom´tica (salvo en la introducciń de los datos). El problema, que la
e a o
construcciń de estos programas de inducciń que generalicen algo util no es fćil.
o o ´ a

Laura Castro

o 53

SISTEMA EXPERTO

Motor Inferencias
PROGRAMA
DATOS DE INDUCCION (conocimento general

Base Conocimientos
(conocimientos
del dominio)

Figura 6.3: Tercer escenario de adquisiciń del conocimiento.
o

SISTEMA EXPERTO

PROGRAMA Motor Inferencias
LIBROS DE COMPRENSION
(conocimento general
TEXTO DE TEXTO solucionador de problemas)

Base Conocimientos
(conocimientos
del dominio)

Figura 6.4: Cuarto escenario de adquisiciń del conocimiento.
o

El programa de comprensiń de texto (escenario 4, figura 6.4) deber´ comprender
o ıa
diagramas, esquemas, y poseer un “criterio”. La interpretaciń del lenguaje natural,
o
aunque sea referido a un campo espec´
ıfico, es algo muy complicado.

El conocimiento, por su parte, tambiń puede ser de muchos tipos (lo iremos vien-
e
do).

ıa

e o

DIRECTIVOS EXPERTOS USUARIOS
Identificacion Descripcion tareas Hechos y relaciones conocidos
Aprobacion proyecto Identificacion ejecuciones exito Consejos
Respuestas y soluciones

Plantea problemas
y cuestiones
INGENIERO CONOCIMIENTO

Selecciona buen dominio y tarea
Aprende sobre la tarea de directivos, expertos y usuarios
Conoce como construir SSBBCC
Conoce las ventajas e inconvenientes de las herramientas

conocimiento estructurado
en forma de conceptos y formalizado

INGENIERO CONOCIMIENTO

Analiza necesidades de representacion y estrategias de control
Regla del pulgar, heuristicas y reglas del dominio
Elige la herramienta
Construye los distintos prototipos
La integra y la mantiene

Laura Castro

o 55

Dec´logo del Ingeniero de Conocimientoa
a

Facultades de Comunicaciń
o
Utilizaciń efectiva del lenguaje (oral y escrito).
o
Capacidad de representaciń esquem´tica.
o a
Capacidad de interpretaciń.o
Trato agradable.
Inteligencia
Capacidad de aprendizaje.
Apertura de mente y flexibilidad.
Tacto y Diplomacia
Reflexiń y tacto.
o
Energ´ y Paciencia
ıa
Valoraciń del trabajo en equipo.
o
Capacidad de decisiń, discusiń, cr´
o o ıtica y estimulaciń.
o
Persistencia
L´gica
o
Claridad de pensamiento, capacidad de orden.
Versatilidad e Inventiva
Potencia anal´
ıtica.
Imaginaciń.
o
Autoconfianza
Conocimiento del Dominio de Aplicaciń
o
Conocimiento acerca de la Programaciń del Sistema
o
a
El problema es que estas todas estas cualidades no suele reunirlas una sola per-
sona, de modo que es necesario la creaciń de grupos interprofesionales.
o

Cuadro 6.1: Dec´logo del Ingeniero de Conocimiento.
a

ıa

e o

Tipo Conocimiento Actividad Tćnica
e
declarativo B´squeda de heur´
u ısticas Entrevistas no estructuradas
generales
procesal B´squeda de rutinas
u Entrevistas estructuradas
y procedimientos
´
semantico B´squeda de conceptos
u Observaciń directa
o
y vocabulario An´lisis de Tareas
a
Heur´ısticas y Procedimientos Emparrillado
de toma de decisiones Clasificaciones
Trazado del proceso
de razonamiento
´
episodico B´squeda de heur´
u ısticas Simulaciones
anal´gicas de soluciń
o o Trazado del proceso de
de problemas razonamiento (An´lisis de
a
protocolos)

Cuadro 6.2: M´todos de Adquisiciń del Conocimiento.
e o

La tćnica a utilizar para la adquisiciń del conocimiento depende no s´lo del tipo
e o o
de conocimiento a adquirir, sino tambiń del dominio, circunstancias particulares, etc.
e

6.2. Las entrevistas
Las entrevistas son un m´todo sencillo, manual, de adquisiciń del conocimiento
e o
que puede ser utilizado por cualquier persona, en cualquier dominio, con cualquier tipo
de experto y con cualquier tipo de conocimiento.

Las primeras entrevistas suelen recibir el nombre de entrevistas de despliegue y su
finalidad es interaccionar con el experto, conocerse mutuamente, etc. Normalmente hay
que vencer una mala predisposiciń, explicar lo que se pretende hacer, lo que se espera
o
del experto,. . . y por tanto su duraciń no deber´ ser muy extensa.
o ıa

A continuaciń aparecen las sesiones de adquisiciń que son de dos tipos:
o o
No estructuradas (sesiones de carćter general).
a
Estructuradas (sesiones de carćter espec´
a ıfico).
Tras la toma de contacto, las entrevistas no estructuradas (no se esperan respues-
tas cerradas a las preguntas que se plantean) sirven para familiarizarse con el dominio
concreto. Hay que saber conducirlas para evitar divagaciones y anćdotas del experto.
e
Muchos de los datos que se adquieran aqu´ no serń directamente trasladables al SBC,
ı a
pero nos ayudarń a hacernos una idea sobre posibles estructuras inferenciales, etc.
a

Se har´ por ultimo una entrevista estructurada para cada parte del sistema identi-
a ´
ficado, donde s´ ya se necesitan respuestas concretas. Suelen tener un guiń con puntos
ı o
similares a:

Laura Castro

6.2. Las entrevistas 57

1. Tćnicas de an´lisis basadas en tareas familiares.
e a

a) Observaciń directa.
o
b) Resoluciń de casos destacados o dif´
o ıciles.

2. Tćnicas basadas en entrevistas.
e

a) No estructuradas.
b) Estructuradas.
c) An´lisis de casos hist´ricos destacados y dif´
a o ıciles.

3. Tćnicas de an´lisis basadas en tareas especiales.
e a

a) Tćnicas psicol´gicas para estudiar resoluciń de problemas.
e o o
1) An´lisis de protocolos.
a
2) An´lisis de toma de decisiones.
a
3) Brainstorming.
b) Tćnicas psicol´gicas para estudiar aprendizaje y memoria.
e o
1) Resoluciń de tareas con informaciń limitada.
o o
2) Resoluciń de tareas con procedimientos limitados.
o
c) Tćnicas que enjuician caracter´
e ısticas de los conceptos.
1) Clasificaciones.
2) Emparrillado.
3) Escalonadas.
4) Escalamiento psicol´gico.
o

Cuadro 6.3: Clasificaciń de los M´todos de Adquisiciń de Conocimiento.
o e o

ıa

e o

√
Descripciń general de la tarea.
o
√
Descripciń de variables involucradas/influyentes.
o
√
Reglas generales que ligan a las variables:
Plantilla 1: ¿Por qu´? Convierte afirmaciones en reglas.
e
Plantilla 2: ¿C´mo? Genera reglas de menor nivel.
o
Plantilla 3: ¿Cuńdo? Extrae generalidad de las reglas, generando
a
otras.
Plantilla 4: ¿Qu´ alternativas hay? Extrae generalidad de las reglas,
e
generando otras.
Plantilla 5: ¿Qu´ pasar´ si? Genera m´s reglas, con condiciones
e ıa a
diferentes.
Plantilla 6: ¿Algo m´s? Genera m´s reglas auxiliares o no contem-
a a
pladas.

Es clave tener en cuenta los aspectos no verbales del experto y distinguir sus opinio-
nes personales (sobre todo acerca de la propia ingenier´ de conocimiento e inteligencia
ıa
artificial) de la informaciń objetiva.
o

Recomendaciones
Las entrevistas deben ser peri´dicas, hacerse a las mismas horas/d´ preferible-
o ıas,
mente por la maãna temprano. Es recomendable usar el lugar de trabajo del experto
n
como lugar de reuniń, sobre todo al principio, tanto por comodidad como porque
o
tenga sus materiales a mano para consultar.
Resulta muy conveniente ir enseãndo al experto los progresos que se van haciendo.
n
Por ello, hay que “digerir” el resultado de una entrevista (realizando un informe para
repasarlo con ´l en la siguiente sesiń) antes de concertar otra.
e o

6.2.1. Entrevistas m´ ltiples
u
Un ingeniero de conocimiento y m´ ltiples expertos
u
Se da cuando los expertos trabajan en grupo o hay varios tipos de expertos. Si ´stos
e
son compatibles, esta clase de entrevistas puede proporcionar muy buenos resultados,
por el contraste de opiniones y puntos de vista, lo que asegura un mejor refinamiento y
m´s y mejor conocimiento, de m´s alto nivel, aunque si la adquisiciń de conocimiento
a a o
es de carćter general (no estructuradas), no resulta demasiado util hacer esto con
a ´
muchos expertos.
El problema se presenta si los expertos son incompatibles entre s´ en ese caso se
ı;
debe prescindir siempre de los conflictos y dividir las entrevistas. El problema puede
presentarse tambiń si es el ingeniero de conocimiento el que no es capaz de controlar
e
las sesiones (los expertos se centran en un tema, discuten de sus cosas,. . . ) o no se
puede concentrar (es muy pesado).

Laura Castro

6.3. El an´lisis de protocolos
a 59

M´ ltiples ingenieros de conocimiento y un experto
u
Nunca deber´ hacerse una entrevista con un solo experto y m´s de tres ingenieros
ıa a
de conocimiento (no apabullar). Este tipo de entrevistas resulta util cuando en el equipo
´
de trabajo contamos con ingenieros senior/junior.
La ventaja que tiene la participaciń de varios ingenieros es que se pueden evitar
o
sesgos introducidos por ellos mismos, cada uno puede aportar cosas, y no se producen
vac´ entre la adquisiciń y la implementaciń del conocimiento.
ıos o o
La desventaja suele ser que el experto es reticente, pues estas sesiones son m´s a
pesadas para ´l, aunque siempre pueden hacerse m´s cortas. Lo que como sea debe
e a
evitarse son las discusiones entre los propios ingenieros (¡mala imagen!).

M´ ltiples ingenieros de conocimiento y m´ ltiples expertos
u u
El principal inconveniente de estas entrevistas es que consumen much´
ısimo tiempo,
aunque tambiń aglutina las ventajas de las vistas anteriormente.
e
Es necesario nombrar un moderador que controle la sesiń. Es una de las opciones
o
m´s usadas.
a

En general, la tćnica de entrevistas para adquirir conocimiento es cara en tiempo,
e
en cualquiera de sus variantes. Es una tćnica introspectiva (el experto tiene que
e
pensar en lo que sabe y verbalizarlo) y requiere un esfuerzo adicional por parte del
ingeniero de conocimiento (que debe hacerse con el vocabulario, confeccionar informes,
etc).
Visto por el lado bueno, es una tćnica muy general, como hemos dicho, que se
e
puede utilizar en muchos campos y en distintas etapas del desarrollo, sin requerir para
ello un entrenamiento especial.
Es clave tener en cuenta los aspectos no verbales del experto y distinguir sus opinio-
nes personales (sobre todo acerca de la propia ingenier´ de conocimiento e inteligencia
ıa
artificial) de la informaciń objetiva.
o

6.3. El an´lisis de protocolos
a
El an´lisis de protocolos es otra tćnica de adquisiciń del conocimiento que re-
a e o
quiere algo m´s de conocimiento por parte del ingeniero de conocimiento, pero tampoco
a
un nivel excesivo.
Consiste en grabar, bien s´lo audio o combinado con v´
o ıdeo, al experto mientras
resuelve una tarea, un problema concreto del dominio, motivo por el cual no goza de
demasiada aceptaciń. Sin embargo, al poder acceder a la grabaciń cualquier ingeniero
o o
de conocimiento, se obvian algunos otros problemas de las entrevistas.
Debe quedarle claro al experto que no tiene que explicar lo que va haciendo, sino
simplemente verbalizar los pasos que est´ siguiendo. Pese a ello, el m´todo sigue siendo
a e
introspectivo.

ıa

e o

Es recomendable usar siempre m´s de una tćnica de adquisiciń del conocimiento,
a e o
y tanto las entrevistas como el an´lisis de protocolos son combinables con cualquier
a
otra.

El an´lisis de protocolos pasa por cuatro fases:
a

1. Obtenciń del protocolo.- Se dan las instrucciones al experto: verbali-
o
zar lo que dice en su cabeza durante la resoluciń del caso, sin intentar
o
explicarlo. Se pueden tomar notas.
2. Transcripciń y segmentaciń.- Escuchar/ver y transcribir lo grabado,
o o
separńdolo en frases que tengan sentido (desde el punto de vista del
a
conocimiento). No todo el mundo hace las segmentaciones igual, ni
una misma persona segmentar´ igual una transcripciń la primera
ıa o
que sucesivas veces.
3. Codificaciń.- Se identifican objetos, valores, operadores y relaciones.
o
Se obtienen las reglas expl´
ıcitas en el texto (reglas inferenciales senci-
llas).
4. Interpretaciń.- Se obtienen las reglas impl´
o ıcitas (cosas que no nos
dice directamente), se puede analizar la forma de razonar (progresivo,
regresivo,. . . ).

El problema es que un protocolo solo no nos sirve, hay que probar muchos casos.
Por esto y por su inherente dificultad, suele usarse exclusivamente en casos puntuales.

Existen variantes:

An´lisis del Recuerdo
a
Si el experto no es capaz de hablarnos mientras resuelve el problema,
puede permit´ ırsele verbalizar el proceso al finalizarlo.
An´lisis de las dos Fases
a
Consiste en comparar resultados con el propio experto en la fase de
codificaciń.
o
An´lisis del Registro
a
Aãde una entrevista al final del proceso.
n
An´lisis de Casos Dif´
a ıciles
En vez de cualquier caso, se resuelven casos concretos de dificultad
espec´
ıfica.

Ventajas
El flujo de informaciń es unidireccional (en entrevistas era bidireccional), del
o
experto al ingeniero de conocimiento, por lo que se minimizan las interacciones.
El protocolo puede ser analizado por tantos ingenieros de conocimiento como sea
necesario.

Laura Castro

6.4. Cuestionarios 61

Permite adquirir conocimiento que es dif´ de adquirir mediante entrevistas
ıcil
(aspectos relacionados con la estrategia de razonamiento que usa el experto, algo
inconsciente que aqu´ queda reflejado).
ı

El experto es el reactivo limitante.

Inconvenientes
Se pueden introducir sesgos (igual que en las entrevistas) inconscientes.

Es una tćnica muy costosa en tiempo (el experto debe aprender a hacer el an´lisis
e a
de protocolos —que no razone sino que acté—), y es muy larga y pesada para el
u
ingeniero de conocimiento (sobre todo si no tiene experiencia), que debe realizar
la transcripciń, segmentaciń, etc.
o o

Es una tćnica introspectiva.
e

6.4. Cuestionarios
Los cuestionarios son una tćnica m´s o menos sencilla que consiste en presentar
e a
al experto una serie de fichas u hojas con preguntas concretas (de ah´ su utilidad).
ı

Ventajas
Flujo unidireccional.

El experto puede contestar el cuestionario cuando desee y donde decida (suelen
aceptarla con agrado gracias a esto), por lo que no hay problemas referentes a
concierto de reuniones, horarios, etc.

Consume menos tiempo que las otras tćnicas vistas hasta ahora.
e

Es util para describir objetos, jerarqu´ certidumbres, relaciones del dominio,. . .
´ ıas,

Inconvenientes
Su elaboraciń no es sencilla.
o

Es una tćnica introspectiva.
e

6.5. An´lisis del movimiento de ojos
a
El an´lisis del movimientode ojos es una tćnica de adquisiciń del conocimien-
a e o
to que s´lo se puede usar en los campos en que sea necesario un reconocimiento visual
o
del problema por parte del experto (existe un aparato —Eye Mark Recorder — que
registra la direcciń, posiciń y duraciń de la mirada).
o o o

ıa

e o

Los datos que se obtienen no tienen por qu´ ser directamente trasladables al siste-
e
ma/dominio, aunque s´ pueden dar informaciń sobre el comportamiento del experto,
ı o
siendo as´ un buen punto de partida. Puede ser clave para descubrir la diferencia entre
ı
lo que se hace y lo que hay que hacer (que suele ser lo que el experto comunica).
Es una tćnica no introspectiva, cuyo principal inconveniente es su carest´
e ıa.

6.6. M´todo de observaciń directa
e o
Esta tćnica de adquisiciń del conocimiento es siempre recomendable. La obser-
e o
vaciń directa consiste en acudir al lugar de trabajo del experto y observar all´ su
o ı
comportamiento.
Su inter´s reside en que se ve lo que realmente pasa, eliminando las interpretacio-
e
nes subjetivas sobre el trabajo del experto. Es un m´todo no introspectivo, aunque
e
siempre se pueden hacer preguntas y, por supuesto, tomar notas. Puede ser interesante
concertar una entrevista despu´s para aclarar dudas.
e
Su objetivo fundamental es captar conocimiento procesal, siendo util para refinar el
´
sistema (no en conocimiento, pero s´ a lo mejor en aspectos relacionados con la interfaz,
ı
por ejemplo). Su principal inconveniente, la gran cantidad de tiempo del ingeniero de
conocimiento que consume, aunque no afecta en absoluto al experto.

6.7. Extracciń de curvas cerradas
o
Esta tćnica suele usarse en campos en los que el conocimiento visual es impor-
e
tante, siendo especialmente interesante cuando existen relaciones espaciales entre los
elementos del dominio, que se desean extraer.
Consiste en confeccionar cartulinas con representaciones de los objetos del dominio
(hasta un m´ximo, por ejemplo, 50) y pedir al experto que relacione, rodeńdolos,
a a
encerrńdolos en un c´
a ırculo, aqu´llos que segń su criterio formen patrones, aparezcan
e u
ligados, tengan caracter´
ısticas similares, etc. Esta fase puede repetirse cuantas veces se
desee, aplicando distintos criterios.
Es obvio que el conocimiento obtenido por medio de la extracciń de curvas
o
cerradas puede no ser directamente trasladable al sistema experto, pero sin duda,
ayuda en el proceso de establecimiento de relaciones entre los conceptos del dominio
y/o para obtener clasificaciones.
Es una tćnica bastante fćil de utilizar para el ingeniero de conocimiento, aunque
e a
requiere conocer con relativa profundidad el campo en que trabajamos y puede aparecer
el problema de que el criterio de clasificaciń sea dif´ de explicitar por parte del
o ıcil
experto.

6.8. Las tćnicas de escalamiento psicol´gico
e o
Las tćnicas de escalamiento psicol´gico son una serie de m´todos semiau-
e o e
tom´ticos de adquisiciń de conocimiento que constituyen el conjunto de los m´s usados
a o a

Laura Castro

e o 63

en IC. Todas ellas tienen el mismo formato de datos a la entrada, una matriz triangular
superior :

E1 E2 E3 . . . En
E1 0 d12 d13 . . . d1n
E2 0 d23 . . . d2n
.
. .. .
.
. . .
En−1 0 d(n−1)n
En 0

donde dij son juicios de distancia que representan c´mo se parecen/diferencian
o
los elementos i y j del dominio.
Las salidas de los tres m´todos de escalamiento psicol´gico que veremos son distin-
e o
tas, pero siempre estń igual formateadas (la misma entrada y datos producen siempre
a
la misma salida), y hay una relaciń constante entre ellas.
o

No obstante, la aplicaciń de estas tćnicas no es sencilla, pues la parte manual,
o e
encargada de adquirir los elementos del dominio (del experto, mediante entrevistas)
es muy importante: el conjunto de elementos debe ser completo y consistente, o de lo
contrario el conocimiento que se obtenga ser´ incompleto, incorrecto y/o inconsistente,
a
ya que las distancias estń condicionadas por el contexto de propios elementos. En el
a
otro extremo, elegir demasiados se enfrentar´ con la negativa y/o imposibilidad del
a
experto de calcular todas las distancias.
n(n − 1)
Una vez que se tienen los elementos del dominio, hay que obtener las dis-
2
tancias (si n es el n´mero de elementos a manejar). Para ello existen tćnicas auxiliares
u e
para suplir el hecho de tener que mostrar al experto la tabla directamente:
√
Clasificaciones: consisten en dibujar fichas que representen los elemen-
tos del dominio y pedir al experto que haga grupos disjuntos con ellos,
repitiendo el proceso en varias ocasiones utilizando distintos criterios.
La distancia entre dos elementos ser´ entonces el inverso del n´mero
a u
de veces que esos dos elementos se clasificaron juntos.
√
Emparrillado: es un m´todo matem´tico semiautom´tico para calcular
e a a
las distancias que veremos en m´s profundidad.
a

6.8.1. Escalamiento multidimensional (EDM )
Existen programas estad´ısticos que contienen herramientas para llevar a cabo un
escalamiento multidimensional sobre un conjunto de datos. El EDM intenta colocar los
elementos de la matriz en un espacio de la menor dimensionalidad posible, reduciendo
al m´ximo la dimensionalidad de la matriz.
a
El problema que tiene es que a veces no es fćil interpretar los resultados, y si la
a
salida tiene m´s de 3 dimensiones no se puede representar.
a

ıa

e o

Coruna Lugo Santiago Orense P ontevedra V igo
Coruna 0 90 60 170 130 150
Lugo 0 120 110 190 210
Santiago 0 120 70 90
Orense 0 100 100
P ontevedra 0 20
V igo 0

Latitud Longitud
Coruna 75 −20
Lugo 40 60
Santiago 20 −20
Orense −60 80
P ontevedra −55 −20
V igo −75 −20

Coruña
Lugo
Santiago

Orense
Pontevedra

Vigo

Cuadro 6.4: Ejemplo de aplicaci´n de EDM.
o

Laura Castro

e o 65

Adem´s, existen infinitas salidas, porque el m´todo s´lo fija el origen de coordenadas
a e o
y no la ubicaciń de los elementos (hay, por tanto, infinitas orientaciones, infinitas
o
rotaciones de los ejes), lo que genera la dificultad en la interpretaciń.
o
No obstante, ayuda a descompilar conocimiento de los expertos, aunque tambiń e
puede no ser directamente trasladable al sistema experto.

6.8.2. An´lisis de clusters (Clustering )
a
El clustering consiste en agrupar los elementos que estń m´s cerca entre s´ En
a a ı.
este caso, se buscan los dos elementos m´s pr´ximos, se agrupan formando un nuevo
a o
elemento, se eliminan de filas y columnas, se aãde el nuevo elemento a la matriz y
n
se recalculan las distancias con respecto al resto de elementos, repitiendo el proceso
hasta que s´lo queden dos elementos en la matriz, o bien hasta que en n´mero de clases
o u
generadas sea adecuado en nuestro dominio. El resultado final ser´ un dendrograma
a
o ´rbol jer´rquico (ver figura 6.5).
a a
La cuestiń m´s delicada en este caso es la forma de recalcular las distancias:
o a
¿c´mo lo hacemos? ¿escogiendo el m´ximo? ¿el m´
o a ınimo? ¿una media? La decisiń de-
o
pender´ de lo que sea m´s conveniente en el contexto en que estemos trabajando. Esta
a a
tćnica tambiń se incorpora en muchos paquetes estad´
e e ısticos. Adem´s, como se puede
a
observar, una vez obtenida la matriz de elementos con sus distancias, ninguna de las
tćnicas de escalamiento es introspectiva.
e

ıa

e o

E1 E2 E3 E4 E5 E6 E7
E1 10 10 7 6 13 8
E2 4 7 8 2 8
E3 9 12 3 8
E4 5 5 5
E5 6 6
E6 9
E7

E1 E3 E4 E5 E7 (E2 , E6 )
E1 10 7 6 8 10
E3 9 12 8 3
E4 5 5 5
E5 6 6
E7 8
(E2 , E6 )

E1 E4 E5 E7 ((E2 , E6 ), E3 )
E1 7 6 8 10
E4 5 5 5
E5 6 6
E7 8
((E2 , E6 ), E3 )

E1 (E4 , E5 ) E7 ((E2 , E6 ), E3 )
E1 6 8 10
(E4 , E5 ) 5 5
E7 8
((E2 , E6 ), E3 )

E1 ((E4 , E5 ), E7 ) ((E2 , E6 ), E3 )
E1 6 10
((E4 , E5 ), E7 ) 5
((E2 , E6 ), E3 )

E1 (((E4 , E5 ), E7 ), ((E2 , E6 ), E3 ))
E1 6
(((E4 , E5 ), E7 ), ((E2 , E6 ), E3 ))

Cuadro 6.5: Ejemplo de clustering (I).

Laura Castro

e o 67

7

6

5

4

3

2

1

E1 E4 E5 E7 E2 E6 E3

Figura 6.5: Ejemplo de clustering (y II): dendrograma.

ıa

e o

El clustering permite elicitar muy r´pido conocimiento muy jerarquizado en la
a
mente del experto. Es util tambiń para validaciń, para construcciń de interfaces
´ e o o
hombre-m´quina (comparaciń de opiniones sobre la importancia de diferentes aspec-
a o
tos), para comprobar el nivel de nuestro sistema frente a los expertos, e incluso para
verificar si las respuestas de un grupo de expertos estń al mismo nivel.
a

6.8.3. Redes ponderadas (Pathfinder )
Esta ultima es la menos usada de las tres tćnicas de escalamiento psicol´gico que
´ e o
vamos a ver. Su salida, como su propio nombre indica, es una red ponderada en la que
los nodos son los elementos del dominio y los arcos que los unen aparecen ponderados
por un peso que es la distancia que los separa. S´lo existir´ un arco entre dos nodos si
o a
la distancia entre ellos a trav´s de cualquier camino es mayor que el valor especificado
e
entre ambos en la matriz de entrada:

E1 E2 E3
E1 4 5
E2 13
E3
4 E2
E1

5

E3

E1 E2 E3
E1 4 5
E2 6
E3
4 E2
E1

5
6
E3

Cuadro 6.6: Ejemplo de redes ponderadas.

El pathfinder es muy util si la representaciń del conocimiento en nuestro sistema
´ o
utiliza algń tipo de red (por ejemplo, una red semńtica), ya que la traducciń de
u a o
conocimiento del dominio es entonces mucho m´s directa.
a

Laura Castro

6.9. La teor´ de constructos personalizados: el Emparrillado
ıa 69

En general, las ventajas del escalamiento psicol´gico son que proporciona conteni-
o
do y a veces incluso arquitectura a nuestra base de conocimientos. Permiten comparar
conocimientos, opiniones y criterios de varios expertos sobre un mismo conjunto de ele-
mentos, adem´s de proporcionar un m´todo riguroso para combinar conocimiento que
a e
procede de distintos expertos o incluso del cliente. No son tćnicas demasiado intros-
e
pectivas (salvando la etapa de determinaciń de elementos y distancias entre ellos), y
o
estń libres de cualquier interpretaciń que pudiese ser incluida por parte del ingeniero
a o
de conocimiento. La salida es estńdar y tiene un formato riguroso, lo que hace que
a
diferentes ingenieros de conocimiento con distintos expertos deban obtener los mismos
resultados, algo que es un buen paso hacia la reutilizaciń (adem´s de permitir la auto-
o a
matizaciń). Por ultimo, son utiles no s´lo en adquisiciń sino tambiń en validaciń
o ´ ´ o o e o
y construcciń de interfaces de usuario.
o

En cuanto a los inconvenientes, cada tćnica tiene los suyos. En general, los
e
elementos y las distancias poseen un proceso de obtenciń no trivial. Como hemos
o
visto, los EDM no son fćiles de interpretar y si su salida es gr´fica no es sencilla de
a a
etiquetar. En clustering puede no ser directo decidir qu´ criterio (m´ximo, m´
e a ınimo,
media) escoger para el rec´lculo de distancias, al igual que en redes semńticas.
a a
Si se usa una herramienta, debemos familiarizarnos con ella; hay que tener una
base matem´tico-estad´
a ıstica para poder saber si es correcto lo que hacemos y saber
interpretarlo. Por ultimo, si no existe una estructura de ligazń fuerte entre elementos,
´ o
o no hay estas relaciones, estas tćnicas son in´tiles.
e u

6.9. La teor´ de constructos personalizados:
ıa
el Emparrillado
La siguiente tćnica que veremos, denominada tćnica de constructos perso-
e e
nalizados o emparrillado (repertory grid), no es propiamente una tćnica de ad-
e
quisiciń de conocimiento, sino m´s bien un m´todo auxiliar de clasificaciń. En la
o a e o
prćtica se usan herramientas que la implementan, que interrogan al usuario sobre los
a
elementos del dominio, sus relaciones, etc. con el fin de estructurar el conocimiento del
experto de una determinada manera (es pues, un m´todo semiautom´tico). Nosotros
e a
estudiaremos su funcionamiento interno.
El emparrillado fue desarrollado inicialmente por George Kelly, un psic´logo cl´
o ınico
que defend´ que cada persona organiza sus conocimientos de una manera distinta
ıa
y adem´s cambiante con el tiempo, y reflejaba las opiniones de las personas sobre
a
las cosas en forma de constructos personalizados. Su modelo cognitivo utilizado
para razonar con dichos constructos ser´ m´s tarde aplicado por Shaw y Griness a
ıa a
la IC (SS.EE. Planet, 1982), siendo as´ una de las primeras tćnicas de aproximaciń
ı e o
autom´tica para tratar el problema de la adquisiciń del conocimiento.
a o
Al estar basada en un modelo del pensamiento humano, esta es una tćnica muy
e
potente que sirve para tener estructurado y accesible el conocimiento de una persona.
Incluye un di´logo inicial con el experto, una sesiń de valoraciń y un an´lisis de los
a o o a
resultados (es decir, de los grupos, los conceptos y las dimensiones).

ıa

e o

Se utilizan dos vertientes: tćnicas binarias, que permiten clasificaciń simple, y
e o
multivaluadas, que proporcionan una clasificaciń m´s rica, al ser continua, dando op-
o a
ciń a la inclusiń de nociones de incertidumbre e incluso conjuntos difusos.
o o

Este m´todo posibilita la obtenciń de informaciń que el experto no es consciente
e o o
que conoce (no es introspectiva, por tanto, salvo en su etapa inicial, aunque puede
considerarse que es intrusiva, pues desvela al experto eso que no es consciente que
sab´ Por otra parte, matem´ticamente, la parrilla es una aplicaciń de los elementos
ıa). a o
del dominio en un conjunto de caracter´ ısticas. Como podemos intuir, la primera fase,
de obtenciń de elementos y caracter´
o ısticas (constructos: [ci , ci ]) es el momento m´s
¯ a
peliagudo, aunque posteriormente existen f´rmulas y ecuaciones que ayudan a eliminar
o
redundancias e informaciones poco significativas (juicios de umbrales, etc).

Una parrilla es una matriz donde las columnas son los elementos del dominio y
las filas representan los constructos, que son caracter´
ısticas en las que deseamos cla-
sificar. Dichos constructos son bipolares, representando una oposiciń de conceptos,
o
sirvińdonos la matriz para ver c´mo piensa el experto, c´mo se organiza.
e o o

Ei
cj vij ... cj
¯

donde
Ei son los elementos del dominio identificados por el experto
cj , cj
¯ son, respectivamente, caracter´
ısticas y su contrapartida en
el dominio (su opuesto l´gico)
o
y
vij son los valores que se corresponden por la relaciń entre
o
unos y otros.
Cuadro 6.7: Esquema de una parrilla.

El emparrillado consta de cinco fases diferenciadas:

1. Identificaciń de elementos (Ei ).
o
2. Identificaciń de caracter´
o ısticas (cj ).
3. Diseõ de la parrilla.
n
4. Formalizaciń de la parrilla.
o
5. Interpretaciń de resultados.
o

6.9.1. Identificaciń de elementos Ei
o
Como ya vimos en escalamiento psicol´gico, los elementos del dominio se obtienen
o
mediante entrevista con el experto y debe lograrse un conjunto completo, consistente
y representativo. Las sesiones pueden ser m´s o menos h´biles, pero los elementos
a a

Laura Castro

ıa 71

obtenidos deben ser homogńeos, representativos y tener en cuenta que no es util
e ´
manejar parrillas demasiado amplias, aunque se pueden manejar varias, lo que tambiń
e
plantea la cuestiń de c´mo “segmentar” los elementos (normalmente, se agruparń en
o o a
una misma parrilla los m´s homogńeos a su vez entre s´
a e ı).

6.9.2. Identificaciń de caracter´
o ısticas cj
Las caracter´ısticas se obtienen de la misma manera que los elementos. Deben po-
der expresarse como un par de conceptos antagńicos, con el fin de poder manejar
o
un segmento clasificatorio. No tienen por qu´ ser uno el polo negativo del otro, pero
e
s´ su negaciń l´gica en el contexto del dominio. Si el experto no fuese luego capaz de
ı o o
clasificar utilizando los conceptos establecidos ser´ indicativo de que ´stos estń mal
ıa e a
elegidos, no son los que ´l usa, le estar´
e ıamos obligando a clasificar segń otros cńones,
u a
de manera que habr´ que replante´rselos.
ıa a

Para llevar a cabo la selecciń de caracter´
o ısticas se usa normalmente el m´todo de las
e
tr´
ıadas , que consiste en tomar los elementos del dominio de tres en tres y presentarlos
al experto, con la propuesta de que enuncie una caracter´ ıstica que diferencia a dos
de ellos del tercero. Se ha estudiado que cognitivamente este sistema de elecciń es o
mucho m´s eficaz, pues el hecho de que se muestren tres elementos evita sesgos que se
a
producir´ con dos y ayuda a elaborar los constructos por oposiciń y no por negaciń.
ıan o o
No obstante, tambiń se puede utilizar extracciń de curvas cerradas, que ya vimos,
e o
e incluso simplemente entrevistas. Siempre es mejor la tćnica de las tr´
e ıadas, pero se
puede simultarear con alguna de ´stas (o con ambas) para contrastar, pues siempre
e
alguna puede funcionar mejor que otra con segń qu´ expertos.
u e

6.9.3. Dise˜ o de la parrilla
n
Una vez obtenidos elementos del dominio y caracter´ ısticas (constructos), hay que
dar valor a la parrilla. Hay varias formas de construirla, que citamos a continuaciń de
o
menos a m´s usada:
a

Dicot´mica
o
Se clasifica cada Ei dependiendo de si “tiene” o no cj (asignaciń
o
binaria).
Clasificatoria
Se clasifican los n Ei en un intervalo 1..n de forma que vij ∈ [1, n] repre-
senta el orden del elemento con respecto al constructo (su proximidad
al constructo). Se obtiene de esta manera una escala de clasificaciń o o
vector clasificador.
Evaluativa
Se elige una escala que se adapte a los elementos y se les clasifica segń
u
ella, pudiendo repetirse valores. Representa c´mo ve el experto al ele-
o
mento dentro de ese constructo, no siendo en este caso una escalaciń o
de elementos.

ıa

e o

Estos distintos m´todos de diseõ de la parrilla no son excluyentes, de hecho, los
e n
resultados deber´ ser compatibles independientemente de qu´ forma de construcciń
ıan e o
us´semos. En general, siempre es preferible una aproximaciń por rangos a una bina-
a o
ria, ya que hay tćnicas de aplicabilidad posterior que no son compatibles con datos
e
bipolares.

6.9.4. Formalizaciń
o
Una vez diseãda la parrilla, tenemos una matriz en la que las filas nos muestran
n
c´mo var´ una caracter´
o ıa ıstica de un elemento a otro, y las columnas c´mo se compor-
o
tan los elementos en el dominio (segń las caracter´
u ısticas seleccionadas). Es decir, la
tabla indica la participaciń de un elemento en una caracter´
o ıstica: por columnas, la
participaciń de un elemento en todas las caracter´
o ısticas, y por filas, la participaciń
o
de todos los elementos en una determinada caracter´ ıstica (constructo):

E1 ... Ei
c1 v11 ... vi1

.
. .
. ...
. .

cj v1j ... vij
La parrilla ha de explorarse en dos sentidos, horizontal y vertical, para obtener
dos ´rboles jer´rquicos, uno de elementos y otro de caracter´
a a ısticas, y ver c´mo estń
o a
relacionados. Esta fase puede automatizarse completamente.

Clasificaciń de elementos
o
Analizando la matriz por columnas (elementos), calculamos distancias entre ele-
mentos para obtener un ´rbol:
a

E1 E2 E3 . . . E8
c1 2 3
c2 2 2
c3 4 5
c4 5 4
c5 5 5 ...
c6 4 4
c7 2 2
c8 4 2
c9 1 1
asumiendo un rango [1.,5], hay varias formas de calcular las distancias, pero la que
se suele usar es la suma de diferencias en valor absoluto de los valores de los elementos
para cada caracter´ ıstica:

Laura Castro

ıa 73

d(E1 , E2 ) = d(E2 , E1 ) = 1 + 0 + 1 + 1 + 0 + 0 + 0 + 2 + 0 = 5
De esta manera se obtiene una matriz triangular superior de distancias entre ele-
mentos, y para construir el ´rbol (dendrograma) se siguen los pasos que ya vimos en
a
escalamiento psicol´gico: se buscan los dos elementos m´s pr´ximos, se eliminan de la
o a o
tabla, se agrupan, se recalculan distancias,. . . ).

Clasificaciń de caracter´
o ısticas
Para las caracter´
ısticas tambiń se va a obtener un ´rbol clasificatorio, pero en esta
e a
ocasiń, como manejamos dos polos, tendremos que calcular dos distancias:
o

E1 E2 E3 E4 E5 E6 E7 E8
Manejable 2 3 5 2 5 3 3 2 No manejable
Deportivo 2 2 2 1 5 2 3 1 No deportivo
¯
Deportivo 4 4 4 5 ¯
1 4 3 5 N odeportivo

.
.
. ...

La regla de c´lculo es la misma:
a

d1 (ci , cj ) = 0 + 1 + 3 + 1 + 0 + 1 + 0 + 1 = 7
d2 (ci , cj ) = d1 (ci , cj )
¯
d2 (ci , cj ) = 2 + 1 + 1 + 3 + 4 + 1 + 0 + 3 = 15
donde cj se calcula a partir de cj . Si se aplic´ una construcciń dicot´mica al
¯ o o o
elaborar la parrilla, simplemente se cambian los “polos” (se otorgan los valores com-
plementarios); si fue clasificatoria, se invierte el orden, y si fue evaluativa, se sigue
misma din´mica que en el siguiente ejemplo:
a

cj 1 2 3 4 5
cj
¯ 5 4 3 2 1
Una vez calculadas las dos distancias para cada par de caracter´
ısticas por elemento,
tendremos una matriz construida de la siguiente forma:

E1 E2 ... En
..
c1 . d1 (ci , cj ) c1
¯
c2 c2
¯

.
. ..
. d1 (ci , cj ) = d2 (ci , cj )
¯ .

..
ci . ci
¯

ıa

e o

donde la submatriz superior son las distancias “directas” (d1 ) y la submatriz infe-
rior, las distancias “inversas” (d2 ).

El paso a una matriz triangular superior se consigue eligiendo la distancia m´ ınima
de las dos (d1 , d2 ), y a partir de ah´ para obtener el dendrograma el proceso es el que
ı
ya conocemos.

6.9.5. An´lisis y estudio de los resultados obtenidos
a
Fundamentalmente, debemos analizar los ´rboles de elementos y caracter´
a ısticas.
Estudiando el primero de ellos, los problemas posibles que podemos encontrar son:
√
Dos elementos estń muy juntos en el ´rbol y el experto afirma que
a a
no deber´
ıan.
→ Debemos comprobar que los valores de la parrilla son correctos y
que los c´lculos estń bien hechos.
a a
→ Falta una caracter´ıstica diferenciadora en la parrilla.
√
Dos elementos estń muy separados en el ´rbol y el experto afirma
a a
que no deber´
ıan.
a a
→ Falta una caracter´ıstica conciliadora en la parrilla.
√
Dos caracter´
ısticas (constructos) aparecen muy ligadas y no deber´
ıan,
segń el experto.
u
a a
→ Falta un elemento diferenciador (que participa de una y no de la
otra) en la parrilla.

Por su parte, en el ´rbol de caracter´
a ısticas se estudian tambiń las caracter´
e ısticas
por pares, empezando por las m´s pr´ximas, buscando relaciones entre ellas. El objetivo
a o
es afinar el polo.

Paralelas
Son caracter´
ısticas (A, B) y (X, Y ) que se comportan:

A → X
B → Y

como por ejemplo (F amiliar, Coupe) y (Habitable, N oHabitable), ya
que
F amiliar → Habitable
Coupe → N oHabitable

Laura Castro

ıa 75

sin embargo
Habitable F amiliar
N oHabitable Coupe
En estos casos, de acuerdo con el experto, se pueden resumir ambas
caracter´
ısticas en una que mantenga este comportamiento.
Rec´
ıprocas
Son caracter´

A ↔ X
B ↔ Y

como se da por ejemplo en el caso de (GranCilindrada, P ocaCilindrada)
y (P otente, P ocoP otente), pues

GranCilindrada ↔ P otente
P ocaCilindrada ↔ P ocoP otente

En estos casos las caracter´
ısticas son t´
ıpicamente redundantes, puede
eliminarse una de ellas o resumir ambas en una nueva.
Ortogonales
Son caracter´

A → X
A Y
A → X
o
B Y
B → X
B Y

como por ejemplo (Deportivo, N oDeportivo) y (N ervioso, P esado),
ya que
Deportivo → N ervioso
Deportivo P esado
N oDeportivo N ervioso
N oDeportivo P esado
En este caso o bien uno de los polos implica relaci´n, o bien ambos im-
o
plican una, el caso es que alg´n polo queda “suelto” (permite eliminar
u
uno de los polos).
Ambiguas
Son caracter´

A → X
A → X
A → Y
B → X o
B → X
B → Y
B → Y

ıa

e o

como por ejemplo (Seguro, Ligero) y (Deportivo, N oDeportivo), ya
que
Deportivo → Seguro
Deportivo → Ligero
N oDeportivo → Seguro
N oDeporitvo → Ligero

No queda muy clara la relaciń entre las caracter´
o ısticas (alguno de los
polos no est´ bien definido), se puede estudiar si es posible cambiar
a
alguna de ellas.

Tambiń se suelen construir ´rboles de por qu´ y c´mo, que sirven para obtener
e a e o
subconjuntos y superconjuntos de caracter´
ısticas.

Deportivo

BuenaVelocidad Rapido Potente Nervioso BuenFreno

(a) Ejemplo de ´rbol por qu´.
a e

Viajero
(Familiar)

Confortable Seguro

Silencioso Habitable BuenaSuspension Frenos Carroceria Repris

(b) Ejemplo de ´rbol c´mo.
a o

El emparrillado es, por tanto, como ya hemos dicho, util en clasificaciń o para
´ o
catalogar expertos. Ayuda tambiń en ´mbitos de incertidumbre, o a la validaciń.
e a o
Sus problemas residen en que los datos aportados por el experto son subjetivos, per-
sonales (surgirń distintas parrillas con diferentes expertos; el grado de distanciamiento
a
entre ellos marca su nivel de similitud).

Laura Castro

6.10. Tćnicas especiales de adquisiciń de conocimiento en grupo
e o 77

6.10. Tćnicas especiales de
e
adquisiciń de conocimiento en grupo
o
Para cerrar este cap´
ıtulo hablaremos de una serie de tćnicas especiales a usar cuan-
e
do queremos trabajar con un grupo de expertos al mismo tiempo.

Sus ventajas e inconvenientes ya fueron mencionados cuando hablamos de las en-
trevistas m´ltiples (p´gina 58): el precio de obtener una bases de conocimiento m´s
u a a
completas y tener la seguridad de que se han tratado todos los aspectos relevantes del
dominio/problema es la introspecciń y el esfuerzo general por ambas partes.
o

Las tćnicas de adquisiciń de conocimiento en grupo m´s destacables son:
e o a
1. Tormenta de ideas (brainstorming).
2. Tćnica nominal de grupo.
e
3. M´todo Delphi.
e
4. Entrevistas.
5. Emparrillado.
6. Escalamiento psicol´gico.
o

6.10.1. Tormenta de ideas (Brainstorming )
En adquisiciń del conocimiento, para aplicar esta popular tćnica, basada en la
o e
opiniń sajona de que la cantidad mejora la calidad, intentaremos tener varios tipos
o
de expertos e ingenieros de conocimiento, que expondrń sus ideas (con una breve
a
explicaciń) sin ningń tipo de cr´
o u ıtica. Suele ser favorable la presencia de un moderador
y su utilidad es manifiesta en dominios en los que se requiere inventiva.
Una vez recopiladas las ideas, se llevan a cabo una serie de cribas. Las primeras se
suelen basar en la aplicabilidad inmediata de la soluciń propuesta, el ajuste con res-
o
pecto a restricciones existentes (de tiempo, de coste,. . . ), la compatibilidad con otros
aspectos del problema (que no supongan conflictos con otros elementos ya implemen-
tados/implantados, etc). Reducida la lista, en ultimo caso se puede elegir la definitiva
´
por votaciń.
o

6.10.2. Tćnica nominal de grupo
e
Esta tćnica es exactamente igual que la anterior, pero en ella las ideas se exponen
e
por escrito. Es mejor cuando hay gente t´ ımida en el grupo, o que no acepta cr´ ıticas,
aplicable fundamentalmente cuando se trata con poca gente.

6.10.3. M´todo Delphi
e
El m´todo Delphi tambiń es un m´todo por escrito, basado en cuestionarios con-
e e e
feccionados por los ingenieros de conocimiento sobre aspectos del problema que se
presentan a distintos tipos de expertos.

ıa

e o

Los expertos responderń el cuestionario de forma anńima, y tambiń a un cues-
a o e
tionario sobre los cuestionarios (¿son las preguntas relevantes? ¿importantes? ¿sobran?
¿faltan? ¿cu´les?). Esto ayuda a refinarlos, acometiendo una segunda vuelta acom-
a
paãda de los resultados de la anterior (media y varianza —primer y tercer cuartil—).
n
Se repite iterativamente (aunque con dos vueltas suele ser suficiente) hasta obtener una
respuesta m´s o menos homogńea —acuerdo—. Si existen dispersiones importantes,
a e
habr´ que pasar a algo no anńimo para identificar el problema, aunque no suele ser
ıa o
necesario.

Laura Castro

Cap´
ıtulo 7

Evaluaciń de los sistemas basados
o
en conocimiento

La evaluaciń de los Sistemas Basados en Conocimiento consta de 4 aspectos que
o
podemos estudiar:

Verificaciń
o
Trata de estudiar la correcciń formal de nuestro sistema, algo que
o
puede hacerse tanto durante el desarrollo como al final del mismo.
De los cuatro aspectos, es el unico criterio est´tico. La mayor´ de
´ a ıa
las herramientas, como por ejemplo Nexpert incluyen correcciń de
o
sintaxis.
Validaciń
o
Se trata de ver si el sistema es correcto, si contempla todos los casos,
si el modelo computable es v´lido. Para poder realizarse, el sistema
a
debe estar funcionando, por tanto. No es suficiente realizar validacińo
por m´dulos, es imprescindible una prueba global integrada.
o
Usabilidad
Usabilidad y Utilidad son conceptos relativamente recientes, influencia
de la ingenier´ del software. El primero representa la satisfacciń que
ıa o
tiene el usuario con el sistema, la interfaz, el tipo de respuestas, su
redacciń, adecuaciń a su nivel, etc. Es, pues, un criterio din´mico
o o a
(el sistema debe estar funcionando).
Utilidad
Por ultimo, la utilidad es un criterio tambiń din´mico que intenta
´ e a
analizar el cambio/mejoras que se producen en el entorno/empresa en
que se introduce el sistema, ver si satisface las expectativas. Se repasan
las propuestas realizadas con el modelo de organizaciń/contextual
o
(motivos que impulsaron al desarrollo del sistema) y se comprueba si
se han cumplido.

79

80

¿VALOR
DE UN
CRITERIO?

Laura Castro
Correccion Validez Usabilidad Utilidad

Criterios
Inspeccionar y Revisar Comparar Uso del sistema por
el modelo formal Hacer resolver el sistema con parte del usuario Realizacion del trabajo
o computable al sistema un caso los requisitos segun un escenario rutinario con el nuevo
en busca del error de prueba establecidos al inicio y expresion de su tandem: usuario +
sintactico establecido de la construccion opinion software

e
o

Opinion del usuario Comparacion con la
situacion anterior

Tecnicas de Valoracion
sobre el criterio
a la instalacion del software

se no se no fue fue capaz el sistema el sistema La nueva La nueva

o
encontraron encontraron capaz de tratar no cumple cumple los ¿V minimo? situacion situacion no
errores errores de tratar el caso los requisitos es mejor es mejor
el caso requisitos

Posibles Valores
corregir seguir con la ampliar la respuesta la respuesta reformar seguir con la reformar seguir el proyecto el proyecto

Figura 7.1: Tćnicas de valoraciń para SS.EE.
la sintaxis construccion los no fue exacta fue exacta el sistema construccion el sistema con la ha sido un no ha sido
conocimientos o la construccion exito un exito
interface

ajustar los seguir
conocimientos con la
Apuntes – 7. Evaluaciń de los sistemas basados en conocimiento

construccion

Actuacion tras la evaluacion

PLANO DE LA REALIDAD
PRACTICA
REAL
ORGANIZACION

Sw+Usuario
UTILIDAD

Utilidad:
Usabilidad:
Validacion:
Verificacion:
REALIDAD

o
CONTROLADA
Casos USUARIO
de Requisitos
Prueba Sw
USABILIDAD

Amplia el entorno al usuario.
VALIDACION VALIDACION
(Completitud (Correspondencia)

Aspectos mas internos del sistema.
y Exactitud)

Valora el sistema en el mundo exterior.
Modelo Modelo Modelo
Conceptual Formal Computable

Aspectos del contexto en un entorno "controlado".

ıa
o
VERIFICACION

Figura 7.2: Relaci´n entre los distintos tipos de evaluaci´n.
(Redundancia, Incompletitud, Inconsistencia)

PLANO DE LA CONSTRUCCION

81

82 Apuntes – 7. Evaluaciń de los sistemas basados en conocimiento
o

7.1. Verificaciń y validaciń
o o
7.1.1. Sistemas de verificaciń autom´tica
o a
Todos las pruebas de verificaciń de software estńdares que existen en ingenier´
o a ıa
del softwae son aplicables a los SBC y SSEE, aunque son necesarias algunas a mayores.
Existen, como hemos mencionado, herramientas que proporcionan verificaciń simple
o
de estructuras, principalmente sintćtica. La mayor´ de los sistemas de verificaciń
a ıa o
autom´tica son para sistemas basados en reglas y suelen controlar:
a
Inconsistencias.- Pueden aparecer por propio error o al trabajar varios
ingenieros sobre una misma base de conocimientos.
Base Conocimientos + Base Hechos ⇒ P ∧ ¬P
atributo(a, x) ∧ atributo(a, y) ⇒ C

Redundancias.- Pueden ser o no determinantes (puede haber que elimi-
narlas o ser correctas/necesarias en nuestro sistema), reduciendo sobre
todo la eficiencia.
Ri ) α ⇒ β
Ri ) α ⇒ β Rj ) β ⇒ γ
Rj ) α ⇒ β Rk ) γ ⇒ θ
Rr ) α ⇒ θ

Subsunciń.- Si las conclusiones de dos reglas son iguales y las premisas
o
de las condiciones son una un subconjunto de la regla se dice que hay
subsunciń. Es decir, una regla est´ subsumida en otra si ambas tienen
o a
la misma conclusiń y las premisas de una son un subconjunto de las
o
premisas de la otra (que es m´s general). Igual que en el caso anterior,
a
pueden querer eliminarse o no, dependiendo del caso.
Cadenas circulares.- Son situaciones del tipo:
α ∧ η0 ⇒ β1
η0 ∧ β1 ⇒ β2
...
ηn−1 ∧ βn ⇒ α

Reglas no disparables.- Si las premisas que tiene una regla nunca son
una conclusiń de otra ni son hechos iniciales, la regla en cuestiń nun-
o o
ca se activar´. Con frecuencia es un error debido a que se escribi´ mal
a o
esa regla o por falta de conocimiento (m´s reglas).
a
Conclusiones no alcanzables.- Si la conclusiń de una regla no es parte
o
de un antecedente de otra regla (por ejemplo, en encadenamiento re-
gresivo) nunca se llegar´ a ella. Igual que en el caso anterior (de hecho,
a
se pueden considerar un tipo especial de reglas no disparables), o bien
est´ mal escrita, o bien falta conocimiento.
a

Laura Castro

o o 83

Completitud.- Si la base de conocimientos no est´ completa puede dar-
a
se la situaciń en que no hayamos alcanzado ninguna conclusiń y
o o
tampoco quede ninguna regla por ejecutar.
Hay cuatro tipos principales de sistemas de verificaciń autom´tica:
o a
√
Sistemas de verificaciń tabular: se basan en la colocaciń de las reglas
o o
en tablas, agrupńdolas por las conclusiones (en una misma fila, la
a
primera columna contiene una conclusiń ci y la segunda, las reglas
o
que concluyen algo sobre ci ), para comprobar posteriormente, dos a
dos, la estructura de dichas reglas, pudiendo as´ detectar redundancias
ı
e incluso inconsistencias (si adem´s de ci tienen en cuenta la negaciń
a o
de ci ).
√
Sistemas de propagaciń de restricciones: toman un conjunto de he-
o
chos iniciales e intermedios lo m´s completo posible y lo propagan
a
por el sistema a trav´z de sus restricciones, comprobando el resultado
e
(analizando si hay redundancias, etc).
√
Sistemas de verificaciń basados en redes de Petri: combierten la base
o
de conocimientos de reglas en una red de Petri , en la que hip´tesis y
o
conclusiones son nodos y las transiciones representan reglas. Estas re-

A
R1

G
B

Figura 7.3: Ejemplo de red de Petri.

des sirven para comprobar la accesibilidad de las conclusiones, ya que
son expresables en forma de sistemas de ecuaciones lineales. Adem´s, a
una vez se dispone del sistema de ecuaciones, si se introduce una in-
consistencia y el sistema tiene soluciń, significa que el sistema tiene
o
inconsistencias (est´ mal); por el contrario, si no la tiene, es que el
a
sistema es correcto.
El peor inconveniente de este tipo de sistemas de verificaciń es que
o
su complejidad es exponencial, aunque a pesar de ello son de los m´s a
empleados.
√
Sistemas de verificaciń basados en grafos dirigidos: a partir de la
o
base de reglas construyen un grafo dirigido en el que los nodos son los
hechos (iniciales, intermedios y conclusiones) y las reglas los arcos, de
forma que existir´ un arco si y s´lo si existe una regla que ligue ambos
a o
hechos/nodos.
A partir del grafo se calculan las matrices de adyacencia y de la traza
de la matriz se analiza si ´sta indica la existencia de caminos que no
e
se deber´ dar, se pueden detectar redundancias, circularidad, etc.
ıa

ıa

84 Apuntes – 7. Evaluaciń de los sistemas basados en conocimiento
o

7.1.2. Validaciń
o
En el proceso de validaciń es deseable que se involucre un amplio perfil de co-
o
laboradores, no s´lo los ingenieros de conocimiento desarrolladores del sistema, sino
o
tambiń los expertos y uno o varios de los usuarios finales, cuya opiniń tambiń es
e o e
importante, casi tanto como la de los propios expertos si son ellos quienes lo van a usar.

Como ya se ha mencionado, no s´lo hay que validar el resultado final (que, en el
o
peor de los casos, puede ser esp´reo), sino si cada paso, paso intermedio, consejo, etc.
u
que da el sistema lo hace de forma correcta. Tambiń es clave que la forma de razona-
e
miento sea la correcta, es decir, que el camino que sigue el sistema para llegar a una
conclusiń sea el mismo que utiliza el experto (a no ser que est´ justificado, por ejemplo,
o e
porque la forma proceder actual sea incorrecta), pues lo hace m´s usable. Asimismo es
a
importante respetar el tipo de lenguaje que se usa, las expresiones, e incluso cuestiones
como que si el usuario no entiende algo que le comunica el sistema (por ejemplo, una
pregunta), que ´ste pueda rehacer el mensaje de otra manera. Y, por supuesto, evitar
e
mensajes de error alarmantes, facilitar la recuperaciń de sesiones y asegurar los pasos
o
que se dan mediante ventanas de confirmaciń. o
Hay que ser cuidadosos en c´mo se realiza la validaciń: debe comunicarse al per-
o o
sonal involucrado cuńto se estima que va a durar (intervalo temporal realista), la
a
metodolog´ y pasos que se deberń seguir, as´ como las expectativas del proceso, evi-
ıa a ı
tando en la medida de lo posible que se convierta en una tarea tediosa.

Referencias estńdar de los SBC
a
El problema de la validaciń es que hay que hacerla con respecto a una referencia.
o
Tanto SBC como SSEE no se dedican a cosas cuyo resultado se conozca siempre per-
fectamente si es correcto o no, es decir, la necesaria referencia estńdar (tambiń
a e
llamada en ocasiones regla de Oro) puede no existir, o bien existir una referencia pero
no ser completamente estńdar, como sucede si la referencia es el experto o un grupo
a
de expertos, que pueden no estar de acuerdo y ¿c´mo se sabe quiń tiene razń? La
o e o
compensaciń que tiene disponer de varios expertos (que deber´ ser siempre de un
o ıan
mismo “nivel”) es que se puede clasificar el sistema con respecto al tipo de expertos
al que se ajusta, siendo, obviamente, preferible que no se ajuste s´lo a aqu´l que m´s
o e a
ayud´ al desarrollo del mismo.
o
En caso de definir un estńdar, debe ser realista, no se puede pretender que el sis-
a
tema vaya m´s all´ de unos determinados niveles.
a a

Para eliminar sesgos y desviaciones suelen ser utiles los estudios ciegos, en los
´
que los expertos dan su opiniń sobre respuestas del propio sistema y otros colegas, sin
o
identificar de quiń provienen, ante un problema. Sea como fuere, en toda validaciń
e o
es necesario efectuar m´s de una iteraciń.
a o
Puede suceder que haya en el sistema/contexto/problema variables m´s importan-
a
tes que otras, que necesitamos con m´s urgencia que funcionen bien, lo que puede
a
establecernos una secuencia de validaciń por prioridades, hacia el ajuste fino.
o

Laura Castro

o o 85

Otro aspecto clave es mantener los problemas relacionados con la usabilidad al
margen de los problemas identificados en la validaciń, esto es, relativos a las bases de
o
conocimiento.

M´todos de validaciń
e o
Existen dos grandes tipos de m´todos de validaciń:
e o

M´todos cualitativos
e
◦ Validaciń retrospectiva (contra casos hist´ricos).
o o
◦ Validaciń prospectiva (contra casos del d´ a d´
o ıa ıa).
◦ Test de Turing (validaciones anńimas en varias iteraciones).
o
◦ Validaciń de subsistemas semiindependientes.
o
M´todos cuantitativos (fundamentalmente m´todos estad´
e e ısticos)
◦ Tanto por ciento de acuerdo.
◦ ´
Indice kappa.

ıa

Apńdice A
e

Ampliaciones

En este apńdice se reproducen algunas de las figuras que intercalan el texto de los
e
cap´
ıtulos de estos apuntes, en un mayor nivel de detalle.

A.1. Figuras
Detalle de la figura 1.1 (p´gina 4):
a

87

88 Apuntes – A. Ampliaciones

BASE DE CONOCIMIENTOS

DECLARATIVOS
− Conocimientos del dominio
− Objetos y relaciones MOTOR DE INFERENCIAS
− Definiciones del vocabulario
− Hechos disyuntivos y/o inciertos
− Encadenamiento adelante/atras
− Situaciones tipicas: estadisticas y
− Unificacion, equiparacion
descripciones de la dinamica del
− Propagacion de restricciones
comportamiento
− Gestion de prioridades
− Suposiciones
− Agenda
− Hipotesis
− Pizarra
− Restricciones
− Razonamiento hipotetico
− Taxonomias
− Resolucion
− Induccion
OPERATIVOS o DE ACCION − Demonios
− Meta−control
− Procesos de solucion
− Gestion de incertidumbre
− Reglas operativas
− Calculos matematicos
− Heuristicas
− Ejemplos de soluciones

METACONOCIMIENTOS
− Semantica situacional
− Razonamiento de sentido comun
− Metarreglas
− Aprendizaje
− Tareas genericas de solucion de problemas Explicacion y Hechos y datos
− Clasificacon y construccion de hipotesis especificos
y planes de solucion de problemas consejos
pre−compilados

INTERFAZ DE COMUNICACION, EXPLICACION Y
ADQUISICION DE CONOCIMIENTO

SUBSISTEMA DE USUARIO SUBSISTEMA DE EXPLICACION SUBSISTEMA DE ADQUISICION
DEL CONOCIMIENTO
− Menus − ¿Como?
− Graficos − ¿Por que? − Procesado de palabras
− ¿Que sucede si...? − Entrada en linea
− Ayuda
− Herramientas de depuracion de la BC
− Librerias de casos y ejemplos
− Animacion
− Control de la inferencia

Usuario Ingenieria del Conocimiento

Figura A.1: Esquema detallado de un SBC.

Laura Castro

´
Indice de cuadros

1.1. Diferencias entre dato, informaciń y conocimiento . . . . . . . . . . .
o 1

4.1. Nombres estńdar de las Funciones de Transferencia.
a . . . . . . . . . . 25
4.2. Tareas Anal´
ıticas vs. Tareas Sint´ticas. . . . . . . . .
e . . . . . . . . . . 30
4.3. Tipos de comunicaciń. . . . . . . . . . . . . . . . . .
o . . . . . . . . . . 37
4.4. Semńtica de algunos tipos de comunicaciń. . . . . .
a o . . . . . . . . . . 38

6.1. Dec´logo del Ingeniero de Conocimiento. . . .
a . . . . . . . . . . . . . . 55
6.2. M´todos de Adquisiciń del Conocimiento. . .
e o . . . . . . . . . . . . . . 56
6.3. Clasificaciń de los M´todos de Adquisiciń de
o e o Conocimiento. . . . . . 57
6.4. Ejemplo de aplicaciń de EDM. . . . . . . . .
o . . . . . . . . . . . . . . 64
6.5. Ejemplo de clustering (I). . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.6. Ejemplo de redes ponderadas. . . . . . . . . . . . . . . . . . . . . . . . 68
6.7. Esquema de una parrilla. . . . . . . . . . . . . . . . . . . . . . . . . . . 70

89

´
Indice de figuras

1.1. Esquema de un SBC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1. IS vs. IC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Esquema de la metodolog´ de desarrollo incremental.
ıa . . . . . . . . . . 8
2.3. Esquema de la metodolog´ en cascada. . . . . . . . .
ıa . . . . . . . . . . 11
2.4. Niveles de la metodolog´ CommonKADS. . . . . . .
ıa . . . . . . . . . . 11

3.1. Modelo de la Organizaciń. . . . . . . . . . . . . . . . . . . . . . . . .
o 16

4.1. Categor´ en el modelo del Conocimiento. . . . . . . . .
ıas . . . . . . . . 19
4.2. Constructos del modelo del Conocimiento. . . . . . . . . . . . . . . . . 20
4.3. Relaciones en el modelo del Conocimiento. . . . . . . . . . . . . . . . . 21
4.4. Ejemplos de representaciń de Tipos de Regla. . . . . . .
o . . . . . . . . 22
4.5. Ejemplo de representaciń de Base de Conocimientos. . .
o . . . . . . . . 23
4.6. Elementos del Conocimiento Inferencial. . . . . . . . . . . . . . . . . . 24
4.7. Ejemplo de Inferencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.8. Ejemplo de Mapa Inferencial. . . . . . . . . . . . . . . . . . . . . . . . 26
4.9. Elementos del Conocimiento de la Tarea. . . . . . . . . . . . . . . . . . 27
4.10. Ejemplo de esquema de un posible M´todo de la Tarea. .
e . . . . . . . . 28
4.11. Gu´ para el modelado del Conocimiento. . . . . . . . . .
ıa . . . . . . . . 30
4.12. Relaciń del modelo de Comunicaciń con otros modelos.
o o . . . . . . . . 34
4.13. Estructura del modelo de Comunicaciń. . . . . . . . . .
o . . . . . . . . 35
4.14. Estructura general de un Diagrama de Di´logo. . . . . .
a . . . . . . . . 37
4.15. Esquema de la estructura de una transacciń (CM-1). . .
o . . . . . . . . 37

5.1. Del an´lisis al diseõ en CommonKADS. . . . . . . . . . . . . . . . . .
a n 41
5.2. Pasos en la construcciń del modelo de Diseõ. . . . . . . . . . . . . . .
o n 43
5.3. Esquema del Model View Controller. . . . . . . . . . . . . . . . . . . . 44

6.1. Primer escenario de adquisiciń del conocimiento. .
o . . . . . . . . . . . 52
6.2. Segundo escenario de adquisiciń del conocimiento.
o . . . . . . . . . . . 52
6.3. Tercer escenario de adquisiciń del conocimiento. .
o . . . . . . . . . . . 53
6.4. Cuarto escenario de adquisiciń del conocimiento. .
o . . . . . . . . . . . 53
6.5. Ejemplo de clustering (y II): dendrograma. . . . . . . . . . . . . . . . . 67

7.1. Tćnicas de valoraciń para SS.EE. . . . . . . . . . . . . . . . . . . . .
e o 80
7.2. Relaciń entre los distintos tipos de evaluaciń. . . . . . . . . . . . . .
o o 81

91

92 Apuntes – A. Ampliaciones

7.3. Ejemplo de red de Petri. . . . . . . . . . . . . . . . . . . . . . . . . . . 83

A.1. Esquema detallado de un SBC. . . . . . . . . . . . . . . . . . . . . . . 88

Laura Castro

Bibliograf´
ıa

[1] Alonso Betanzos, Amparo. Apuntes de clase.

[2] Vicente Moret, Amparo Alonso, et al. Fundamentos de Inteligencia Artiﬁcial. Ser-
vicio de Publicaciones de la Universidad de La Coru˜a, 2000.
n

93

´
Indice alfab´tico
e

conocimiento, 1 de adquisiciń, 56
o
adquisiciń, 51
o de despliegue, 56
an´lisis de protocolos, 59
a estructuradas, 56
brainstorming, 77 no estructuradas, 56
clustering, 65 experto
constructos personalizados, 69 acad´mico, 51
e
cuestionarios, 61 prćtico, 51
a
curvas cerradas, 62 te´rico, 51
o
entrevistas, 56
escalamiento multidimensional, 63 informaciń, 1
o
escalamiento psicol´gico, 62
o metodolog´ıa
escenarios, 51 CommonKADS, 10
m´todo delphi, 77
e desarrollo incremental, 8
movimiento de ojos, 61 en cascada, 8
observaciń directa, 62
o en espiral, 8
redes ponderadas, 68 prototipado r´pido, 7
a
tćnica nominal, 77
e modelo
tćnicas especiales, 77
e de agentes, 12, 16
categor´ 18
ıas, de comunicaciń, 12, 34
o
de la tarea, 26 de conocimiento, 12, 17
del dominio, 20 construcciń, 30
o
especificaciń, 31
o documentaciń, 34
o
identificaciń, 31
o plantillas, 29
inferencial, 23 validaciń, 33
o
ingenier´ del, 2
ıa de diseõ, 12, 41
n
p´blico, 2
u de organizaciń, 10, 15
o
privado, 2 de tareas, 12, 16
refinamiento, 33
semip´blico, 2
u nivel
sistema basado en, 3 de concepto, 12
constructos, 20 de contexto, 13
de implementaciń, 12
o
dato, 1 nivel de contexto, 10
dendrograma, 65
pathfinder, 68
EDM, 63 Petri
emparrillado, 69 red de, 83
entrevistas plan de comunicaciń, 36
o

94

referencia estńdar, 84
a
reglas
cadenas circulares, 82
completitud, 83
conclusiones no alcanzables, 82
inconsistencia, 82
no disparables, 82
redundancia, 82
subsunciń, 82
o

SBC, 3
evaluaciń, 79
o
software
ingenier´ del, 2
ıa

tr´
ıadas, 71
transacciń, 36
o

usabilidad, 79
utilidad, 79

validaciń, 79, 84
o
verificaciń, 79
o

95

Ec.pdf

Más contenido relacionado

La actualidad más candente (16)

Similar a Ec.pdf (20)

Ec.pdf