Множатся и ширятся на ИТ-рынке "платформы" для создания баз знаний. Тут тебе и персональные, и корпоративные - бесплатно и за большие деньги. Казалось бы - бери и радуйся! Но не всё так "шоколадно", как преподносят разработчики. При детальном рассмотрении на текущем рынке представлены всего 3 (Три) класса продуктов для создания баз знаний. На почетном первом месте - многочисленные вики-подобные решения. Они могут отличаться друг от друга визуально, но по предлагаемым функциям - это старая добрая Вики-машина. Идеологически она рассчитана на коллектив авторов, которые заполняют ее контентом. Всё вручную - и страницы, и правки, и редакции. На втором месте - корпоративные порталы. Это такой гибрид вики и социальной сети. В его наполнении контентом уже участвуют не только избранные авторы, но и сами пользователи - через свои публикации, комментарии и оценки авторского контента. В самом "продвинутом" варианте корпоративный портал имеет систему рейтингов для контента и автофильтры. На третьем месте наименее распространенные, но наиболее пригодные для создания полноценной базы знаний - системы поддержки онтологий. Они прямо так и называются. Видимо, поэтому и не сильно популярны. Основу таких решений, как видно из названия, составляет редактор онтологий. Чаще всего - древовидный (иерархический). Реже - в форме графа. Совсем редко - многомерные. Если сильно повезет, редактор онтологий позволяет хранить ссылки на места хранения контента. В этом случае он напоминает "хранилища данных" (система для работы с множеством баз данных, источников данных, агрегированных данных, вычисляемых данных и т.д.). Собственно, на этом всё. Других классов решений пока не встречается. Можно ли на основе описанных выше решений формировать и поддерживать базу знаний? Ответ - да, можно. Другой вопрос - какого качества получится такая база знаний и насколько эффективно можно будет ею управлять? Нередко предлагаемые продукты - "кот в мешке" для пользователя. Демо-версии и пробный период эксплуатации (обычно 15..30 дней) не позволяют получить достоверное представление о возможностях платформы. Самое интересное начинается, когда объем накопленного контента и его упорядочивание достигают критического порога. До этого порога как-то можно управлять базой знаний, после него - эффективность резко падает. Особенно это заметно на задачах актуализации контента. При плохо организованной структуре базы знаний попытки "массовой" актуализации могут спровоцировать "цепную ядерную реакцию". Например, одна правка вызывает необходимость изменить два связанных контента. Те, в свою очередь, требуют сделать правку в 2..3 местах хранения контента (каждый). На выходе уже 4..6 правок вместо одной входящей. Ну, и так далее... Если такую "цепную реакцию" не остановить принудительно и не откатить изменения до первоначального - значительная часть базы знаний будет испорчена (потеряет актуальность). Проблема в том, что предсказать (просчитать) заранее все необходимые правки сложно. Особенно, если нет онтологии, связывающей весь контент базы знания в единое целое. Даже при наличии онтологии, связи между отдельными фрагментами контента могут быть неявными. Но при этом - очень важными. Тут в добавок к онтологии нужен механизм работы с контекстами. Контексты - это "сцена", на которой контент обретает смысл. В разных контекстах смыслы одного и того же контента могут сильно различаться. Люди умеют определять контексты интуитивно. Как сказал бы Карл Юнг - бессознательно. Правда, не все люди одинаково хорошо могут это делать. Отсюда многочисленные ошибки и конфликты, вызванные "человеческим фактором". Чтобы исключить эту проблему на уровне базы знаний, контексты нужно формировать явно. Как промежуточный вариант - обучать специальную нейросеть на распознавание контекстов для данной онтологии. Но, в конце концов, контексты должны приобрести явный вид и применяться как упаковка для контента. Это можно назвать "хорошим тоном" при проектировании базы знаний