Искусство. Код... ИИ?

Как разработчику быстро углубиться в тему 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. Матрица эмбеддингов может быть очень крупной: при словаре около 50 000 токенов и размерности эмбеддинга 12 288, как у GPT-3, она содержит порядка 614 миллионов параметров. Поскольку трансформер не имеет встроенного понимания порядка токенов, к смысловому вектору добавляется позиционное кодирование. Итоговый вектор для каждого токена является суммой эмбеддинга и позиционного вектора, что позволяет модели учитывать как семантическое значение, так и положение токена в последовательности. Такая комбинация служит входом для дальнейшей обработки слоями внимания. Познакомиться с этой темой ближе позволит статья «Глубокое погружение в токенизацию», для более глубокого погружения можно упороться в видеолекции (первая, вторая) от ФКН ВШЭ, или от Стэндфорда (выборочно, из первых 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 Авторы исследования «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 раз по сравнению с прозой.

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 может дать преимущества только в узких случаях, требующих централизации и унификации ценой дополнительных усилий. 🐍 Пример клиента:

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. Это облегчает постепенный переход на новый протокол без потери доступа к старым интеграциям. ⚠️ TL;DR: UTCP (Universal Tool Calling Protocol) позволяет ИИ-агентам напрямую обращаться к API и CLI-инструментам — без промежуточных серверов, JSON-RPC и кастомных «прокладок». Поддерживает HTTP, gRPC, WebSocket, CLI и стримы. Есть SDK для Python, Node.js, Go и MCP-адаптер под Node.js и Python.

UTCP: новая альтернатива MCP Универсальный протокол вызова инструментов (Universal Tool Calling Protocol, UTCP) представляет собой смену парадигмы взаимодействия агентов ИИ с внешними инструментами и сервисами. В отличие от традиционных подходов, требующих серверов-обёрток и прокси-слоёв, UTCP обеспечивает прямое взаимодействие между агентами ИИ и инструментами через их собственные эндпоинты. Проблема Сегодня, чтобы подключить ИИ к внешним инструментам, разработчики вынуждены писать обёртки: агент → MCP-сервер → инструмент. Это означает: * лишние задержки и точки отказа; * дублирование безопасности; * инфраструктура ради посредника. --- ### 💡 Решение: UTCP UTCP убирает прослойку. Он работает как “manual” — инструкция, как вызывать инструмент напрямую по его нативному интерфейсу. Если человек может вызвать ваш API, UTCP делает так, чтобы ИИ-агент мог сделать то же самое — с теми же правами, но без новых серверов. --- ### ⚙️ Пример на Python

import asyncio
from utcp.client import UtcpClient
from utcp.shared.provider import HttpProvider

async def main():
    client = await UtcpClient.create()
    manual_provider = HttpProvider(
        name="weather_service",
        provider_type="http",
        http_method="GET",
        url="http://localhost:8000/utcp"  # ваш UTCP manual
    )

    tools = await client.register_manual_provider(manual_provider)
    print(f"Registered {len(tools)} tools")

    result = await client.call_tool(
        "weather_service.get_weather",
        arguments={"location": "San Francisco"}
    )
    print(result)

asyncio.run(main())

Здесь агент узнаёт из UTCP-описания, как вызвать API. Без обёрток, без “proxy”, без дублирования токенов — только нативный вызов. --- ### ✅ Мини-чеклист: включаем UTCP [ ] Добавьте endpoint /utcp, возвращающий UTCP-описание (совместимо с OpenAPI). [ ] Опишите ваши инструменты (методы, параметры, аутентификацию). [ ] Проверьте SDK (pip install utcp, npm i @utcp/core, go get utcp). [ ] Зарегистрируйте manual в клиенте → вызовите инструмент напрямую. [ ] (опционально) подключите мост utcp-mcp, если у вас старая MCP-инфраструктура. --- ### ⚡️ Почему стоит попробовать * Без инфраструктурных затрат: достаточно одного JSON manual. * Минимальная латентность: агент вызывает API напрямую. * Нативная безопасность: используется ваш API-ключ или OAuth без дублирования. * Гибкость: HTTP, CLI, gRPC, WebSocket — без ограничений. * Масштабирование бесплатно: UTCP растёт вместе с вашим API. --- ### 🔗 Ресурсы * Документация: [utcp.io](https://www.utcp.io) * GitHub SDK: [github.com/universal-tool-calling-protocol](https://github.com/universal-tool-calling-protocol) * Статья: *UTCP — прямая альтернатива MCP* --- Вывод: UTCP — это новый стандарт “интеграций без посредников”. Добавив один endpoint, вы открываете вашим ИИ-инструментам прямой канал к API. Меньше обёрток — больше пользы. TL;DR: UTCP (Universal Tool Calling Protocol) позволяет ИИ-агентам напрямую обращаться к вашим API и CLI-инструментам — без промежуточных серверов, JSON-RPC и кастомных «прокладок». Поддерживает HTTP, gRPC, WebSocket, CLI и стримы. Есть SDK для Python, Node.js, Go.

🧩 Принципы и паттерны безопасной разработки: 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-строки и шаблоны По мотивам предыдущего поста: 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.

О t-строках в Python 3.14 В юбилейной π-версии 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 = "<script>alert(1)</script>"
assert html(t"<p>{evil}</p>") == "<p>&lt;script&gt;alert(1)&lt;/script&gt;</p>"

Однако, как и говорится в описании изменений, t-строки — это лишь механизм обработки строк, а не панацея от инъекций, неправильное использование которого позволит прострелить себе конечность не менее лихо, чем в случае с f-строками: • Эффективность санитизации интерполяций — целиком зависит от правильного выбора или написания их обработчиков. • Все выражения внутри блоков {…} вычисляются сразу же в лексическом скоупе, интерполяцией же становится результат этого вычисления. Поэтому t"{eval(request.get['a'])}" — это всё ещё RCE, вне зависимости от обработчиков. Похожая история — и с попаданием в Template или Interpolation входных данных при создании объектов этих классов из конструкторов (вообще, стоит этого по-возможности избегать, и пользоваться предложенным синтаксическим сахаром t"…"). • Конкатенация Template + Template разрешена. Это удобно, но может породить «вирусность» шаблонов и неочевидную логику сборки, если смешивать части, ожидающие разных политик экранирования. • Формат-спецификаторы внутри {…} вычисляются до format_spec, что может привести к потере грамматического контекста, когда придёт время обработчика. • Валидацию входных данных в соответствии с бизнес-логикой этот механизм не заменяет, и относится лишь ко второму эшелону эффективной обработки данных. В общем, механизм годный, использовать стоит, но «думать всё равно придётся» (с) 😊

Новый взгляд на «контекст» в ИИ: от prompt engineering к context engineering Команда Anthropic опубликовала статью «Effective Context Engineering for AI Agents», где утверждает, что в эпоху агентных систем привычное «написать правильный prompt» постепенно уступает место более широкому подходу — контекст-инженерии. Контекст — не просто текст промпта, а весь набор токенов, который модель «видит» в момент вывода. Авторы показывают, что по мере роста размеров контекста модели начинают терять фокус: не вся информация доходит до «внимания». В этом смысле контекст — ограниченный ресурс, и важно тщательно отбирать «высокосигнальные» куски данных. Что составляет контекст-инженерию на практике? • Отказ от перегруженных инструкций и «жёстких» шаблонов в пользу сбалансированных, гибких указаний. • Динамическое подключение данных по принципу «just in time»: агент подгружает нужные фрагменты контекста в момент, когда они действительно важны. • Техники для задач с большой временной протяженностью: сжатие истории (основные факты сохраняются, лишнее — убирается), записи-заметки вне контекста, или распределённые структуры с суб­агентами. По мнению авторов, context engineering — это не просто тренд, а фундаментальный сдвиг в проектировании ИИ-агентов. Даже по мере роста возможностей моделей, бережное управление вниманием остаётся ключом к стабильному и надёжному поведению.

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 — как инфраструктурные провайдеры. Установка (единый паттерн):

git clone https://github.com/Arindam200/awesome-ai-apps.git
cd awesome-ai-apps/<project_name>
pip install -r requirements.txt

🧘‍♀️ Каждый проект снабжен своим README.md, а там можно и сразу стартовать. Этот репозиторий можно в чистом виде 🏖️ R&D-песочница, быстро тестировать разные стеки, паттерны взаимодействия агентов, интеграции MCP и реализацию RAG. Гении, как известно, воруют 👌 #AI #LLM #RAG #LangChain #LlamaIndex #CrewAI #Agno #Memori #AIagents #opensource #MCP #Python #MachineLearning #GenerativeAI

SymbolicAI — правильный подход к нейросимвольному программированию. Среди постоянно льющегося буллшита вокруг нейросимвольных технологий (которыми сейчас стали называть любые системы, в которых формальные методы выступают верификаторами ИИ-шных и наоборот) затерялась недооцененная жемчужина, здорово упрощающая жизнь ресерчерам и разработчикам ИИ-систем. 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",
    "description": "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, короче.

Эстетика ИИ-агентов: и снова... Claude Code В догонку к предыдущему посту. На днях The Pragmatic Engineer опубликовали статью «How Claude Code is built», которая однозначно заслуживает внимания. Тезисно: • От хакатона до бизнеса на $500 млн в год: идея началась как пробный скрипт в терминале, но когда модель стала сама «гулять» по импортам и читать кодовую базу, команда поняла, что это полноценный продукт — и решилась быстро вывести его наружу. • Минимум кода вокруг модели: разработчики сознательно удаляли вспомогательную логику, чтобы ИИ сам брал на себя максимум работы. Это риск — меньше контроля и привычных «страховок», но выигрыш в скорости развития. • Лёгкий, нестандартный стек: TypeScript + React (Ink) + Yoga для терминального UI, Bun для сборки. Решили не тянуть привычные тяжёлые фреймворки, чтобы обновления шли мгновенно. • Рекордный темп: до 100 внутренних релизов в день, десятки прототипов за пару суток. Такую скорость поддержали «короткие циклы доверия»: фичи выпускаются рано, чтобы сразу получать фидбек, а не шлифовать месяцами. • Дерзкий баланс свободы и безопасности: Claude Code может менять файлы и запускать команды, но каждое действие требует подтверждения. Разработчики сознательно дали модели широкие полномочия — с минимальным, но чётким контролем пользователя. • Sub-agents за 3 дня: идею «агентов внутри агента» оформили в продакшн после двух провальных попыток — показав, что команда готова быстро рисковать и отбрасывать неудачные решения. В деталях:

Как разработчику быстро вкатиться в тему 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, как говорится☺️

Два «питомца» для ИИ-пентеста: 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 — тяжеловес, в хорошем смысле этого слова, для поиска полноценных деревьев атак. Оба проекта в целом хорошо показывают, куда идёт автоматизация вебсека, что не может не радовать... ...или пугать, это уж как посмотреть 😬

Уязвимости в дата-репозиториях. Обзорно главное Репозитории для анализа данных и ML - зона повышенного риска ⚠️. Быстрое прототипирование, работа с чувствительными данными и специфичные инструменты создают уникальные векторы атак. Вот ключевые из них: 1. 🤫 Секреты в коде. Самая распространённая и критичная уязвимость. Хардкод API-ключей (например, к AWS S3, OpenAI, базам данных), токенов доступа и даже паролей прямо в Jupyter Notebook, конфигурационных файлах и скриптах. При попадании такого кода в публичный репозиторий злоумышленники получают прямой доступ к платным сервисам и данным. Лечение ‘git grep’ + ‘truffleHog’, ротация ключей, менеджер секретов. 2. 🧑‍💻 RCE через десериализацию Библиотеки pickle и joblib - стандарты для сохранения ML-моделей в Python - небезопасны. Десериализация файла из ненадёжного источника может привести к выполению произвольного кода на машине. Лечение yaml.safe_load(), ONNX, sandbox. 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 — главные уязвимости

Новый выпуск — и он про безопасность! В нём эксперт по Application Security из Positive Technologies Владимир Кочетков рассказывает: • что будет, если вообще забить на безопасность; • почему от уязвимостей бизнес-логики «никогда в жизни не защитит» даже самый крутой AF; • правда ли, что хакеры теперь умнее нас из-за ИИ; • как внедрить безопасность, чтобы тебя не возненавидели все разработчики. Слушать → на удобной площадке на YouTube на Яндекс Музыке в Вконтакте

Принял участие в подкасте DevOps Deflope. Поболтали чуть за безопасную разработку и смежные с ней темы 😍

В разы быстрее, на порядок опаснее: исследование безопасности ИИ-разработки от Apiiro На фоне растущей тенденции повсеместного и обязательного (а, в некоторых случаях, и принудительно-карательного) внедрения ИИ-решений в процессы разработки, компания 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'а за спиной выстроенные и работающие процессы тестирования и безопасной разработки. И тут было бы уместно завершить пост красивой установкой, прозвучавшей в исследовании: «внедряете ИИ-кодеров, внедряйте и ИИ-аппсеков», если бы не одно но... Несмотря на ожидаемый в конце исследования призыв «покупайте наши решения», там почему-то отсутствуют такие же красивые диаграммы, показывающие влияние предлагаемых решений на общую картину. А ведь это напрашивается в такой публикации само собой. Видимо аргумент о «чудес не бывает» — пока ещё актуален по обе стороны баррикад 🤷‍♂️

Абстрактная интерпретация и символьное выполнение: в чем разница?

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

Пост родился по мотивам вчерашних обсуждений с собратьями по несчастью коллегами. Дело в том, что эти два подхода к анализу приложений здорово путают, а иногда считают одно подмножеством другого. На самом деле, все чуть сложнее) При символьном выполнении код интерпретируется, или выполняется, в соответствии с подмножеством семантики целевого языка, заменой всех неизвестных значений (входных данных) символьными переменными и вычислением формул в модели памяти, вместо конкретных значений. Подмножеством — потому что, невычислимые и сложно-вычислимые конструкции (вроде циклов и рекурсии, инварианты которых включают символьные переменные) упрощаются различными способами, про которые в академическом мире пишут целые диссертации. В реальном же мире 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). Это уже лучше, чем только интервалы, но и дороже. Таким образом, эти два подхода действительно принадлежат одному семейству в том смысле, что осуществляют интерпретацию кода. Но символьное выполнение полагается в большей степени на упрощение семантики языка, в то время, как абстрактная интерпретация — на упрощение семантики данных, заданное на старте интерпретации. Но вообще, отвечая на вопрос, является ли одно подмножеством другого... если у абстрактной интерпретации отрезать все ограничения на входные данные, и основанные на них техники вычисления циклов и рекурсии, но пришить при этом упрощение семантики языка, то из дедушки возможно и получится бабушка🤷‍♂️

Эстетика ИИ-агентов: 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, чтобы попробовать его в деле, задействуя максимум возможностей, если вдруг ещё не.

🧩 Принципы и паттерны безопасной разработки: SRP Хоть это и не вполне очевидно, но разработка безопасных приложений может (а, возможно, и должна) начинаться, отнюдь не с моделирования угроз, внедрения в код механизмов защиты, ревью безопасности, пентестов, внедрения SCA/SAST/DAST, или, тем более, чего-то, вроде хантовского «Hack Yourself First» ✝️ В лучших традициях Shift Left Security, начинать стоит с базовых принципов разработки, таких, как SOLID, YAGNI, DRY, KISS, чистый код с архитектурой и т.п. Именно они позволяют заложить в архитектуру и реализацию приложения правильный фундамент, на котором будет гораздо проще и дешевле реализовывать прочие решения и этапы внедрения DevSecOps. Начнём с принципа единственной ответственности (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»: мелкие простые модули легче защитить и проверить.