Интервью. Как Создать Качественную Базу Знаний: Подбор Технологий, Поиск И Дальнейшая Поддержка

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

Но суть одна: там хранится информация, доступ к которой необходим для решения тех или иных задач.

), кто будет ею пользоваться (сотрудники или, наоборот, клиенты и пользователи), будет ли она перенесли и если да, то как.

Важно понимать: недостаточно просто создать базу знаний и начать добавлять в нее информацию.

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

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

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

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

Стоит ли создавать инструмент самому или на основе существующих? Это сложный вопрос и на него сложно ответить однозначно.

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

На практике такие базы очень быстро приходят в негодность, так как сильно разрастаются и появляются все связанные с этим проблемы.

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

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

Изначально SharePoint не предназначался специально для создания баз знаний, но корпоративная инфраструктура клиентов была сильно привязана к этой технологии.

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

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

создавать и поддерживать.

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

Основная его проблема: из-за огромных объемов хранимого контента найти там что-то конкретное практически невозможно.

Этот факт стал одним из преимуществ ресурса Stack Overflow: одно время существовали очень распространенные темы, в которых люди делились ссылками на конкретные статьи из MSDN — по сути, это был единственный способ найти там то, что вам нужно.

У Microsoft были и другие попытки создать базу знаний.

Другой проект назывался TechNet Wiki, и его идея заключалась в привлечении сообщества пользователей к обслуживанию базы данных.

Предполагалось, что люди будут сами писать статьи, расставлять в них теги и так далее.

Сам wiki-движок базы данных был интегрирован с корпоративной АТС.

Для ускорения обслуживания клиентов в данной системе реализовано сочетание механизма распознавания речи и поиска информации в базе данных по ключевым словам.

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

Звучит серьезно, но в современных базах знаний используются и более продвинутые подходы — например, Ontology Search, который позволяет создавать целые иерархии вложенных тегов, зависящих друг от друга, и соответственно получать более точные результаты при поиске статей.

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