Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
DrugCoding научился превращать исследовательский запрос по поиску лекарств в связанный процесс из вычислительных задач и выполнять его через специализированные модели. В препринте, который не рецензирован и где все числа получили сами авторы, система успешно завершила с первой попытки 97,35% тестовых сессий против 88,11% у Codex. Для продуктовой команды работа предлагает архитектуру агента, но ещё не доказывает, что он способен самостоятельно получать надёжные научные результаты.
План хранится отдельно от разговоров агентов
DrugCoding начинает не с выбора инструмента, а с разбора цели и входных данных. Отдельный агент выделяет молекулы, белки, клеточные линии, требуемые результаты и связи между ними. Программные проверки сопоставляют найденные сущности с исходными записями, чтобы последующие шаги ссылались на конкретную последовательность белка или молекулярную строку, а не на пересказ модели.
Затем планировщик строит граф зависимостей. Каждая вершина описывает научную операцию, входные данные и результаты предыдущих шагов, без которых она не может запуститься. Например, стыковка молекулы с белком может потребовать сначала подготовить структуру рецептора и определить карман связывания.
Метаагент принимает план и передаёт готовые этапы агентам-исполнителям. Принятые планы, выбранные модели и результаты хранят программные компоненты, а не контекст диалога. Поэтому система различает предложение языковой модели, фактически выполненный вызов и результат, который прошёл проверку и разрешён для следующих этапов.
Отдельный агент в конце собирает отчёт только из принятых записей и ссылок на полученные файлы. Если текст отчёта не сформировался, система допускает одну повторную попытку, но не меняет сами вычисления. Независимую проверку готового отчёта другой языковой моделью архитектура не проводит.
Эту схему проверяли с семью базовыми LLM на восьми научных подзадачах: среди них прогноз связи лекарства с мишенью, оценка свойств молекулы, виртуальный скрининг, стыковка и генерация молекул. Тест измеряет, правильно ли агент выбрал инструмент, сохранил аргументы и собрал последовательность вызовов.
Маршрутизатор отделяет научный выбор от возможности запуска
Для одной операции DrugCoding может знать несколько специализированных моделей. При прогнозе связи молекулы с белком в каталоге доступны DMFF-DTA, DTIAM и TSEDTA, а для стыковки — DiffDock и KarmaDock. Маршрутизатор сравнивает кандидатов по пригодности для задачи и переданным сведениям о качестве.
Рекомендация ещё не означает запуск. Исполняющий слой отдельно проверяет формат входных данных, наличие нужных файлов, совместимость адаптера, разрешённый способ выполнения и доступность среды. Если лучший научный кандидат нельзя запустить с текущими ресурсами, система выбирает следующий подходящий вариант; если подходящих нет, задача остаётся без привязки.
Такое разделение полезнее единого запроса «выбери и вызови модель». Команда может обновлять научные критерии независимо от инфраструктурных ограничений, а каждый запуск получает явную привязку к модели, контрольной точке, преобразователю входов и исполнителю.
При этом маршрутизатор не учитывает задержку, кэширование и стоимость ресурсов. Его оценка отражает научную пригодность, а не производственный баланс качества, цены и времени ответа. Для реального сервиса эти критерии придётся добавить поверх предложенной схемы.
Архитектуру можно заимствовать, результат — пока нет
На усложнённой части теста DrugCoding получил 97,92% успешных первых попыток и опередил лучший научный агент на 1,31 процентного пункта. Разбор ошибок связывает преимущество прежде всего с сохранением входных данных и корректной структурой вызовов. В одном примере конкуренты добавили к переданной молекулярной строке суффикс )O, хотя выбрали правильную операцию.
Многоагентность сама по себе дала только 0,56 процентного пункта в среднем и помогла чуть больше чем в половине конфигураций. Для некоторых LLM единый агент работал лучше. Работа поэтому не подтверждает правило «больше агентов — выше надёжность»: конфигурацию нужно проверять вместе с конкретной базовой моделью.
Главная практическая идея — вынести состояние процесса из переписки LLM. План, зависимости, исходные сущности, исполнимые привязки и принятые результаты должны жить в проверяемых структурах. Специализированным агентам тогда остаются ограниченные задачи: разобрать контекст, предложить план, сравнить модели, выполнить разрешённый вызов или собрать отчёт.
Менять планы по автоматизации вычислительного drug discovery только на основании итогового процента рано. M-TCDD проверяет соответствие эталонным вызовам инструментов, а не качество найденных молекул, воспроизводимость полного исследования или пользу результатов для лаборатории. DrugCoding стоит рассматривать как проектный шаблон для оркестрации и контроля данных, а не как готовое доказательство автономного поиска лекарств.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
