Этап 5 оценивает пригодность ЭС для конечного пользователя. При этом разработчики стараются привлечь как можно больше пользователей различной квалификации, которые могут обращаться к системе для реализации разнообразных запросов. Для того, чтобы не дискредитировать систему в глазах пользователя, разработчики перед этим этапом должны устранить все ошибки в работе системы, даже мелкие технические ошибки. Пользователь анализирует систему с точки зрения полезности (возможность системы в ходе диалога определить потребности пользователя, выявить и устранить причины его неудач в работе) и удобства (настраиваемость на уровень квалификации пользователя, а также устойчивость к ошибкам).
По результатам 5-го этапа может понадобиться не только модификация программного обеспечения, но и идеологии разработки интерфейса.
Этап 6. Призван осуществлять оценку системы в целом. Тут необходимо особое внимание уделить подбору тестовых примеров. В них должны найти отражение следующие случаи:
* неверно сформулированныые вопросы пользователя;
* присутствие неопределенности в вопросах пользователя;
* доступность для пользователя лексики системы;
* доступность для пользователя объяснений, которые выдает система;
* проиворечивость и неполнота правил;
* согласование контекстов действия правил.
По результатам 6-го этапа осуществляется модификация системы. Наиболее простым её видом явл-ся усовершенствование прототипов. Этот вид затрагивает только этапы 4 и 6.
Более серьёзным видом модификации явл-ся переконструирование представлений. Этот вид модификации необходим в том случае, если обнаруживается, что желаемое поведение системы не достигнуто. Предполагается возврат на этап формализации и далее осуществляется весь цикл проектирования. Если проблемы функционирования системы еще более серьёзны, то приходится возвращаться на этапы 2 и 1 для переформулирования требований к системе и основных понятий.
3. Практические аспекты разработки и внедрения ЭС.
В соответствии с результатами тестирования ЭС может находиться на одной из следующих стадий:
1) демонстрационный прототип (решает только часть задач в рамках ПО, демонстрируя правильность выбранного аппарата логического вывода). Срок доведения системы до этой стадии - около 3-х мес., кол-во правил в базе знаний - 50-100.
2) исследовательский прототип (решает все задачи в рамках ПО, на недостаточно устойчива в работе, не полностью проверена). Срок доведения - 1-2 года, кол-во правил - 200-500.
3) действующий прототип (решает стабильно все задачи в рамках ПО, но недостаточно эффективна в работе, в том числе нерациональное использование памяти, невысокое быстродействие). 2-3 г., 500-1000.
4) промышленная система (обеспчивает эффективную работу и высокое качество решений, содержит по сравнению со стадией 3 намного больше правил в базе знаний, программное обеспечение по сравнению с 3) переписано на язык низкого уровня). 2-4 г., 1000-1500.
5) коммерческая система (предполагает обобщение задач, уход от специфики ПО, предназначается для продажи другим потребителям. Развита по сравнинию с 4) система редактирования знаний, интерфейса с конкретным пользователем, обучения). 3-6 лет, 1000-3000.
В процессе проектирования ЭС следует учитывать тот отрицательный опыт, который накоплен разработчиками на каждой стадии проектирования.
На этапе 1 может оказаться, что система или задача настолько трудна, что её нельзя реализовать в рамках выдеенной проектировщиком системы ресурсов (время, деньги и т. д.). Проектировщики должны очень внимательно подойти к вопросу, сможет ли решение задачи принести существенную пользу, для пресонала, который её эксплуатирует. Следует учесть, что для сокращения времени проектирования нельзя расширять состав проектировщиков, так как процесс проектирования итеративный и категории проектировщиков не могут в сжатые сроки осмыслить все этапы проектирования.
Традиционной ошибкой этапа 3 явл-ся подгонка инструментального средства под понятия и взаимосвязи конкретной ПО.
Нельзя соглашаться при разработке прототипа на программирования сразу же на языках низкого уровня, т. е. без использования инструментальной системы.
На всех стадиях проектирования инженер по знаниям работает с экспертом и при этом возникает целый ряд трудностей, которые заранее надо учитывать:
* эксперты всегда должны быть высококвалифицированными, их нужно заинтересовывать материально;
* эксперт никогда не может найти время на работу с инженером по знаниям;
* в системе обязательно должна использоваться та же терминология, что и у экспертов ПО; только в этом случае эксперт может успешно понимать структуру базы знаний и вносить в неё соответствующие изменения;
* с течением времени эксперт теряет интерес к проекту системы и постоянно сокращает время работы с проектировщиком. Для устранения этого проектировщик вносит изменения в систему только вместе с экспертом, тестирует также вместе с ним;
* эксперт незнаком, как правило, с компьютером, поэтому РС устанавливается на его рабочем месте и доработка системы производится там же;
* при извлечении знаний эксперта проектировщику очень трудно отделить знания ПО от метазнаний, поэтому работа с экспертом должна происходить не по всем вопросам в целом, а по строго спланированным инженером по знаниям порциям.
На этапе 4 при разработке прототипа следует стремиться не разрабатывать самостоятельно средства объяснения, а использовать только те, что есть в инструментальной системе.
При разработке первого прототипа необходимо стремиться к тому, чтобы в базу знаний попали простые универсальные правила и сокращать количество специфических правил.
На этапе 6 следует учитывать, что если размер правил превышает 300, то их исправление и добавление может привести к появлению новых ошибок, поэтому должен существовать специальный тест, который проверяет систему на непротиворечивость правил.
Особенности реализации экспертных систем на базе логической модели знаний.
1. Понятие логической модели знаний.
2. Характеристика языка предикатов первого порядка. Особенности
представления знаний.
3. Аппарат логического вывода.
4. Особенности машинной реализации языка предикатов первого порядка.
1. Понятие логической модели знаний.
В основе лог. модели знаний лежит понятие формальной теории и отношения, которые существуют между единицами знаний можно описывать только с помощью синтаксических правил, допустимых в рамках этой теории.
Формальная теория задается всегда четверкой символов S=<B, F, A, R>, где
В - конечное множество базовых символов, иначе - алфавит теории S;
F - подмножество выражений теории S, называемых формулами теории. Обычно имеется эффективная процедура, которая представляет собой совокупность правил, позволяющих из элементов множества В строить синтаксически правильные выражения.
А - выделенное множество правил, называемых аксиомами теории, т. е. множество априорно истинных формул.
R - конечное множество отношений { r1, r2, ... , rn } между формулами, называемыми правилами вывода. Для любого ri существует целое положительное число j, такое, что для каждого множества, состоящего из j формул, и для каждой формулы F эффективно решается вопрос о том, находятся ли эти j-формулы в отношении ri с формулой F. Если ri выполняется, то F называют непосредственным следствием F-формул по правилу ri.
Следствием (выводом) формулы в теории S называется такая последовательность правил, что для любого из них представленная формула явл-ся либо аксиомой теории S, либо непосредственным следствием.
Правила вывода, которые разрабатываются проектировщиками, позволдяют расширить множество формул, которые явл-ся аксиомами теории.
Формальная теория наз. разрешимой, если существует эффективная процедура, позволяющая узнать для любой заданной формулы, существует ли её вывод в теории S.
Формальная теория S наз. Непротиаворечивой, если не существует такой формулы А, что и А, и не А выводимы в данной теории.
Наиболее распространенной формальной теорией, используемой в системах искуственного интеллекта явл-ся исчисление предикатов, то есть функций, которые могут принимать только 2 значения.
К достоинствам логической модели относят:
- наличие стандартной типовой процедуры логического вывода (доказательства теорем). Однако такое единообразие влечет за собой основной недостаток модели - сложность использования в процессе логического вывода эвристик, отражающих специфику ПО.
К другим недостаткам логической модели относят:
- “монотонность”;
- “комбинаторный взрыв”;
- слабость структурированности описаний.
2. Характеристика языка предикатов первого порядка.Особенности представления знаний.
В основе языка предикатов первого порядка лежит понятие предикатов, то есть логическая функция от одной или нескольких нелогических пременных. Функция может принимать значения истина (t) или ложь (f). В рамках логики утверждение считается истинным, если и относящееся к нему предположение считается истинным и заключение самого утверждения тоже истина.
Синтаксис языка предикатов включает: предикативные символы, символы переменных, константы (?), а также разделители ( ), [ ], “, ‘.
Предикативные символы используются для обозначения отношений. Объекты отношений записываются в ( ) после предикативного символа и наз-ся аргументами. Полная запись отношения наз-ся атомной или атомарной формулой.