Корпоративная вики, которая понимает смысл: как создать и использовать

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

В этой статье разберем:

  • Что делает корпоративную вики «семантической» и зачем это нужно на практике.

  • Как свойства и представления в Gramax решают эти задачи без изучения онтологий и графовых баз данных.

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

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

Зачем корпоративной вики нужна семантика

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

Semantic Wiki идет дальше: она не просто хранит текст, но и понимает структуру данных внутри него. Это значит, что информацию можно размечать так, чтобы система умела ее искать, фильтровать и агрегировать.

Представьте, что команда проводит Customer Development и записывает результаты интервью. В обычной корпоративной вики появится страница «Интервью с Анной Ивановой, 15.01.2026» — просто текст. В семантической — к этой странице добавятся метаданные: «респондент: Анна Иванова», «дата: 15.01.2026», «сегмент: владельцы малого бизнеса», «проблема: нехватка времени на учет». И из этих данных уже можно строить отчеты.

Как устроена семантическая вики

Механизм держится на трех элементах: статьи, свойства и запросы.

  • Статьи — это обычный контент. Например, «Интервью №25» с описанием беседы с клиентом.

  • Свойства — типизированные поля, которые связывают статьи друг с другом или хранят конкретные значения. В примере с CustDev это «Респондент» (ссылка на страницу человека), «Выявленная боль» (текст), «Оценка проблемы» (число от 1 до 10), «Дата интервью» (дата).

  • Запросы — способ делать выборки. Можно автоматически собрать таблицу всех интервью, где оценка проблемы выше 7, или распределение респондентов по сегментам.

Что это дает на практике:

  • Автоматическая аналитика вместо ручного труда. Раньше: перечитываете 30 интервью, переносите данные в Excel, сводите таблицу — 2–3 часа. Теперь: запрос «все респонденты B2B, чья главная боль — интеграция с 1С» — и система выдает готовый список.

  • Живые дашборды без ручных обновлений. Добавили новую статью — все отчеты пересчитались автоматически. Никакой синхронизации вручную.

  • Единообразие данных. Конец ситуации, когда один пишет «Малый бизнес», второй «SMB», третий «небольшие компании». Структурированные свойства задают единую логику.

Как это работает в Gramax

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

Свойства: умные теги для корпоративной базы знаний

Внешне свойства выглядят как обычные теги на статье. В каждом каталоге создается свой набор. Продолжим на примере CustDev: каждое интервью содержит свойства:

  • Компания

  • Дата интервью

  • Тип интервью

  • Должность респондента

  • Гипотеза

Автор статьи просто накликает нужные варианты и публикует изменения. Никакой разметки, никакого синтаксиса.

Как Gramax хранит это системно. В Gramax каждый каталог — это репозиторий Git, а каждая статья — MD-файл. Это реализация подхода Docs as Code. Свойства сохраняются во frontmatter статьи — доступны не только из интерфейса Gramax, но и напрямую из Git-хранилища. Данные не заперты в проприетарной базе.

Представления: смотрите на базу знаний под нужным углом

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

  • Доска с группировкой по должности респондента.

  • Список с группировкой по гипотезам.

  • Таблица с группировкой по компаниям.

Отображение гибко настраивается: можно превратить список в таблицу, скрыть или показать нужные свойства, найти записи с пропущенными значениями, применить сортировку и фильтры.

Главное — представления опираются на свойства, а не на текст. Изменилось свойство в статье — все связанные представления пересчитались сразу. Это та самая магия, ради которой строят Semantic Wiki, но без необходимости разбираться с RDF и онтологиями.

Честно о том, чего в Gramax пока нет

Прежде чем появились вопросы в комментариях — обозначим сами, чем наша реализация отличается от настоящих Semantic Wiki, вроде Semantic MediaWiki или Wikidata.

  • Нет строгой привязки полей к типам. Если у статьи указан тип интервью «Проблемное», поля для фиксации проблем не появятся автоматически. В Semantic MediaWiki это решается через Page Forms. В Gramax — частично через механизм шаблонов статей.

  • Нет языка запросов. Semantic MediaWiki имеет синтаксис {{#ask: ...}}, Wikidata — SPARQL. В Gramax вместо этого — UI-фильтры: выбираете значения из списка, настраиваете группировки через интерфейс. Проще и быстрее в освоении, менее гибко для экзотических сценариев. Покрывает 90% практических задач без изучения синтаксиса.

  • Свойства только на уровне статьи. В Semantic MediaWiki можно разметить отдельный фрагмент текста прямо внутри статьи. В Gramax свойство назначается всей статье целиком. Работаем над этим.

  • Нет графа связей. В классической Semantic Wiki связи между сущностями образуют граф: «Анна работает в Компании X», «Компания X относится к сегменту B2B» — и система сама находит всех респондентов из B2B по цепочке. В Gramax свойства живут на каждой статье независимо, «пройтись» по нескольким уровням связей нельзя. Для большинства задач это решается явным указанием всех нужных свойств или обычными ссылками для навигации.

А вот связи между статьями — отслеживаются!

Какие проблемы мы решили

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

Боль 1. Тирания дерева

В любой вики статьи собираются в дерево: раздел → подраздел → статья. Это жестко привязывает к одной логике группировки. Но что, если одна функция используется в трех разных модулях? Куда ее положить? Дублировать через единый источник? Вынести в корень и везде линковать? Оба варианта неудобны.

Боль 2. Ссылки, которые протухают

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

Боль 3. Теги без интерфейса

Теги — привычная сущность. Но во многих базах знаний по ним можно фильтровать только через строку поиска, что добавляет лишних кликов и превращает тегирование в ритуал «для галочки».

Боль 4. Разводящие статьи, которые устаревают

В пользовательской документации есть жанр «разводящей статьи»: она лежит в корне раздела и ссылается на все вложенные материалы. Создавать такое оглавление вручную — значит снова наступать на грабли устаревших ссылок.

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

Как мы сами используем это вместо таск-трекера

Примеряя механизм на разные сценарии, мы обнаружили столько вариантов применения, что даже страшно перечислять все сразу. Расскажу о самом радикальном: мы в команде полностью отказались от внешнего таск-трекера и ведем задачи прямо в Gramax.

Вот как это устроено: в навигации слева — статьи. Каждая статья — задача с описанием. На каждой задаче живут свойства:

  • Assignee — исполнитель.

  • PO — ответственный продакт-менеджер.

  • Release — месяц релиза.

  • State — статус.

По этим свойствам строятся представления:

  • Канбан-доска по статусам.

  • Список «назначено на меня» с фильтром по исполнителю.

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

Почему это важно для вашей команды

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

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

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

ИИ поверх структурированных данных: логичный следующий шаг

Логичный вопрос: если данные в корпоративной вики типизированы, почему не подключить к ним LLM для автоматических выводов? Именно так и устроено. Недавно мы записали видео о том, как ИИ в связке со свойствами работает в Gramax. Механизм оказался на удивление прямолинейным — структурированные метаданные делают контекст для модели намного понятнее.

Итог: корпоративная вики, которая не требует от вас быть архитектором данных

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