Как мы случайно сделали Semantic Wiki в Gramax

Всем привет! Меня зовут Катя, я развиваю Gramax — базу знаний для it-команд. В этой статье я расскажу, как мы решали довольно очевидную проблему связи знаний и случайно сделали штуку, у которой даже есть отдельное название.

Когда говорят «Semantic Wiki», обычно представляют что-то сложное: онтологии, RDF, графы и так далее. Но можно ли это сделать как-то проще и для людей? В этой статье разберем:

• Что делает вики «семантической».

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

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

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

Введение

Однажды нас упомянул в своей статье пользователь @itGuevara. Тема статьи и его комментарии нас заинтересовали, а если что-то интересно — надо это отслеживать. Проштудировав тему цифровых двойников мы также двинулись в сторону Semantic Wiki. Мы хотели понять: что это такое, зачем это нужно пользователям, и главное — стоит ли это добавлять в Gramax?

Немного контекста: что такое Semantic Wiki

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

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

Как устроена

Семантическая вики работает на основе трех элементов: страницы, свойства и запросы.

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

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

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

Профит 1. Автоматическая аналитика вместо ручного труда

• Было. Вручную перечитываете 30 интервью, делаете пометки в Excel, сводите данные в таблицу. Время: 2-3 часа.

• Стало. Пишете запрос «Покажи всех респондентов из сегмента B2B, у которых главная боль — интеграция с 1С». Система выдает список.

Профит 2. Живой дашборд, который обновляется сам

• Было. Провели интервью — обновили табличку вручную.

• Стало. Добавили новую статью — дашборды пересчитались автоматически.

Профит 3. Единообразие и системность

• Было. Разброд и шатания в терминах, один пишет «Малый бизнес», другой «SMB», третий «Небольшие компании».

• Стало. Структурированные данные с единой логикой оформления.

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

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

Свойства: как обычные теги, только умнее

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

• Компания

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

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

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

• Гипотеза

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

В Gramax каждый каталог — репозиторий, каждая статья — Markdown-файл в репозитории. Это позволяет использовать все преимущества Docs as Code в работе, но подробнее об этом раскрывали в статье.

Свойства сохраняются во фронтматтере статьи. Таким образом к ним можно получить доступ не только из интерфейса Gramax, но и из Git-хранилища.

Представления: смотрите на данные так, как вам удобно

Представления — это способ показать статьи не по принципу «как мы их написали», а по принципу «что в них указано». Например:

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

  

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

  

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

  

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

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

Как НЕ работает в Gramax

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

Нет строгой привязки полей для заполнения к свойствам

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

Никаких языков для запросов

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

Вот так в интерфейсе:

Вот так в исходнике:

[view:Компания=Технопарус&Аспект Лаб&Кобальт Финанс&Янтарь Биотех&Вектор Инноваций&СибирьСофт&ТурбоСкан&Мозаика Систем&none,Тип интервью=Решенческое&none:Дата:Компания:Дата,Тип интервью,Должность,Гипотеза:Table]

Свойства только на статье

В Semantic MediaWiki можно добавлять свойства к любому фрагменту текста прямо внутри статьи: "Температура составляла [[Температура::25°C]]". В Gramax пока что задать свойство можно только ко всей статье целиком, не к абзацу или строке текста. К этому усердно идем.

Нет свойств-ссылок и графа

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

На каждой статье можно проверить:

• Куда она ссылается.

• Какие статьи ссылаются на нее.

Почему не сделали сразу по стандарту

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

Боль 1. Ограничения древовидной структуры

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

Боль 2. Устаревающие ссылки

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

Боль 3. Тегирование и поиск по тегам

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

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

Боль 4. Автоматическое оглавление

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

А еще…

Чуть позже, «натягивая» этот механизм на разные задачи, мы выяснили, что прикладных сценариев использования ТАК много, что даже страшно приводить список. Расскажу о самом главном: мы в команде полностью отказались от таск-трекера и теперь ведем задачи в Gramax.

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

На статьях есть свойства:

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

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

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

• State — статус.

По этим свойствам мы строим отчеты:

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

• Список по исполнителям (назначено на меня).

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

Почему это важно пользователям

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

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

Как сюда прикрутить ИИ?

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

Итог

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

Чтобы продолжать развивать этот механизм, нам нужна ваша обратная связь. Что думаете? Чего не хватает? Где наш подход упирается в ограничения?

Открыто, бесплатно, и с сообществом

• Смотрите наш сайт — https://gram.ax

• Проверяйте исходники в GitHub и GitVerse.

• Вступайте в комьюнити — https://t.me/gramax_chat