Jupyter в Cursor даёт буст в продуктивности для R&D. Работать иначе уже почти немыслимо.
И, честно говоря, студентов стоит учить ML сразу в таком окружении. Очень хочется, чтобы подобные среды появлялись и у нас — с адекватными условиями для учащихся.
И, честно говоря, студентов стоит учить ML сразу в таком окружении. Очень хочется, чтобы подобные среды появлялись и у нас — с адекватными условиями для учащихся.
🥰1
Галлюцинации LLM и закат ИИ
После публикации статьи https://arxiv.org/abs/2509.04664 инфлюенсеры заговорили о «закате ИИ». Аргумент прост: если LLM подвержены галлюцинациям, то им нельзя доверять. Но не всё так однозначно.
1. LLM — это не весь ИИ, а крест ставят на всём ИИ.
2. Генеративные LLM типа GPT обучаются предсказывать следующий токен с помощью авторегрессии. Это принцип пошагового построения текста: модель каждый раз достраивает последовательность слов на основе ранее сгенерированной последовательности. Авторегрессивный подход критически важен для масштабирования: он позволяет эффективно обучать модели на огромных объемах текста, поскольку каждое слово в тексте становится и входными данными, и целевым значением для обучения. Без авторегрессии создание действительно больших языковых моделей было бы технически невозможно. Но именно у больших моделей и проявляются эмерджентные свойства — способности, которые не закладывались напрямую при обучении, но возникают при увеличении масштаба модели.
3. Модель всегда что-то генерирует: если нет точного ответа, она создаёт максимально правдоподобную последовательность токенов (отдельных слов, их частей, знаков препинания и т. д.).
В научной литературе термин "галлюцинации" охватывает все виды неточных генераций LLM. Для практического анализа можно выделить:
- Правдоподобные ошибки — логичные, но фактически неверные ответы, часто содержащие смесь правильной и неправильной информации.
- Бессвязные генерации — хаотичный набор токенов, включая переключения между языками или явно нелогичные конструкции.
Современные LLM чаще производят правдоподобные ошибки, чем полностью бессвязный текст. И это не всегда плохо. Способность генерировать правдоподобные, логически связные тексты даже при отсутствии точных данных может быть полезным свойством для творческих задач, генерации идей или работы с неполной информацией. Вспомните продавцов, пиарщиков или маркетологов: умение быстро и убедительно «додумать» недостающую часть информации — для них ключевой профессиональный навык, а не недостаток.
Важно понимать контекст применения: там где нужна фактическая точность, такие генерации проблематичны, но в творческих, коммуникативных и эвристических задачах они могут быть ценны.
Поэтому преждевременно утверждать о «закате ИИ», учитывая, что речь идёт исключительно об LLM.
Да и для LLM не всё потеряно. Уже намечен следующий шаг — калибровка уверенности: научить модели оценивать и выражать степень достоверности своих ответов, чтобы человек понимал, где можно доверять модели, а где — лучше перепроверить. Для этого разрабатываются методы обучения моделей самооценке точности генерации и создаются новые бенчмарки, которые оценивают не только содержательность, но и надёжность ответов.
После публикации статьи https://arxiv.org/abs/2509.04664 инфлюенсеры заговорили о «закате ИИ». Аргумент прост: если LLM подвержены галлюцинациям, то им нельзя доверять. Но не всё так однозначно.
1. LLM — это не весь ИИ, а крест ставят на всём ИИ.
2. Генеративные LLM типа GPT обучаются предсказывать следующий токен с помощью авторегрессии. Это принцип пошагового построения текста: модель каждый раз достраивает последовательность слов на основе ранее сгенерированной последовательности. Авторегрессивный подход критически важен для масштабирования: он позволяет эффективно обучать модели на огромных объемах текста, поскольку каждое слово в тексте становится и входными данными, и целевым значением для обучения. Без авторегрессии создание действительно больших языковых моделей было бы технически невозможно. Но именно у больших моделей и проявляются эмерджентные свойства — способности, которые не закладывались напрямую при обучении, но возникают при увеличении масштаба модели.
3. Модель всегда что-то генерирует: если нет точного ответа, она создаёт максимально правдоподобную последовательность токенов (отдельных слов, их частей, знаков препинания и т. д.).
В научной литературе термин "галлюцинации" охватывает все виды неточных генераций LLM. Для практического анализа можно выделить:
- Правдоподобные ошибки — логичные, но фактически неверные ответы, часто содержащие смесь правильной и неправильной информации.
- Бессвязные генерации — хаотичный набор токенов, включая переключения между языками или явно нелогичные конструкции.
Современные LLM чаще производят правдоподобные ошибки, чем полностью бессвязный текст. И это не всегда плохо. Способность генерировать правдоподобные, логически связные тексты даже при отсутствии точных данных может быть полезным свойством для творческих задач, генерации идей или работы с неполной информацией. Вспомните продавцов, пиарщиков или маркетологов: умение быстро и убедительно «додумать» недостающую часть информации — для них ключевой профессиональный навык, а не недостаток.
Важно понимать контекст применения: там где нужна фактическая точность, такие генерации проблематичны, но в творческих, коммуникативных и эвристических задачах они могут быть ценны.
Поэтому преждевременно утверждать о «закате ИИ», учитывая, что речь идёт исключительно об LLM.
Да и для LLM не всё потеряно. Уже намечен следующий шаг — калибровка уверенности: научить модели оценивать и выражать степень достоверности своих ответов, чтобы человек понимал, где можно доверять модели, а где — лучше перепроверить. Для этого разрабатываются методы обучения моделей самооценке точности генерации и создаются новые бенчмарки, которые оценивают не только содержательность, но и надёжность ответов.
🔥3🤝3❤2✍1
Хочу поделиться разработанной мною архитектурой Graph RAG.
Эта архитектура обладает двумя ключевыми особенностями: во-первых, наличием этапа интеллектуального планирования запроса (R), управляемого онтологией, и, во-вторых, использованием той же онтологии для семантического обогащения и контекстуализации ответа (A-G).
Важную роль играет генерация промежуточного представления (Intermediate Representation, IR) — структурированного, независимого от языка запросов объекта (например, JSON), формализующего намерение пользователя. IR позволяет абстрагироваться от особенностей конкретных СУБД и, тем самым, подключать разные базы данных без влияния на остальные компоненты архитектуры.
Отдельно стоит отметить особенность работы Модуля Валидации: его результаты (успех, тип ошибки, данные `EXPLAIN`) могут использоваться для автоматического сбора сигналов обратной связи (reward signal) и дообучения (fine-tuning) модулей генерации кода. Это создает замкнутый контур для непрерывного, автоматизированного улучшения качества генерации запросов.
Прошу не судить строго за визуализацию — она целиком сгенерирована по описанию архитектуры.
Эта архитектура обладает двумя ключевыми особенностями: во-первых, наличием этапа интеллектуального планирования запроса (R), управляемого онтологией, и, во-вторых, использованием той же онтологии для семантического обогащения и контекстуализации ответа (A-G).
Важную роль играет генерация промежуточного представления (Intermediate Representation, IR) — структурированного, независимого от языка запросов объекта (например, JSON), формализующего намерение пользователя. IR позволяет абстрагироваться от особенностей конкретных СУБД и, тем самым, подключать разные базы данных без влияния на остальные компоненты архитектуры.
Отдельно стоит отметить особенность работы Модуля Валидации: его результаты (успех, тип ошибки, данные `EXPLAIN`) могут использоваться для автоматического сбора сигналов обратной связи (reward signal) и дообучения (fine-tuning) модулей генерации кода. Это создает замкнутый контур для непрерывного, автоматизированного улучшения качества генерации запросов.
Прошу не судить строго за визуализацию — она целиком сгенерирована по описанию архитектуры.
1🔥8👍6👏1🤔1
Вдохновение для промптинга слабых моделей нужно черпать не в гайдах Anthropic, а у Джоэла Спольски
❤1👍1
Формализованный подход к оценке NL-to-Query систем - часть 1/3
Первая итерация реализации прототипа предложенной мной архитектуры Graph RAG завершена. В процессе работы удалось получить ряд инсайтов, одним из которых я поделюсь в этой серии постов.
В процессе разработки возникла потребность в оценке качества генерации запросов. Я адаптировал execution-based подход к оценке с акцентом на робастность к различным формулировкам: подход измеряет семантическую точность через сравнение результатов выполнения, а не через анализ синтаксиса сгенерированных запросов.
Почему синтаксическое сравнение не работает?
Оценка NL-to-Query систем осложняется двумя факторами:
1. Вариативность языка: одну и ту же мысль можно выразить множеством способов.
2. Семантическая эквивалентность: разные запросы могут давать одинаковый результат.
Это означает, что прямое сравнение "сгенерированный запрос = эталонный запрос" — неадекватная метрика. Она штрафует синтаксически различные, но при этом корректные решения.
Решение: оценивать не синтаксис запроса, а результат его выполнения.
Первая итерация реализации прототипа предложенной мной архитектуры Graph RAG завершена. В процессе работы удалось получить ряд инсайтов, одним из которых я поделюсь в этой серии постов.
В процессе разработки возникла потребность в оценке качества генерации запросов. Я адаптировал execution-based подход к оценке с акцентом на робастность к различным формулировкам: подход измеряет семантическую точность через сравнение результатов выполнения, а не через анализ синтаксиса сгенерированных запросов.
Почему синтаксическое сравнение не работает?
Оценка NL-to-Query систем осложняется двумя факторами:
1. Вариативность языка: одну и ту же мысль можно выразить множеством способов.
2. Семантическая эквивалентность: разные запросы могут давать одинаковый результат.
Это означает, что прямое сравнение "сгенерированный запрос = эталонный запрос" — неадекватная метрика. Она штрафует синтаксически различные, но при этом корректные решения.
Решение: оценивать не синтаксис запроса, а результат его выполнения.
👍2
Формализованный подход к оценке NL-to-Query систем - часть 2/3
Структура тестового набора
Тестирование проводится на фиксированном эталонном наборе данных (Reference Dataset), что обеспечивает воспроизводимость результатов.
Каждый тестовый случай включает три элемента:
1. Эталонный Запрос (Reference Query ): Канонический, верифицированный экспертом запрос к СУБД.
2. Эталонный Результат (Reference Result Set): Множество данных, полученное при выполнении эталонного запроса на эталонном наборе данных. Служит "истинным" результатом для всех сравнений.
3. Множество NL-вариаций: Репрезентативная выборка текстовых формулировок на естественном языке, которые семантически эквивалентны эталонному запросу.
Структура тестового набора
Тестирование проводится на фиксированном эталонном наборе данных (Reference Dataset), что обеспечивает воспроизводимость результатов.
Каждый тестовый случай включает три элемента:
1. Эталонный Запрос (Reference Query ): Канонический, верифицированный экспертом запрос к СУБД.
2. Эталонный Результат (Reference Result Set): Множество данных, полученное при выполнении эталонного запроса на эталонном наборе данных. Служит "истинным" результатом для всех сравнений.
3. Множество NL-вариаций: Репрезентативная выборка текстовых формулировок на естественном языке, которые семантически эквивалентны эталонному запросу.
Формализованный подход к оценке 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💯3👍1🤝1
Пересматривал вчера «Репетицию оркестра» Феллини. Очень рекомендую.
Линия дирижёра — это линия корпоративного архитектора.
А начиная с 56-й минуты — Эджайл и отношение к архитектору в нём.
Всё как сейчас: каждый сам за себя, и все — против дирижёра.
Однако не стоит забывать уроки великого мастера.
Линия дирижёра — это линия корпоративного архитектора.
А начиная с 56-й минуты — Эджайл и отношение к архитектору в нём.
Всё как сейчас: каждый сам за себя, и все — против дирижёра.
Однако не стоит забывать уроки великого мастера.
🤔3😁2
Новые подходы к разработке и архитектурные стили рождаются из наблюдения. Сегодня мы наблюдаем торжество подхода, ставшего венцом эволюции через отрицательный отбор. Я обобщил его принципы и выразил их в манифесте.
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.
Ретроспективы на сеансах терапии.
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.
Ретроспективы на сеансах терапии.
💔8🔥2😁1🤩1
Мы с коллегами из МИРЭА выступили на конференции «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 монолит», хотя и то, и другое — фейк, и само это противопоставление абсурдно.
Зато в архитектуре интеллектуальных систем пока ещё можно сказать своё слово — до того, как западные хайп-пасторы придумают очередную чушь, а наши копи-пасторы разнесут её по просторам.
👍22😁6👏5❤4🤯2🍾2🔥1😢1🤩1👌1
Что такое железнодорожный пузырь?
В середине XIX века железные дороги были эквивалентом AI-стартапов:
инновации, вера в огромный рост, минимальное регулирование.
Железные дороги воспринимались как путь к быстрому обогащению, поэтому:
- компании выпускали огромные объёмы облигаций;
- банки активно кредитовали строительство;
- инвесторы покупали бумаги железных дорог почти вслепую.
В результате объём железнодорожного строительства значительно превысил реальную потребность экономики.
Пузырь лопнул, но железные дороги остались.
В середине XIX века железные дороги были эквивалентом AI-стартапов:
инновации, вера в огромный рост, минимальное регулирование.
Железные дороги воспринимались как путь к быстрому обогащению, поэтому:
- компании выпускали огромные объёмы облигаций;
- банки активно кредитовали строительство;
- инвесторы покупали бумаги железных дорог почти вслепую.
В результате объём железнодорожного строительства значительно превысил реальную потребность экономики.
Пузырь лопнул, но железные дороги остались.
🔥4👍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
Как оценить мотивацию и истинную готовность к внедрению инноваций?
Терми́т — это пиротехническая смесь порошков (например, алюминия и оксида железа), при воспламенении выделяющая температуру порядка 2500°C и продолжающая гореть независимо от наличия атмосферного кислорода, поскольку окисление происходит за счёт кислорода, содержащегося в самом оксиде металла.
Вот если у лидеров на заднице горит термитная смесь и потушить пламя уже нет никакой возможности — время говорить о внедрении инноваций пришло.
Терми́т — это пиротехническая смесь порошков (например, алюминия и оксида железа), при воспламенении выделяющая температуру порядка 2500°C и продолжающая гореть независимо от наличия атмосферного кислорода, поскольку окисление происходит за счёт кислорода, содержащегося в самом оксиде металла.
Вот если у лидеров на заднице горит термитная смесь и потушить пламя уже нет никакой возможности — время говорить о внедрении инноваций пришло.
❤3👍1