Рекомендация:
Если вы интересуетесь ИИ, советую не игнорировать когнитивную науку. Это наука о том, как человек воспринимает, думает, говорит и понимает.
Без опоры на эти знания трудно всерьёз рассуждать о «мышлении» и «понимании» ИИ.
⠀
Книга «Мышление и речь» Льва Выготского — ключевая работа о том, как слово становится мыслью, а мысль — словом.
Выготский показал: мышление не возникает в голове "само по себе" — оно развивается через речь и культуру.
В будущих постах поговорим о том, как сети состояния покоя (Resting-State Neural Networks, RSNs) могут быть соотнесены с фоновым дообучением и самоадаптацией LLM.
#когнитивнаянаука #психология #Выготский #книги
Если вы интересуетесь ИИ, советую не игнорировать когнитивную науку. Это наука о том, как человек воспринимает, думает, говорит и понимает.
Без опоры на эти знания трудно всерьёз рассуждать о «мышлении» и «понимании» ИИ.
⠀
Книга «Мышление и речь» Льва Выготского — ключевая работа о том, как слово становится мыслью, а мысль — словом.
Выготский показал: мышление не возникает в голове "само по себе" — оно развивается через речь и культуру.
В будущих постах поговорим о том, как сети состояния покоя (Resting-State Neural Networks, RSNs) могут быть соотнесены с фоновым дообучением и самоадаптацией LLM.
#когнитивнаянаука #психология #Выготский #книги
👍9🔥3❤2👎1
Одна из тех статей, на которые скоро начнут опираться 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."
Продолжая мысль из предыдущего поста: без базового понимания когнитивной науки и нейронауки невозможно предсказывать развитие ИИ и понимать, какие мотивы заложены в основу архитектур.
📄 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."
Продолжая мысль из предыдущего поста: без базового понимания когнитивной науки и нейронауки невозможно предсказывать развитие ИИ и понимать, какие мотивы заложены в основу архитектур.
arXiv.org
Reasoning RAG via System 1 or System 2: A Survey on Reasoning...
Retrieval-Augmented Generation (RAG) has emerged as a powerful framework to overcome the knowledge limitations of Large Language Models (LLMs) by integrating external retrieval with language...
🔥2❤1
Reasoning RAG via System 1 or System 2.pdf
166.5 KB
Поделюсь конспектом этой статьи, где я отметил, хоть и не новые для себя, но созвучные вещи.
Ниже подчеркну отдельные моменты, которые коррелируют с контентом этого канала.
Явное упоминание фрейминга:
"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.
Ниже подчеркну отдельные моменты, которые коррелируют с контентом этого канала.
Явное упоминание фрейминга:
"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.
🔥4👍3❤2
Детальное ТЗ — новый код
Чтобы получить отдачу от LLM, одного запроса недостаточно. Нужно расписывать всё до болтов: уточнять цели, формулировать задачу, описывать контекст, ограничения, архитектурные решения, примеры и критерии успешности. Ничего не напоминает?
Иными словами, моделям нужно передать замыслы и знания.
Решение задачи теперь начинается с её описания. Чем яснее и структурированнее вы описали задачу, тем лучше результат.
В этом контексте на первый план выходит моделирование и детальное документирование: онтологии и графы знаний, спецификации, схемы.
То, что в Эждайл откладывается «на никогда», теперь становится критически важным с самого начала.
При этом всё чаще наступает разочарование в Cursor-подобных продуктах. Код пишется легко и быстро, но собрать что-то большее, чем MVP, удаётся редко — и непонятно, как это потом развивать.
На верхнем уровне резко возрастает роль бизнес- и корпоративной архитектуры: моделям нужно передавать не только инструкции, но и бизнес-контекст, знания о процессах и ИТ-ландшафте.
#документирование #ИИвбизнесе #БизнесАрхитектура #архитекторы
Чтобы получить отдачу от LLM, одного запроса недостаточно. Нужно расписывать всё до болтов: уточнять цели, формулировать задачу, описывать контекст, ограничения, архитектурные решения, примеры и критерии успешности. Ничего не напоминает?
Иными словами, моделям нужно передать замыслы и знания.
Решение задачи теперь начинается с её описания. Чем яснее и структурированнее вы описали задачу, тем лучше результат.
В этом контексте на первый план выходит моделирование и детальное документирование: онтологии и графы знаний, спецификации, схемы.
То, что в Эждайл откладывается «на никогда», теперь становится критически важным с самого начала.
При этом всё чаще наступает разочарование в Cursor-подобных продуктах. Код пишется легко и быстро, но собрать что-то большее, чем MVP, удаётся редко — и непонятно, как это потом развивать.
На верхнем уровне резко возрастает роль бизнес- и корпоративной архитектуры: моделям нужно передавать не только инструкции, но и бизнес-контекст, знания о процессах и ИТ-ландшафте.
#документирование #ИИвбизнесе #БизнесАрхитектура #архитекторы
1👍8🔥4
Самая распространённая ошибка сегодня — убеждение, которое всё чаще прослеживается в кулуарных разговорах инженеров: «бизнес» считает, что ничего структурировать и описывать не нужно — модели сами всё структурируют и придумают, они и так уже содержат все знания мира.
«Любит — не любит, плюнет — поцелует...»
Помните детскую гадалку?
«Верю - не верю»
Именно так принимаются решения о технологиях - без малейшего представления об их устройстве и применимости.
«Любит — не любит, плюнет — поцелует...»
Помните детскую гадалку?
«Верю - не верю»
Именно так принимаются решения о технологиях - без малейшего представления об их устройстве и применимости.
👍6😁3❤1❤🔥1🔥1💯1
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
Представьте, что 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
🔥9👍6❤4
Архитектура как код (Architecture as Code) — перестаёт быть результатом ручного труда.
Будущее — за генерацией архитектурных спецификаций из описаний на естественном языке с помощью ИИ-агентов. Взаимодействие будет выстроено именно с ними.
Вы описываете архитектурный замысел: компоненты, их связи и ограничения — а агент преобразует его в код.
Именно этот код — будь то описание в Structurizr DSL или другом языке описания архитектуры — и будет использоваться как детерминированная, точная спецификация для LLM. Он станет тем самым набором токенов, который увеличивает предсказуемость генерации.
Код архитектуры всё больше будет уходить «под капот», становясь служебным артефактом, а не результатом человеческого труда. И, возможно, в какой-то момент сам код, специфицирующий архитектуру, исчезнет — вместо него будет строиться граф.
По своей сути, любой код, описывающий архитектуру (AaC), уже является текстовым представлением графа. Сегодня мы используем код (текст) как способ сериализации этой графовой модели, чтобы её можно было версионировать и хранить в Git.
В какой-то момент необходимость в таком текстовом посреднике отпадёт.
ИИ-агент, получив от человека сформулированный замысел, сможет:
- Построить и верифицировать модель архитектуры напрямую в виде графовой структуры у себя в памяти, в специализированной базе данных (например, графовой БД).
- Работать с этим графом как с «источником истины» (source of truth), изменяя его на основе дальнейших инструкций.
- Появятся инструменты или расширения графовых БД для версионирования графов и сравнения версий (дифов), такая работа уже ведётся.
Текстовая спецификация в виде кода является промежуточным звеном. Будущее — это отказ и от этого звена в пользу прямого манипулирования графовой моделью системы.
А где здесь онтологии?
Без общего, формализованного словаря (онтологии) вашей компании ИИ-агент не сможет адекватно интерпретировать специфические для компании требования и другие "инструкции" на естественном языке.
Онтология создаёт семантический каркас, на основе которого строится осмысленный диалог "человек-машина" и, в конечном итоге, граф.
Будущее — за генерацией архитектурных спецификаций из описаний на естественном языке с помощью ИИ-агентов. Взаимодействие будет выстроено именно с ними.
Вы описываете архитектурный замысел: компоненты, их связи и ограничения — а агент преобразует его в код.
Именно этот код — будь то описание в Structurizr DSL или другом языке описания архитектуры — и будет использоваться как детерминированная, точная спецификация для LLM. Он станет тем самым набором токенов, который увеличивает предсказуемость генерации.
Код архитектуры всё больше будет уходить «под капот», становясь служебным артефактом, а не результатом человеческого труда. И, возможно, в какой-то момент сам код, специфицирующий архитектуру, исчезнет — вместо него будет строиться граф.
По своей сути, любой код, описывающий архитектуру (AaC), уже является текстовым представлением графа. Сегодня мы используем код (текст) как способ сериализации этой графовой модели, чтобы её можно было версионировать и хранить в Git.
В какой-то момент необходимость в таком текстовом посреднике отпадёт.
ИИ-агент, получив от человека сформулированный замысел, сможет:
- Построить и верифицировать модель архитектуры напрямую в виде графовой структуры у себя в памяти, в специализированной базе данных (например, графовой БД).
- Работать с этим графом как с «источником истины» (source of truth), изменяя его на основе дальнейших инструкций.
- Появятся инструменты или расширения графовых БД для версионирования графов и сравнения версий (дифов), такая работа уже ведётся.
Текстовая спецификация в виде кода является промежуточным звеном. Будущее — это отказ и от этого звена в пользу прямого манипулирования графовой моделью системы.
А где здесь онтологии?
Без общего, формализованного словаря (онтологии) вашей компании ИИ-агент не сможет адекватно интерпретировать специфические для компании требования и другие "инструкции" на естественном языке.
Онтология создаёт семантический каркас, на основе которого строится осмысленный диалог "человек-машина" и, в конечном итоге, граф.
🔥10❤3👍2
Forwarded from Hard&Soft Skills
На Архитектурном трёпе #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
👍4
Добавлю от себя:
"Структурируйте метаданные заранее" — ценный совет. Однако считаю, что технари слишком полагаются на метаданные и пока не говорят о семантике.
Метаданные описывают структуру, но не передают смысл.
Почему онтологии — это "общий семантический знаменатель":
- В RAG retriever работает с индексами документов — онтология может помочь семантически нормализовать их.
- В generator (LLM) онтология может служить опорой для структурирования ответа.
- Онтологии также помогают решать проблему многозначности терминов в разных доменах, что критично для точности retrieval'а.
Онтологии помогают обеспечить смысловую согласованность между этапами поиска и генерации ответов. И главное — смысловую согласованность между документами и доменами.
"Структурируйте метаданные заранее" — ценный совет. Однако считаю, что технари слишком полагаются на метаданные и пока не говорят о семантике.
Метаданные описывают структуру, но не передают смысл.
Почему онтологии — это "общий семантический знаменатель":
- В RAG retriever работает с индексами документов — онтология может помочь семантически нормализовать их.
- В generator (LLM) онтология может служить опорой для структурирования ответа.
- Онтологии также помогают решать проблему многозначности терминов в разных доменах, что критично для точности retrieval'а.
Онтологии помогают обеспечить смысловую согласованность между этапами поиска и генерации ответов. И главное — смысловую согласованность между документами и доменами.
👍2🔥1
Forwarded from LLM под капотом
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 🤗
это метод структурированного промптинга, в котором заранее заданные схемы управляют рассуждениями больших языковых моделей, явно кодируя экспертные когнитивные процессы в процессе вывода.
Да, это тот самый 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 🤗
❤3👍2🔥1🤔1
Постов до конца года будет меньше.
У меня год устроен так, что в начале года больше R и меньше D, а в конце — наоборот. В начале этого года R было много, теперь много D.
На этот раз поделюсь постами на тему, которая может показаться отвлечённой, хотя, на мой взгляд, она помогает понять, как устроено окружение, что важно при построении систем.
А теперь, собственно, пост про отрицательный отбор - Часть 1/3:
Матрица оценки офицеров фон Хаммерштейн-Экворта — это классификационная система оценки военных кадров, разработанная немецким генералом Куртом фон Хаммерштейн-Эквортом (1878-1943). Эта система стала широко известной в военной теории и менеджменте.
Матрица основана на двух критериях:
- Умственные способности (умный/глупый)
- Трудолюбие (трудолюбивый/ленивый)
Это даёт четыре типа офицеров:
1. Умный и трудолюбивый
- Подходят для штабной работы
- Хорошие исполнители сложных задач
- Надёжные заместители
2. Глупый и ленивый
- Составляют основную массу армии
- Выполняют рутинные задачи
- Не причиняют особого вреда
3. Умный и ленивый
- Лучшие кандидаты на высшие командные должности
- Способны принимать стратегические решения
- Не увязают в мелочах, видят общую картину
4. Глупый и трудолюбивый
- Самый опасный тип
- Необходимо немедленно увольнять
- Их активность в сочетании с глупостью может привести к катастрофе
Хаммерштейн считал, что именно "умные и ленивые" офицеры лучше всего подходят для высшего командования, поскольку они находят эффективные решения, не усложняя процессы излишней активностью.
Эта матрица до сих пор используется в теории менеджмента и военном деле для анализа кадрового потенциала.
У меня год устроен так, что в начале года больше R и меньше D, а в конце — наоборот. В начале этого года R было много, теперь много D.
На этот раз поделюсь постами на тему, которая может показаться отвлечённой, хотя, на мой взгляд, она помогает понять, как устроено окружение, что важно при построении систем.
А теперь, собственно, пост про отрицательный отбор - Часть 1/3:
Матрица оценки офицеров фон Хаммерштейн-Экворта — это классификационная система оценки военных кадров, разработанная немецким генералом Куртом фон Хаммерштейн-Эквортом (1878-1943). Эта система стала широко известной в военной теории и менеджменте.
Матрица основана на двух критериях:
- Умственные способности (умный/глупый)
- Трудолюбие (трудолюбивый/ленивый)
Это даёт четыре типа офицеров:
1. Умный и трудолюбивый
- Подходят для штабной работы
- Хорошие исполнители сложных задач
- Надёжные заместители
2. Глупый и ленивый
- Составляют основную массу армии
- Выполняют рутинные задачи
- Не причиняют особого вреда
3. Умный и ленивый
- Лучшие кандидаты на высшие командные должности
- Способны принимать стратегические решения
- Не увязают в мелочах, видят общую картину
4. Глупый и трудолюбивый
- Самый опасный тип
- Необходимо немедленно увольнять
- Их активность в сочетании с глупостью может привести к катастрофе
Хаммерштейн считал, что именно "умные и ленивые" офицеры лучше всего подходят для высшего командования, поскольку они находят эффективные решения, не усложняя процессы излишней активностью.
Эта матрица до сих пор используется в теории менеджмента и военном деле для анализа кадрового потенциала.
🔥9👍2
Продолжение поста про отрицательный отбор - Часть 2/3:
Матрица Хаммерштейн-Экворта в зрелых (по Адизесу) структурах перестаёт работать и начинает работать Отрицательный отобор, который доминирует в стареющих организациях.
Отрицательный отбор — это механизм, при котором система (организация, государственная структура, армия и т.п.) систематически поощряет не наиболее способных и ценных, а наиболее лояльных, управляемых и безопасных для самой системы людей. При этом более компетентные, самостоятельные и критически мыслящие сотрудники вытесняются или не допускаются к принятию решений.
Основные черты отрицательного отбора:
1. Искажение критериев оценки.
Решающее значение приобретают не профессиональные качества (компетентность, стратегическое мышление, способность брать ответственность), а признаки лояльности, показной активности и подчинённости.
2. Подмена ценности.
Умные, независимые и инициативные воспринимаются как потенциальная угроза и рассматриваются как «неудобные» или «неблагонадёжные». В то же время глупые, но исполнительные и демонстрирующие активность — воспринимаются как надёжные.
3. Иерархическая самозащита.
Руководители, опасаясь конкуренции или критики снизу, стремятся окружить себя менее способными, но покорными подчинёнными. Это создаёт замкнутый контур воспроизводства посредственности.
4. Репрессивная обратная связь.
Попытки инициировать улучшения, предложить нестандартные решения или критически осмыслить статус-кво воспринимаются как опасное поведение. Люди, демонстрирующие такие качества, исключаются, подавляются или маргинализируются.
5. Системное закрепление.
Отрицательный отбор со временем становится встроенным механизмом: система формирует такие правила игры, при которых вероятность продвижения глупого, но лояльного выше, чем умного, но самостоятельного. Это ведёт к постепенной деградации компетентности на всех уровнях.
На мой взгляд, культ показной активности разрушает зрелые корпорации: их деятельность сводится к потогонке, бесконечным презентациям и не несущим никакой пользы результатам.
От себя добавлю: организация с цветовой дифференциацией штанов — это, как правило, стареющая организация.
Матрица Хаммерштейн-Экворта в зрелых (по Адизесу) структурах перестаёт работать и начинает работать Отрицательный отобор, который доминирует в стареющих организациях.
Отрицательный отбор — это механизм, при котором система (организация, государственная структура, армия и т.п.) систематически поощряет не наиболее способных и ценных, а наиболее лояльных, управляемых и безопасных для самой системы людей. При этом более компетентные, самостоятельные и критически мыслящие сотрудники вытесняются или не допускаются к принятию решений.
Основные черты отрицательного отбора:
1. Искажение критериев оценки.
Решающее значение приобретают не профессиональные качества (компетентность, стратегическое мышление, способность брать ответственность), а признаки лояльности, показной активности и подчинённости.
2. Подмена ценности.
Умные, независимые и инициативные воспринимаются как потенциальная угроза и рассматриваются как «неудобные» или «неблагонадёжные». В то же время глупые, но исполнительные и демонстрирующие активность — воспринимаются как надёжные.
3. Иерархическая самозащита.
Руководители, опасаясь конкуренции или критики снизу, стремятся окружить себя менее способными, но покорными подчинёнными. Это создаёт замкнутый контур воспроизводства посредственности.
4. Репрессивная обратная связь.
Попытки инициировать улучшения, предложить нестандартные решения или критически осмыслить статус-кво воспринимаются как опасное поведение. Люди, демонстрирующие такие качества, исключаются, подавляются или маргинализируются.
5. Системное закрепление.
Отрицательный отбор со временем становится встроенным механизмом: система формирует такие правила игры, при которых вероятность продвижения глупого, но лояльного выше, чем умного, но самостоятельного. Это ведёт к постепенной деградации компетентности на всех уровнях.
На мой взгляд, культ показной активности разрушает зрелые корпорации: их деятельность сводится к потогонке, бесконечным презентациям и не несущим никакой пользы результатам.
От себя добавлю: организация с цветовой дифференциацией штанов — это, как правило, стареющая организация.
🔥9👍4
Продолжение поста про отрицательный отбор - Часть 3/3:
То же самое можно наблюдать и в отраслях. На конференциях часто можно услышать доклады, где рассказывается, как изначально всё было сделано неправильно, в ходе работы допущены детские ошибки, все самоотверженно устали — и в конце что-то получилось.
Это называют «кейсами», которые все так любят.
То же самое можно наблюдать и в отраслях. На конференциях часто можно услышать доклады, где рассказывается, как изначально всё было сделано неправильно, в ходе работы допущены детские ошибки, все самоотверженно устали — и в конце что-то получилось.
Это называют «кейсами», которые все так любят.
😁4💯4🤝1
Когда подчинённые приносят ТОП-менеджеру не короткую презентацию из пяти слайдов — чтобы подсветить проблему и предложить варианты решений — а из ста тридцати пяти, это обычно говорит о двух вещах: у них нет чётких идей, как решить проблему, и они пытаются компенсировать это объёмом — показать, как сильно старались и сколько сил потратили.
Что, в общем-то, позволяет их легко классифицировать.
Что, в общем-то, позволяет их легко классифицировать.
💯3👏2🔥1🤝1
ArchiMate- от версии 3.2 к ArchiMate NEXT.md
4.8 KB
ArchiMate переходит на NEXT: что важно знать
В новой версии спецификации ArchiMate происходит значимый сдвиг в сторону унификации и упрощения метамодели.
Главное — переход от традиционного разделения на “слои” (Business, Application, Technology) к доменам, включая Strategy, Motivation и Implementation and Migration.
Новая модульная структура обеспечивает гибкость, сохраняя ключевые аспекты (Behavior, Active Structure, Passive Structure, Motivation) и позволяет использовать элементы кросс-доменно, без строгой иерархии.
Ранее различавшиеся поведенческие элементы — такие как Business Process, Application Function и Technology Process — теперь объединены в четыре универсальные категории Common Domain: process, function, service и event. Это устраняет избыточность и упрощает моделирование.
Из языка исключены элементы, дублирующие базовые сущности: contract, constraint, gap, representation, implementation event, а также все виды interaction. Их заменяют специализированные формы, такие как requirement, business object, assessment, data object, artifact, material, event.
В целом ArchiMate NEXT делает язык компактнее, чище и лучше приспособленным к автоматизации.
В новой версии спецификации ArchiMate происходит значимый сдвиг в сторону унификации и упрощения метамодели.
Главное — переход от традиционного разделения на “слои” (Business, Application, Technology) к доменам, включая Strategy, Motivation и Implementation and Migration.
Новая модульная структура обеспечивает гибкость, сохраняя ключевые аспекты (Behavior, Active Structure, Passive Structure, Motivation) и позволяет использовать элементы кросс-доменно, без строгой иерархии.
Ранее различавшиеся поведенческие элементы — такие как Business Process, Application Function и Technology Process — теперь объединены в четыре универсальные категории Common Domain: process, function, service и event. Это устраняет избыточность и упрощает моделирование.
Из языка исключены элементы, дублирующие базовые сущности: contract, constraint, gap, representation, implementation event, а также все виды interaction. Их заменяют специализированные формы, такие как requirement, business object, assessment, data object, artifact, material, event.
В целом ArchiMate NEXT делает язык компактнее, чище и лучше приспособленным к автоматизации.
👍10❤1
Напомню, ArchiMate — это никакая не нотация, это язык моделирования, причём кастомизируемый, который интегрирует разные аспекты архитектуры, о которых многие разработчики и пользователи C4 даже не догадываются.
И да, визуальная нотация — это лишь часть языка моделирования.
И да, визуальная нотация — это лишь часть языка моделирования.
👍4✍2
Forwarded from LLM под капотом
А вы знаете, что пост про демку бизнес-ассистента с SGR под капотом - это самый тщательно скрываемый секрет нашего коммьюнити?
Если верить статистике Telegram, этот пост люди пересылали в личке разы чаще, чем все остальные посты, но никто не шарил этот пост публично.
Правда секретом это будет оставаться не так долго. Следующий ERC (это наш формат соревнований) точно будет про Enterprise Reasoning Challenge, где командам нужно будет построить агента или мультиагентную систему, которые смогут использовать предоставленные им API, чтобы распутывать корпоративные задачки. Все как в SGR демке, только чуть масштабнее.
Событие планируется осенью/зимой. Точные сроки зависят от того, как быстро раскачаются отделы маркетинга в TimeToAct и IBM. Тестовый прогон будет точно этой осенью.
Формат проведения будет примерно аналогичен прошлому Enterprise RAG Challenge: команды со всего мира, небольшой призовой фонд, максимально открытые исходники и публичный сравнительный анализ результативности различных архитектур.
Возможно, все вместе сможем обнаружить новые паттерны в построении агентских систем для бизнеса.
Ваш, @llm_under_hood 🤗
Если верить статистике Telegram, этот пост люди пересылали в личке разы чаще, чем все остальные посты, но никто не шарил этот пост публично.
Правда секретом это будет оставаться не так долго. Следующий ERC (это наш формат соревнований) точно будет про Enterprise Reasoning Challenge, где командам нужно будет построить агента или мультиагентную систему, которые смогут использовать предоставленные им API, чтобы распутывать корпоративные задачки. Все как в SGR демке, только чуть масштабнее.
Событие планируется осенью/зимой. Точные сроки зависят от того, как быстро раскачаются отделы маркетинга в TimeToAct и IBM. Тестовый прогон будет точно этой осенью.
Формат проведения будет примерно аналогичен прошлому Enterprise RAG Challenge: команды со всего мира, небольшой призовой фонд, максимально открытые исходники и публичный сравнительный анализ результативности различных архитектур.
Возможно, все вместе сможем обнаружить новые паттерны в построении агентских систем для бизнеса.
Ваш, @llm_under_hood 🤗
👍3✍1❤1🔥1
Автор разработал свой подход к промпт-инжинирингу, который назвал Schema-Guided Reasoning (SGR) 👆. В этом подходе он с глубоким пониманием мат части скомпилировал эффективные техники промпт-инжиниринга
Мы тестируем эти техники, интегрируем их в наши наработки и сочетаем с собственными находками. Я закоммитился написать статью по результатам.
В завершение хочу сказать, что отслеживаю посты этого автора (Rinat Abdullin) как одного из немногих, кто действительно хорошо понимает мат часть и нацелен на практические результаты.
Мы тестируем эти техники, интегрируем их в наши наработки и сочетаем с собственными находками. Я закоммитился написать статью по результатам.
В завершение хочу сказать, что отслеживаю посты этого автора (Rinat Abdullin) как одного из немногих, кто действительно хорошо понимает мат часть и нацелен на практические результаты.
👍7🔥1🤝1
Это фрагмент промпта, который задаёт роль агента:
"Вы — ИИ-Системный Аналитик высшей квалификации. Ваша задача — выступить в роли инженера требований, который преобразует хаотичный набор исходных предложений в строго структурированный и логически безупречный набор требований."
«Хаотичный набор предложений» — именно так обычно и выглядят требования, написанные в Agile-культуре.
"Вы — ИИ-Системный Аналитик высшей квалификации. Ваша задача — выступить в роли инженера требований, который преобразует хаотичный набор исходных предложений в строго структурированный и логически безупречный набор требований."
«Хаотичный набор предложений» — именно так обычно и выглядят требования, написанные в Agile-культуре.
👍5