Прототип этой системы я пытался создать в гордом одиночестве. Результат был для меня очевиден с самого начала - это неудача. Причина проста. Подобные программные комплексы не создаются одиночными программистами (даже прототипы, и даже если программист гениален).

Я, правда, грешным делом надеялся найти в процессе работы спонсоров. Но потерпел неудачу и в этом начинании (вот если бы я нефть добывал, это было бы другим делом). Работы пришлось остановить. Однако эта мое нытье имеет отношение только к моей попытке создания готового продукта, а никак к самой идее, которую я считаю прогрессивной и перспективной.

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

К сожалению, написание технического задания мой заказчик не смог выполнить самостоятельно. Не хватало компетентности. Однако центральная идея в технологическом цикле при решении любых проблем меня увлекла. Я решил сделать сам постановку задачи и реализовать ее в жизни (запрограммировать). От программного обеспечения у меня уже ничего не осталось. А вот постановку задачи я напишу в этой статье. Правда, в сокращенном виде.

Как всегда я буду рисовать диаграммы. Мне кажется, что с помощью рисунков проще самому понимать то, что пытаешься объяснить другому человеку. Более того, я стараюсь в своих статьях (на сайте) не приводить очень детальное обсуждение всех аспектов моих идей (поскольку Интернет сайт требует, чтобы количество текста в рамках одной статьи было ограниченно). А рисунки сильно помогают при ограничениях, установленных на объемы текстов, при обсуждении проблемы.

Конечно, я могу создать новый веб ресурс, в котором были бы сняты ограничения по размеру текстов (это требование является частью представленной постановки задачи). Собственно, по этой причине (создание нового движка) я пытался создать прототип сайта по описываемой в этой статье технологии. Mea culpa, сил не хватило. Но все - хватит хандрить, пора вернуться к основной теме нашего обсуждения.

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

Итак. Меня будет интересовать коллегиальная (экспертная) схема принятия решений или разрешения проблем.

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

Прежде всего, надо сформулировать общее понимание проблемы. Если это сделать сложно, то проблему надо разложить (произвести декомпозицию) на более мелкие проблемы (из которых она состоит) и потом заниматься их поэтапным решением. В результате решения частичных проблем будет достигнута глобальная цель. Так, например, было начато покорение космоса человеком.

На моем рисунке схематически изображена технология решения только одной проблемы (Problem Decision). Но никто не мешает трансформировать эту схему на решение комплексной и сложной проблемы.

У каждого эксперта в коллегиальной схеме принятия решения есть свое собственное мнение (Expert opinion X). Это очевидно. Однако мнения могут совпадать, совпадать частично или не совпадать. Можно в соответствии со степенью совпадения понимания проблемы поставить численные оценки. В дальнейшем их стоит использовать в качестве показателя релевантности понимания при и в процессе решения проблемы.

Но в самом начале обсуждения проблемы мы этого можем и не знать. Для этого мы должны обсудить мнения экспертов (хотя бы мнение друг друга). При этом не обязательно, что в обсуждении будут принимать участие только члены экспертного совета. Это могут быть привлеченные сторонние эксперты.

В результате, мнение каждого эксперта будут нивелироваться, и приводиться в соответствие с пониманием проблемы остальными экспертами (будет создаваться своего рода единая карта решения проблемы).

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

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

Только не стоит думать, что каждый раз при обсуждении новой проблемы нам надо заново формировать терминологическую базу знаний (Terminological base). Для любой отрасли деятельности человека (точнее можно написать для конкретного вида бизнеса) подобная база знаний терминов формируется практически один раз. В дальнейшем она просто уточняется и расширяется.

Я недаром нарисовал в своей схеме использование априорного опыта (Aprioristic experience). А последующий опыт (Subsequent experience) уже будет важен при решении аналогичных проблем в будущем. На самом деле, предыдущий и последующий опыт, в сущности, представляют собой историю принятия решения. В моей диаграмме нет шкалы времени, но ее можно смело нарисовать.

В результате обсуждения мы получим несколько направлений решения нашей проблемы. Эти конкретные направления решения проблемы можно, в конце концов, обобщить. А это позволить сформировать базу шаблонов - паттернов (так, например, устроена прецедентная правовая система).

Шаблоны (Pattern) играю важную роль в жизни человека. Я не буду писать о том, что такое NLP и на основе чего оно строится. Я просто напомню вам только о том, что простой поход в магазин строится на основе шаблонов. В случае магазина - это просто список покупок и выделенный на это бюджет (естественно, в каждом конкретном случае этот шаблон уточняется в зависимости от ситуации). В результате мы получаем не только решение текущей проблемы, но и уточненные паттерны решения аналогичных проблем в будущем.

Все. Обсуждение концепции я закончил. Если кому-то что-то непонятно, то приглашайте меня в гости, и я вам все детально объясню. А теперь пора поговорить о программном обеспечении (software).

Я являюсь сторонником развития компьютерной сети Интернет, как коммерческой основы для развития услуг по аренде программного обеспечения и информационного фундамента глобализации мировой экономики. Посему моя постановка задачи будет выполнена на базе Интернет решения (без указания конкретных инструментальных средств).

Прежде всего, начнем с того, что изобретать велосипед, и по второму разу открывать Америку я не буду.

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

Можете для примера посмотреть на мой веб ресурс. Хороший образчик обсуждения решений для проблем в менеджменте одним экспертом на основе статичных текстов. Это первый тип информационных объектов - статические статьи (Articles) - или детальные исследования. Причем публиковаться они могут разными авторами.

Вторым типом ресурсов, предназначенных для решения проблем, являются специализированные конференции или статические обсуждения (Reviewing). Как правило, такие обсуждения могут (и должны иметь) древовидную структуру. Это уже очевидно из опыта эксплуатации существующих веб конференций. Древовидная структура позволяет формировать цепочку обсуждений не только в рамках решения проблемы, но и в рамках единичной реплики эксперта. Естественно, надо ограничить глубину возможных вложений. На мой взгляд, достаточно 3-5 уровней иерархии.

Третий тип - чаты (Dialogue). В реальности лучше использовать не технологию чатов, а технологию обмена мгновенными сообщениями. Это удобнее. Поскольку позволяет снизить нагрузку на любого эксперта при обсуждении проблемы в режиме реального времени.

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

Следующий момент - поисковые возможности. Сегодня они поддерживаются на двух технологических уровнях - внутренние поисковые возможности и внешние поисковые системы (например, Google.com, Yandex.ru, Yahoo.com, Msn.com и тому подобных).

Внешние поисковые системы можно использовать в качестве аналитической основы при априорных исследованиях проблемы. Также существующие поисковые системы стоит задействовать для конкретизации в решении проблемы (поиск поставщиков, технологий, продуктов, услуг и так далее). Не стоит забывать и о коммерческой стороне проекта. Без правильного использования внешних поисковых систем невозможно создать большой трафик (большое количество посещений) на данный ресурс.

Внутренние поисковые возможности предназначены для облегчения работы экспертов. Я надеюсь, что этот факт является для вас очевидным и обсуждать тут нечего.

Теперь давайте поговорим о том, а что же я предлагаю добавить в эти схемы.

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

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

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

Последняя добавка.

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

На самом деле, это есть надводная часть айсберга под названием конкретизация предложения (по товарам, услугам, компаниям). Она необходима на этапе решения проблемы. Конечно, мы можем воспользоваться уже существующими специализированными ресурсами. Но это не всегда удобно. Поскольку мы не можем ранжировать участников независимых каталогов (например, по надежности, по партнерской дисциплине и так далее). А в собственной системе мы это можем сделать. В результате, мы получим список производителей ранжированных в соответствии с экспертными заключениями.

В моем тестовом программном обеспечении (веб сайте) было реализовано: статические статьи, поиск, обсуждения, терминология с поддержкой обсуждения, каталог с поддержкой ранжирования. Не было аналитики, чата и много еще чего.

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

Последнее изменение: 30.03.2006