1

7.5 Sistemas basados en reglas, tablas de decisión, y árboles de decisión en monitorización de estado y clasificación de situaciones, control y apoyo de decisiones Sistemas Basados en reglas, tablas de decisión, y árboles de decisión: características comunes La aplicación de sistemas basados en reglas, tablas de decisión, y árboles de decisión en monitorización del estado, clasificación de situaciones (valoración) y apoyo de decisiones es similar tanto desde el punto de vista técnico como de los objetivos. Todas las herramientas mencionadas trabajan según principios similares y difieren principalmente con respecto al esquema de representación de conocimiento interno y detalles acerca del mecanismo de control de inferencia. En muchas aplicaciones la selección de una herramienta en particular es arbitraria y puede depender de preferencias individuales, del tamaño del problema a ser resuelto, del tipo de lógica subyacente (proposicional vs. lógica de predicados), etc. Sin embargo, el esquema básico principal de funcionamiento es el mismo: para una descripción de estado de entrada dada, encontrar el modelo apropiado que le corresponde (condición previa de la regla, condiciones de la tabla de decisión o sucesión de condiciones en un árbol de decisión), y finalmente seleccionar el ítem apropiado (regla del sistema basado en reglas, fila o columna de una tabla de decisión, camino de decisión en árbol de decisión) y ejecutarlo. El modo básico de trabajo se ilustra en la figura siguiente.

El esquema básico de funcionamiento es el mismo para todas las herramientas discutidas. A continuación se presentarán algunos problemas particulares acerca de la realización y aplicación. Se empezará con reconocimiento de situaciones o valoración de situaciones que son el mecanismo básico que verifica si y qué condiciones previas de la regla, tabla de decisión parte condicional o reconocimiento de sucesión de árbol de decisión se cumplen.

Reconocimiento de situaciones

La detección de situaciones específicas, la verificación de satisfacción de condiciones previas de reglas, la detección de fallos, la detección de ocurrencias de formas de comportamiento específicas, etc. usando cualquiera de los lenguajes presentados para la representación de conocimiento consiste básicamente en la aplicación del mismo mecanismo: pattern matching. La idea principal consiste en emparejar la descripción de estado actual con la fórmula específica de la situación y verificar si la generalización se sostiene. Después, si es necesario, se determinan los valores específicos de los parámetros.

También es posible usar una combinación de formalismos de representación del conocimiento - en este caso, las fórmulas que representan la información total deben estar compuestas de partes separadas expresadas mediante un solo formalismo. Para simplificar el tratamiento se asume que sólo ha sido escogido un formalismo. La extensión al uso simultáneo de varios formalismos (lenguajes de representación de conocimiento) es directa.

La suposición básica es que el estado del sistema se monitoriza, y se construye una fórmula que describe estado actual en ciertos intervalos de tiempo mediante la aplicación apropiada de algún enfoque de la transformación señal-símbolo. Esta fórmula -- guarda la información sobre el estado actual, es decir, parámetros de sistema, relaciones que se mantienen, etc., para un intervalo de tiempo, a veces llamado ventana de tiempo. De hecho, no es necesario escribir la fórmula explícitamente, ciertos componentes simplemente deben ser accesibles si es necesario.

Ahora supongamos que para la identificación de situaciones específicas esperadas (condiciones previas, fallos, etc.) del sistema considerado se ha determinado un conjunto de fórmulas que las define (y simultáneamente describe). Sea un conjunto de fórmulas de situación que define las posibles situaciones de interés , , donde cada es una fórmula de situación que define cierto tipo de situación. El problema de identificar la situación específica definido por la fórmula puede ser reemplazado ahora por verificar si esta fórmula generaliza una fórmula que describa el estado actual, si.

Como los métodos para la comprobación de generalización entre fórmulas ya se han presentado, el único problema restante es evaluar todas las fórmulas de situación sistemáticamente con respecto a la descripción de estado actual. Si se sostiene para alguna generalización, entonces la situación específica definida por se confirma. Puede haber ocurrencia simultánea de varias situaciones específicas (por ejemplo pueden satisfacerse condiciones previas de varias reglas simultáneamente u ocurrir fallos múltiples) al mismo tiempo.

Problemas de aplicación práctica: una visión general

En la literatura pueden encontrarse varias aplicaciones practicas (vea algunas de las referencias adjuntas). En [Laffey et al, 1988] se discuten los problemas acerca de las aplicaciones en tiempo real de sistemas basados en conocimiento. Éstos se aplican en apoyo al control, monitorización y supervisión y en sistemas basados en conocimiento de apoyo a decisiones. Entre otras, las aplicaciones en tiempo real se distinguen por las siguientes características:

No monotonia: los datos de entrada, procedentes de sensores, y los hechos que se afirman a la base de conocimiento del sistema no permanecen estáticos durante toda la ejecución del programa.

Funcionamiento continuo: Un sistema en tiempo real debe ser capaz de funcionar continuamente, aun después de un fallo total o parcial de uno o más componentes del sistema controlado.

Eventos asíncronos: Un sistema en tiempo real debe ser capaz de ser interrumpido mientras funciona normalmente, para aceptar datos de entrada de eventos no programados o asíncronos y reaccionar de forma apropiada.

Interface hacia el exterior: Un sistema experto en tiempo real necesita típicamente estar acoplado a sensores de la entrada y actuadores.

Datos inciertos o perdidos: Un sistema en tiempo real debe poder reconocer y procesar apropiadamente los datos del proceso de validez incierta o disminuida.

Gran capacidad de procesado: Un requisito típico para sistemas en tiempo real basados en conocimiento es una gran capacidad de procesado rápido de la información; esto es debido al corto tiempo de contestación y a la naturaleza compleja de los datos y métodos de procesado de los mismos.

Razonamiento temporal: Un sistema en tiempo real típicamente debe tener la habilidad de razonar sobre eventos pasados, presentes y futuros, así como la secuencia en la que ocurren.

Enfoque de atención: Cuando ocurre un evento significante, es importante que el sistema en tiempo real pueda enfocar sus recursos en los objetivos importantes.

Tiempo de contestación garantizado: El sistema debe poder responder cuando se necesita una contestación. Es más, normalmente se requiere la mejor contestación posible dentro de un tiempo límite.

Integración con componentes procesales: Un sistema basado en conocimientos en tiempo real debe integrarse típicamente con un software en tiempo real convencional por cumplir tareas como procesado de senyal, extracción de características y aplicación de algoritmos específicos de entrada/salida.

Destaquemos que la mayoría de las características anteriores están, de una u otra manera, representadas y usadas en cualquier sistema de control y supervisión basado en conocimiento. En [Laffey et al, 1988] se describen aproximadamente cincuenta aplicaciones diferentes, desde sistemas aeronáuticos y espaciales hasta aplicaciones financieras, médicas, en comunicaciones y de control automático, incluso aplicaciones en robótica y en vehículos autónomos. Uno de los ejemplos más llamativos consiste en un sistema experto en tiempo real que controla a un robot jugador de tenis de mesa.

También se han descrito varias aplicaciones en dominios más clásicos del control automático. En algún articulo recopilatorio se describen aplicaciones de sistemas basado en conocimiento a la supervisión, diagnóstico, y control en el dominio de la automática [Tzafestas, 1987], [Tzafestas, 1989], [Tzafestas, 1989a]. Las aplicaciones de ejemplo incluyen autosintonía de controladores PID, un supervisor basado en reglas autosintonizado, un sistema experto para control de destilación, y supervisión experta de un motor turbo-diesel.

Problemas técnicos seleccionados

En esta sección se discutirán algunos problemas acerca de la aplicación de sistemas basados en conocimiento, usando principalmente la metodología basada en reglas. Dependiendo de la aplicación específica y de las características deseadas del sistema de supervisión basado en conocimiento, ocurren varios problemas prácticos que normalmente no son considerados teóricamente. Estos problemas son de naturaleza heterogénea. Sin embargo, con respecto a la estructura general de un sistema de monitorización y supervisión basado en conocimiento pueden distinguirse los cuatro siguiente grupos básicos:

Problemas de entrada - problemas que afectan a la entrada de señales que provienen del ambiente y del sistema controlado así como la "posterior transformación" de las señales en forma de representación de conocimiento aceptada, es decir, fórmulas lógicas,

Problemas de salida - estos problemas involucran la salida del sistema de control basado en conocimiento, en particular la "transformación" de la parte apropiada del conocimiento representada en forma lógica en acciones del control y posterior ejecución de las operaciones requeridos,

Problemas de representación del conocimiento - problemas de representación interna del conocimiento; estos problemas son principalmente tres: primero, qué parte de conocimiento debe representada explícitamente y qué conocimiento puede tratarse forma implícita, segundo, cómo codificar y organizar la base de conocimiento, y tercero, cómo debe el manejarse y actualizarse el conocimiento,

Problemas de razonamiento - éstos son los problemas que implican la estrategia de razonamiento y otros detalles, incluyendo selección de reglas o mecanismos de solución de conflictos, algoritmos eficaces de emparejamiento, tratamiento de predicados, funciones y constantes específicos, y razonamiento tilizando conocimiento implícitamente representado, etc.,

Para los problemas anteriores no puede proporcionarse una teoría general y las soluciones prácticas dependen del problema específico. Es más, la clasificación anterior se refiere a una estructura de sistema de supervisión producto, en gran parte, de una convención. De hecho, todos los problemas están fuertemente interconectados y la selección de una solución a ciertos problemas en uno de los grupos indicados puede proyectarse e influir en las soluciones de otros problemas en otros grupos. Entre las áreas de influencia mutua pueden distinguirse dos de gran importancia. En primer lugar, los problemas en la entrada y la salida están entrelazados con los de representación de conocimiento, y segundo, los problemas de representación de conocimiento influyen en los problemas de razonamiento.

Los problemas en la entrada y en la salida son en cierto grado similares, ya que ambos involucran la interfaz entre el sistema de supervisión basado en conocimiento y el exterior. Las soluciones prácticas dependen del carácter de las señales (eléctricas, mecánicas, químicas, biológicas, etc.), posibilidades de adquisición (descubrimiento, medida, observación, etc.), la posibilidad de realizar acciones de control, sensores y actuadores accesibles, exactitud requerida, etc., Las soluciones prácticas pueden incluir la aplicación de gran variedad de instrumentos usados en el control automático clásico y no clásico, incluso cámaras y sistemas de procesado e interpretación de imágenes para la entrada, así como robótica o sistemas de manipulación capaces de realizar operaciones mecánicas complejas para la salida.

Los problemas de representación de conocimiento se interconectan fuertemente con los problemas de razonamiento. El problema básico de representación de conocimiento involucra la representación práctica de fórmulas de estado. La introducción teórica y la presentación en los capítulo 4 y 6 proporcionan sólo un planteamiento general que debe ajustarse a cualquier caso específico.

Tipos de hechos y su representación

Puede decirse que no es necesario (y quizá irrazonable) guardar todo el conocimiento acerca del estado actual en la memoria d en forma de hechos. En general, entre todos los hechos pueden distinguirse por lo menos los siguientes tipos con respecto a los problemas de aplicación:

hechos ordinarios, representando relaciones en el sistema supervisado, pero no accesibles a través de los canales de entrada,

hechos que representan el estado interno de la memoria del sistema de supervisión basado en conocimiento, como el objetivo de control, el estado, la historia, etc.,

hechos de entrada que pueden siempre generarse a partir de los valores recientes de los parámetros de entrada,

hechos de entrada de usuario, hechos que sólo pueden obtenerse a partir del usuario-supervisor (si existe),

hechos deducibles, hechos que representan algun tipo de información redundante y que pueden deducirse fácilmente a partir de otros hechos existentes,

hechos que representan relaciones matemáticas (aritméticas), como mayor o iguala a (

), igual (=), etc.,

hechos que representan propiedades específicas del dominio, que pueden evaluarse a partir del conocimiento experto del dominio.

Con respecto a la clasificación anterior de hechos, sólo deben representarse necesariamente de forma explícita en la base de conocimiento aquellos que pertenecen a los dos primeros grupos. Puede ser poco razonable guardar los hechos de entrada y los de usuario en la memoria, ya que, en cualquier instante, si son necesarios, pueden ser "leídos" de la interfaz de entrada y el usuario puede simplemente pedirlos. Finalmente, pueden generarse hechos deducibles, matemáticos, y específicos del dominio según las necesidades actuales mediante el uso de mecanismos de inferencia especiales, y probablemente esto sería más eficaz que guardarlos en todo momento en la base de conocimiento. La utilización este esquema de representación del conocimiento parcialmente implícito puede contribuir significativamente a reducir la cantidad memoria requerida para la representación del estado. Simultáneamente, puede acelerar la ejecución, ya que la generación de ciertos hechos puede ser más rápida que su búsqueda en una base de conocimiento grande y el tiempo requerido para la actualización de la base de conocimiento se reduce significativamente. Sin embargo, el conocimiento implícito provoca problemas adicionales al mecanismo de razonamiento y, particularmente, a los procedimientos de emparejamiento. Si algunos hechos se representan implícitamente, los emparejamientos directos de hechos incluidos en alguna fórmula simple (posiblemente describiendo las condiciones previas de alguna regla de transformación) con la fórmula de estado no son satisfactorios. Se requieren procedimientos especializados de emparejamiento que cubran la generación de hechos implícitos. En el general, debe tenerse en cuenta el equilibrio entre las representaciones de conocimiento explícitas e implícitas, deben considerarse varios factores. Por consideraciones prácticas, se han seleccionado los siguientes tipos de hechos:

de estado - especificados por la parte básica de la fórmula de estado y guardados en memoria,

de control - hechos especiales que especifican el estado de la memoria del controlador,

de usuario - especificados por el usuario, leídos si es necesario,

de entrada - leídos como datos de entrada, si es necesario,

de inferencia - hechos a ser inferidos según determinadas reglas mediante el uso de mecanismos especiales de inferencia,

especiales - interpretados según reglas especiales, por ejemplo aritméticas.

Como ejemplo, se muestra cómo los hechos anteriores se codifican como términos de algunos ‘meta-hechos’ que son cláusulas de Prolog. Cualquiera de estos hechos puede tener varios argumentos aparte del término que codifica la fórmula lógica; para el ejemplo de aplicación se han escogido tres argumentos: el tipo de hecho lógico, el átomo, es decir, la fórmula lógica apropiada, y su valor de verdad actual. El siguiente extracto de programa en Prolog muestra la estructura apropiada.

{ *** Types of facts *** }
{
state - specified by the state formula
control - special facts specifying state of the controller
memory
user - specified by the user
input - to be read as input data
infer - fact to be inferred according to given rules
special - interpreted according to special rules
The form of any fact in database is:
fact(<type>,<atom>,<truth-value>).
and f(<type>,<atom>) for preconditions,
where:
<type> = one of the above types,
<atom> = specification of the atomic formula defining the
fact,
<truth_value> = current status; true/false.
}

Para resumir, no puede esperarse una sola solución universal que proporcione un acercamiento consistente a la resolución de problemas de aplicación prácticos. En esta sección sólo se han esbozado agrandes rasgos los más obvios. Las siguientes subsecciones se dedican al análisis de ciertos problemas particulares poniendo por delante algunas pautas prácticas. Algunas de las consideraciones se apoyan en ejemplos simples de aplicaciones prácticas.

El mecanismo de control del razonamiento y el uso de heurísticas del dominio

Otro grupo de problemas relacionado inevitablemente con cualquier aplicación práctica de sistemas del control basados en reglas es el que afecta al control de razonamiento, es decir, la estrategia de búsqueda a aplicar en las reglas. A grandes rasgos, el problema básico de control del razonamiento consiste en la ejecución repetida del siguiente ciclo:

Buscar en el conjunto de reglas de transformación aquellas aplicables al estado actual; la fórmula de condición previa de cualquier regla examinada se compara con la fórmula del estado actual mediante un algoritmo de emparejamiento (en una versión básica se lleva a cabo una prueba de generalización basada en la teoría presentada en [Ligeza, 1993] en la práctica, puede aplicarse también algunos algoritmos especializados)

Seleccionar el conjunto de todas las reglas aplicables al estado actual (el llamado conjunto de conflicto),

Si no hay ninguna regla en el conjunto de conflicto, repetir el procedimiento desde 1 (puede ser necesario un retraso entre dos ciclos consecutivos),

Si hay exactamente una regla, ir al próximo paso; si hay más de una regla en el conjunto de conflicto, aplicar el mecanismo de solución de conflictos especializado para seleccionar la regla a ser aplicada y seleccionar la regla,

Ejecutar la regla seleccionada; realizar las acciones de control especificadas por la regla y modificar la base de conocimiento,

Ir a 1 para repetir el ciclo.

El esquema anterior esboza el algoritmo básico de razonamiento en un sistema del control basado en conocimiento. Las modificaciones principales incorporadas en aplicaciones prácticas pueden involucrar los siguientes problemas:

Segmentación del conjunto inicial de reglas con respecto a ciertos contextos; dependiendo del contexto en curso sólo se tiene en cuenta un segmento apropiado de reglas durante la búsqueda en el conjunto de conflicto,

Aplicación de varios mecanismos de solución de conflictos heurísticos, dependientes del dominio,

Aplicación de algoritmos especializados y procedimientos heurísticos para la preselección de reglas,

Aplicación de procedimientos de cálculo especializados para determinar características específicas de la base de conocimiento en curso, por ejemplo encontrando algún extremo(mínimo, máximo), calculando el número exacto de elementos que satisfacen algunas condiciones, etc.,

La segmentación de la base de reglas es un paradigma normalmente usado en varios sistemas basados en conocimiento. El objetivo principal de esta segmentación es reducir el número de reglas considerado al mismo tiempo mediante la separación temporal de las reglas que no son aplicables. La clave para seleccionar las reglas es el contexto en curso. En sistemas del control el contexto puede definirse con respecto al modo de funcionamiento, como por ejemplo automático, semiautomático, manual, etc., Otro factor usado para determinar el contexto puede tener en cuenta el status de funcionamiento por ejemplo funcionamiento normal, arrancada, paro, emergencia, fallo, diagnóstico, etc. Dentro de un contexto es posible distinguir varios subcontextos, y así realizar más segmentaciones. Así se introduce una jerarquía natural en el conjunto de reglas. El mecanismo de control de razonamiento también trabaja entonces de forma jerárquica, primero determina el contexto apropiado (y, posiblemente, el subcontexto), y luego realiza la búsqueda normal teniendo en cuenta sólo el conjunto determinado de reglas limitado al contexto. Este enfoque proporciona la posibilidad de acelerar la ejecución, pero también es importante para hacer la base de reglas mucho más transparente al usuario, más fácil entender, dirigir, modificar y poner a punto.

Los mecanismos de resolución de conflictos están basados normalmente en algunas suposiciones arbitrarias (como que el orden de las reglas indica la jerarquía de ejecución; este enfoque constituye uno de los principios del lenguaje de programación Prolog), o en reglas heurísticas, por ejemplo asignando prioridades numéricas a las reglas. En el general, los mecanismos más típicos de resolución de conflictos operan siguiendo los siguientes principios:

Ejecución ordenada de las reglas de la base de conocimiento (sólo aquéllas cuya parte condicional se satisfaga); típicamente se sigue un orden lineal de ejecución; incluyendo el caso de información adicional en la parte siguiente de las reglas Las reglas especificadas se examinan primero, y la primera seleccionada se aplica; de esta forma se acelera la ejecución de algunas rutinas típicas,

Pueden aplicarse mecanismos de evaluación de prioridades para establecer el orden de reglas en conflicto; la evaluación de prioridades puede tener en cuenta diversos factores como el número de aplicaciones exitosas de una regla, el tiempo desde la última aplicación de una regla, los posibles valores de los parámetros para la aplicación actual de una regla, ciertas condiciones externas, etc. Algunas posibilidades más simples incluyen el uso de la regla aplicada mas recientemente, el uso de la regla aplicada menos recientemente, el uso de la regla más específica, el uso de la regla con el menor número de variables, etc.,

Pueden usarse sistemas basados en conocimientos de meta-control para la selección de la regla a ser aplicada; estos sistemas pueden utilizar el enfoque típico de los sistemas expertos y tener en cuenta el objetivo actual de razonamiento, condiciones ambientales, estadísticas acerca del comportamiento pasado del sistema, etc.,

Los hechos que determinan el contexto puede usarse como semáforos para bloquear y permitir al mecanismo de control de inferencia limitar el subconjunto de reglas que pueden ejecutarse; de esta forma puede manejarse la segmentación dinámica del conjunto de todas las reglas,

También puede aplicarse los valores de los parámetros para seleccionar la regla cuyos parámetros mejor satisfagan algunos determinadas condiciones; este método puede considerarse como una modificación de los métodos de evaluación de prioridades,

El enfoque de control óptimo puede ser aplicado en la selección de la regla que asegure el mejor valor de algún indicador; en caso de sistemas de planificación puede aplicarse programación dinámica o búsqueda heurística para generar una sucesión de reglas que constituyan la solución óptima.

Por supuesto, un sistema realista puede combinar los enfoques anteriores e incluir algún otro. Sin embargo, no puede sugerirse ninguna solución general, puesto que el diseño y aplicación de control del razonamiento es una tarea altamente especializada y específica del dominio.

Como ilustración, la estrategia básica llevada a cabo es una búsqueda lineal de reglas con ejecución de la primera regla encontrada; después de la ejecución de la regla se repite el ciclo de búsqueda. El orden de especificación de las reglas es equivalente a establecer prioridades, la primera regla tiene la prioridad más alta, etc. La aplicación más simple puede ser:

run:-
repeat,
findrule(_Number),
executerule(_Number),
test,!.
findrule(_Number):-
rule(_Number,_,_Preconditions,_,_,_),
consistent(_Preconditions),!.
executerule(_Number):-
rule(_Number,_,_Preconditions,_,_Dels,_Adds),
consistent(_Preconditions),
remove(_Dels),
add(_Adds).
test:-
rule(1,_,_Preconditions,_,_,_),
consistent(_Preconditions).
remove([]):- !.
remove([_F|_T]):- retract(fact(_F)),remove(_T).
add([]):- !.
add([_F|_T]):- assert(fact(_F)),add(_T).

La versión más simple de un intérprete de reglas como el presentado utiliza un formato simplificado de reglas y la prueba más simple para las condiciones previas. Otra versión de intérprete de reglas para búsqueda lineal y ejecución de la primera regla encontrada es:

run:-
write('LOOP'),nl,
findrule(_Number,_Name,_Preconditions,_Negative_preconditions),
executerule(_Number,_Name,_Preconditions,_Negative_preconditions),
!,
run.
run:-
nl,nl,nl, write('No rule applicable; operation halted').
findrule(_Number,_Name,_Preconditions,_Negative_preconditions):-
rule(_Number,_Name,_,_Preconditions,_Negative_preconditions,_,_,_,_,_),
write('Find rule: testing preconditions: '), write(_Number),nl,
satisfied(_Preconditions),
unsatisfied(_Negative_preconditions).
executerule(_Number,_Name,_Preconditions,_Negative_preconditions):-
rule(_Number,_Name,_,_Preconditions,_Negative_preconditions,
_Action,_Delete_results,_Add_results,_Message,_Next_rules),
write('Exec rule: No testing of preconditions: '), write(_Number),nl,
{satisfied(_Preconditions),
unsatisfied(_Negative_preconditions), }
write('Action executed: '),write(_Action),nl,
remove(_Delete_results),
add(_Add_results),
write(' *** INFO *** '),nl,write(_Message),nl.
remove([]):- !.
remove([f(_Type,_Term)|_T]):-
retract(fact(_Type,_Term,_)),remove(_T).
add([]):- !.
add([f(_Type,_Term)|_T]):-
write(_Type),write(' '), write(_Term),nl,
process(f(_Type,_Term),f(_Type,_New_term)),
write(f(_Type,_New_term)),nl,
assert(fact(_Type,_New_term,true)),add(_T).
process(f(state,angle(plus(_Angle,_Alpha))),f(state,angle(_New_angle))):-
data(_Alpha,_Given),
write(_Given),nl,
_New_angle is _Angle + _Given,
write(_New_angle),nl,!.
process(_Term,_Term).

Esta versión no prueba las condiciones previas de las reglas encontradas dos veces e incorpora un esquema diferente al lazo en Prolog. n [Ligeza, 1993] se propone una modificación del algoritmo básico de interpretación que permite el cambio flexible entre reglas. La idea es que si se dispone de conocimiento experto del dominio para reordenar las reglas, puede codificarse mediante la parte siguiente de las reglas. El significado de esta especificación es: si después de la ejecución de alguna regla es razonable escoger la ejecución de una sucesión dada de reglas, puede abandonarse temporalmente la búsqueda lineal básica y probarse primero las reglas especificadas. Este mecanismo permite un reordenamiento muy flexible y general de ejecución de las reglas. De hecho, se incorpora una cola LIFO (last in first out) dinámica en el mecanismo de control de razonamiento. Un intérprete "a dos niveles" que realiza la búsqueda y ejecución según esta estrategia puede ser:

run:-
write('LOOP NEXT RULES'),nl,
pick(_Number),
findrule(_Number,_Name,_Preconditions,_Negative_preconditions),
executerule(_Number,_Name,_Preconditions,_Negative_preconditions),
!,
run.
run:-
next([]),
write('LOOP LINEAR'),nl,
findrule(_Number,_Name,_Preconditions,_Negative_preconditions),
executerule(_Number,_Name,_Preconditions,_Negative_preconditions),
!,
run.
run:-
nl,nl,nl, write('No rule applicable; operation halted').
pick(_Number):-
next([]),!,fail.
pick(_Number):-
retract(next([_First|_Rest])),
eq(_Number,_First),
assert(next(_Rest)).
pick(_Number):- pick(_Number).
\end{verbatim}

Para una correcta ejecución, la cola next/1 debe estar inicializada, por ejemplo, por una lista vacía. Otra modificación y extensión del mecanismo propuesto pueden consistir en asignar a las reglas prioridades numéricas y modificaciones dinámicas. Esto puede hacerse especificando una función apropiada en la sección siguiente de cualquier regla; entonces las reglas pueden ordenarse durante cualquier ciclo de búsqueda con respecto a las prioridades actuales.