Новая версия баз знаний для групп Б24 предполагает наполнение контентом через создание отдельных страниц. Понятно и логично с точки зрения контент-редактора или технического писателя.
Однако, от современной базы знаний хочется немного больше технологичности. В наше время мало кто ограничивается одним типом клиента доступа к данным. Кроме веб-решений в компаниях применяются мобильные приложения, чат-боты, навыки для умных колонок и так далее.
Например, в компании внедрен корп портал Б24. В портале есть база знаний для сотрудников, где можно получить любую информацию о компании, процессах, внутренних вопросах и так далее. Сотрудник компании может зайти в портал Б24 и получить информацию из базы знаний.
Допустим, что кроме Б24 в компании есть стороннее корпоративное мобильное приложение, где тоже должен быть доступ к базе знаний. И еще есть чат-бот, который не связан с Б24, но там тоже должна быть та же база знаний. И еще в дополнение есть внутренний корпоративный навык для Алисы.
Логичным решением является интеграция внешнего приложения и чат-бота с Б24 и подгрузка через API контента с базы знаний: поиск по базе, вывод разделов, контента страниц и так далее. Тогда не придется вести одну базу в трех местах и с любого клиента будет к ней доступ.
Но, если контент базы знаний хранится в виде страниц, то с ним мало что можно сделать: не сделать нормальный поиск по базе, не прикрутить синонимы или теги к вопросам для реализации NLU (а без этого голосовой навык для той же Алисы будет ужасным).
Чтобы можно было все красиво интегрировать, контент базы знаний должен хранится в каком-то структурированном виде с возможностью расширения служебных полей. Хоть банально в инфоблоках.
Под служебными полями я имею в виду, например, синонимы и различные формы написания одного вопроса, которые нужны для построения интентов NLU. Либо разметку ударений для голосовых помощников. Тогда не придется еще дополнительно выгружать куда-то базу знаний и расширять ее в стороннем приложении, а потом следить за актуальностью всех источников.
Страницы базы знаний могут забирать и отображать контент с нужным форматированием и по нужному шаблону.
Для внешних приложений контент будет отдаваться через API. Причем как с форматированием, так и без. Например, в мобильном приложении можно применить форматирование текста. В чат-ботах и голосовых помощниках - нет.
Понятно, что можно для таких "сложных" случаев не применять стандартную базу знаний, а сделать свою. На тех же инфоблоках и Сайтах24.
Но:
1. Потребность в единой базе знаний, доступной в разных видах, каналах и с разных типов устройств становится все больше. Пользователи хотят работать с продуктами там, где им удобно и это не только сайт и мобильное приложение.
2. Сами по себе базы знаний в формате набора текстовых страниц подходят только небольшим проектам и компаниям. Для любого активно развивающегося проекта база знаний со временем превращается в монстра, надежно хранящего все секреты и не дающего ответы на пользовательские вопросы. Намного проще и быстрее спросить у коллеги или позвонить в поддержку. Поэтому важно базу знаний делать максимально гибкой и расширяемой, чтобы можно было прикручивать к ней "интеллектуальные расширения".
3. Если есть встроенный специальный модуль для баз знаний, то логично использовать его. Тем более, что он новый и очень перспективный. И должен соответствовать времени, а не пылиться на полке аналогично wiki.
Резюме.
Представим, что мы внедряем базу знаний не из 5-10 страниц, а намного большую. 500 - 1000 типовых вопросов, ответов, советов, заметок для сотрудников крупной компании. Или тысячи типовых вопросов клиентов в поддержку.
Мы хотим эту базу сделать интеллектуальной, наложить на нее современные инструменты NLU или что-то еще. И чтобы все было доступно через десятки видов клиентских каналов - боты, виджеты, колонки, соц сети и так далее.
Также для больших баз знаний могут надстраиваться инструменты продвинутой аналитики как контента, так и работы с ним.
Отсюда мы получаем требования к форме хранения контента, возможностям его расширения и предоставления не только в красивом шаблоне на сайте, но и в различных форматах через API.
Инфоблоки тоже рассматриваются, но вроде это мало поможет вашей задаче (так как ИБ это всего лишь источник, и он не отражает иерархии страниц в БЗ).
1)
2)
3)