Лекция 13

Стадия реализации

Стадия реализации включает в себя перевод формализованных знаний на предыдущей стадии в схему представления, определяемую выбранным языком. Как только представленные по этой схеме знания становятся согласованными и организованными так, чтобы определить потоки информации и управления, они становятся рабочей программой.

Конструктор развивает схему представления знаний и использует ее для получения прототипного варианта ЭС. Предметно-ориентированные знания, выявленные и сформулированные на этапе формализации, определяют содержание структуры данных, правил ввода и стратегий управления. Схема представления определяет их форму. Локальная непротиворечивость используемых для решения элементов, которая была достигнута на предыдущих стадиях, не гарантирует работоспособности программы, так как могут быть глобальные несоответствия между структурами данных и какими-либо правилами или стратегиями управления.

Такие противоречия должны быть устранены, чтобы обеспечить быстрое развитие прототипного варианта ЭС. Создание прототипного варианта является исключительно важным шагом в процессе построения ЭС. Отдельные фрагменты этой, в конечном счете, выбрасываемой программы могут быть сохранены и использованы в более поздних версиях. Однако главной целью деятельности на данном этапе становится проверка соответствия формальной схемы основным используемым идеям.

Прототипная база знаний создается с помощью различных программных средств, имеющихся для выбранной схемы представления знаний (текстовые редакторы, интеллектуальные редакторы, программы для приобретения знаний). Если существующие средства оказываются неподходящими, то инженер знаний должен создать новое. Может даже случиться так, что потребуется разработать новую систему, предназначенную для построения ЭС или новый язык.

Стадия тестирования

Стадия тестирования предусматривает проверку прототипного варианта системы и схем представления знаний, использованных для создания этого варианта. Как только прототипный вариант может отработать от начала до конца на 2-3 примерах, он должен быть проверен на многих примерах для того, чтобы вывить дефекты в базе знаний и механизме логического вывода или дедуктивной машине.

Главными характеристиками ввода-вывода являются приобретение данных и представление результатов. Конкретный метод приобретения данных может оказаться ошибочным или неподходящим из-за того, что неверные вопросы задаются по ходу работы или собирается недостаточно информации. Например, задаваемые вопросы могут быть трудными для понимания, двусмысленными или плохо сформулированными для пользователя системы. Сама система может быть неудобной для работы, в ней может отсутствовать возможность для пользователя прервать ход вычислений, чтобы ввести данные в соответствии с предпочитаемым порядком и формой.

Наиболее очевидное место для поиска ошибок в рассуждениях – множество правил вывода. Они редко бывают независимыми друг от друга. Помимо всего прочего, правила могут быть неправильными, противоречивыми, неполными или отсутствовать. Если посылки в правиле определены неверно, оно может прилагаться в неправильном контексте, нарушая, таким образом, всю логику. В таких случаях очень часто не удается замечать подслучаи. Заключение правила может быть неправильным часто по своему смыслу или по возможности различать подслучаи. Но даже если посылки и заключения верны, они могут быть связаны неправильными мерами присоединения. Так как правила не являются независимыми, то должно учитываться их влияние на другие правила.

Оценки, степени уверенности, веса связей играют важную роль, и они не могут присваиваться независимо от того, как группы правил будут использоваться в контексте конкретных случаев.

Часто ошибки в прототипной версии возникают из-за использованных стратегий управления. Если система рассматривает гипотезы в порядке, отличном от соответствующего порядка, которого придерживается эксперт, то конструктор должен проанализировать дедуктивную машину.