Глава 1     Глава 2     Глава 3   

Предпосылки создания KXEN 2


В результате появляются следующие требования:

1.             Четкий и лаконичный API.

2.             Возможность интеграции в любой пользовательский интерфейс.

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

4.             Возможность внедрения моделей в операционную среду компании.

Выполнение этого требования дает возможность не только производить моделирование в режиме on-line, но и экспортировать построенные модели, используя другие программные языки, например Java, SQL, PMML и др. Встраивание модели KXEN в виде программного кода в рабочую базу данных позволяет производить анализ и получать прогнозную оценку в регулярном режиме.

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

Примером такого партнерства является специальный модуль KXEN для Clementine, хорошо известного приложения Data Mining от SPSS, который интересен как с точки зрения самой интеграции приложений, так и сочетания KXEN с более традиционными техниками Data Mining.

И еще один вопрос, который часто задается потенциальными партнерами: "Зачем мне встраивать технологию KXEN вместо того, чтобы просто связать свое приложение с приложением одного из вендоров (продавцов) Data Mining?" Ответ на этот вопрос следующий: практический опыт показал, что использование дескриптивного анализа и прогнозирования не заканчивается построением модели. Данные меняются со временем, и необходимо периодически производить мониторинг эффективности моделей с целью принятия решения об их корректировке или выставления меток в операционной среде. Компания KXEN включила управление конфигурацией модели в API, тем самым обеспечив сигнализацию об автоматическом выявлении отклонений на входных распределениях или во взаимосвязях входов-выходов. Очевидно, в последнем случае необходимо использование надежных методов, потому что статистические отклонения в производительности модели не должны являться следствием техники моделирования, но должны идентифицировать различия в данных, которые требуется моделировать.

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

•              выявлять отклонения в операционной среде;

•              запускать переобучение моделей;

•              использовать эти модели в режиме реального времени или в процессе пакетной обработки;
•              строить операционные пользовательские интерфейсы, которые будут использовать все возможности по построению моделей.