Inconvénients

  Les inconvénients de l'architecture sont multiples, mais chacun d'entre eux est soit une contrepartie d'un de ses avantages, soit un problème dû à la jeunesse du système...

Sous-optimalité :

 les résultats fournis peuvent être qualifiés de sous-optimaux, c'est-à-dire que le résultat optimal n'est pas forcément fourni à chaque exécution (mais cela dépend grandement de l'application et de sa difficulté). C'est une contrepartie à la créativité et à la diversité des résultats fournis.

Indéterminisme :

toujours à cause de la variété des résultats, due à la gestion particulière du déterminisme, les résultats ne sont pas prévisibles, ils dépendent d'une série de choix aléatoires. Ce qui, comme nous l'avons dit dans la partie Avantages - Créativité est un inconvénient dans les applications où l'on cherche une solution optimale plutôt qu'une solution rapide.

Pas d'explication :

 le système est incapable de fournir une explication aux résultats fournis, tout comme un humain n'est pas forcément capable de dire comment il a reconnu un visage, ou d'expliquer une impression de déjà-vu. Une manière de faire serait de transcrire toutes les actions, et l'état du système (Réseau de Concepts et Blackboard) à chaque cycle, mais il faudrait encore les interpréter. BASCET n'est clairement pas ce qu'on appelle un « système expert ».

Beaucoup de paramètres différents :

 les paramètres à régler sont un frein à l'exploitation du système, parce qu'ils sont nombreux et ont une influence non négligeable sur son comportement.

• Le nombre d'agents à exécuter à chaque cycle. Ce paramètre influe directement sur les temps d'exécution du système, car c'est généralement l'exécution des agents qui prend le plus de temps (et pas la propagation des activations, par exemple). Lorsqu'on exécute beaucoup d'agents, on privilégie un parcours des solutions presqu'exhaustif (c'est-à-dire qu'on examine le plus de solutions possibles, en commençant par les plus pertinentes). Au contraire, quand on diminue le nombre d'agents exécutés, on limite les solutions examinées aux plus pertinentes. On obtient aussi une sorte d'« effet retard » dû au fait que les agents les plus pertinents mais non choisis restent dans le Réservoir d'Agents pour les cycles suivant. Au fur et à mesure ces agents vont devenir de plus en plus prioritaires et être exécutés dans les cycles suivants. Ce sont donc principalement les noeuds les plus activés au début du traitement qui verront leurs agents exécutés pendant le traitement.
• Le seuil d'activation , à partir duquel un noeud est considéré comme activé (pour qu'il puisse poster ses agents dans le Réservoir d'Agents). C'est un paramètre qui conditionne le nombre d'agents postés dans le Réservoir d'Agents. Plus ce seuil est bas, plus le parcours des solutions est exhaustif. Au contraire, s'il est trop haut, on risque de ne pas trouver de noeuds activés. En effet, il faut un certain nombre de propagations de l'activation avant qu'un noeud puisse être activé par les noeuds qui l'influencent. Si ces noeuds influant sont désactivés avant que ce noeud soit considéré comme actif, il ne le sera jamais. Il est donc capital de bien choisir le seuil. Une valeur souvent utilisée est 50. Mais cette valeur dépend en fait des taux de désactivation et des liens inter-noeuds du Réseau de Concepts.
• La formule de normalisation des valeurs d'urgence  selon la température (formule 3.5, page ). Elle conditionne le déterminisme du système. Celle utilisée pour l'instant ne permet pas au système d'être complètement déterministe lorsque la température est nulle. Mais il est malgré tout préférable d'avoir une formule qui fasse un passage continu entre l'indéterminisme (qu'on a bien lorsque la température est au maximum) et le déterminisme qu'on veut avoir. Dès lors, une solution du genre du choix de l'agent ayant la plus grande valeur d'urgence quand la température est basse n'est pas viable, car trop brusque.

La difficulté principale du réglage de ces paramètres vient de leur forte inter-dépendance. En modifier un signifie aussi modifier l'influence des autres sur le comportement du système. Il est donc souhaitable d'étudier chaque paramètre séparément, en lançant une procédure de test pour chaque changement d'un seul paramètre. Nous n'avons pas pu prendre le temps d'effectuer ces tests séparés, car nous avons jugé plus urgent de construire d'abord un système qui fonctionne entièrement. Cette partie de réglage du modèle reste à faire...

Construction du Réseau de Concepts:

 la construction d'un modèle pour un système à base de connaissance est en général un problème difficile, qui réclame deux expertises : celle du système et celle du domaine. Ceci est vrai aussi pour BASCET. Il y est en général difficile de déterminer les poids des liens, les importances conceptuelles des noeuds, leurs taux de désactivation, ainsi que les taux d'urgence de leurs agents. On l'a vu plus haut, ces paramètres conditionnent le comportement du système. Mais il existe des applications dans lesquelles certaines de ces valeurs sont plus faciles à fixer : par exemple, lorsqu'on utilise des co-occurrences entre noeuds, on peut utiliser la formule d'influence d'un noeud sur l'autre.

Cohérence des agents (satisfaction) :

 une des principales difficultés de l'écriture (ou de la réutilisation) des agents est la cohérence de leurs interventions dans le Blackboard. En effet, lorsque des agents différents y construisent des objets en leur donnant une satisfaction , il faut faire attention à ce qu'un objet dont la valeur de satisfaction est plus élevée que celle d'un deuxième objet soit vraiment plus satisfaisant. En effet, c'est souvent cette valeur qui permet de décider, lorsqu'un agent veut remplacer un objet par un autre, s'il peut le faire ou non. Il est donc primordial que les échelles de satisfaction des différents agents soient très proches, sinon identiques.

Inhibition des agents :

 lorsqu'un noeud a été instancié, c'est qu'un agent de ce noeud en a construit une instance dans le Blackboard. Par conséquent, le noeud est activé, et se désactivera lentement (parce qu'il a au moins une instance). Or quand un noeud est activé, il poste ses agents dans le Réservoir d'Agents. Ce qui fait que cet agent aura une forte valeur d'urgence, et donc de fortes chances d'être exécuté -pour rien- très rapidement. Mais il se peut que les instances du noeud soient ensuite détruites pour diverses raisons par des agents d'autres noeuds. Il faut donc que les agents du noeud soient relancés pour voir si c'était une erreur, auquel cas, ils pourraient reconstruire l'objet. Nous avons donc introduit un mécanisme d'inhibition des agents : un agent peut s'inhiber pour un certain nombre de cycles. C'est ce nombre qu'il est difficile de déterminer (à estimer selon les applications et le Réseau de Concepts). De la même manière, il peut réactiver des agents inhibés s'il sait qu'après avoir construit un objet, la suite logique est la construction d'une instance d'un autre noeud. C'est une sorte de raccourci pour anticiper le comportement du Réseau de Concepts.