Привет, Хабр! Недавно вышло несколько интересных исследований: один ИИ-агент без участия человека автоматически готовит научную статью, другой научился управлять любыми Windows-приложениями. Появились методы, позволяющие сотням симулированных пользователей выявлять слабые места в интерфейсе; платформа, где герои знакомых романов превращаются в ИИ-агентов и создают новые сюжеты; а также симуляция соцсетей, в которой сотни ИИ-юзеров читают посты, лайкают, репостят и проверяют фейки.

Если хотите быть в курсе новейших исследований в области искусственного интеллекта, воспользуйтесь Dataist AI - бесплатным ботом, ежедневно обозревающим свежие научные публикации, а также подписывайтесь на мой Telegram-канал, где я рассказываю про создание ИИ-стартапов и реальные кейсы внедрения ИИ в бизнес. Поехали!

1. Новая малая языковая модель: Phi-4-Mini-Reasoning

Производительность Phi-4-Mini-Reasoning на математических бенчмарках

В апреле команда Microsoft представила Phi-4-Mini-Reasoning – языковую модель с 3,8 млрд параметров, способную по точности решения сложных математических задач обойти более крупные аналоги (7–8 млрд параметров). Авторы описывают четыре этапа обучения, каждый из которых вносит свой весомый вклад:

  1. Синтетическая дистилляция. Модель скормили 10 млн синтетически сгенерированных цепочек рассуждений, основанных на 1,6 млн задач из публичных датасетов. Благодаря этому CoT (Chain of Thought) компонент получил мощный импульс: точность модели на MATH-500 выросла с 71,8% до 82,9% (+11,1%).

  2. Supervised Fine-Tuning (SFT). Взяли набор задач университетского уровня (алгебра, геометрия, теория чисел, вероятность, интегралы и т. д.) и дообучили модель на полных рассуждениях, где модель учится вовремя завершать доказательство. Это добавило ещё +6,4% к итоговой точности, доведя её до 89,3%.

  3. Direct Preference Optimization (DPO). Вместо удаления цепочек с ошибками, эти битые примеры используются как негативные, и модель учится отдавать более высокую вероятность полностью корректным решениям. Такой подход добавил +4,3%, доведя итоговую точность до 93,6%.

  4. Reinforcement Learning с проверкой финального ответа (PPO + GRPO). Для стабильности обучения выровняли длины CoT-цепочек в батчах (prompt optimization), ребалансировали награды (oversampling тяжёлых задач и равное число неправильных ответов) и плавно снижали температуру генерации с 1,0 до 0,6. Финальный результат – 94,6% Pass@1 на MATH-500. На AIME 2024 модель набрала 57,5% (у DeepSeek-7B – 53,3%, у Llama-8B – 43,3%), а на GPQA Diamond – 52% против 49,5% и 47,3% соответственно.

Абляционный анализ показал, что ключевым является именно первый этап синтетической дистилляции, затем SFT, а DPO и осторожный RL лишь доводят модель до идеала. Особенно интересно то, что неправильные примеры не выбрасываются, а становятся топливом для Preference Learning, а выравнивание CoT и контроль длин гарантируют стабильность PPO. В итоге компактная модель решает университетские математические задачи быстрее и дешевле, чем её более тяжёлые коллеги, что открывает путь к применению SLM (Small Language Models) напрямую в мобильных устройствах.

📄 Статья
🤖 Модель

2. Автоматизируем научный конвейер с The AI Scientist v2

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

Исследователи попытались решить ещё более амбициозную задачу: AI Scientist-v2 должен сам придумать идею, сформулировать гипотезу, сгенерировать код, запустить серию экспериментов, нарисовать графики, написать рукопись и пройти независимое рецензирование. Причём без человеческого вмешательства.

AI Scientist-v2 включает генерацию идей, запуск экспериментов, визуализацию, написание и рецензирование статьи. В отличие от первой версии, система не использует шаблоны, написанные человеком, а с помощью agentic tree search и модуля Experiment Progress Manager сама генерирует и уточняет код. Лучшие версии используются для пошаговой проверки гипотез.

Ключевые новшества:

  • Agentic Tree Search под управлением Experiment Progress Manager — параллельное разветвление и углубление гипотез вместо линейного прохода.

  • Встроенная Vision-Language Model (VLM) проверяет каждый рисунок: есть ли подпись, читабельна ли ось, совпадает ли рисунок с текстом.

  • Проверка идеи на новизну идёт через Semantic Scholar, а итог оценивают рецензенты ICLR 2025.

Этапы работы The AI Scientist v2
  1. Генератор идей за пару итераций рождает десятки направлений внутри темы.

  2. Experiment Progress Manager разбивает работу на 4 стадии: первичный скаутинг, тюнинг гиперпараметров, основную программу и абляционные прогоны.

  3. На каждой стадии agentic tree порождает узлы-варианты. "Buggy"-узел ловит ошибку, сохраняет стектрейс и уходит в отладку; "non-buggy" идёт дальше.

  4. LLM-оценщик отбирает лучшую ветку по метрике качества, времени и новизны.

  5. Итоговый результат проходит VLM-ревью (оценка визуально-языковой моделью).

Весь этот пайплайн живёт на GitHub-репозитории и принимает датасеты через datasets.load_dataset, будь то MNIST, CIFAR-10. Одновременный запуск до 128 узлов позволяет за ночь перепробовать тысячи конфигураций — руками такое не осилить.

Чтобы проверить концепцию, система без помощи людей написала три статьи и подала их на ICBINB-воркшоп. Итог — одна работа («Compositional Regularization») получила оценки 6-7-6 и вошла в верхние 45% заявок. Две другие провалились: рецензенты нашли дубликаты графиков, слабую мотивацию и пропущенные ссылки.

Одна из статей, сгенерированных AI Scientist-v2, прошла рецензирование на воркшопе ICBINB

AI Scientist-v2 впервые показал, что полностью автономная система способна пройти peer-review, экономя недели рутинной работы. Но риски — от галлюцинаций LLM до этических вопросов авторства — никуда не делись. Оптимальный путь — гибридная работа: ИИ занимается рутиной, а человек проверяет текст, графики, ссылки. Следующий шаг — встроить узкоспециализированные модули (биология, физика) и честно маркировать ИИ-контент.

📄 Статья
💾 Код

3. Переводим научную статью в код: Paper2Code

PaperCoder доказывает, что LLM-агенты уже умеют писать рабочие репозитории по свежим ML-статьям. Авторы начали с тревожной статистики: в 2024 году лишь 19,5% работ на ICLR, ICML и NeurIPS приложили код. Остальные 80% оставили исследователей без инструмента для проверки результатов. PaperCoder накидывается на эту проблему и показывает, как координация LLM-агентов превращает PDF в GitHub — почти без участия человека.

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

Система делит пайплайн от статьи до кода на три этапа:

  1. Планирование. Агент извлекает ключевые сущности статьи, строит карту проекта и дерево файлов.

  2. Анализ. Для каждого файла формируется детальное ТЗ с классами, функциями и параметрами.

  3. Программирование. Финальный агент пишет файлы по порядку зависимостей, опираясь на уже созданные модули и config.yaml.

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

Наивный подход: LLM сразу пытается сгенерировать весь репозиторий из текста статьи, а PaperCoder делит задачу на три этапа

Авторы собрали Paper2CodeBench (90 статей) и PaperBench Code-Dev (20 статей). На первом датасете PaperCoder взял 3,68–3,83 балла из 5 в reference-based и 4,73–4,77 в reference-free, оставив позади ChatDEV и MetaGPT. Разрыв с наивным Paper-baseline ≈ 0,6 балла.

На PaperBench Code-Dev система воспроизвела 45–51% экспериментов, тогда как базовые агенты не дотянули до 35%. Главное — код почти исполняем: в пяти случайных репозиториях исправления требовали всего 0,81% строк. Типовые патчи — сменить устаревший вызов OpenAI API или добавить trust_remote_code в HuggingFace.

С инженерной точки зрения PaperCoder похож на CI/CD-пайплайн: статья играет роль Pull Request, а тестами служит возможность воспроизвести результаты. Поэтому система настойчиво расставляет приоритеты: сначала интерфейсы, затем модели, потом training loop, и лишь после этого скрипты запуска.

Следующий шаг — встроить PaperCoder прямо в процесс подачи статей на конференции. При сабмите PDF автор получает pull-request с базовой версией кода; рецензент может запускать эксперименты, оргкомитет — проверять воспроизводимость. Уже обсуждается пилот на ICLR-2025: если тест пройдёт, то пожелание прикрепить код к статье станет правилом.

📄 Статья
💾 Код

4. Управляем Windows с Desktop AgentOS UFO

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

  1. Хрупкость — до 30% скриптов отваливаются после незначительного редизайна.

  2. Медленное выполнение — каждый клик = отдельный вызов LLM, десятки секунд задержки.

  3. Плохой UX — скрипт отбирает рабочий стол, мешая человеку работать.

Сравнение существующих CUA (Computer-Using Agents) и Desktop AgentOS UFO

Команда Microsoft поставила задачу вывести автоматизацию из прототипа в рабочий инструмент для ОС. Итогом стала система UFO — Desktop AgentOS для Windows, в которой:

  • агенты понимают, как автоматизировать UI и API приложений;

  • многопоточная архитектура HostAgent + AppAgents гарантирует изоляцию сбоев;

  • пользователь и агент работают параллельно в окне «картинка-в-картинке».

Иерархия «диспетчер + исполнители» делает систему масштабируемой: добавляем новый AppAgent — и все сложные цепочки автоматически начинают использовать свежую экспертизу:

Общая схема UFO: сверху HostAgent разбирает задачу, снизу пул AppAgent-ов. Такое разделение позволяет работать параллельно и сократило среднее время сессии до 58с

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

Детали HostAgent: он видит процессы, запускает нужное приложение и записывает все на доску. Благодаря явному плану маршрутизации число ошибок распределения упало на 30%

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

FSM HostAgent — пять состояний: CONTINUE → ASSIGN → PENDING → FINISH или FAIL. Чёткая логика ловит тупики; авторестарт удаётся в 92% случаев без участия человека

Получается маленький плагин, который знает тонкости Excel или Word и при этом говорит на одном языке с центральным диспетчером:

AppAgent — мини-рантайм для одного приложения

Практика показала: чистой автоматизации UI хватает далеко не везде, а чистого vision-парсинга — ещё реже; гибридный вариант закрывает оба пробела:

Гибридный детектор: сначала автоматизация UI, потом OmniParser-v2. Control-Recovery-Ratio вырос с 0 до 9,9% — именно столько невидимых элементов теперь гарантированно находится

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

Puppeteer решает, что быстрее: API или клик. При экспорте Excel-таблицы один save_as заменил 5 GUI-действий и ускорил операцию с 11 до 3 секунд

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

Подложка знаний: векторный поиск по мануалам и логи успешных запусков. Через неделю база дала +11% к успешному завершению редких задач в Word

Модель думает, а валидатор отсекает ошибки на лету, итог — меньше задержек:

LLM сразу предлагает пакет шагов, валидатор отбрасывает лишнее. На OSWorld-W число вызовов модели сократилось вдвое, а ценник — на 51,5%

Благодаря PiP-сессии роли чётко разделены: агент тихо делает своё дело в окне, а человек — свою работу на основном экране:

Окно PiP — отдельный виртуальный рабочий стол. Пользователь продолжает работу, а скрипт не отбирает курсор; за три недели тестов не было ни одного конфликта

Человеку оставили «красную кнопку» — последнее слово всегда за ним, если действия потенциально опасны:

Перед удалением файлов или изменением реестра агент спрашивает подтверждение. В 7% сценариев это спасло данные тестеров; фатальных потерь нет

Так UFO превращается в платформу: любые внешние агенты можно подключить и сразу получить буст за счёт общей структуры:

Registry: сторонний OpenAI Operator обёрнут в 15 строк кода и стал AppAgent-ом. Под управлением HostAgent его SR вырос с 20,8% до 26%

Разделение легковесного клиента и «больших мозгов» упрощает DevOps-жизненный цикл и снижает риски утечки моделей:

Клиент-сервер: лёгкий клиент 20 МБ делает скриншоты, облачный сервер ведёт логику и LLM. Админы довольны: обновления ставятся централизованно, без походов к ПК

Долой чёрные ящики: каждый шаг прозрачен, а логи читаются в любом редакторе:

Markdown-логгер: после сессии создаётся файл с промптами, CoT и скриншотами. Разбор бага сократился с 40 до 12 минут

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

LLM-судья читает журналы, применяет CoT и ставит оценки. 94% автоматических вердиктов совпали с мнениями экспертов

Рабочий пример, как переход к API снижает и время, и риск — особенно после патчей приложений:

Кейс с CSV: GUI-скрипт — 5 кликов, 14с и сбой после обновления Office; API-вариант — 1 вызов, 3с без ошибок

Что по результатам? На самом сложном наборе данных OSWorld-W агент закрыл 28,6% задач — вдвое выше ближайшего преследователя.

Веб-браузер: здесь система буквально развернулась. 40% успешных сценариев - это влияние сразу двух факторов: гибридный детектор уверенно ловит кастомные HTML-кнопки, а Puppeteer умеет дергать JavaScript-API.

Кодинг с IDE: самый заметный рекорд. UFO закрыл 58% задач с GPT-4o. Для среды, где окна, панели и всплывающие подсказки меняются еженедельно, это почти магия. Ключевая фишка — RAG: агент вытаскивает свежие хоткеи и команды из документации VS Code или PyCharm прямо во время работы.

Windows-системные утилиты: 45 % успеха, +16% к лучшему старому CUA. Тут решает глубокая автоматизация UI: стандартные контролы хорошо размечены, агент кликает без визуальных догадок и почти не ошибается.

Медиа и видео: скользкий лёд. Всего 38% с мощной о1. Причина проста: видеоплееры и редакторы часто рендерят интерфейс с DirectX, а автоматизация UI тут не поможет, OmniParser угадывает не всё. Это направление для будущей работы.

Офисные пакеты: здесь цифры разошлись: старый LibreOffice в WAA дал лишь 4–7%, а Microsoft 365 в OSWorld-W шагнул до 52%. Команда уже ведёт переговоры с The Document Foundation, чтобы включить больше UI-меток в будущие билды LibreOffice.

Кросс-приложения: тяжёлый кейс: «собери данные в Excel, вставь в Outlook и прикрепи PDF». 9% успеха кажутся скромными, но это втрое выше любого базового агента. Здесь главный ограничитель — долговременная координация. Тут авторы будут работать с долговременной памятью в HostAgent, чтобы он помнил контекст на десятки минут.

Как итог, UFO убедительно доказывает, что переход от кликов по пикселям к OS-native автоматизации даёт двукратный рост надёжности и половину экономии на вызовах LLM. Главные задачи на следующий этап — портировать подход на Linux/macOS и снизить стоимость инференса через компактные модели, не потеряв в прозрачности и безопасности.

📄 Статья
💾 Код

5. Мультимодальный UniversalRAG

LLM умеют отвечать на самые разные вопросы и вести диалоги, но порой выдают неточные или устаревшие факты, если тема выходит за рамки их области знаний. Чтобы исправить это, используют Retrieval-Augmented Generation (RAG): модель достает фрагменты из внешней базы и генерирует ответ, опираясь на них. Однако классические RAG-решения обычно работают только с одним типом данных (например, текстом) и фиксированными чанками (например, абзацами). Между тем запросы пользователей могут требовать короткие факты, визуальную информацию (форму или цвет) из изображений, динамику или инструкции из видео, и при этом как мелкие фрагменты (абзац, кадр), так и целые документы или ролики.

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

(А) RAG с одной модальностью не справляется с запросами по другим типам данных. (B) RAG с единой детализацией либо даёт слишком мелкую, либо слишком грубую информацию. (C) RAG с единым корпусом всех данных смещает выдачу в пользу той модальности, которой задан запрос. (D) UniversalRAG решает эти проблемы, используя маршрутизацию по разнообразным корпусам с учётом модальности и уровня детализации.

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

  1. Разбиение корпусов на субкоркусы: тексты в виде абзацев и целых документов, изображения и видео (клипы и полное видео).

  2. Маршрутизатор (Router) на базе DistilBERT решает, к какому субкорпусу обращаться: никакому, к абзацу, документу, изображению, клипу или полному видео.

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

  4. Генератор (LVLM) Модели InternVL2.5-8B, Qwen2.5-VL-7B или Phi-3.5-Vision-Instruct создают финальный ответ, учитывая запрос и выбранный фрагмент.

На восьми бенчмарках UniversalRAG показал устойчивое преимущество над другими методами RAG и подходом с единым корпусом. Чем больше модель, тем лучше рост результатов.

Результаты разных RAG-методов

UniversalRAG удачно решает две ключевые задачи RAG: работает с разными типами данных и гибко меняет объемы контекста. Это важно для виртуальных помощников, образовательных систем и аналитики. Дальнейшие работы направят на улучшение маршрутизатора для неизвестных типов данных, снижение вычислительных затрат и расширение новых модальностей (аудио, 3D, графы).

6. Симуляция юзабилити-тестирования с UXAgent

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

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

Исследователь описывает идеальную персону и распределение демографии. Дальше генератор создаёт 60+ виртуальных покупателей с разными целями и вкусами. Каждого ведёт связка двух циклов: Fast Loop реагирует на интерфейс почти в реальном времени, а Slow Loop периодически думает, сверяя действия с мотивами.

Архитектура LLM-агента включает два цикла: Fast Loop для быстрой работы с вебом и Slow Loop для глубокого размышления.

Всё, что агент видит и делает, пишется в единую память, а сайт к агенту подключается через упрощённый HTML-коннектор.

Universal Web Connector превращает исходную веб-страницу в упрощённую HTML-структуру с иерархическими именами для всех интерактивных элементов, а модуль Perception создаёт по ней описательную память наблюдений.

60 агентов отправили на WebArena: 45 оформили покупку, средний чек — $57,5, средняя сессия — 9,26 клика. Пятерым UX-исследователям (20–30 лет, опыт 1–6 лет) дали 40 минут поиграть с реплеями, логами мыслей и чат-интервью. Итог: доверие 3,6/5, полезность 3,4/5, прозрачность данных 4/5.

Интерфейс интервью агента: исследователь UX выбирает LLM-персону для проведения качественных интервью

Инструмент полезен тем, что за вечер можно прогнать десятки сценариев без найма дополнительных UX-исследователей. Агенты исследуют слабые места интерфейса, и она уже не похожа на игрушку, а близка к полноценным A/B-тестам: меняете параметры симуляции — и смотрите, как меняются метрики. Пример на видео:

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

📄 Статья
💾 Код

7. А/B-тестирование с ИИ-агентами

Сколько раз вы откладывали идею новой фичи, потому что для ее проверки нужны тысячи пользователей и несколько месяцев на эксперимент? Исследователи предложили обход: вместо людей в браузер запускают армию LLM-агентов и получают необходимую статистику уже через пару часов.

Рабочий процесс веб-A/B-тестирования и три проблемы: высокая стоимость и сложность привлечения значительного трафика для достоверных результатов, тестирование может растягиваться на недели и месяцы, ограниченные возможности для проведения тестов

1 000 виртуальных покупателей, созданных Claude 3.5 Sonnet, получают разные личности — от студента до обеспеченного гурмана. Половина видит обычную колонку фильтров на Amazon, другая — обрезанный список с релевантными опциями. Агент читает JSON-слепок страницы, решает, куда нажать, а Selenium жмёт кнопки за него. Лимит — 20 шагов; параллельный запуск на 16 узлах закрывает тест за вечер.

Архитектура AgentA/B. Система принимает от пользователя информацию об агенте и спецификации тестирования для автоматического: создания большого числа LLM-агентов, осуществления взаимодействия агента с заданной веб-средой, проведения пост-тестового анализа и возврата результатов конечным пользователям

Одна итерация предсказания действия проходит так:

  1. Модуль профилирования агента формирует описание агента (LLM-персона, цель пользователя и историю действий).

  2. Модуль разбора среды преобразует веб-страницу в структурированное представление и список возможных действий.

  3. Эти данные передаются LLM-агенту для предсказания следующего действия.

  4. Модуль исполнения действий запускает выбранное действие в веб-среде.

Как работает одна итерация предсказания действия

В итоге в живом тесте на миллионе сессий LLM-агенты показали конверсию 0,81%, тогда как у реальных пользователей этот показатель составил 0,62%. Иными словами, из 10 000 сессий агенты совершали покупку примерно в 81 случае, а люди – в 62.

Агенты тратили в среднем 6,05 действий (кликов или других взаимодействий) до завершения сессии, а люди – 15,96. Это значит, что агенты идут по прямой к целевому товару: они быстро находят нужные фильтры, категории и кнопки “добавить в корзину”, без лишних прокруток и переходов. Живые пользователи, напротив, часто перебирают несколько разделов, читают описания и сравнивают варианты, что увеличивает число шагов.

После внедрения алгоритма, скрывающего опции фильтрации товаров с релевантностью ниже 80%, число реальных покупок выросло на 10: с 404 до 414. При этом средний чек поднялся с $55,14 до $60,99. Получается, что новый интерфейс не только ускорил выбор товаров, но и подстегнул покупки более дорогих позиций, повысив общую выручку.

Две версии левого фильтра на Amazon.com для A/B-теста: в контрольном варианте показаны все опции фильтра, а в экспериментальном скрываются варианты с релевантностью ниже 80% к запросу

ИИ-агенты рациональны и им не знакомы импульсивные покупки, но как фильтр идей AgentA/B уже экономит недели и сотни тысяч долларов. Команда подчёркивает: это не замена конечному пользователю, живой трафик всё равно нужен, но к релизу остаётся 1-2 проверенных варианта вместо двадцати гипотез. Метод уже тестируют в ed-tech: агенты разных уровней решают задания и заранее показывают, где ученики буксуют.

📄 Статья

8. BookWorld: Многопользовательская генерация историй

- Теперь мы знаем, что живём свою жизнь в книге.
- Если то, что ты говоришь, правда, я убегу из книги и пойду своим путём.
«Мир Софии», Юстейн Гордер

Что, если знакомый нам роман оживёт и герои начнут общаться без сценариста? Именно это обещает BookWorld — система, которая превращает обычный роман в мультиагентную песочницу. Алгоритм сначала извлекает из текста профили персонажей, карту локаций и скрытые правила вроде «магия для магглов табу». Затем каждому герою выдаётся свой LLM-агент с памятью и целями, а над ними парит «мировой агент», следящий за сценами и глобальными событиями.

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

Так за один прогон формируется в среднем 4 230 слов истории, разбитых на сцены и раунды, где инициатива переходит от агента к агенту. При сравнении на пяти метриках BookWorld уверенно обходит прямое генерирование: 95,6% по погружению, 84,1% по консистентности персонажей и 91,2% по качеству текста.

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

Пока протестировано 16 романов и шесть LLM, включая Llama-3-70B. Открытые модели справляются хуже — им не хватает стилистики. Кроме того, упрощённая карта мира не позволит полноценно сыграть, скажем, в «Мафию».

Тем не менее BookWorld уже сейчас выглядит как небанальный инструмент для игр и VR, фанфик-мастерских и исследования коллективного поведения агентов. Авторы напоминают: движок не заменит писателя — он строит каркас, а финальную шлифовку текста всё равно делает человек. Зато непредсказуемые повороты сюжета ценят гейм-дизайнеры.

📄 Статья
💾 Код

9. MOSAIC: Песочница социальных ИИ-агентов

Многих волнует, как останавливать поток фейковых новостей в соцсетях. Команда из MIT разработала систему MOSAIC — это большая песочница, где вместо людей сидят ИИ-агенты, разговаривают, лайкают и шарят посты примерно так же, как настоящие пользователи. В такой безопасной модели можно проверить любые правила модерации, не рискуя реальными людьми. Работает система так:

MOSAIC - мультиагентная социальная симуляция, где агенты взаимодействуют в среде, похожей на соцсеть, формируют динамическое поведение на основе памяти и реагируют на дезинформацию через общинную, стороннюю или гибридную проверку фактов.
  1. Создание агентов. Сначала авторы собрали настоящие анкеты (возраст, интересы, ценности) и научили GPT-4o писать из них короткие биографии. Для остальных юзеров данные вытаскивали из специального набора вопросов (AgentBank) и генерировали случайно, но по правдоподобным распределениям. Каждый агент получил память: он запоминает, что постил, что комментировал, и потихоньку забывает, если воспоминание не важно.

  2. Модуль 1 «Взаимодействие». Симуляция выглядит как мини-Twitter: есть граф подписок, лента и доступные действия: лайк, репост, комментарий, подписка, игнор. Перед любым действием агент считывает ленту, вытаскивает из памяти подходящие воспоминания (интересы, недавние события) и решает, что делать, прямо в промпте. После действия новая запись кладётся обратно в память — так формируется личная история.

  3. Модуль 2 «Реакция на дезинформацию». В систему периодически подмешивают заранее помеченные фейки из базы NewsGuard. Далее запускают три схемы: Факт-чекинг сообществом (сами агенты пишут заметки и оценивают чужие), сторонний факт-чекер – отдельный LLM смотрит самые популярные посты и выносит вердикт, а также гибридный вариант.

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

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

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

📄 Статья
💾 Код

10. Generative AI Act II: Инженерия когнитивных систем

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

Акт I: Prompt-engineering (2020–2023)

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

Акт II: Cognition-engineering (с 2024-го)

Однако с 2024 года произошла смена парадигмы. Стало ясно, что LLM способны не просто выдавать ответы, но и вести полноценный мыслительный процесс. Теперь акцент сместился с того, "что спросить" на то, "как модель думает в процессе генерации ответа". Это означает, что для получения качественных результатов необходимо запускать в модели последовательность шагов мышления, так называемую цепочку рассуждений (chain-of-thought). Вместо того чтобы использовать заранее подготовленные промты, инженеры начали выстраивать когнитивные структуры, которые помогают модели не просто отвечать, но понимать и логически обосновывать свои ответы.

Этот этап обозначается как cognition-engineering. Ключевой навык теперь заключается в умении управлять когнитивными процессами модели, грамотно задавать направление её размышлений и следить за тем, чтобы шаги её внутренней логики были прозрачны и эффективны.

Чтобы понять эту трансформацию, представим пирамиду DIKW:

  • Data (Данные): Сырые факты, сигналы.

  • Information (Информация): Обработанные данные, имеющие контекст.

  • Knowledge (Знания): Примененная информация, понимание закономерностей.

  • Wisdom (Мудрость): Глубокое понимание, суждения, творчество.

Модели Акта I достигли уровня «Знаний». Они отлично справлялись с запоминанием и выдачей информации. Но Акт II, называемый «Инженерией когнитивных систем» (Cognition Engineering), стремится к уровню «Мудрости». Цель – научить ИИ не просто знать, а понимать «почему» и «как», рассуждать и даже делать открытия.

Пирамида DIKW (Data, Information, Knowledge, Wisdom)

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

  1. Pre-training (Предварительное обучение): На этом этапе ИИ скармливают гигантские объемы текстов и кода. В его «мозгу» формируются отдельные «острова знаний» – базовые концепции, но связи между ними еще слабые.

  2. Post-training (Дообучение): После предварительного обучения модель дополнительно настраивают на более специфических данных. «Острова знаний» уплотняются, между ними появляются более прочные «мостики» – связи между связанными концепциями.

  3. Test-time Scaling (Масштабирование во время решения задачи): Это сердце Акта II. Когда ИИ получает сложную задачу, он не выдает ответ мгновенно. Вместо этого он использует дополнительное время и вычислительные ресурсы для «глубоких размышлений». Он активно строит длинные цепочки рассуждений, соединяя даже отдаленные «острова знаний». Это позволяет ему находить решения для сложных проблем.

Три этапа масштабирования знаний в моделях

Для реализации глубоких размышлений во время решения задачи (test-time scaling) используются различные методы:

  1. Методы параллельного выбора примеров (Parallel Sampling): Представьте, что ИИ генерирует не один, а сразу несколько (N) вариантов ответа или цепочек рассуждений на один и тот же запрос. Затем специальный механизм (например, голосование по большинству или оценочная функция) выбирает из них наилучший. Это похоже на мозговой штурм, где из множества идей отбирается самая перспективная.

    Иллюстрация методов параллельного выбора примеров
  2. Поиск по дереву (Tree Search): Для сложных задач ИИ может строить «дерево решений». Каждый узел в этом дереве – это возможный шаг в рассуждениях, а ветви – разные пути. ИИ исследует эти пути, оценивая перспективность каждого шага. Пространство поиска определяет, на каком уровне детализации ИИ «думает» (например, отдельные слова, предложения или целые этапы решения). Функция оценки помогает ИИ понять, насколько хорош текущий шаг или насколько перспективна данная «ветка» рассуждений. А алгоритм поиска - стратегия, по которой ИИ исследует «дерево» (например, поиск в ширину, поиск в глубину, MCTS).

    Ключевые компоненты поиска по дереву.
  3. Многоэтапная коррекция (Multi-turn Correction): ИИ генерирует ответ, затем сам себя (или с помощью внешней системы) проверяет, находит потенциальные ошибки или неточности и пытается исправить свой ответ. Этот процесс может повторяться несколько раз. Тут важен механизм, указывающий на ошибки, и способность модели использовать обратную связь для улучшения своего ответа.

    Ключевые компоненты многоэтапной коррекции
  4. Ансамбль методов масштабирования во время тестирования (Ensemble of Test-Time Scaling Methods): Часто наилучшие результаты достигаются не использованием одного метода, а их комбинацией. Например, ИИ может сначала сгенерировать несколько вариантов решения с помощью параллельного выбора, а затем для каждого из них применить поиск по дереву или многоэтапную коррекцию для выбора и доработки наилучшего. Различные методы могут усиливать друг друга, позволяя ИИ подходить к решению задач более гибко и эффективно.

    Ансамбль методов масштабирования на этапе тестирования

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

📄 Статья

***

Вот такие интересные исследования вышли в апреле. Не забудьте подписаться на мой Telegram-канал, где я делюсь инсайтами из ИИ-индустрии, советами по внедрению ИИ в бизнес и разработке ИИ-стартапов, а также комментирую важнейшие новости. Будем вместе впереди в мире технологий!