Клиническое программирование: где LLM спотыкаются
Подготовка данных клинических исследований к регуляторной подаче — процесс с жёсткими требованиями. Протоколы нужно превращать в аналитические наборы, соответствующие стандартам CDISC, и любая ошибка здесь может стоить задержки или отклонения заявки. Долгое время этот этап оставался узким местом: он требует и знания домена, и аккуратности в коде, и понимания регуляторной логики.
Когда дело доходит до генерации такого кода с помощью больших языковых моделей, картина выглядит удручающе. В эксперименте, описанном в препринте на arXiv, пять frontier-моделей получили одиннадцать однократных попыток создать валидный subject-level набор данных — и ни одна не справилась. Речь не о незначительных огрехах, а о полной непригодности результата. Модели как будто не учитывают саму структуру процесса: они пытаются собрать весь пайплайн разом, без промежуточных проверок и понимания того, какие шаги обязательны, а какие зависят от предыдущих.
GxP-Agent: декомпозиция через граф процессов
Ответом на эту проблему стала мультиагентная система GxP-Agent. Её ключевая идея — не полагаться на «рассуждения» модели о том, как устроен регуляторный процесс, а закодировать этот процесс явно. Регуляторный порядок действий представляется в виде направленного ациклического графа (DAG). Вместо монолитной генерации всего набора данных за один шаг задача разбивается на 15 доменно-специфичных узлов. Каждый узел — это отдельная операция, которую выполняет агент-воркер, снабжённый контекстом навыков из pharmaverse. Между узлами стоят валидационные шлюзы, а при необходимости предусмотрен условный повтор.
Такой подход меняет саму природу ошибок. Если модель в каком-то узле отклоняется от ожидаемого результата, это обнаруживается сразу, и можно перезапустить шаг, а не переделывать весь пайплайн. По сути, LLM перестаёт быть «генератором всего сразу» и превращается в исполнителя локальных, хорошо описанных подзадач. Топология графа задаёт жёсткий каркас, внутри которого модель может действовать более свободно.
Как это выглядит на практике
Каждый узел DAG отвечает за конкретный домен данных, а воркер получает не абстрактное задание «сделай ADSL», а узкую задачу с понятными входами, выходами и критериями проверки. Если результат не проходит проверку, активируется условный повтор — агент получает обратную связь и корректирует код. Это напоминает цикл «сгенерировал — проверил — исправил», но встроенный в структуру графа, а не выполняемый произвольным образом.
Цифры на CDISC-Bench: от нуля до ста
Чтобы оценить эффективность подхода, авторы разработали execution-based бенчмарк CDISC-Bench. Он построен на основе реального пилотного сабмишена FDA — CDISCPilot01, включающего 254 субъекта и 49 ground-truth переменных ADSL. Такой бенчмарк проверяет не просто синтаксис или семантику кода, а фактический результат его выполнения.
Здесь GxP-Agent показал впечатляющие результаты: с моделью Claude Sonnet 4.6 он достиг 100% структурного совпадения — все 49 переменных и все 254 записи были корректны в трёх независимых запусках. Для сравнения, лучший retrieval-augmented бейзлайн остановился на 59,2%, а все остальные подходы — single-agent и flat multi-agent — не набрали ни одного процента. Иными словами, любая архитектура без графовой топологии просто не способна справиться с задачей.
Слабым моделям тоже становится легче
Любопытный побочный эффект: DAG-топология снижает требования к самой модели. Когда в качестве воркера использовалась GPT-4.1 на том же графе, среднее структурное совпадение составило 59,2% — тот же уровень, что и у retrieval-augmented бейзлайна на сильной модели. Без графовой структуры GPT-4.1 показывала нулевой результат. Это подтверждает: решающую роль играет не мощность отдельной модели, а то, как организован процесс.
Универсальность подхода и выводы
Авторы не ограничились одним доменом. Тот же принцип применили к набору данных ADAE (нежелательные явления) — там используется ветвящийся DAG из 9 узлов, 55 переменных и 1191 записи. С первой попытки было достигнуто 100% структурное совпадение. Это говорит о том, что метод обобщается за пределы ADSL и подходит для других типов клинических данных.
Главный вывод работы: надёжность в клиническом программировании достигается не за счёт «умных рассуждений» LLM, а за счёт кодирования доменных знаний о процессе в виде топологии графа. Модель остаётся важным, но не единственным компонентом системы. Именно граф задаёт ограничения и порядок, а языковая модель наполняет его конкретным кодом. Такой симбиоз позволяет получать GxP-совместимые результаты, на которые можно положиться при регуляторных подачах.
