Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Агент смог превращать научное задание в систему, которую после сборки можно заново запускать и проверять на скрытых примерах. В препринте, который не прошёл рецензирование и опирается на собственные замеры авторов, 28 отобранных систем прошли 33 проверки. Для команд, создающих подобных агентов, работа предлагает более строгую единицу результата: не диалог и не отчёт, а упакованный исполнимый артефакт.
Что остаётся после работы агента
Jinge Wu и соавторы назвали такой артефакт «ИИ-лабораторией». Это решатель конкретной научной задачи, который объединяет модели, данные, базы знаний, инструменты и контроллер — код, определяющий порядок их вызова.
Лаборатория получает входные данные через фиксированный интерфейс и возвращает результат в заданном формате. Внутреннее устройство не закреплено: агент может обучить специализированную модель, построить поисковый индекс, написать расчётные инструменты или собрать всё это вокруг платформенной LLM.
Во время сборки агент работает в отдельной среде с доступом к публичным наборам данных, программам и весам моделей. Он сам готовит данные, выбирает представление, запускает обучение, проверяет промежуточные версии и упаковывает итоговый решатель. Платформенную LLM при этом не дообучают: агент обучает предметные модели и пишет код, через который LLM использует инструменты.
В готовых лабораториях встречаются три схемы управления. Контроллер может выполнять заранее заданную процедуру, разрешать LLM писать и запускать код либо сначала искать кандидатов в подготовленном индексе, а затем поручать модели их ранжирование. Один контракт запуска скрывает эти различия от проверяющего хоста.
Каждая сборка оставляет журнал действий, сведения о потраченных ресурсах, рабочую директорию и доставленный артефакт. Поэтому результат можно связать с конкретным кодом и повторно запустить после того, как агент закончил работу.
Как хост отделяет сборку от проверки
Главное разделение проходит между агентом-строителем и хостом, который оценивает результат. Агент видит описание задачи и доступные ресурсы, но эталонные ответы для итоговой проверки остаются за пределами интерфейса лаборатории.
После доставки хост запускает артефакт на отложенных примерах, проверяет полноту ответов и рассчитывает метрику задачи. Идентификаторы примеров заменяются, а поля переставляются местами, чтобы решатель не мог опираться на прежние номера или позиции. Эти меры не доказывают, что публичные ресурсы для сборки не пересекались с проверочными примерами, но закрывают прямой доступ к ответам через интерфейс.
Десять лабораторий содержали предсказательные модели, обученные во время сборки. Остальные в основном сочетали поисковые системы, исполнимые инструменты и управляющую логику с платформенной LLM.
На задаче распознавания сигнала в последовательности ДНК агент собрал ансамбль свёрточных моделей, поиск похожих фрагментов и проверку решения через LLM. Готовая система получила F1 0,8977 при пороге 0,88; F1 объединяет точность положительных ответов и полноту их обнаружения.
Прохождение порога ещё не означает, что вся прибавка появилась благодаря сборке. В прямом сравнении исходная LLM без лаборатории уже преодолела заданный порог в 11 из 12 проверок. Значит, часть результатов показывает работоспособность доставленного артефакта, но не превосходство над простым вызовом модели.
Работа охватывает молекулярные и геномные задачи, физиологические сигналы, клинические расчёты, поиск по медицинским текстам и научные вопросы. При этом в отчёт вошли только системы, которые прошли настроенные пороги. Это не доля успешных сборок: использовалась одна конфигурация claude-opus-5, отдельный запуск для каждого кейса и неодинаковые вычислительные бюджеты, а сами пороги не были единообразными сравнениями с лучшими результатами в областях.
Меняет ли LabFactory планы продуктовых команд
Работа не даёт оснований выбирать конкретную LLM или рассчитывать надёжность автономной сборки. Отбор успешных кейсов скрывает, как часто агент не доставляет рабочую систему, а неодинаковые бюджеты мешают сравнивать стоимость задач.
Зато LabFactory задаёт полезную архитектурную границу. Если агент должен создавать аналитические или научные решения, его результат стоит оформлять как версионируемый пакет с фиксированным входом, воспроизводимым запуском и сохранёнными зависимостями. Диалог агента остаётся журналом разработки, но не доказательством качества.
Второе изменение касается приёмки. Проверяющая среда должна принадлежать не агенту, а отдельному хосту: хранить эталоны, запускать доставленный пакет и считать метрики. Такая схема снижает риск, что система отчитается по собственной локальной проверке или незаметно изменит правила задачи.
Наконец, измерять нужно весь путь вывода, а не только базовую модель. В лаборатории итог могут определять подготовка входа, специализированный предиктор, поиск, расчётный инструмент, LLM и правила выбора между ними. Отдельная оценка каждого компонента полезна для отладки, но продукт принимает решение по исполнимой системе целиком.
Практический вывод ограничен процессом разработки: LabFactory поддерживает переход от оценки рассуждений агента к проверке того, что он действительно доставил. Менять технологический стек по этой работе рано, а выделить независимый контур сборки и приёмки уже имеет смысл.
Источники
Иллюстрация: рисунок из статьи «LabFactory: Building and Evaluating Executable AI Labs», Jinge Wu, Hongjian Zhou, Mingde Zeng и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
