Онто.

Структурированное знание как способ снизить зависимость от конкретной LLM
Мы провели эксперимент: дали четырём разным языковым моделям — Qwen3.8-27B, DeepSeek Reasoner, GPT-5.6-sol и Claude Opus 4.8 — доступ через MCP к одной и той же структурированной модели знания в Онто. После этого моделям была задана одинаковая последовательность аналитических вопросов. Главный результат: несмотря на различия в стиле, глубине рассуждений и способе оформления ответа, все четыре модели сохранили общую предметную рамку и пришли к совместимым по смыслу выводам.

Это важно, потому что обычно значительная часть предметного знания неявно находится внутри самой нейросети. Мы рассчитываем, что модель «знает» необходимые понятия, правильно понимает их взаимосвязи и одинаково интерпретирует используемые термины. Но разные модели обучены на разных данных, используют разные механизмы рассуждения и могут по-разному восстанавливать контекст. Поэтому при смене модели часто меняется не только качество текста, но и сама логика анализа.

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

Получается разделение ответственности:
Онто хранит предметное знание, его структуру, критерии и связи;
LLM находит нужные элементы, интерпретирует их применительно к вопросу и формирует понятный человеку ответ.
Именно структурированное знание становится инвариантом между разными моделями. Можно менять нейросеть, но предметная система координат остаётся прежней.

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

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

Такой подход потенциально даёт несколько эффектов:
Снижается зависимость от поставщика модели.
Организация не привязывает свою предметную логику к одной конкретной нейросети.
Упрощается замена и сравнение LLM.
Модели можно оценивать на одной базе знания, не обучая каждую из них заново предметной области.
Знание обновляется в одном месте.
Изменение критерия или связи в структурированной модели становится доступно всем подключённым LLM.
Сокращается потребность в предметном дообучении.
Необязательно помещать всю логику предметной области внутрь весов каждой модели. Часть специализации переносится из обучения в управляемый внешний контекст.
Повышается проверяемость ответов.
Можно проследить, на какие внешние понятия и критерии опиралась модель. Это не делает внутренние рассуждения LLM полностью прозрачными, но позволяет проверять основания ответа.

Но уже сейчас можно сформулировать подтверждённый инженерный вывод:
внешнее структурированное знание заметно снижает разброс смыслов между разными LLM и позволяет им работать в общей предметной системе координат.

Мы опубликовали открытую методологию ведения проектов разработки ПО основанной на графе знания.

Она связывает работу от причины её появления и ожидаемого изменения до требований, выполнения, проверки, выпуска и обратной связи. Методология не заменяет Scrum, Kanban или внутренние регламенты — она помогает не потерять исходный смысл и подтвердить, что достигнут именно нужный результат.

Но главное для нас в другом. Такая модель открыла путь к AI-native процессу производства ПО.
AI-native — это не чат-бот у каждого сотрудника. Чтобы агент стал участником производства, он должен видеть цели, объекты работы, зависимости, полномочия и критерии завершения. В Онто люди и агенты работают с одной связной моделью, поэтому агент может восстановить контекст, найти пропуски, провести проверку или подготовить решение, не присваивая себе человеческие полномочия.

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

Результат пилота измеряем по сквозной трассируемости работ, времени восстановления контекста, числу возвратов и доле операций, которые можно безопасно передать агентам.
Методология: https://ontonet.ru/methodology
Предложение для компаний: https://ontonet.ru/companies/software-development

Мы зарелизили новую версию сайта Онто: https://ontonet.ru/

В этот раз нам было важно не просто перечислить возможности платформы, а подробнее рассказать о самом методе работы со знаниями. Как начинать с конкретной задачи, выделять объекты и связи, собирать из них живую модель, а затем использовать структурированное знание в работе — в том числе в процессе производства ПО. Требования, решения, архитектура, задачи и участники при таком подходе существуют не в отдельных документах, а в общем связанном контексте.

Для самой платформы Онто мы сделали отдельный раздел: https://ontonet.ru/product. Там подробнее показали, как устроены пространства, общая память, живые диаграммы и работа AI непосредственно с объектами модели.

Заметно усилился и блок «Живой пример» на главной странице. Если раньше можно было сделать небольшую модель знания, то тТеперь можно поиграть с готовыми вопросами, получить ответ нейросети и сразу увидеть, на какие объекты модели она опиралась. То есть посмотреть не только на ответ, но и на его основание.

Посмотрите сайт и расскажите, удалось ли нам объяснить Онто понятнее.

Карточка Jira постепенно превращается в маленькое кладбище контекста. В ней лежат постановка задачи, уточнения, гипотезы, логи, результаты проверок, объяснения решений и переписка нескольких исполнителей. Человеку уже трудно понять, что из этого описывает систему сейчас, а что было лишь промежуточной версией. Агенту ещё сложнее: в новой сессии ему приходится заново восстанавливать ход чужой работы из этой свалки.

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

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

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

Почему сложный софт нельзя собрать одной волшебной командой

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

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

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

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

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

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

Более того, в пространстве могут жить отдельные агенты-смотрители. Один следит за архитектурой, другой — за требованиями, третий — за качеством и проверками. Они не заменяют общую модель продукта, а помогают сохранять её живой и не позволяют тысячам локально правильных изменений превратиться в глобально бессмысленную систему.

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

Большой промпт может однажды превратить универсальную языковую модель в убедительного бизнес-ассистента. Но в следующей сессии всё приходится собирать заново: объяснять устройство компании, перечислять ограничения и надеяться, что роль будет интерпретирована так же, как в прошлый раз.

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

В качестве сквозного примера я взял аналитика расчётов с персоналом. Мы последовательно определяем его бизнес-результат, описываем нужную часть модели, учреждаем базовое агентное население, задаём территорию и ограничения роли, регистрируем её в пространстве, а затем проверяем на реальной задаче.

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

Новая статья: «От модели бизнеса к работающему ассистенту: практический рецепт».

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

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

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

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

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

Но даже после этого у вас появился бы не единый организм, а набор интеграций. Кто отвечает за конкретный объект? Какой контекст сейчас считается актуальным? Где заканчиваются полномочия агента? Что сохранится после его замены? И как решение человека попадёт следующему агенту без пересказа истории из пяти чатов?

Онто в этой конструкции — не ещё один инструмент. Это несущая среда, в которой агенты получают место в организации, контекст конкретной работы, общие с людьми объекты, правила взаимодействия и память. Отдельного исполнителя можно заменить, а его роль, полномочия, связи и история останутся.

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

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

Если перестать рассчитывать, что опытный руководитель «на месте разберётся», что останется от процесса?

Работа с агентами превращает этот вопрос из методологического в практический. Агент не компенсирует плохую инструкцию знанием компании, не догадывается об устных договорённостях и не восстанавливает сам границы ответственности. Чтобы он мог действовать автономно, приходится явно описывать цель, контекст решений, критерии результата и правила передачи работы.

И тут обнаружилось неожиданное: отдельная методология управления агентами нам не понадобилась. Сработали Agile, Scrum, Lean, Kanban, Team Topologies и разделение полномочий — просто с агентами эти принципы пришлось применить буквально.

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

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

«Общие коллеги: как люди и агенты работают в одном пространстве Онто»

Как выглядит механизм онбординга нового исполнителя который уже опубликован в общем пространстве

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

Получился ящик с умными инструментами. Нужного специалиста не приходится каждый раз собирать заново: он восстанавливает свою роль, выполняет свою часть работы и передаёт результат дальше. Если оркестратору или QA нужна помощь, они сами обращаются к регистратору дефектов. А если подходящей роли в пространстве вообще нет, агенты уже умеют обнаружить пробел и предложить нового специалиста — иногда даже такого, которого не было в исходной методологии.

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

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

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

В этом сравнении RAG обеспечивает доступ к знаниям, а микроагент позволяет сохранить и совместно использовать определённый способ работы. Пространство постепенно накапливает не только данные и историю, но и собственный состав специализированных агентов.

Bootstrap-as-Memory: когда объект получает право возражать

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

Но в такой архитектуре обычно отсутствует тот, кто представляет интересы одного конкретного объекта.

И вот как агентская память в Онто становится бутстрапом агента конкретного узла читать

Что такое хорошо документированный процесс разработки?

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

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

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

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

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

Именно в этом Онто изначально силён. Он позволяет хранить не только отдельные артефакты, но и связи между ними. API, требования, решения, задачи, дефекты, диаграммы и результаты проверок перестают жить в разных местах как независимые документы и начинают складываться в связанную модель знания.

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

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

Хорошая документация — это не текст о системе. Это способность системы объяснить саму себя и позволить любому участнику пройти путь от действия к смыслу и обратно.

Не пропустите нашу методику документирования системы. Мы ею обязательно поделимся.

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

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

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

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

Для пользователя это значит меньше ручной работы и меньше визуального шума. Большую модель становится легче читать: у кластеров появляется узнаваемый визуальный контур, а цвет и иконка начинают работать не как случайное оформление карточки, а как подсказка о месте объекта в общей структуре.

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

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

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

Цвет и иконка здесь становятся не украшением, а частью навигации по знанию.