Онто.

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

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

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

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

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

🎾 Архитектурный аудит под ключ (2–3 месяца): быстро разбираю стек/архитектуру, нахожу риски и узкие места и выдаю roadmap, который снижает стоимость ошибок и ускоряет развитие продукта.

🎾 Part-time CTO / VPoE (20–25 ч/нед): ставлю инженерные процессы, помогаю с наймом и архитектурой так, чтобы стартап быстрее дошёл до предсказуемой скорости и качества без фуллтайм-ставки.

🎾 Архитектурный надзор: 2–3 сессии в неделю с командой, где я фильтрую опасные решения, удерживаю стандарты и веду эволюцию системы без “переписываний ради переписываний”.

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

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

🎾 Точечные внедрения LLM в бизнес: нахожу 1–3 кейса с понятным ROI и внедряю LLM как инструмент (поиск/аналитика/ассистенты/автоматизация) так, чтобы получился измеримый эффект без зоопарка и галлюцинаций.

Пишите в личку (@varkulevich): краткое описание продукта и задачи — возвращаюсь с предложением формата работы и ожидаемым roadmap; приоритетно проекты на русском языке (возможны варианты), локация и формат контрактования значения не имеют.

Мы сделали то, что обещали. И это большая веха для Онто.

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

Что появилось уже сейчас?

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

Это прикладная вещь, не «косметика».

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

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

Что дальше
Уже сейчас видно направление развития:
функциональные роли вида «я как…», которые будут показывать разные аспекты знаний и разные пространства в зависимости от контекста мышления.

Но это следующий шаг.
Принцип остаётся прежним:
если мы что-то обещаем — мы это делаем.

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

И управление пространствами — важный шаг именно в эту сторону.

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

Мы помним всё, о чём говорили. И шаг за шагом возвращаем эти долги в продукте.

Сегодня — небольшой, но очень важный шаг.
В Онто появился личный кабинет.

Теперь через него можно:

— ✍️ Изменить имя, чтобы работа в пространствах стала по-настоящему личной. Людям проще и точнее с вами коммуницировать, без догадок и ошибок.
— 🔐 Управлять API-ключами: создавать новые, удалять ненужные, держать порядок и контроль.

Зачем это нужно на практике?
Чтобы усиливать свои возможности при интеграции Онто в рабочие процессы:
подключать n8n, автоматизации, собственные сервисы, эксперименты и боевые сценарии — осознанно и безопасно.

И это только начало. В очереди дальше:

— управление списком пространств
— встроенный MCP-клиент
— ассистенты, доступные не только через OntoAI, но и пользователям без ChatGPT
— усиление контекстов чатов
— возврат ролей
— контексты внутри контекстов
— и ещё много того, о чём мы говорили раньше

Мы искренне верим, что наш подход — с живыми графами, контекстами и агентами — гораздо мощнее и при этом заметно менее прожорлив по ресурсам, чем «просто RAG».

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

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

В n8n появился нативный слой взаимодействия с Онто — действия, а не REST-вызовы.
Что это означает на практике

Раньше интеграция выглядела так:
• разработчик знает API,
• помнит версии,
• собирает URL,
• руками прокидывает заголовки,
• аккуратно не путается в realmId, entityId, relatedEntities и т.п.

Теперь:
• в сценарии выбирается «Entity → Get», «Diagram → Load», «Link → Create» и т.д.;
• параметры имеют смысловые названия;
• авторизация и детали API спрятаны внутри адаптера;
• сценарий читается как процесс, а не как набор HTTP-запросов.
Это принципиально другой уровень абстракции.

Зачем это бизнесу
1. Скорость интеграций
• новые сценарии собираются быстрее;
• меньше зависимости от конкретных разработчиков;
• меньше времени на онбординг команд.
2. Снижение стоимости изменений
• API можно менять, версионировать, расширять — сценарии остаются рабочими;
• меньше «хрупких» интеграций, которые ломаются от мелких правок.
3 . Повышение управляемости
• сценарии становятся понятны не только авторам, но и владельцам процессов;
• интеграция — это актив, а не чёрный ящик.

Зачем это IT и архитектуре
1. Чёткое разделение ответственности
• API Онто — зона платформы;
• сценарии n8n — зона автоматизации;
• бизнес-логика не размазана по URL и заголовкам.
2. Контракт вместо импровизации
• узел = контракт взаимодействия;
• меньше неявных договорённостей и «знаний в голове».
3. Подготовка к масштабированию
• мульти-realm,
• разные окружения (dev / preprod / prod),
• разные команды и подрядчики — без хаоса.

Если коротко
Мы перестали интегрироваться с API и начали работать с моделью Онто напрямую — через действия и смыслы.

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

Онто + n8n постепенно перестают быть «набором инструментов»
и становятся платформой интеграции знаний и процессов.
И это только начало.

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

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

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

🎉 С наступающим 2026 годом!
Пусть в новом году ваши графы будут связными, модели — минимальными, знания — живыми, а решения — спокойными. Пусть будет меньше хаоса и больше радости от того, что всё на своих местах.
И пусть 2026-й станет годом, когда даже Дед Мороз работает по онтологии — и подарки доходят без missing-dependencies ✨

Прокачал прототип “живой онтологии процесса” ещё на один уровень — теперь он не просто активирует задачи, а назначает исполнителя алгоритмом (без AI-лотереи).

Раньше логика была такая:
✅ задача стала “Выполнена” → движок пересчитал граф → следующие задачи перешли в “Назначена”.

Теперь добавил следующий шаг:
✅ задача перешла в “Назначена” → движок находит подходящего исполнителя по правилам → создаёт связь “задача → исполнитель”.

То есть “назначение” у меня больше не ручной шаг и не “пусть нейросеть решит”, а нормальная инженерная штука:
🔹понятные критерии,
🔹предсказуемый результат,
🔹воспроизводимость (одинаковый вход → одинаковый назначенный человек),
🔹и главное — всё фиксируется в модели: кто почему назначен, и где это в графе.

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

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

#ontonet #knowledgegraph #n8n #процессы #онтология #automation #raci #workflow

Это чудо-постройка находится рядом с храмом Христа Спасителя и известна как дом Перцовой (Соймоновский проезд, 1). Участок с существовующим 3-этажным домом в начале XX века выкупил инженер путей сообщения Петр Перцов, он же выбрал автора проекта и контролировал перестройку здания.
Автором дома стал художник Сергей Малютин. Чтобы лучше представить общую компоновку здания, он вылепил его модель из глины. Стены облицевали красным кирпичом, а на фасаде появилась майолика, выполненная артелью художников "Мурава". Также дом украсили деревянная резьба и литые детали.
Были применены новейшие для 1900-х годов технические решения: телефоны, лифты, принудительная вентиляция. Провода, водопровод, канализация были спрятаны внутри стен. В создании дома участвовали также архитектор Николай Жуков и инженер Борис Шнауберт. Постройка, законченная в 1907 г., была оформлена на жену Петра Перцова Зинаиду.

P. S. Прилагаю схему с перечисленными персоналиями, выполненную с помощью приложения Онто (ontonet.ru)

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

Пост-апдейт: статья вышла ✅

Помните мой прошлый пост про “процесс как живую онтологию”, где:
• задачи — это объекты,
• “ход” — это связь,
• а состояние — это шаблон (тип объекта), а не поле?

Я обещал разложить всё по полочкам — и вот, наконец, результат:
«Живая онтология процессов: от смысловой модели к автоматизации»
https://ontonet.ru/learning/tpost/7fxav0j7l1-zhivaya-ontologiya-protsessov-ot-smislov

Что внутри (по-инженерному, без магического мышления):
• почему процессы в BPMN/регламентах “умирают” и дрейфуют от реальности;
• минимальная модель: Процесс → Задачи → связь “Ход”, и как из этого рождается продвижение этапов;
• как n8n у меня работает не как сценарий, а как интерпретатор модели: читает граф и делает переходы (смена шаблона у задач);
• мини-кейс “волны”: одна выполненная задача активирует следующий блок задач (в статье + видео).

🎥 Видео я вставляю прямо в статью — будет видно “до/после” на живой модели.

Если интересно, куда это можно развивать дальше (проверяемость, симуляции, “что-если”, цифровая тень процесса) — тоже есть, но без фантазий: что уже можно, и что пока честно прототип.

#ontonet #knowledgegraph #n8n #mbse #процессы #онтология #automation

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

Онто сейчас доступна бесплатно, и часть из вас уже ведёт на платформе реально полезные кейсы: проекты, словари, процессы, заметки, “живые” модели.

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

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

Если у вас уже есть что показать — напишите короткую историю:
• что вы пытались решить (боль/задача),
• как разложили это в Онто (какие объекты/связи/диаграмма),
• что стало лучше (скорость, ясность, коммуникации, контроль, повторяемость),
• и один скрин/картинка “до/после” (идеально).

Где публиковать: Хабр, TenChat, Telegram, VC, личный блог — любое место. Можно даже коротким постом, без лонгрида.

А ссылку — кидайте сюда в канал/в комментарии. Мы соберём подборку кейсов и будем продвигать авторов (и, да, это помогает платформе выжить).
Вселенная странная штука: иногда продукт живёт не за счёт фич, а за счёт историй людей, которые нашли ему смысл. Давайте соберём эти истории.

Я долго писал про “семантический ритуал” — как превращать документы в живую онтологию: не текст, а структуру смыслов, с которой можно работать.

А потом меня догнала мысль: а почему процессы мы до сих пор описываем как мёртвые схемы?
BPMN, регламенты, вики-страницы… Всё это красиво живёт ровно до первого реального изменения. Дальше начинается дрейф: модель отдельно, реальность отдельно, люди интерпретируют “как поняли”.

Я попробовал сделать иначе: процесс как живую онтологию.
В Онто у меня:
• задачи — это объекты,
• зависимость “ход” — это связь,
• а состояние задачи — это не поле, а шаблон (тип объекта).

И вот дальше начинается магия, которую я показываю в видео:
n8n не хранит процесс и не “ведёт сценарий”. Он просто исполняет модель.

Когда задача становится “Выполнена”, движок пересчитывает граф и автоматически переводит следующие задачи в “Назначена”. Получается не “workflow”, а исполняемая модель — очень близко к MBSE-логике: сначала модель, потом её интерпретация.
В видео — короткий фрагмент прототипа: как “выполнение” одной задачи активирует следующий этап целого блока.

Статья уже на подходе: там разложу по полочкам, почему это вообще MBSE, чем живые онтологии отличаются от “диаграммы ради диаграммы”, и как такой подход масштабируется дальше (проверки, симуляции, “что если”, цифровая тень процесса).

#онтология #mbse #n8n #процессы #knowledgegraph #онтонет #onto

У Онто множество инструментов — от OntoAI до MCP-server и ассистентов вроде OntoDev и Thesaurus Assistant.

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

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

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

В статье разобрал весь процесс: от презентации до живой онтологии.

Иногда всё начинается с простой задачи — выгрузить диаграмму и туда, и сюда: в Confluence, в BI, в DrawIO…

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

OntoAI показывает, как модели LLM читают граф знаний Onto и превращают его в код, схемы и аналитику.

📘 Читайте статью:
Интеллект в графе: как структурированное знание становится капиталом

🚀 Друзья, нужен небольшой экспертный взгляд!

Мы сейчас готовим арабскую версию Онто — экземпляр для стран Ближнего Востока:
🔗 https://app.ontonet.ae/

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

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

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

Вот как «шаблон-объект» превращает любой текст в стройную модель знаний — и почему это удобно.

❓Зачем
• Единый язык: глава/раздел/абзац становятся объектами, а не “сырой простынёй”. Их можно ссылать, версионировать, сравнивать.
• Повторное использование: один и тот же раздел (например, “Интеграционный ландшафт”) живёт как объект и переиспользуется в других отчётах.
• Навигация и трассировка: от вывода → к фактам → к первоисточнику. Любая фраза имеет «адрес» в графе.
• Массовые операции: благодаря тому, что любой объект может стать шаблоном, меняем структуру отчёта или классификацию в одно действие.
• RAG по делу: ИИ работает не по PDF, а по формализованным фрагментам. Ответы точнее, ссылки — кликабельны.

❓Как сделать (хау-ту)
1. Заводим базовые шаблоны
o Глава (поля: цель, владелец, версия)
o Раздел (область, критичность, метрики)
o Абзац (тезис, цитата/источник, страница/якорь)
o Факт/Наблюдение, Риск, Рекомендация
Связи: включает →, обосновывает →, связан-с-риском →, привязан-к-источнику →.
2. Включаем «шаблон-объект»
Любой объект (например, существующий “Интеграционный ландшафт”) переводим в роль шаблона и используем как классификатор для новых разделов/абзацев.
3. Разбираем текст отчёта
🔹 Делим на главы/разделы/абзацы.
🔹 Каждый абзац — отдельный объект с ссылкой на первоисточник (файл, страница, таймкод).
🔹 Ядро смысла выносим в Факт/Наблюдение, от него вешаем Риск и Рекомендацию.
4. Собираем граф
Отчёт = Глава → Раздел → Абзац → (Факт → Риск → Рекомендация) с обратными ссылками на источники.
5. Автоматизируем
🔹 Шаблонные кнопки “разбить текст”/“создать абзацы из выделения”.
🔹 Агент, который предлагает риски и рекомендации из типовых библиотек.
🔹 Массовая переклассификация через сценарии проб (сначала на выборке, затем — bulk).

Мини-пример (аудит банковской системы)
1. Глава: Интеграционный ландшафт
1.1 Раздел: Способы интеграции
1.1.1 Абзац: “Используются MQ, файлы, REST; есть прямой доступ к БД.” (источник: стр. 12)
1.1.2 Факт: Обнаружен прямой доступ к БД из внешнего контура
1.1.3 Риск (высокий): обход сервисного слоя, утечки, сложность мониторинга
1.1.4 Рекомендация: убрать прямые коннекты; ввести API-шлюз, аудит и трассировку
2 Глава: Миграционная стратегия
2.1 Раздел: Перенос данных
2.1.1 Абзац: “Планируется dual-write и backfill.” (стр. 27)
2.1.2 Факт: Выбран подход dual-write + backfill
2.1.3 Риск (средний): расхождение состояний при сбоях
2.1.4 Рекомендация: CDC + идемпотентность + чёткая стратегия rollback

Как развивать
☑️ Библиотека доменных шаблонов: типовые главы/разделы для аудитов (платёжные контуры, закрытие дня, отчётность, миграция).
☑️ Каталог рисков и контролей: подключаем как справочник — абзац сразу “подсвечивает” релевантные риски/контроли.
☑️ Версионирование и сравнение отчётов: дифф по объектам — видно, что поменялось между аудитами.
☑️ Метрики полноты: дашборд “какие разделы закрыты фактами/рисками/рекомендациями”.
☑️ Генерация итогового PDF: отчёт собирается из объектов по шаблону, с автоматическими оглавлением и ссылками.

‼️✅ Итог
«Шаблон-объект» делает текст управляемым: из линейного документа он становится живым графом с повторным использованием, массовыми изменениями и точной ссылочностью. Для аудитов это экономит время, уменьшает риски и радикально повышает прозрачность выводов.

Шаблоны становятся важной вехой в эволюции Онто.

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

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

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

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

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

Онто❤️ становится универсальным классификатором, который помогает соединять точность мышления и естественность восприятия.

Карта развития Онто.

Дальнейшее развитие будет двигаться сразу в двух потоках:
• усиление Онто как универсального инструмента исследователя знания, усиление классификатора знаний;
• глубокая интеграция AI-ассистентов в интерфейс платформы.

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

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

🎯 Финальный кейс ЛЦТ Феста 2025: “Живое знание как процессный движок”

Этот материал — про наш путь на ЛЦТ Фест 2025 в задаче «Интеллектуальный цифровой инженер данных». Мы пришли не с ещё одним «ML-демо», а с управляемым процессом импорта: Онто как мозг (сигнатуры, профили датасетов, шаблоны пайплайнов), MCP как оркестратор шагов, MinIO для presigned-загрузки без лишнего трафика, Airflow с одним универсальным DAG и Postgres на выходе. Вместо «магии нейросети» в критическом пути — алгоритмы и правила, а LLM — ассистент и объяснитель.

Мы собрали управляемый процесс импорта данных — вместо зоопарка скриптов и “магии” нейросетей в критическом пути.
Архитектура простая и честная: Онто как мозг (сигнатуры, профили, шаблоны пайплайнов) → MCP оркеструет шаги → MinIO принимает файл по presigned URL без лишнего трафика → Airflow запускает один универсальный DAG → Postgres получает таблицу.
LLM — ассистент и объяснитель, решения принимают алгоритмы и правила.

💡 Что важно по экономике
— Сделано за 3 человеко-дня (без бесконечных MVP).
— В работе было 5 нейросетевых помощников (BA/SA, backend, DevOps, DAG, QA) — ускорение без хаоса.
— Переносим opex ИТ из “вечных доработок” в capex хранения знаний: один раз зафиксировал сигнатуры и шаблоны — дальше процесс едет по рельсам.
— Меньше трафика, меньше ручных телодвижений, больше воспроизводимости.

Почему это проходит у архитекторов и поддержки? Потому что предсказуемо, прозрачно и воспроизводимо.
Алгоритмы решают, LLM объясняет — и это снижает риски и TCO.

Подробная история, how-to и выводы:
👉 Хабр или зеркало в учебном центре Онто

#Онто #LCTFest2025 #dataengineering #Airflow #MinIO #MCP #управляемый_импорт #живое_знание