Как Bayer построил надёжную систему agentic AI для поиска по архивам
Компания Bayer совместно с Thoughtworks создала PRINCE (Preclinical Information Center), облачную платформу для поиска информации в доклинических базах. Исторически исследователи полагались на ключевые слова и булеву логику, что неэффективно для сложных вопросов. PRINCE эволюционировала через три этапа: от структурированного поиска (Search) к RAG-powered вопросам (Ask) к многоагентной системе, способной выполнять сложные задачи, включая черновики нормативных документов (Do).
Система использует LangGraph для оркестровки, FastAPI для бэкенда и составной стек хранилищ: OpenSearch для векторных представлений отчётов, Athena для структурированных данных, PostgreSQL для отслеживания состояния агентов. Критическая идея, context discipline: каждый этап (планирование, исследование, рефлексия, письмо) получает разный контекст, что упрощает отладку и оценку. Система включает multiple fallback уровни: повторные попытки на уровне LLM-вызова и целого узла рабочего графа, автоматический перелёт на альтернативный провайдер (OpenAI, Anthropic, Google). Наблюдаемость реализована через Langfuse и CloudWatch; оценка качества идёт ежедневно на живых данных с использованием RAGAS.
Ключевые факты
- Agentic RAG эффективнее простого поиска для сложных вопросов в специализированных доменах (фармакология, токсикология)
- Context engineering критична: разные этапы рабочего процесса требуют разных срезов данных и контекста
- Harness engineering (оркестровка, recovery, observability) обеспечивает надёжность вокруг моделей, не внутри них
- Multi-level fallback (LLM call + node level + provider switching) необходим в production системах
- Ежедневная оценка на живых данных (RAGAS) выявляет деградацию быстрее, чем статические тесты
Ред. Пять buzzword-ов на пять пунктов, идеальная плотность. Хорошо хоть, что за каждым стоит реальный fallback, а не слайд.
Почему это важно
Фармакологический поиск требует достаточно гибкого понимания сложных вопросов, которое традиционные системы не могут предоставить. Архивы Bayer содержат десятилетия отчётов в PDF, чьи структурированные метаданные часто неполные или неправильные. LLM-based RAG позволяет задавать вопросы на естественном языке и получать ответы из неструктурированного текста без переписывания баз данных. Bayer в ранние дни инвестировала в generative AI, и PRINCE продемонстрировала реальную экономию времени исследователей.
Ред. Десятилетия PDF с «неполными или неправильными» метаданными, классический корпоративный архив, который проще обложить агентами, чем привести в порядок.
Кому это важно
Farmacology teams, toxicology researchers и regulatory affairs специалистам, чьи дневные задачи включают поиск информации из больших несортированных архивов. Инженеры, строящие agentic RAG системы в других industries (юрпомощь, медицина, финансы, консалтинг) могут заимствовать паттерны context engineering и harness engineering. Enterprise LLM teams, которые хотят перейти от RAG к multi-agent workflows, найдут практические советы по fallback дизайну и observability.
Ред. Список целевых индустрий (юрпомощь, медицина, финансы, консалтинг) подозрительно совпадает с теми, где ошибка дороже всего стоит.
Как это применить
Начните с разделения вашего агентского рабочего процесса на этапы: планирование, поиск, рефлексия, письмо. Каждому этапу дайте узкий контекст, а не один большой bag. Выберите orchestration фреймворк (LangGraph, Lanchain, собственный); Bayer выбрала LangGraph. Реализуйте fallback на двух уровнях: внутри LLM calls (retry + switch provider) и на уровне graph nodes (повторить весь шаг). Подключите observability (Langfuse, Arize, собственное логирование) и оценку (RAGAS, кастомные metrics) с самого начала; ежедневная оценка на живых данных выявляет проблемы быстрее, чем батч-тесты.
Ред. Совет «разбейте процесс на этапы и дайте каждому узкий контекст» звучит как «пишите хороший код», но в мире агентов это, видимо, всё ещё новость.
Можно ли доверять
Bayer опубликовала не только технический пост на Martin Fowler, но и peer-reviewed статью в Frontiers in Artificial Intelligence. PRINCE работает в production и обслуживает реальных исследователей. Многие идеи (context engineering, harness engineering) соответствуют ширине practice в индустрии, но терминология относительно новая. Честно говоря, в статье отсутствуют некоторые детали про accuracy rate, mean latency, или cost per query, так что full реальность PRINCE может быть более сложной. Однако архитектурные решения разумны и воспроизводимы.
Ред. Кейс без единой цифры про accuracy, latency и стоимость запроса. Peer review есть, а вот метрик, по которым кейс можно было бы перепроверить, как-то не завезли.
Риски и подводные камни
Context windows не решают проблему качества агентского рассуждения, выбор, что включить в контекст, остаётся критичным решением. Аутоматические retry + fallback могут замаскировать проблемы: если на одном провайдере идёт дрейф качества, автоматический switch может временно скрыть это. Надо мониторить, какой провайдер использовался и как часто. RAGAS и кастомные метрики требуют хорошо размеченного золотого стандарта (ground truth), который не все доменыимеют. Наконец, complex orchestration (LangGraph, стейт-машины) может быть сложна в отладке при edge cases, требует хорошего логирования и трассировки.
Ред. Автоматический fallback, который тихо прячет дрейф качества у одного провайдера, это надёжность, которая маскирует ненадёжность. Удобно ровно до первого аудита.
«Context engineering shaped what information each model received, what it did not receive, and how context moved between specialized steps such as research, reflection, and writing. Harness engineering shaped the scaffolding around the models: orchestration, tool boundaries, state persistence, retries, fallbacks, validation, reflection loops, observability, and human review.»
— Martin Fowler blog, Bayer case study