Приветствую, уважаемое сообщество!
Забегая вперед прошу прощения у тех, кто ожидает новизны или революционных идей. Их тут нет. Но есть вполне хорошая прикладная система.
Системы поддержки принятия решений сейчас набирают обороты. Причем я не буду особо останавливаться на перечислении способов реализации. Оговорюсь только об основных свойствах.
Я бы очень упрощенно и обобщенно назвал эти системы вероятностными. То есть они выдают рекомендации с известной долей вероятности используя накопленную и проанализированную статистику. Не скажу что это плохо. Тема BigData и Machine learning нынче в тренде. Так же эти системы работают по принципу черного ящика. Поэтому проверить достоверность работы заложенной модели не всегда можно выявить.
Я же постараюсь описать систему поддержки принятия решений основанную на несколько другом, кто-то может скажет и архаичном, принципе – условно назовем его оценочным. То есть система моделирует принцип того как человек реально действует – оценивает ситуацию и принимает решение на основе сделанной оценки в этой конкретной ситуации. А не на обобщенных данных.
Простейший пример: Вы входите в комнату. Оцениваете светло или нет. Если темно, то включаете свет и проходите в комнату. Если светло, то сразу проходите в комнату. И новая оценка…
Упрощенно примерно такой же подход использует и описываемое мной решение. То есть для принятия решения не проводится анализ на основании BigData с выявлением неких тенденций и закономерностей. А оценивается конкретная ситуация. И на основании конкретной оценки принимается вполне конкретное решение.
Чтобы избежать сильно большой критики могу сказать, что BigData очень даже полезны. И данные, полученные на их основе, должны использоваться в СППР. Но СППР не должна опираться на BigDta, как на фундаментальную основу. Это тема для отдельной дискуссии.
Предыстория
В основе решения лежит методика Частных алгоритмов действий врача. В данном случае добавлена абстракция и расширена сфера применения.
Способов алгоритмичных описаний много. Далеко не все бывают удобными. И уж тем более далеко не все могут претендовать на то, чтобы ими можно было одинаково хорошо описать экспертную систему. Да еще и в различных профессиональных областях.
Мне лично понравилась достаточно простая модель описания, которая использует 3 основных элемента: вопрос, ответ и рекомендация.
Примечательно, что данная методика позволила описать наиболее сложную с точки зрения формализации отрасль – медицину. То есть у данной методики было успешное практическое применение.
И еще немаловажно то, что при наличии инструментария, логику СППР могут создавать специалисты из своих профессиональных областей без привлечения разработчиков.
Для начала работы был взят на бумажном носителе алгоритм для специализированной бригады скорой помощи «Комы, Отравления, Коллапсы». Мне его в руки так и не отдали. Только временное использование. По сути это был набор карточек с инструкциями.
Идеологически хотелось получить решения для различных профессиональных областей кроме медицины. Поэтому было принято решение разрабатывать некую платформу, с помощью которой можно будет как создавать алгоритмы (создавать логику СППР), так и использовать созданную СППР. Был выбран путь не противопоставления системы уже существующим решениям, а наоборот, создать как дополнение, которое позволяет расширять функционал. То есть в системе должен быть API, который бы позволил встраиваться в существующие системы.
Реализация
Так и появилась концепция платформы СППР Универсальные алгоритмы. Которая стоит на 3-х китах:
• Методика создания и описания алгоритмической модели
• Алгоритм-Дизайнер – приложение для визуального создания и редактирования алгоритмов СППР
• Алгоритм-Навигатор – web-приложение, которое реализует использование логической модели СППР.
Всем понятно, что речь идет о графовой модели. Если честно не хотелось изобретать велосипед, но один недоброжелатель своим язвительным замечанием подтолкнул к тому чтобы нарисовать создаваемую модель. Поэтому было взятое готовое решение Graphviz, которое прекрасно справляется с такой задачей. Плюсом еще является и то, что данный пакет позволяет создавать интерактивные графы с URL.
Отрисовывать граф целого алгоритма нет смысла, иначе он не поместится на огромной стене. Поэтому был выбран путь создания графа для каждой ситуации. Если какой-то элемент ведет в другую ситуацию, то это так и отображается на графе.
Алгоритм-Дизайнер
Алгоритм-Дизайнер позволяет создавать логическую модель согласно методологии. Алгоритм по содержанию делится на ситуации. А в ситуациях реализуется модель рассуждений.
Алгоритм-Дизайнер – Windows приложение. Пока что не придумана концепция как еще можно реализовать весь функционал такого приложения в виде альтернативного решения (например web).
На скриншоте обозначены основные элементы в Алгоритм-Дизайнере:
- • Меню и панель инструментов – тут пояснения не требуются
- • Дерево алгоритма (дерево решений) – наиболее удобное отображение структуры алгоритма
- • Область для работы с «родительскими» элементами узла.
- • Область для отображения дочерних элементов узла.
- • Область для заполнения «Рекомендаций» и «пояснительных комментариев» — в этой области вносится текст рекомендации. Так же для остальных элементов позволяется вносить пояснительную или справочную информацию. Эта информация превращает алгоритм в справочное пособие для пользователя, когда ему может быть не понятен смысл предлагаемого на выбор элемента. На примере Алгоритм-Навигатора будет показан способ отображения таких комментариев.
- • Область «Репозиторий» — вспомогательный инструмент для хранения наиболее часто встречающихся логических конструкций. Чтобы не вводить повторно можно просто копировать из репозитория. И при изменении данных в репозитории, они автоматически реплицируются на все связанные элементы в дереве алгоритма.
Как уже упоминалось, на самом деле структура алгоритма представляет собой графовую модель. Но работать на прикладном уровне удобно с древовидной структурой. И логически разделять общую модель данных удобнее в древовидном представлении.
Основной логический элемент – Алгоритм.
Алгоритм может содержать вложенные элементы такого же типа. То есть элемент алгоритма «Скорая помощь» может содержать в себе элементы-алгоритмы для специализированных бригад скорой помощи.
Далее Алгоритм делится на Ситуации. Ситуация существует для того чтобы разделить Алгоритм на логические разделы. Это позволяет выделить отдельную логическую задачу из общего алгоритма.
Примечание: В терминах программирования можно считать, что Алгоритм – это программа, а Ситуация – подпрограмма, процедура или функция.
Естественно, что все элементы взаимосвязаны. Поэтому логические элементы Алгоритма позволяют устанавливать связи и переходы между Ситуациями.
Далее идет элемент – Вопрос. Система работает по принципу оценки «текущей ситуации». Поэтому она постоянно работает в режиме задавания вопроса и получения ответа от пользователя.
Ответ – логический элемент, связанный с вопросом. То, что пользователь будет выбирать для оценки «текущей ситуации»
Рекомендация – логический элемент, который на основании оценки предлагает, или требует выполнить некие действия. Рекомендации делятся на простые и те, что устанавливают время на исполнение. То есть для таких рекомендаций определяется временной промежуток, в течении которого должно быть выполнено действие прежде чем будет продолжено движение по алгоритму – минимальный и максимальный интервал.
Еще используется вспомогательный элемент – Закрыть линию. Это было продиктовано тем, что хотелось визуально выделить момент, когда заканчивается линия рассуждений. Этот элемент может использоваться многократно в алгоритме. В данном случае есть избыточность. Но ею лучше пренебречь ради наглядности.
Для чего понадобились «Работа с родительскими и дочерними элементами»?
Алгоритм – это граф. Но отображение древовидное. Следовательно, в дереве отображается только один родительский элемент узла. Что не отображает реальное положение вещей. Так же в дереве не видны все дочерние узлы, если они находятся в других ветках дерева. Так же нужен был механизм для установки таких связей.
Поэтому был реализован функционал назначения «Родителя» для узла. Дочерние элементы – это просто информативное отображение.
Для упрощения просмотра и тестирования в дереве при двойном клике на элементе осуществляется переход на 1-й дочерний узел. В том числе и на тот, который установлен в другой ветке. Обратное движение по дереву к родителям осуществляется двойным кликом в поле отображения дочерних узлов.
Логическая модель редактируема и открыта. Но визуальное представление делает ее еще более наглядной и понятной для более широкой аудитории без специальных знаний. В качестве средства визуализации был выбран инструмент Graphviz. Потому что строит диаграммы быстро, бесплатный и кроссплатформенный. Есть еще ряд преимуществ. Одно из них – это возможность строить интерактивные диаграммы. То есть каждый элемент может содержать в себе URL.
Отображать решено было по ситуациям. Так как весь алгоритм представляет собой довольно большое полотно, в котором трудно разобраться. Элементы диаграмм содержат в себе отображение всех текстов. Это касается Рекомендаций и дополнительных справочных комментариев-пояснений для Ответов. Это позволяет полностью отразить логическое и содержательное наполнение системы.
Для реализации были использованы Delphi, СУБД Firebird, Graphviz. Привязка к СУБД продиктована использованием компонента. Для использования в web-приложении Алгоритм-Навигатор база конвертировалась в MySql, SQLite и т.д.
Алгоритм-Навигатор
Алгоритм-Навигатор разработан как web-приложение с адаптивным дизайном. Вполне нормально смотрится на экранах с различными ориентацией и разрешением. Так же интерфейс достаточно простой для использования, чтобы не требовалось специальное обучение пользователя.
Я выбирал некоторое время способ реализации Алгоритм-Навигатора. Известно было, что это должно быть web-приложение, что должна быть возможность запуска на Linux и должен быть API для встраивания в другие информационные системы. Потому что изначально планировалось не противопоставлять систему уже существующим, а наоборот дополнять.
Для разработки был выбран Python. Фреймворк bottle (планирую все перенести на django). Тут не нужно особых пояснений. Я не являюсь специалистом в дизайне и занимаюсь проектом сам. Поэтому был взят готовый набор для front-end titon.io, который обладает всем необходимым функционалом.
Я верстал страницы так как они должны были выглядеть. А потом на их основе делал шаблоны.
Поскольку хотелось иметь функционал генерации диаграмм и в Алгоритм-Навигаторе, то был использован пакет pydot.
Порядок и принцип работы.
Алгоритм-Дизайнер позволяет создавать логическую модель. В принципе ее можно начинать использовать сразу после создания нескольких шагов.
По мере прохождения по алгоритму все шаги пользователя фиксируются. По ним происходит восстановление протокола. Это еще одна особенность данной методологии – при прохождении по алгоритму формируется протокол рассуждений специалиста. Который может быть использован как документ. Я планировал копирование текста в заявки системы сервис-деск.
Пример API
UID – ID пользователя алгоритма
OID – ID объекта. В данном случае может быть любой объект. В медицине – пациент.
Parameter list – набор параметров типа name=value для макроподстановки в текстах алгоритма. Как пример имя, название компании, название продукта.
Algorithm entry point – точка входа в алгоритм. Не всегда нужно начинать с самого начала. При вызове алгоритма из другой системы можно выбрать точку в алгоритме (ситуацию) с которой будет начата работа.
Примеры применения.
Прежде всего алгоритмы были созданы и использованы в медицине. Правда это происходило на карточках. Забавно было увидеть этот способ, когда из сотни карточек при помощи пары спиц выпадала нужная. Современные индексные поиски и запросы отдыхают по скорости предоставления данных пользователю.
Медицина: Диспетчер скорой помощи, Алгоритмы специализированных бригад скорой помощи (я упоминал Комы, Отравления, Коллапсы), Проф. осмотр, Пульманология, Кардиология, Педиатрия, Акушерство и Геникология, Алгоритм по взысканиям для ЛПУ.
Это не полный перечень.
Я уже описал попытку создания экспертной системы для службы поддержки в филиальной сети частной медицинской компании.
Пример критериального анализа CRM при условии, что критерии являются составными.
Скрипты разговоров и продаж услуг.
Возможность создания опросника для тайного покупателя.
Побочный эффект – возможность описания регламентов с помощью диаграмм.
Использовали для описания регламента для выписки пациентов
В своей работе так же описал процесс внедрения.
Предшествующие связанные публикации:
Часть 2. СППР Универсальные алгоритмы – Алгоритм для службы поддержки
Часть 3. Чат-бот Telegram на ядре логики СППР (в песочнице)
Автор: AlexVist
