Корпоративный поиск. Находим правильную метафору

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

В качестве причины того, почему молодые сотрудники не могут быстро найти нужные инструкции и распоряжения рассматривались две гипотезы. Одна принадлежала мне, другая – нашему CIO. Мое предположение заключалось в том, что издающие распоряжения руководители мало заботятся о том, чтоб кто-либо узнал об их существовании. Все усилия тратятся на то, что подготовить, согласовать и утвердить распоряжение. На что-либо большее сил у людей уже не остается. Потому свежеизданное распоряжение закидывают в дальний угол, где найти его достаточно проблематично. Вариант исправления этой ситуации, по моему наивному мнению, заключался в том, чтоб научить людей публиковать такого рода документы на едином централизованном ресурсе. Правильно их классифицировать, указывать зависимости между документами, назначить ответственных за категории и темы и т.д. В общем, типичный подход присущий архитектору информационных систем. Предположение нашего CIO, человека намного более опытного, заключалось в том, что никто описанной выше ерундой заниматься не будет и единственное возможное решение – простая, удобная в использовании и релевантная система корпоративного поиска. Именно это решение и легло в проект.

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

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

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

Это очень похоже на нереляционные базы данных. Вернее, на организацию индексов в виде нереляционных баз данных. Сами исходные документы – файлы или записи традиционных БД могут располагаться где угодно. Главное чтоб к объектам этих хранилищ можно было бы обратиться по ссылкам. Индексы же создаются отдельно. Получается архитектура, схематично нарисованная на заглавной картинке этого сообщения. Причем процесс добавления в индекс образа нового документа может быть как ручным, так и автоматическим. Кто выделяет ключевые слова из текста человек или алгоритм – вопрос второстепенный. Естественно современные поисковые системы содержат много других полезных вещей: парсеры запросов, адаптированные под конкретный язык анализаторы текстов, фасетные фильтры и т.п., но основа архитектуры – индексы формате «ключ=значения».

Несколько выводов и рекомендации.

  1. Корпоративный поиск – это функция, которая должна быстро и просто приводить пользователя к одному из нескольких тысяч (максимум десятков тысяч) документов. Это задача сильно отличается от поиска в Интернет, осуществляемого по огромному массиву информации. Как реализовывать эту функцию, построением каталогов и таксономий или формированием хорошего индекса для поисковой системы – вопрос важный, но вторичный
  2. Не надо противопоставлять структурированные и неструктурированные данные. Принято думать, что ECM системы используются для работы с неструктурированными данными. Но, на самом деле, индексы документов в ECM строятся в обычных реляционных моделях. В этом их сильная сторона, т.к. пользователи должны не только запихнуть документ в хранилище, но и заполнить обязательные поля в карточке документа. С другой стороны, в этом же слабая сторона ECM. Для создания нового типа документов нужно звать аналитика и программиста. Если это своевременно не сделано, то пользователи начинают засорять данные, вводя в обязательные поля всякую ерунду.
  3. Организация корпоративного поиска это, все же, задача для людей. Причем как для людей, владеющих предметной областью, так и разбирающихся в подходах к структурированию данных и возможностях современных информационных систем.

Еще несколько заметок по этой теме:

Корпоративный поиск. Находим правильную метафору: 3 комментария

  1. Не ит-архитектурное дополнение.

    “Мое предположение заключалось в том, что издающие распоряжения руководители мало заботятся о том, чтоб кто-либо узнал об их существовании…
    …Вариант исправления этой ситуации, по моему наивному мнению, заключался в том, чтоб научить людей публиковать такого рода документы на едином централизованном ресурсе. Правильно их классифицировать, указывать зависимости между документами, назначить ответственных за категории и темы и т.д.”

    Обычно (у нас так) забота о том чтобы тот, кому положено, узнал о существовании документа, была задача канцелярии. От руководителя требовалось только прописать в документе вполне разумные вещи – кто должен исполнять, кто отвечает за контроль, и передать в канцелярию.

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

    1. Это, безусловно, правильно. Наверное так когда-то и было. Но только с ростом размера организации или же при увеличении объема операций такого рода процессы рассыпаются. Люди перестают вести каталоги документов, актуализировать списки рассылки и т.д.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *