VALIDACIN Y USABILIDAD

DE
SISTEMAS INFORMTICOS

Vicente Moret Bonillo, Mayo de 2005

1

VALIDACIN Y USABILIDAD DE SISTEMAS INFORMTICOS

El objetivo de la ingeniera del conocimiento es definir las tcnicas que nos permitan
adquirir, formalizar, representar, y utilizar conocimiento de gran calidad, y especfico de un
dominio concreto. Este conocimiento debe poder ser integrado en un sistema computacional
ms amplio, y debe permitir la resolucin de problemas complejos para los que,
normalmente, se precisa un alto nivel de experiencia humana. La tabla muestra algunas de
las diferencias ms importantes que podemos identificar entre los sistemas inteligentes y los
sistemas convencionales.

Estructura

Problemas
apropiados

Estrategias de

Sistemas Expertos

Software convencional

Separacin del conocimiento de las estructuras de

Separacin de datos y algoritmos que utilizan los

control
Suelen incluir estructuras de explicacin de las

datos

Existen gestores de bases de datos que nos

(shells) comerciales que permiten centrarse en el

permiten centrarnos exclusivamente en los datos y

conocimiento
Problemas mal definidos, que no pueden ser

no en su almacenamiento o estructuracin
Problemas bien definidos, que pueden ser

especificados con precisin y que son resueltos

especificados sin ambigedad y que son resueltos

utilizando conocimiento heurstico.

Generalmente dominios sin experiencia

por algoritmos especficos.

Generalmente dominios con experiencia

computacional

computacional

Mtodos declarativos y no determinsticos

Mtodos procedimentales y determinsticos

Intentan seguir lneas de razonamiento similares a

Se centran en la solucin y no en la forma en que

las de los expertos humanos

se obtiene.

Interpretan datos

Manipulan datos

resolucin
Tienen en cuenta aspectos como la abstraccin, la
incertidumbre, el aprendizaje, etc.

Naturaleza del
conocimiento
empleado
Tipo de

No existen estructuras de explicacin

conclusiones
Se suelen construir a partir de herramientas

Resuelven problemas a travs del manejo de

informacin almacenada en bases de datos y
mediante procesos predecibles, fiables y exactos.

Son altamente interactivos

No siempre es necesaria la interactividad

Conocimiento proveniente de la experiencia

Conocimiento de naturaleza algortmica (alta

humana (alta interaccin con expertos)

interaccin con usuarios)

Informacin numrica y simblica

Informacin numrica

Informacin con incertidumbre

Informacin sin incertidumbre

informacin
utilizada

En el desarrollo de un sistema inteligente el ingeniero de conocimiento tiene que afrontar

retos y problemas que se salen del mbito de competencias de los ingenieros de software.
Claramente, y como ya se ha mencionado antes en este mismo texto, la ingeniera del
conocimiento est directamente relacionada con el conocimiento necesario para resolver
problemas. Por ello, las caractersticas diferenciales, estructurales y funcionales, de los
sistemas inteligentes y de los sistemas convencionales, condicionan enormemente los
2

procesos de validacin. As, aunque ya hemos comentado sucintamente algunas de tales

caractersticas, en este captulo ampliaremos lo dicho, y trataremos de orientar la discusin
hacia los aspectos ms relacionados con los problemas de validacin.

1. Adquisicin del Conocimiento, Representacin y Razonamiento

Decamos que los problemas ms importantes que debe resolver un ingeniero de
conocimiento, cuando se plantea el diseo y construccin de un sistema inteligente son: (1)
la adquisicin del conocimiento, (2) la representacin del conocimiento, y (3) la eleccin de
un modelo de razonamiento adecuado.
La adquisicin del conocimiento es una fase crucial en el desarrollo de un sistema
inteligente, que sin embargo carece de la misma importancia en el desarrollo de un sistema
convencional. Lo ms parecido a una adquisicin de conocimiento en ingeniera del
software es el establecimiento de los requisitos que el analista debe emplear para disear el
producto software que se pretende construir. Por el contrario, el ingeniero de conocimiento
debe ser capaz de disear todo un modelo computacional de comportamiento inteligente.
Para ello debe tratar de extraer el conocimiento experto de una manera correctamente
articulada, y luego ser capaz de transferir este conocimiento a un programa. Esta tarea es
enormemente compleja, hasta el punto que muchos autores la consideran un cuello de
botella que impide la popularizacin de los sistemas inteligentes en muchos mbitos.
Aunque ya hemos adelantado algo sobre este interesante problema de la adquisicin del
conocimiento, comentaremos ahora que, segn Gonzlez y Dankel-, la tarea global puede
dividirse en dos fases: (1) extraccin del conocimiento de las fuentes de experiencia, y (2)
representacin de este conocimiento en una herramienta. La figura ilustra distintas tcnicas
que pueden emplearse en la adquisicin del conocimiento, y que van desde lo estrictamente
manual hasta mtodos prcticamente automticos.

FUENTE DE
CONOCIMIENTO

Experto
humano

MODO DE
ADQUISICIN

Ingeniero del
conocimiento
Manuales

2
Textos

Experto
humano

Programa
inteligente
de edicin

Semiautomticos

Ejemplos y
casos histricos
4

Textos

Programa de
induccin

Programa de
comprensin
de textos

Automticos

Comentaremos en primer lugar la interaccin directa entre expertos humanos e ingenieros de

conocimiento, que habitualmente se lleva a cabo mediante frecuentes entrevistas entre
miembros de ambos colectivos. En este caso, el proceso de adquisicin se efecta de manera
progresiva, y el ingeniero de conocimiento suele realizar codificaciones parciales que le son
presentadas al colectivo de expertos para su crtica y anlisis. Este procedimiento interactivo
suele conducir a modelos computacionales cada vez ms refinados. De acuerdo con este
esquema, el ingeniero de conocimiento no acta como un mero receptor de informacin; al
contrario, ayuda al experto humano a descompilar su conocimiento y lo convierte en algo
que es computacionalmente operativo. Es importante reconocer aqu que, normalmente, los
expertos humanos saben resolver problemas, pero tienen grandes dificultades a la hora de
explicar cmo lo hacen.
Pero la entrevista no es el nico modo de extraccin del conocimiento de los
expertos humanos. Otras tcnicas como la observacin directa, o los mtodos intuitivos,
pueden ser utilizados de forma combinada con las entrevistas, para que la adquisicin del
conocimiento sea ms eficaz. Adems, hay que recordar que el colectivo de expertos no es la
4

nica fuente de conocimientos de que dispone el ingeniero i.e., conocimiento pblico y

conocimiento semipblico-.
Hasta ahora slo hemos comentado mtodos manuales de adquisicin del conocimiento. Sin
embargo la automatizacin de la tarea ha ido ganando terreno poco a poco, y han ido
apareciendo nuevos esquemas de adquisicin que incluyen distintos grados de
automatizacin. Uno de tales esquemas supone la interaccin del experto con un programa
inteligente de edicin. De este modo, el experto humano puede introducir directamente su
organizacin conceptual del dominio, y sus heursticas, en la base de conocimientos. En este
caso, la labor del ingeniero de conocimiento consiste en desarrollar adecuadamente el
programa inteligente de edicin, que debe incorporar capacidades sofisticadas de dilogo, y
un amplio conocimiento sobre la estructura de la base de conocimientos.
Otra tcnica automtica de adquisicin es el aprendizaje automtico. Esta tcnica implica:
(1) la recoleccin de ejemplos o casos histricos, que son suministrados por el colectivo de
expertos humanos, o que son obtenidos directamente a partir de las fuentes bibliogrficas, y
(2) la utilizacin de un programa de induccin que nos permitir extraer reglas y heursticas
de los casos. La mayor ventaja de esta tcnica estriba en que, a pesar de que los expertos
tienen problemas para explicar cmo hacen las cosas, suelen encontrarse cmodos cuando
de lo que se trata es de interpretar ejemplos.
En cualquier caso, y por muy avanzados que sean los mtodos automticos de adquisicin
del conocimiento, la interaccin con el experto va a ser siempre imprescindible. Esta
circunstancia exige que el ingeniero de conocimiento adems de conocer los paradigmas de
la programacin clsica, tiene que dominar y utilizar correctamente aspectos relacionados
con la psicologa cognoscitiva, y la programacin simblica.
Frente a la programacin convencional, en donde los requisitos del programa, una vez
establecidos, estn claros para todo el mundo, la programacin inteligente se enfrenta con el
problema de la subjetividad inherente al conocimiento. El conocimiento humano es
subjetivo por naturaleza, y suele ser corriente que, frente a un mismo problema, dos expertos
distintos incluso de la misma cualificacin profesional-, se comporten de forma distinta.
Las respectivas soluciones propuestas, e incluso los distintos enfoques planteados, pueden
ser perfectamente correctos, pero cada uno de estos expertos considerar su propuesta como

la mejor. Adems, factores ajenos a los procesos especficamente inferenciales estrs,

cansancio,- pueden afectar al proceso de toma de decisiones de un individuo concreto.
La subjetividad a que acabamos de referirnos afecta de manera importante a la validacin de
un sistema inteligente ya que, finalmente, el rbitro que tendr que decidir sobre el grado de
correccin del sistema inteligente tendr que ser el colectivo de expertos humanos (esto es
una sobresimplificacin del problema, sobre la que discutiremos en profundidad ms
adelante) y quin valida al validador?
La segunda gran cuestin a la que el ingeniero de conocimiento debe dar respuesta se refiere
al paradigma de representacin del conocimiento previamente adquirido. Al respecto, la
eleccin del esquema de representacin del conocimiento, y de la herramienta que va a
emplear para su representacin, son cuestiones crticas en el desarrollo de sistemas
inteligentes, que pueden tener una gran repercusin en la futura utilizacin de los mismos.
Ya hemos comentado que los distintos esquemas de representacin del conocimiento pueden
ser clasificados en diversas categoras (mtodos formales, mtodos estructurados, mtodos
declarativos, mtodos procedimentales). Nos ocuparemos aqu de dos categoras no
excluyentes, que son los mtodos procedimentales, y los mtodos declarativos.
Los mtodos procedimentales engloban a los sistemas que utilizan reglas de produccin, y a
los sistemas basados en reglas lgicas. En tales mtodos, el conocimiento se representa en
base a estructuras dinmicas que nos describen la forma en que se utiliza el conocimiento
representado. Por el contrario, los mtodos declarativos de representacin frames, objetos,
redes semnticas,- son ms adecuados para la representacin de hechos de naturaleza
esttica, pero que estn relacionados entre s (por ejemplo a travs de taxonomas). Estos
mtodos declarativos incluyen tambin cierta informacin muy limitada-, sobre cmo
emplear el conocimiento representado.
Como norma general, los sistemas que combinan las capacidades de representacin de los
mtodos declarativos (habitualmente los que siguen el paradigma de orientacin a objetos),
con las capacidades inferenciales de los mtodos procedimentales (generalmente reglas de
produccin), suelen ser las soluciones ms flexibles y mejores.
El esquema de representacin elegido est estrechamente relacionado con el mecanismo de
razonamiento que tendremos que implementar en nuestro sistema inteligente. As, los
6

procesos de razonamiento influyen sobre el paradigma de representacin, y viceversa. Y es

aqu donde puede aparecer uno de los mayores problemas de la ingeniera del conocimiento,
denominado desplazamiento del paradigma, que fue descrito por Waterman, y que se
muestra en la figura.

Desarrollo
incremental

Paradigma 2
Herramienta 2

Cambio de
paradigmas

Desarrollo
incremental

Esquema
2

Retraso en el
proyecto

Paradigma 1
Herramienta 1

Esquema
1

Paradigmas
inapropiados

Continuar sin
cambios

Dificultades en
el diseo

El desplazamiento del paradigma surge cuando, en la fase de desarrollo del sistema

inteligente, el ingeniero de conocimiento descubre que alguno de los esquemas elegidos para
el desarrollo del sistema no es adecuado (normalmente, esquema de representacin, modelo
de razonamiento, o herramienta entorno- de programacin). La cuestin ahora es decidir si
se debe continuar el desarrollo con infraestructuras inadecuadas que posteriormente
complicarn los resultados de la validacin, y la usabilidad del sistema-, o si se debe
replantear el proyecto, con el consiguiente retraso que ello puede suponer. De todas formas,
si el desplazamiento del paradigma tiene lugar en etapas tempranas de construccin, su
deteccin puede ser beneficiosa, ya que permite ajustar y optimizar las tcnicas de
desarrollo.
Por ltimo, la tercera gran cuestin con la que se enfrenta el ingeniero del conocimiento es
la eleccin del modelo de razonamiento que debe seguir el sistema inteligente.
7

Los mecanismos o modelos de razonamiento forman parte de las estructuras de control del
conocimiento en la mayor parte de los casos del motor de inferencias-, y son fundamentales
a la hora de organizar la bsqueda de soluciones.
Ya hemos comentado que las caractersticas del dominio, y las caractersticas del problema,
condicionan en gran medida el modelo de razonamiento que debe ser implementado.
Recordamos ahora algunos dominios tpicos y los modelos de razonamiento apropiados:

Dominios Simblicos sin Incertidumbre

Dominios de Naturaleza Estadstica

Dominios con Incertidumbre

Dominios con Matices Lingsticos

Modelos Categricos
Modelos Estadsticos
(Bayes, Redes de Creencia)
Modelos Cuasi-Estadsticos
(Factores de Certidumbre, Teora Evidencial)
Lgica Difusa

El concepto de incertidumbre juega un papel muy importante en los sistemas inteligentes, y

afecta considerablemente a su validacin. Muchas tareas propias de la programacin
inteligente llevan asociados un cierto grado de incertidumbre. Los sistemas basados en
conocimiento tratan de presentar una conducta inteligente; para ello intentan modelar las
asociaciones empricas, y las relaciones heursticas, que los expertos humanos han ido
elaborando a travs de la prctica diaria de su profesin o dominio de experiencia. En
cualquier caso no suelen utilizar algoritmos determinsticos que ofrecen soluciones precisas.
Por lo tanto, los sistemas inteligentes que trabajen en ciertos dominios deben manejar con
soltura conceptos, ideas y relaciones, que vengan afectados de incertidumbre.

La incertidumbre puede aparecer por distintas causas:

Hay falta de informacin. Algunos datos no estn disponibles en un momento dado.

Los datos y la informacin estn disponibles, pero son ambiguos debido a errores en las
medidas, a la presencia de medidas contradictorias, o a otras causas similares.
8

La representacin de la informacin es imprecisa o es inconsistente.

La informacin disponible est basada en suposiciones del usuario.

La informacin est basada en estndares, pero los estndares incluyen excepciones.

Adems de las circunstancias que acabamos de detallar, la incertidumbre puede ser una
caracterstica esencial del propio conocimiento heurstico del experto, ya que puede
representar suposiciones que los expertos hacen basndose en asociaciones plausibles (pero
no necesariamente ciertas) observadas.
Todas estas consideraciones sobre la incertidumbre obligan a que, durante el proceso de
validacin, tengamos que considerar aspectos relacionados con la representacin del
conocimiento incierto, la forma de tratar la informacin imprecisa, y los mecanismos segn
los cuales podemos inferir conocimiento a partir de datos inciertos. Al respecto, algunos
autores sostienen que, debido a la capacidad limitada de los sistemas inteligentes en el
tratamiento de la incertidumbre, el rendimiento de tales sistemas puede estar lejos del
conseguido por un humano, incluso no tan experto. Estaramos pues fallando en la
construccin de un modelo computacional de comportamiento inteligente. En consecuencia,
hay que seguir trabajando en la construccin de modelos y teoras que nos permitan tratar de
manera eficiente esta escurridiza incertidumbre.

2. Metodologas de Diseo y Desarrollo

Al igual que ocurre con los sistemas software convencionales, la utilizacin de una
metodologa de diseo y desarrollo para la construccin de sistemas inteligentes contribuye
de manera decisiva al xito del proyecto. A continuacin analizaremos algunas de las
metodologas ms utilizadas por los ingenieros de conocimiento, y trataremos de
compararlas con las metodologas de la ingeniera del software, cuando ello sea posible.

Metodologa de Desarrollo Adquiere y Codifica

Los primeros sistemas inteligentes fueron desarrollados sin un esquema preciso y bajo un
mtodo que pas a llamarse adquiere y codifica, muy similar al codifica y corrige del
software convencional. Este mtodo consiste en desarrollar el sistema en base a una serie de
9

iteraciones, en cada una de las cuales se interacta con el experto y se codifica el

conocimiento extrado.
En un principio se puede suponer que este procedimiento es vlido, ya que las diferencias
existentes con los sistemas convencionales impiden la utilizacin de mtodos de desarrollo
tpicos. Esta afirmacin puede ser cierta para sistemas pequeos y que trabajen de forma
aislada, sin estar integrados en sistemas ms amplios. Sin embargo, como su documentacin
es mnima, y se han sustituido las especificaciones y el diseo por el cdigo del programa,
este mtodo no es apropiado para sistemas de tamao mayor.
Adems, con el mtodo adquiere y codifica, estamos olvidando lecciones que los
desarrolladores de software han estado aprendiendo durante 40 aos. Por ejemplo, durante la
fase de anlisis los desarrolladores determinan el mbito del problema, investigan visiones
alternativas de las tareas a realizar y producen una especificacin de requisitos del software
con la que todo el personal puede trabajar. Viendo el proyecto como un todo, el personal
debe realizar planificaciones. Finalmente, para asegurarnos de que se han cumplido los
requisitos, el personal involucrado debe establecer una metodologa que permita la
produccin, la verificacin, y la validacin de los productos intermedios.
En 1983, Boehm confeccion una lista de principios, o lneas directrices, que deberan
cumplirse a la hora de desarrollar sistemas convencionales, y que tambin son aplicables al
diseo y construccin de sistemas inteligentes. Entre ellos destacamos los siguientes:

Desarrollar el sistema mediante un ciclo de vida dividido en fases.

Verificar el sistema y validar sus resultados en cada fase.

Mantener el control del producto a travs de hitos o puntos de control.

Utilizar tcnicas modernas de programacin como las herramientas y los anlisis

estructurados, por ejemplo, las herramientas CASE.

Mantener una descripcin detallada de la situacin del proyecto en cada momento.

Utilizar menos personal en el desarrollo del sistema, pero con ms experiencia.

Comprometerse a mejorar el proceso adoptando diferentes mtodos y tcnicas.

10

Siguiendo este planteamiento, Martin indic la idoneidad de estas recomendaciones en el

desarrollo de sistemas de inteligencia artificial y tambin mostr como la tcnica de
adquiere y codifica slo cumpla dos de ellos: la validacin continua y la utilizacin de
equipos pequeos.

Metodologa de Desarrollo de Buchanan.

Uno de los primeros mtodos de desarrollo estructurado de sistemas inteligentes fue el
propuesto por Buchanan y otros autores en 1983. Segn estos autores la adquisicin del
conocimiento de un sistema inteligente, y por extensin la construccin de todo el sistema,
poda dividirse en las cinco fases dela figura: identificacin, conceptualizacin,
formalizacin, implementacin y prueba.

Requisitos

Identificacin

Conceptos

Conceptualizacin

Estructuras

Formalizacin

Reglas

Rediseos

Refinamientos

Implementacin

Reformulaciones

Prueba

Sin embargo el proceso real no est tan bien definido como puede sugerir la figura anterior,
y ms bien representa una aproximacin a las distintas y complejas fases que se llevan a
cabo a la hora de desarrollar un sistema inteligente, y que pueden variar de una situacin a
otra.
La descripcin de cada una de estas fases es la siguiente:

11

Identificacin. Fase mediante la que se reconocen aspectos importantes del problema,

como son los participantes (expertos del dominio, ingenieros del conocimiento y futuros
usuarios), las caractersticas del problema (tipo, subtareas de que se compone,
terminologa a utilizar, aspectos fundamentales, etc.), los recursos disponibles (fuentes
de conocimiento, facilidades computacionales, tiempo de desarrollo, financiacin, etc.),
y las metas a alcanzar (formalizar conocimiento experto, distribuir experiencia, ayudar a
la formacin de nuevos expertos, etc.).

Conceptualizacin. Fase mediante la que se trata de organizar el conocimiento segn un

esquema conceptual. El experto y el ingeniero del conocimiento tratan de encontrar
conceptos que representen el conocimiento del experto, al mismo tiempo que intentan
determinar cmo es el flujo de informacin durante el proceso de resolucin de
problemas.

Formalizacin. Esta fase consiste en traducir los conceptos clave, los subproblemas, y
las caractersticas del flujo de informacin, identificados durante la fase anterior, en
representaciones formales basadas en herramientas o esquemas de la ingeniera del
conocimiento.

Elicitacin. Aunque no aparece en el trabajo original de Buchanan, es comn incluir una

fase de elicitacin despus de la fase de formalizacin. En esta fase se lleva a cabo la
extraccin del conocimiento mediante un soporte fsico que es consistente con la
informacin obtenida durante los procesos de identificacin y conceptualizacin.

Implementacin. En esta fase, el ingeniero de conocimiento formula reglas, y estructuras

de control, que representan los conceptos y el conocimiento formalizado. El resultado es
un programa prototipo que nos permite comprobar si hemos conceptualizado y
formalizado bien el conocimiento que el experto tiene sobre el problema.

Prueba. Esta fase consiste en la evaluacin del rendimiento del prototipo construido para
encontrar errores o anomalas en la base de conocimientos o en los mecanismos de
inferencia.

Buchanan sita los lazos de realimentacin despus de la fase de prueba, pero tambin
indica que el proceso no tiene por qu seguir estrictamente la secuencia representada en la
12

figura anterior. Autores posteriores, como Mayrhauser, sealan que las retroalimentaciones
pueden aparecer entre cualquier par de fases de la metodologa. As, por ejemplo, si el
ingeniero del conocimiento no encuentra reglas adecuadas durante la implementacin puede
requerir una vuelta atrs y una reformulacin del problema. La nueva representacin del
ciclo de vida de los sistemas inteligentes sera tal y como se presenta en la siguiente figura,
una red completamente comunicada.

Identificacin

Prueba

Implementacin

Conceptualizacin

Formalizacin

Las estructuras de este tipo son muy complejas de controlar y de manejar, ya que el nmero
de iteraciones entre las fases es desconocido, y los objetivos pueden cambiar a medida que
avanza el desarrollo. Tambin es difcil llevar a cabo un control de los progresos realizados.

Metodologa de Diseo Incremental

Hasta ahora hemos visto cmo la construccin de sistemas inteligentes pone un nfasis
especial en el desarrollo iterativo de los mismos, es decir, el sistema se desarrolla en base a
una serie de ciclos, en cada uno de los cuales se lleva a cabo un refinamiento (depurando
errores en la base de conocimientos hacindola ms exacta), o una extensin del sistema
existente (ampliando las capacidades del mismo).
13

Esta tendencia hacia diseos incrementales o evolutivos es propia tambin de la ingeniera

del software convencional. As, los ms modernos desarrollos del software tendan a tcnicas
incrementales o evolutivas, dejando cada vez ms de lado el clsico modelo en cascada. En
palabras de Boehm el modelo en cascada no est muerto, pero debera estarlo.
Los modelos de desarrollo incremental de los sistemas inteligentes se caracterizan porque
intentan ajustar la terminologa de la ingeniera del software al desarrollo de sistemas de
inteligencia artificial. Cuando describamos la metodologa de Buchanan, veamos que
aparecan trminos completamente nuevos (conceptualizacin, formalizacin, etc.), trminos
que generalmente no habamos visto en los modelos de desarrollo del software
convencional. El motivo es que Buchanan inicialmente pens su metodologa como una
metodologa de adquisicin del conocimiento, e hizo hincapi en las fases que describen el
proceso que sufre la informacin, desde que fluye del experto, hasta que es finalmente
implementada en el sistema. Posteriormente este proceso se tom como la construccin del
sistema inteligente completo, porque las fases descritas se ajustaban tambin a esta
descripcin. En este caso las etapas de adquisicin del conocimiento, propiamente dichas,
seran las de conceptualizacin, formalizacin, y elicitacin.
Posteriormente, y probablemente con el fin de hacerlos ms familiares, los mtodos de
desarrollo adquirieron los nombres tpicos de la ingeniera del software (anlisis,
especificacin, diseo, etc.) quedando las fases propias de los sistemas inteligentes, como la
adquisicin de conocimiento, imbuidas dentro de estas fases tpicas. Existen multitud de
mtodos de desarrollo de sistemas inteligentes (probablemente tantos como investigadores
trabajan en el tema), y la gran mayora de ellos se basan en el prototipado rpido y el
desarrollo incremental como paradigmas para lograr un sistema efectivo.

Metodologa de Desarrollo de Gonzalez-Dankel

El mtodo de Gonzalez-Dankel se basa en una primera adquisicin y representacin del
conocimiento, necesaria para la implementacin de un aspecto limitado del dominio del
problema. De esta forma se puede construir un primer prototipo que exhiba cierto parecido
con lo que ser el sistema final.

14

La construccin de este prototipo permite la aparicin de informacin de retroalimentacin,

que nos ayuda a definir el mbito de nuestro conocimiento, las necesidades del usuario, y la
validez de las decisiones tomadas durante la etapa de diseo. De esta forma, si fuese
necesario realizar un desplazamiento del paradigma, su impacto sera mnimo debido a su
temprana aparicin.
Este prototipo inicial utiliza un ciclo de vida modificado. Las fases de anlisis y
especificacin se realizan teniendo en cuenta el sistema global, pero el diseo y la
implementacin se realizan de forma ms sencilla y preliminar. De esta forma podemos
obtener pronto un prototipo que puede ser evaluado para obtener la necesaria informacin de
retroalimentacin.
El prototipo inicial puede entonces desecharse, o ser mejorado de forma incremental, hasta
desarrollar un subsistema del producto final. Muchas veces se prefiere desecharlo para
empezar el proceso de desarrollo de una forma fresca, evitando los errores iniciales que
hayamos podido producir.
El proceso que sigue es el del desarrollo incremental del sistema. Este desarrollo utiliza el
concepto de divide y vencers, en donde el conocimiento se separa en mdulos que son
desarrollados de forma incremental hasta componer el problema completo. Este desarrollo
implica varios ciclos de elicitacin de conocimiento de los expertos, implementacin de este
conocimiento en los expertos, validacin de los resultados y refinamiento de la
implementacin o correccin de los errores encontrados.
Al utilizar la divisin en mdulos podemos tener al sistema parcialmente funcionando antes
de estar completamente terminado. Generalmente esta aproximacin no es posible en los
sistemas convencionales, y se debe esperar a que el sistema en cuestin est totalmente
implementado antes de empezar a usarlo. La figura siguiente ilustra esquemticamente el
mtodo de Gonzlez y Dankel que acabamos de describir.

15

Anlisis

Ajuste del diseo

Especificacin

Implementacin

Diseo preliminar
Prueba (V&V)
Prototipo inicial
Mantenimiento

Evaluacin

Diseo final

Esta descripcin coincide con un modelo de desarrollo del software convencional que
incluya el prototipado rpido y el desarrollo incremental. Sin embargo las fases descritas
incorporan ciertas diferencias de forma que admitan las caractersticas diferenciales de los
sistemas inteligentes, como veremos a continuacin:

Anlisis del problema. Evala el problema y los recursos disponibles para determinar la
aplicabilidad de la solucin basada en el conocimiento. Se realizan anlisis de costebeneficio, y tambin pueden establecerse estudios de mercado.

Especificacin de requisitos. Se formaliza y se escribe lo aprendido durante la fase de

anlisis. Se fijan los objetivos del proyecto, y los medios a utilizar para conseguir esos
objetivos. Debido a las especiales caractersticas de los sistemas inteligentes suele ser
complicado establecer unos requisitos claros desde el primer momento; sin embargo, la
experiencia indica que los sistemas no pueden desarrollarse adecuadamente sin estar
basados en unas especificaciones formales.

Diseo preliminar. Trata las decisiones de alto nivel necesarias para el desarrollo del
prototipo inicial. Se determina el esquema de representacin del conocimiento, la
eleccin de la herramienta, y la eleccin de los expertos humanos que colaborarn en el

16

desarrollo. En esta fase es necesaria la realizacin de tareas de adquisicin del

conocimiento.

Prototipo inicial y evaluacin. Se desarrolla un prototipo similar al sistema completo

pero con una funcionalidad limitada. Este prototipo suele incluir una interfaz, y un
subconjunto de conocimiento razonablemente robusto. Mediante el prototipo se pretende
extraer nuevo conocimiento de los expertos y validar las consideraciones de diseo
establecidas. Se realiza una evaluacin para comprobar que no se han cometido errores
en el diseo preliminar.

Diseo final. Implica la seleccin de las herramientas y los recursos necesarios para el
desarrollo del sistema (tambin incluye la seleccin del esquema de representacin del
conocimiento). Se deben especificar cules son los mdulos en los que se va a dividir el
sistema, cules son sus entradas y cules son las salidas que se pretenden obtener.

Implementacin. Sigue las indicaciones obtenidas del diseo para implementar la base de
conocimientos del sistema.

Prueba. Generalmente conocida en el mundo de los sistemas inteligentes como la fase

V&V (verificacin y validacin). Los objetivos son similares a los de la fase de prueba
en los sistemas convencionales, pero la forma de llevarla a cabo difiere
considerablemente, cuestin que veremos con ms detalle ms adelante en este mismo
libro.

Ajuste del diseo. A medida que el trabajo progresa es necesario realizar ajustes de
diseo al principio de cada iteracin. Si estos ajustes son de poca importancia no suelen
plantearse problemas adicionales, pero si los ajustes requieren cambios significativos
pueden aparecer desplazamientos del paradigma.

Mantenimiento. Fase similar a la descrita para los sistemas convencionales.

Metodologa de Desarrollo de Scott.

En este mtodo, el desarrollo de un sistema inteligente se divide en cuatro fases: (a) fase de
anlisis, en la que las partes interesadas investigan la posibilidad de desarrollar un sistema
inteligente, (b) fase de especificacin, en la que se inicia el proyecto y se fijan las bases a
17

utilizar en el desarrollo, (c) fase de desarrollo, en la que se realiza el diseo y la

implementacin del sistema, y (d) fase de utilizacin, en la que se habilita el sistema para su
uso rutinario. Estas fases se dividen en subfases como puede verse en la figura.

ANLISIS
Identificacin

ESPECIFICACIN

DESARROLLO

Refinamiento
y extensin

UTILIZACIN

Identificacin de la potencial
aplicacin

Valoracin

Comprobacin de la adecuacin
de las tcnicas de ingeniera del
conocimiento

Familiarizacin

Definir lo que har el sistema.

Trabajar con el experto para
planificar el desarrollo.

Diseo conceptual

Aprender cmo el experto

resuelve el problema y desarrollar
un modelo conceptual del sistema

Diseo de
implementacin

Decidir la representacin del

conocimiento y los formalismos de
control para implementar el
modelo conceptual

Implementacin

Seguir el diseo de
implementacin para construir la
base de conocimientos

Evaluacin

Comprobar si el sistema funciona

correctamente

Pruebas de campo

Mantenimiento

Instalar el sistema en el dominio

de uso rutinario
Corregir errores, actualizar y
aumentar el sistema

Los aspectos importantes de esta metodologa son los siguientes:

Sigue haciendo hincapi en el prototipado rpido y en el desarrollo incremental. Las

primeras versiones del sistema no tienen por qu realizar todas las tareas posibles, ni por
qu tratar todos los conjuntos de casos. Los incrementos posteriores se realizarn a
travs de una fase de refinamiento y extensin.
18

Los sucesivos prototipos que se van construyendo son una ayuda para el proceso de
adquisicin del conocimiento.

La fase de utilizacin empieza cuando el sistema se instala en el dominio en el que se

usar de forma rutinaria. La fase de mantenimiento posterior puede mostrar errores, que
es preciso corregir, o recoger sugerencias de los usuarios, que es necesario implementar.

Como vemos, las caractersticas de esta metodologa son muy parecidas a las de la
metodologa de Gonzalez y Dankel, slo que la forma de representar las fases es diferente.
Sin embargo, en la metodologa de Scott se presta ms atencin a la fase de adquisicin del
conocimiento. Aunque esta fase no aparece en la figura anterior, la adquisicin del
conocimiento es un proceso que se distribuye en todas las fases que se han representado; es
decir, la adquisicin del conocimiento tiene cierta importancia en cada una de las fases de
desarrollo de un sistema inteligente, segn se ilustra en la figura siguiente.

Identificacin
Fam iliarizacin
Diseo de im plem entacin
Evaluacin
Mantenim iento
0

10

20

30

40

50

60

70

80

90

100

La metodologa de Scott distingue entre dos tipos de adquisicin del conocimiento:

Adquisicin inicial. Es una fase preparatoria en la que la informacin obtenida nos

permite tener un conocimiento ms amplio de lo que debe hacer el sistema inteligente,
de cmo va a ser usado, y de cmo hay que desarrollarlo. Esta adquisicin inicial
aparece en las fases de anlisis y especificacin.

19

Adquisicin detallada. Se caracteriza porque su foco de atencin es ms estrecho y

profundo, es decir, pone ms nfasis en los detalles que la fase anterior. La informacin
obtenida en esta fase permite, a los ingenieros del conocimiento, comprender cmo los
expertos humanos realizan sus tareas. Esta comprensin posibilita que se trasladen los
procedimientos de los expertos humanos a la base de conocimientos de un sistema
inteligente. La adquisicin detallada aparece en las fases de desarrollo y utilizacin.

Tipos de prototipos
Como hemos visto en las metodologas expuestas en los apartados anteriores, el desarrollo
incremental consiste en la construccin de una serie de prototipos que son modificados
sucesivamente hasta obtener el sistema final. Waterman divide estos prototipos en cinco
categoras a partir de una serie de criterios: uso, robustez, eficacia, nmero de reglas, tiempo
de desarrollo, etc. Hoy en da ya no existe una correspondencia clara entre el nmero de
reglas y el nivel del prototipo aunque en esta divisin se siguen manteniendo los criterios de
Waterman. Los distintos prototipos son:

Prototipo de demostracin. Es un programa pequeo que contiene una parte del

problema a resolver. Este programa se usa generalmente de dos formas: (a) para
convencer a los potenciales usuarios de que la tecnologa de los sistemas expertos puede
ser empleada para resolver el problema en cuestin, y (b) para comprobar ideas sobre la
definicin del problema, el mbito, y la representacin del dominio. En sistemas basados
en reglas estos prototipos suelen contener de 50 a 100 reglas, son capaces de resolver
uno o dos casos y su desarrollo suele llevar unos tres meses.

Prototipo de investigacin. Es un programa de tamao medio y que tiene un rendimiento

aceptable en una serie de casos de prueba. Estos sistemas tienden a ser frgiles y a fallar
cuando se le presentan casos que estn en el lmite del dominio de aplicacin del
sistema. Debido a que la validacin no ha sido intensiva tambin pueden fallar en casos
que caen dentro de su mbito. Un prototipo de investigacin suele contener de 200 a 500
reglas, se comporta correctamente en un gran nmero de casos y su desarrollo suele
llevar de uno a dos aos.

20

Prototipo de campo. Son sistemas de tamao medio y grande, que han sido validados a
travs de casos reales. Son moderadamente fiables, contienen interfaces amigables y
recogen las necesidades de los usuarios finales. Un prototipo de campo suele contener
entre 500 y 1000 reglas, se comporta muy bien en un gran nmero de casos y su
desarrollo puede llevar de 2 a 3 aos.

Prototipo o modelo de produccin. Son grandes sistemas que han sido intensivamente
probados en el entorno de trabajo real y que pueden ser reimplementados en lenguajes
ms eficientes para incrementar su velocidad y reducir las necesidades de
almacenamiento. Un prototipo de produccin suele contener entre 500 y 1500 reglas; es
correcto, rpido y eficiente en la toma de decisiones y su desarrollo lleva de 2 a 4 aos.

Sistema comercial. Son prototipos de produccin que son usados de forma regular en
sistemas o mbitos comerciales. XCON, uno de los mejores ejemplos de un sistema
comercial tena alrededor de 3000 reglas, alcanzaba conclusiones correctas entre un 90 y
un 95 por cien de las veces y su desarrollo necesit de 6 aos.

Desgraciadamente todava hay muy pocos sistemas que alcanzan el rango de prototipo de
produccin, y menos an los que llegan a convertirse en un sistema comercial. La mayora
de los sistemas se quedan en las fases de prototipo de demostracin o prototipo de
investigacin.

Metodologa de Desarrollo en Espiral

Cuando hablbamos del software convencional comentbamos que las metodologas
incrementales se mejoraron con la llegada de las metodologas en espiral. Con los sistemas
inteligentes pas algo parecido. As, el desarrollo incremental del sistema pas a
representarse no como un bucle cuyas fases se repiten sucesivamente, sino como una espiral
en la que las fases se repiten, aunque con modificaciones, a medida que avanza el desarrollo.
En la bibliografa podemos encontrar muchas referencias que defienden la metodologa en
espiral como la ms adecuada para los sistemas inteligentes (Lee y OKeefe, 1994), (Lowry
y Duran, 1989), (Culbert et al., 1987), (Noblett y Jones, 1991), (Cardeosa et al., 1991),
(Stachowitz y Combs, 1987), etc. De todos ellas destacaremos el trabajo de Lee y OKeefe

21

ya que en l se presta una especial atencin al problema de la validacin y verificacin de

sistemas inteligentes.
Lee y OKeefe presentan un modelo de desarrollo que sigue el modelo en espiral propuesto
por Boehm (1988), pero modificado para aceptar las particularidades de los sistemas
inteligentes, tal y como se muestra en la figura.

Anlisis de
Requisitos
(AR)

AR

AR

Verificacin
de Requisitos
(VR)

AR

AR

Recoleccin
de datos

Test de
campo

Validacin

VR

VR

Inicio del ciclo

AC

Casos de Test
NAR
Prot. demostracin
Verificacin

VR

VR

Prototipo de
investigacin

AC

NAR

AC

Adquisicin del
conocimiento
(AC)
AC

Grupo de
control

Prototipo de
campo

Verificacin
Prototipado

Modelo de
produccin

NAR

NAR

Fijar un nivel
aceptable de
rendimiento(NAR)

En su trabajo, Lee y OKeefe no pretenden desarrollar el mtodo de construccin de

sistemas inteligentes sino que presentan su aproximacin al problema, e indican que
cualquier otra solucin puede ser igualmente vlida siempre que incluya el prototipado
rpido y el desarrollo incremental.
En este modelo es de destacar la inclusin del trmino nivel aceptable de rendimiento.
Esta expresin fue introducida por OKeefe en 1987, y hace referencia al hecho de que, al
validar un sistema inteligente, no se debera clasificar su rendimiento como vlido o invlido
ya que, al ser los sistemas expertos representaciones o abstracciones de la realidad, nunca se
iba a obtener un rendimiento perfecto. En vez de eso se fija un nivel de aceptabilidad que el
22

sistema debe cumplir, y que puede ser fijado por los usuarios, los desarrolladores, los
encargados de la financiacin del proyecto, o por terceras personas
Imaginemos un sistema que produce una interpretacin dividida en 4 categoras: A, B, C y
D. Un sistema ideal obtendra rendimientos de casi en 100% en su clasificacin, sin
embargo, un nivel aceptable de rendimiento puede no ser tan estricto. As, por ejemplo,
podemos indicar que la clasificacin de A y B debe ser correcta pero se permite cierta
variacin en la clasificacin de C y D, adems nunca se debe clasificar un caso A como B,
pero puede no ser tan importante si un caso B se clasifica como A. Muchas veces el nivel
aceptable de rendimiento reflejar la habilidad de trabajar a niveles similares a los de la
experiencia humana (como el sistema es un modelo del experto no trabajar mejor que el
experto). As Bachant y McDermott (1984) comprobaron que al sistema R1 los usuarios no
le pedan ms de lo que le pedan a sus predecesores humanos.
El nivel aceptable de rendimiento se define normalmente en los requisitos del sistema pero,
a menudo, es redefinido y expandido despus de la adquisicin de conocimiento. La
comprobacin del cumplimiento de este nivel se realiza a travs de diversos mtodos
(pruebas basadas en casos, tests de Turing, tests de campo, etc.), que veremos
detalladamente un poco ms adelante. En las ltimas espirales esta comprobacin tender a
desplazarse hacia criterios de usabilidad, siempre teniendo en cuenta el tipo de sistema que
estamos construyendo.
En este modelo, el desarrollo de un sistema inteligente se divide en cuatro fases:

Anlisis de requisitos. Una cuestin fundamental a la que hay que responder antes de
desarrollar un sistema es la siguiente:es de utilidad el sistema? (OKeefe, 1989). Es
muy importante fijar desde el inicio cul es el problema a resolver, cules son los
potenciales usuarios y cul es el impacto que tendr el sistema en la organizacin (un
sistema que funcione perfectamente, pero que no se adapte a la forma de realizar las
tareas por los usuarios, no tendr ningn valor, porque no ser usado). Por ello es
necesaria una fase de definicin de requisitos en los que se especifiquen cuestiones
como: qu tipo de problemas se quieren resolver o en qu entornos se van a ejecutar, etc.
As, el problema a resolver debe ser adecuado para la aplicacin de tcnicas de IA, debe
poder descomponerse en subproblemas de forma que los ingenieros del conocimiento
puedan organizar el conocimiento, etc.
23

Adquisicin del conocimiento. La adquisicin del conocimiento, como sabemos, es un

proceso que consiste en la extraccin de conocimiento de una fuente de experiencia y su
transformacin en un esquema de representacin dado. El conocimiento extrado debe de
ser verificado. Boose (1986) propone la utilizacin de diagramas (grafos, tablas,
jerarquas) que representen el proceso de solucin del problema. Estos diagramas deben
ser presentados al experto para su verificacin. Como veremos ms adelante, muchas
herramientas de construccin de sistemas inteligentes ya presentan la inclusin de
mecanismos para la verificacin automtica del conocimiento.
En esta metodologa se trata de forma distinta el anlisis de requisitos y la adquisicin
del conocimiento. Sin embargo, existen metodologas que tratan de cubrir elementos de
ambas fases. Una de estas metodologas es KADS (Wielinga et al., 1992), desarrollada
en Europa al amparo del proyecto ESPRIT. En KADS el conocimiento es estructurado
en cuatro niveles: un nivel del dominio que consiste en hechos bsicos, conceptos y
relaciones; un nivel inferencial que describe los procesos de resolucin de problemas de
una manera declarativa; el nivel de tareas que incluye descripciones procedimentales de
las tareas que pueden llevarse a cabo utilizando partes del nivel inferencial, y un nivel
estratgico que suministra modelos de resolucin de problemas complejos y los
relaciona con el entorno. Este ltimo nivel a menudo no ha sido considerado por los
ingenieros del conocimiento, y es un problema que est en fase de investigacin.
Vindolo de forma conjunta podemos decir que el nivel estratgico controla diversas
tareas que aplican inferencias que utilizan hechos y relaciones del dominio.
Los autores de KADS citan que, en sus primeros intentos, su metodologa de adquisicin
segua un modelo en cascada (Barthlemy et al., 1987), pero posteriormente se sustituy
por una metodologa en espiral (Taylor et al., 1989).

Prototipado. El desarrollo incremental del sistema a travs de una serie de prototipos

permite que en cada ciclo se fijen los requisitos a cumplir, as como un mejor
conocimiento de los objetivos del sistema y de las expectativas de los usuarios. Lee y
OKeefe presentan la estructura de prototipos propuesta por Waterman (1986). Sin
embargo, para que la construccin de prototipos sea efectiva, es necesario realizar una
validacin de los mismos. Para ello tenemos muchas tcnicas, y la eleccin de la ms
adecuada depender de las caractersticas del sistema, de las caractersticas del dominio
24

de aplicacin y de la etapa de desarrollo en que nos encontremos. As, por ejemplo, en

los primeros prototipos primar la verificacin automtica del cdigo, posteriormente se
realizarn tests con casos de prueba y tests de Turing. Cuando el sistema est ms
evolucionado se realizarn tests de campo, y cuando el prototipo constituya un modelo
de produccin pueden utilizarse tcnicas como el grupo de control, y recoger datos para
futuras validaciones orientadas al uso. Todas estas tcnicas las veremos con ms detalle
ms adelante en este mismo libro.

Implementacin y mantenimiento. Una vez hemos desarrollado un prototipo de un

sistema inteligente tenemos dos posibles opciones: (a) utilizar el prototipo como una
fuente de especificaciones, o (b) ms normalmente, evolucionar el prototipo hasta
convertirlo en un sistema de produccin implementado.

Cuando el sistema est ya operativo se debe monitorizar, se debe comprobar su

concordancia con los requisitos, y se debe documentar la utilizacin del mismo en el
dominio de aplicacin incorporando, si fuera necesario, los nuevos requisitos de diseo que
puedan surgir.
El mantenimiento tambin requiere realizar tareas de validacin, lo que Adrion et al. (1982)
denominaban tests regresivos. Estos tests se basan en la ejecucin de casos antiguos para
detectar contradicciones entre el conocimiento ya existente y el nuevo conocimiento
introducido, y asegurar de esta forma la robustez del sistema. En muchas ocasiones los casos
antiguos pueden no tener validez porque los lmites del sistema han cambiado.

3. Anlisis del Comportamiento de los Sistemas Inteligentes

Ya hemos mencionado antes que un sistema inteligente es, al mismo tiempo, un software
convencional y un modelo del conocimiento humano. La verificacin y la validacin de la
parte software puede ser realizada siguiendo la metodologa de la ingeniera del software,
pero la parte propiamente heurstica del sistema necesita tcnicas particulares.
A pesar de que en la ingeniera del software trminos como validacin o verificacin estn
bastante bien definidos, al intentar adaptar estos mismos trminos a la ingeniera de
conocimiento el consenso encontrado no es tan grande. As, a pesar de que se han hecho
intentos para unificar la terminologa (Hoppe y Meseguer, 1993), lo normal es que cada
25

autor desarrolle su propia definicin de verificacin y validacin. En todo caso, y an

considerando las diferencias que podamos encontrar entre las distintas definiciones, siempre
existe una parte comn que podemos extraer de todas ellas y que intentaremos resaltar en
este apartado.
En primer lugar es importante destacar que, aunque la V&V constituye la primera parte del
anlisis de comportamiento de un sistema inteligente, existen tambin fases posteriores. As,
el anlisis de comportamiento puede verse como una pirmide basada en la verificacin y
validacin, a partir de las cuales se desarrollan una serie de actividades que permiten
asegurar la calidad del sistema. En la figura que sigue, las fases posteriores a la V&V se han
agrupado bajo el trmino evaluacin.

Evaluacin

Validacin

Verificacin

Laverificacines,segnBoehm(1981),lacomprobacindequeestamosconstruyendoel
productocorrectamente.Alahoradetratarsistemasinteligentesestadefinicinseformula
deformadistinta,comoporejemplocomprobarqueelsistemanotieneerroresycumple
susespecificacionesiniciales.
La validacin, tambin segn Boehm (1981), es la comprobacin de que estamos
construyendo el producto correcto. Lo que, expresado en trminos de sistemas inteligentes
significa comprobar que la salida del sistema es la correcta y que se cumplen las
necesidades y los requisitos del usuario.
Muchos autores incluyen una o varias fases despus de la validacin, comnmente
agrupadas bajo el trmino evaluacin, que se encargaran de analizar aspectos que van ms
all de la correccin de las soluciones finales. As la evaluacin se encargara de analizar
26

aspectos como utilidad, robustez, velocidad, eficiencia, posibilidades de ampliacin,

facilidad de manejo, etc.
La fase de evaluacin es quiz la menos estudiada de las tres, principalmente porque se
supone que para llegar a ella se ha realizado una verificacin y una validacin satisfactorias
y el sistema est en sus ltimas etapas de desarrollo.

4. Verificacin de Sistemas Inteligentes

Ya hemos comentado que con la verificacin se pretende comprobar que el sistema
desarrollado cumple sus especificaciones de diseo, y que el software no contiene errores.
La verificacin es la fase ms estudiada en el mbito del anlisis del comportamiento de los
sistemas inteligentes, y es la que ms se parece a la correspondiente fase de verificacin,
clsicamente efectuada en ingeniera del software.
De acuerdo con lo argumentado hasta ahora, y considerando los elementos y caractersticas
diferenciales de los sistemas inteligentes, el proceso de verificacin incluye las siguientes
tareas: (a) verificacin del cumplimiento de las especificaciones, (b) verificacin de los
mecanismos de inferencia, y (c) verificacin de la base de conocimientos.

Verificacin del Cumplimiento de las Especificaciones

El anlisis de las especificaciones puede ser llevado a cabo por los desarrolladores, por los
usuarios, por los expertos, o por un grupo de evaluadores independientes. En el software
convencional este proceso est cada vez ms automatizado gracias a la aparicin de las
herramientas de ingeniera del software asistida por ordenador (CASE). Sin embargo, la
inclusin de estas herramientas en el mbito de la ingeniera del conocimiento es lenta, y no
est exenta de problemas.
Segn Gonzlez y Dankel, las cuestiones ms importantes que se deben abordar en este
proceso consisten en comprobar si:

Se ha implementado el paradigma de representacin del conocimiento adecuado.

Se ha empleado la tcnica de razonamiento adecuada.

27

El diseo y la implementacin del sistema han sido llevados a cabo modularmente.

La conexin con el software externo se realiza de forma adecuada.

El interfaz de usuario cumple las especificaciones.

Las facilidades de explicacin son apropiadas para los potenciales usuarios del sistema.

Se cumplen los requisitos de rendimiento en tiempo real.

El mantenimiento del sistema es posible hasta el grado especificado.

El sistema cumple las especificaciones de seguridad.

La base de conocimientos est protegida ante modificaciones realizadas por personal no

autorizado.

La comprobacin de errores en el sistema inteligente debe referirse a cada uno de sus

componentesprincipales:losmecanismosdeinferenciaylabasedeconocimientos.

Verificacin de los Mecanismos de Inferencia

El uso de herramientas comerciales para el desarrollo de sistemas inteligentes ha reducido la
dificultad de la verificacin de los mecanismos de inferencia, ya que se asume que sta ha
sido realizada por los desarrolladores de la herramienta. As, ahora la responsabilidad del
ingeniero del conocimiento recae fundamentalmente en la eleccin de la herramienta
apropiada.
Sin embargo, esta asuncin de correcto funcionamiento no siempre es cierta (sobre todo en
versiones nuevas de la herramienta). Por ello, para aplicaciones que trabajan en dominios
crticos, el funcionamiento correcto del sistema inteligente debe verificarse a travs de
distintas pruebas.
Muchas veces los problemas que surgen con las herramientas comerciales pueden no ser
causa de errores en su programacin. As, en ocasiones hay que pensar en un
desconocimiento del funcionamiento exacto de la herramienta. Por ejemplo, los
procedimientos de resolucin de conflictos, o los mecanismos de herencia, pueden hacer
28

difcil el seguimiento del curso exacto de la inferencia. De esta forma, aunque el

conocimiento esttico est verificado, el funcionamiento final del sistema puede no ser el
apropiado.
En el supuesto de que decidamos construir nuestros propios mecanismos de inferencia, ser
preciso realizar su verificacin. Como estamos tratando software convencional ya se ha
dicho que un motor de inferencias es bsicamente un programa convencional que incluye un
intrprete y unas estructuras de control-, podemos aplicar para su verificacin las tcnicas
clsicas de la ingeniera del software.
En cualquier caso, Geissman y Schultz (1988) recomiendan la utilizacin, siempre que sea
posible, de mecanismos de inferencia certificados, es decir, aqullos cuyo funcionamiento
correcto haya sido debidamente contrastado. Adems, en caso de utilizar herramientas
comerciales, aconsejan realizar pruebas para comprobar que efectivamente tales
herramientas se comportan como se indica en sus manuales.

Verificacin de la Base de Conocimientos.

La verificacin de la base de conocimientos, a diferencia de la correspondiente a los
mecanismos de inferencia, es plena responsabilidad del ingeniero del conocimiento. Esta
verificacin se basa, generalmente, en el concepto de anomalas. Una anomala es un uso
poco comn del esquema de representacin del conocimiento, que puede ser considerado
como un error potencial (existen anomalas que no constituyen errores y viceversa).
La verificacin de la base de conocimientos no nos asegura que las respuestas de nuestro
sistema sean correctas, lo que nos asegura es que el sistema ha sido diseado e
implementado de forma correcta.
La mayora de los estudios publicados que tratan sobre la verificacin de las bases de
conocimientos se refieren a los sistemas basados en reglas, ya que son los ms ampliamente
utilizados. Por ello en este estudio nos centraremos en este tipo de sistemas. Esto no quiere
decir que los sistemas construidos segn otros paradigmas no necesiten ser verificados , o
que su verificacin no sea posible. As, por ejemplo, Cheng (1989) muestra cmo se llevara
a cabo la verificacin de un sistema inteligente basado en frames. Por otra parte, Shiu
(1997) realiza una verificacin formal de un sistema que utiliza reglas y frames. Kandelin y
29

OLeary (1995) realizan la verificacin de un sistema inteligente que implementa el

paradigma de orientacin a objetos.
Los aspectos que se suelen examinar a la hora de verificar una base de conocimientos son la
consistencia y la completitud. A continuacin comentaremos una serie de pruebas que se
realizan para comprobar que la base de conocimientos es consistente y completa. En
principio supondremos que los sistemas no manejan incertidumbre, luego veremos cmo la
inclusin de incertidumbre puede afectar a las pruebas desarrolladas.

Verificacin de la consistencia
La verificacin de la consistencia de la base de conocimientos consiste en la deteccin de
reglas redundantes, reglas conflictivas, reglas englobadas en otras, reglas circulares, y
condiciones IF innecesarias.

Reglas redundantes
Existen dos tipos de redundancias, por un lado redundancias sintcticas, que ocurren cuando
dos reglas tienen las mismas premisas y alcanzan idnticas conclusiones:
p(x) q(x) r(x)
q(x) p(x) r(x)
Por otro lado tenemos redundancias semnticas, que ocurren cuando las premisas o las
conclusiones de una regla no son idnticas en la sintaxis, pero s en el significado.
p(x) q(x) r(x) = Tormenta
q(x) p(x) r(x) = Actividad Elctrica
Las redundancias semnticas son menos comunes que las sintcticas, pero tambin son ms
difciles de detectar.
Las redundancias no causan necesariamente problemas lgicos, aunque pueden afectar a la
eficiencia del sistema (Suwa et al., 1982). Sin embargo, los problemas pueden aparecer
cuando, en futuras versiones del sistema, se cambie una regla pero no la otra.
30

Reglas conflictivas
Dos reglas son conflictivas cuando sus premisas son idnticas pero sus conclusiones son
contradictorias.
p(x) q(x) r(x)
p(x) q(x) r(x)
No siempre que las premisas de dos reglas sean idnticas podemos decir que ha ocurrido un
conflicto. As, por ejemplo, si la conclusin es un atributo multivaluado, podemos estar
tratando de establecer la probabilidad de aparicin de las distintas hiptesis. Tambin puede
suceder que el atributo est tomando, a la vez, varios valores (i.e. una persona puede ser
alrgica a varias substancias o haber sido infectada por varios organismos).

Reglas englobadas en otras

Una regla est englobada en otra si las dos reglas tienen las mismas conclusiones, pero una
de ellas tiene restricciones adicionales en la premisa.
p(x) q(x) r(x)
p(x) r(x)
En este caso la regla con ms restricciones en la premisa est englobada dentro de la que
tiene menos. En las estrategias de resolucin de conflictos entre las reglas se podra intentar
ejecutar primero la regla ms especfica, y en caso de no ser posible, ejecutar la regla ms
general.

Reglas circulares
Un conjunto de reglas es circular si el encadenamiento de las mismas forma un ciclo, es
decir, se comienza por una determinada condicin y que al final del razonamiento volvemos
de nuevo a la misma condicin.
p(x) q(x)
31

q(x) r(x)
r(x) p(x)
Los conjuntos de reglas circulares pueden provocar que el sistema caiga en un bucle infinito
durante su ejecucin, salvo que se incluya algn mecanismo para evitarlo.

Condiciones IF innecesarias
Una condicin IF innecesaria existe cuando dos reglas tienen idnticas conclusiones, una
premisa de una regla est en contradiccin con una premisa en la otra regla, y el resto de
premisas son equivalentes.
p(x) q(x) r(x)
p(x) q(x) r(x)
En este caso las dos reglas pueden resumirse en una que contemple slo las premisas
equivalentes.
p(x) r(x)
Puede haber situaciones especiales en la que una condicin IF innecesaria no implique
necesariamente que se unan las dos reglas. As por ejemplo en el conjunto de reglas:
p(x) q(x) r(x)
q(x) r(x)
el problema quedara resuelto eliminando la condicin IF innecesaria de la primera regla
pero manteniendo intacta la segunda regla:
p(x) r(x)
q(x) r(x)

32

Verificacin de la completitud
Frecuentemente ocurre que el proceso de adquisicin de conocimiento a partir de fuentes de
experiencia no es completo, lo que puede producir huecos en el conocimiento adquirido.
Existen una serie de situaciones tpicas que pueden ser indicativas de un hueco en la base
de conocimientos, como son valores no referenciados de atributos, valores ilegales de
atributos, reglas inalcanzables, o reglas sin salida. Veamos estos casos ms
detalladamente.

Valores no referenciados de atributos

Esta situacin ocurre cuando algunos valores, del conjunto de posibles valores de un
atributo, no son cubiertos por la parte IF de ninguna regla. Por ejemplo, si tenemos el
atributo Temperatura cuyo rango de posibles valores es {alta, normal, baja} de forma
que los valores alta y normal aparecen en la parte IF de alguna regla, pero el valor
baja no est representado en el antecedente de ninguna regla de la base de conocimientos,
estamos ante una situacin de valores no referenciados de atributos.
Un atributo parcialmente cubierto puede impedir que el sistema alcance una conclusin, o
puede provocar conclusiones errneas cuando el valor no cubierto aparece en la ejecucin.
Este error puede indicar la falta de alguna regla en la base de conocimientos.

Valores ilegales de atributos

Esta situacin ocurre cuando una regla hace referencia a valores de atributos que no estn
incluidos en el conjunto de valores vlidos para ese atributo. Por ejemplo, si el conjunto de
valores vlidos de Temperatura es {alta, normal, baja} y encontramos condiciones del
tipo Temperatura = muy alta o Temperatura = algo baja, tanto en premisas como en
conclusiones, estamos ante una situacin de valores ilegales de atributos.
Este error es causado, generalmente, por equivocaciones en la escritura, aunque tambin
puede ser indicativo de que el conjunto de valores vlidos del atributo es incompleto.

33

Reglas inalcanzables
En un sistema inteligente que utiliza una bsqueda regresiva dirigida por las metas-, una
regla es inalcanzable si la conclusin de la regla no aparece en el objetivo a buscar, y no
aparece en la condicin IF de otra regla. Por ejemplo la regla IF Temperatura > 37 THEN
Fiebre sera inalcanzable si Fiebre no aparece en el objetivo buscado ni en la condicin
IF de otra regla.
En caso de que el razonamiento fuese dirigido por los datos, la regla sera inalcanzable si sus
premisas no pueden ser obtenidas del exterior (por ejemplo, preguntndole al usuario), y no
aparecen como conclusin de ninguna regla. Siguiendo con el ejemplo anterior, la regla IF
Temperatura > 37 THEN Fiebre sera inalcanzable si el valor de Temperatura no puede
ser actualizado desde el exterior, ni aparece como conclusin de alguna otra regla.
Esta situacin puede afectar a la eficiencia del sistema pero nunca a su salida (ya que la
regla con la conclusin inalcanzable nunca ser disparada). Una causa muy comn de este
tipo de situaciones son errores en la terminologa. As, por ejemplo, la conclusin Fiebre
podra aparecer en la parte IF de una regla de la siguiente forma:
IF Temperatura_Elevada THEN ...
en donde los trminos Temperatura_Elevada y Fiebre son sinnimos para el experto,
pero no para el sistema inteligente.

Reglas sin salida

Estecasoestdirectamenterelacionadoconelanalizadoenelpuntoanterior.Unaregla
inalcanzableparaunrazonamientodirigidoporlasmetasesunareglasinsalidaparaun
razonamientodirigidoporlosdatos.Delamismaforma,unareglainalcanzableparaun
razonamientodirigidoporlosdatosesunareglasinsalidaparaunrazonamientodirigido
porlasmetas.

Influencia de las Medidas de Incertidumbre

Los procedimientos vistos hasta ahora para verificar la consistencia y la completitud son
vlidos, siempre y cuando los sistemas no incluyan incertidumbre. Cuando existe
34

incertidumbre, la validez de estas pruebas es dudosa, ya que en estos casos pueden aparecer
situaciones normales que sean interpretadas como errores.
En sistemas que pretenden trabajar con incertidumbre, o con grados de asociacin
(utilizando factores de certeza, probabilidades bayesianas, o cualquier otro mtodo) tambin
es importante verificar cuestiones como la consistencia, la completitud, la correccin, y la no
redundancia. Estas tareas se realizan, en primer lugar, asegurndonos de que cada regla
incluye un factor de incertidumbre (o cualquier otra medida de caractersticas similares), y
que estos factores cumplen las restricciones impuestas por la teora o modelo en que se
basan.
La bsqueda de anomalas en las medidas de incertidumbre de un sistema inteligente es un
proceso que no ha recibido mucha atencin por parte de los investigadores, quiz debido al
limitado nmero de sistemas inteligentes que hacen un uso extensivo de las medidas de
incertidumbre. Un ejemplo de verificacin de este tipo aparece publicado en un trabajo que
OLeary (1990) desarroll en sistemas que seguan el esquema bayesiano. El modo en que el
uso de medidas de incertidumbre tambin puede afectar a la realizacin de los tests de
consistencia y completitud puede verse en los siguientes ejemplos (Nguyen et al., 1987):

Redundancia: Si antes la redundancia no afectaba a la salida del sistema ahora puede

causar graves problema ya que, al considerar la misma informacin dos veces, pero con
distintos valores, se pueden modificar los pesos de las conclusiones.

Reglas englobadas en otras: Esta situacin puede no ser errnea ya que las dos reglas
pueden indicar la misma conclusin pero con distintas confianzas. La regla englobada
sera un refinamiento de la regla ms general para el caso de que tengamos ms
informacin.

Condiciones IF innecesarias: Igual que en el caso anterior, una condicin IF innecesaria

puede utilizarse para variar la confianza en la conclusin final.

Reglas circulares: Pueden existir casos en los que la utilizacin de medidas de

incertidumbre rompan la circularidad de un conjunto de reglas. Por ejemplo, si el factor
de certidumbre de una conclusin implicada en el ciclo cae por debajo de un umbral

35

por ejemplo 0.2-, se considera que el valor de la conclusin es desconocido y el ciclo

se rompe.

Reglas sin salida: La deteccin de este tipo de reglas se complica con la introduccin
de incertidumbre. As, una regla puede convertirse en una regla sin salida si su
conclusin tiene una certidumbre por debajo del umbral en el cual un valor se considera
conocido. Por ejemplo, la siguiente cadena de reglas:
R1

R2

R3

A 0.4 B 0.7 C 0.7 D

podraparecervlida,sinembargosiAseconocecontotalcertidumbre,elfactorde
certezadeDdespusdeunrazonamientoprogresivosera0.40.70.7=0.196,valor
que cae por debajo del umbral antes mencionado. En este caso el valor de D sera
desconocidoylalneaderazonamientoacabaraenunpuntosinsalida.

Reglas inalcanzables: de forma similar al ejemplo anterior pueden existir reglas que, por
causa de los factores de certeza, se convierten en inalcanzables. Si consideramos el
siguiente conjunto de reglas:
R1

R2

A 0.1 B 1 C

la regla R2 sera inalcanzable en un razonamiento progresivo (aunque su premisa

apareceenlaconclusindeotraregla)porqueelvalordeBcaepordebajodelumbralde
0.2.

Verificacin Dependiente del Dominio

El tipo de verificacin que hemos visto hasta ahora se denomina independiente del dominio
porque no es especfico de ningn dominio en particular. Se basa, como hemos visto, en una
deteccin de anomalas que pueden ser errores o no. Esta bsqueda de anomalas se realiza
normalmente a travs de aproximaciones heursticas.
Sin embargo, existe un tipo de verificacin que es dependiente del dominio (OKeefe y
OLeary, 1993). Este tipo de verificacin emplea metaconocimiento del dominio para

36

examinar la base de conocimientos. El metaconocimiento se define como el conocimiento

que el sistema tiene acerca de su propia estructura.
El primer ejemplo de esta tcnica (y tambin el mejor conocido) aparece con los trabajos de
Davies (1976) en TEIRESIAS, un sistema que se encargaba de verificar la introduccin de
conocimiento nuevo en el sistema experto MYCIN.
Un ejemplo de la verificacin dependiente del dominio podra ser el siguiente: supongamos
que dado un hipottico sistema, y una situacin, nuestro metaconocimiento nos puede
indicar las caractersticas del saln de una casa. El proceso de verificacin puede detectar
que el saln est incompleto si no hemos puesto un sof, pueden existir redundancias si
hemos puesto ms de un sof, puede haber incorrecciones si hemos puesto el lavabo en la
sala y pueden existir inconsistencias si ponemos un sof y una silla, y a ambos los
denominamos sof. Como vemos, todo el proceso de anlisis se basa en el conocimiento
previo que tenemos sobre cmo debera ser un saln.
Sin embargo, a pesar de las ventajas evidentes que supone utilizar metaconocimiento en la
verificacin, existen una serie de inconvenientes que limitan su aplicacin prctica:

El metaconocimiento tiene que ser verificado (ya que tambin es conocimiento).

El metaconocimiento puede no ser estable, o puede no ser prctico actualizarlo con

frecuencia.

En general, el desarrollo de una aproximacin dependiente del dominio puede ser

bastante costosa debido a los costes de adquirir y mantener el metaconocimiento.

Por estas razones la mayora de los sistemas se verifican con una aproximacin
independiente del dominio.

5. Aspectos Generales de la Validacin de Sistemas Inteligentes

Yahemosmencionadoquelavalidacinconsisteencomprobarsiestamosconstruyendoel
productocorrecto;loquerequiereexaminarlavalidezdelosresultadossuministradosporel
sistemasoncorrectos,ylaconstatacindelcumplimientodelasnecesidadesy requisitos
delusuario.
37

La comprobacin sobre la validez de los resultados del sistema recibe habitualmente el

nombredevalidacinorientadaalosresultados(LeeyOKeefe,1994).Elobjetivoaques
compararelrendimientodelsistemaconunrendimientoesperadoproporcionadoporuna
referenciaestndaroporexpertoshumanos,ycomprobarqueelsistemaalcanzaunnivel
queseconsideraaceptable.
Existetambin otrotipodevalidacin, denominada validacin orientadaaluso,quese
centraencuestionesquehacenreferenciaalacalidaddelarelacinhombremquina,ms
alldelacorreccindelosresultadosobtenidosporelsistema.Estetipodevalidacinse
suelecitarenlaliteraturaconeltrmino assessment (OLeary,1987),queencastellano
podramosinterpretarcomovaloracin.
Enlavalidacinorientadaalusoseanalizanaspectoscomolafacilidaddeutilizacindel
sistema, la calidad del dilogo hombremquina, la calidad de la implementacin, la
adecuacin y la eficiencia del hardware, etc. Algunos autores, como Liebowitz (1986),
presuponen que la fase de validacin se orienta nicamente hacia la correccin de los
resultados. En este casola validacin orientada al uso seincluira dentro dela fase de
evaluacin. Liebowitz tambin propone una metodologa denominada AHP (Analytical
HierarchyProcess)pararealizarlavalidacinorientadaaluso.
Normalmente lavalidacin orientadaalosresultados constituyeunprerrequisito parala
realizacindeunavalidacinorientadaaluso.As,siunsistemanopresentaunrendimiento
aceptableoalmenosindicacionesdequeelrendimientomejorarenunfuturoalincluir
mejoraseneldesarrollo,losaspectosqueconciernenalavalidacinorientadaalusoson
irrelevantes.Porestemotivoenestetrabajonoscentramosbsicamenteenelestudiodela
validacinorientadaalosresultadosalaque,apartirdeahora,denominaremossimplemente
comovalidacin.
Antes de describir y proponer una metodologa concreta, parece conveniente sealar y
discutir algunas de las caractersticas principales del procesode validacin. Al respecto
destacaremoslassiguientes:

Personal involucrado en la validacin.

38

Partes del sistema a validar.

Datos utilizados en la validacin.

Criterios de validacin.

Momento en el que se realiza la validacin

Mtodos de validacin

Errores cometidos en la validacin.

Personal Involucrado en la Validacin

Una cuestin importante a determinar en todo tipo de validacin es quin va a llevarla a
cabo. El primer elemento a considerar es el ingeniero de conocimiento que ha desarrollado
el sistema, ya que es quien mejor conoce las caractersticas del sistema inteligente. Sin
embargo, la inclusin sin matices del ingeniero del conocimiento en el proceso puede afectar
a la objetividad del estudio. Ello puede ser debido a que el ingeniero de conocimiento ha
dedicado mucho esfuerzo en el desarrollo del sistema y puede sentirse inclinado a
sobrevalorar los resultados del mismo. De todas formas, en la validacin siempre es
necesaria la presencia de una persona que tenga un conocimiento amplio del sistema, aunque
no sea su constructor.

Ingeniero del
conocimiento

Experto
humano

Evaluadores
independientes

Validacin del
sistema

Usuarios
finales

39

Tambinesnecesariocontarconexpertoshumanos.Comoveremos,elmtodobsicopara
realizarlavalidacineselanlisisdecasosdepruebayaresueltos.Estoscasoshabrnsido
analizadostambinporexpertoshumanosconlosquepodremosestudiarlasdiscrepancias
encontradas.Generalmenteesconvenientequelosexpertosqueparticipenenlavalidacin
noseanlosmismosquecolaboraneneldesarrollodelsistema.Conestamedidaseintenta
conseguirqueelconocimientodelsistemaseadecealdeunconsensodeexpertos,yno
sloalconocimientodelexpertoquehacolaboradoensudiseo.
Relacionadaconlanecesidaddeindependenciaenlavalidacinsurgelaideadehacerrecaer
todaslasresponsabilidadesenungrupodeexpertosindependientequeOKeefeyOLeary
(1993)denominantercerosexpertos.Sinembargo,sielconstructordelsistemapoda
sobrevalorarsuproducto,laparticipacindeungrupohumanodevalidacintotalmente
independiente puede provocar el efecto contrario (Buchanan y Shortliffe, 1984). Esta
situacineslaqueChandrasekaran(1983)describicomolafalaciadelsuperhombre:se
leexigemsalsistemainteligentedeloqueseleexigiraaunexpertohumano,teniendoen
cuenta que el conocimiento del sistema inteligente es simplemente un modelo del
conocimientodelosexpertoshumanos.
Tambinpuedenaparecerproblemassilosevaluadoresnoaceptanfcilmentelautilizacin
desistemasinteligentesensureadetrabajo,osilasolucinpropuestaperteneceauna
escueladepensamientodiferentealasuya.Comoveremosposteriormente,paraevitar
subjetividadesenelprocesodevalidacin,sepuedenllevaracaboloquesedenominan
estudiosciegos.
Los usuarios finales del sistema tambin pueden participar en el proceso de validacin; sin
embargo, puede ocurrir que la experiencia de los mismos no sea suficiente para realizar la
validacin del sistema inteligente. Por ello generalmente su labor se destina a una validacin
orientada al uso.

Partes del Sistema que Deben Ser Validadas

Nuestroprincipalobjetivoeslograrquelosresultadosfinalesdelsistemainteligentesean
correctos.Sinembargo,tambinpuedeserinteresanteanalizarsilosresultadosintermedios
40

del sistema son correctos, o si el razonamiento seguido hasta dar con la solucin es
apropiado.
La validacin de los resultados intermedios puede ser interesante porque los resultados
finales dependen de ellos. As, el anlisis de dichos resultados intermedios nos da una
descripcindelfuncionamientointernodelsistemaynospermiteunarpidacorreccinde
loserrorescometidos.
Tambin puede resultar apropiado validar las estructuras de razonamiento; es decir,
comprobarqueelsistemaalcanzalarespuestacorrectaporlasrazonescorrectas(Gaschnig
et al., 1983). Un proceso de razonamiento incorrecto puede provocar errores cuando
queramosampliarnuestrabasedeconocimientos (Chandrasekaran,1983).Enestecasolo
quesepretendeesemularelprocesoderazonamientoquerealizanlosexpertoshumanos.
Deestaformalosusuariosdelsistemaencontrarnmsagradablesuutilizacinalseguir
unalnealgicaalahoradeplantearlascuestiones.
Para ver con ms claridad lo que acabamos de comentar, consideremos el siguiente ejemplo:
sea un paciente en una unidad de cuidados intensivos, en la cual estamos monitorizando
constantemente sus datos gasomtricos. Adems contamos con las caractersticas del
contexto particular de su caso. Con estos datos intentamos interpretar su balance cido-base
a travs de un sistema inteligente. En la figura podemos observar que, ante un caso
determinado, se ha producido un error y el resultado no es el esperado.

SISTEMA EXPERTO

Datos

Gasometras
pCO2 = 48 mmHg
pH
= 7.32
[HCO3] = 17 mg / l
Contexto

Paciente

No presenta fallo
renal

Razonamiento

Resultado
(Balance cido-base)
ACIDOSIS METABLICA

Valor esperado
ACIDOSIS METABLICA Y
RESPIRATORIA

41

Analizando los resultados intermedios vemos que el error es debido a un fallo en la

interpretacin del pCO2 producido por una errata en una de las reglas que determina el
estado del pCO2, como se muestra en la figura siguiente.

IF pCO2 > 50 mmHg THEN Estado_pCO2 = ALTO

IF pCO2 > 46 mmHg THEN Estado_pCO2 = ALTO

Gasometras
pCO2 = 48 mmHg
pH
= 7.32
[HCO3] = 17 mg / l
Contexto

Resultado
(Balance cido-base)
ACIDOSIS METABLICA Y
RESPIRATORIA

SISTEMA EXPERTO
Resultados intermedios

Razonamiento
previo

Estado_pCO2 = Normal
Alto
Estado_pH
= Bajo
Estado_HCO3 = Bajo

Razonamiento
final

No presenta fallo
renal

=
Valor esperado
ACIDOSIS METABLICA Y
RESPIRATORIA

Corregido el error las conclusiones del sistema son correctas. Sin embargo, si analizamos los
procesos de razonamiento empleados vemos que en la determinacin del estado del [HCO 3]
no se ha tenido en cuenta el hecho de que el paciente presente o no Fallo Renal. La
presencia de fallo renal puede alterar los valores normales del [HCO 3], si en nuestro
estudio no aparece ningn caso con esta patologa el sistema parecer funcionar
perfectamente, pero sus conclusiones sern errneas en el momento que aparezca un
paciente con fallo renal, como se muestra en la figura.

Resultado
(Balance cido-base)

SISTEMA EXPERTO
Gasometras
pCO2 = 48 mmHg
pH
= 7.32
[HCO3] = 17 mg / l
Contexto

ACIDOSIS METABLICA Y
RESPIRATORIA

Resultados intermedios
Razonamiento
previo

Estado_pCO2 = Alto
Estado_pH
= Bajo
Estado_HCO3 = Bajo

=
Razonamiento
final

No presenta fallo
renal

Valor esperado
ACIDOSIS METABLICA Y
RESPIRATORIA

IF [HCO3] < 18 mg / l THEN Estado_HCO3 = BAJO

IF (([HCO3] < 18 mg / l) and (no Fallo Renal)) or

(([HCO3] < 16 mg / l) and (Fallo Renal))

THEN Estado_HCO3 = BAJO

42

Conesteejemplohemospretendidoilustrarcmoelanlisisdelosresultadosintermedios
puedeayudaraladeteccindeerroresenlasconclusionesfinales,ycmounaestructurade
razonamiento inadecuada en este caso incompleta puede parecer correcta, pero dar
problemascuandoelmbitodetrabajoseamplaenestecasocuandoaparecenpacientes
confallorenal.

Casustica de la Validacin
Elusodecasosdepruebaeselmtodomsampliamenteutilizadoparalavalidacinde
sistemasinteligentes.Alrespecto,loidealserapodercontarconunagrancantidaddecasos
representativosdeunespectrocompletodeproblemas,datosquefuesenanalizadosporun
grupoms omenos numeroso deexpertos.En larealidad, desafortunadamente, es muy
comnnodisponermsquedeunnmeroreducidodecasosyconpocosexpertosque
colaborenensuanlisis.Paraqueunamuestradecasosseasusceptibledeseraceptadaen
un proceso de validacin debe cumplir dos propiedades fundamentales: cantidad y
representatividad.
Elnmerodecasosempleadosenlavalidacintienequesersuficienteparaquelasmedidas
de rendimiento que obtengamos sean estadsticamente significativas (Chandrasekaran,
1983). Ante esto podemos plantearnos un mtodo muy sencillo de captura de datos: ir
recogiendo todos los casos de que podamos disponer hasta que tengamos un nmero
suficientedeellos.
No obstante hay que considerar otra caracterstica de la muestra como es su
representatividad.Noslohayquecapturarunnmeroelevadodecasos,sinoquestos
debenserrepresentativosdelosproblemascomunesalosquesevaaenfrentarelsistema
experto,aquellosproblemasqueconstituyensudominio.Chandrasekaran (1983)aconseja
queaquellosproblemasqueresuelvaelsistemainteligentedebenaparecerrepresentadosen
loscasosdeprueba.OKeefeetal.(1987)destacanquelacoberturadeloscasosesmucho
msimportantequesunmero,yqueloscasosdebenrepresentarconfiabilidadeldominio
deentradadelsistema.Eldominiodeentradaestconstituidoporaquelloscasosqueson
43

susceptibles de ser tratados por el sistema inteligente, cuanto mayor sea el dominio de
entradamscomplejasehacelavalidacindelsistema.
Para intentar mantener la representatividad de los datos se suelen emplear muestreos
estratificados. As, por ejemplo, supongamos que tenemos un sistema experto mdico a
partir del cual pretendemos obtener tres posibles diagnsticos: A, B y C. Revisando la
historia clnica comprobamos que en este tipo de clasificaciones el diagnstico A ha
aparecidoel80%delasveces,Bel15%yCel5%.Deestaforma,sinuestramuestraest
compuestapor200casos,160deellosdebenperteneceraldiagnsticoA,30aldiagnstico
By10aldiagnsticoC.
Aunque el procedimiento de muestras estratificadas pueda parecer vlido, su utilizacin
tambinhasidoobjetodecontroversias.As,OLeary(1993),presentaelejemplodelos
sistemas expertos que analizan las probabilidades de bancarrota en firmas comerciales
estadounidenses.Enunaoseproducensloentreun3yun5%debancarrotas,loque
significaqueenunamuestraestratificadaunacantidadcercanaal96%loconstituirncasos
pertenecientesafirmascomercialesquenohansufridounabancarrota.Estainundacinde
casos puede provocar que el sistema obtenga tasas de acierto elevadas an cuando sus
capacidadesparapredecirunabancarrotanoseanadecuadas.Entalescasospuederesultar
adecuadoestablecerunamuestraequilibrada,enlaqueelnmerodecasosdebancarrotasea
similaralnmerodecasosenlosquenosehaproducidounabancarrota.
Tambinpuedeocurrirqueelexpertoestinteresadoencomprobarlarespuestadelsistema
antecasosextraosycomplejosque,siempleramosunamuestraestratificada,apareceran
enunaproporcinminscula.Entalcasolamuestradebevariarseparaacogerunnmero
representativodecasosdeltipoespecificado.
Otroproblemaquepuedeapareceresquenoseaposibledisponerdecasosdepruebapara
validarelsistema.Hayquerecordarqueenlavalidacinsiempreesaconsejablenoutilizar
aquelloscasosquesehanutilizadoeneldiseo delsistemayaque,previsiblemente,el
sistemahabrsidoadaptadoparatratarestoscasosadecuadamente.
Unasolucinalacarenciadecasoseslautilizacindecasossintticos,esdecir,casos
generados artificialmente por los expertos. El problema con esta aproximacin es que
44

demanda una considerable objetividad por parte de los evaluadores siempre es una
tentacingenerarcasosqueresaltenlospuntosfuertesdelsistema.
Apesardetodoslosproblemascomentados,elestudiodecasosdepruebaresultaadecuado
paralavalidacindesistemasinteligentesporqueseadaptaperfectamentealosmtodosde
desarrolloincremental.Podemospartirdeunconjuntodecasoslimitadopararealizarla
validacindelasprimerasetapasdedesarrolloy,amedidaqueelsistemasevayaampliando
ysedesarrollennuevosaspectosfuncionales(siempredeacuerdoconlaespecificacinde
requisitosyelalcancedeldominio),podemoscapturarnuevoscasosdepruebaparavalidar
las nuevas capacidades del sistema. Despus de una modificacin importante podemos
volveraanalizarcasosyaresueltosparacomprobarsialgn efectolateral haprovocado
erroresque,antesdelamodificacin,noaparecan.
La casustica empleada en la validacin del sistema debe incluir dos tipos de datos: por un
lado las caractersticas de cada caso en particular y, por otro lado, un criterio que permita
identificar el tipo de caso que estamos tratando. A continuacin, el proceso de validacin
podra plantearse del siguiente modo:

Obtencin de la casustica de validacin.

Los datos de la casustica son transferidos al sistema inteligente, que se encarga de

interpretarlos.

Los resultados del sistema y el criterio de validacin que acompaa a los datos sirven de
entrada para un proceso de validacin en el que se analizar el rendimiento del sistema
inteligente.

Aunque el proceso pueda parecer sencillo aparecen cuestiones importantes, que a veces son
difciles de resolver. Por ejemplo: qu utilizamos como criterio de validacin?, quin
asocia cada caso de prueba con una interpretacin (o categora de interpretaciones) en
particular?. Al respecto, podemos diferenciar dos tipos de validacin atendiendo al tipo de
criterio establecido: validacin contra el experto y validacin contra el problema (Gaschnig
et al., 1983).

45

Validacin contra el Experto

La validacin contra el experto consiste, bsicamente, en utilizar las opiniones y las
interpretacionesdeexpertoshumanoscomocriteriodevalidacin.Estetipodevalidacines
el ms comnmente empleado en los sistemas inteligentes despus de todo, lo que
pretendemos es construir un modelo del conocimiento del experto humano, por lo que
resultalgicoutilizaralosexpertoscomounamedidadeldesempeodenuestrosistemaen
lavalidacin.
Sin embargo, la validacin contra el experto no est exenta de problemas, generalmente
debidos a la propia naturaleza del conocimiento. As, puede ser comn que expertos de un
mismo nivel concluyan soluciones diferentes ante el mismo problema. Incluso un mismo
experto puede tener actitudes diferentes, ante un mismo caso, segn las condiciones del
momento en que fue realizado el anlisis. Las causas de estas discordancias pueden ser:

Factores externos: estrs, cansancio, etc.

Los expertos pueden no ser independientes y estar influidos por otro de mayor categora
profesional, o de mayor prestigio, o de mayor poder, etc.

Ambigedades o errores en la adquisicin de los datos pueden provocar que los expertos
den opiniones diferentes ante los mismos casos.

Los expertos pueden pertenecer a diferentes escuelas de pensamiento.

Tendencias, a favor o en contra, de los sistemas inteligentes pueden hacer variar las
opiniones de los expertos humanos en la validacin

Existen tres posibles tipos de validacin contra los expertos:

Validacin contra un experto.

Validacin contra un grupo de expertos.

Validacin contra un consenso de expertos.

46

La validacin contra un nico experto no es la ms recomendable de todas pero,

desgraciadamente, suele ser bastante comn. Dada la escasa disponibilidad de expertos
humanos, no siempre es posible contar con varios expertos en el proceso de validacin. El
inconveniente de utilizar un nico experto es que la objetividad del estudio es cuestionable.
Una situacin ms deseable a la hora de realizar la validacin es contar con las opiniones de
una serie de expertos humanos. Esto conlleva una serie de ventajas: (1) no estamos ligados a
una nica opinin, que puede ser errnea, y (2) permite comparar el grado de consistencia
existente entre los expertos del dominio.
El principal inconveniente de esta tcnica es cmo medir el rendimiento del sistema
inteligente. Generalmente los expertos no suelen tener la misma cualificacin y se suele
buscar una concordancia elevada con aquellos expertos de mayor nivel. Sin embargo, si los
expertos son todos de un nivel similar generalmente lo que se busca es comprobar que las
interpretaciones del sistema se parezcan a las de los expertos, tanto como las
interpretaciones de los expertos se parecen entre s. Para ello, existen una serie de medidas y
procedimientos estadsticos potencialmente tiles para medir estos acuerdos (medidas de
Williams, anlisis cluster, escalamiento multidimensional y medidas de dispersin y
tendencia) que analizaremos ms adelante.
La otra opcin comnmente empleada en la validacin con expertos, es conseguir unir las
opiniones de varios expertos en una nica opinin. Este consenso tiene la ventaja de que
procura ser lo ms objetivo posible y, si el acuerdo del sistema inteligente con el consenso es
amplio, la confianza en el sistema aumentar considerablemente. El inconveniente de esta
tcnica es que, en cierta manera, estamos volviendo a la tcnica de validacin con un nico
experto, es decir, todo aquello que cae fuera del consenso es considerado errneo. Sin
embargo puede haber otras soluciones vlidas que los expertos podran haber elegido, pero
que han cambiado para adaptarse a un estndar del cual no estn plenamente convencidos
(posiblemente influidos porque un experto de mayor nivel est de acuerdo con el consenso).
Adems, la bsqueda de un estndar o consenso entre los expertos puede ser una ardua tarea.
Entre los distintos mtodos para lograr un consenso a partir de las opiniones devarios
expertos destaca el mtodo Delphi (Sackman, 1974). Este mtodo se caracteriza por el
anonimatoylainteraccinremotadelosparticipantes,superfilretroalimentadoyelusode
metodologasestadsticasenelanlisisdelosresultados,enelquesecombinangeneracin
47

deideasyevaluacin deopciones.EstemtodofuedesarrolladoporlacompaaRAND
comounmtododeprospeccin,ysebasaenlarecopilacindeinformacincualitativa
basadaenjuicios deexpertos.Elmodeloaspiraaeliminarlosefectos indeseables dela
interaccindirectaeliminandoelcontactopersonalentrelosmiembrosdelproyectoque,ni
tansiquiera,conocenlaidentidaddelosdemsmiembrosdelgrupo.
Delphi utiliza un grupo o panel de expertos, seleccionados de acuerdo con su vala
profesionaly enfuncindelanaturalezadelproblema,alqueseenvauncuestionario
completopararecopilarjuiciosacercadeprocesosofenmenosreales,msespecficamente
sobresutendenciaydesarrollofuturo.Todoslosparticipantesformulandemanerasecretae
independientelashiptesiseideasquelessugiereelproblema,quesonenviadasporescrito
al coordinador del proyecto. ste interpreta y consolida los resultados preliminares
hiptesis,reasdeintersenrelacinalproblema,propuestasenunresumenglobaly
annimodecarcterestadsticoyfrecuentementetabular.
Dichoresumenglobalseenva,juntoconinformacinestadstica,alosexpertos,aquienes
sesolicitaque,ensucaso,modifiquensusapreciacionesinicialesorealicenlaspropuestaso
aclaraciones queconsiderenoportunas,teniendoencuentalasrazonesoconsideraciones
expuestasporlosdemsparticipantes.Enlamedidaenquesusapreciacionesdifierandela
opinin predominante del grupo se solicita que aclaren su posicin, lo que permite
incorporarnuevasideasyperspectivasalgrupodedecisin.Tabuladalainformacin,el
coordinadorenvaunnuevoinformealosparticipantesysereiniciaelciclodeconsulta.A
medidaquesteserepite,lasposicionesdelosexpertostiendenaconvergerenlasvariables
y procesos crticos del fenmeno, hasta alcanzar un grado suficientemente amplio de
consenso.
Estemtodosediferenciadelpaneldeexpertostradicional,ensucarcterannimoyenla
realizacindedosomsciclositerativosdeconsulta,loqueleconfieregranpotenciaen
cuantoalageneracindeideasylaorientacinalcompromisologradaporlainformacin
estadstica que se proporciona, al trmino de cada ciclo, a los expertos. Entre sus
deficienciasmssignificativascabedestacarelelevadogradodedependenciaenrelacinal
contenido,laformulacin delaspreguntasenelcuestionarioinicial,ylaseleccindelos
expertos.
48

Existen otros muchos mtodos para lograr un consenso entre varios expertos como el
Brainstorming, las tcnicas de grupos nominales, el AHP, ... (Medsker et al., 1994).
Tambienautorescomo(Xuetal.,1992)hanpropuestomtodosmatemticosparacombinar
informacinprovenientededistintasfuentes.Sinembargoelmtodomspopulardentrode
lossistemasexpertoseselmtodoDelphidebidoasucarcterannimoyasumtodode
realimentacin controlada (Clarke et al., 1994). Podemos encontrar ejemplos de la
utilizacin del mtodo Delphi en la validacin de sistemas inteligente en (Hamilton y
Breslawski,1996)y(RothyWood,1993).

Validacin contra el Problema

Leyendoelapartadoanterior,unapreguntaquecontodaprobabilidadhasurgidoes:qu
pasasilos expertos humanos seequivocan?. As, sipuedeversecomo natural quedos
expertosdiscrepen,tambinpuedesucederqueningunodeelloshayasabidodarconla
solucinrealdelproblema.
Consideremos el ejemplo del sistema MYCIN (Shortliffe, 1976). MYCIN se encargaba de
identificar la bacteria causante de la infeccin de un paciente y sugerir la terapia apropiada a
cada caso. Evidentemente MYCIN puede evaluarse comparando sus diagnsticos con los de
los expertos humanos. Pero tambin podemos comparar los diagnsticos de MYCIN con los
resultados del laboratorio que nos identifican, de forma inequvoca, cual ha sido la bacteria
causante de la infeccin.
Estesegundotipodevalidacindescritosedenominavalidacincontraelproblema,yaque
estamostratandodedescubrirsinuestrosistemaresuelverealmenteelproblemaquelehan
planteado.
Laventajadeestemtododevalidacinesevidente:setratadeunmtodocompletamente
objetivo,lasolucinrealdelproblemaeslaquesemuestra.Sinuestrosistemadiscrepadel
experto pero coincide con la solucin real, la credibilidad del sistema experto se ver
aumentada.
Sinembargoestemtodotambinpresentainconvenientes.Unodeellosesquepodemos
volveracaerenlafalaciadelsuperhombrequehabamosdescritoconanterioridad,es
49

decir,exigirlemsalsistemaexpertodeloqueseleexigiraalunexpertohumano.As,
supongamosunsistemaquepresentaunacuerdodel70%conlasolucinrealdelproblema.
Esteresultadopuedeparecerinadecuado,sinembargo,cuandoanalizamoslosresultadosde
losdistintosexpertoshumanosvemosqueelacuerdodeestosconlasolucinrealtampoco
sobrepasael70%yquesusinterpretacionessonmuysimilaresalasdelsistemaexperto.En
talcasopodremossuponerqueelcomportamientodelsistemaexpertoesaceptableyaquesu
rendimientoessimilaraldelosexpertoshumanosdeldominio.
Otroproblemaquesurgeenlavalidacincontraelproblemaesque,puedenoserposible
obtener una solucin real. Siguiendo con el ejemplo de MYCIN, el sistema experto
aconsejaba una terapia para cada caso, la nica forma de comprobar que la terapia es
adecuadaesprobarlasobreelpaciente.Evidentemente,porrazonesticas,slosepodr
probarunaterapiasobreunpacientesicoincideconlaterapiaquehaprescritoelexperto
humano(loquelimitabastanteelestudio).Ademselhechodequeelpacienteevolucione
bienpuedenoserindicativodequelaterapiaaplicadaeslamejor(puedeexistirotraque
hagaevolucionaralpacientemsdeprisayconmenossufrimiento).Portodosestosmotivos
lavalidacindeMYCINserealizcontralosexpertosynocontraelproblema(Yuetal.,
1979).
OKeefeetal.(1987)tambinrecomiendanlavalidacincontraexpertoshumanos,aunque
indicaque,siestdisponiblelasolucinrealdelproblema,suutilizacindentrodelproceso
devalidacinpuedeproporcionarinformacinmuyinteresante.

Momento en el que se Realiza la Validacin

Otroproblemaquesurgealahoradeplantearlavalidacines:cundorealizarla?.Ante
esta cuestin podemos encontrarnos dos posturas diferentes: por un lado Bachant y
McDermott(1984)adviertenquevalidarunsistemaquenoestcompletopuedenosertil,
yaquestenoposeetodoelconocimientonecesarioparaestablecerdecisionescorrectas.
PorotroladoBuchananyShortliffe(1984)recomiendanrealizarlavalidacinalolargode
todoeldesarrollodelsistema.
Comohemosvistoaldescribirlasdistintasmetodologasdelaingenieradelconocimiento,
elpuntodevistamscomnmenteaceptadoeselderealizarlavalidacinalolargodel
50

desarrollodelsistema,realizandopreferentementeundesarrolloincrementalenelcual,al
finaldecadaincremento,serealizaunavalidacin.SinembargoelrazonamientodeBachant
yMcDermotttambines,enciertosentido,vlido.As,enlasprimerasetapasdedesarrollo,
puedesernormalqueelrendimientodelsistemanoseaelevado,yloqueseesperaesque
esterendimientoseeleveamedidaquesevadesarrollandoelproyecto.
La validacin que se realiza en etapas tempranas del desarrollo esta muy vinculada al
proceso de adquisicin del conocimiento. As surge un nuevo proceso, denominado
refinamientodelconocimiento,yquepodemosencuadrardentrodelafasedeadquisicin.
Elprocesoderefinamientoconsisteenverificaryvalidarelconocimientorecinadquirido
en busca de problemas, resultados incorrectos, estructuras inadecuadas, etc. Existen
herramientas como SEEK (Politakis, 1985) y SEEK2 (Ginsber y Weiss, 1985) que se
encargandeverificaryvalidarelnuevoconocimientoadquiridoidentificandolasreglasque
puedensercausadeloserrores.
Otro aspecto a tener en cuenta, y que guarda cierta relacin con el momento de realizar la
validacin, es la diferenciacin existente entre la llamada validacin retrospectiva y la
validacin prospectiva. La validacin retrospectiva se realiza sobre casos histricos ya
resueltos y almacenados en una base de datos. Este tipo de validacin es la ms comnmente
realizada en los sistemas inteligentes, y los casos utilizados pueden incluir como referencia
de validacin tanto opiniones de expertos humanos, como la solucin real al problema
planteado (validacin contra expertos o contra el problema). La validacin retrospectiva se
utiliza en las etapas de desarrollo del sistema, antes de que este se instale en su entorno de
trabajo habitual.
Por otro lado, la validacin prospectiva consiste en confrontar al sistema con casos reales y
ver si es capaz de resolverlos o no (est frecuentemente relacionada con la validacin
orientada al problema). En la validacin prospectiva no se utilizan casos almacenados en
bases de datos sino que se utilizan casos que en ese momento estn siendo tratados por
expertos humanos. De este modo se puede evaluar, no slo la correccin de los resultados,
sino aspectos referentes al uso del sistema. El problema surge, al igual que en la validacin
contra el problema, cuando el dominio de aplicacin es crtico, y el sistema intenta
manipular el entorno (por ejemplo, administrndole una terapia a un paciente). Si la

51

manipulacin no ha sido aprobada por un experto humano no podr llevarse a cabo, lo que
puede limitar la utilidad de este tipo de validacin.
La validacin prospectiva se utiliza una vez que hemos validado el sistema en un entorno de
desarrollo y utilizando casos histricos, y se desea realizar una nueva validacin en el campo
de aplicacin del sistema. Este tipo de validacin es similar a las pruebas beta que
analizaremos ms adelante.

Mtodos de Validacin
Los mtodos para realizar la validacin pueden dividirse en dos grupos principales: mtodos
cualitativos y mtodos cuantitativos (OKeefe et al., 1987). Los mtodos cualitativos
emplean tcnicas subjetivas de comparacin del rendimiento, mientras que los mtodos
cuantitativos se basan en la utilizacin de medidas estadsticas. Esto no implica que los
mtodos cualitativos sean menos formales que los mtodos cuantitativos. Estas tcnicas no
son mutuamente excluyentes y lo normal es utilizar una combinacin de las mismas.
Dentrodelosmtodoscualitativosdevalidacinpodemosdestacarlossiguientes:

Validacin superficial.
Esunavalidacininformalquesebasaenreunionesentrelosdesarrolladoresdelsistema
inteligente,algnexpertohumanodeldominioy,ocasionalmente,algnusuario.Endichas
reunionesseanalizan,subjetivamente,lasconclusionesalasquellegaelsistemacuandoes
confrontadoconunaseriedecasosdeprueba.
Este tipo de validacin es habitualmente realizado en fases de desarrollo del sistema
inteligente,peroserecomiendaquenoseaelnicotipodevalidacinaplicadaalsistema.

Pruebas de Turing
Unodelosprincipalesproblemasdelacolaboracindeexpertosenlavalidacindesistemas
inteligenteseslapresenciadetendenciasafavoroencontradelpropiosistema,odelas
opinionesdeotrosexpertos.Conobjetodeevitarestastendenciasseutilizanlaspruebasde
Turing,desarrolladasapartirdelaideapropuestaporelmatemticoAlanTuringen1950.
52

Enestaspruebasloquesepretendeesreuniraungrupodeexpertoshumanosyhacerque
estosanalicenlosresultados desuscompaeros ylosresultados delsistemainteligente.
Estos resultados deben ser presentados de tal forma que resulte imposible conocer la
identidaddelapersona,omquina,queloshaanalizado.
Chandrasekaran (1983) recomienda la utilizacin de estas pruebas en sistemas expertos
mdicosymuestraunametodologaparallevarlasacabo,queincluyelavalidacindelos
resultadosfinalesdelsistema,ascomosusestructurasderazonamiento.Laspruebasde
TuringtambinsehanempleadoenlavalidacindelossistemasexpertosMYCIN(Yuet
al.,1979)yONCOCIN(Hickametal.,1985).

Test de campo
Lostestsdecampoconsistenencolocaralsistemainteligenteenelquevaasersuentorno
detrabajohabitual,ypermitirquelosusuariosinteraccionenconlenbuscadeposibles
errores.Esloqueenlaingenieradelsoftwareconocamoscomopruebasbeta.
Los tests de campo presentan una serie de ventajas como: (1) parte de las tareas de
validacinseefectanporlosusuariosdelsistema,(2)elnivelderendimientoaceptablese
obtiene implcitamente cuando los usuarios dejan de notificar problemas y, (3) permite
descubrirerroresquesehabanpasadoporaltoenotrotipodevalidaciones.
Sin embargo su utilizacin conlleva una serie de problemas: (1) los usuarios pueden
inundarnos con llamadas sobre preguntas menores que tienen poca relacin con el
rendimientodelsistema,(2)elsistemapuedeperdercredibilidadsielprototipomostradoes
muyincompleto,y(3)slopuedeutilizarseenaquellosdominiosnocrticosenlosquelos
usuariosestncapacitadosparacomprobarlacorreccindelasconclusionesdelsistema
experto.
Unejemplodelautilizacindelostestsdecampopuedeverseenlavalidacindelsistema
R1/Xcon(BachantyMcDermott,1984)

53

Validacin de subsistemas
Estemtodorequiereladivisindelabasedeconocimientos endiversossubsistemaso
mdulosque,posteriormente,sevalidanporseparadoutilizandootrosmtodos.
Estatcnicadedivideyvencerspermitereconocermsfcilmenteloserroresyfacilitael
procesodevalidacin.Sinembargo,presentaunaseriedeinconvenientescomoson:(1)no
todos los sistemas se pueden dividir fcilmente en subsistemas independientes y, (2) la
validacin de todos los subsistemas por separado no es equivalente a la validacin del
sistemacompleto.Porejemplo,supongamosdosmdulosdeunsistemaexpertomdicoque
proponenporseparadolaadministracindedosdrogasdistintas.Laadministracindelas
drogasporseparadonoofreceproblemas,sinembargo,suadministracinconjuntapuedeser
peligrosaparalavidadelpaciente.

Anlisis de sensibilidad
Estatcnicaconsisteenpresentar,alaentradadelsistema,unaseriedecasosmuysimilares
entres,entreloscuales haysinembargopequeas diferencias. Elimpacto dedichas
variacionesenloscasosdeentradapuedeserestudiadoobservandoloscambiosresultantes
enlasalida.
Esta tcnica es especialmente til cuando tratamos sistemas que manejan medidas de
incertidumbre,yaquepuedeestudiarseelimpactodeloscambiosendichasmedidas,tanto
enlosresultadosintermedios,comoenlasconclusionesfinales.

Grupos de control
Lossistemasinteligentespretendensimplificareltrabajoarealizarporpartedelosexpertos
humanos. Por ello, no slo debe evaluarse el sistema por separado, tambin es til
comprobarelimpactoquetieneelsistemaenlaorganizacin.Unatcnicacomnmente
empleadaenestecometidoeslabasadaengruposdecontrol.
En este caso se presentan los casos a dos grupos de expertos, unos que utilizan el sistema
inteligente, y otros que trabajan sin l -y constituyen el denominado grupo de control-. De
esta forma podemos comparar el rendimiento de los expertos cuando utilizan el sistema
54

inteligente, y cuando no lo utilizan. Para una mayor discusin sobre los grupos de control y
otras tcnicas denominadas quasi-experimentales se puede consultar (Adelman, 1991b).
Por otra parte, la validacin cuantitativa consiste en el empleo de medidas estadsticas para
cuantificar el rendimiento de un sistema experto. Muchos mtodos estadsticos se han
empleado en la validacin: contrastes de hiptesis, anlisis de la varianza (ANOVA),
intervalos de confianza, etc. Sin embargo, estas tcnicas pueden resultar confusas para
alguien que no tenga amplios conocimientos de estadstica, y son difciles de interpretar.
Enestecursohemosdecididocentrarnosenaquellas tcnicasmscomunesyfcilesde
interpretar (comoel ndice deacuerdo) que,utilizadas junto aotras medidas ytcnicas
grficas,permitentenerunconocimientoampliosobreelrendimientodenuestrosistema.
Podemosdividirnuestrastcnicascuantitativasentresgrupos:medidasdepares,medidasde
grupoyratiosdeacuerdo.Acontinuacinharemosunabrevedescripcindetodasellas,yse
analizarnconmsdetallealgomsadelante.

Medidas de pares
Las medidas de pares pretenden evaluar el grado de acuerdo y/o asociacin entre las
interpretaciones de dos expertos (incluyendo sistema experto, expertos humanos, o una
referenciaestndar).
Lasmedidasdeacuerdoseconsideranuntipoespecialdemedidasdeasociacindestinadas
acomprobarlafiabilidadolareproducibilidaddelasobservacionesrealizadas.Dentrode
ellasdestacamos:elndicedeacuerdo,elndicedeacuerdodentrodeuno(similaralanterior
peroqueconsideracomoacuerdosparcialesaquellasdiscrepanciasquesediferenciasenuna
slocategorasemnticaasumiendoquelasinterpretacionespuedenserordenadassegn
unaescalaordinal),kappa(quecorrigeaquellosacuerdosquesondebidosalacasualidad)y
kappa ponderada (similar a la anterior pero ponderando las distintas discrepancias en
funcindelamagnituddelasdesviaciones).
Enlasmedidas deasociacin seinvestigaelgradoderelacinlinealexistenteentrelas
variablesy,siesposible,predecirlosvaloresdeunavariableapartirdelosvaloresdeotra.
Dentrodeestasmedidaspodemosdestacarlatau( )ylataub(b)deKendall,larhode
55

Spearman(rs)ylagammadeGoodmanKruskal().Todasellasmedidasnoparamtricas,
yaquenohacenningunasuposicinsobreladistribucinsubyacentedelosdatos.

Medidas de grupo
Lasmedidasdegrupotratanlainformacindeungrupodeexpertossobreunadeterminada
interpretacin.Elobjetivoesverqugrupospuedenaparecerentreunconjuntodeexpertos
ycomprobarsilasopinionesdelsistemainteligentesonsimilaresalasdelosotrosexpertos
(especialmentedeaquellosqueseconsideranconmayorcategora).Dentrodelasmedidas
degrupopodemosdestacar:

Las medidas de Williams, Con las que se pretende ver si la relacin de un experto
aislado con el grupo de referencia es similar a la relacin existente entre los expertos del
grupo.

El anlisis cluster, en donde agrupamos a los expertos en un rbol jerrquico segn la

similitud de sus interpretaciones.

El escalamiento multidimensional, donde se representa a los expertos en un plano 2D, en

el que cuanto ms cercano estn los expertos ms similares sern sus conclusiones.

Las medidas de dispersin y tendencias, en donde se analiza cmo de dispersos son los
resultados de un experto si los comparamos con el resto de expertos del grupo, y hacia
qu interpretaciones tienden a dirigir sus conclusiones los expertos.

Ratios de acuerdo
Losratiosdeacuerdoseencargandecompararlasinterpretacionesdeunexperto(osistema
inteligente)conunareferenciaestndar(yaseaunconsensoentrelosexpertoshumanosola
solucin real al problema planteado). Esta comparacin se hace para cada una de las
posiblescategorasenlasquesedivideunainterpretacin(porejemplo,sieldiagnsticode
unaenfermedadpuedeobtener3posiblesvalores:enfermedadA,BoC,podemoshallarlos
ratiosdeacuerdoparacadaunadelas3posiblesenfermedades).Losratiosdeacuerdose
calculanapartirdeunatabla22,ylosmsutilizadossonlasensibilidad,laespecificidad,
56

elvalorpredictivopositivo,elvalorpredictivonegativo,elndicedeacuerdoylamedidade
Jaccard.

Coeficientes de exactitud
Enlossistemasinteligentespuedesercomnqueunasalidaserepresentemedianteuna
etiquetasemnticayunaprobabilidad(ounfactordecertidumbre)asociada.Porejemplo,
imaginemosqueunsistemaexpertopredicequeunpacientetienelaenfermedadXconuna
probabilidad del 0.75, y otro sistema experto tambin predice que el paciente tiene la
enfermedadXperoestavezconprobabilidad0.95.Sielpacienteefectivamentetenala
enfermedadXambasrespuestaspuedenconsiderasecorrectas,perolarespuestadelsegundo
sistemaexpertosermscorrectaqueladelprimero.
Paracuantificarestasdiferenciassehapropuestolautilizacindecoeficientesdeexactitud
(Shapiro, 1977). Reggia (1985) utiliz el coeficiente Q para la validacin del sistema
experto TIA (un sistema para la deteccin de ataques isqumicos transitorios). Este
coeficientesedefinecomo:
n

2 pi 0.5
i 1

endondepieslaprobabilidadasignadaporelsistemaexpertoalasalidaisima.Lamedida
Qseinterpretadelasiguienteforma:suvalores1siprediccinesperfecta,0sielsistema
nopresentacapacidadesdepredicciny1silaprediccinestotalmenteincorrecta.

Curvas ROC
LascurvasROC(ReceiverOperatingCharacteristic)estnmuyrelacionadasconlosratios
deacuerdoyconelanlisisdesensibilidad.Seutilizan,sobretodo,paraanalizarcmoun
determinadocriteriodedecisininternoafectaalrendimientodelsistema.Paradescubrir
estainfluenciasecomputanlosratiosdeacuerdoparavariassituacionesenlasqueseha

57

variadoelcriteriodedecisininternosobresuposiblerango.Elgrficoquerelacionalos
verdaderospositivosconlosfalsospositivosesloqueseconocecomocurvaROC.
Como ejemplo tomemos el grfico de la figura que sigue a continuacin. En este grfico, un
umbral interno del sistema se vara desde el valor 0.9 hasta el valor 0.05. La mejor relacin
entre los verdaderos positivos (TP) y los falsos positivos (FP) se da cuando el valor del
umbral es 0.1.

Distancias aritmticas
Existenocasionesenlasquesepuedenmedirlasdiferenciasentredosexpertosapartirde
distanciasaritmticas(comoladistanciaeucldea).Unejemplodeutilizacindeestamedida
loencontramos enlavalidacin delossistemas expertos probabilsticos PNEUMONIA
(Verdagueretal.,1992)yRENOIR(Hernndezetal.,1994).Enambostrabajoslasalidadel
sistemainteligenteesunvectorenelquesedetallanlasprobabilidadesdeaparicindelas
distintashiptesistomadasenconsideracin.Paracompararlassalidadelsistemaexperto
con la de varios expertos humanos se utiliza la distancia eucldea, la distancia de
Mahalanobis,ladistanciadeChebychevoladistancia Manhattan(odebloquesdecasas).
Ladefinicindeestasmedidaseslasiguiente:

Eucldea

d (i, j )

x
N

m 1

Mahalanobis

d (i, j )

im

x jm 2

(x i x j ) W 1 (x i x j )

Chebychev

d (i, j ) Max m x im x jm

Manhattan(obloquesdecasas)

d (i, j ) xim x jm

m 1

endondedrepresentaladistancia,iyjsonexpertos,Neselnmerodecoordenadas(eneste
casodeposibleshiptesis)yximeslaprobabilidadquehaasignadoelexpertoialahiptesis
58

m.ParaelcasodeladistanciadeMahalanobis(xixj)eselvectorcolumnamdimensional
dediferenciasentrelosvectoresdeprobabilidadesdelexpertoiydelexpertoj,(xixj)es
el vector transpuesto correspondiente y W1 es la inversa de la matriz de varianzas y
covarianzasparalasdistintasenfermedades.En(Bisquerra,1989)oen(CoxyCox,1994)
podemosencontrarotrostiposdedistanciasmatemticas.

Tipos de Errores en la Validacin

Enlossistemasinteligentespuedenaparecerdostiposdeerrores:erroresdecomisin y
erroresdeomisin(GonzalezyDankel,1993).
Loserroresdecomisinocurrencuandoelsistemaexpertodeduceconclusionesincorrectas
apartirdelosdatosdeentrada.Estoserroresafectanalaprecisindelsistemaysonfciles
dedetectarpero,amenudo,difcilesdelocalizarycorregir.
Loserroresdeomisinocurrencuandoelsistemaesincapazdellegaraningunaconclusin
apartirdelosdatosdeentrada.Enotraspalabras,elconocimientonecesariopararesolver
unproblemaenparticulardentrodeldominiodeaplicacinnoseencuentraenlabasede
conocimientos. Estos errores son ms difciles de detectar porque el caso de prueba
necesarioparadetectarlopuedenoserevidenteparaeldesarrollador.Estoserroresafectana
laadecuacindelsistema.
Sin embargo los errores tambin pueden aparecer en el proceso de validacin. OKeefe et al.
(1987) identifican dos posibles errores: de Tipo I o de riesgo para el desarrollador y de Tipo
II o de riesgo para el usuario. La tabla que sigue ilustra la situacin.

Estado del sistema experto

El sistema es vlido
El sistema se acepta
Accin

como vlido
El sistema NO se acepta
como vlido

Decisin correcta
Error Tipo I
(Riesgo para el desarrollador)

El sistema NO es vlido
Error Tipo II
(riesgo para el usuario)
Decisin correcta

59

LoserroresdeTipoIseproducencuandounsistemaesconsideradocomoinvlido,ana
pesardeservlido.Esteerroraumentainnecesariamenteloscostesdedesarrollodelsistema
ymermalacredibilidadenelmismo.Secalificancomoderiesgoparaeldesarrollador
porqueelpropiodesarrollodelsistemapuedeponerseenentredicho.
Porotrolado,loserroresdeTipoIIseproducencuandoseaceptacomovlidounsistema
quenoloes.LasconsecuenciasdeesteerrorsonmspeligrosasquelasdelerrordeTipoI,
sobre todo si el sistema acta en dominios crticos (un sistema experto mdico que
diagnostiqueunaenfermedadincorrectamentepuedeprovocaralospacientesunsufrimiento
innecesario).

60