Bayer доверяет ИИ-агентам десятилетия исследований лекарств.

В подробном разборе создания агентной системы в Bayer главный консультант Thoughtworks Саранг Санджай Кулкарни объясняет, почему для построения надёжных агентных систем нужна не более совершенная модель, а более совершенный харнесс и рабочий процесс. В посте описывается, как они построили PRINCE — Preclinical Information Center, который помогает учёным разбираться в десятилетиях отчётов по исследованиям безопасности. Это отличная возможность заглянуть в то, как строить реальную агентную систему, которая работает для реальных пользователей на реальных данных.

Они разбили проект на три части, каждая из которых соответствует типичному пути внедрения агентов: Search (фильтрация по метаданным), Ask (retrieval augmented generation, позволяющий задавать вопросы на естественном языке) и Do (несколько специализированных агентов для планирования, исследования, рефлексии, написания текста и выполнения сложных задач). На каждом этапе они расширяли функциональность, одновременно увеличивая возможности для ошибок.

1Harness важнее модели

Ключевая цитата статьи такая: «Надёжность достигается за счёт инженерной проработки как контекста, который видит модель, так и харнесса, в рамках которого модель действует». Здесь есть два основных понятия: context engineering, когда вы осознанно отправляете конкретную информацию конкретным агентам в конкретные моменты (например, передаёте контекст планирования планировщику, контекст исследования исследователю и т. д.) вместо того, чтобы вбрасывать всю информацию в один огромный промпт в надежде на лучшее; и harness engineering, который заключается в построении фреймворка вокруг модели (например, оркестрация, границы, сохранение состояния, автоматические повторные попытки, запасные варианты, валидация, рефлексия, наблюдаемость, вмешательство человека).

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

Они подробно описывают и свой RAG-процесс: извлечение ключевых слов + фильтрация по метаданным, расширение запроса для генерации 5 семантически различных версий, взвешенный гибридный поиск (0,7 семантический, 0,3 по ключевым словам) и переранжирование с помощью cross-encoder (которое сокращает примерно 20 чанков до топ-7). Также они ограничили число повторных попыток SQL до 3 и выборку записей до 50 на запрос. Это может показаться скучным, но в этом и суть.

2Почему это важно для тебя

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

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