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

Команда CRM-платформы «Модус» от ИТ-холдинга Т1 переводит руководства пользователя и администратора из Confluence в Docs as Code. Задача — связать документацию с релизами продукта, сократить ручную сборку и сделать так, чтобы аналитики могли писать в Markdown без боли.

Подробно об этом мы поговорили с Екатериной, владельцем продукта «Модус», и Еленой, ведущим аналитиком, которая драйвила переход на новый процесс. В статье раскроем: что не работало в старой схеме, как команда выбирала инструмент, как прошел пилот и какого эффекта удалось добиться.

Всем привет, меня зовут Катя, я развиваю Gramax. Уже несколько месяцев мы делаем ИИ-агента для работы с текстом и документацией, поэтому много смотрим на реальные кейсы в разных компаниях. Один из самых сильных принесли друзья из SellOut+. Они делают аналитические системы для фармы и FMCG, быстро пробуют новые подходы и в какой-то момент взяли первую версию функции агентов в Gramax.

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

У нас было 120 процессов, 9 областей управления, более 100 авторов из 60 компаний, 3 ветки на каждый репозиторий и ещё по одной на каждую задачу, AI-агент, таск-трекер, толстый клиент редактора и три портала документации. Не то чтобы всё это нам было нужно, чтобы описать методологию управления в ИТ. Но когда однажды начинаешь собирать серьёзную базу знаний — возникает тенденция разогнаться так далеко, как только сможешь.

Единственное, что меня по-настоящему беспокоило — это конфликты слияния. Нет в мире ничего беспомощнее и безответственнее, чем методолог, пытающийся разобраться, что такое конфликт слияния. И я знал, что скоро мы в эту дрянь попадём.

Если вы когда-нибудь пробовали в одиночку причесать чужой Word-документ, в котором двадцать комментариев на полях и три уровня правок разными цветами — вы поймёте, с чего начнётся эта история. Только умножьте на 100 авторов из 60 компаний и 120 процессов. И добавьте ноль бюджета: всё это люди делают по вечерам, потому что им не всё равно, как будет выглядеть управление ИТ в стране.

Это не туториал и не обзор инструмента. Это история о том, как я полтора года уговаривал себя, что Wiki — нормальный выбор, потом ещё полгода уговаривал команду, что пора слезать. И как после переезда на Docs as Code половина того, чего я ждал, не случилась, а половина случилась не так. И почему мне всё равно нравится, что вышло.

Если вы делаете RAG-поиск по документации или базе знаний, то рано или поздно упираетесь в проблему: хорошо найти — это еще не хорошо ответить.

База знаний, RAG, найденные чанки, LLM строит ответ. Но пользователь не знает ни про DCG, ни про Recall@10, ни про чанки вообще. Он видит только то, что написано в итоговом ответе. А проблемы начинаются именно здесь: модель может что-то проигнорировать, ответить на другом языке, добавить что-то от себя или выдать уверенный текст с иероглифами посередине.

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

Привет, меня зовут Дима, я делаю ИИ-функции в Gramax. В этой статье расскажу, как мы выстроили методику оценки ответов RAG-поиска. Заодно поделюсь, какая модель прямо сейчас дает лучший результат на наших задачах.

Всем привет! Меня зовут Катя, я развиваю Gramax — базу знаний для ИТ-команд.

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

Один из примеров такой документации — Architecture Decision Records — короткие структурированные документы, которые фиксируют одно конкретное архитектурное решение вместе с контекстом, рассмотренными альтернативами и принятыми trade-off'ами. Ключевое слово — конкретное. ADR — это не архитектурный обзор системы и не проектная документация. Это ответ на один вопрос: «почему мы решили именно так, а не иначе?»

На эту статью меня вдохновил испанский ИИ-слоп и тред на Hacker News вокруг вопроса «как вы фиксируете ПОЧЕМУ инженерных решений, а не только ЧТО?». В статье напомню, зачем нужен ADR и какие есть стандартные проблемы. Также приведу выжимки из кейсов, в которых описаны любопытные ИИ-автоматизации.

Всем привет! Меня зовут Катя, я развиваю Gramax — базу знаний для ИТ-команд.

В Gramax мы делаем упор на качественную работу как человека, так и машины. И часто получаем вопросы, как автор статей может повлиять на качество выдачи ИИ-поиска.

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

Всем привет! Меня зовут Катя, я развиваю Gramax — базу знаний для ИТ-команд. Эта статья — интервью с Екатериной Ушаковой о ее книге «Если ты — технический писатель». Екатерина Ушакова — одна из узнаваемых фигур в сообществе технических писателей. Она создала техническую редакцию в Ozon, преподает в Университете Иннополис, организует конференции и ведет сообщество руководителей технических редакций.

Сейчас Катя готовится к выпуску книги о современном техническом писательстве. В статье вы узнаете:

📌 Как и зачем Катя решила написать книгу о роли «Технический писатель».

📌 Почему выбрала печатный, а не электронный формат.

📌 Как Gramax помог справиться с редактурой сотен комментариев.

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

Недавно на Хабре вышла статья про создание RAG-системы для строительных ГОСТов. Команда Цифрового стандарта проделала титаническую работу — полгода вручную разбивали документы на смысловые чанки. Респект за настойчивость и результат.

Их история вдохновила поделиться собственным опытом. Мы тоже столкнулись с проблемой чанкования для умного поиска по базе знаний. Тоже прошли через RAG, векторные базы и поиски оптимального решения. Но пошли по пути полной автоматизации.

Всем привет, меня зовут Дима, я делаю ИИ-функции в Gramax. Эта статья для тех, кто сейчас воюет с чанками вручную или пытается найти оптимальный подход. Делимся нашим путем от быстрого прототипа до продакшен-решения с метриками 90%+.

Привет, Хабр, меня зовут Александр Мачулин, я основатель Gramax, open source системы для ведения документации в подходе Docs as Code с визуальным редактором. Gramax хранит контент в git-репозитории. Это означает, что у пользователей могут возникнуть конфликты при синхронизации изменений. Я считаю, что нагружать пользователей решением конфликтов – не очень хорошо и пытаюсь найти решение для этой задачи.

Привет, Хабр! Я Паша, разработчик Gramax — Open Source платформы для управления документацией в подходе Docs as Code.

В прошлой статье я рассказывал о том, как мы переводили наше приложение с Isomorphic Git на libgit2, как засунули его в веб-версию приложения при помощи Emscripten и с какими трудностями столкнулись в процессе.

На этот раз — как мы оптимизировали хранение файлов ресурсов каталога (в большинстве случаев, изображений) при помощи Git LFS, тем самым ускорив его клонирование и синхронизацию.

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

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

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

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

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

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

Меня зовут Александр Мачулин, я основатель Gramax – open source системы для ведения документации в подходе Docs as Code с визуальным редактором.

Сегодня я расскажу вам идею, как вести всю документацию по проекту и весь цикл разработки в одном Git-репозитории и настроить backward-трассировку требований в Git.

Привет, Хабр! Меня зовут Паша, я разработчик Gramax — open source-платформы для управления технической документацией в подходе Docs as Code.

В этой статья я расскажу, как и для чего мы интегрировали Git в браузер, какие технологии использовали и какие технические решения приняли. А если подробнее: почему отказались от IsomorphicGit в пользу libgit2, каким образом мы собрали его под WebAssembly, как он работает с файлами и зачем вообще все это было нужно.

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

Концепция «Файл вместо приложения», предложенная Стефаном Ангом, сооснователем Obsidian, предлагает решение: переместить фокус с инструментов на данные, обеспечив их доступность, долговечность и независимость от конкретного ПО.

Всем привет! Меня зовут Катя, я развиваю open-source платформу Gramax для управления технической документацией. В этой статье хочу обсудить, почему подход «Файл вместо приложения» набирает популярность, какие преимущества приносит бизнесу, а также как мы реализуем его в Gramax.

Представьте, что вы разработали программное обеспечение. Все идеально: код отточен, тесты пройдены, система готова к работе. Но тут встает вопрос: как отправить документацию заказчику?

Всем привет! Меня зовут Катя, я развиваю Gramax, open source-платформу для управления технической документацией. В этой статье хочу поделиться впечатлением от стандартных способов передачи документации на заказную разработку. А также рассказать о том, как этот процесс можно автоматизировать с помощью Gramax.

Всем привет! Меня зовут Катя, я развиваю Gramax, open source-платформу для управления технической документацией.

В нашем чате и у пользователей регулярно встает вопрос переезда в Gramax c других платформ. Переезд с Confluence и Notion мы сделали прямо в интерфейсе приложения, а с Yandex Wiki — отдельной утилитой. Нет, мы не поленились, просто заметили, что сообщество Yandex Wiki такое давно просит: пример №1 (367 голосов), пример №2 (874 голоса).

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

Привет, Хабр! Меня зовут Катя, я лидирую Gramax, open source-платформу для управления технической документацией.

О Gramax мы писали ранее тут. В этой статье расскажу о Gramax Check — сервисе для автоматических проверок текста на базе LLM. По сути — нашей версии «Главреда», но с настраиваемыми правилами.

Привет, Хабр! Меня зовут Катя, я лидирую Gramax, open source-платформу для управления технической документацией. Однажды мы с коллегами утонули в хаосе рабочих документов: без версий, без согласований, без истории принятых решений. Это подтолкнуло нас к созданию Gramax — инструмента, который интегрирует документацию в процесс разработки, делая его прозрачным и управляемым.

В этой статье расскажу, как Gramax помогает на каждом этапе разработки ПО. Как перейти к документированию в подходе Docs as Code и шагнуть дальше — к Everything as Code.