Формализованный подход к оценке NL-to-Query систем - часть 3/3
Процесс оценки и метрики
Оценка качества модели для каждого тестового случая производится итеративно для каждой NL-вариации и включает следующие шаги:
1. Генерация и исполнение: NL-вариация обрабатывается моделью, генерируется формальный запрос, который затем исполняется в СУБД.
2. Сравнение результатов: Полученный набор данных сравнивается с эталонным результатом. Используется проверка на равенство множеств, что обеспечивает независимость результата от порядка элементов.
3. Фиксация результата: При полном совпадении множеств тест считается пройденным.
На основе результатов тестирования вычисляются следующие ключевые метрики:
- Синтаксическая корректность (Parsing Success Rate): Доля запросов, которые были сгенерированы синтаксически корректно.
- Семантическая точность (Semantic Accuracy): Доля NL-вариаций, для которых сгенерированные запросы вернули результат, полностью идентичный эталонному. Метрика характеризует способность модели распознавать семантику запроса независимо от лексико-синтаксического выражения.
Данный подход обеспечивает объективную и воспроизводимую оценку систем NL-to-Query.
Процесс оценки и метрики
Оценка качества модели для каждого тестового случая производится итеративно для каждой NL-вариации и включает следующие шаги:
1. Генерация и исполнение: NL-вариация обрабатывается моделью, генерируется формальный запрос, который затем исполняется в СУБД.
2. Сравнение результатов: Полученный набор данных сравнивается с эталонным результатом. Используется проверка на равенство множеств, что обеспечивает независимость результата от порядка элементов.
3. Фиксация результата: При полном совпадении множеств тест считается пройденным.
На основе результатов тестирования вычисляются следующие ключевые метрики:
- Синтаксическая корректность (Parsing Success Rate): Доля запросов, которые были сгенерированы синтаксически корректно.
- Семантическая точность (Semantic Accuracy): Доля NL-вариаций, для которых сгенерированные запросы вернули результат, полностью идентичный эталонному. Метрика характеризует способность модели распознавать семантику запроса независимо от лексико-синтаксического выражения.
Данный подход обеспечивает объективную и воспроизводимую оценку систем NL-to-Query.
👍1
RAG в архитектуре мультиагентных систем играет ту же роль, что R в CRUD или Q в CQRS.
1👍5🤝3
Не могу не поделиться фрагментом интерфейса 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
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, к которому структура онтологии должна быть «дружественной».
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, к которому структура онтологии должна быть «дружественной».
🤔3👍1
По просьбам подписчиков попробую пересказать предыдущий пост простыми словами.
Онтология отражает язык вашей предметной области, на котором вы разговариваете каждый день в своей работе.
Этот язык не нужно придумывать — его нужно «вытащить на поверхность» и оцифровать.
Когда вы создаёте онтологию, вы формализуете этот язык, чтобы его одинаково понимали и вы, и ваши коллеги, и машины.
В процессе создания онтологии вы и другие эксперты договариваетесь о терминах и делаете неявные знания явными.
Одновременно вы создаёте и «скелет» знаний для LLM — основу, на которую модель сможет опираться при решении ваших задач.
LLM прекрасно натренированы на синтаксисе формальных онтологий (например, Turtle) и хорошо его понимают.
Передавая онтологию в контекст LLM через промпт (in-context learning), вы выполняете «заземление» рассуждений модели (grounding) и резко снижаете вероятность галлюцинаций.
Модель буквально начинает говорить на вашем языке.
Структура формальных онтологий (тройки субъект-предикат-объект) естественным образом отображается на структуру графовых баз данных.
Разрабатывая онтологию, вы фактически проектируете схему вашей будущей графовой базы данных.
А дальше — всего один шаг, чтобы начать разговаривать с вашими данными в графовой БД на вашем языке.
Отдельный вызов — научиться фреймить контексты, чтобы не перегружать LLM и управлять её вниманием. То есть не просто передавать в модель всю онтологию, а динамически собирать из неё релевантные подграфы — «подъязыки», соответствующие конкретным задачам.
О многом из сказанного в этом тексте я уже писал в своих предыдущих постах — и пытливый ум при желании мог воссоздать эту «картину» ещё несколько месяцев назад.
Онтология отражает язык вашей предметной области, на котором вы разговариваете каждый день в своей работе.
Этот язык не нужно придумывать — его нужно «вытащить на поверхность» и оцифровать.
Когда вы создаёте онтологию, вы формализуете этот язык, чтобы его одинаково понимали и вы, и ваши коллеги, и машины.
В процессе создания онтологии вы и другие эксперты договариваетесь о терминах и делаете неявные знания явными.
Одновременно вы создаёте и «скелет» знаний для LLM — основу, на которую модель сможет опираться при решении ваших задач.
LLM прекрасно натренированы на синтаксисе формальных онтологий (например, Turtle) и хорошо его понимают.
Передавая онтологию в контекст LLM через промпт (in-context learning), вы выполняете «заземление» рассуждений модели (grounding) и резко снижаете вероятность галлюцинаций.
Модель буквально начинает говорить на вашем языке.
Структура формальных онтологий (тройки субъект-предикат-объект) естественным образом отображается на структуру графовых баз данных.
Разрабатывая онтологию, вы фактически проектируете схему вашей будущей графовой базы данных.
А дальше — всего один шаг, чтобы начать разговаривать с вашими данными в графовой БД на вашем языке.
Отдельный вызов — научиться фреймить контексты, чтобы не перегружать LLM и управлять её вниманием. То есть не просто передавать в модель всю онтологию, а динамически собирать из неё релевантные подграфы — «подъязыки», соответствующие конкретным задачам.
О многом из сказанного в этом тексте я уже писал в своих предыдущих постах — и пытливый ум при желании мог воссоздать эту «картину» ещё несколько месяцев назад.
❤8👍2
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.
🔗 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.
🔥6❤1
Чуть больше месяца назад вышла книга «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 — для формирования структуры организации команд.
От себя хочу сказать, что архитектура в отрыве от стратегии и бизнеса — это «чистое искусство».
А архитектура в отрыве от (структуры власти) оргдизайна — это «чистая фантазия».
https://www.amazon.com/Adaptive-Systems-Domain-Driven-Wardley-Topologies/dp/0137393032
Инфлюенсеры с восторгом продвигают эту книгу, однако я не советую читать её целиком — слишком много воды и утопических галлюцинаций.
Выделю жирным главную мысль, с которой я абсолютно согласен: нужно добиваться согласованности (alignment) между бизнесом, архитектурой и организационной структурой.
Для этого автор предлагает использовать три подхода, один из которых спустя два десятилетия так и остаётся ремесленным по сути:
1. Wardley Mapping — для осознания и формирования бизнес-стратегии.
2. Domain-Driven Design — для проектирования архитектуры.
3. Team Topologies — для формирования структуры организации команд.
От себя хочу сказать, что архитектура в отрыве от стратегии и бизнеса — это «чистое искусство».
А архитектура в отрыве от (структуры власти) оргдизайна — это «чистая фантазия».
🔥5💯4👍1🤝1
Пересматривал вчера «Репетицию оркестра» Феллини. Очень рекомендую.
Линия дирижёра — это линия корпоративного архитектора.
А начиная с 56-й минуты — Эджайл и отношение к архитектору в нём.
Всё как сейчас: каждый сам за себя, и все — против дирижёра.
Однако не стоит забывать уроки великого мастера.
Линия дирижёра — это линия корпоративного архитектора.
А начиная с 56-й минуты — Эджайл и отношение к архитектору в нём.
Всё как сейчас: каждый сам за себя, и все — против дирижёра.
Однако не стоит забывать уроки великого мастера.
🤔3😁2
Мы с коллегами из МИРЭА выступили на конференции «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 немного позже — с радостью поделимся, как только она выйдет.
В завершение поста хочу поблагодарить коллег из МИРЭА и Сбера за возможность заниматься исследованиями в этой области.
В одном из модулей доклада «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 немного позже — с радостью поделимся, как только она выйдет.
В завершение поста хочу поблагодарить коллег из МИРЭА и Сбера за возможность заниматься исследованиями в этой области.
❤11🔥2👍1
Я переименовал канал и сменил направление.
Миссия привнести инженерию в разработку оказалась невыполнимой. И через десять лет всё так же будут спорить «микросервисы vs монолит», хотя и то, и другое — фейк, и само это противопоставление абсурдно.
Зато в архитектуре интеллектуальных систем пока ещё можно сказать своё слово — до того, как западные хайп-пасторы придумают очередную чушь, а наши копи-пасторы разнесут её по просторам.
Миссия привнести инженерию в разработку оказалась невыполнимой. И через десять лет всё так же будут спорить «микросервисы vs монолит», хотя и то, и другое — фейк, и само это противопоставление абсурдно.
Зато в архитектуре интеллектуальных систем пока ещё можно сказать своё слово — до того, как западные хайп-пасторы придумают очередную чушь, а наши копи-пасторы разнесут её по просторам.
👍23😁6👏5❤4🤯2🍾2🔥1😢1🤩1👌1
Что такое железнодорожный пузырь?
В середине XIX века железные дороги были эквивалентом AI-стартапов:
инновации, вера в огромный рост, минимальное регулирование.
Железные дороги воспринимались как путь к быстрому обогащению, поэтому:
- компании выпускали огромные объёмы облигаций;
- банки активно кредитовали строительство;
- инвесторы покупали бумаги железных дорог почти вслепую.
В результате объём железнодорожного строительства значительно превысил реальную потребность экономики.
Пузырь лопнул, но железные дороги остались.
В середине XIX века железные дороги были эквивалентом AI-стартапов:
инновации, вера в огромный рост, минимальное регулирование.
Железные дороги воспринимались как путь к быстрому обогащению, поэтому:
- компании выпускали огромные объёмы облигаций;
- банки активно кредитовали строительство;
- инвесторы покупали бумаги железных дорог почти вслепую.
В результате объём железнодорожного строительства значительно превысил реальную потребность экономики.
Пузырь лопнул, но железные дороги остались.
🔥5👍1🤔1
Чтобы не создавать информационный вакуум, поделюсь новостями.
В Сбере мы строим САПР для архитекторов и встраиваем в него СППР. В рамках этого направления я сделал прототип 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. СППР будут играть решающую роль в САПР, поскольку при проектировании мы постоянно принимаем решения, а возможности СППР (интеллектуальных помощников) продолжают расти.
В Сбере мы строим САПР для архитекторов и встраиваем в него СППР. В рамках этого направления я сделал прототип 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. СППР будут играть решающую роль в САПР, поскольку при проектировании мы постоянно принимаем решения, а возможности СППР (интеллектуальных помощников) продолжают расти.
Telegram
Intelligent Systems Architecture
Хочу поделиться разработанной мною архитектурой Graph RAG.
Эта архитектура обладает двумя ключевыми особенностями: во-первых, наличием этапа интеллектуального планирования запроса (R), управляемого онтологией, и, во-вторых, использованием той же онтологии…
Эта архитектура обладает двумя ключевыми особенностями: во-первых, наличием этапа интеллектуального планирования запроса (R), управляемого онтологией, и, во-вторых, использованием той же онтологии…
👍5🔥3👏1🤝1
Всем привет!
Нашу статью выложили в researchgate: https://www.researchgate.net/publication/398872240_The_Use_of_LLM_in_Selecting_the_Architectural_Patterns_for_Safety_Critical_Automotive_Systems
Это предпоследний пост в этом году. Последний — контентный, дальше будет только поздравление.
Нашу статью выложили в researchgate: https://www.researchgate.net/publication/398872240_The_Use_of_LLM_in_Selecting_the_Architectural_Patterns_for_Safety_Critical_Automotive_Systems
Это предпоследний пост в этом году. Последний — контентный, дальше будет только поздравление.
ResearchGate
The Use of LLM in Selecting the Architectural Patterns for Safety Critical Automotive Systems | Request PDF
Request PDF | On Dec 19, 2025, Maxim Tikhomirov and others published The Use of LLM in Selecting the Architectural Patterns for Safety Critical Automotive Systems | Find, read and cite all the research you need on ResearchGate
1👍9🔥5⚡2
Дорогие друзья, уважаемые подписчики!
Поздравляю вас с наступающим Новым годом!
Для меня этот год был особенным: плодотворным в работе и науке, полным вызовов и ценных уроков.
Одним из важных событий для меня стала маленькая победа — преодоление рубежа в 1000 подписчиков!
Спасибо за доверие и интерес к информации, которой я с вами делюсь.
В наступающем году я желаю вам, прежде всего, крепкого здоровья — чтобы сил и энергии хватало на все планы. И пусть наступающий 2026-й год будет отмечен новыми победами — в профессии, в исследованиях и в любых начинаниях!
Впереди — много интересного. Мы заложили крепкий фундамент! С праздником!
Поздравляю вас с наступающим Новым годом!
Для меня этот год был особенным: плодотворным в работе и науке, полным вызовов и ценных уроков.
Одним из важных событий для меня стала маленькая победа — преодоление рубежа в 1000 подписчиков!
Спасибо за доверие и интерес к информации, которой я с вами делюсь.
В наступающем году я желаю вам, прежде всего, крепкого здоровья — чтобы сил и энергии хватало на все планы. И пусть наступающий 2026-й год будет отмечен новыми победами — в профессии, в исследованиях и в любых начинаниях!
Впереди — много интересного. Мы заложили крепкий фундамент! С праздником!
❤18🎄2⚡1🥰1😍1
Cursor_ai_engineering_guideline.pdf
79.6 KB
Практика довольно быстро показала: базовые инженерные принципы — контракты, инварианты, разделение ответственности — продолжают работать и в мире AI-ассистированного программирования. Более того, без них взаимодействие с LLM через агентов становится плохо управляемым.
Я набросал небольшой гайд — «Cursor AI — Engineering Standard & Governance Guide», который помогает перевести работу с AI из стохастического ремесла в воспроизводимый инженерный процесс.
Работа в этом направлении будет продолжаться. А пока — пользуйтесь, если посчитаете полезным.
Я набросал небольшой гайд — «Cursor AI — Engineering Standard & Governance Guide», который помогает перевести работу с AI из стохастического ремесла в воспроизводимый инженерный процесс.
Работа в этом направлении будет продолжаться. А пока — пользуйтесь, если посчитаете полезным.
⚡7🔥3👍2🤔1
Точка бифуркации: «агенты» не справляются — часть 1/3
Индустрия разработки с использованием ИИ приближается к развилке.
Хайп вокруг «автономных агентов» находится на пике, однако реальные проблемы уже невозможно игнорировать.
Из моего опыта: современные LLM (даже на ~30B параметров) способны хорошо генерировать код.
Главный вызов текущей агентной разработки — неконтролируемые изменения, сложности управления контекстом и чрезмерно многословные обновления.
В результате почти неизбежно происходит потеря контроля над проектом.
И дело не в моделях.
Дело в архитектуре взаимодействия с ними.
Я наблюдаю формирование двух школ мысли, которые в ближайшее время окончательно разойдутся:
• Vibe Coding — интуитивная разработка через чат, когда требования сложно сформулировать, не до конца понятно, что именно нужно сделать, или просто лень формализовывать.
• Spec-Based Engineering — детерминированная разработка на основе спецификаций.
Заглянем в будущее и сравним оба подхода.
Индустрия разработки с использованием ИИ приближается к развилке.
Хайп вокруг «автономных агентов» находится на пике, однако реальные проблемы уже невозможно игнорировать.
Из моего опыта: современные LLM (даже на ~30B параметров) способны хорошо генерировать код.
Главный вызов текущей агентной разработки — неконтролируемые изменения, сложности управления контекстом и чрезмерно многословные обновления.
В результате почти неизбежно происходит потеря контроля над проектом.
И дело не в моделях.
Дело в архитектуре взаимодействия с ними.
Я наблюдаю формирование двух школ мысли, которые в ближайшее время окончательно разойдутся:
• Vibe Coding — интуитивная разработка через чат, когда требования сложно сформулировать, не до конца понятно, что именно нужно сделать, или просто лень формализовывать.
• Spec-Based Engineering — детерминированная разработка на основе спецификаций.
Заглянем в будущее и сравним оба подхода.
❤3👍2
Вайбкодинг против инженерии: метафора 3D-принтера — часть 2/3
Давайте сравним эти два подхода.
1. Школа «Vibe Coding» (Вайбкодинг)
Это то, что нам активно продают сейчас: бесконечные контексты и идея «поговори с кодом».
Суть: разработка на основе нечеткого интента. «Сделай красиво», «поправь тут», «перепиши в другом стиле».
Результат: отлично подходит для прототипирования «на выброс». Но на длинной дистанции это путь к хаосу. Контекст размывается, энтропия растёт.
Аналогия: у вас есть 3D-принтер, и вы говорите ему: «Напечатай матрёшку». Он печатает. Потом вы говорите: «Сделай её повеселее». После сотни итераций матрёшка превращается во Франкенштейна, и никто не понимает, как вернуть её к нормальному виду.
2. Школа «Spec-Based Engineering» (инженерный подход)
Это направление, к которому неизбежно придут команды, создающие production-ready решения.
Суть: управляемая генерация на основе формализованных требований (спецификаций).
Результат: гарантированная воспроизводимость и трассируемость к требованиям.
Аналогия: вы не разговариваете с принтером. Вы загружаете в него STL-файл (спецификацию) конкретной матрёшки. Результат всегда одинаковый. Хотите изменить изделие? Вы правите не пластик (код), а чертёж (спецификацию).
Давайте сравним эти два подхода.
1. Школа «Vibe Coding» (Вайбкодинг)
Это то, что нам активно продают сейчас: бесконечные контексты и идея «поговори с кодом».
Суть: разработка на основе нечеткого интента. «Сделай красиво», «поправь тут», «перепиши в другом стиле».
Результат: отлично подходит для прототипирования «на выброс». Но на длинной дистанции это путь к хаосу. Контекст размывается, энтропия растёт.
Аналогия: у вас есть 3D-принтер, и вы говорите ему: «Напечатай матрёшку». Он печатает. Потом вы говорите: «Сделай её повеселее». После сотни итераций матрёшка превращается во Франкенштейна, и никто не понимает, как вернуть её к нормальному виду.
2. Школа «Spec-Based Engineering» (инженерный подход)
Это направление, к которому неизбежно придут команды, создающие production-ready решения.
Суть: управляемая генерация на основе формализованных требований (спецификаций).
Результат: гарантированная воспроизводимость и трассируемость к требованиям.
Аналогия: вы не разговариваете с принтером. Вы загружаете в него STL-файл (спецификацию) конкретной матрёшки. Результат всегда одинаковый. Хотите изменить изделие? Вы правите не пластик (код), а чертёж (спецификацию).
❤6👍4
Software 3.0: LLM как компилятор — часть 3/3
Как реализовать инженерный подход на практике?
Нужно перестать относиться к LLM как к «собеседнику».
В парадигме Software 3.0 нейросеть — это компилятор.
Мы пишем спецификации — это наш новый исходный код.
А LLM, зажатая в строгий пайплайн (TDD, машины состояний), компилирует эти спецификации в рабочий софт.
Если нам нужен надёжный результат, а не «генеративное искусство», пора переходить от промптов к инженерии спецификаций.
Это и есть Software 3.0 в моём понимании:
когда код генерируется машиной, но управляется формальной логикой спецификаций.
Как реализовать инженерный подход на практике?
Нужно перестать относиться к LLM как к «собеседнику».
В парадигме Software 3.0 нейросеть — это компилятор.
Мы пишем спецификации — это наш новый исходный код.
А LLM, зажатая в строгий пайплайн (TDD, машины состояний), компилирует эти спецификации в рабочий софт.
Если нам нужен надёжный результат, а не «генеративное искусство», пора переходить от промптов к инженерии спецификаций.
Это и есть Software 3.0 в моём понимании:
когда код генерируется машиной, но управляется формальной логикой спецификаций.
👍23❤1🤝1
Forwarded from Блог Сергея Баранова (Сергей Баранов)
Темпоральность в Event Storming
Вчера обсуждали с Геной Кругловым темпоральность в Event Storning, а сегодня выступал перед участниками IN HUB с темой «Картина производственной системы за часы» (домен промышленного производства и смежных отраслей) и был у меня в презентации такой слайд и вчерашнее обсуждение и сегодняшнее выступление привели к новым мыслям.
Так вот, на этом слайде сразу четыре темпоральности (авторская интерпретация и она может измениться):
▪️Хаос (Chaotic Exploration)
Здесь только темпоральность события как высказывания с точки зрения семантики (по модели Рейхенбаха). События концептуально относены ко времени.
▪️Хронология (timeline enforcement)
Это интерсубъективно разделяемая хронология. Ключевой смысл в том, что здесь появляется темпоральность модели как структуры. В самой структуре появляется отношение порядка. Однако, пока только порядка (раньше/позже) и это важно.
▪️Контекст (обогащение модели, в первую очередь через Policy в рассматриваемом контекст)
В хронологии появляется своего рода реактивная темпоральность. На самом деле это кусочки реактивной темпоральности. Политики позволяют отличить автоматизированную реактивность от человеческой и вводят критерий верификации модели: Почему эта команда выполняется? При каких условиях? Всегда ли? Отсутствие явных политик делает причинно-следственные связи неявными и модель теряет способность отвечать на вопросы «Почему?» и «В каком случае/когда?»
▪️История (Narrative / Reverse Narrative
А здесь самое интересное. Это нарративная темпоральность (Paul Ricoeur, Джером Брунер), история, общий нарратив, обеспечивает переход от «позже - не значит вследствие» к «это вследствие вот этого». Это усиление темпоральности модели причинно-следственными связями.
А теперь прикладной вывод: если мы можем построить согласованную историю, построенную полностью на основе реактивной автоматизированной темпоральности (между каждым событием и командой поставить Policy), то мы можем с большей степенью уверенности говорить, что описанный процесс может быть реализован с помощью автономного ИИ-агента или мультиагентной системы.
Однако на текущий момент требуется больше наработок, потому что:
▪️Не факт, что агенты способны интерпретировать все типы Policy
▪️Человеческий контекст и неформализуемые аспекты могут оказать существенное влияние
▪️Техническая реализуемость не следует прямо из концептуальной полноты модели
Вчера обсуждали с Геной Кругловым темпоральность в Event Storning, а сегодня выступал перед участниками IN HUB с темой «Картина производственной системы за часы» (домен промышленного производства и смежных отраслей) и был у меня в презентации такой слайд и вчерашнее обсуждение и сегодняшнее выступление привели к новым мыслям.
Так вот, на этом слайде сразу четыре темпоральности (авторская интерпретация и она может измениться):
▪️Хаос (Chaotic Exploration)
Здесь только темпоральность события как высказывания с точки зрения семантики (по модели Рейхенбаха). События концептуально относены ко времени.
▪️Хронология (timeline enforcement)
Это интерсубъективно разделяемая хронология. Ключевой смысл в том, что здесь появляется темпоральность модели как структуры. В самой структуре появляется отношение порядка. Однако, пока только порядка (раньше/позже) и это важно.
▪️Контекст (обогащение модели, в первую очередь через Policy в рассматриваемом контекст)
В хронологии появляется своего рода реактивная темпоральность. На самом деле это кусочки реактивной темпоральности. Политики позволяют отличить автоматизированную реактивность от человеческой и вводят критерий верификации модели: Почему эта команда выполняется? При каких условиях? Всегда ли? Отсутствие явных политик делает причинно-следственные связи неявными и модель теряет способность отвечать на вопросы «Почему?» и «В каком случае/когда?»
▪️История (Narrative / Reverse Narrative
А здесь самое интересное. Это нарративная темпоральность (Paul Ricoeur, Джером Брунер), история, общий нарратив, обеспечивает переход от «позже - не значит вследствие» к «это вследствие вот этого». Это усиление темпоральности модели причинно-следственными связями.
А теперь прикладной вывод: если мы можем построить согласованную историю, построенную полностью на основе реактивной автоматизированной темпоральности (между каждым событием и командой поставить Policy), то мы можем с большей степенью уверенности говорить, что описанный процесс может быть реализован с помощью автономного ИИ-агента или мультиагентной системы.
Однако на текущий момент требуется больше наработок, потому что:
▪️Не факт, что агенты способны интерпретировать все типы Policy
▪️Человеческий контекст и неформализуемые аспекты могут оказать существенное влияние
▪️Техническая реализуемость не следует прямо из концептуальной полноты модели
🔥3❤1