nowanie nad jej poprawnością. Wypełnianie tego szkieletu z równoczesnym testowaniem pozwala na pewne i wiarygodne rozbudowywanie bazy do rozmiarów problemu., jaki ma być rozwiązywany przy jej pomocy .
Podczas projektowania reguł należy dbać o to, aby ich interpretacja była oczywista dla użytkownika. Chodzi o to, aby nie miał wątpliwością czego dotyczą pytania systemu oraz nie miał trudności ze sformułowaniem odpowiedzi. Reguły muszą tworzyć taką strukturę, która w procesie wnioskowania będzie powodowała przechodzenie od problemów ogólnych do coraz bardziej szczegółowych. Dzięki temu pytania zadawane przez system będą tworzyć pewien ciąg myślowy. Nie powinny padać pytania należące do zablokowanych ścieżek rozumowania. Na przykład w systemie diagnozowania uszkodzeń samochodu, jeśli z dialogu z użytkownikiem wynika, że uszkodzenie polega na przerywanej pracy silnika i jest spowodowane awarią gaźnika (a nie układu zapłonowego) - system nie powinien zadawać dalszych pytań o stan instalacji elektrycznej, gdyż pytania te są zbędne.
Łączenie wiedzy pochodzącej z różnych źródeł wiąże się na ogół z problemem rozbieżności zdań ekspertów w tej samej dziedznie. W takich przypadkach autoryzowanie reguł oraz informowanie użytkownika o tych rozbieżnościach poprawia jakość systemu. Warto też przyporządkowywać wagi lub współczynniki prawdopodobieństwa poszczególnym hipotezom.
Projektant systemu musi być skłonny do ciągłej jego adaptacji w dynamicznie (wraz z rozwojem nauki i praktyki) zmieniającym się środowisku. Po każdej aktualizacji bazy wiedzy należy sprawdzić poprawność działania systemu. Przy niewielkich korekcjach badanie całej przestrzeni stanów nie jest konieczne, wystarczy przetestować tylko poprawiane ścieżki rozumowania.
69