RAG в архитектуре мультиагентных систем играет ту же роль, что R в CRUD или Q в CQRS.

Не могу не поделиться фрагментом интерфейса Memgraph Lab: Memgraph Lab’s LLM integrations allow you to chat with Memgraph in English, without needing to know Cypher.

https://memgraph.com/docs/memgraph-lab/features/graphchat

https://memgraph.com/docs/memgraph-lab/features/graphchat

Note: Large graph schemas can consume significant tokens in the LLM’s context window. In such cases, consider disabling automatic inclusion of the graph schema to optimize cost and performance.

Прелесть Cypher-баз данных в том, что при наличии онтологии graph schema - это и есть онтология.

И самое интересное начинается там, где схемы становятся большими.
Это «интересное» — context engineering, к которому структура онтологии должна быть «дружественной».

По просьбам подписчиков попробую пересказать предыдущий пост простыми словами.

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

Этот язык не нужно придумывать — его нужно «вытащить на поверхность» и оцифровать.

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

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

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

LLM прекрасно натренированы на синтаксисе формальных онтологий (например, Turtle) и хорошо его понимают.

Передавая онтологию в контекст LLM через промпт (in-context learning), вы выполняете «заземление» рассуждений модели (grounding) и резко снижаете вероятность галлюцинаций.

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

Структура формальных онтологий (тройки субъект-предикат-объект) естественным образом отображается на структуру графовых баз данных.
Разрабатывая онтологию, вы фактически проектируете схему вашей будущей графовой базы данных.

А дальше — всего один шаг, чтобы начать разговаривать с вашими данными в графовой БД на вашем языке.

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

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

Qdrant опубликовал туториал, в котором показал, как можно строить RAG-системы на базе Neo4j и Qdrant:
🔗 https://qdrant.tech/documentation/examples/graphrag-qdrant-neo4j/

В этом туториале демонстрируется совместное использование графовой и векторной баз данных для построения гибридного RAG, объединяющего графовый и векторный (R) retrieval.

Особое внимание заслуживает шаг 2. Ontology Creation:

An LLM processes the raw data into an ontology, structuring entities, relationships, and hierarchies. Better approaches exist to extracting more structured information from raw data, like using NER to identify the names of people, organizations, and places.

На самом деле на этом шаге выполняется построение графа знаний (knowledge graph), о чём авторы прямо упоминают в статье. При этом понятия ontology и knowledge graph в тексте фактически подменяются, и роль онтологии остаётся нераскрытой.

Приведу показательный фрагмент:

LM-centric GraphRAG approach faces several challenges:
KG Construction with LLMs: Since the LLM is responsible for constructing the knowledge graph, there are risks such as inconsistencies, propagation of biases or errors, and lack of control over the ontology used. However, we used an LLM to extract the ontology in our implementation…

Для production-систем необходима чётко определённая онтология, разработанная экспертами предметной области — возможно, с использованием подхода LLM-assisted ontology engineering.

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

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

Чуть больше месяца назад вышла книга «Architecture for Flow» Сюзанны Кайзер:
https://www.amazon.com/Adaptive-Systems-Domain-Driven-Wardley-Topologies/dp/0137393032

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

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

Для этого автор предлагает использовать три подхода, один из которых спустя два десятилетия так и остаётся ремесленным по сути:

1. Wardley Mapping — для осознания и формирования бизнес-стратегии.
2. Domain-Driven Design — для проектирования архитектуры.
3. Team Topologies — для формирования структуры организации команд.

От себя хочу сказать, что архитектура в отрыве от стратегии и бизнеса — это «чистое искусство».
А архитектура в отрыве от (структуры власти) оргдизайна — это «чистая фантазия».

Пересматривал вчера «Репетицию оркестра» Феллини. Очень рекомендую.

Линия дирижёра — это линия корпоративного архитектора.
А начиная с 56-й минуты — Эджайл и отношение к архитектору в нём.

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

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

PZD-Driven Development (Persistent Zero-Discipline Driven Development):
PZD-Разработка (Разработка, ведомая устойчивым отсутствием дисциплины):

1. Discipline is optional, delivery is mandatory.
Дисциплина необязательна, выкатка обязательна.
2. Increment through firefighting.
Инкремент через тушение пожаров.
3. Architecture emerges from survival.
Архитектура порождается выживанием.
4. Documentation as an Archaeological Diary.
Документация как археологический дневник.
5. Retrospectives in therapy.
Ретроспективы на сеансах терапии.

Мы с коллегами из МИРЭА выступили на конференции «International Conference on Intelligent Information Technologies for Industry (IITI 25)».

В одном из модулей доклада «The Use of LLM in Selecting the Architectural Patterns for Safety-Critical Automotive Systems» мы представили «AI Assisted Safety Tactic Selection algorithm», где ещё в начале года применили нейросимволическую интеграцию — подход, который сейчас становится трендом и набирает обороты.

Вот фрагмент этого модуля:

We propose the "AI Assisted Safety Tactic Selection" algorithm, a hybrid approach that utilizes the strengths of Large Language Models in natural language processing and structured knowledge in ontologies.

The algorithm proceeds through four main steps:
1. It spots potential failure modes using an LLM, then double checks them against a safety ontology.
2. It pulls relevant safety tactics using a symbolic lookup.
3. The LLM suggests alternative sets of tactics, but keeps them grounded in real domain knowledge.
4. It lets the system architect review and fine-tune the suggestions interactively.

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

В завершение поста хочу поблагодарить коллег из МИРЭА и Сбера за возможность заниматься исследованиями в этой области.

Я переименовал канал и сменил направление.

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

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

Что такое железнодорожный пузырь?

В середине XIX века железные дороги были эквивалентом AI-стартапов:
инновации, вера в огромный рост, минимальное регулирование.

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

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

Пузырь лопнул, но железные дороги остались.

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

В Сбере мы строим САПР для архитекторов и встраиваем в него СППР. В рамках этого направления я сделал прототип GraphRAG с NL-to-Query с устойчивой точностью 85-100%, заметно обновив изначальный концепт: https://news.1rj.ru/str/IntelligentSystemsArchitecture/328

Параллельно начал работу над Reasoning RAG (https://news.1rj.ru/str/IntelligentSystemsArchitecture/293), и первые результаты уже выглядят многообещающе. Поделюсь наработками в статьях в следующем году.

И GraphRAG, и тем более Reasoning RAG имеют нейросимволическую архитектуру, в которой онтологии играют решающую роль.

Тезисы:
1. RAG-системы меняют подход к организации доступа к корпоративным знаниям — они комбинируют «умный» поиск на основе запросов на естественном языке с исследованием гетерогенных баз знаний.
2. СППР будут играть решающую роль в САПР, поскольку при проектировании мы постоянно принимаем решения, а возможности СППР (интеллектуальных помощников) продолжают расти.

Как оценить мотивацию и истинную готовность к внедрению инноваций?

Терми́т — это пиротехническая смесь порошков (например, алюминия и оксида железа), при воспламенении выделяющая температуру порядка 2500°C и продолжающая гореть независимо от наличия атмосферного кислорода, поскольку окисление происходит за счёт кислорода, содержащегося в самом оксиде металла.

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