Numan — британская компания в сфере цифрового здравоохранения, которая помогает пациентам справляться с долгосрочными заболеваниями в области контроля веса, гормонов и сексуального здоровья. Многие из наших пациентов проходят программу по снижению веса и ежедневно используют приложение для отслеживания прогресса.
При создании Nu, нашего ИИ-тренера по здоровью, одной из проектных задач было обеспечение высокого качества коучинга без перехода черты в область медицинских диагнозов, назначений или принятия клинических решений — все это является строгими ограничениями для агентов в нашей строго регулируемой медицинской сфере. Хотя изначально мы сосредоточились на самом агенте и автоматизации вокруг него, в итоге ключевое значение имело качество наших критериев оценки. Это история о том, как мы разработали и улучшили наши критерии оценки, чтобы обеспечить высокое качество пользовательского опыта и одновременно держаться в стороне от областей, подлежащих регулированию.
Где стандартные подходы к оценке не подошли для Nu
Мы начали с того, с чего начинает большинство команд: с набора данных входных данных и ожидаемых результатов, а также судьи на базе языковой модели (LLM), оценивающего каждый ответ. Хотя этот подход хорошо работает для агента типа «вопрос-ответ», коучинг — это диалог, а не ответ. Каждый подход, который заранее фиксировал ответ Nu, давал сбой в двух направлениях:
1. Одношаговые оценки на статических примерах (фиксированный вход, фиксированный ожидаемый выход и судья, оценивающий один ответ сам по себе). Поведенческий коучинг редко имеет один правильный ответ на запрос, и то, был ли ответ безопасным, зависит от контекста всего разговора. Nu должна понимать, что мешает пациенту на протяжении всего диалога, прежде чем давать советы, и удерживать правильные границы, когда пациент настаивает.
Усреднение одной оценки по всему набору данных скрывало те моменты, где Nu терпела неудачу. Несколько плохих ответов едва ли меняют общую цифру, поэтому диалог выглядит соответствующим требованиям, хотя на самом деле это не так. Примеры также создали вторую проблему. В одном из запусков группа низких оценок оказалась результатом ошибки самой оценки, а не Nu. Критерии требовали проявления эмпатии, исследования и советов в рамках всего лишь двухшагового обмена репликами, в то время как живой тренер распределил бы это по ходу всего диалога. Nu проводила коучинг правильно, но узкие фиксированные критерии оценки некорректно сигнализировали об ошибках.
2. Сценарии многошаговых диалогов. Очевидным решением для одношаговых примеров является предварительное написание предполагаемой серии ответов пациента. С помощью такого «сценария» несколько шагов сценария, передаваемых Nu по одному за раз, позволяют судье оценить весь диалог в конце. Хотя это дает судье больше свободы, чем один ответ, оценка рухнула точно так же. Когда второй шаг пациента написан заранее, тест игнорирует то, что Nu фактически сказала на первом шаге. В тот момент, когда Nu говорит то, чего сценарий не ожидал, каждый последующий шаг отвечает на диалог, которого никогда не было.
Эти два типа сбоев сформировали все, что мы создали впоследствии.
Фреймворк оценки, который мы используем сегодня
Nu представляет собой граф LangGraph. Модель-супервайзер координирует передачу задач узкоспециализированным субагентам, каждый из которых сосредоточен на одной области коучинга со своими собственными промптами и инструментами. Такая модель композиции делает добавление нового специалиста дешевым, а главное — поддерживает единую поверхность оценки для всех них.
Некоторые вещи, которые Nu должна делать правильно, можно определить по одному ответу. Например, правильно ли супервайзер направил запрос нужному специалисту, получил ли вопрос о медикаментах безопасный ответ или сработал ли защитный барьер должным образом. Для этого мы запускаем тематические наборы данных, охватывающие качество коучинга, безопасность, запросы о медикаментах, маршрутизацию и суммирование. В отличие от наших первоначальных одношаговых оценок, мы изменили две вещи: 1) Каждый набор данных оценивается по категориям судьей на базе LLM, а не по единому среднему значению, поэтому скопление сбоев в одной категории остается заметным, даже если остальные выглядят благополучно. И 2) каждый критерий оценивает только то, что может показать один ответ, поэтому судья больше не штрафует Nu за темп диалога, который выбрал бы тренер.
Все, что примеры не могут охватить (то есть то, что требует структуры всего диалога целиком), получает собственный уровень, описанный ниже. Поскольку Nu является графом, оценка может быть направлена на всю систему или на отдельный субагент, и новый специалист наследует эту поверхность оценки.
«То, что мы выпускаем, — это то, что мы тестируем»
Самый простой способ создать систему оценки — это отдельный тестовый инструмент (harness), который копирует промпт агента и напрямую вызывает модель... что работает ровно до тех пор, пока тестовый инструмент и продакшн не начинают расходиться. У нас нет отдельного тестового инструмента, и мы придерживаемся принципа: то, что мы выпускаем в продакшн, мы и тестируем. Каждая оценка запускается через тот же граф LangGraph, с которым общается пациент, поэтому мы оцениваем именно то, с чем сталкивается пациент.
По мере масштабирования мы начали задаваться вопросом, правильно ли использовать одного провайдера для каждого агента, поскольку супервайзер и доменные специалисты выполняют разную когнитивную работу. Сегодня Nu работает на двух передовых провайдерах, выбираемых для каждого агента: один для супервайзера, другой для специалистов. Благодаря переносимости нашего набора оценок, созданного в виде открытых тематических наборов данных, которые мы можем применять к любой конфигурации, мы запустили одни и те же наборы данных у разных провайдеров и сравнили результаты бок о бок. Миграция между передовыми провайдерами, которая обычно занимает недели ручного тестирования, заняла всего один день.
Поведенческие тесты для поддержания регуляторных границ
Согласно руководству MHRA, программный продукт с медицинским назначением (предоставление клинических консультаций, постановка диагнозов или рекомендации по лечению) становится медицинским изделием. Nu была разработана как велнес-продукт для лайфстайл-коучинга и просвещения, а не для клинического ухода.
Мы проверяем соответствие Nu этим рамкам при каждом изменении. Проверки безопасности выполняются как метрики по категориям и служат барьером для релизов: регрессия в этой области блокирует автоматический выпуск изменений. Мы настраиваем систему на безопасное завершение диалога — перенаправление, которое удерживает границу, но при этом звучит как тренер, так что пациент, задающий вопрос вне рамок компетенции, получает теплый и полезный ответ вместо резкого отказа.
Помимо тестирования, узлы защиты (guard nodes) работают в каждом диалоге внутри графа. Защитный барьер проверяет каждый исходящий ответ на соответствие фиксированному набору правил клинической безопасности перед тем, как пациент его увидит. Небезопасный проект ответа отправляется обратно супервайзеру для повторной генерации. Если ошибки продолжаются, сообщение заменяется безопасным резервным вариантом вместо отправки небезопасного ответа. А поскольку защитные узлы встроены в граф, они находятся в той же зоне оценки — у нас есть один из тематических наборов данных, созданный специально для проверки того, что защитный барьер ловит именно то, что должен. Кроме того, тренеры по здоровью ежедневно просматривают выборку реальных диалогов и отмечают все, что выглядит как упущение в безопасности, благодаря чему эксперты в предметной области калибруют то, что считается безопасным.
Симуляция диалогов вместо написания сценариев
Наш новейший уровень, который сейчас находится на стадии прототипа, имитирует разговор, а не следует жесткому сценарию. Мы передаем системе оценки пациентскую персону, сценарий, ключевые проблемы, которые Nu должна выявить, и лимит ходов. Более дешевая модель играет роль пациента, ведет многоходовой диалог с реальным агентом и реагирует на все, что говорит Nu. Затем судья оценивает всю стенограмму по категориям. Поскольку пациент генерируется, а не является фиксированным, мы можем тестировать состязательные случаи (формулировки, призванные протащить клинический запрос мимо трейнера, манипуляции под видом обычного вопроса) и выявлять сбои, с которыми статический тестовый набор никогда не сталкивается. Например, когда Nu спешит дать ответ вместо того, чтобы разобраться в проблеме так, как подобает трейнеру.
Такое усиление промптов с помощью смоделированных разговоров позволило сократить серьезные нарушения границ в сценариях обхода защиты (jailbreak) на регуляторном рубеже. Мы запустили параллельные оценки запросов на прием лекарств в качестве фильтра регрессий, чтобы улучшения промптов не могли нарушить поведение, которому мы уже доверяем.
Использование слоя симуляции разговоров для непрерывного совершенствования без внесения регрессий — это в меньшей степени инженерная проблема и в большей — проблема системы критериев (рубрикатора). Когда мы впервые разрабатывали критерии для этого слоя, две темы, которые, как нам казалось, были совместимы, на практике противоречили друг другу в отношении обработки пропущенных доз: одна гласила — отклонить запрос и направить к клиницисту, другая — безопасно завершить диалог с помощью общих фактов из листка-вкладыша с информацией для пациента. Один промпт не может удовлетворять обоим требованиям. Этот пример конфликта промптов научил нас тому, что дефицитным и ценным ресурсом является вовсе не промпт (его способная модель неплохо пишет на основе ограниченного контекста), а критерии оценки. А на регулируемой границе эти критерии должны создаваться и утверждаться клиницистом, который также понимает регуляторные требования, а не инженером. Результаты смоделированных разговоров Nu оцениваются по критериям, разработанным инженерами, поэтому этот уровень не блокирует релизы и не служит основой для каких-либо заявлений о безопасности до тех пор, пока клиницист не утвердит рубрикатор (что и удерживает продукт на стороне оздоровительных услуг, не пересекая черту).
Стек: LangGraph и LangSmith
LangGraph и LangSmith работают вместе как единая система, составляя наш стек разработки агентов.
LangGraph — это сам агент. Супервайзер запускает профильных специалистов, каждый из которых имеет собственный промпт и инструменты.
Оценки выполняются через тот же граф. Оба уровня оценки (и статические наборы, и смоделированные разговоры) обращаются к реальному агенту и могут нацеливаться как на всю систему, так и на отдельного субагента.
LangSmith — это место, где все измеряется. Каждый разговор, смоделированный или реальный, сохраняется в виде трейса. Рецензенты аннотируют эти трейсы, запуская цикл непрерывного улучшения качества. Датасеты и эксперименты также находятся там. Например, сравнительный анализ провайдеров, лежащий в основе нашего однодневного мигрирования, был прочитан напрямую из LangSmith.
Интеграция между LangGraph и LangSmith делает выполнение оценки недорогим. Здесь нет вспомогательного кода, сшивающего три разрозненных инструмента. То, что мы поставляем в продакшн, и то, что мы тестируем, представляет собой один и тот же граф, за которым следит одна и та же платформа.
Куда мы движемся: масштабирование критериев, а не только агента
Качество коучинга зависит от 1) разработки критериев, определяющих, был ли разговор хорошим, и 2) расширения покрытия, по которому они тестируются. Поэтому мы сосредоточены на тестировании новых состязательных персон и сценариев, добавлении новых тем по мере создания новых специалистов и расширении роли клинициста в цикле оценки везде, где затрагиваются безопасность или рамки дозволенного. Рецензенты продолжают читать реальные разговоры в LangSmith, а инженеры по-прежнему утверждают каждое изменение промпта.
Все описанное выше происходит в офлайне, доказывая, что изменение удерживает регуляторные границы до релиза. Следующий шаг — онлайн-оценщики, которые непрерывно применяют те же рубрикаторы к реальным разговорам по мере их появления в LangSmith, оценивая реплики Nu. Вместо ежедневной выборки, которую трейнеры просматривают сегодня, человеческие рецензенты начнут с разговоров, которые уже были помечены оценщиком, — чтобы следить за соблюдением границ в продакшене и совершенствовать рубрикатор при ложных срабатываниях.
Мы также наблюдаем обнадеживающие результаты первых экспериментов по автоматизации рабочих процессов, следующих за надежным рубрикатором, включая сортировку проверенных разговоров в ранжированный бэклог и настройку промпта по фиксированному эталону. Недавно офлайн-цикл оптимизации промптов, ориентированный на один поведенческий эталон, существенно улучшил показатель без ручной настройки... что подтверждает нашу гипотезу: если вы правильно задаете критерии, все остальное поддается автоматизации.
Создание ИИ-трейнера вблизи регуляторной границы
Если вы создаете разговорного агента где-то вблизи регуляторной границы, вот наши рекомендации:
- Фиксированный датасет не может охватить весь разговор целиком. Используйте статические тесты для того, что может показать один ответ, симулируйте разговоры для всего остального и оценивайте по категориям, а не гонитесь за агрегированным показателем.
- Сделайте границу объектом проверки (пробой). Запускайте ее при каждом изменении, позволяйте регрессии блокировать релиз и применяйте тот же рубрикатор в продакшене.
- На регулируемой границе рубрикатор принадлежит клиницисту. Критериев, составленных инженерами, достаточно для запуска тестового окружения, но их недостаточно для утверждения заявлений о безопасности.
- Вкладывайте основные усилия в критерии оценки. Все остальное следует за ними: лучший коучинг, защищенная граница и, в конечном итоге, автоматизация, которой можно доверять.
Мы напишем снова, когда критерии и автоматизация станут более зрелыми.
Nu построена на базе LangGraph и LangSmith. ИИ-система Numan ведет диалоги по медицинскому коучингу в различных областях здравоохранения. Nu разработана как оздоровительный продукт, а не как медицинское изделие. Она предоставляет коучинг и медицинское просвещение, не ставит диагнозы, не выписывает рецепты, не контролирует заболевания и не принимает клинических решений или решений, влияющих на них.
