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

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

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

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

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

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

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

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

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

В (социотехнических) 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 — это умение:
- видеть информацию как сеть связанных сущностей,
- думать не «где лежит информация», а «как всё связано и что из чего вытекает».

Как думают дети и ИИ: параллели

К вопросу о рассуждении и эмерджентных способностях моделей.

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

А что с ChatGPT и другими генеративными ИИ? Они "думают в тексте" — рассуждение происходит прямо в процессе генерации слов. Каждое следующее слово влияет на ход рассуждения, формируя поток речи в реальном времени.

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

Мысль не предшествует речи — она формируется в процессе говорения.

Ключевое различие:

Ребенок: Постепенно переходит от эгоцентрической речи к внутренней — учится "думать про себя", сохраняя при этом диалогическую структуру мышления.

ИИ: Остается на стадии "говорения вслух" и не может развить внутренний диалог, который формируется у человека через усвоение социального общения.

Парадокс:

ИИ показывает, что эгоцентрическая речь может быть гораздо более мощным инструментом мышления, чем можно было предположить. Возможно, переход к внутренней речи — не единственный путь развития мышления?
⠀
#когнитивнаянаука #ИИ #психология #Выготский

Рекомендация:

Если вы интересуетесь ИИ, советую не игнорировать когнитивную науку. Это наука о том, как человек воспринимает, думает, говорит и понимает.

Без опоры на эти знания трудно всерьёз рассуждать о «мышлении» и «понимании» ИИ.
⠀
Книга «Мышление и речь» Льва Выготского — ключевая работа о том, как слово становится мыслью, а мысль — словом.

Выготский показал: мышление не возникает в голове "само по себе" — оно развивается через речь и культуру.

В будущих постах поговорим о том, как сети состояния покоя (Resting-State Neural Networks, RSNs) могут быть соотнесены с фоновым дообучением и самоадаптацией LLM.

#когнитивнаянаука #психология #Выготский #книги

Одна из тех статей, на которые скоро начнут опираться R&D-команды: Reasoning RAG via System 1 or System 2: A Survey on Reasoning Agentic Retrieval-Augmented Generation for Industry Challenges (12.06.2025).

📄 https://arxiv.org/abs/2506.10408
💻 https://github.com/ByebyeMonica/Reasoning-Agentic-RAG

Полгода назад в дисскуссии к этому каналу мы затрагивали Систему 1 и Систему 2, и что мы видим: "Perspective of Cognitive Science - System 1 and System 2:
To further contextualize predefined and agentic reasoning within the dual-process theory of cognition—commonly referred to as System 1 and System 2 thinking...
— we can draw an analogy between these RAG paradigms and human cognitive modes."

Продолжая мысль из предыдущего поста: без базового понимания когнитивной науки и нейронауки невозможно предсказывать развитие ИИ и понимать, какие мотивы заложены в основу архитектур.

Поделюсь конспектом этой статьи, где я отметил, хоть и не новые для себя, но созвучные вещи.

Ниже подчеркну отдельные моменты, которые коррелируют с контентом этого канала.

Явное упоминание фрейминга:

"By framing these paradigms through the lens of cognitive systems we highlight the trade-off between efficiency and adaptability, and the growing capacity of agentic RAG to emulate more sophisticated, human-like problem solving."

Как раз этот компромисс мы и обсуждали в дискуссии полгода назад.

Дальнейшее направление исследований:

"Future research should focus on techniques that help agents avoid excessive or unnecessary search queries, select the most promising sources, and know when sufficient information has been gathered."

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

А какова роль онтологий, спросите вы?

Онтологии передают LLM язык вашей организации и «принуждают» её (grounding) рассуждать на вашем языке.

В этом и заключается важнейшая практическая значимость онтологий в контексте Reasoning RAG.

Детальное ТЗ — новый код

Чтобы получить отдачу от LLM, одного запроса недостаточно. Нужно расписывать всё до болтов: уточнять цели, формулировать задачу, описывать контекст, ограничения, архитектурные решения, примеры и критерии успешности. Ничего не напоминает?

Иными словами, моделям нужно передать замыслы и знания.

Решение задачи теперь начинается с её описания. Чем яснее и структурированнее вы описали задачу, тем лучше результат.

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

То, что в Эждайл откладывается «на никогда», теперь становится критически важным с самого начала.

При этом всё чаще наступает разочарование в Cursor-подобных продуктах. Код пишется легко и быстро, но собрать что-то большее, чем MVP, удаётся редко — и непонятно, как это потом развивать.

На верхнем уровне резко возрастает роль бизнес- и корпоративной архитектуры: моделям нужно передавать не только инструкции, но и бизнес-контекст, знания о процессах и ИТ-ландшафте.

#документирование #ИИвбизнесе #БизнесАрхитектура #архитекторы

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

«Любит — не любит, плюнет — поцелует...»
Помните детскую гадалку?

«Верю - не верю»
Именно так принимаются решения о технологиях - без малейшего представления об их устройстве и применимости.

Стратегия всегда разворачивается во времени

RAG — не R-A G

Представьте, что LLM — это гениальный, но изолированный мозг. Он знает всё, чему его научили, но отрезан от внешнего мира и актуальной информации. Как заставить его работать с последними, актуальными данными? Ответ — RAG (Retrieval-Augmented Generation).

Но давайте посмотрим на это глубже. Возможно, создатели концепции RAG немного поспешили с названием, сделав упор на векторизацию поиска.

RAG — на самом деле не R-A G, а R A-G

Если абстрагироваться от векторного поиска — так называемого традиционного или векторного RAG — мы увидим, что эта концепция становится гораздо шире, и её название трансформируется из Retrieval-Augmented Generation в Retrieval Augmented-Generation — с другим смысловым акцентом.

Ограниченность традиционного понимания RAG

Классический RAG сводится к схеме: "векторизация → поиск в embedding пространстве → генерация". Но современные AI-системы показывают, что это лишь частный случай более фундаментального принципа.

Реальные агенты на этапе Retrieval выходят за рамки векторного поиска:

- Обращаются к API внешних сервисов
- Выполняют SQL/GQL-запросы к базам данных
- Вызывают специализированные модели и обращаются к другим агентам
- Получают real-time данные из IoT устройств
- Интегрируются с корпоративными системами

Это именно то, что сегодня называют Advanced RAG или Agentic RAG. И это уже мейнстрим в разработке AI-систем.

R A-G как архитектурный императив

1. R (Retrieval) — Фундаментальный шаг. Без качественного получения внешней информации (Retrieval) AI-система обречена на изоляцию. Система должна уметь находить, извлекать и интегрировать информацию из множества источников, понимая не просто слова, а контекст и смысл запроса.

2. A-G (Augmented-Generation) — Генерация с усилением внешними данными. Получив информацию извне, модель (как часть AI-системы) органично интегрирует её в процесс рассуждения. Она дополняет свои базовые знания актуальными данными и усиливает (Augmented) свои рассуждения, создавая точный и контекстуальный ответ. Здесь происходит синтез внутренних знаний, контекста и внешних данных.

Пересмотр концепции RAG приводит к важным изменениям

Влияние на архитектуру:

- Системы проектируются как "открытые" по умолчанию
- Множественные источники данных становятся нормой
- Качество внешних данных — критический фактор успеха

Новые метрики:

- Не только точность генерации, но и релевантность найденной информации
- Скорость получения и качество внешних данных
- Качество синтеза внутренних знаний с внешним контекстом

Итог: Мы признаём, что взаимодействие с внешним миром — первично и неизбежно. Генерация с усилением следует за этим как естественное следствие. RAG эволюционирует из частного технического решения в фундаментальный принцип построения AI-систем.

#RAG #AI #LLM #TechExplained #AgenticAI

Архитектура как код (Architecture as Code) — перестаёт быть результатом ручного труда.

Будущее — за генерацией архитектурных спецификаций из описаний на естественном языке с помощью ИИ-агентов. Взаимодействие будет выстроено именно с ними.

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

Именно этот код — будь то описание в Structurizr DSL или другом языке описания архитектуры — и будет использоваться как детерминированная, точная спецификация для LLM. Он станет тем самым набором токенов, который увеличивает предсказуемость генерации.

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

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

В какой-то момент необходимость в таком текстовом посреднике отпадёт.

ИИ-агент, получив от человека сформулированный замысел, сможет:
- Построить и верифицировать модель архитектуры напрямую в виде графовой структуры у себя в памяти, в специализированной базе данных (например, графовой БД).
- Работать с этим графом как с «источником истины» (source of truth), изменяя его на основе дальнейших инструкций.
- Появятся инструменты или расширения графовых БД для версионирования графов и сравнения версий (дифов), такая работа уже ведётся.

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

А где здесь онтологии?

Без общего, формализованного словаря (онтологии) вашей компании ИИ-агент не сможет адекватно интерпретировать специфические для компании требования и другие "инструкции" на естественном языке.

Онтология создаёт семантический каркас, на основе которого строится осмысленный диалог "человек-машина" и, в конечном итоге, граф.

На Архитектурном трёпе #125 обсудили работу с системами Retrieval-Augmented Generation (RAG).

🎯 С чего начинать: готовые решения или своё?

Я рекомендую сначала взять готовое SaaS-решение за $100 в месяц, проверить свои гипотезы, понять, что именно вам нужно, а уже затем задумываться о собственной разработке

Советы участников по первому этапу:

🔸Быстро тестируйте идеи на готовых решениях
🔸Не усложняйте сразу — идите от простого к сложному
🔸Применяйте проверенные библиотеки (LamaIndex, LangChain)

🧩 Векторный и гибридный поиск

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

Проблемы чистого векторного поиска:

🔹Потеря семантики из-за неправильного чанкирования
🔹Снижение производительности при увеличении объёмов данных
🔹Недостаток точности при обработке сложных запросов

Рекомендуемые практики:

🔸Сочетайте векторы с дополнительными фильтрами
🔸Структурируйте метаданные заранее
🔸Используйте LLM для автоматизации создания метаданных

🗄 Проблемы хранения данных

Участники сошлись во мнении, что оптимальный подход состоит из нескольких уровней:

🔹Исходные файлы (PDF, изображения) — отдельно, например, в S3
🔹JSON-данные и промежуточные структуры — в MongoDB
🔹Финальные векторные данные — в PostgreSQL с PgVector или специализированные векторные базы

📑 Чанкирование и обработка информации

Неправильно созданные чанки резко снижают качество поиска, поэтому важно подходить к этому осмысленно и постепенно уточнять чанки

Рекомендации по чанкированию:

🔸Начинайте с базовых подходов (по абзацам)
🔸Применяйте LLM для определения границ смысловых блоков
🔸Вручную дорабатывайте чанки для сложных документов

🗃 Разные типы информации — разные архитектурные решения

🔹Простые тексты требуют минимум усилий
🔹Таблицы и формулы нуждаются в отдельной логике обработки
🔹JSON-данные и транскрибации разговоров требуют особой структуры

Каждый тип данных — это новая архитектурная задача. Всегда учитывайте, как новая информация повлияет на вашу RAG-систему

🛠 Реальные кейсы, проблемы и рекомендации

Модератор встречи Peter Hanzo поделился кейсом из практики:

Мы делали поиск агрохимикатов. Пользователь задаёт вопрос, чем лечить томаты от конкретной болезни. RAG-система на основе векторного поиска и фильтрации по метаданным из нескольких тысяч препаратов выделяет 5 подходящих

Другие практические советы от участников:

🔹Используйте реальные запросы пользователей
🔹Тестируйте RAG-системы на заранее подготовленных наборах вопросов
🔹Применяйте LLM для постобработки и улучшения результатов
🔹Не забывайте о пользователях

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

🔗А еще Peter Hanzo поделился списком полезных материалов по теме:

раздел Вступление в RAG
https://docs.llamaindex.ai/en/stable/understanding/rag/
https://github.com/mem0ai/mem0
https://github.com/memodb-io/memobase

раздел Векторный поиск
https://github.com/pgvector/pgvector
https://weaviate.io/blog/multimodal-search-in-typenoscript
https://jkatz05.com/post/postgres/hybrid-search-postgres-pgvector/

раздел Гибридный поиск
https://docs.opensearch.org/docs/latest/vector-search/ai-search/conversational-search/#step-6-use-the-pipeline-for-rag
https://aws.amazon.com/ru/blogs/big-data/amazon-opensearch-service-vector-database-capabilities-revisited/
https://github.com/meilisearch/meilisearch
https://nuclia.com/
https://github.com/infiniflow/infinity

раздел Проблемы и Хранение
https://unstract.com/
https://github.com/quivrhq/megaparse
https://github.com/docling-project/docling

раздел Готовые проекты
https://github.com/infiniflow/ragflow
https://github.com/Cinnamon/kotaemon
https://github.com/deepset-ai/haystack
https://github.com/milvus-io/milvus
https://github.com/HKUDS/LightRAG
https://github.com/oramasearch/orama
https://github.com/gusye1234/nano-graphrag
https://github.com/vanna-ai/vanna
https://github.com/trustbit/RAGathon
https://github.com/danny-avila/rag_api
https://github.com/confident-ai/deepeval

Добавлю от себя:

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

Метаданные описывают структуру, но не передают смысл.

Почему онтологии — это "общий семантический знаменатель":

- В RAG retriever работает с индексами документов — онтология может помочь семантически нормализовать их.
- В generator (LLM) онтология может служить опорой для структурирования ответа.
- Онтологии также помогают решать проблему многозначности терминов в разных доменах, что критично для точности retrieval'а.

Онтологии помогают обеспечить смысловую согласованность между этапами поиска и генерации ответов. И главное — смысловую согласованность между документами и доменами.

Иллюстрация к посту про Schema-Guided Reasoning (SGR)

Ваш, @llm_under_hood 🤗

Schema-Guided Reasoning (SGR)

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

Да, это тот самый SO CoT/Custom CoT, про который мы уже год говорим в нашем комьюнити. Только Custom Chain of Thought, несколько путает людей, а ведь паттерн позволяет паковать довольно сложные нелинейные рассуждения в один промпт.

Если более формально, то подход Schema-Guided Reasoning (SGR) позволяет управлять LLM, задавая явные сценарии рассуждений через типизированные схемы вывода. Constrained decoding вынудит модель последовательно заполнять эти схемы, а значит мы будет контроллировать не только финальную организацию информации, но и весь процесс.

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

Используя схемы (Structured Output/Constrained Decoding) вы получаете предсказуемые и контролируемые рассуждения, можете точно оценивать промежуточные результаты (evals), повышать качество и делать ход рассуждений модели - более прозрачным.

В схему можно закладывать не только онтологии (enums), но и ветвления (tagged unions in Pydantic), процедуры (nested objects), циклы (lists) и некоторые дополнительные ограничения (см иллюстрацию)

Почему это полезно:

(1) получаем более стабильные результаты при повторных вызовах, даже на разных моделях
(2) каждый шаг рассуждения становится явным и доступным для анализа.
(3) появляется возможность прямой оценки и улучшения промежуточных шагов (типизированные поля не требуют LLM-as-a-judge). А дальше - см quality is a trajectory.
(4) можно преобразовывать экспертный опыт и чеклисты в исполняемые сценарии. Сюда хорошо ложится DDD метолодогия.
(5) нередко получается прирост точности в 5-10% за счет контроля и возможности видеть цепочку рассуждений
(!) Повышается качество слабых моделей - особенно локальных (без SGR с ними работать почти невозможно)

Технология хорошо поддерживается OpenAI, Mistral, Fireworks AI и современными локальными движками для inference (например, vLLM, ollama, TensorRT). Gemini поддерживает частично.

Ваш, @llm_under_hood 🤗