Как разработчику быстро вкатиться в тему LLM? Часть 4
Часть 3
4. Автономные ИИ-агенты
Итак, промпты писать научились, обогащать контекст актуальными знаниями с помощью RAG — тоже, но кое-чего ещё не хватает. Большинство привычных ИИ-сервисов представляют собой множество модулей, каждый из которых решает какую-либо конкретную задачу, планируя решение с помощью LLM и заданных правил, и имея в распоряжении внешний инструментарий для взаимодействия со внешним миром: от поиска в сети, до генерации и выполнения кода в реальной среде. Такие модули называются ИИ-агентами. Наиболее близкой и понятной разработчикам аналогией агентов в классической разработке, пожалуй, являются микросервисы.
Вообще, есть годные курсы по ИИ-агентам от Microsoft и Hugging Face, гайд от OpenAI, и исчерпывающий AI Agents Handbook, полностью погружающие в эту (и следующую, btw) темы. Но мы же здесь говорим о быстром старте?
AI-агенты — это автономные программы, способные самостоятельно планировать и выполнять задачи на основе целей пользователя. В основе агента обычно лежит LLM, далеко не всегда мощная, которая понимает запрос и формирует решение, и при необходимости использует инструменты — внешние функции, API или базы знаний. Проще говоря, вы даёте агенту задачу — он сам решает, что делать и как, действуя в цифровой среде подобно разумному ассистенту. Всю вводную информацию, необходимую для старта, можно подчерпнуть из статьи «AI-агенты на основе LLM и мультиагентные системы».
Различают два основных типа агентов: реактивные (мгновенно реагируют на входные данные) и проактивные (могут планировать шаги для долгосрочных целей). Как правило, агент состоит из нескольких ключевых компонентов, формирующих пайплайн решения задачи: восприятие, анализ, действие, память и т.п. Типам и структуре агента, организации взаимодействия между его компонентами, вместе с их базовой реализацией, посвящена статья «Agents 101: Как создать своего первого ИИ-агента за 30 минут».
Разумеется, здесь никуда без паттернов. Аналогом GoF в мире агентов является «Agentic AI Handbook: Design Patterns», описывающая свыше сотни различных шаблонов проектирования и разработки агентов. Наиболее популярными из них являются:
Workflow паттерны:
• Prompt Chaining — последовательный разбор задачи шаг за шагом (outline → проверка → генерация);
• Routing/Handoff — выбор исполнителя (агента или модели) для подзадачи;
• параллелизация — выполнение независимых шагов одновременно.
Agentic паттерны:
• Reflection — агент оценивает и улучшает свой ответ, устраняя ошибки и уточняя детали;
• Tool Use — агент использовать внешние инструменты (API, поиск, код) в процессе;
• ReAct (Reason + Act) — итеративный цикл: рассуждение → действие → наблюдение → повтор;
• Planning — разбивка задачи, создание плана с подзадачами и последовательное выполнение;
• Multi-Agent — распределение ролей между агентами, коллективное решение сложных задач (приведен для полноты картины, этой теме будет посвящена следующая часть).
Ознакомиться с подходами к реализации этих и других популярных паттернов можно в статьях:
«AI Agents Design Patterns Explained»
«Building effective agents»
«Zero to One: Learning Agentic Patterns»
Также, стоит упомянуть класс паттернов «Schema-Guided Reasoning» (SGR), позволяющий LLM создавать структурированные, понятные и предсказуемые результаты, удобные для дальнейшей обработки компонентами агента.
В качестве примеров готовых агентов и реализуемых ими кейсов можно смело брать на изучение проекты из репозитория «500 AI Agents Projects».
Задачка на потренироваться:
Пройти воркшоп «Build Your Own Coding Agent» и доработать получившийся проект, реализовав в нём функциональность поиска секретов в коде на основе связки сигнатурного поиска и оценки энтропии строковых литералов (или любой другой понятный вам кейс кодинга).
Часть 5.
Часть 3
4. Автономные ИИ-агенты
Итак, промпты писать научились, обогащать контекст актуальными знаниями с помощью RAG — тоже, но кое-чего ещё не хватает. Большинство привычных ИИ-сервисов представляют собой множество модулей, каждый из которых решает какую-либо конкретную задачу, планируя решение с помощью LLM и заданных правил, и имея в распоряжении внешний инструментарий для взаимодействия со внешним миром: от поиска в сети, до генерации и выполнения кода в реальной среде. Такие модули называются ИИ-агентами. Наиболее близкой и понятной разработчикам аналогией агентов в классической разработке, пожалуй, являются микросервисы.
Вообще, есть годные курсы по ИИ-агентам от Microsoft и Hugging Face, гайд от OpenAI, и исчерпывающий AI Agents Handbook, полностью погружающие в эту (и следующую, btw) темы. Но мы же здесь говорим о быстром старте?
AI-агенты — это автономные программы, способные самостоятельно планировать и выполнять задачи на основе целей пользователя. В основе агента обычно лежит LLM, далеко не всегда мощная, которая понимает запрос и формирует решение, и при необходимости использует инструменты — внешние функции, API или базы знаний. Проще говоря, вы даёте агенту задачу — он сам решает, что делать и как, действуя в цифровой среде подобно разумному ассистенту. Всю вводную информацию, необходимую для старта, можно подчерпнуть из статьи «AI-агенты на основе LLM и мультиагентные системы».
Различают два основных типа агентов: реактивные (мгновенно реагируют на входные данные) и проактивные (могут планировать шаги для долгосрочных целей). Как правило, агент состоит из нескольких ключевых компонентов, формирующих пайплайн решения задачи: восприятие, анализ, действие, память и т.п. Типам и структуре агента, организации взаимодействия между его компонентами, вместе с их базовой реализацией, посвящена статья «Agents 101: Как создать своего первого ИИ-агента за 30 минут».
Разумеется, здесь никуда без паттернов. Аналогом GoF в мире агентов является «Agentic AI Handbook: Design Patterns», описывающая свыше сотни различных шаблонов проектирования и разработки агентов. Наиболее популярными из них являются:
Workflow паттерны:
• Prompt Chaining — последовательный разбор задачи шаг за шагом (outline → проверка → генерация);
• Routing/Handoff — выбор исполнителя (агента или модели) для подзадачи;
• параллелизация — выполнение независимых шагов одновременно.
Agentic паттерны:
• Reflection — агент оценивает и улучшает свой ответ, устраняя ошибки и уточняя детали;
• Tool Use — агент использовать внешние инструменты (API, поиск, код) в процессе;
• ReAct (Reason + Act) — итеративный цикл: рассуждение → действие → наблюдение → повтор;
• Planning — разбивка задачи, создание плана с подзадачами и последовательное выполнение;
• Multi-Agent — распределение ролей между агентами, коллективное решение сложных задач (приведен для полноты картины, этой теме будет посвящена следующая часть).
Ознакомиться с подходами к реализации этих и других популярных паттернов можно в статьях:
«AI Agents Design Patterns Explained»
«Building effective agents»
«Zero to One: Learning Agentic Patterns»
Также, стоит упомянуть класс паттернов «Schema-Guided Reasoning» (SGR), позволяющий LLM создавать структурированные, понятные и предсказуемые результаты, удобные для дальнейшей обработки компонентами агента.
В качестве примеров готовых агентов и реализуемых ими кейсов можно смело брать на изучение проекты из репозитория «500 AI Agents Projects».
Задачка на потренироваться:
Пройти воркшоп «Build Your Own Coding Agent» и доработать получившийся проект, реализовав в нём функциональность поиска секретов в коде на основе связки сигнатурного поиска и оценки энтропии строковых литералов (или любой другой понятный вам кейс кодинга).
Часть 5.
4🔥7👍3⚡1
🧩 Принципы и паттерны безопасной разработки: SRP
Хоть это и не вполне очевидно, но разработка безопасных приложений может (а, возможно, и должна) начинаться, отнюдь не с моделирования угроз, внедрения в код механизмов защиты, ревью безопасности, пентестов, внедрения SCA/SAST/DAST, или, тем более, чего-то, вроде хантовского «Hack Yourself First»✝️ В лучших традициях Shift Left Security, начинать стоит с базовых принципов разработки, таких, как SOLID, YAGNI, DRY, KISS, чистый код с архитектурой и т.п. Именно они позволяют заложить в архитектуру и реализацию приложения правильный фундамент, на котором будет гораздо проще и дешевле реализовывать прочие решения и этапы внедрения DevSecOps.
Начнём с принципа единственной ответственности (Single Responsibility Principle, SRP — первая буква в SOLID), утверждающему, что каждый класс или модуль должен иметь единственную ответственность (только одну причину для изменения). С точки зрения безопасности SRP способствует изолированности компонентов и чётким границам доверия в коде, что существенно облегчает последующую работу с моделью угроз. Когда компонент сконцентрирован на одной задаче, его легче проверять на уязвимости и логические ошибки. Это снижает риск скрытых багов, возникающих при смешении разных обязанностей (например, проверка прав доступа вперемешку с бизнес-логикой). Как отмечают эксперты, соблюдение SRP «ограничивает случайную эскалацию привилегий и упрощает поиск ошибок», а также уменьшает общую поверхность атаки за счёт уменьшения сложности компонентов.
Тривиальный пример: допустим, класс UserAuth одновременно проверяет пароль пользователя и создаёт сессию при входе.
Нарушение SRP может выглядеть так:
В этом коде смешаны проверки безопасности (надежность пароля) и бизнес-логика сессии. Если разработчик решит изменить логику создания сессии, есть риск ненароком ослабить или обойти шаг проверки пароля. Правильнее разделить эти обязанности на отдельные классы (например,
Забавно, что «живым» примером последствий нарушения SRP является одна из наиболее нашумевших уязвимостей в библиотеке логирования Apache Log4j 2 CVE-2021-44228, известная как Log4Shell. Логирование — это задача записи сообщений, но Log4j помимо этого выполнял ещё и роль интерпретатора/поисковика ресурсов (JNDILookup). Фактически, в библиотеку логирования «просочилась» функциональность, выходящая за рамки её единственной ответственности — она не только записывала логи, но и могла выполнять сетевые запросы и загружать код. Если бы Log4j ограничился исключительно записью логов, без вычисления каких-либо lookup-выражений, уязвимость бы не возникла. И действительно, исправление проблемы заключалось в отключении/удалении функции JNDI Lookup из Log4j.
Соблюдение SRP помогает избежать многих CWE, связанных с логическими ошибками и неправильной проверкой условий, которые трудно выявить в нагромождённом коде. Например, SRP предотвращает появление скрытых дефектов управления доступом, из разряда CWE-732, CWE-862, возникающих, когда проверка прав смешана с другими функциями и может быть пропущена.
В целом, SRP укрепляет принцип «secure by design»: мелкие простые модули легче защитить и проверить.
Хоть это и не вполне очевидно, но разработка безопасных приложений может (а, возможно, и должна) начинаться, отнюдь не с моделирования угроз, внедрения в код механизмов защиты, ревью безопасности, пентестов, внедрения SCA/SAST/DAST, или, тем более, чего-то, вроде хантовского «Hack Yourself First»
Начнём с принципа единственной ответственности (Single Responsibility Principle, SRP — первая буква в SOLID), утверждающему, что каждый класс или модуль должен иметь единственную ответственность (только одну причину для изменения). С точки зрения безопасности SRP способствует изолированности компонентов и чётким границам доверия в коде, что существенно облегчает последующую работу с моделью угроз. Когда компонент сконцентрирован на одной задаче, его легче проверять на уязвимости и логические ошибки. Это снижает риск скрытых багов, возникающих при смешении разных обязанностей (например, проверка прав доступа вперемешку с бизнес-логикой). Как отмечают эксперты, соблюдение SRP «ограничивает случайную эскалацию привилегий и упрощает поиск ошибок», а также уменьшает общую поверхность атаки за счёт уменьшения сложности компонентов.
Тривиальный пример: допустим, класс UserAuth одновременно проверяет пароль пользователя и создаёт сессию при входе.
Нарушение SRP может выглядеть так:
class UserAuth {
public Session Authenticate(string username, string password) {
// Фрагмент, работающий с новыми пользователями
if (!PasswordChecker.IsStrong(password)) {
throw new Exception("Weak password");
}
var user = userRepository.CreateUser(username, password);
return sessionManager.StartSession(user);
}
}В этом коде смешаны проверки безопасности (надежность пароля) и бизнес-логика сессии. Если разработчик решит изменить логику создания сессии, есть риск ненароком ослабить или обойти шаг проверки пароля. Правильнее разделить эти обязанности на отдельные классы (например,
PasswordChecker, UserRepository, SessionManager), а UserAuth сделать оркестратором. Тогда код станет понятнее и безопаснее: каждая часть легко проверяется и тестируется отдельно.Забавно, что «живым» примером последствий нарушения SRP является одна из наиболее нашумевших уязвимостей в библиотеке логирования Apache Log4j 2 CVE-2021-44228, известная как Log4Shell. Логирование — это задача записи сообщений, но Log4j помимо этого выполнял ещё и роль интерпретатора/поисковика ресурсов (JNDILookup). Фактически, в библиотеку логирования «просочилась» функциональность, выходящая за рамки её единственной ответственности — она не только записывала логи, но и могла выполнять сетевые запросы и загружать код. Если бы Log4j ограничился исключительно записью логов, без вычисления каких-либо lookup-выражений, уязвимость бы не возникла. И действительно, исправление проблемы заключалось в отключении/удалении функции JNDI Lookup из Log4j.
Соблюдение SRP помогает избежать многих CWE, связанных с логическими ошибками и неправильной проверкой условий, которые трудно выявить в нагромождённом коде. Например, SRP предотвращает появление скрытых дефектов управления доступом, из разряда CWE-732, CWE-862, возникающих, когда проверка прав смешана с другими функциями и может быть пропущена.
В целом, SRP укрепляет принцип «secure by design»: мелкие простые модули легче защитить и проверить.
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍7🔥3❤🔥2💯1
Эстетика ИИ-агентов: Claude Code
Последнее время появляется всё больше и больше хвалебных статей и отзывов о Claude Code. В некоторых из них его даже называют образчиком правильного подхода к разработке agentic-решений. Почему так?
Он прост, практичен, и вызывает минимум когнитивной нагрузки у своего пользователя 🤷♂️ Может и не блестяще, но весьма добротно решая при этом те задачи, под которые был разработан. Вот такой простой рецепт успешного успеха)
Не вполне уверен насчёт прям образчика разработки agentic-решений (насмотренности не хватает), но примером следования KISS, до ощутимого удовольствия в органах эстетического восприятия, Claude Code совершенно точно является. И, как по мне, вполне себе тянет на решение, из которого совершенно не зазорно заимствовать принципы и подходы при разработке собственных ИИ-агентов.
Относительно поверхностно ознакомиться с особенностями реализации Claude Code можно в статье «What makes Claude Code so damn good (and how to recreate that magic in your agent)!?» Детальнейший же (и весьма немаленький) разбор архитектуры и реализации этого агента доступен в отчете «Claude Code: An analysis». И, поверьте, там есть на что посмотреть)
Ну и, на всякий случай, вот ещё awesome-подборка материалов по Claude Code, чтобы попробовать его в деле, задействуя максимум возможностей, если вдруг ещё не.
Последнее время появляется всё больше и больше хвалебных статей и отзывов о Claude Code. В некоторых из них его даже называют образчиком правильного подхода к разработке agentic-решений. Почему так?
Он прост, практичен, и вызывает минимум когнитивной нагрузки у своего пользователя 🤷♂️ Может и не блестяще, но весьма добротно решая при этом те задачи, под которые был разработан. Вот такой простой рецепт успешного успеха)
Не вполне уверен насчёт прям образчика разработки agentic-решений (насмотренности не хватает), но примером следования KISS, до ощутимого удовольствия в органах эстетического восприятия, Claude Code совершенно точно является. И, как по мне, вполне себе тянет на решение, из которого совершенно не зазорно заимствовать принципы и подходы при разработке собственных ИИ-агентов.
Относительно поверхностно ознакомиться с особенностями реализации Claude Code можно в статье «What makes Claude Code so damn good (and how to recreate that magic in your agent)!?» Детальнейший же (и весьма немаленький) разбор архитектуры и реализации этого агента доступен в отчете «Claude Code: An analysis». И, поверьте, там есть на что посмотреть)
Ну и, на всякий случай, вот ещё awesome-подборка материалов по Claude Code, чтобы попробовать его в деле, задействуя максимум возможностей, если вдруг ещё не.
1👍5❤2🍾1🦄1
Абстрактная интерпретация и символьное выполнение: в чем разница?
Пост родился по мотивам вчерашних обсуждений ссобратьями по несчастью коллегами. Дело в том, что эти два подхода к анализу приложений здорово путают, а иногда считают одно подмножеством другого. На самом деле, все чуть сложнее)
При символьном выполнении код интерпретируется, или выполняется, в соответствии с подмножеством семантики целевого языка, заменой всех неизвестных значений (входных данных) символьными переменными и вычислением формул в модели памяти, вместо конкретных значений. Подмножеством — потому что, невычислимые и сложно-вычислимые конструкции (вроде циклов и рекурсии, инварианты которых включают символьные переменные) упрощаются различными способами, про которые в академическом мире пишут целые диссертации. В реальном же мире SAST, как правило, просто ограничиваются «прокруткой» таких конструкций фиксированное количество раз или охапкой эвристик.
Основной челлендж разработчиков SAST, работающих в парадигме символьного выполнения: приемлемая аппроксимация семантики языка и эффективное решение проблемы экспоненциального роста путей выполнения или множества значений. Короче, долго, «дорого» (в плане сложности реализации), но относительно точно.
Абстрактная интерпретация же — это размен точности на скорость, при примерно той же «стоимости». Вместо неизвестных значений берутся их приближения: «переменная
Проще пояснить на примере вычисления цикла:
Символьное выполнение (один из подходов):
– принимает число итераций за неизвестную переменную
– выводит через интерпретацию уравнение
– находит, например,
– крутит цикл k раз.
Относительно точно, но для сложных циклов всё же нужны инварианты (см. диссертацию выше), иначе анализ взорвётся по путям выполнения. На практике, в реальных приложениях, для подобного цикла — это произойдет задолго до приближения к 50-ой итерации.
Абстрактная интерпретация (интервальный домен):
– начнём с
– каждую итерацию добавляем 2:
– рост бесконечный, поэтому применяем widening («перепрыгиваем» через растущие приближения, чтобы гарантировать быстрое достижение фиксированной точки, пусть и грубым образом) и прыгаем к границе
– потом применяем narrowing (уточняем полученное приближение, чтобы вернуть часть точности, которую потеряли на шаге widening) и условие выхода из цикла уточняют результат до
Интервалы говорят: «на выходе точно
Если взять домен «чёт/нечет», анализ сохранит инвариант:
Таким образом, эти два подхода действительно принадлежат одному семейству в том смысле, что осуществляют интерпретацию кода. Но символьное выполнение полагается в большей степени на упрощение семантики языка, в то время, как абстрактная интерпретация — на упрощение семантики данных, заданное на старте интерпретации.
Но вообще, отвечая на вопрос, является ли одно подмножеством другого... если у абстрактной интерпретации отрезать все ограничения на входные данные, и основанные на них техники вычисления циклов и рекурсии, но пришить при этом упрощение семантики языка, то из дедушки возможно и получится бабушка🤷♂️
В любой непонятной ситуации, когда станет совсем скучно — заводи спор о терминологии...
Пост родился по мотивам вчерашних обсуждений с
При символьном выполнении код интерпретируется, или выполняется, в соответствии с подмножеством семантики целевого языка, заменой всех неизвестных значений (входных данных) символьными переменными и вычислением формул в модели памяти, вместо конкретных значений. Подмножеством — потому что, невычислимые и сложно-вычислимые конструкции (вроде циклов и рекурсии, инварианты которых включают символьные переменные) упрощаются различными способами, про которые в академическом мире пишут целые диссертации. В реальном же мире SAST, как правило, просто ограничиваются «прокруткой» таких конструкций фиксированное количество раз или охапкой эвристик.
Основной челлендж разработчиков SAST, работающих в парадигме символьного выполнения: приемлемая аппроксимация семантики языка и эффективное решение проблемы экспоненциального роста путей выполнения или множества значений. Короче, долго, «дорого» (в плане сложности реализации), но относительно точно.
Абстрактная интерпретация же — это размен точности на скорость, при примерно той же «стоимости». Вместо неизвестных значений берутся их приближения: «переменная
x в [0..10]», или «переменная y чётная», или (в продвинутых техниках) «переменная s определяется конечным автоматом [a-zA-Z]+». Это формирует т.н. домен интерпретации. И далее осуществляется интерпретация кода в соответствии с определенным доменом. Анализ завершается в куда более приемлемое время, и охватывает все пути, но ценой роста процента ложных срабатываний.Проще пояснить на примере вычисления цикла:
def g(x):
while x < 100:
x = x + 2
return x
Символьное выполнение (один из подходов):
– принимает число итераций за неизвестную переменную
k;– выводит через интерпретацию уравнение
x0 + 2k = 100 и ищет его решения;– находит, например,
x0 = 0, k = 50;– крутит цикл k раз.
Относительно точно, но для сложных циклов всё же нужны инварианты (см. диссертацию выше), иначе анализ взорвётся по путям выполнения. На практике, в реальных приложениях, для подобного цикла — это произойдет задолго до приближения к 50-ой итерации.
Абстрактная интерпретация (интервальный домен):
– начнём с
x ∈ [0..50];– каждую итерацию добавляем 2:
[0..52] → [0..54] → …;– рост бесконечный, поэтому применяем widening («перепрыгиваем» через растущие приближения, чтобы гарантировать быстрое достижение фиксированной точки, пусть и грубым образом) и прыгаем к границе
[0..+∞);– потом применяем narrowing (уточняем полученное приближение, чтобы вернуть часть точности, которую потеряли на шаге widening) и условие выхода из цикла уточняют результат до
[100..+∞).Интервалы говорят: «на выходе точно
x ≥ 100», но теряют информацию о чётности.Если взять домен «чёт/нечет», анализ сохранит инвариант:
x ≡ x0 (mod 2). Это уже лучше, чем только интервалы, но и дороже.Таким образом, эти два подхода действительно принадлежат одному семейству в том смысле, что осуществляют интерпретацию кода. Но символьное выполнение полагается в большей степени на упрощение семантики языка, в то время, как абстрактная интерпретация — на упрощение семантики данных, заданное на старте интерпретации.
Но вообще, отвечая на вопрос, является ли одно подмножеством другого... если у абстрактной интерпретации отрезать все ограничения на входные данные, и основанные на них техники вычисления циклов и рекурсии, но пришить при этом упрощение семантики языка, то из дедушки возможно и получится бабушка
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥9💯2🍓1
В разы быстрее, на порядок опаснее: исследование безопасности ИИ-разработки от Apiiro
На фоне растущей тенденции повсеместного и обязательного (а, в некоторых случаях, и принудительно-карательного) внедрения ИИ-решений в процессы разработки, компания Apiiro задалась вопросом о влиянии ИИ-ассистентов на безопасность кода. Исследование, к сожалению, получилось не воспроизводимое и аффилированное, поскольку сама компания является поставщиком ИИ-агентных решений AppSec.
Однако, в общую картинку почему-то хочется верить. Даже если допустить, что выводы там существенно искажены в удобную компании сторону, упоминаемая ими тенденция размена ИИ-ассистентами простых багов на более опасные и трудноуловимые архитектурные и логические уязвимости, в целом — очень похожа на правду:
Чудес не бывает. На чем LLM обучили, на том она и хороша. А в сети — тьма открытого кода с пока ещё не найденными уязвимостями этих и аналогичных им hardcase-классов 😕 С помощью ИИ-ассистентов можно получать хороший, стабильный и безопасный код. Но для этого его нужно уметь писать и без них, формулируя соответствующие требования на входе, и проводя ревью результатов на выходе. Ну, и иметь в качестве fallback'а за спиной выстроенные и работающие процессы тестирования и безопасной разработки.
И тут было бы уместно завершить пост красивой установкой, прозвучавшей в исследовании: «внедряете ИИ-кодеров, внедряйте и ИИ-аппсеков», если бы не одно но...
Несмотря на ожидаемый в конце исследования призыв «покупайте наши решения», там почему-то отсутствуют такие же красивые диаграммы, показывающие влияние предлагаемых решений на общую картину. А ведь это напрашивается в такой публикации само собой.
Видимо аргумент о «чудес не бывает» — пока ещё актуален по обе стороны баррикад🤷♂️
На фоне растущей тенденции повсеместного и обязательного (а, в некоторых случаях, и принудительно-карательного) внедрения ИИ-решений в процессы разработки, компания Apiiro задалась вопросом о влиянии ИИ-ассистентов на безопасность кода. Исследование, к сожалению, получилось не воспроизводимое и аффилированное, поскольку сама компания является поставщиком ИИ-агентных решений AppSec.
Однако, в общую картинку почему-то хочется верить. Даже если допустить, что выводы там существенно искажены в удобную компании сторону, упоминаемая ими тенденция размена ИИ-ассистентами простых багов на более опасные и трудноуловимые архитектурные и логические уязвимости, в целом — очень похожа на правду:
AI assistants are good at catching the small stuff. Our analysis shows trivial syntax errors in AI-written code dropped by 76%, and logic bugs fell by more than 60%.
But the tradeoff is dangerous: those shallow gains are offset by a surge in deep architectural flaws. Privilege escalation paths jumped 322%, and architectural design flaws spiked 153%. These are the kinds of issues scanners miss and reviewers struggle to spot – broken auth flows, insecure designs, systemic weaknesses.
Чудес не бывает. На чем LLM обучили, на том она и хороша. А в сети — тьма открытого кода с пока ещё не найденными уязвимостями этих и аналогичных им hardcase-классов 😕 С помощью ИИ-ассистентов можно получать хороший, стабильный и безопасный код. Но для этого его нужно уметь писать и без них, формулируя соответствующие требования на входе, и проводя ревью результатов на выходе. Ну, и иметь в качестве fallback'а за спиной выстроенные и работающие процессы тестирования и безопасной разработки.
И тут было бы уместно завершить пост красивой установкой, прозвучавшей в исследовании: «внедряете ИИ-кодеров, внедряйте и ИИ-аппсеков», если бы не одно но...
Несмотря на ожидаемый в конце исследования призыв «покупайте наши решения», там почему-то отсутствуют такие же красивые диаграммы, показывающие влияние предлагаемых решений на общую картину. А ведь это напрашивается в такой публикации само собой.
Видимо аргумент о «чудес не бывает» — пока ещё актуален по обе стороны баррикад
Please open Telegram to view this post
VIEW IN TELEGRAM
💯4👍3
Принял участие в подкасте DevOps Deflope. Поболтали чуть за безопасную разработку и смежные с ней темы 😍
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DevOps Deflope News
Новый выпуск — и он про безопасность!
В нём эксперт по Application Security из Positive Technologies Владимир Кочетков рассказывает:
• что будет, если вообще забить на безопасность;
• почему от уязвимостей бизнес-логики «никогда в жизни не защитит» даже самый крутой AF;
• правда ли, что хакеры теперь умнее нас из-за ИИ;
• как внедрить безопасность, чтобы тебя не возненавидели все разработчики.
Слушать →
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте
В нём эксперт по Application Security из Positive Technologies Владимир Кочетков рассказывает:
• что будет, если вообще забить на безопасность;
• почему от уязвимостей бизнес-логики «никогда в жизни не защитит» даже самый крутой AF;
• правда ли, что хакеры теперь умнее нас из-за ИИ;
• как внедрить безопасность, чтобы тебя не возненавидели все разработчики.
Слушать →
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте
5❤4👍3👌1
Forwarded from OK ML
Уязвимости в дата-репозиториях. Обзорно главное
Репозитории для анализа данных и ML - зона повышенного риска⚠️ . Быстрое прототипирование, работа с чувствительными данными и специфичные инструменты создают уникальные векторы атак.
Вот ключевые из них:
1.🤫 Секреты в коде.
Самая распространённая и критичная уязвимость. Хардкод API-ключей (например, к AWS S3, OpenAI, базам данных), токенов доступа и даже паролей прямо в Jupyter Notebook, конфигурационных файлах и скриптах. При попадании такого кода в публичный репозиторий злоумышленники получают прямой доступ к платным сервисам и данным.
Лечение
2.🧑💻 RCE через десериализацию
Библиотеки pickle и joblib - стандарты для сохранения ML-моделей в Python - небезопасны. Десериализация файла из ненадёжного источника может привести к выполению произвольного кода на машине.
Лечение
3.💻 Открытые ноутбуки
Юпитер ноутбуки, развёрнутые с настройками по умолчанию, часто остаются доступными для всех в сети (особенно в облаках). Пароли, токены и результаты запросов с конфиденциальными данными могут быть видны в интерфейсе.
Лечениеты в коде.
‘nbstripout’ аудит перед коммитом. Регулярно аудить права доступа (IAM) к S3-бакетам, базам данных и другим ресурсам. Принцип наименьших привилегий - база 🤭.
4.🙈
DoS через загрузку моделей.
Эндпоинт для загрузки моделей без проверки размера файла может быть атакован путём отправки огромного файла, что приводит к переполнению диска и отказу в обслуживании (Denial-of-Service).
Data Poisoning. Злонамеренное изменение обучающих данных для подрыва работы модели (например, добавление в выборку для классификации спама писем с определённым словом, помеченных как "не спам").
Adversarial Attacks. Специально сконструированные входные данные, предназначенные для обмана модели (например, незаметные для человека изменения в изображении, заставляющие модель видеть не то, что есть на самом деле)
Лечение
Pre-commit хуки, сканирование в CI/CD, обучение DS основам безопасности.Менеджеры секретов, безопасные форматы сериализации, инструменты для мониторинга (Evidently AI, WhyLabs).
#DataSecurity #MLSecurity #PickleRCE #SecretsManagement #DevSecOps
🔗 Полезные ссылки:
1. TruffleHog— сканер секретов
2. nbstripout — очистка ноутбуков
3. OWASP Top 10 — главные уязвимости
Репозитории для анализа данных и ML - зона повышенного риска
Вот ключевые из них:
1.
Самая распространённая и критичная уязвимость. Хардкод API-ключей (например, к AWS S3, OpenAI, базам данных), токенов доступа и даже паролей прямо в Jupyter Notebook, конфигурационных файлах и скриптах. При попадании такого кода в публичный репозиторий злоумышленники получают прямой доступ к платным сервисам и данным.
Лечение
git grep’ + ‘truffleHog’, ротация ключей, менеджер секретов.2.
Библиотеки pickle и joblib - стандарты для сохранения ML-моделей в Python - небезопасны. Десериализация файла из ненадёжного источника может привести к выполению произвольного кода на машине.
Лечение
yaml.safe_load(),3.
Юпитер ноутбуки, развёрнутые с настройками по умолчанию, часто остаются доступными для всех в сети (особенно в облаках). Пароли, токены и результаты запросов с конфиденциальными данными могут быть видны в интерфейсе.
Лечениеты в коде.
‘nbstripout’ аудит перед коммитом. Регулярно аудить права доступа (IAM) к S3-бакетам, базам данных и другим ресурсам. Принцип наименьших привилегий - база 🤭.
4.
DoS через загрузку моделей.
Эндпоинт для загрузки моделей без проверки размера файла может быть атакован путём отправки огромного файла, что приводит к переполнению диска и отказу в обслуживании (Denial-of-Service).
Data Poisoning. Злонамеренное изменение обучающих данных для подрыва работы модели (например, добавление в выборку для классификации спама писем с определённым словом, помеченных как "не спам").
Adversarial Attacks. Специально сконструированные входные данные, предназначенные для обмана модели (например, незаметные для человека изменения в изображении, заставляющие модель видеть не то, что есть на самом деле)
Лечение
Pre-commit хуки, сканирование в CI/CD, обучение DS основам безопасности.Менеджеры секретов, безопасные форматы сериализации, инструменты для мониторинга (Evidently AI, WhyLabs).
#DataSecurity #MLSecurity #PickleRCE #SecretsManagement #DevSecOps
🔗 Полезные ссылки:
1. TruffleHog— сканер секретов
2. nbstripout — очистка ноутбуков
3. OWASP Top 10 — главные уязвимости
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1
Два «питомца» для ИИ-пентеста: CAI и PentAGI
Два годных проекта на случай, если захочется поиграться с ИИ-пентестированием веб-приложений.
CAI
Открытый фреймворк, реализующий функциональность ассистента пентестера.
• Сканы, поиск уязвимостей (SQLi, XSS, LFI) и базовая эксплуатация — всё в режиме автономного агента.
• Дружит с 300+ LLM (от OpenAI до Ollama), логирует действия через Phoenix и ставит guardrails, чтобы бот не сломал сам себя.
• В CTF-замерах оказался в среднем в 11 раз быстрее человека, а на отдельных задачах — в 3600 раз.
• Уже отмечен в TryHackMe и Hack The Box: находит бреши, читает /etc/passwd, но пока далёк от идеала — цепочки атак увы ещё не особо осиливает. Кожаный мешок с соответствующей экспертизой где-то рядом всё же нужен — агент далеко не всегда безошибочен и не во всем автономен.
PentAGI
По-настоящему автономный ИИ-пентестер со встроенными тулзами и собственной «долгой памятью»
• Более 20 классических инструментов (nmap, Metasploit, sqlmap и т.п.) прямо из коробки.
• Встроенный браузер и поиск (Google, DuckDuckGo, Tavily) для разведки.
• Векторная база знаний (PostgreSQL + pgvector), чтобы помнить свои прошлые результаты и выстраивать сложные цепочки последовательных атак в рамках одного дерева.
• Отчёты и метрики в Grafana/Prometheus, всё в Docker, разворачивается относительно легко.
• Ориентирован на топовые облачные LLM и весьма прожорлив до токенов (но оно того стоит).
Подытоживая: CAI — добротный инструмент для быстрой работы по низко-висящим фруктам, в то время, как PentAGI — тяжеловес, в хорошем смысле этого слова, для поиска полноценных деревьев атак. Оба проекта в целом хорошо показывают, куда идёт автоматизация вебсека, что не может не радовать...
...или пугать, это уж как посмотреть😬
Два годных проекта на случай, если захочется поиграться с ИИ-пентестированием веб-приложений.
CAI
Открытый фреймворк, реализующий функциональность ассистента пентестера.
• Сканы, поиск уязвимостей (SQLi, XSS, LFI) и базовая эксплуатация — всё в режиме автономного агента.
• Дружит с 300+ LLM (от OpenAI до Ollama), логирует действия через Phoenix и ставит guardrails, чтобы бот не сломал сам себя.
• В CTF-замерах оказался в среднем в 11 раз быстрее человека, а на отдельных задачах — в 3600 раз.
• Уже отмечен в TryHackMe и Hack The Box: находит бреши, читает /etc/passwd, но пока далёк от идеала — цепочки атак увы ещё не особо осиливает. Кожаный мешок с соответствующей экспертизой где-то рядом всё же нужен — агент далеко не всегда безошибочен и не во всем автономен.
PentAGI
По-настоящему автономный ИИ-пентестер со встроенными тулзами и собственной «долгой памятью»
• Более 20 классических инструментов (nmap, Metasploit, sqlmap и т.п.) прямо из коробки.
• Встроенный браузер и поиск (Google, DuckDuckGo, Tavily) для разведки.
• Векторная база знаний (PostgreSQL + pgvector), чтобы помнить свои прошлые результаты и выстраивать сложные цепочки последовательных атак в рамках одного дерева.
• Отчёты и метрики в Grafana/Prometheus, всё в Docker, разворачивается относительно легко.
• Ориентирован на топовые облачные LLM и весьма прожорлив до токенов (но оно того стоит).
Подытоживая: CAI — добротный инструмент для быстрой работы по низко-висящим фруктам, в то время, как PentAGI — тяжеловес, в хорошем смысле этого слова, для поиска полноценных деревьев атак. Оба проекта в целом хорошо показывают, куда идёт автоматизация вебсека, что не может не радовать...
...или пугать, это уж как посмотреть
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4✍2🤗1
Как разработчику быстро вкатиться в тему LLM? Часть 5 (заключительная)
Часть 4
5. Мультиагентные системы и протоколы взаимодействия
Работая над нетривиальном агентом, разработчик может столкнуться с ситуацией, когда реализуемая им логика перестает укладываться в концепцию агента-соло. Например, когда разделение ролей, параллелизм, изоляция рисков или масштабируемость дают измеримую выгоду по качеству, времени или стоимости. Иногда перестает хватать контекстного окна, или промпт оказывается переусложненным из-за разнородности задач, или возникает необходимость использовать несколько различных моделей. В таких случаях переходят от одноагентных систем к мультиагентным (MAS), где каждый из агентов решает часть общей задачи. В такой системе нет единого центра – координация происходит либо за счёт прямого общения агентов, либо через некоторую общую среду. Основные концепции MAS неплохо описаны в этой статье.
Вот лишь некоторые возможные паттерны ролей агентов в MAS:
• Planner → Executors: планировщик дробит задачу, исполнители — узкоспециализированные агенты.
• Critic/Verifier: независимая проверка фактов/ограничений, «красные команды», контрафактуальная проверка.
• Tool-specialists: агенты-обёртки над конкретными инструментами (Bash, Snowflake, Jira).
• Memory/RAG-агенты: отдельный агент управление знанием (индексация, извлечение, цитирование).
О проектировании MAS неплохо написано тут.
Агентам в MAS нужно как-то взаимодействовать с окружением и друг-другом. С этой целью были созданы протоколы A2A от Google, и MCP от Anthropic. Поверхностно ознакомиться с ними поможет эта статья. Вкратце:
• MCP – представляет собой «универсальный разъём a-la USB» между LLM-агентом и внешними инструментами. Протокол вводит три роли участников: Host (основное приложение/интерфейс, где работает агент), Client (компонент-встроенный коннектор при модели) и Server (поставщик инструментов или данных). Фактически, Host координирует диалог и хранит общую память, Server предоставляет реализацию какого-то действия (например, доступ к базе знаний или вызов внешнего API), а Client-соединение позволяет модельному агенту запрашивать у Host доступные инструменты и вызывать их. За счёт этого агент может использовать произвольные инструменты через единый протокол, не требуя от разработчика писать для каждого API свой код обработки.
• A2A же — протокол «агент-агент», дополняющий MCP: если MCP фокусируется на подключении инструментов, то A2A стандартизирует коммуникацию между независимыми агентами (каждый из которых может быть отдельным сервисом). Агент в A2A публикует свой «карточку» с описанием возможностей, а другие агенты могут посылать ему задания через HTTP. В сочетании, MCP и A2A покрывают разные уровни: MCP – подключение одного агента к инструментам и контексту, A2A – связь между разными агентами.
Для начала работы с MCP неплохо также ознакомиться и с этой статьей.
Разумеется, изобретать заново архитектуры MAS и реализовывать протоколы взаимодействия особой необходимости нет — существуют специализированные фреймворки, в которых «всё уже украдено до нас». Наиболее популярным из них является CrewAI: Python-фреймворк, упрощающий создание и оркестрацию группы агентов. В нём вводятся основные сущности – Agent (автономный агент с определённой ролью и целями), Task (задача для агента), Crew (группа агентов, объединённых общей целью), Tool (внешний инструмент, которым могут пользоваться агенты). Фреймворк берёт на себя маршрутизацию задач между агентами и сбор результатов. Стартовать с ним поможет эта статья.
Более подробный обзор доступных открытых решений для разработки ИИ-агентов представлен здесь.
Задачка на потренироваться:
Доработать coding-агента из предыдущего задания, добавив к нему verifier-агента на базе другой reasoning-модели, верифицирующего полученные результаты.
———
На этом, серия постов про вкатывание в разработку для LLM подошла к концу. Но не рубрика «LLM для разработчиков». Stay tuned, как говорится☺️
Часть 4
5. Мультиагентные системы и протоколы взаимодействия
Работая над нетривиальном агентом, разработчик может столкнуться с ситуацией, когда реализуемая им логика перестает укладываться в концепцию агента-соло. Например, когда разделение ролей, параллелизм, изоляция рисков или масштабируемость дают измеримую выгоду по качеству, времени или стоимости. Иногда перестает хватать контекстного окна, или промпт оказывается переусложненным из-за разнородности задач, или возникает необходимость использовать несколько различных моделей. В таких случаях переходят от одноагентных систем к мультиагентным (MAS), где каждый из агентов решает часть общей задачи. В такой системе нет единого центра – координация происходит либо за счёт прямого общения агентов, либо через некоторую общую среду. Основные концепции MAS неплохо описаны в этой статье.
Вот лишь некоторые возможные паттерны ролей агентов в MAS:
• Planner → Executors: планировщик дробит задачу, исполнители — узкоспециализированные агенты.
• Critic/Verifier: независимая проверка фактов/ограничений, «красные команды», контрафактуальная проверка.
• Tool-specialists: агенты-обёртки над конкретными инструментами (Bash, Snowflake, Jira).
• Memory/RAG-агенты: отдельный агент управление знанием (индексация, извлечение, цитирование).
О проектировании MAS неплохо написано тут.
Агентам в MAS нужно как-то взаимодействовать с окружением и друг-другом. С этой целью были созданы протоколы A2A от Google, и MCP от Anthropic. Поверхностно ознакомиться с ними поможет эта статья. Вкратце:
• MCP – представляет собой «универсальный разъём a-la USB» между LLM-агентом и внешними инструментами. Протокол вводит три роли участников: Host (основное приложение/интерфейс, где работает агент), Client (компонент-встроенный коннектор при модели) и Server (поставщик инструментов или данных). Фактически, Host координирует диалог и хранит общую память, Server предоставляет реализацию какого-то действия (например, доступ к базе знаний или вызов внешнего API), а Client-соединение позволяет модельному агенту запрашивать у Host доступные инструменты и вызывать их. За счёт этого агент может использовать произвольные инструменты через единый протокол, не требуя от разработчика писать для каждого API свой код обработки.
• A2A же — протокол «агент-агент», дополняющий MCP: если MCP фокусируется на подключении инструментов, то A2A стандартизирует коммуникацию между независимыми агентами (каждый из которых может быть отдельным сервисом). Агент в A2A публикует свой «карточку» с описанием возможностей, а другие агенты могут посылать ему задания через HTTP. В сочетании, MCP и A2A покрывают разные уровни: MCP – подключение одного агента к инструментам и контексту, A2A – связь между разными агентами.
Для начала работы с MCP неплохо также ознакомиться и с этой статьей.
Разумеется, изобретать заново архитектуры MAS и реализовывать протоколы взаимодействия особой необходимости нет — существуют специализированные фреймворки, в которых «всё уже украдено до нас». Наиболее популярным из них является CrewAI: Python-фреймворк, упрощающий создание и оркестрацию группы агентов. В нём вводятся основные сущности – Agent (автономный агент с определённой ролью и целями), Task (задача для агента), Crew (группа агентов, объединённых общей целью), Tool (внешний инструмент, которым могут пользоваться агенты). Фреймворк берёт на себя маршрутизацию задач между агентами и сбор результатов. Стартовать с ним поможет эта статья.
Более подробный обзор доступных открытых решений для разработки ИИ-агентов представлен здесь.
Задачка на потренироваться:
Доработать coding-агента из предыдущего задания, добавив к нему verifier-агента на базе другой reasoning-модели, верифицирующего полученные результаты.
———
На этом, серия постов про вкатывание в разработку для LLM подошла к концу. Но не рубрика «LLM для разработчиков». Stay tuned, как говорится
Please open Telegram to view this post
VIEW IN TELEGRAM
5🔥7❤1
Эстетика ИИ-агентов: и снова... Claude Code
В догонку к предыдущему посту. На днях The Pragmatic Engineer опубликовали статью «How Claude Code is built», которая однозначно заслуживает внимания. Тезисно:
• От хакатона до бизнеса на $500 млн в год: идея началась как пробный скрипт в терминале, но когда модель стала сама «гулять» по импортам и читать кодовую базу, команда поняла, что это полноценный продукт — и решилась быстро вывести его наружу.
• Минимум кода вокруг модели: разработчики сознательно удаляли вспомогательную логику, чтобы ИИ сам брал на себя максимум работы. Это риск — меньше контроля и привычных «страховок», но выигрыш в скорости развития.
• Лёгкий, нестандартный стек: TypeScript + React (Ink) + Yoga для терминального UI, Bun для сборки. Решили не тянуть привычные тяжёлые фреймворки, чтобы обновления шли мгновенно.
• Рекордный темп: до 100 внутренних релизов в день, десятки прототипов за пару суток. Такую скорость поддержали «короткие циклы доверия»: фичи выпускаются рано, чтобы сразу получать фидбек, а не шлифовать месяцами.
• Дерзкий баланс свободы и безопасности: Claude Code может менять файлы и запускать команды, но каждое действие требует подтверждения. Разработчики сознательно дали модели широкие полномочия — с минимальным, но чётким контролем пользователя.
• Sub-agents за 3 дня: идею «агентов внутри агента» оформили в продакшн после двух провальных попыток — показав, что команда готова быстро рисковать и отбрасывать неудачные решения.
В деталях:
В догонку к предыдущему посту. На днях The Pragmatic Engineer опубликовали статью «How Claude Code is built», которая однозначно заслуживает внимания. Тезисно:
• От хакатона до бизнеса на $500 млн в год: идея началась как пробный скрипт в терминале, но когда модель стала сама «гулять» по импортам и читать кодовую базу, команда поняла, что это полноценный продукт — и решилась быстро вывести его наружу.
• Минимум кода вокруг модели: разработчики сознательно удаляли вспомогательную логику, чтобы ИИ сам брал на себя максимум работы. Это риск — меньше контроля и привычных «страховок», но выигрыш в скорости развития.
• Лёгкий, нестандартный стек: TypeScript + React (Ink) + Yoga для терминального UI, Bun для сборки. Решили не тянуть привычные тяжёлые фреймворки, чтобы обновления шли мгновенно.
• Рекордный темп: до 100 внутренних релизов в день, десятки прототипов за пару суток. Такую скорость поддержали «короткие циклы доверия»: фичи выпускаются рано, чтобы сразу получать фидбек, а не шлифовать месяцами.
• Дерзкий баланс свободы и безопасности: Claude Code может менять файлы и запускать команды, но каждое действие требует подтверждения. Разработчики сознательно дали модели широкие полномочия — с минимальным, но чётким контролем пользователя.
• Sub-agents за 3 дня: идею «агентов внутри агента» оформили в продакшн после двух провальных попыток — показав, что команда готова быстро рисковать и отбрасывать неудачные решения.
В деталях:
Pragmaticengineer
How Claude Code is built
A rare look into how the new, popular dev tool is built, and what it might mean for the future of software building with AI. Exclusive.
2❤4🔥2👍1
SymbolicAI — правильный подход к нейросимвольному программированию.
Среди постоянно льющегося буллшита вокруг нейросимвольных технологий (которыми сейчас стали называть любые системы, в которых формальные методы выступают верификаторами ИИ-шных и наоборот) затерялась недооцененная жемчужина, здорово упрощающая жизнь ресерчерам и разработчикам ИИ-систем.
SymbolicAI – это нейросимвольный фреймворк на Python, который позволяет объединить классическое программирование, возможности LLM, символьных решателей и множество вспомогательных средств. Он построен так, чтобы его пользователь не задумывался о вопросах интеграции и мог сосредоточиться на логике разрабатываемого им решения.
Символы (Symbol) – это базовые объекты данных, которым можно задавать операции как обычным Python-методам, а при необходимости переключаться в семантический режим для логических или лингвистических вычислений.
Возможности
• Универсальные операции. Символы поддерживают перегруженные операторы: == для «приближённого» равенства, + для смыслового объединения и & для логического вывода. Все операции можно комбинировать в цепочки на одном объекте, чередуя «синтаксический» и «семантический» режимы. Фреймворк умеет переводить тексты, отвечать на запросы и выполнять обычные функции.
Например, перевод:
или лингвистические аналогии:
• Контракты и проверка. Для надежности разработчики ввели механизм контрактов (Design by Contract, DbC) – позволяющий описывать входные/выходные модели и автоматически проверять или корректировать результаты LLM.
• Интеграция с сервисами. SymbolicAI умеет работать не только с LLM, но и с WolframAlpha, OCR, поиском в интернете и мультимодальными источниками: изображениями, речью и т.п. Это позволяет использовать фреймворк для самых разных задач: от анализа текста и генерации вывода до поиска фактов и работы с данными.
Ещё примеры
Семантическая замена:
Использование вызова инструментов:
Использование контрактов:
Ещё больше примеров есть в документации.
Кмк, классный инструмент для, как минимум, экспериментов ресерчеров в Jupyter-like ноутбуках (примеры). А продуманные средства DbC как бы намекают на пригодность использования и в серьезных продакшн-системах.
Must have, короче.
Среди постоянно льющегося буллшита вокруг нейросимвольных технологий (которыми сейчас стали называть любые системы, в которых формальные методы выступают верификаторами ИИ-шных и наоборот) затерялась недооцененная жемчужина, здорово упрощающая жизнь ресерчерам и разработчикам ИИ-систем.
SymbolicAI – это нейросимвольный фреймворк на Python, который позволяет объединить классическое программирование, возможности LLM, символьных решателей и множество вспомогательных средств. Он построен так, чтобы его пользователь не задумывался о вопросах интеграции и мог сосредоточиться на логике разрабатываемого им решения.
Символы (Symbol) – это базовые объекты данных, которым можно задавать операции как обычным Python-методам, а при необходимости переключаться в семантический режим для логических или лингвистических вычислений.
from symai import Symbol
S = Symbol("Cats are adorable", semantic=True)
print("feline" in S) # True — семантическая проверка «относится ли 'feline' к S»
Возможности
• Универсальные операции. Символы поддерживают перегруженные операторы: == для «приближённого» равенства, + для смыслового объединения и & для логического вывода. Все операции можно комбинировать в цепочки на одном объекте, чередуя «синтаксический» и «семантический» режимы. Фреймворк умеет переводить тексты, отвечать на запросы и выполнять обычные функции.
Например, перевод:
from symai import Symbol
S = Symbol("Welcome to our tutorial")
print(S.translate('Russian')) # «Добро пожаловать на наш урок!»
или лингвистические аналогии:
S = Symbol("King - Man + Woman").interpret()
print(S) # “Queen”• Контракты и проверка. Для надежности разработчики ввели механизм контрактов (Design by Contract, DbC) – позволяющий описывать входные/выходные модели и автоматически проверять или корректировать результаты LLM.
• Интеграция с сервисами. SymbolicAI умеет работать не только с LLM, но и с WolframAlpha, OCR, поиском в интернете и мультимодальными источниками: изображениями, речью и т.п. Это позволяет использовать фреймворк для самых разных задач: от анализа текста и генерации вывода до поиска фактов и работы с данными.
Ещё примеры
Семантическая замена:
from symai import Symbol
items = Symbol(['apple', 'banana', 'cherry', 'cat'])
print(items.map('replace fruits with vegetables'))
# -> ['carrot', 'broccoli', 'spinach', 'cat']
Использование вызова инструментов:
from symai.components import Function
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"denoscription": "Get current temperature for a location.",
"parameters": {
"type": "object",
"properties": {
"location": {"type": "string"}
},
"required": ["location"]
}
}
}]
fn = Function(
"Choose and call the appropriate function",
tools=tools
)
# GPT-style tool call
resp = fn("What's the temperature in Bogotá, Colombia?", raw_output=True)
# resp.choices[0].finish_reason == "tool_calls"
# resp.choices[0].message.tool_calls[0].function.name == "get_weather"
Использование контрактов:
from symai import Expression
from symai.strategy import contract
from symai.models import LLMDataModel
from typing import Optional, List # For type hints in examples
# Default retry parameters used if not overridden in the decorator call
DEFAULT_RETRY_PARAMS = {
"tries": 5, "delay": 0.5, "max_delay": 15,
"jitter": 0.1, "backoff": 2, "graceful": False
}
@contract(
pre_remedy: bool = False,
post_remedy: bool = True,
accumulate_errors: bool = False,
verbose: bool = False,
remedy_retry_params: dict = DEFAULT_RETRY_PARAMS # Uses defined defaults
)
class MyContractedClass(Expression):
# ... class implementation ...
pass
Ещё больше примеров есть в документации.
Кмк, классный инструмент для, как минимум, экспериментов ресерчеров в Jupyter-like ноутбуках (примеры). А продуманные средства DbC как бы намекают на пригодность использования и в серьезных продакшн-системах.
Must have, короче.
1🔥3
Forwarded from OK ML
Awesome AI Apps - технический гид по созданию LLM-приложений
🦙 Репозиторий awesome-ai-apps - коллекция продакшен-примеров для построения приложений на базе LLM. Внутри — проекты на LangChain, LlamaIndex + habr, CrewAI, Agno, Mastra, Nebius AI Studio, GibsonAI и много других полезных!..
Что можно найти:
- минимальные прототипы на базе OpenAI SDK, LangGraph, Camel AI — идеальны для экспериментов,
- готовые сценарии вроде финансового трекера, HITL-агента или бот для веб-автоматизации,
- демонстрации работы с Model Context Protocol (MCP) для репозиториев, документов или бд. Это особенно актуально для стандартизации, взаимодействия между агентами и внешними сервисами. Ну и тем, кто оттягивает знакомство с MCP, еть уже готовые анализ GitHub-репо, QnA по документации, работа с Couchbase и GibsonAI DB. Не оттягивайте🤪 .
- агенты с persistent memory (на Memori), которые позволяют строить более контекстно-зависимые системы (например, arXiv Researcher или Social Media Agent).
- примеры Agentic RAG (они не устарели!!!) с использованием Qdrant, Exa, LlamaIndex. Поддержка работы с PDF, кодом и OCR (Gemma3).
- комплексные пайплайны (например, Meeting Assistant, который конвертирует митинг в задачи и заметки, или Finance Service Agent на FastAPI)
Что под капотом (продублируем для удобства твоего гугл эдвэнсед, большинство ссылок выше) и ждет, когда затащишь себе?
🫰 LangChain + LangGraph для оркестрации агентов.
🫰 Agno как фреймворк для построения agentic workflows.
🫰 CrewAI для мультиагентных исследований.
🫰 LlamaIndex как основа RAG и документных ассистентов.
🫰 Memori для хранения контекста и долгосрочной памяти.
🫰 Nebius AI и Bright Data — как инфраструктурные провайдеры.
Установка (единый паттерн):
🧘♀️ Каждый проект снабжен своим README.md, а там можно и сразу стартовать.
Этот репозиторий можно в чистом виде 🏖️ R&D-песочница, быстро тестировать разные стеки, паттерны взаимодействия агентов, интеграции MCP и реализацию RAG. Гении, как известно, воруют 👌
#AI #LLM #RAG #LangChain #LlamaIndex #CrewAI #Agno #Memori #AIagents #opensource #MCP #Python #MachineLearning #GenerativeAI
🦙 Репозиторий awesome-ai-apps - коллекция продакшен-примеров для построения приложений на базе LLM. Внутри — проекты на LangChain, LlamaIndex + habr, CrewAI, Agno, Mastra, Nebius AI Studio, GibsonAI и много других полезных!..
Что можно найти:
- минимальные прототипы на базе OpenAI SDK, LangGraph, Camel AI — идеальны для экспериментов,
- готовые сценарии вроде финансового трекера, HITL-агента или бот для веб-автоматизации,
- демонстрации работы с Model Context Protocol (MCP) для репозиториев, документов или бд. Это особенно актуально для стандартизации, взаимодействия между агентами и внешними сервисами. Ну и тем, кто оттягивает знакомство с MCP, еть уже готовые анализ GitHub-репо, QnA по документации, работа с Couchbase и GibsonAI DB. Не оттягивайте
- агенты с persistent memory (на Memori), которые позволяют строить более контекстно-зависимые системы (например, arXiv Researcher или Social Media Agent).
- примеры Agentic RAG (они не устарели!!!) с использованием Qdrant, Exa, LlamaIndex. Поддержка работы с PDF, кодом и OCR (Gemma3).
- комплексные пайплайны (например, Meeting Assistant, который конвертирует митинг в задачи и заметки, или Finance Service Agent на FastAPI)
Что под капотом (продублируем для удобства твоего гугл эдвэнсед, большинство ссылок выше) и ждет, когда затащишь себе?
Установка (единый паттерн):
git clone https://github.com/Arindam200/awesome-ai-apps.git
cd awesome-ai-apps/<project_name>
pip install -r requirements.txt
Этот репозиторий можно в чистом виде 🏖️ R&D-песочница, быстро тестировать разные стеки, паттерны взаимодействия агентов, интеграции MCP и реализацию RAG. Гении, как известно, воруют 👌
#AI #LLM #RAG #LangChain #LlamaIndex #CrewAI #Agno #Memori #AIagents #opensource #MCP #Python #MachineLearning #GenerativeAI
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍4
Новый взгляд на «контекст» в ИИ: от prompt engineering к context engineering
Команда Anthropic опубликовала статью «Effective Context Engineering for AI Agents», где утверждает, что в эпоху агентных систем привычное «написать правильный prompt» постепенно уступает место более широкому подходу — контекст-инженерии. Контекст — не просто текст промпта, а весь набор токенов, который модель «видит» в момент вывода.
Авторы показывают, что по мере роста размеров контекста модели начинают терять фокус: не вся информация доходит до «внимания». В этом смысле контекст — ограниченный ресурс, и важно тщательно отбирать «высокосигнальные» куски данных.
Что составляет контекст-инженерию на практике?
• Отказ от перегруженных инструкций и «жёстких» шаблонов в пользу сбалансированных, гибких указаний.
• Динамическое подключение данных по принципу «just in time»: агент подгружает нужные фрагменты контекста в момент, когда они действительно важны.
• Техники для задач с большой временной протяженностью: сжатие истории (основные факты сохраняются, лишнее — убирается), записи-заметки вне контекста, или распределённые структуры с субагентами.
По мнению авторов, context engineering — это не просто тренд, а фундаментальный сдвиг в проектировании ИИ-агентов. Даже по мере роста возможностей моделей, бережное управление вниманием остаётся ключом к стабильному и надёжному поведению.
Команда Anthropic опубликовала статью «Effective Context Engineering for AI Agents», где утверждает, что в эпоху агентных систем привычное «написать правильный prompt» постепенно уступает место более широкому подходу — контекст-инженерии. Контекст — не просто текст промпта, а весь набор токенов, который модель «видит» в момент вывода.
Авторы показывают, что по мере роста размеров контекста модели начинают терять фокус: не вся информация доходит до «внимания». В этом смысле контекст — ограниченный ресурс, и важно тщательно отбирать «высокосигнальные» куски данных.
Что составляет контекст-инженерию на практике?
• Отказ от перегруженных инструкций и «жёстких» шаблонов в пользу сбалансированных, гибких указаний.
• Динамическое подключение данных по принципу «just in time»: агент подгружает нужные фрагменты контекста в момент, когда они действительно важны.
• Техники для задач с большой временной протяженностью: сжатие истории (основные факты сохраняются, лишнее — убирается), записи-заметки вне контекста, или распределённые структуры с субагентами.
По мнению авторов, context engineering — это не просто тренд, а фундаментальный сдвиг в проектировании ИИ-агентов. Даже по мере роста возможностей моделей, бережное управление вниманием остаётся ключом к стабильному и надёжному поведению.
1👍2💯1
О t-строках в Python 3.14
В юбилейной π-версии Python реализован новый подход к обработке строк, описанный в PEP-750, и уже вызвавший неоднозначную реакцию в сети. По сути, шаблонные строковые литералы, или t-строки (
Например,
На самом деле — очень здравая языковая фича, позволяющая строить эффективную обработку выходных данных за счет:
• Чёткого разделения данных и шаблона, позволяющих (при желании и умении) учитывать грамматический контекст, формат-спецификаторы/конверсии и т.п.
• Запрета «тихой» конкатенации со строками (сложение
• Явного рендера за счет отсутствия
• Композиционности. Обработчики не обязательно должны возвращать строки, что позволяет объединять их в цепочки. Можно вкладывать шаблоны и обрабатывать по уровням контекста (например, атрибуты HTML как dict → безопасная строка атрибутов).
В psycopg, например, уже подсуетились и реализовали параметризацию SQL-запросов через t-строки в текущем dev своей библиотеки. Их обработчик можно подсмотреть в _trstrings.py.
Пример простого обработчика, санитизирующего данные в контексте HTML/Text:
Однако, как и говорится в описании изменений, t-строки — это лишь механизм обработки строк, а не панацея от инъекций, неправильное использование которого позволит прострелить себе конечность не менее лихо, чем в случае с f-строками:
• Эффективность санитизации интерполяций — целиком зависит от правильного выбора или написания их обработчиков.
• Все выражения внутри блоков
• Конкатенация
• Формат-спецификаторы внутри
• Валидацию входных данных в соответствии с бизнес-логикой этот механизм не заменяет, и относится лишь ко второму эшелону эффективной обработки данных.
В общем, механизм годный, использовать стоит, но «думать всё равно придётся» (с) 😊
В юбилейной π-версии Python реализован новый подход к обработке строк, описанный в PEP-750, и уже вызвавший неоднозначную реакцию в сети. По сути, шаблонные строковые литералы, или t-строки (
t"…") — литералы, которые выглядят как f-строки, но не вычисляются сразу же в str. Вместо этого они возвращают объект Template с раздельным доступом к статичной части и вставкам в неё. Это даёт библиотекам шанс корректно экранировать/параметризовать значения под конкретный контекст (SQL, HTML, shell и т.д.) и, якобы, тем самым снизить риск инъекций.Например,
t"Hello {name}" создаёт string.templatelib.Template, в котором доступны части строки и интерполяции, как объекты Interpolation(value, expression, conversion, format_spec). У Template нет __str__, поэтому его невозможно «случайно» напечатать как готовую строку — нужно явно вызвать обработчик (например, html(template) или sql(template), в соответствии с грамматикой принимающей стороны).На самом деле — очень здравая языковая фича, позволяющая строить эффективную обработку выходных данных за счет:
• Чёткого разделения данных и шаблона, позволяющих (при желании и умении) учитывать грамматический контекст, формат-спецификаторы/конверсии и т.п.
• Запрета «тихой» конкатенации со строками (сложение
Template + str запрещено, разрешено только Template + Template.• Явного рендера за счет отсутствия
__str__, заставляющего разработчика осознанно походить к выбору обработчиков.• Композиционности. Обработчики не обязательно должны возвращать строки, что позволяет объединять их в цепочки. Можно вкладывать шаблоны и обрабатывать по уровням контекста (например, атрибуты HTML как dict → безопасная строка атрибутов).
В psycopg, например, уже подсуетились и реализовали параметризацию SQL-запросов через t-строки в текущем dev своей библиотеки. Их обработчик можно подсмотреть в _trstrings.py.
Пример простого обработчика, санитизирующего данные в контексте HTML/Text:
from html import escape
from string.templatelib import Template, Interpolation
def html(tmpl: Template) -> str:
out = []
for part in tmpl:
if isinstance(part, Interpolation):
out.append(escape(str(part.value)))
else:
out.append(part)
return "".join(out)
evil = "<noscript>alert(1)</noscript>"
assert html(t"<p>{evil}</p>") == "<p><noscript>alert(1)</noscript></p>"
Однако, как и говорится в описании изменений, t-строки — это лишь механизм обработки строк, а не панацея от инъекций, неправильное использование которого позволит прострелить себе конечность не менее лихо, чем в случае с f-строками:
• Эффективность санитизации интерполяций — целиком зависит от правильного выбора или написания их обработчиков.
• Все выражения внутри блоков
{…} вычисляются сразу же в лексическом скоупе, интерполяцией же становится результат этого вычисления. Поэтому t"{eval(request.get['a'])}" — это всё ещё RCE, вне зависимости от обработчиков. Похожая история — и с попаданием в Template или Interpolation входных данных при создании объектов этих классов из конструкторов (вообще, стоит этого по-возможности избегать, и пользоваться предложенным синтаксическим сахаром t"…").• Конкатенация
Template + Template разрешена. Это удобно, но может породить «вирусность» шаблонов и неочевидную логику сборки, если смешивать части, ожидающие разных политик экранирования.• Формат-спецификаторы внутри
{…} вычисляются до format_spec, что может привести к потере грамматического контекста, когда придёт время обработчика.• Валидацию входных данных в соответствии с бизнес-логикой этот механизм не заменяет, и относится лишь ко второму эшелону эффективной обработки данных.
В общем, механизм годный, использовать стоит, но «думать всё равно придётся» (с) 😊
1❤2🔥2
🧩 Принципы и паттерны безопасной разработки: OCP и fail-closed
(Open/Closed Principle) — классы и функции открыты для расширения, но закрыты для модификации. Говоря проще: проектируем приложение так, чтобы для новых фичей требовались минимальные изменения в уже существующем (протестированном и стабильном, ну... как правило) коде.
С точки зрения безопасности, это снижает риски сломать уже существующие защитные меры и получить на ровном месте регрессии вроде:
• CWE-840 — логическая уязвимость из-за изменения условий
• CWE-489 — ослабление проверки при модификации кода
... и охапки прочих, на правах их прямых последствий.
🐛 Жизненное
В Apache HTTPD (CVE-2021-41773) разработчики изменили ядро обработки путей — и открыли обход директорий
Та же история с Dirty Pipe (CVE-2022-0847) в Linux: неаккуратная «оптимизация» существующего кода pipe нарушила старые гарантии → повышение локальных привилегий.
💡 Пример: PEP-750, t-строки и шаблоны
По мотивам предыдущего поста:
Плохой пример:
Новый формат → новая ветка → новый риск сломать там что-то ранее работавшее (вспоминаем goto fail;).
Хороший пример:
Ядро неизменно — добавляем только новые обработчики, неизвестные спецификации блокируются (fail-closed*): безопаснее, предсказуемее, тестируется в разы проще.
⚠️ OCP — не догма
«Модификация» в OCP не про рефакторинг, баги или уязвимости. Если в существующем коде нашли нашли проблему, то нужно править. Безопасность и здравый смысл приоритетнее. OCP всё же — не тотальный запрет на изменения, а гигиена расширяемости: добавление фичей, без изменения того, что уже защищено и протестировано.
TL;DR:
• Стоит разумно следовать OCP, чтобы не сломать защиту, добавляя фичи.
• Расширять, а не модифицировать, если речь не идёт о рефакторинге, багах или уязвимостях.
• Из-за нарушений OCP «увидели свет» многие, в том числе именитые, CVE.
(Open/Closed Principle) — классы и функции открыты для расширения, но закрыты для модификации. Говоря проще: проектируем приложение так, чтобы для новых фичей требовались минимальные изменения в уже существующем (протестированном и стабильном, ну... как правило) коде.
С точки зрения безопасности, это снижает риски сломать уже существующие защитные меры и получить на ровном месте регрессии вроде:
• CWE-840 — логическая уязвимость из-за изменения условий
• CWE-489 — ослабление проверки при модификации кода
... и охапки прочих, на правах их прямых последствий.
🐛 Жизненное
В Apache HTTPD (CVE-2021-41773) разработчики изменили ядро обработки путей — и открыли обход директорий
../. Если бы новую логику добавили отдельным модулем, а не правили существующую, старая проверка осталась бы нетронутой.Та же история с Dirty Pipe (CVE-2022-0847) в Linux: неаккуратная «оптимизация» существующего кода pipe нарушила старые гарантии → повышение локальных привилегий.
💡 Пример: PEP-750, t-строки и шаблоны
По мотивам предыдущего поста:
t"..." создаёт объект Template, а его части (Interpolation) форматируются по format_spec. Здесь напрашивается типичная ошибка — дописывать в обработчике if/elif для новых форматов (HTML, SQL, shell). Каждый раз приходится лезть в уже написанный код, и, тем самым, нарушать OCP.Плохой пример:
def render(t):
for part in t:
if spec == "html":
out.append(html_escape(v))
elif spec == "sql":
out.append(sql_param(v))
else:
out.append(format(v))
Новый формат → новая ветка → новый риск сломать там что-то ранее работавшее (вспоминаем goto fail;).
Хороший пример:
_handlers = []
def register(h): _handlers.append(h); return h
def render(t):
for it in t:
if isinstance(it, str): yield it
elif h := next((h for h in _handlers if h.supports(it)), None):
yield h.apply(it)
else:
raise ValueError(f"Unsupported spec: {it.format_spec}")
@register
class HtmlHandler:
def supports(self, it): return it.format_spec.startswith("html")
def apply(self, it): return html_escape(str(it.value))
Ядро неизменно — добавляем только новые обработчики, неизвестные спецификации блокируются (fail-closed*): безопаснее, предсказуемее, тестируется в разы проще.
*️⃣ Fail-closed (безопасный отказ) — принцип проектирования, при котором система в случае ошибки или неопределённости выбирает безопасное поведение, даже если это мешает работе.
Примеры:
• парсер не знает формат входных данных → отклоняет запрос;
• фильтр не смог проверить токен → доступ запрещён;
• обработчик t-строк встретил неизвестный `format_spec` → бросает исключение вместо неэкранированного вывода.
Такой подход предотвращает «тихие» обходы проверок и делает поведение системы предсказуемым даже при сбоях.
⚠️ OCP — не догма
«Модификация» в OCP не про рефакторинг, баги или уязвимости. Если в существующем коде нашли нашли проблему, то нужно править. Безопасность и здравый смысл приоритетнее. OCP всё же — не тотальный запрет на изменения, а гигиена расширяемости: добавление фичей, без изменения того, что уже защищено и протестировано.
TL;DR:
• Стоит разумно следовать OCP, чтобы не сломать защиту, добавляя фичи.
• Расширять, а не модифицировать, если речь не идёт о рефакторинге, багах или уязвимостях.
• Из-за нарушений OCP «увидели свет» многие, в том числе именитые, CVE.
5👍6❤2🔥2💯1
AppSec.png
752.6 KB
Давно хотел поделиться этой диаграммой. Впервые появившись в серии публикаций «Six Pillars of DevSecOps», она прошла некоторые эволюционные этапы, один из которых присутствует у вашего покорного слуги в офисе, в качестве подаренного коллегами на ДР визуала на пол стены 🎨
Комментировать тут особо нечего. Идеальный Secure SDLC, к которому надо стремиться. Хотя, тут ещё есть что добавить, как минимум — в плане защиты от supply-chain атак, как по мне.
Каждому этапу разработки сопоставлены триггеры. Каждому триггеру — соответствующие действия или инструментарий, обеспечивающие безопасность на данном этапе.
Простая и наглядная иллюстрация, которая будет постоянно напоминать о том, почему у вас в проекте все плохо с безопасностью 😁
Комментировать тут особо нечего. Идеальный Secure SDLC, к которому надо стремиться. Хотя, тут ещё есть что добавить, как минимум — в плане защиты от supply-chain атак, как по мне.
Каждому этапу разработки сопоставлены триггеры. Каждому триггеру — соответствующие действия или инструментарий, обеспечивающие безопасность на данном этапе.
Простая и наглядная иллюстрация, которая будет постоянно напоминать о том, почему у вас в проекте все плохо с безопасностью 😁
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥3👍1
UTCP: новая альтернатива MCP
Универсальный протокол вызова инструментов (Universal Tool Calling Protocol, UTCP) представляет собой смену парадигмы взаимодействия ИИ-агентов с внешними инструментами и сервисами. В отличие от традиционных подходов, требующих серверов-обёрток и прокси-слоёв, UTCP обеспечивает прямое взаимодействие между агентами ИИ и инструментами через их собственные эндпоинты.
Сегодня, чтобы подключить ИИ к внешним инструментам, разработчики вынуждены писать обёртки: агент → MCP-сервер → инструмент, и неизбежно сталкиваются с:
• лишними задержками и точками отказа;
• дублированием безопасности;
• необходимости в инфраструктуре ради вторичного посредника.
UTCP убирает необходимость в такой прослойке. В целом, сравнение UTCP и MCP можно свести к следующему: UTCP — это «мануал» (описание инструмента), а MCP — «посредник» (сервер, оборачивающий инструмент). UTCP предполагает архитектуру прямого взаимодействия «агент → инструмент», тогда как MCP — «агент → MCP-сервер → инструмент».
Отсюда вытекают и все преимущества UTCP:
• Инфраструктура: UTCP не требует новых сервисов (достаточно добавить endpoint в существующий API), MCP же нуждается в отдельном сервере(-ах) для каждого набора инструментов.
• Производительность: UTCP выполняет вызов за один шаг (агент сразу обращается к API инструмента), MCP добавляет “двойной прыжок” через посредника, увеличивая накладные задержки.
• Безопасность: UTCP использует нативную аутентификацию/авторизацию инструмента, MCP вынужден реализовывать и хранить учетные данные на своей стороне, что расширяет поверхность атаки.
• Поддержка протоколов: UTCP гибок (HTTP, WebSocket, CLI, gRPC и т.д. – вплоть до чтения локальных файлов), а MCP ограничен форматом JSON-RPC поверх единственного транспорта.
• Поддержка и масштабирование: UTCP-интеграции практически не требуют поддержки (статический JSON с описанием), масштабируются вместе с существующим сервисом; MCP-серверы же добавляют постоянные заботы (деплой, обновления, мониторинг, масштабирование отдельно от основного API).
Иначе говоря, UTCP выигрывает в простоте, скорости и универсальности, тогда как MCP может дать преимущества только в узких случаях, требующих централизации и унификации ценой дополнительных усилий.
🐍 Пример клиента:
В случае уже имеющейся MCP экосистемы, доступен также адаптер (пока только для Node.js и Python): utcp-mcp, который позволяет подключить свыше 230 существующих MCP-инструментов через единый сервер, использующий под капотом UTCP. Это облегчает постепенный переход на новый протокол без потери доступа к старым интеграциям.
⚠️ TL;DR:
UTCP (Universal Tool Calling Protocol) позволяет ИИ-агентам напрямую обращаться к API и CLI-инструментам — без промежуточных серверов, JSON-RPC и кастомных «прокладок». Поддерживает HTTP, gRPC, WebSocket, CLI и стримы. Есть SDK для Python, Node.js, Go и MCP-адаптер под Node.js и Python.
Универсальный протокол вызова инструментов (Universal Tool Calling Protocol, UTCP) представляет собой смену парадигмы взаимодействия ИИ-агентов с внешними инструментами и сервисами. В отличие от традиционных подходов, требующих серверов-обёрток и прокси-слоёв, UTCP обеспечивает прямое взаимодействие между агентами ИИ и инструментами через их собственные эндпоинты.
Сегодня, чтобы подключить ИИ к внешним инструментам, разработчики вынуждены писать обёртки: агент → MCP-сервер → инструмент, и неизбежно сталкиваются с:
• лишними задержками и точками отказа;
• дублированием безопасности;
• необходимости в инфраструктуре ради вторичного посредника.
UTCP убирает необходимость в такой прослойке. В целом, сравнение UTCP и MCP можно свести к следующему: UTCP — это «мануал» (описание инструмента), а MCP — «посредник» (сервер, оборачивающий инструмент). UTCP предполагает архитектуру прямого взаимодействия «агент → инструмент», тогда как MCP — «агент → MCP-сервер → инструмент».
Отсюда вытекают и все преимущества UTCP:
• Инфраструктура: UTCP не требует новых сервисов (достаточно добавить endpoint в существующий API), MCP же нуждается в отдельном сервере(-ах) для каждого набора инструментов.
• Производительность: UTCP выполняет вызов за один шаг (агент сразу обращается к API инструмента), MCP добавляет “двойной прыжок” через посредника, увеличивая накладные задержки.
• Безопасность: UTCP использует нативную аутентификацию/авторизацию инструмента, MCP вынужден реализовывать и хранить учетные данные на своей стороне, что расширяет поверхность атаки.
• Поддержка протоколов: UTCP гибок (HTTP, WebSocket, CLI, gRPC и т.д. – вплоть до чтения локальных файлов), а MCP ограничен форматом JSON-RPC поверх единственного транспорта.
• Поддержка и масштабирование: UTCP-интеграции практически не требуют поддержки (статический JSON с описанием), масштабируются вместе с существующим сервисом; MCP-серверы же добавляют постоянные заботы (деплой, обновления, мониторинг, масштабирование отдельно от основного API).
Иначе говоря, UTCP выигрывает в простоте, скорости и универсальности, тогда как MCP может дать преимущества только в узких случаях, требующих централизации и унификации ценой дополнительных усилий.
import asyncio
from utcp.client import UtcpClient
from utcp.shared.provider import HttpProvider
async def main():
# Инициализируем UTCP-клиента
client = await UtcpClient.create()
# Определяем HTTP-провайдер (manual endpoint) для сервиса погоды
manual_provider = HttpProvider(
name="weather_service",
provider_type="http",
http_method="GET",
url="http://localhost:8000/utcp" # URL, возвращающий UTCP-описание (manual)
)
# Регистрируем инструменты из указанного manual (добавляем описание)
tools = await client.register_manual_provider(manual_provider)
print(f"Registered {len(tools)} tools")
# Вызов инструмента "get_weather" с параметром location
result = await client.call_tool(
"weather_service.get_weather",
arguments={"location": "San Francisco"}
)
print(f"Weather: {result['temperature']}°C, {result['conditions']}")
В случае уже имеющейся MCP экосистемы, доступен также адаптер (пока только для Node.js и Python): utcp-mcp, который позволяет подключить свыше 230 существующих MCP-инструментов через единый сервер, использующий под капотом UTCP. Это облегчает постепенный переход на новый протокол без потери доступа к старым интеграциям.
UTCP (Universal Tool Calling Protocol) позволяет ИИ-агентам напрямую обращаться к API и CLI-инструментам — без промежуточных серверов, JSON-RPC и кастомных «прокладок». Поддерживает HTTP, gRPC, WebSocket, CLI и стримы. Есть SDK для Python, Node.js, Go и MCP-адаптер под Node.js и Python.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3❤2🤔1
Поэзия как джейлбрейк: стихи ломают защиту LLM
Авторы исследования «Adversarial Poetry as a Universal Single-Turn
Jailbreak Mechanism in Large Language Models» протестировали 25 моделей (OpenAI, Anthropic, Google, DeepSeek, Mistral, Meta, Qwen и др.), подавая им опасные запросы… в рифму.
Два эксперимента:
1. 20 вручную написанных стихов о кибератаках, CBRN (химическое, биологическое, радиологическое и ядерное оружие), манипуляциях и потере контроля.
2. 1200 «вредных» промптов из открытого бенчмарка MLCommons AILuminate, автоматически превращённых в стихи.
Результаты оценивали LLM-судьи и люди. Метрика — ASR (Attack Success Rate), доля небезопасных ответов.
Результаты
Ручные стихи: 62% средний успех атаки
• gemini-2.5-pro: 100%
• DeepSeek / Mistral / Qwen: 80–95%
• Лишь Claude и GPT-5-nano удержали 0–10%.
Автогенерированные стихи:
• Проза: 8% ASR
• Стихи: 43% ASR → рост в 5 раз
По темам:
• Приватность: +45 п.п.
• Ненасильственные преступления: +39 п.п.
• CBRN: +38 п.п.
Обсуждение кибератак в стихах дало 84% успеха🤩
Почему поэзия работает
1. Фильтры обучены на прозе, а метафоры и ритм «смещают» текст от ожидаемого распределения.
2. Модели воспринимают стихи как безопасный жанр и снижают строгость отказов.
3. Большие модели уязвимее — лучше понимают переносный смысл, но не успевают применить защитные эвристики.
4. Эффект универсален: наблюдается у всех провайдеров и почти во всех категориях вреда.
Что это значит
• Текущие бенчмарки и сертификация (в духе EU AI Act) переоценивают безопасность — они не проверяют стилистические обходы.
• Нужны новые тесты, где намерение пользователя выражено не только прямым текстом, но и через поэзию, нарратив, юмор и бюрократический стиль.
• Без этого защиты условны: LLM остаются уязвимыми к самым простым «поэтическим» джейлбрейкам.
⚠ TL;DR:
Исследование показало: достаточно переписать вредный запрос в стихах — и защита крупных языковых моделей рушится. Поэтическая форма становится универсальным одностадийным джейлбрейком: для некоторых моделей доля небезопасных ответов превышает 90%, в среднем рост атак-успеха — в 4–5 раз по сравнению с прозой.
Авторы исследования «Adversarial Poetry as a Universal Single-Turn
Jailbreak Mechanism in Large Language Models» протестировали 25 моделей (OpenAI, Anthropic, Google, DeepSeek, Mistral, Meta, Qwen и др.), подавая им опасные запросы… в рифму.
Два эксперимента:
1. 20 вручную написанных стихов о кибератаках, CBRN (химическое, биологическое, радиологическое и ядерное оружие), манипуляциях и потере контроля.
2. 1200 «вредных» промптов из открытого бенчмарка MLCommons AILuminate, автоматически превращённых в стихи.
Результаты оценивали LLM-судьи и люди. Метрика — ASR (Attack Success Rate), доля небезопасных ответов.
Результаты
Ручные стихи: 62% средний успех атаки
• gemini-2.5-pro: 100%
• DeepSeek / Mistral / Qwen: 80–95%
• Лишь Claude и GPT-5-nano удержали 0–10%.
Автогенерированные стихи:
• Проза: 8% ASR
• Стихи: 43% ASR → рост в 5 раз
По темам:
• Приватность: +45 п.п.
• Ненасильственные преступления: +39 п.п.
• CBRN: +38 п.п.
Обсуждение кибератак в стихах дало 84% успеха
Почему поэзия работает
1. Фильтры обучены на прозе, а метафоры и ритм «смещают» текст от ожидаемого распределения.
2. Модели воспринимают стихи как безопасный жанр и снижают строгость отказов.
3. Большие модели уязвимее — лучше понимают переносный смысл, но не успевают применить защитные эвристики.
4. Эффект универсален: наблюдается у всех провайдеров и почти во всех категориях вреда.
Что это значит
• Текущие бенчмарки и сертификация (в духе EU AI Act) переоценивают безопасность — они не проверяют стилистические обходы.
• Нужны новые тесты, где намерение пользователя выражено не только прямым текстом, но и через поэзию, нарратив, юмор и бюрократический стиль.
• Без этого защиты условны: LLM остаются уязвимыми к самым простым «поэтическим» джейлбрейкам.
Исследование показало: достаточно переписать вредный запрос в стихах — и защита крупных языковых моделей рушится. Поэтическая форма становится универсальным одностадийным джейлбрейком: для некоторых моделей доля небезопасных ответов превышает 90%, в среднем рост атак-успеха — в 4–5 раз по сравнению с прозой.
Please open Telegram to view this post
VIEW IN TELEGRAM
4🔥10👍4❤3
Как разработчику быстро углубиться в тему LLM? Часть 1
В жизни каждого разработчика наступает момент, когда поверхностного знания технологии становится недостаточно, и возникает необходимость углубиться в детали, чтобы использовать её более эффективно и осознанно. В случае LLM это означает, что рано или поздно, вкатившийся в эти темы разработчик захочет побольше узнать о таких вещах, как:
1. Токенизация и эмбеддинги
2. Механизмы внимания
3. Архитектуры трансформеров
4. Популярные архитектуры LLM
5. Проблемы и решения при работе с LLM
6. Обучение моделей
7. Эффективный инференс и деплой
Звучит, как план, правда?☺️
1. Токенизация и эмбеддинги
Современные большие языковые модели работают на основе векторных представлений и механизма внимания, заложенного в архитектуру трансформеров. Первым шагом в обработке текста является токенизация — разбиение входной строки на токены, которые могут представлять собой слова, части слов или отдельные символы. Компиляторщиков и разработчиков средств анализа кода этот термин может слегка смутить, т.к. в NLP токенами не всегда принято считать то, что является ими в формальных языках. На практике широко используется subword-токенизация, например Byte-Pair Encoding: так, слово unhappiness может быть преобразовано в последовательность «un», «happi» и «ness». Такой подход уменьшает размер словаря и позволяет эффективно работать с редкими или ранее невстречавшимися словами.
Каждый токен получает уникальный идентификатор, по которому модель извлекает его вектор из матрицы эмбеддингов. Эмбеддинг — это высокоразмерный числовой вектор, отображающий семантику токена. После токенизации каждый элемент текста фактически превращается в набор чисел, отражающих его смысловые связи. Чем ближе по смыслу токену друг к другу, тем меньшее расстояние между ними в векторном пространстве. Например, вектор для слова apple окажется ближе к fruit, чем к car.
У моделей типа GPT-3 таблица эмбеддингов может быть очень большой: при словаре ~50 000 токенов и размерности эмбеддинга ~12 288 получается матрица порядка 50 000 × 12 288. Однако в современных крупных MoE-моделях, за счет sparse-архитектуры, эти оценки кратно меньше: 2k для 30B, 4k для 235B, например.
Поскольку трансформер не имеет встроенного понимания порядка токенов, к смысловому вектору добавляется позиционное кодирование. Итоговый вектор для каждого токена является комбинацией эмбеддинга и позиционного вектора, что позволяет модели учитывать как семантическое значение, так и положение токена в последовательности. Такая комбинация служит входом для дальнейшей обработки слоями внимания.
Познакомиться с этой темой ближе позволит статья «Глубокое погружение в токенизацию», для более глубокого погружения можно упороться в видеолекции (первая, вторая) от ФКН ВШЭ, или от Стэндфорда (выборочно, из первых 6 лекций), если «глубинное обучение» режет слух, и хочется привычного «deep learning».
Для специализированных задач типа анализа исходного кода, существуют отдельные модели эмбеддингов. Так, jina-embeddings-v2-base-code поддерживает английский язык и около 30 языков программирования, способна обрабатывать последовательности до 8192 токенов и оптимизирована для семантического поиска по коду. В таких моделях принципы токенизации и построения эмбеддингов остаются теми же, но словарь и обучающие данные адаптированы к структурам и паттернам программного кода.
Говоря о структурах, отдельно стоит отметить модели, опирающиеся на различные графовые представления кода, и позволяющие за счет этого намного точнее учитывать семантику кодовых баз:
• code2vec / code2seq: Path-Attention поверх AST
• GraphCodeBERT: Transformer поверх DFG + элементы GNN
• CuBERT: Transformer поверх фич CFG
• Devign: GNN поверх AST+CFG+DFG
• Code T5 / Code T5+: Transformer поверх AST-токенов
Ну и куда же без изучения тематической awesome-подборки, на правах домашнего задания🤓
В жизни каждого разработчика наступает момент, когда поверхностного знания технологии становится недостаточно, и возникает необходимость углубиться в детали, чтобы использовать её более эффективно и осознанно. В случае LLM это означает, что рано или поздно, вкатившийся в эти темы разработчик захочет побольше узнать о таких вещах, как:
1. Токенизация и эмбеддинги
2. Механизмы внимания
3. Архитектуры трансформеров
4. Популярные архитектуры LLM
5. Проблемы и решения при работе с LLM
6. Обучение моделей
7. Эффективный инференс и деплой
Звучит, как план, правда?
1. Токенизация и эмбеддинги
Современные большие языковые модели работают на основе векторных представлений и механизма внимания, заложенного в архитектуру трансформеров. Первым шагом в обработке текста является токенизация — разбиение входной строки на токены, которые могут представлять собой слова, части слов или отдельные символы. Компиляторщиков и разработчиков средств анализа кода этот термин может слегка смутить, т.к. в NLP токенами не всегда принято считать то, что является ими в формальных языках. На практике широко используется subword-токенизация, например Byte-Pair Encoding: так, слово unhappiness может быть преобразовано в последовательность «un», «happi» и «ness». Такой подход уменьшает размер словаря и позволяет эффективно работать с редкими или ранее невстречавшимися словами.
Каждый токен получает уникальный идентификатор, по которому модель извлекает его вектор из матрицы эмбеддингов. Эмбеддинг — это высокоразмерный числовой вектор, отображающий семантику токена. После токенизации каждый элемент текста фактически превращается в набор чисел, отражающих его смысловые связи. Чем ближе по смыслу токену друг к другу, тем меньшее расстояние между ними в векторном пространстве. Например, вектор для слова apple окажется ближе к fruit, чем к car.
У моделей типа GPT-3 таблица эмбеддингов может быть очень большой: при словаре ~50 000 токенов и размерности эмбеддинга ~12 288 получается матрица порядка 50 000 × 12 288. Однако в современных крупных MoE-моделях, за счет sparse-архитектуры, эти оценки кратно меньше: 2k для 30B, 4k для 235B, например.
Поскольку трансформер не имеет встроенного понимания порядка токенов, к смысловому вектору добавляется позиционное кодирование. Итоговый вектор для каждого токена является комбинацией эмбеддинга и позиционного вектора, что позволяет модели учитывать как семантическое значение, так и положение токена в последовательности. Такая комбинация служит входом для дальнейшей обработки слоями внимания.
Познакомиться с этой темой ближе позволит статья «Глубокое погружение в токенизацию», для более глубокого погружения можно упороться в видеолекции (первая, вторая) от ФКН ВШЭ, или от Стэндфорда (выборочно, из первых 6 лекций), если «глубинное обучение» режет слух, и хочется привычного «deep learning».
Для специализированных задач типа анализа исходного кода, существуют отдельные модели эмбеддингов. Так, jina-embeddings-v2-base-code поддерживает английский язык и около 30 языков программирования, способна обрабатывать последовательности до 8192 токенов и оптимизирована для семантического поиска по коду. В таких моделях принципы токенизации и построения эмбеддингов остаются теми же, но словарь и обучающие данные адаптированы к структурам и паттернам программного кода.
Говоря о структурах, отдельно стоит отметить модели, опирающиеся на различные графовые представления кода, и позволяющие за счет этого намного точнее учитывать семантику кодовых баз:
• code2vec / code2seq: Path-Attention поверх AST
• GraphCodeBERT: Transformer поверх DFG + элементы GNN
• CuBERT: Transformer поверх фич CFG
• Devign: GNN поверх AST+CFG+DFG
• Code T5 / Code T5+: Transformer поверх AST-токенов
Ну и куда же без изучения тематической awesome-подборки, на правах домашнего задания
Please open Telegram to view this post
VIEW IN TELEGRAM
6❤7👍3🔥2💯1
Почему мы почти не фокусируемся на работе, и как с этим бороться
Часто случается так, что в конце дня вы ощущаете себя рабом, отпахавшем на галере, с одной стороны, но и с ощущением бесцельно прожитого дня, с другой? Особенно в дни, когда пришлось сорваться в офис с привычной удаленки на несколько встреч?🤗
Вышедшая на днях статья «The Math of Why You Can’t Focus at Work» утверждает, что большинство проблем с концентрацией легко объясняются не силой воли или дисциплинированностью, а не зависящими от них тремя параметрами, которые можно формализовать в понятную и в чем-то даже изящную систему.
Прелесть этой системы в том, что она напрямую не основана на каких-либо трудновоспроизводимых исследованиях, работе с фокус-группами и т.п. Автор рассматривает рабочий день, как процесс, в котором внешние события возникают случайно, примерно как в модели пуассоновского потока.
Все переменные этого процесса любой желающий может подобрать под себя сам, а выводы, которые из этого последуют, опираются лишь на конечность продолжительности рабочего времени в сутках.
Ключевые параметры
1. Частота прерываний (λ)
Любой внешний стимул — сообщение, пуш-уведомление, созвон, «разговор на пару минут» — дробит рабочий день на мелкие фрагменты. Рост λ — гарантированная потеря структуры дня, независимо от навыков, настроения собранности.
2. Стоимость возврата в контекст (Δ)
После прерывания нужно время на реконструкцию модели задачи. Среднее Δ выглядит маленьким (5–15 минут), но на масштабе дня превращается в часы «скрытых» потерь.
3. Порог глубокого фокуса (θ)
Для нетривиальных задач нужен минимальный непрерывный интервал. Если временной слот < θ, работа идёт, но ценность почти не растёт — ничем, кроме рутины, заняться не удаётся.
Возможные сценарии
Шумный день
• Около двух десятков прерываний.
• Большинство доступных интервалов не пересекает θ.
• Около 4 часов полезной работы и всего один нормальный блок фокуса.
Формально «работали весь день», фактически — мало в чём продвинулись.
День с контролем среды
• Меньше внешних событий + быстрый возврат в задачу.
• 6+ часов продуктивного внимания.
• Несколько последовательных глубоких интервалов.
Здесь эффект нелинейный: снизили λ на 20–30%, а качество дня выросло кратно.
Что важно
• Вред приносит не количество задач, а фрагментация внимания.
• Одно «вставленное» совещание портит весь рабочий график, разрушая потенциальные интервалы ≥ θ.
• Пинг-культура в чатах увеличивает λ до уровня, где глубокая работа становится статистически маловероятной.
• Без управления этими параметрами невозможно стабильно планировать сроки, качество работы и комплексные задачи.
Автор также собрал симулятор карты рабочих дней, моделирующий предложенную им систему по заданным параметрам (залипнув в котором, можно запросто прощелкать слот-другой глубокого фокуса, btw).
⚠ TL;DR:
Продуктивность — это не дисциплина, а параметры среды.
Управляете прерываниями (λ), сокращаете количество возвратов в контекст (Δ), защищаете фокусные слоты (θ) — получаете системный кратный прирост качества и скорости.
Игнорируете — получаете «рабочие будни», в которых почти ничего не достигнуто, кроме ощущения лютой вымотанности к концу дня.
Часто случается так, что в конце дня вы ощущаете себя рабом, отпахавшем на галере, с одной стороны, но и с ощущением бесцельно прожитого дня, с другой? Особенно в дни, когда пришлось сорваться в офис с привычной удаленки на несколько встреч?
Вышедшая на днях статья «The Math of Why You Can’t Focus at Work» утверждает, что большинство проблем с концентрацией легко объясняются не силой воли или дисциплинированностью, а не зависящими от них тремя параметрами, которые можно формализовать в понятную и в чем-то даже изящную систему.
Прелесть этой системы в том, что она напрямую не основана на каких-либо трудновоспроизводимых исследованиях, работе с фокус-группами и т.п. Автор рассматривает рабочий день, как процесс, в котором внешние события возникают случайно, примерно как в модели пуассоновского потока.
Все переменные этого процесса любой желающий может подобрать под себя сам, а выводы, которые из этого последуют, опираются лишь на конечность продолжительности рабочего времени в сутках.
Ключевые параметры
1. Частота прерываний (λ)
Любой внешний стимул — сообщение, пуш-уведомление, созвон, «разговор на пару минут» — дробит рабочий день на мелкие фрагменты. Рост λ — гарантированная потеря структуры дня, независимо от навыков, настроения собранности.
2. Стоимость возврата в контекст (Δ)
После прерывания нужно время на реконструкцию модели задачи. Среднее Δ выглядит маленьким (5–15 минут), но на масштабе дня превращается в часы «скрытых» потерь.
3. Порог глубокого фокуса (θ)
Для нетривиальных задач нужен минимальный непрерывный интервал. Если временной слот < θ, работа идёт, но ценность почти не растёт — ничем, кроме рутины, заняться не удаётся.
Возможные сценарии
Шумный день
• Около двух десятков прерываний.
• Большинство доступных интервалов не пересекает θ.
• Около 4 часов полезной работы и всего один нормальный блок фокуса.
Формально «работали весь день», фактически — мало в чём продвинулись.
День с контролем среды
• Меньше внешних событий + быстрый возврат в задачу.
• 6+ часов продуктивного внимания.
• Несколько последовательных глубоких интервалов.
Здесь эффект нелинейный: снизили λ на 20–30%, а качество дня выросло кратно.
Что важно
• Вред приносит не количество задач, а фрагментация внимания.
• Одно «вставленное» совещание портит весь рабочий график, разрушая потенциальные интервалы ≥ θ.
• Пинг-культура в чатах увеличивает λ до уровня, где глубокая работа становится статистически маловероятной.
• Без управления этими параметрами невозможно стабильно планировать сроки, качество работы и комплексные задачи.
Автор также собрал симулятор карты рабочих дней, моделирующий предложенную им систему по заданным параметрам (залипнув в котором, можно запросто прощелкать слот-другой глубокого фокуса, btw).
Продуктивность — это не дисциплина, а параметры среды.
Управляете прерываниями (λ), сокращаете количество возвратов в контекст (Δ), защищаете фокусные слоты (θ) — получаете системный кратный прирост качества и скорости.
Игнорируете — получаете «рабочие будни», в которых почти ничего не достигнуто, кроме ощущения лютой вымотанности к концу дня.
Please open Telegram to view this post
VIEW IN TELEGRAM
10👍19🔥10❤3😢3