Онто-методология: от бизнес-функций и контекстов исполнения к C4-диаграммам

Бизнес-функция vs. бизнес-процесс vs. бизнес-сервис

Контекст исполнения бизнес-функции

Онтологическая модель функций и контекстов (Онто)

Переход от бизнес-функции к архитектуре (C4-модель)

Шаг 1: Диаграмма системного контекста (C4: System Context)

Шаг 2: Диаграмма контейнеров (C4: Container)

Примечание: В дополнение к стандартным контейнерам добавлен API-GW, через который Agent Web Portal взаимодействует с Backend Service. Это отражает современный паттерн интеграции.

Шаг 3: Диаграмма компонентов (C4: Component)

Примечание: Все компоненты (Subscription Manager, Billing API Client, Provisioning API Client, Data Access) являются частью Application Backend Service. Их интеграции с внешними системами реализуются через Applications типа Adapter (например, Provisioning Adapter).

Дополнительные замечания

Заключение

Интеграция RAG(Retrieval-Augmented Generation) и графов знаний в генеративных ИИ (часть 1)

Интеграция RAG(Retrieval-Augmented Generation) и графов знаний в генеративных ИИ (часть 1)

Введение

RAG и графы знаний: структурированное знание против галлюцинаций

Примеры практической интеграции графов знаний и RAG

GraphRAG от Microsoft: графовая надстройка над RAG

DataGemma от Google: привязка языковых моделей к фактам Data Commons

LightRAG и PathRAG: оптимизация знаний для эффективности

Интеграция RAG(Retrieval-Augmented Generation) и графов знаний в генеративных ИИ (выводы и заключение)

Интеграция RAG(Retrieval-Augmented Generation) и графов знаний в генеративных ИИ (Выводы и заключение)

Влияние интеграции графов знаний на качество и точность ответов

Заключение

Источники

Сноски в статье

Живое знание как процессный движок для импорта данных Часть 1 — «Предыстория и замысел»

Часть 1 — «Предыстория и замысел».

Предыстория и замысел

Живое знание как процессный движок для импорта данных Часть 2. How-to

Часть 2. How-to: один проход от пробы до Postgres

Архитектурная рамка

MCP — оркестратор шагов и API-слой

Поток из четырёх инструментов

Как это выглядит end-to-end (сверху вниз)

Почему это работает в корп-среде

Что хранит Онто — детально: что это и зачем

Что такое шаблон в Онто

Почему это важно для MCP-driven процесса

Проба: считаем сигнатуру локально (детально)

1) Что считаем (поля сигнатуры)

2) Нормализация заголовков (строго в таком порядке)

3) Кодировка и разделитель

4) Объём пробы

5) Типизация колонок (простые эвристики)

6) PII-эвристики (по сэмплу)

7) Контроль качества пробы (самопроверки)

8) Формат выходного JSON (payload сигнатуры)

9) CLI-процедура (быстрый сценарий)

10) Граница ответственности (важно)

11) Краевые случаи и что делать

Сопоставление в Онто: класс найден/создан

Алгоритм

Что получает инженер на выходе

Загрузка в MinIO: только presigned PUT

Импорт: один DAG для всех

Где здесь «живое знание»

Почему это дешевле MVP-гоночки

Чек-лист запуска

Типичные ошибки и как их не допускать

Живое знание как процессный движок для импорта данных Часть 3 — «Заключение и вывод»

Часть 3. Финал: риски LLM-оркестрации в проде, польза LLM как ассистента, экономика и рост качества

1) Почему «LLM-оркестратор» в проде — риск

2) Где LLM реально полезен (как ассистент)

3) Экономика: где мы выигрываем деньги и время

4) Качество: как растёт предсказуемость и доверие

5) Операционная модель: как «встроить» это в прод

6) Финальная позиция

Материалы

Семантический ритуал: как я извлекаю смысл из документов Часть 1 - "Мотивация"

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

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

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

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

Семантический ритуал: как я извлекаю смысл из документов Часть 2 - "Практика"

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

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

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

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

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

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

Продолжение Семантический ритуал: как я извлекаю смысл из документов Часть 3 - "Заключение"

Семантический ритуал: как я извлекаю смысл из документов Часть 3 - "Заключение"

начало Семантический ритуал: как я извлекаю смысл из документов Часть 2 - "Практика"

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

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

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

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

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

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

Материалы

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

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

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

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

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

Введение

Проблема: «мёртвые» процессы без смысла

А что если процесс – это онтология?

Почему это важно? Потому что тогда состояние становится частью онтологии:

Архитектура исполнения: где тут n8n

1) Сканируем «выполненные задачи» (ProcessExecutedTask)

{
  "method": "POST",
  "url": "https://app.ontonet.ru/api/v2/core/realm/<realmId>/entity/find/v2",
  "body": {
    "name": "",
    "comment": "",
    "metaEntityRequest": {
      "uuid": "45c30420-8b5b-4435-8bdc-930c72abc19f"
    },
    "metaFieldFilters": [],
    "pagination": {
      "first": 0,
      "offset": 100
    }
  }
}

2) Активируем соседей по связи «Ход» (AssignTask)

2.1 Получаем окружение задачи (связанные сущности):

{
  "method": "GET",
  "url": "https://app.ontonet.ru/api/v2/core/realm/<realmId>/entity/{{ $json.id }}?relatedEntities=true&relatedDiagrams=false"
}

2.2 Фильтруем соседей: берём только Ход и только задачи в “неактивном” состоянии (UUID 1bbe…):

// псевдокод фильтра в n8n (узел If)
relationName == "Ход" &&
entity.metaEntity.uuid == "1bbec7ad-6373-4bcb-b085-..."

2.3 Переводим выбранную соседнюю задачу в состояние “Назначена” через смену шаблона:

{
  "method": "PATCH",
  "url": "https://app.ontonet.ru/api/v2/core/realm/<realmId>/entity/{{ $json.entity.id }}/meta",
  "body": {
    "metaEntityId": "a885220e-f5bd-4cc3-8ff2-..."
  }
}

Мини-кейс из прототипа: как одна выполненная задача «зажигает» следующий этап

Почему это MBSE?

Заключение: исполняемый смысл как новая норма

от онтологии оливье к онтологии Деда Мороза

То не присказка, то сказка

Карта королевства

0) Сначала — не «шаблоны», а вопросы к реальности

1) Самый важный поворот: «Меню ≠ список рецептов»

2) Итоговый «скелет» модели: 8 шаблонов и понятные связи

3) Что именно делали в Onto, чтобы модель стала «живой»

4) Почему модель получилась именно такой (а не “ещё одной таблицей”)

И вот наш верный Ланселот идёт за провизией

1) Инструкция как контракт: что именно мы заставили OntoAI сделать

2) Шаг нулевой: OntoAI нашёл UUID всех шаблонов

3) Меню как план: что будет на столе

4) Рецепт и ингредиенты: раскрутка цепочки “Рецепт → Компонент → Продукт”

5) Остатки как факты: что уже есть и где оно лежит

6) Сопоставление меню и остатков: чего не хватает

7) Главное: закупка стала объектом в Onto, а не просто текстом

8) Полезная честность: текущая логика сравнения пока “булевая”

Заключение: от онтологии оливье к онтологии Деда Мороза

Поздравление

Инженерное знание как код: зачем я связываю MCP, агентов и модель изменений

От чата с агентом к графу изменений: как я перестроил проектирование фич

Это не канбан и не процессный трекер

От модели данных к модели действий

Что изменилось после появления MCP

Реальная работа идёт в чате с агентом

Диаграмма — это не место работы, а след работы

Пример: агентская память

Мотив нельзя оставлять в комментарии

User Story как граф, а не строка текста

Почему агентная разработка стала возможной

Где здесь пользовательская выгода

Что даёт MCP именно в этой связке

Почему это важно именно сейчас

Почему это не просто «ИИ помогает писать код»

Финал

Ссылки