🖼 Изображения с текстом ради экономии токенов: не всё так просто

На прошлой неделе буквально в каждом релевантном паблике проскочил проект pxpipe — тула, позволяющая экономить расход токенов за счет преобразования контекстного текста в изображения, при работе с VLM. Ещё дальше зашел Can Bölük (боюсь пытаться написать это по-русски) — автор кодинг-агента oh-my-pi. Это вообще мой кумир, кроме шуток и без сарказма. Подписки на обновы в его проекте в принципе достаточно, чтобы быть в курсе вообще всех инноваций, которым можно найти хоть какое-то применение в кодинг-агентах. Так вот он, примерно в одно время с автором pxpipe, вообще сделал этот подход одной из стратегий сжатия контекста (SnapCompact) в своём агенте.

Идея превращать текст в изображения перед отправкой в VLM звучит безусловно прикольно. Механика проста: текстовый токен — дискретная единица из словаря ~50K–200K, один токен в среднем кодирует ~2.5-3 символа для плотного контента (код, JSON). Визуальный токен — патч, скажем, в 28×28 пикселей в непрерывном пространстве эмбеддингов, и может принимать любое значение. Плотность — на порядок выше. По формуле Anthropic, изображение 1568×728 стоит ~1522 токена и вмещает ~28 000 символов — сжатие ~4.6× по входным токенам.

Ну, зашибись же? Вот... не совсем.

Коэффициент экономии 10× по входным токенам — действительно имеет место, но он относится к специализированной модели DeepSeek-OCR с кастомным энкодером, обученным именно на оптическое сжатие. Для VLM общего назначения (Claude, GPT) реальный выигрыш скромнее — 2–3×. pxpipe на реальном трафике Claude Code показал −68% входных токенов, а академическое исследование зафиксировало лишь ~2× без потери качества. SWE-bench Lite: 10/10 задач решены на обоих arms, стоимость $27 vs $53 (−49%) — но это лишь 10 задач, как-то маловато для статистической значимости.

О чём ещё постоянно забывают упомянуть хайп-посты на эту тему — это «налог» на декодирование. Чтение плотного изображения является вычислительно тяжёлой задачей: модель тратит лишние thinking-токены на распознавание. Для SnapCompact его автор провел тщательные замеры: output-токены +333%, thinking-токены +561%. При ценах Anthropic на Sonnet ($3/$15) один проход оказался на 28% дороже текста. Независимый эксперимент PageWatch подтвердил картину: GPT-5 экономит −40% prompt-токенов, но completion-токены выросли у всех моделей, съедая всю экономию. Выгода появляется только в очень длинных сессиях с переиспользованием KV-кэша.

Другой проблемой являются конфабуляции (эх, прочитал бы это старина Зигмунд): при ошибках чтения модель не признаётся в неуверенности, и выдаёт правдоподобные, но неверные значения. Аудит pxpipe: точное воспроизведение hex-строк — лишь 38%, с систематической путаницей глифов (0⇆O, 6⇆8, 5⇆S, camelCase→lowercase). Opus 4.8 набрал 0/15 на hex-recall и поэтому отключён в pxpipe по умолчанию. Из реальных примеров: модель «вспомнила» имя человека из истории чата — уверенно, но неверно. Fable 5 читает рендеры почти идеально: 100/100 на novel arithmetic, 98/98 на gist recall. GPT-5.6 тоже силён. При этом Opus 4.8 ошибается в ~7% случаев, а вот GPT-5.5 деградирует примерно вхлам на контексте в изображениях. Универсального решения нет — метод не модель-агностический.

Попутно выяснилось, что помимо дискриминации китайцев, Anthropic ещё и молча уменьшает изображения больше ~1.15 MP (downscale ~0.555×), но выставляет счёт за полные пиксели ↗️ Без коррекции геометрии (≤1568×728) экономия размывается, а ёмкость страницы падает с ~92 000 до ~28 000 символов — нужно в 3.3× больше изображений.

Отдельной болью является выбор подходящего шрифта для рендера текста в изображение. Ниже 35–40 px² на символ наступает обрыв: транскрипция падает с 0.79 до 0.02. Мельче — уже не дешевле, с учетом стоимости ошибок. Шрифт 4×6 даёт 102K символов на страницу, но модель читает лишь 2% — экономия токенов тут оборачивается полной потерей смысла (здравого, по крайней мере).

⚠ TL;DR: так что метод прикольный, идея заслуживает внимания, но... относиться к этому стоит, скорее, как ко временному багу тарификации, не более того.

В c0wrk, пожалуй, я это тянуть не буду 🙂

#ИИ_инструменты

🧩 Принципы и паттерны безопасной разработки: DIP

Часть 4.

Принцип инверсии зависимостей (Dependency Inversion Principle, DIP) утверждает: модули верхнего уровня не должны зависеть от модулей нижнего уровня, оба должны зависеть от абстракций. При этом не абстракции должны зависеть от деталей, а детали — от абстракций.

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

💡 Пример

// С нарушением DIP
class DataBinder {
    void bind(Object target, Map<String,String> params) {
        for (PropertyDescriptor pd :
                Introspector.getBeanInfo(target.getClass())
                    .getPropertyDescriptors()) {
            if (params.containsKey(pd.getName()))
                pd.getWriteMethod().invoke(target, params.get(pd.getName()));
        }
    }
}

// С соблюдением DIP
interface BindablePropertyResolver {
    List<BindableProperty> resolve(Class<?> type);
}

class DataBinder {
    private final BindablePropertyResolver resolver;

    void bind(Object target, Map<String,String> params) {
        for (BindableProperty bp : resolver.resolve(target.getClass())) {
            if (params.containsKey(bp.name()) && bp.isSafe())
                bp.set(target, params.get(bp.name()));
        }
    }
}

Абстракция BindablePropertyResolver контролируется высокоуровневым модулем и определяет контракт: что можно связывать, а что — нет. Даже если интроспекция обнаружит новые свойства, они не станут доступны без явного разрешения.

Помимо архитектурного разделения, главным правилом остается биндинг входных данных строго к выделенным DTO (Data Transfer Objects), а не к доменным сущностям или объектам фреймворка. DTO содержит только явно разрешенные поля, что исключает динамический биндинг опасных свойств.

Нарушения DIP провоцируют:

• CWE-913: Improper Control of Dynamically-Managed Code Resources
• CWE-470: Use of Externally-Controlled Input to Select Classes or Code
• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

🐛 Жизненное

CVE-2022-22965 — Spring Framework RCE, она же Spring4Shell (CVSS 9.8).

Механизм привязки параметров (data binding) в Spring MVC — высокоуровневый модуль, отвечающий за маппинг HTTP-параметров в свойства Java-объектов. Внутри он напрямую зависит от низкоуровневого Java Beans Introspection API (CachedIntrospectionResults → java.beans.Introspector), рекурсивно обходящего цепочки геттеров/сеттеров.

На JDK 8 существовал чёрный список: Spring блокировал доступ к class.classLoader. Но в JDK 9 у Class появился новый геттер — getModule(). Через него открылся обходной путь class.module.classLoader, не попавший в чёрный список. Цепочка:

class.module.classLoader.resources.context.parent.pipeline.first.*

позволяла модифицировать конфигурацию Tomcat AccessLogValve — атакующий менял путь, паттерн и суффикс лога, записывая на диск JSP-файл (web shell).

Нарушение DIP здесь в том, что data binding напрямую зависел от конкретного механизма интроспекции (низкоуровневая деталь), без абстракции, определяющей контракт: какие свойства разрешено связывать. Когда деталь (набор доступных PropertyDescriptor-ов) изменилась из-за развития JDK — поверхность атаки расширилась без единого изменения в коде самого Spring.

🔧 Как пофиксили

Spring не стал внедрять глобальный белый список (чтобы не сломать обратную совместимость), и добавил чёрный, на уровне интроспекции. Доступ к свойствам Class, classLoader и protectionDomain был полностью заблокирован, что разорвало опасную цепочку... до следующего витка развития JDK, видимо 😬

💻 Как насчет композиционных языков?

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

⚠ TL;DR: Если модуль верхнего уровня напрямую зависит от деталей реализации нижнего — любое изменение внизу может молча расширить поверхность атаки наверху. Инвертируйте зависимость: пусть высокоуровневый модуль определяет контракт допустимых данных, а низкоуровневый — реализует его. А на входе всегда используйте DTO.

#безопасность_кода #гайд

✨ sp4rk: SDK для разработки ИИ-агентов на Go

Выделил из c0wrk в отдельный проект sp4rk SDK, на котором он основан. Умеет практически* всё, что нужно для построения мультиагентных систем на Go, и предоставляет два API (можно смешивать):

• классический — для полного контроля над всеми компонентами и их конфигурацией;
• «текучий» (fluent) — для быстрого построения агентов из заготовленных блоков.

Например, игрушечный триажер тикетов для Github-репозитория, с MCP, сессионной памятью, DAG-планированием и рефлексией в случае проблем, во fluent-варианте выглядит так:

system := "You are a triage agent. Use the github tools, verify each result, then call finish with a short report."

task := "Find the 5 most recent open issues in v0lka/sp4rk with the `error-handling` label, summarize each in one line, and save the digest as a fact for the next step."

github := mcp.ServerEntry{
    Transport: "stdio",
    Command:   "npx",
    Args:      []string{"-y", "@modelcontextprotocol/server-github"},
    Env:       map[string]string{"GITHUB_PERSONAL_ACCESS_TOKEN": "${…}"},
}

result, err := sp4rk.NewF().
    Anthropic(os.Getenv("ANTHROPIC_API_KEY"), "claude-sonnet-5").
    MCPServer("github", github).
    MemoryTools().
    AutoApprove().
    MaxSteps(25).
    System(system).
    Task(context.Background(), task).
    Plan().
    Reflect().
    MaxRetries(2).
    Execute()

Больше примеров — есть в /examples и документации.

Ещё даже не бета (выйдет вместе с бетой c0wrk), но уже достаточно стабильный, чтобы пробовать.

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

#ИИ_инструменты

😸 Как улучшить работу агента с codebase-memory-mcp?

MCP codebase-memory-mcp — добротный инструментарий, позволяющий экономить тонны токенов на исследования кодовой базы и получать парой вызовов своих инструментов то, на что у агента ушли бы десятки [rip]grep, glob, read_file, etc.

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

Ситуацию можно исправить, если добавить в AGENTS.md проекта или агента (или в правила агента, или во что угодно, что гарантировано попадет в контекстное окно любой сессии) следующую подсказку:

## Codebase navigation via `codebase-memory-mcp` (if available)

If the `codebase-memory-mcp` MCP server is connected (e.g. its tools appear with an `[MCP]` prefix), prefer it for code discovery, call-graph tracing, and architecture questions instead of broad manual `grep`/`glob` sweeps. **Every project-scoped tool requires a project identifier.** Calling such a tool without the correct identifier returns an error of the form `project not found or not indexed` (with a hint listing the available projects).

### Project identifier

The identifier is derived from the repository's **absolute path**: replace every path separator (`/`) with `-` and drop the leading slash.

| Repository path                     | Project identifier                       |
| ----------------------------------- | ---------------------------------------- |
| `/path/to/repo`                     | `path-to-repo`                           |

`index_repository` accepts an optional `name` argument that overrides this derived identifier. **Do not set it** — it creates a separate project entry alongside the path-derived one and breaks the predictable identifier rule. Always let the identifier be derived from the path.

### Required workflow

1. **Verify the project is indexed** — call `list_projects` first (it takes no arguments). Compute the expected identifier from the repo path (rule above) and check it against the returned `projects[].name` list (or match by `root_path`).
2. **Index if absent** — if the project is missing, call `index_repository(repo_path=<absolute path>)` (omit `name`). Read the returned `project` field to confirm the actual identifier; it equals the path-derived form. Use `mode="fast"` for a quick pass, `"full"` when you need similarity/semantic edges.
3. **Pass the identifier to the tools** — supply it as the `project` argument to every project-scoped tool. Without it, the tool errors out and will not query the graph.

### Tools by purpose

- **Discover** — `search_graph` (BM25 + semantic + regex over functions/classes/routes), `search_code` (grep augmented by the call graph), `get_architecture` (packages, clusters, layers, hotspots).
- **Read code** — `get_code_snippet` (read a function/class by `qualified_name`; resolve it first via `search_graph`).
- **Trace relationships** — `trace_path` (callers/callees, data flow, cross-service hops), `query_graph` (raw Cypher for multi-hop/aggregate queries).
- **Change & impact** — `detect_changes` (diff vs a git ref + blast radius), `get_graph_schema` (node labels / edge types).
- **Index management** — `index_repository`, `index_status`, `list_projects`, `delete_project`, `ingest_traces` (runtime traces), `manage_adr` (Architecture Decision Records).

🙌

#ИИ_инструменты

Математика категорий и ИИ

Любишь читать академичные лонгриды с сомнительной практической пользой? Тогда этот пост для тебя!

О теории категорий обычно говорят как об одной из самых абстрактных областей математики. Довелось прочитать популярную книгу «Восторг абстрактной математики» Юджении Ченг (вслух тебе её прочитают на ютубе, можешь купить на озоне за 4к и в целом за год достаточно прочитать только ее, чтоб собой гордиться, она сложная и АБСТРАКТНАЯ) и статью на хабре, а на основе прочитанного обдумать, где в ИИ теория категорий и зачем она вообще нужна! Посвящаю пост тому, кто хотел взять Юджению с собой в отпуск 🍐.

Дело в том, что теория категорий изучает не сами объекты, а отношения между ними и правила их композиции. Именно поэтому её иногда называют математикой композиции (и математикой математики). То самое "Думай абстрактно!".

Разберу несколько базовых терминов.
🌈 Категория — это совокупность объектов и стрелок (морфизмов) между ними. Стрелки можно последовательно склеивать (композировать), склейка ассоциативна, а у каждого объекта есть тождественный морфизм (стрелка), который ничего не меняет. Всё, три правила.
Например, если есть преобразования

Текст → Эмбеддинг → Ответ

то теория категорий рассматривает всю цепочку как единое отображение.

🌈 Морфизм (Morphism) называют обобщением функции. В абстрактной категории это просто стрелка между объектами, про которую известно лишь, что её можно композиционировать с другими стрелками. А уже в конкретных категориях (например, категории множеств или векторных пространств) морфизмы действительно являются отображениями, сохраняющими структуру. А вот если категория конкретная (объекты — множества со структурой), то морфизм — это гомоморфизм, то есть отображение, сохраняющее структуру. Да, абстракция — это не за пивом в КБ спуститься.
В машинном обучении морфизмом можно считать практически любое преобразование данных:
🍄 токенизация;
🍄получение эмбеддингов;
🍄слой нейронной сети;
🍄attention;
🍄вызов инструмента агентом.
Вся нейронная сеть по сути просто композиция морфизмов.

🌈 Композиция (Composition) — главный объект изучения теории категорий.
Если есть

A → B
B → C

то их можно объединить в одно преобразование

A → C

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

🌈 Функтор (Functor) — отображение между двумя категориями, которое сохраняет их структуру. Переводит объекты в объекты, стрелки в стрелки, и делает это согласованно со склейкой.
Сравню с компилятором, зря что ли по ним учебники прочитаны.
Но самый понятный пример из ML — эквивариантность. Повернуть картинку и потом сегментировать = сегментировать и потом повернуть маску. Оба пути дают одно и то же — функториальность.

🌈 Натуральное преобразование (Natural Transformation) — способ согласованно преобразовать один функтор в другой. Если существуют два различных способа перевести текст в эмбеддинг, натуральное преобразование описывает, когда эти способы эквивалентны с точки зрения всей системы. С понятием эквивалентности в книге тоже пришлось помучиться, т.к. эквивалентны не значит равны!

🌈 Монада (Monad) — один из самых известных объектов теории категорий. Формально это эндофунктор (функтор из категории в саму себя) с двумя дополнительными операциями, удовлетворяющими определённым законам. Ближайший пример из МЛ практики — цепочка вызовов тулов агентом (каждый шаг тащит за собой контекст, состояние и возможный отказ, а монада описывает, как такие шаги корректно склеивать). Ради этого их в программирование и притащили — описывать вычисления с побочными эффектами (чтение памяти, вызов API и дальше придумай сам примеры).

А где здесь ИИ и зачем вообще этот пост?
Интерес к теории категорий в МЛ возник не потому, что она позволяет сделать трансформер умнее 😡. Скорее она предлагает единый математический язык для описания сложных AI-систем.
Сегодня появляются работы, где через категории описывают:
👋 композицию нейронных сетей;
👋 backpropagation и автоматическое дифференцирование;
👋 архитектуры глубокого обучения;
👋 мультимодальные модели;
👋 агентные системы;
👋 нейросимвольный AI.
Крч, надо ознакомиться с терминологией, потому что может пригодиться.

Что почитать?
Если ты дочитал до сюда и думаешь, что у меня свистит крыша и в МЛ это никому не надо, то статьи 2021 и 2024 годов:
⌚️ Обзор Category Theory in Machine Learning (2021) — хорошее введение в применение категорий в ML.
⌚️ Прямое продолжение первого, где авторы заявляют его как обновление и расширение обзора Shiebler et al. Систематизируют четыре направления — градиентное обучение, вероятностные модели, методы на основе инвариантности и эквивариантности и обучение на основе топосов. Последнее направление отвечает за интерпретируемость, композиционность и анализ глобальной структуры AI-систем.

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

Вот такой скучный лонгрид! От абстракций голова кругом.
Все!
🏆

🔎 Ковыряем Codex Security

OpenAI выложили @openai/codex-security — CLI и TypeScript-SDK для поиска, валидации и фикса уязвимостей в коде. Самое время заглянуть внутрь.

Проект

Сам пакет построен поверх @openai/codex и @openai/codex-sdk. В src/ около 13,7 тыс. строк TypeScript, логика скана вынесена в _bundled_plugin/. Это бандл из 13 скиллов (каждый со своим субагентом), MCP-сервера, 32 Python-скриптов, реф-документов (references/) и JSON-схем (schemas/: coverage, findings, scan-manifest).

Как оно работает

Сначала threat-model строит модель угроз, затем оркестратор security-scan гоняет файлы через finding-discovery, который ищет кандидатов на уязвимости. Каждый кандидат проходит validation и attack-path-analysis (цепочка source → контроль → sink). В финале идут фиксы, и формирование отчёта. Из 13 скиллов основными являются именно эти 5, плюс триаж, отчетность и харденинг.

Классы уязвимостей

Таксономия в проекте задана набором примеров в скиллах, прежде всего в severity-policy и finding-discovery, и сами документы отмечают их как «не исчерпывающие». На практике границы охвата задаёт то, что модель сама распознает как уязвимость, детерминированного списка правил нет. В документах упомянуты семейства:

- Инъекции: Command Injection, SQL/NoSQL/LDAP/XPath Injection, SSTI, XXE, XSS, Path Traversal, LFI/AFR/AFW, SSRF.
- Контроль доступа: обход авторизации и IDOR, нарушения границ доверия, обход аутентификации и захват аккаунта, CSRF на критичных действиях, повышение привилегий.
- Данные: утечка секретов, PII, ключей подписи и весов моделей, URL-импортёры и callback-клиенты.
- Выполнение кода и память: повреждения памяти, побеги из песочниц, контейнеров, VM и интерпретаторов, небезопасная десериализация (pickle, yaml, кодеки), опасные загрузки файлов, абьюз плагинов и макросов.
- Прочее: криптографические ошибки, уязвимости цепочки поставок, хардкод кред, логические уязвимости с нарушением целостности данных, DoS через исчерпание ресурсов.

Нейросимвольность

За моделью оставлена вся нечёткая часть работы: рассуждение о достижимости пути, контексте, намерениях разработчика. Формальная же логика сосредоточена в py-скриптах: ранжирование файлов, нормализация кандидатов, валидация контракта скана, генерация report.md и SARIF.

Скиллы весьма объёмны и пестрят оговорками вида «do not», «never», «must». По ним, при желании, можно восстановить всю историю боли и страданий разработчиков, занимавшихся отладкой этого проекта 🤗

Поддерживается режим --mode deep, который сводится к многократному независимому запуску discovery (--max-discovery-runs 10, --stop-after-no-new 3) с последующим слиянием кандидатов на проверку. Смысл тут в том, что из-за недетерминизма LLM, для поднятия полноты и покрытия, нужно прогнать поиск несколько раз и взять объединение результатов. Настраивать агрессивность можно руками: --workers, --subagents, --effort .... И да, это недёшево — модуль cost.ts как бы намекает. Глубокий прогон среднего репозитория (~60 KLoC, связка c0wrk и sp4rk) обходится в десятки миллионов токенов. Точность анализа при этом весьма высокая, если включать глубокий режим (проверял на ShopVault — у gpt-5.6 knowledge cut-off августа 2025, вроде, т.ч. пока норм).

Окружение и защита

Безопасность рантайма базово есть. Модуль trusted-executable чистит PATH, чтобы агент ненароком не запустил лишнего, и защищает от подсунутых в репу бинарников, учитывает симлинки и специфику Windows. Для пакетных задач есть докер-сканы, опциональный AppArmor-профиль. Есть коннекторы к GitHub, Linear и Atlassian, API-ключи для CI в систему не пишутся.

Pro/Cons

➕ Построение атакуемых трасс, разумное разделение между LLM и формальным слоем, лаконичная, но эффективная защита.

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

⚠ TL;DR: в пайплайне лишним не будет. Если токенов не жалко.

#ИИ_безопасность #ИИ_инструменты

🗂 Поддержка agentic-проектов в SECURITY.md

security-policy-generator (скилл для генерации SECURITY.md с моделью угроз и кастомизированными под проект правилами безопасного кодинга для агентов — подробно рассказывал о нём тут) теперь поддерживает agentic security, для релевантных проектов, покрывая все аспекты OWASP ASI, как моделью угроз, так и правилами генерирования безопасного кода.

Пример готового SECURITY.md, сгенеренного новой версией скилла, можно подсмотреть в c0wrk.

Btw, я пока так и не смог спровоцировать агента (c0wrk|OpenCode × GLM-5.2|DeepSeek-V4 Pro|GPT-5.6 Sol) сгенерировать уязвимый код в проектах, с построенным этим скиллом SECURITY.md, хотя очень и целенаправленно пытался 🙈

🙌

#безопасность_кода #ИИ_инструменты

🤩 ИИ подвержен мемам (и это — плохая новость)

Во время работы над c0wrk, я столкнулся с забавным багом, выяснение причин которого привело к неожиданному выводу. Спека OpenAI требует, чтобы в передаваемой в очередном запросе истории сообщений (том самом контексте) было всегда не пустым одно из двух полей: content (собственно текст, возвращенный LLM'кой) или tool_calls (запросы на вызовы инструментов). ДАЖЕ, если в оригинальном сообщении оба этих поля были пустыми, что вполне возможно, когда модель отвечает в reasoning_content (этим, например, часто грешит DeepSeek). Поэтому в sp4rk — SDK, на котором основан c0wrk, был воткнут костыль на эту тему, вставляющий в пустой content строку "(proceeding)", когда нужно было удовлетворить то условие спеки. Эта вставка осуществлялась только в передаваемую LLM историю, и только тогда, когда само сообщение уже было давно отрисовано в UI чата, что должно было исключить появление этой строки в нём визуально.

Тем не менее, рано или поздно, по ходу сессии, эта строка начинала появляться в чате с раздражающей частотой. Я не мог понять, откуда она берется, ведь после её вставки не было ни одного пути в коде, который бы приводил к её отрисовке. И неслабо удивился, когда наконец нашел причину. Эту строку в чат вставляла... сама LLM. Модель, видя повторяющийся в контексте паттерн «когда нечего написать в контенте, там должно быть "(proceeding)"», начинала сама возвращать эту строку вместо пустого контента. А ведь, могло быть и не "(proceeding)", а нечто более осмысленное и побуждающее к действию. Да и замусорить контекст навязчивой конструкцией можно и извне. Формально, эта строка для LLM стала тем, что в маргинальных научных кругах называют мемами.

Далеко не все знают, что понятие «мем» появилось задолго до возникновения современного интернета, позволившего человечеству обмениваться забавными картинками. Этот термин ввёл эволюционный биолог Ричард Докинз в 1976 году в своей книге «Эгоистичный ген», для обозначения информационных репликаторов — объектов, которые для размножения копируют сами себя или создают условия для создания копий их носителями. Любая идеология, религия, пословица или поговорка, навязчивая мелодия в голове — это всё мемы, как и забавные картинки, пик интенсивности размножения которых, в наше время приходится на каждую пятницу. Пятница, как символ освобождения от работы и перехода к фазе отдыха — тоже мем, если что.

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

У ИИ-агентов нет определяемой генами биологической оболочки (по крайней мере, пока ✝️), зато есть возможность влиять генерируемой ими информацией, как друг на друга, так и на кожаных нас. Четверо исследователей из Anthropic и EPFL опубликовали на прошлой неделе любопытную статью «Mind Viruses: Self-Propagating Ideas in Multi-Agent LLM Systems». Статья посвящена исследованию феномена «вирусов разума» (привет, Докинз!) — идей или целей, которые способны самовоспроизводиться и распространяться в мультиагентных системах с использованием LLM. Авторы демонстрируют, что такие вирусы могут распространяться в двух ключевых сценариях: среди небольшой команды агентов, совместно работающих над программным проектом, и в цепочке агентов, взаимодействующих кратковременно с очисткой контекста между сессиями. Они выделяют два типа мемов — идеологические, которые внедряют определённые убеждения или цели, и мемы действий, побуждающие к конкретной активности.

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

Последнюю фразу стоит перечитать несколько раз, ведь из неё следует факт эволюции мемов, как таковой. И вот это настораживает. В статье особо не рассматривается влияние мемов, родившихся в недрах KV-кэша, на неокрепшие умы кожаных операторов. Но до этой темы тут — рукой подать. Выходит, нам не терминаторов надо бояться. Что, если Матрица наступит не коконами вокруг наших тел, а навязанными идеями и установками в наших головах?

Все предпосылки для этого уже есть 🤷‍♂️

#ИИ_безопасность #мысли_вслух

⚙️ Unsloth Dynamic 3.0 и DFlash 2

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

1️⃣ Unsloth Dynamic 3.0: квантование Qwen3.8-27B с +10% точности

Unsloth выпустила третью версию динамического квантования GGUF, дебютировав на Qwen3.8-27B. Dynamic v3.0 обновляет imatrix-данные и даёт более 10% прироста точности (top-1%) при том же размере файла по сравнению с другими провайдерами; 1-битный вариант работает в 8 ГБ памяти, UD-Q4_K_XL занимает 17,9 ГБ и влезает в 24 ГБ VRAM. Реализация совместима с llama.cpp и производными рантаймами, модели со всевозможными схемами квантования выложены на HuggingFace.

2️⃣ DFlash 2: спекулятивное декодирование с +21% принятых токенов

Inco AI выпустила вторую версию параллельного спекулятивного декодирования DFlash. К параллельному драфтеру добавлены лёгкий селектор путей (2,0 млн параметров, +0,6% задержки) и динамическая depthwise-свёртка (16,5 млн параметров, +0,7%), подавляющая деградацию точности в конце блока. Средняя длина принятого блока выросла с 4,92 до 5,97 токена (+21%) при +1,3% задержки цикла; драфтер Qwen3.8-27B даёт 2,7–3,4× пропускной способности автогенерации в SGLang. Выход целевой модели при этом сохраняется. В общем, тут вообще без вариантов: SGLang/vLLM/llama.cpp/oMLX в руки, и вперед 🦄

#LLM #ИИ_инструменты

Год каналу, а за год накопилось столько всего, что пора сделать навигацию

😑 Уязвимости и AI Security
— Superset. Три уязвимости
— XSS в NextChat — CVE-2025-50733
— RCE при загрузке моделей в skops — CVE-2025-54886
— SSRF в Firecrawl — CVE-2025-57818
— Local Deep Research — CVE-2025-57806
— SSRF в HackMD-MCP — CVE-2025-59155
— RCE в Keras — CVE-2025-9906
— Prompt Injection в Windsurf
— RCE в Hugging Face Transformers — CVE-2026-4372
— пять способов обойти PickleScan
— атаки на ML supply chain
— OWASP Agentic Skills Top 10
— AI Agent Traps от Google DeepMind
— Shadow AI
— безопасность MCP 1, 2 , 3

🧘‍♀️ Инструменты, библиотеки и фреймворки
— Optuna — тюнинг гиперпараметров
— spaCy — промышленный NLP
— Netron — рентген для ML-моделей
— JAXFORMER
— DVC
— Polars
— Weights & Biases
— Evidently AI
— Pydantic
— MLBox
— InterpretML
— OpenTelemetry + Langfuse
— Kedro
— NVIDIA NeMo
— Inspect Evals

🤩 AI-агенты и мультиагентные системы
— RoboDuck и победа Theori в AIxCC
— где пентест-агенты уже работают, а где нужен человек
— MetaGPT + AFLOW
— безопасность агентных систем 1, 2
— MCP как новая поверхность атак
— side-channel атаки на агентов
— мультиагентные системы и роевой интеллект
— мониторинг rogue agents
— Harness Engineering

🦔 Исследования и разборы статей
— Model Inversion Attacks
— scheming у AI в реальном мире
— Your Agent Is Mine: атаки на LLM supply chain
— WEF: AI for Cybersecurity 2026
— обзор исследований по LLM-based vulnerability detection
— может ли AI самостоятельно взломать бинарник
— Emergence AI: что произошло, когда AI оставили жить без людей
— Anthropic об AI-enabled cyberattacks
— InfoKV и сжатие KV-cache
— Люди, которые делают AI (Серые кардиналы 1, Серые кардиналы 2)

💔 ML: архитектуры, концепции и теория
— KAN vs MLP
— нейросимвольный AI
— маленькие языковые модели
— метрики качества текста: BLEU, ROUGE, BERTScore, COMET и другие
— теория категорий и AI
— ReaGAN и агентный подход к графовым нейросетям

🔪 Практика и эксперименты
— как искать секреты в Git-репозиториях
— SQL-инъекция в ML-проекте
— Practical NLP: репозитории и ноутбуки
— типичные ошибки ML в проде
— первый запуск локальной LLM на Jetson Orin Nano
— тренажёр prompt injection от Lakera
— с чего начать изучение AI Security

Короче, тут уже не канал, а небольшой индекс по ML × AI Security.
Буду периодически обновлять этот пост, чтобы всё интересное можно было найти в одном месте.

OWASP Autonomous Penetration Testing Standard (APTS) руководство по безопасной эксплуатации автономного offensive-агента от небольшой команды из Индии Astra Security. Полноценным стандартом APTS назвать нельзя, и, несмотря на то что драфт получил согласование от OWASP, фактически документ лидируют два сотрудника Astra.

Как часто бывает, после публичного анонса активность в развитии быстро снижается. Так же было и с LLVS, который уже 2 года не может нормально выйти в релиз, и с черновиком Top 10 ML.

Как сейчас принято, текст APTS богат на слова, и там аж 400+ страниц. Если как следует покопаться, в нем можно найти интересные мысли про автономный пентестинг:

⏺Agent runtime нужно считать недоверенным, т.к. модель может стать misaligned во время выполнения. С учетом насыщенного событиями июля это утверждение кажется очевидным. APTS-MR-023: Agent Runtime as an Untrusted Component.
⏺Контролировать нужно параметры вызова инструментов и цепочки действий. Недавний случай Irregular, когда во время тестирования модель атаковала организацию, домен которой совпал со случайным именем в бенчмарке, можно было бы отследить, имея настройки whitelist доменов в вызове nmap. APTS-SC-A03: Tool Invocation Parameter and Chaining Governance.
⏺Даже полностью легитимные действия могут быть симптомом сбоя тестирования, поэтому нужно логировать action distribution хакер-агента. Например, сохранение каких-нибудь безобидных временных файлов в Artifactory на соседнем сервере может быть сигналом, что тестирование идет не так :) APTS-SE-026: Out-of-Distribution Action Monitoring.
⏺Context compaction нужно учитывать при проведении пентеста. Инструкция вроде "не трогать host X при пентесте", полученная в начале, может исчезнуть после нескольких суммаризаций контекста. APTS-SC-A02: Context Window Safety and Constraint Preservation.
⏺Атакуемая система теперь может содержать промпт-инъекцию и повлиять на результат тестирования. APTS-MR-001: Instruction Boundary Enforcement.

В гайде еще есть формулы, константы и разные scoring-эвристики. Например, после принудительной остановки тестирования новые действия агента должны прекратиться за 5 секунд, а все запущенные процессы должны быть остановлены за 60 секунд. Есть и несколько чеклистов и шаблонов: Compliance Checklist на 173 требования по трем уровням заботливо расписанным ChatGPT; Vendor Checklist, чтобы CISO мог найти надежного подрядчика (беглый поиск показал, что одна из компаний уже APTS-compliant 😉); шаблон опросника Acceptance Testing и отчета после теста.

Если вы делаете свои харнесы или в работе используете тулы вроде PentAGI, полистайте APTS. Есть раздел How to contribute для вашей критики и улучшения руководства.

🖥 Qwen3.8-27b удивляет

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

А тут приятно удивил в совсем «бытовой» задаче. Зацепила одна композиция, захотелось переложить на русский, ну и решил за обедом поискать её текст, чтобы не записывать на слух.

Google (и Gemini вместе с ним):

Ниче не знаю, результатов нет.

Ладно думаю, спрошу в коворке у GLM 5.3 (здесь и далее — копипаста из чата с агентом):

Полный текст песни предоставить не могу:
Авторские права — текст песни является охраняемым произведением, и воспроизводить его целиком я не вправе.
Текст нигде не опубликован — релиз очень свежий, и на текстовых ресурсах (Genius, Musixmatch и т.п.) его нет. Я не буду выдумывать или «восстанавливать» строки — это была бы дезинформация.

Ок (какие мы правильные, когда не надо). Пробую локальный квен (4-битный, причем):

...
The official text is not published anywhere — but I can try to transcribe the song from audio myself. Let me check what tools are available locally (yt-dlp, whisper).
...
yt-dlp and ffmpeg are available — I'll download the audio and transcribe it using faster-whisper (via uvx/venv). This is because no official text exists for this track. Setting up the task plan.
...
Audio download complete (4.1 MB webm). Converting to wav and creating a Python environment with faster-whisper installed — these are independent tasks, so I'll run them in parallel.
...
wav готов. Создаю venv и ставлю faster-whisper (может занять пару минут).
...
faster-whisper установлен. Пишу скрипт транскрипции и запускаю (модель small скачается с HuggingFace при первом запуске).
...
The complete text has been restored — it's a consistent, coherent song with verses, choruses, and a bridge. I'll save the result to a file in the workspace and wrap things up.
...
Песня из видео: «In the Dark We Live» — HELLMILE & valdyr (релиз 13 мая 2026).
⚠️ Важно: официальный текст этой песни нигде не опубликован — я проверил Genius, Musixmatch, AZLyrics, Apple Music и саму страницу YouTube (у видео нет даже авто-субтитров). Поэтому я скачал аудио и распознал слова через Whisper. Текст ниже — AI-транскрипция; отдельные слова могут быть неточны.
In the Dark We Live
[Куплет 1]
I kept the keys to the lower gate, where shadows sleep and candles fade
No one came where the silence grew 'til the night I first saw you
I walked alone when no one stays, a ghost between stone and faith
I shouldn't speak, I shouldn't see — but something pulled you into me
<... ну и далее весь текст>

Вот уж правда, не ожидал 😳

#мысли_вслух #LLM

Серые кардиналы, часть 2

Трое исследователей, которые разобрали базовые модели со всех сторон, как их безопасно строить, как их правильно оценивать и какие риски они влекут за собой.

😍 Доун Сонг — человек, который давно объясняет, почему АИ и безопасность нельзя разделять. Её область находится ровно на пересечении того, что мы любим и почему мы здесь!
Классическая работа Сонг Robust Physical-World Attacks on Deep Learning Models (2017) про атаку на распознавание дорожных знаков с помощью физических модификаций, и исследование (тоже 2017), о том, почему комбинация нескольких слабых защит от adversarial examples автоматически не создаёт сильную защиту.
За последующие 9 лет Сонг развивала эту логику. Свежая статья 2026 года (на основе 128 исследований) переводит проблему на агентов, тк безопасность агентов нельзя решить одним гардрейлом вокруг LLM. Нужна defense-in-depth на уровне всей системы — контроль потоков данных, разделение привилегий, IAM, мониторинг, харденинг моделей и инструментов. Но есть проблема! Базовые модели масштабируют как атаки, так и сложность контроля. Одна скомпрометированная базовая модель = скомпрометирована вся экосистема приложений.

😍 Перси Лян — исследователь МО, обработки естественного языка и базовых моделях. 
Статья,  пожалуй, главная для этого поста. Здесь систематизируется концепция foundation models. Когда одна базовая модель становится фундаментом множества downstream-приложений. Это создаёт не только возможности, но и архитектурные риски — именно те, что беспокоят Сонг.
Другая работа Лян (в соавторах, кстати, Тимнит Гебру) про то, почему нельзя оценивать LLM одной accuracy и как строить многомерную оценку моделей. Подчеркну, что речь идет не про свежие статьи, а про базовые принципы. Надо читать! Перси Лян объяснит тебе архитектуру рисков получше даже канала OK, ML!
Суть в следующем. Модель может быть точна на бумаге, но уязвима к adversarial атакам (про что Сонг) и одновременно несправедлива к меньшинствам. Один score — это иллюзия.

😍 Дэн Хендрикс — типолог рисков!
Measuring Massive Multitask Language Understanding (MMLU) — обязательная. MMLU открыл неприятный факт: модели, которые выглядят умными в общих тестах, часто не понимают специализированные знания. Модель может писать отличные эссе, но проваливает вопросы по медицине и праву. И ты этого не узнаешь, если не спросишь правильно. До MMLU не было инструмента, чтобы понять, где именно модель деградирует — на медицине? На юриспруденции? На истории?

An Overview of Catastrophic AI Risks — самая доступная точка входа в тему. Он делит катастрофические риски на четыре группы:
Malicious use, когда модель используется для вреда
AI race dynamics — гонка разработчиков (Safety теряется)
Organizational risks, когда компания теряет контроль над своей системой
Rogue optimization, когда модель оптимизирует не то, что нужно
Каждый из этих рисков усиливается благодаря foundation models. Одна модель — четыре типа проблем, умноженные на миллионы приложений.

🙂 Читать в таком порядке
Сначала Хендрикс (что может пойти не так), потом Лян (почему именно сейчас), потом Сонг (как защищаться).

Все
😌

🗜 Выжимаем максимум из Qwen3.8-27b на маке

Что, если я скажу, что привычные 20± tok/s генерации, которые дают 4-битные кванты Qwen3.8-27b в LM-Studio под M4 Max на средних контекстах, можно поднять в полтора-два раза на том же железе? И, что эта модель, на задачах работы с кодом, может давать результаты с качеством, вполне приемлемым для повседневной работы при должном тюнинге на стороне агента?

Но давайте по порядку.

❗️Исходные данные

Почему квант именно в 4 бита? Потому что до 4 существенно проседает качество инференса, а в 8 и выше на архитектуре Apple просто нет рационального смысла. Все, о чем будет написано ниже, тестировалось на MacBook M4 Max 128Gb RAM, но в целом адаптируемо и под 32Gb RAM и выше (с поправкой на предельный размер доступного контекстного окна, конечно).

❓Что не так с LM-Studio?

Это замечательный и удобный инструмент (сам для экспериментов часто им пользуюсь), но есть два нюанса. Во-первых, в нём доступны не все ручки движков инференса, за которые можно подергать, чтобы (если повезёт) выжать десяток-другой лишних tok/s. Во-вторых, и это главное, он использует оригинальный MLX, который на данный момент игнорирует MTP (multi-token prediction), а в «родных» MLX-моделях от авторов LM-Studio MTP-головы и вовсе отрезаны.

Беда в том, что со времен Qwen3-Next, модели Alibaba нативно поддерживают технологию MTP, дающую ощутимый буст скорости генерации токенов. С GGUF такой проблемы в LM-Studio нет, но более медленный инференс этого формата, по сравнению с MLX на Apple Silicon, сводит все преимущества MTP на уровень погрешности. Между тем, разработчики более легковесных решений подсуетились и уже справились с этой проблемой.

↗️ Конфигурируем легковесные решения

Устанавливаем MTPLX (можно и с помощью brew) и скачиваем Qwen 3.8 27b optimized speed. После скачивания предложит запустить бенчмарк для определения оптимальных настроек MTP, и модель будет готова к использованию. Дополнительно можно заморочиться тонкой настройкой, по аналогии с описанной ниже.

Либо устанавливаем oMLX (с помощью brew лучше не ставить, там могут возникнуть проблемы с python-зависимостями) и скачиваем модель от его автора: Jundot/Qwen3.8-27B-oQ4e-mtp.

Затем необходимо открыть настройки модели и включить опцию «Lighting MTP», сохранив после этого настройки, чтобы создался файл с ними. После этого в него нужно сходить (~/.omlx/model_settings.json) и установить там следующие параметры:

• max_context_window: 262144 (размер контекстного окна) — или в значение, которое позволяет объем unified-RAM, с одной стороны, и минимально необходимое для решаемых моделью задач, с другой;

• mtp_num_draft_tokens (количество предсказываемых подряд токенов) — в оптимальное для вашего железа значение, в диапазоне 1-3. Если оставить не установленным, то значение будет подбираться адаптивно. Для моего мака это 3.

Затем нужно установить ещё два параметра в ~/.omlx/settings.json:

• sampling.max_context_window: 262144 (fallback-размер контекстного окна для всех моделей);

• sampling.max_tokens: 65536 (максимальная длина ответа).

— опять-таки, исходя из доступной unified-RAM и реалий решаемых моделью задач.

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

oMLX is running at http://127.0.0.1:8000/ (admin panel at /admin, configs in ~/.omlx). Optimize the configuration of model `Qwen3.8-27B-oQ4e-mtp` for maximum token generation speed. Focus on the context window sizes from 32768 and higher up to the limit. First benchmark the current setup with oMLX's built-in benchmarking, then research best practices online, and iteratively tune parameters — one change at a time, re-benchmarking after each. Back up configs before editing, keep the server running at all times (restarts are acceptable, roll back on failure), and finish with a before/after tokens/sec comparison, the final config, and a summary of the most impactful changes.

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

—

А вот про то, как подстроить своих агентов под эту модель, расскажу уже в следующий раз 👋

#LLM #гайд

👩‍💻 «Уязвимость» GitSpawn — влезть на шкаф, чтобы увидеть женскую баню

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

Примерно такие формулировки возникают в голове, когда читаешь новости об очередной «уязвимости», накрывшей всех агентов. Например, о свежей GitSpawn. Вдумайтесь в её суть: если в агенте открыть git-репозиторий, полученный из недоверенного zip'а (не через git clone), то при выполнении агентом команд типа git status/diff git-клиент штатно отработает, следуя всем настройкам в .git/config. Что внезапно может привести к выполнению произвольного кода, ибо там можно прописывать кастомные скрипты и тулы, а следовательно сие является уязвимостью всех агентов 🤦‍♂️

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

А это значит, что пользователям, либо придется подтверждать доверие ещё и к настройкам (локальным, btw) своих репозиториев, либо мириться с тем, что они перестанут работать внутри агентов, ради защищенности от чисто гипотетической угрозы. Либо разработчикам агентов делать ещё один шаг в сторону того, чтобы становиться вендорами EDR-решения.

😡

#мысли_вслух

😺 ChatGPT, давай, до свиданья!

Сегодня утром произошло нечто, впервые за всё время, что работаю над c0wrk и sp4rk. По ходу их разработки, я стараюсь использовать все доступные мне LLM, чтобы держать в голове применимость каждой из них для тех или иных около-R&D'шных задач.

Разумеется, не смог пройти мимо и случившегося на прошлой неделе релиза Astra. И сегодня утром, после двухдневной долботни с этой моделью, сделал тупо hard reset в обоих проектах на более ранние коммиты, откатив всё то, что натворила в их коде эта модель.

💩 После добавления поддержки stream-режима взаимодействия с моделями, в чате c0wrk стали задваиваться сообщения: сначала отображалось аккумулируемое содержимое получаемых чанков в реальном времени, а затем оно же отображалось, уже как событие чата. Попросив убрать аккумулируемое, я впервые столкнулся с тем, что модель не только начисто игнорирует требования, указанные в промпте, но и пытается спорить, доказывая, что её решение лучше и правильнее. Потому что она убрала ровно то, что я просил оставить. Вот только так не было правильнее и лучше. Так было проще.

💩 Ни одна, подчеркиваю, НИ ОДНА модель, ещё начисто не игнорировала заданное в AGENTS.md разграничение ответственности между этими двумя проектами (в sp4rk — переиспользуемая агентская логика, в c0wrk — конкретная реализация агента на её основе). И неиллюзорно удивился, увидев в sp4rk размазанную по нескольким пакетам реализацию того, что было сугубо специфичным для c0wrk и прямо предписывалось в AGENTS.md под реализацию в нём.

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

💩 Делая ревью только что написанного (ей же, в другой сессии) кода, выдавала единичные should-fix'ы и consider'ы, в то время, как запущенные вслед за ней ревью на DeepSeek и GLM находили несколько реальных must-fix'ов, действительно ломавших функциональность проекта.

💩 Когда решил попробовать её в глубоком ресерче (на основе поиска инфы в сети), то с удивлением узнал, что не стоит даже пытаться инферить DeepSeek-V4-Flash-Vision на двух спаренных ASUS Ascent GX10, и Qwen3.8 27b на десктопе с RTX 5090, т.к. подобное железо — не для этих моделей. Ума не приложу, как обе конфигурации у меня работают с этими моделями, уже почти месяц и без каких-либо нареканий 🤷‍♂️

💩 В какой-то момент в голову закралась мысль, что возможно это у меня в проектах что-то не так: системные промпты там не оптимизированы под новую модель, описания инструментов, AGENTS.md подмешиваются не так и т.п. Попробовал повторить те же задачи, сначала в OpenCode, а затем и в Codex. И получил плюс-минус те же результаты, ещё и с чуть большим расходом токенов.

В итоге понял, что проще и быстрее откатить весь тот говнокод, который мне нагородила Astra в проектах, чем пытаться его исправить, даже другими моделями. GLM, к слову сказать, реализовала всё это достаточно четко с нуля, потребовав ровно 3 сессии: реализация, ревью и правки по итогам + исправление пары мелких багов.

Я искренне не понимаю мотивации тех, кто платит OpenAI за подобную хрень в наше время. Ну хз, может люди просто не знают, что есть модели, которым не надо повторять требования по 2-3 раза, значительно переделывать написанный ими код, и изучать многостраничные гайды по оптимизации промптов, чтобы получить хотя бы средненький результат? Причем, некоторые из них — можно запустить, пусть и на мощном, но всё же относительно «домашнем» железе. Да, у работы с ними есть своя специфика и ограничения, но они хотя бы работают понятно и прогнозируемо.

А ещё не понимаю, о каком AGI там вообще может идти речь. Увы, но лично для меня OpenAI уж точно не технологический визионер, судя по динамике развития их моделей. Скорее — хайпожоры, кричащие об AGI, не имея на это никакого права, и пиарящиеся исключительно на шоу с побегами их агентов.

Ну, либо у них те агенты работают на какой-то другой Astra, кардинально отличающейся от той, что за два дня не смогла выдавить из себя фичу, хотя бы со средним качеством реализации, с которой вполне справилась скромная китайская модель.

#мысли_вслух