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

Начинаю делиться обзорами, которые делаю для себя с помощью инструментов Deep Research от Gemini и Claude.

В этом посте — обзор «Системное мышление: обзор определений и концепций».

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

От себя хочу добавить: архитекторы, по сути, синтезируют структуры, которые во многом определяют будущие характеристики систем — в первую очередь их способность к развитию.

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

"Ричмонд (Richmond) предлагает определение, описывая системное мышление как "the art and science of making reliable inferences about behavior by developing an increasingly deep understanding of underlying structure". Он подчеркивает важность понимания того, что "structure drives behavior".

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

В продолжение этой мысли, в этом посте я делюсь кратким обзором из моего небольшого исследования «Применение фрейминга и рефрейминга в инженерной практике», где поднимается вопрос: как можно целенаправленно влиять на интерпретацию.

А чего ты расплываешься по древу знаний? Какая связь между твоими постами? Сам-то ты фреймингом пользуешься?» — спросите вы. А кто-то, решив, что автор — городской сумасшедший, просто отпишется от канала.

Но связь есть, и вот она:

1. В ближайшем будущем моделям (в первую очередь LLM) придётся передавать семантику ваших предметных областей — парадоксально, ведь LLM уже “содержат все знания мира”, — но без этого, как и сейчас, результаты будут неутешительны.

2. Формальные онтологии — точный и мощный инструмент для выражения семантики предметных областей и передачи её между интеллектами — как человеческими, так и искусственными.

3. Даже понять важные структуры систем без системного мышления не возможно.

4. Без понимания структур систем невозможно осознанно применять фрейминг.

5. Без фрейминга не получится эффективно управлять контекстом и вниманием — ни своим, ни моделей.

6. Сейчас я разрабатываю метод концептуализации (построения онтологий), который, помимо прочего, существенно упростит фрейминг контекстов и управление вниманием.

LLM и логика: видимость мышления или настоящее понимание?

Бенчмарки действительно показывают, что LLM становятся все лучше в решении задач, которые мы классифицируем как "логические".

Разберёмся, почему это так, и в чём принципиальные ограничения таких моделей по сравнению с классическими символьными (логическими) системами при выполнении формального логического вывода.

LLM обучаются на огромных объемах текста. Этот текст включает в себя бесчисленное множество примеров рассуждений, аргументов, математических доказательств, описаний логических головоломок и их решений.

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

Улучшение на бенчмарках часто означает, что модель стала лучше распознавать эти паттерны, даже в сложных и запутанных формах, и генерировать текст, который соответствует ожидаемому "логическому" результату.

Вместо того чтобы следовать строгим правилам логического вывода (как это делают, например, OWL-reasoners ), LLM развивают своего рода "статистическую интуицию". Если в обучающих данных определённые типы посылок часто приводят к определённым выводам, модель начинает считать такую связь высоковероятной.

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

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

Именно так и работает LLM.

В дополнение к предыдущему посту — Часть 1/2: Про “понимание” в LLM

LLM учится ассоциировать определенные входные последовательности с определенными выходными последовательностями, которые часто встречались вместе в обучающих данных.

Основная задача LLM — предсказать следующий токен в последовательности. Когда модель многократно встречает последовательность "1 + 1 =", она замечает, что статистически наиболее вероятным следующим токеном является "2".

Распознавание паттернов:

Модель не "вычисляет" сумму. Она распознает текстовый паттерн. "1 + 1 =" — это для нее такой же паттерн, как "столица Франции -" (после чего наиболее вероятным будет "Париж").

Обобщение (в некоторой степени):

Помимо запоминания конкретного примера "1 + 1 = 2", модель также видит множество других арифметических примеров: "2 + 2 = 4", "5 - 3 = 2", "2 * 3 = 6" и т.д. Это позволяет ей выучить более общие паттерны, связанные с математическими операциями в текстовом виде.

Однако это обобщение все еще основано на текстовых паттернах, а не на понимании математических аксиом.

Что важно понимать:

Это не математическое "понимание": LLM не "понимает" концепцию числа или операции сложения так, как человек. Она просто знает, что после текстовой строки "1 + 1 =" с очень высокой вероятностью должна идти текстовая строка "2".

В дополнение к предыдущему посту — Часть 2/2: Про практику в архитектуре

LLM не рационально использовать в роли "калькулятора", потому что она может ошибиться в вычислениях, особенно в тех, что выходят за рамки простейших и часто встречающихся примеров. Хотя ошибка в сложении '1+1' сегодня действительно крайне маловероятна.

Кроме того, это дорого — токены чего-то стоят, обучение моделей требует затрат, - видеокарты заметно греют воздух.

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

В итоге возникает вопрос: что же делать в эпоху массовой ИИ-трансформации, когда уже сформированы ожидания, будто в архитектуре останутся только LLM и данные, на которые они будут "смотреть"?

Ответ на этот вопрос лежит в гибридных архитектурах. А это уже промышленная — то есть не vibe-, а рациональная архитектура.

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

Шутка для тех, кто в теме LLM: температура 1.0 — это Гартнер (крепко), 1.5 — это уже Маккинзи (забористо).

Прокомменрирую пост Жени Истомина.

Структурный и темпоральный аспекты систем.

Любая «живая» система имеет структуру и подвержена изменениям во времени (темпоральность).

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

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

Состояние системы можно рассматривать как своего рода мост между структурным и темпоральным аспектами системы.

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

Пример: В организме структура — это анатомия (строение тела), а процессы — это метаболизм, рост, старение.

Человек из-за ограниченных когнитивных способностей не может одновременно охватить все элементы системы (вплоть до мельчайших деталей) и их взаимосвязи. Поэтому мы разделяем структуру системы на разные (вложенные) структуры, выстраиваем иерархии и рассматриваем систему по частям — на разных уровнях абстракции.

В (социотехнических) software-intensive системах, например, можно выделить, как минимум, следующие типы структур:

- Ценностная - кому и какую ценность приносит система;
- Организационная — кто за что отвечает;
- Коммуникационная — кто с кем и по каким каналам взаимодействует;
- Функциональная — какие подсистемы какие функции выполняют;
- Структура данных - какие функции какими данными манипулируют;
- Конструктивная — какие компоненты какие функции воплощают;
- Инфраструктурная (или размещения) — на какой инфраструктуре какие компоненты развёрнуты.

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

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

Следовательно, модели (включая архитектуру) систем должны учитывать не только их статичные структуры, но и временной аспект.

Процессы, протекающие в системе, непрерывно изменяют её структуру хотя бы на микроуровне.

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

То же самое происходит и с работающей (живой) информационной системой — её структура непрерывно изменяется, пусть даже на уровне байтов.

Мы склонны игнорировать эти микроскопические изменения, пока не сталкиваемся с последствиями: заканчивается место на дисках, падает пропускная способность, замедляется «метаболизм».

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

Можно задать себе вопрос: насколько хорошо наши модели подходят для анализа влияния изменений (impact analysis)?

Немного визионерства.

Как завершится ЭйАй-трансформация уже совсем скоро?

1. LLM по плану заменит всех сотрудников, но людей для суппорта этой трэшанины нужно будет ещё больше
2. Сотрудников переназовут ЭйАй-партнёрами
3. Отпразднуют успешное завершение трансформации и объявят новый тренд - Омницентричность, где в центре будет и LLM, и его партнёры, в завимости от контекста

Пелевин в Generation "П" был прав.

Привнесу новый концепт - Agentic Architecture Compliance (AAC).

Не делал rлубокий research, возможно это название уже кто-то использует, но оно пока не гуглится.

Агенты как комплаенс-контролёры:

- ИИ-агенты анализируют архитектурные решения и код на соответствие стандартам
- Принимают контекстуальные решения, которые не могут быть заложены в статичные правила GaC (Governance as Code).
- Адаптируются к новым паттернам

Против традиционного GaC:

- GaC: Жесткие, предопределенные правила, которые блокируют пайплайн при нарушении
- AAC: Интеллектуальная оценка с учетом контекста, объяснением решений и предложениями по исправлению

Преимущества агентного подхода:

- Трактовка намерений разработчиков, а не только формальных правил
- Способность к обучению на основе предыдущих решений
- Более гибкие исключения для обоснованных случаев
- Интерактивное взаимодействие с разработчиками

Вывод после беседы с одним умным собеседником: тренды у нас не рождаются — их импортируют. Российские инфлюенсеры, по большей части, репост-машины.
Так что если хочешь, чтобы что-то новое дошло до наших масс, сначала опубликуй это на Западе и желательно в тандеме с кем-то по фамилии Смит или Джонсон.

Neo4j запустила бесплатную GraphAcademy

Компания Neo4j открыла бесплатную онлайн-академию для изучения графовых баз данных.

В программе курсы для новичков и экспертов - от основ Cypher до интеграции с LLM для создания ИИ-приложений.

Особенно интересно направление по Knowledge Graphs + Generative AI - показывают как графовые базы усиливают возможности больших языковых моделей.

Включает практические задания, сертификацию и даже бесплатную футболку за прохождение тестов.

Хороший способ разобраться с графовыми базами, которые становятся все популярнее в ИИ-проектах.

#Graph #RAG #Neo4j #обучение
------
@tsingular

В продолжение к предыдущему посту: напомню, Cypher — это язык запросов к графовым базам данных, разработанный Neo4j.

В 2024 году был принят стандарт GQL (Graph Query Language) — первый "официальный язык запросов" к графовым базам, вобравший в себя множество наработок из Cypher: https://www.iso.org/standard/76120.html

Google (Spanner), TigerGraph, Neo4j и другие уже заявили о планах по поддержке GQL — полностью или частично.

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

Но сразу предупрежу — этого недостаточно. Чтобы эффективно строить графы знаний, нужно сформировать Graph thinking (его не даст LLM).

Если коротко Graph thinking — это умение:
- видеть информацию как сеть связанных сущностей,
- думать не «где лежит информация», а «как всё связано и что из чего вытекает».