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

Зачем мне живые онтологии в повседневной работе

В любой даже очень опытной команде есть невидимый слой работы — мы обмениваемся смыслами, притворяясь, что обмениваемся словами. Для одного «проект» — это инициатива, для другого — бюджет, для третьего — просто папка в Jira. «Клиент» в одном контуре — человек, в другом — юрлицо, в третьем — сегмент, в четвёртом — запись в CRM или вообще API. Пока команда маленькая, это живёт как фоновый шум. Но как только начинаются рост, интеграции и сложные изменения, этот шум превращается в системные ошибки.

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

С этого момента у меня появилась рутинная практика: под любой серьёзный проект я поднимаю слой живой онтологии — словаря, встроенного прямо в модель. Не PDF с терминами на финальном слайде и не «где-то был глоссарий в Confluence», а отдельный смысловой слой, который живёт в том же графе, что и процессы, продукты, метрики, системы. Этот слой превращает хаос терминов в управляемую лексику, которую видят и люди, и AI. Модель начинает вести себя предсказуемо: меньше недопониманий, меньше дубликатов сущностей, меньше серых зон, где каждый «и так всё понимает».

Практический эффект очень прозаичен:

— постановка задач перестаёт превращаться в переписку «а что ты имел в виду под…»,

— моделирование процессов и продуктов ускоряется, потому что ключевые понятия уже разобраны,

— API проектируются на одном языке с бизнесом, а не на языке случайных полей,

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

— навигация по графу превращается в осмысленное путешествие, а не в игру «найди нужный узел»,

— AI-агенты опираются на тот же словарь, что и команда, а не на собственные догадки.

По сути, такой словарь — это единый языковой интерфейс к системе. Строгий, но живой, контекстный, меняющийся вместе с моделью.

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

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

Как отсутствие словаря ломает модели и команды

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

На практике это выглядит очень приземлённо.

Ты создаёшь сущность «Клиент» — и уверен, что всё очевидно.

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

С процессами ровно такая же история.

«Проект» — это проект разработки? Бизнес-инициатива? Проектная команда? Бюджет? План-факт?

Пока система живёт в голове одного архитектора и пары аналитиков — она держится.

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

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

Поэтому отсутствие словаря — это не «у нас просто нет документа про термины». Это отсутствие опоры для всей онтологии.

Это проявляется очень конкретно:

— появляются дублирующие сущности с похожими, но не совпадающими комментариями,

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

— команды смотрят на одну и ту же диаграмму и видят в ней разное,

— любые изменения начинают с обсуждения не сути, а терминов,

— AI большую часть времени занят тем, что «догадывается», а не понимает.

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

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

Как я пришёл к идее OntoLex

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

Мне всегда не хватало инструмента, который бы не просто сокращал текст, а показывал:

какие идеи в нём живут, как они связаны и откуда взялись.

По сути, мне нужен был ключ — проводник в ту область знания, из которой этот документ вырос. И довольно быстро стало очевидно, что самым честным, формальным и переносимым таким ключом является словарь, но не в виде списка слов, а в виде сети понятий.

Проблема была только в одном:

делать такой словарь вручную — тяжёлое ремесло.

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

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

И вдруг стало очевидно: если система уже умеет работать со связями, понятиями и классами, то почему бы не научить её помогать мне с документами?

Так появился OntoLex.

Не как «продукт», не как «фича», а как контекстный инструмент для решения моей собственной боли:

• взять документ,

• извлечь смысл,

• собрать словарь,

• перевести всё в онтологию,

• и сделать это не героическим усилием, а регулярной процедурой.

Шаг за шагом стало понятно, что создание ассистента «для извлечения знаний в виде связанного словаря» — это самое простое и естественное решение.

OntoLex просто занял своё место в моём ритуале:

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

Почему я использую OntoLex: ассистент, который превращает рутину в смысл

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

Чем OntoLex принципиально отличается от привычных «умных помощников» из мира текста?

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

• Во-вторых, он узнаёт термины, которые уже есть в словаре, и аккуратно встраивает их в контекст, а не плодит дубли под разными формулировками.

• В-третьих, он честно говорит: «здесь, кажется, новое понятие» — и предлагает создать сущность, а не просто выделить жирным.

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

• И, наконец, он умеет работать страница за страницей, превращая документ в карту смыслов, а не в очередной «подсвеченный текст».

Но главное — OntoLex делает процесс повторяемым.

Не один храбрый подвиг в стиле «мы однажды провели онтологический анализ этой презентации».

А понятная, спокойная, воспроизводимая процедура:

1. Задали пространство.

2. Подняли базовый словарь.

3. Описали источник и его разделы.

4. Прошли документ постранично.

5. Получили живую онтологию, с которой можно работать дальше.

После этого словарь перестаёт быть артефактом, лежащим «где-то рядом».

Он становится центральным рабочим инструментом:

— и для меня как моделирующего,

— и для команды, которая смотрит на одну и ту же систему,

— и для AI, который наконец-то начинает опираться на чётко очерченный язык, а не на догадки.

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

Готовлю пространство: выбираю, где будет жить словарь

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

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

Но иногда правильнее сделать наоборот.

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

• улучшается качество ссылочных данных (меньше «висячих» ссылок и разнородных формулировок);

• появляются однозначные определения там, где раньше была только коллективная интуиция;

• исчезают дубликаты сущностей, которые назывались похоже, но жили отдельно;

• связи между объектами становятся более строгими и осмысленными;

• AI-агенты перестают «угадывать по ситуации» и начинают опираться на формализованный язык.

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

По сути, у меня есть два равноправных сценария:

• новое исследование → новое пространство и словарь, который растёт из одного источника;

• укрепление текущей системы → словарь поверх существующего графа, который выпрямляет и связывает термины.

И ценность OntoLex как раз в том, что он делает оба сценария нормальными:

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

Формирую модель классов: ключевые термины, принципы, ценности, концепции

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

Первое, что делает OntoLex, — предлагает создать базовую сущность: «Словарная статья».

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

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

• ключевые термины — фундаментальные сущности предметной области («Онто», «AI-агент», «Живая модель», «пространство знаний» и т.п.);

• принципы — опорные идеи, на которых строится подход;

• концепции — сущности среднего уровня: процессы, шаблоны, механизмы, состояния;

• ценности — эффекты и обещания: «скорость изменений», «устойчивость системы», «дешёвые изменения», «контроль над изменениями»;

• второстепенные термины — полезные, но не несущие конструкцию понятия;

• синонимы — альтернативные названия, исторические ярлыки и разные языковые формы для одного смысла.

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

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

• базовую онтологию — понятия платформы как системы (что такое Онто, OntoAI, что такое граф смыслов, живая модель и т.п.),

• прикладную онтологию — понятия внедрения и использования (какие ценности даёт платформа, какие процессы, какие эффекты и сценарии применения).

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

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

• базовый класс «Словарная статья» как главный носитель смысла;

• класс «Синоним» как дочерний;

• набор системных связей вроде «Синоним → Статья», «Статья → Статья» (Includes, Dependency, Synonym) — тот минимум, который позволяет словарю жить как графу, а не как таблице.

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

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

Формирование модели классов — это не подготовительный этап.

Это момент, когда словарь перестаёт быть кучей слов и становится каркасом смысла.

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

Добавляю онтологию источников: документ становится частью модели

Когда каркас словаря выстроен, я перехожу к следующему шагу — делаю сам документ полноправным объектом онтологии.

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

Для этого я ввожу два класса:

• «Источник» — документ целиком: презентация, статья, отчёт, регламент, исследование. Всё то, на что мы ссылаемся, когда задаём вопрос «а где это написано?»

• «Раздел источника» — логический кусок документа: слайд, страница, секция, фрагмент.

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

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

• «Содержит» — Источник → Раздел источника;

• «Следующий/предыдущий раздел» — навигация между частями документа;

• «Ссылается на» — Раздел источника → Словарная статья;

• «Относится к источнику» — Словарная статья → Источник (обратная связь).

В этот момент документ перестаёт быть просто входным материалом и становится элементом онтологии. У него есть:

• структура,

• разделы,

• связи,

• роль в модели.

Дальше каждый термин, который мы извлечём, будет иметь не только определение и класс, но и:

• своё происхождение (из какого источника),

• свой контекст появления (на какой странице/слайде),

• свой маршрут внутри документа.

Это даёт очень сильный эффект: словарь становится трассируемым.

Я в любой момент могу открыть термин и увидеть: он появился на Странице 2, связан с такими-то соседними понятиями, а их корень — вот там, на Странице 1.

По сути, это уже не просто структурирование — это маленькая эпистемология.

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

И каждый раз, когда я делаю этот шаг, я думаю:

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

В связке с OntoLex это превращается в спокойный, повторяемый ритуал:

создал Источник, нарезал его на Разделы — и документ плавно растворился в графе, став его частью.

Строю структуру презентации: создаю 16 страниц и связи «Содержит»

Когда классы «Источник» и «Раздел источника» готовы, начинается одна из самых зрелищных фаз — я превращаю сам документ в граф.

Я создаю объект «Презентация Онто» — это и есть наш Источник.

Дальше OntoLex делает за меня ту часть работы, которую раньше приходилось выполнять вручную, лениво и с ошибками:

• создаёт 16 объектов класса «Раздел источника» — по одному на каждый слайд;

• аккуратно нумерует их и даёт имена, привязанные к содержанию;

• заполняет комментарии, если это нужно;

• строит структурные связи.

На уровне графа это выглядит так:

• «Презентация Онто → содержит → Страница 1»

• «Презентация Онто → содержит → Страница 2»

• …

• «Презентация Онто → содержит → Страница 16»

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

На этом OntoLex не останавливается.

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

Страница 1 → Страница 2 → Страница 3 → … → Страница 16

В итоге у меня в модели — не просто набор страниц, а онтологическая карта документа:

• я вижу, сколько у него разделов;

• как они связаны;

• в каком порядке идут;

• как к ним можно перейти из других частей графа.

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

• узел Источника,

• гроздь из 16 разделов,

• цепочка последовательности,

• готовые точки, к которым позже пристегнутся термины.

И каждый раз этот жест простой, почти механический шаг — «создать страницы и связи» — даёт одно и то же ощущение:

обычный PDF вдруг начинает вести себя как часть системы знаний, а не как файл, который лежит где-то сбоку.

Главное волшебство: OntoLex читает каждую страницу и извлекает термины

Когда структура документа готова — 16 страниц на своих местах, каждая связана с Источником и с соседями — начинается самая вкусная часть процесса.

Я открываю Страницу 1 презентации.

OntoLex — тоже.

И вот здесь каждый раз срабатывает одинаковое ощущение:

ассистент начинает читать страницу не как текст, а как пространство смыслов.

Он не пытается просто найти «ключевые слова» и подсветить их жёлтым.

Он ищет понятия. Разбирает, что на странице является сущностью, что — ценностью, что — эффектом, а что — просто обвязкой.

На заглавном слайде он сразу выделяет:

• «Онто» — уже существующий ключевой термин;

• «Живая модель» — тоже ключевой термин;

• «AI-агент» — новый объект, для которого стоит создать статью;

• «Ценность в темпе» — формулировку, которую разумно оформить как отдельную «ценность».

И делает не просто список. Он спрашивает меня:

«Создаём новый термин AI-агент?

К какому классу отнесём?

Свяжем Страницу 1 с этим термином?»

То есть он ведёт себя не как парсер, а как онтологический собеседник.

Я отвечаю «да» — и в этот момент появляются:

• новая словарная статья «AI-агент»;

• связь «Страница 1 → Ссылается на → AI-агент»;

• принадлежность к классу (ключевой термин или участник модели);

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

Страница 2 — другая картина.

Там концентрат ценностей и эффектов: «скорость изменений», «устойчивость системы», «контроль над изменениями», «конкурентное преимущество», «усиление людей AI-агентами». OntoLex раскладывает это по полочкам:

• вот список ценностей,

• вот процессы и эффекты,

• вот новые понятия,

• вот уточнение уже существующих.

Если термин уже живёт в словаре (например, «скорость изменений»), ассистент не создаёт дубликат — он предлагает связать раздел с существующей сущностью. Если понятие новое — предлагает завести статью и сразу вставить её в правильное место онтологии.

Каждый раз, когда я подтверждаю его предложения:

• создаём новую статью или используем старую;

• фиксируем связь «Страница N → Ссылается на → Термин»;

• уточняем класс и контекст;

• наращиваем сетку смысловых отношений.

В этот момент словарь перестаёт быть набором карточек и становится структурным контекстом, вплетённым в общий граф.

Третья страница, четвёртая, пятая…

Ритуал повторяется, но ощущение меняется:

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

• новые связи появляются как ветки и корни;

• старые понятия обретают глубину, когда для них добавляются новые контексты;

• страницы становятся не картинками, а логическими блоками происхождения знания;

• презентация шаг за шагом растворяется в онтологии.

Это тот самый момент, который я для себя однажды сформулировал так — и специально оставляю эту фразу в тексте:

«Это один из самых красивых шагов, потому что именно здесь OntoLex начинает работать как семантический сканер документа…»

И это действительно так:

ты видишь, как ассистент проходит по документу, слой за слоем, и превращает его из линейной последовательности слайдов в распределённое поле смыслов.

Постепенное нарастание структуры: категории, ценности, концепции, процессы

После нескольких страниц становится видно, что документ больше не живёт как линейная лента слайдов.

Он уже ведёт себя как фрагмент живой онтологии.

На этом этапе лучше всего подходит слово «нарастание».

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

• ключевые термины превращаются в узлы высокой связности — к ним тянутся ценности, процессы, контексты;

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

• концепции становятся центрами объяснений: вокруг них группируются процессы, состояния, механизмы;

• процессы связывают принципы и результаты: «почему мы так делаем» → «какого эффекта достигаем»;

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

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

Сначала структура напоминает набор отдельных деревьев.

Через несколько страниц — уже кусты, где ветви начинают переплетаться.

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

Важно, что это не просто «красиво нарисованная картинка».

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

Я при этом не пишу ни одной строки кода, не руками протягиваю линии между узлами и не сижу ночами в графовом редакторе. Я всего лишь:

• подтверждаю создание нужных статей,

• уточняю классы,

• соглашаюсь или не соглашаюсь на предлагаемые связи,

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

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

И тут раскрывается вторая половина его силы:

• если появляется повторяющееся понятие под другой формулировкой — он предложит связать его с уже существующим;

• если термин похож на существующий, но отличается оттенком смысла — задаст вопрос, в чём именно различие, и поможет развести их аккуратно;

• если термин одновременно тянется к нескольким концепциям — покажет, как это отразить в связях, не потеряв ясности;

• если в документе начинают появляться новые эффекты или процессы, которые не вписываются в текущую сетку — предложит расширить онтологию.

Это уже не просто «анализ документа».

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

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

Презентация растворяется в живой модели: как выглядит финальный граф

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

PDF, с которого всё начиналось, перестаёт быть главным объектом.

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

• словарь — набор терминов с чёткими определениями и классами,

• онтологию понятий — кто с кем связан и почему,

• онтологию источников — откуда каждое из этих понятий взялось,

• сеть отношений — как термины, страницы, ценности и процессы переплетены друг с другом,

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

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

Каждый термин — не слово, а сущность с происхождением, связями, классом и контекстами.

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

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

• один узел Источника — «Презентация Онто»,

• от него — веер из Страниц 1–16,

• от каждой страницы — набор связей «Ссылается на → термин»,

• а дальше — слои онтологии: ключевые термины, ценности, процессы, концепции.

Визуально это больше похоже не на документ, а на нейронную карту.

Каждый узел — смысл.

Каждая линия — отношение.

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

И вот в этот момент становится очень очевидно:

документ — это всего лишь упаковка.

Смысл должен жить не в слайдах, а в модели.

Я вижу, как:

• ценности связаны с принципами,

• принципы — с ключевыми терминами,

• ключевые термины — с процессами,

• процессы — с эффектами,

• эффекты — с контекстами,

• а все они — с конкретными страницами, откуда были извлечены.

Нет больше «на втором слайде была важная мысль, надо ещё раз посмотреть».

Теперь эта мысль — узел в онтологии. Она встроена в граф, имеет связи, историю и влияние.

Каждый раз, когда я прохожу такой цикл, я думаю одно и то же:

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

И именно так, на мой взгляд, должна работать онтология в реальной жизни:

конечный результат — не красиво оформленный PDF, а структура смыслов, которая продолжает жить, расти, дополняться и служить точкой опоры для решений.

Что это даёт: скорость, меньше ошибок, яснее коммуникация и адекватный AI

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

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

1. Скорость работы растёт в разы

Мне больше не нужно листать документ туда-сюда.

Если нужно вспомнить, где впервые появилось понятие «скорость изменений», я не пробегаю глазами по PDF. Я открываю соответствующий узел в онтологии — и сразу вижу:

• страницу происхождения,

• связанные ценности,

• связанные процессы,

• все соседние понятия, которые с этим связаны.

То, что раньше занимало минуты (иногда десятки минут с отвлечениями), превращается в пару кликов.

2. Исчезают смысловые ошибки

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

Когда термин в онтологии:

• имеет класс (кто он — сущность, процесс, ценность, роль?),

• живёт в контексте (где используется, с чем связан),

• обладает явными связями,

• знает своё происхождение,

путать его с соседними просто не получается.

Это реально ощущается как семантическая безопасность системы.

3. Коммуникация внутри команды становится чище

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

Ответ уже есть в модели:

• определение,

• класс,

• где термин родился,

• что от него зависит.

Мы начинаем говорить одним языком, а не шестью слегка разными диалектами.

4. Вычищаются дубли, противоречия и «серые зоны»

Это один из самых приятных побочных эффектов.

OntoLex сам обращает внимание на похожие термины:

«Вот здесь “скорость изменений”, а вот здесь “быстрота внедрения” — это одно и то же или нет?»

Иногда я сам впервые замечаю, что в голове смешивал два разных уровня смысла.

После онтологизации документа:

• дубли уходят или аккуратно сливаются,

• различия становятся явными,

• структура выравнивается,

• модель ведёт себя спокойнее и предсказуемее.

5. AI начинает работать по делу, а не по догадкам

AI — не маг. Он не может «догадаться», что под одним и тем же словом разные люди подразумевают разные вещи. Но если:

• каждое ключевое понятие определено,

• встроено в онтологию,

• связано с источником,

• имеет контекст и связи,

AI-агенты перестают галлюцинировать и начинают рассуждать в рамках общей модели.

В какой-то момент я поймал себя на мысли:

«Я наконец-то перестал обучать AI догадкам. Я дал ему язык, и он работает на этом языке».

6. Модель становится дополненной памятью команды

Словарь и онтология вместе хранят:

• что это за сущность,

• зачем она вообще нужна,

• откуда она появилась,

• как она связана с другими вещами,

• где о ней впервые было сказано,

• какие части системы зависят от её изменений.

Обычно всё это существует в виде «коллективной памяти» опытных людей.

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

В итоге превращение документа в онтологию — это не про «красивый граф».

Это про усилитель:

• скорости,

• качества решений,

• стабильности изменений,

• эффективности AI,

• и ясности коммуникации внутри команды.

Как повторить метод: короткий рецепт, который работает на любом документе

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

Вот минимальный рабочий рецепт.

Шаг 1. Определите, где будет жить словарь

Сначала отвечаю себе на вопрос: в каком контексте этот словарь будет полезнее.

• Если это новое исследование или пилот — создаю отдельное пространство, чтобы увидеть «чистую» семантику документа.

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

Шаг 2. Сформируйте базовую структуру словаря

OntoLex берёт на себя стартовую работу:

• создаёт базовый класс «Словарная статья»,

• поднимает класс «Синоним»,

• заводит минимальные служебные связи между статьями.

Я добавляю своё:

• выделяю ключевые термины,

• формирую классы «Принцип», «Концепция», «Ценность», «Второстепенный термин»,

• при необходимости разделяю онтологию на базовую и прикладную.

Шаг 3. Сделайте документ частью модели

Дальше я завожу:

• объект Источник — сам документ (презентация, отчёт, статья),

• объекты Раздел источника — страницы, слайды, секции,

• связи «Содержит» (Источник → Раздел) и связи последовательности между разделами.

На этом шаге документ становится картой внутри модели.

Шаг 4. Пройдите документ постранично

Это основная рутина — но именно её OntoLex сильно облегчает.

Для каждой страницы:

• открываю раздел в Onto,

• даю OntoLex прочитать текст,

• смотрю, какие понятия он предлагает извлечь,

• подтверждаю создание новых статей или связывание с существующими,

• утверждаю связи «Страница N → Ссылается на → Термин».

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

Шаг 5. Дождитесь, пока онтология начнёт расти сама

После 5–6 страниц контур становится виден:

• появляются центры смыслов — узлы, к которым тянется множество связей;

• ценности начинают группироваться, показывая, вокруг чего строится история;

• процессы связываются с принципами и эффектами;

• видно, какие вещи повторяются, а какие появляются впервые.

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

Шаг 6. Используйте граф вместо документа

На этом этапе документ перестаёт быть главным объектом.

Работа идёт уже с:

• страницами как онтологическими разделами,

• терминами как объектами системы,

• связями как объяснениями,

• диаграммами как визуальными проекциями смысла.

Нужно вспомнить, что именно обещали под «скоростью изменений»?

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

И самое важное:

Этот метод переносим куда угодно

Теоретически всё то же самое можно сделать:

• в Excel,

• в Notion или Confluence,

• на стикерах и Miro,

• хоть на бумаге.

Разница только в том, какой ценой.

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

В связке Onto + OntoLex рутинная часть — извлечение, связывание, проверка консистентности — ложится на ассистента, а вам остаётся самое интересное: думать о смыслах.

Лично для меня эта процедура уже давно перестала быть «разовой задачей» и превратилась в рабочий рефлекс:

Новый важный документ — значит, впереди ещё одна живая онтология.

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

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

Материалы

? Исходный документ

Презентация Онто (PDF)

? RDF-модель результата

Экспорт онтологии ( RDF )

?️ Диаграммы, созданные в Onto

Структура онтологии

https://app.ontonet.ru/ru/context/736757bf-6d6a-4c64-82fa-0affe2dd3c59/diagram/93e7ed61-d68b-4c78-8981-af8ca80cbe77

От словаря к структурному контексту

https://app.ontonet.ru/ru/context/736757bf-6d6a-4c64-82fa-0affe2dd3c59/diagram/3b48f70c-b44e-47c1-9bba-6e353ac44898

Структура презентации

https://app.ontonet.ru/ru/context/736757bf-6d6a-4c64-82fa-0affe2dd3c59/diagram/e15d453b-4413-414b-b0cf-3df47155a72a

Страницы 1–3 (первый смысловой кластер)

https://app.ontonet.ru/ru/context/736757bf-6d6a-4c64-82fa-0affe2dd3c59/diagram/0a59502b-1688-4e07-bef3-abdf05de06fb

? Процесс работы

Диалог с OntoLex (частичный протокол разбора презентации)

https://chatgpt.com/share/69332bab-2580-8007-b173-4db89d07fa82