En inteligencia artificial , la planificación basada en preferencias es una forma de planificación y programación automatizadas que se centra en producir planes que además satisfagan tantas preferencias especificadas por el usuario como sea posible. En muchos dominios de problemas, una tarea se puede lograr mediante varias secuencias de acciones (también conocidas como planes). Estos planes pueden variar en calidad: puede haber muchas maneras de resolver un problema, pero generalmente se prefiere una que sea, por ejemplo, rentable, rápida y segura.
Los planificadores basados en preferencias tienen en cuenta estas preferencias al elaborar un plan para un problema determinado. Ejemplos de software de planificación basado en preferencias incluyen PPLAN [1] y HTNPlan-P [2] ( planificación HTN basada en preferencias ).
Las preferencias pueden considerarse restricciones suaves de un plan. La calidad de un plan aumenta cuando se satisfacen más preferencias, pero puede que no sea posible satisfacer todas las preferencias en un solo plan. Esto difiere de las restricciones estrictas que deben cumplirse en todos los planes producidos por el software de planificación. Estas restricciones estrictas son parte del conocimiento del dominio , mientras que el usuario especifica por separado las restricciones suaves (o preferencias). Esto permite reutilizar el mismo conocimiento del dominio para varios usuarios que pueden tener diferentes preferencias.
El uso de preferencias también puede aumentar la duración de un plan para satisfacer más preferencias. Por ejemplo, al planificar un viaje de casa al colegio, el usuario puede preferir comprar una taza de café en el camino. El software de planificación ahora podría planear visitar Starbucks primero y luego continuar con la escuela. [3] Esto aumenta la duración del plan pero se satisface la preferencia del usuario.
El lenguaje de definición de dominio de planificación (a partir de la versión 3.0 [4] ) admite la especificación de preferencias mediante preferencedeclaraciones. Por ejemplo, la declaración
(preference (always (clean room1)))indica que el usuario prefiere que room1esté limpio en cada estado del plan. En otras palabras, el planificador no debe programar una acción que provoque room1que se ensucie. Como muestra este ejemplo, una preferencia se evalúa con respecto a todos los estados de un plan (si se requiere semánticamente ).
Además de always, también se admiten otras construcciones basadas en lógica temporal lineal , como sometime(al menos una vez durante el plan), sometime-after(para planificar después de un estado particular) y at-most-once(la preferencia se mantiene durante como máximo una secuencia de estados en el plan). ).
Además de determinar si se satisface una preferencia, también necesitamos calcular la calidad de un plan en función de cuántas preferencias se satisfacen. Para ello, PDDL 3.0 incluye una expresión denominada is-violated <name>que es igual al "número de preferencias distintas con el nombre de pila que no se satisfacen en el plan". [4] Para un plan, ahora se puede calcular un valor utilizando una función métrica, que se especifica con :metric:
(:metric minimize (+ (* 5 (is-violated pref1)) (* 7 (is-violated pref2))))Esta función métrica de ejemplo especifica que el valor calculado del plan debe minimizarse (es decir, un plan con valor v1 y un plan con valor v2 tal que v1 < v2 , el plan anterior es estrictamente preferido). El valor de un plan se calcula mediante la función dada, que se expresa en notación polaca . En este caso, la violación de la segunda preferencia, pref2, ha recibido una pena mayor que la de la primera preferencia, pref1.
En el área de los problemas de satisfacción de restricciones , existen variantes flexibles que abordan restricciones suaves de manera similar a las preferencias en la planificación basada en preferencias.