Cтраница 1
Разработчик знаний берет набор представленных проблем и обсуждает их с экспертом. Цель состоит в том, чтобы определить, как эксперт организует знания в каждой проблеме, представляет концепции и гипотезы, обращается с несовместимыми, ошибочными, искаженными знаниями и данными, относящимися к проблеме. [1]
Разработчик знаний задает вопросы эксперту, чтобы решить ряд проблем, проверяя доводы эксперта при решении этих проблем. По мере того как эксперт решает каждую проблему, разработчик знаний обеспечивает его новыми данными. Эксперт должен решать реалистические проблемы, описывая процесс решения вслух и выделяя промежуточные шаги насколько возможно. Разработчик знаний задает вопрос к каждому шагу, чтобы определить стоящую за ним сущность, включая принимаемые гипотезы и используемые стратегии для получения этих гипотез, поставленные ы ели и выбор стратегии для ее достижения. [2]
Разработчик знаний предоставляет другим экспертам примеры, решаемые экспертом, и прототипы системы. Это обеспечивает сравнение стратегии выбора разных экспертов и точки рассогласования. Умелый разработчик знаний может разбить на части знания эксперта, используя только что описанные методы. А еще более искусный разработчик знаний может ввести в окончательную систему эвристические методы и оперативные процедуры, совершенствующие ход рассуждений системы. [3]
Эксперт предлагает разработчику знаний проблемы для решения, упорядочивая их от легких к более трудным. Прежде чем экспертная система станет действующей, разработчик знаний проводит решения на бумаге, используя концепции, формализмы и правила, приобретенные у эксперта. Это обеспечивает быстрый контроль содержания и завершенности знаний при извлечении их у эксперта. Как только экспертная система сможет работать, даже в ограниченном объеме, разработчик знаний должен использовать ее для решения проблем, предложенных экспертом. [4]
Микропрограммирование является сложным делом, требующим от разработчика знания программирования и аппаратных средств. В начале раздела рассмотрена общая схема гипотетической машины, затем обсуждаются функции микроопераций и в конце раздела приведены простые микропрограммы. [5]
Методы извлечения знаний у эксперта. [6] |
Парадокс разработки знаний предполагает второе указание, предназначенное разработчику знаний: не верьте всему, что говорит эксперт. Разработчик знаний должен знать, что подтверждение правил экспертизы происходит не только по причине того, что эксперт ручается за точность правил, но и потому, что эксперт демонстрирует использование правила в процессе решения проблемы. [7]
Широкий ассортимент интегральных полупроводниковых микросхем различного назначения, принципы построения и организации которых рассмотрены в данном пособии, требует от разработчика МЭА знаний их схемотехнических особенностей и конструктивного оформления. Вопросам создания полупроводниковых микроэлектронных устройств на БМК и ПЛУ посвящена следующая книга данной серии. [8]
Процесс приобретения знаний при разработке экспертной системы. [9] |
Например, рассмотрим проблему построения экспертной системы в помощь адвокатам. Разработчик знаний должен обеспечить эксперта описаниями реальных случаев, включая показания свидетелей и следователей, медицинскую экспертизу, необходимые фотографии и документы. После того как эксперт изучит материал, разработчик знаний ( называемый также инженером по знаниям) спрашивает эксперта, как детально он будет пытаться найти решение в каждом отдельном случае. Разработчик знаний может изучать все стороны каждого случая, изменяя в нем факты и отмечая, как эксперт упорядочивает изменяющиеся условия. [10]
Методы извлечения знаний у эксперта. [11] |
Парадокс разработки знаний предполагает второе указание, предназначенное разработчику знаний: не верьте всему, что говорит эксперт. Разработчик знаний должен знать, что подтверждение правил экспертизы происходит не только по причине того, что эксперт ручается за точность правил, но и потому, что эксперт демонстрирует использование правила в процессе решения проблемы. [12]
У разработчика есть описанная экспертом типовая проблема с основной категорией возникших ответов. Это помогает разработчику знаний определить прототип проблемы с категорией ответов, чтобы построить экспертную систему, которая использует этот прототип в своем решении. Этот пример может также предложить способы организации иерархических знаний в экспертной системе. Данный подход работает особенно хорошо в проблемах диагностического типа, таких, как медицинская диагностика и комплектование электронного оборудования. [13]
Методы извлечения знаний у эксперта. [14] |
Если вы являетесь разработчиком знаний, который тщательно изучает предметную область, работайте с настоящим экспертом в каком-либо аспекте. [15]