Медицинский AI проверяют не логами и не набором unit-тестов. Корректность заметки или маршрутизации оценивает клиницист, а его время становится самым дефицитным ресурсом проекта. На этом ограничении сходятся два кейса из обзора LangChain: Abridge, которая превращает диалоги врач-пациент в клинические заметки, и Included Health с AI-гидом Dot.
Короткий ответ: LangSmith помогает превратить клинический обзор в переиспользуемую инфраструктуру. Размеченные датасеты, калиброванные LLM-судьи и автоматические релизные гейты заменяют разовый ручной разбор, который команда повторяла перед каждым релизом. В блоге LangChain эту мысль формулируют прямо: клинический обзор становится инфраструктурой, а не повторяющейся операционной статьёй расходов.
На практике это выглядит так. Abridge сократила цикл релиза с одного-двух месяцев до нескольких дней. Included Health после запуска получила рост вовлечённости в чат на 75% и корректное выявление более 99% высокорисковых ситуаций. Дальше разберём, из каких блоков состоит такой пайплайн и где у него слабые места.
Почему клиническая экспертиза становится узким местом медицинского AI
В медицине планку качества задаёт человек вне инженерной команды. Разработчик видит метрики, трейсы и логи, но решает, верна ли заметка или безопасна ли рекомендация, только клиницист. Клиницист быстро определяет, правильно ли заметка приписала симптом, или предложен ли участнику подходящий уровень помощи. Проверять тысячи случаев без конца он не может.
Отсюда главный вывод обзора: при масштабировании ограничивающим фактором становится экспертная валидация, а не compute и не данные. Если каждый релиз требует нового раунда ручного разбора, скорость выпуска упирается в календарь врачей, а не в инженеров.
Обе команды решают это одинаково: превращают решения клиницистов в актив, который можно применять повторно. Метки, оценщики и датасеты остаются после релиза и работают в следующих. Блог LangChain описывает этот принцип на примере двух медицинских продуктов и платформы LangSmith.
Что именно переиспользуется:
- датасеты с разметкой экспертов, которые не нужно собирать заново;
- LLM-судьи, калиброванные по этой разметке;
- автоматические проверки, которые отсекают регрессии до релиза.
Кейс Abridge: от диалога врач-пациент до клинической заметки
Abridge преобразует разговор пациента и врача в клиническую заметку. С согласия пациента врач записывает визит, а система превращает разговор в текст, который попадает в продольную медицинскую запись и участвует в выставлении счетов.
Заметка уходит в реальную документацию, поэтому ошибка здесь не косметическая. Обзор выделяет два риска.
Первый: атрибуция. Если наблюдение пациента подано как заключение врача, симптом может превратиться в выставленный в счёт диагноз. Формально это строка текста, фактически - изменение медицинской и финансовой картины визита.
Второй: галлюцинации. Лекарство или дозировка, которые никогда не назначались, могут попасть в запись. Такая ошибка опасна и клинически, и юридически.
Из этого следуют требования к надёжной заметке: сохранять, кто что сказал, фиксировать клинически значимое и не вносить ничего, что разговор не подтверждает. Каждый пункт превращается в отдельную проверку, а не в общую оценку «хорошо или плохо».
Как Abridge строит оценки: отдельные судьи под типы ошибок
Abridge использует LangSmith для запуска оценок. Этот результат в обзоре LangChain связывают с переносом проверок в автоматический контур: цикл релиза сократился с одного-двух месяцев до нескольких дней.
Ключевая идея: одного судьи недостаточно. Разные типы ошибок требуют разных критериев, поэтому под них строят отдельных LLM-судей. Для заметок логично разделить оценку минимум по нескольким направлениям:
- точность - факты и детали совпадают с разговором;
- соответствие требованиям - кодирование и биллинг подтверждены текстом;
- стиль - тон профессиональный, без лишних оценок;
- полнота - клинически значимое не потеряно.
Отдельный вопрос - нужен ли эталон. Reference-based оценки сравнивают результат с эталонной заметкой, и это работает, когда эталон есть. Reference-free оценки проверяют заметку без эталона: например, ищут утверждения, которых нет в исходном диалоге. Для генерации текста, где один и тот же визит можно описать по-разному, комбинация двух подходов даёт более полную картину, чем каждый по отдельности.
Похожую логику разбора LLM-судей на неоднозначных результатах разбирает кейс Similarweb: там тоже показывают, как плохо настроенная оценка маскирует реальные улучшения агента.
Align Evaluator: сверка судьи с аннотациями клиницистов
LLM-судья ошибается систематически: он может стабильно завышать оценку стилю или пропускать редкие ошибки атрибуции. Чтобы этому доверять, его сверяют с человеком. В LangSmith для этого есть Align Evaluator, который сопоставляет оценки судьи с аннотациями и показывает степень согласия.
Логика калибровки такая: клиницисты размечают выборку случаев, тот же набор прогоняют через судью, расхождения разбирают и правят рубрику или промпт. Пока согласие судьи с экспертом не измерено, цифра в дашборде выглядит убедительно, но к реальному качеству может не иметь отношения.
Ограничение важное. Обзор LangChain описывает подход на уровне принципов и не приводит конфигурацию судей Abridge, набор рубрик или детали калибровки. Конкретные критерии и пороги команда настраивает под свой продукт, и готового рецепта «сделай так же» нет.
Кейс Included Health: AI-гид Dot на LangGraph и Deep Agents
Included Health построила Dot, AI-гида на базе LangGraph и Deep Agents. Ассистент разбирает неоднозначные запросы участников, отвечает на вопросы о покрытии и счетах, направляет человека к подходящей помощи и распознаёт экстренные ситуации.
Проверять здесь нужно две разные вещи. Первая - точность ответа. Вторая - учёл ли Dot полный контекст участника, прежде чем предложить следующий шаг. Безопасная рекомендация при неполном контексте может оказаться неверной, даже если каждое отдельное утверждение корректно.
Abridge и Included Health используют LangSmith для решения одного ограничения: качество определяет человек вне команды. После запуска Dot вовлечённость в чат выросла на 75%, а система корректно отметила более 99% высокорисковых ситуаций.
Как устроен сам агент, мы разбирали отдельно: федеративная мультиагентная архитектура Dot включает суперграф, отдельные подграфы под запись к врачу, срочную помощь и поведенческое здоровье, а также human-in-the-loop с передачей диалога живому специалисту при неуверенности.
Annotation queue в LangSmith: как реальные диалоги становятся метками
Annotation queue превращает разбор реальных диалогов в структурированные метки. Схема такая: продакшен-трейсы попадают в очередь, ревьюер просматривает диалог и ставит метку, а метки затем используются повторно.
Для Dot такой поток, по логике обзора, работает в трёх направлениях сразу: дашборды показывают, где система ошибается; метки уточняют определения навыков (skills), которые агент применяет при маршрутизации; перед релизом изменения прогоняют по накопленным меткам. Цикл замыкается: реальные диалоги дают метки, метки улучшают продукт, продукт порождает новые диалоги.
Ценность в масштабировании экспертизы. Один разбор ревьюера превращается в правило, которое применяется к тысячам похожих случаев без нового участия человека.
Ограничение: в обзоре LangChain этот контур описан на уровне принципа. Конкретная настройка очереди, поля меток и то, как именно метки связаны с определениями навыков Dot, не раскрыты, поэтому детали придётся проектировать под свой продукт.
Релизные гейты: как автоматические проверки ускоряют выпуск
Релизный гейт - это набор автоматических проверок, которые изменение обязано пройти до выпуска. Гейт срабатывает на наборе размеченных случаев и на судьях, калиброванных по этим же данным.
Пример из обзора - Abridge. Проверок не стало меньше. Изменилось другое: они перестали ждать свободного окна в календаре клиницистов, поэтому цикл релиза упал с одного-двух месяцев до нескольких дней.
Гейт не отменяет экспертизу. Он снимает с эксперта рутинные случаи и оставляет ему новые или спорные. Клиницист смотрит то, где судьи расходятся или где метрика у порога, а не тысячи однотипных заметок.
Какие метрики включать в гейт для медицинского AI
Список зависит от продукта, но для генерации клинических заметок он выглядит так:
| Метрика | Что проверяет | Пример проверки |
|---|---|---|
| Атрибуция | Кто что сказал | Наблюдение пациента не подано как заключение врача |
| Галлюцинации | Нет данных вне разговора | Лекарство и дозировка подтверждены диалогом |
| Соответствие требованиям | Кодирование и биллинг | Код диагноза опирается на текст заметки |
| Стиль | Профессиональный тон | Нет разговорных оборотов и субъективных оценок |
| Полнота | Клинически значимые детали | Симптомы, анамнез и назначения на месте |
Для Dot набор другой: корректность маршрутизации, распознавание экстренных ситуаций и использование полного контекста участника при выборе следующего шага.
Пороги нельзя брать с потолка. Их калибруют на размеченных данных: сначала измеряют, как судья согласуется с экспертом, и только потом выбирают значение, при котором гейт пропускает безопасные изменения и блокирует опасные. Слишком строгий порог останавливает выпуск на пустом месте, слишком мягкий пропускает регрессии. Оба перекоса стоят дорого.
PHI, дрейф и выбор развёртывания LangSmith
Медицинские данные попадают под режим защищённой информации о здоровье (PHI) и требования HIPAA. Это меняет вопросы, которые обычно задают к пайплайну оценки: где хранятся трейсы, кто имеет к ним доступ, попадает ли реальный диалог во внешний сервис. Цена ошибки в медицинских продуктах высока, что видно по разбору ChatGPT Health: сервис обрабатывает около 300 млн запросов в неделю, но OpenAI прямо предупреждает, что он не предназначен для диагностики.
Практический приём - разносить среды. Реальные диалоги с PHI обрабатывают в контролируемом контуре, а судей и датасеты калибруют на деперсонализированных или синтетических данных. Тогда оценка не выносит защищённую информацию за периметр.
Обзор LangChain не разбирает вопросы PHI и развёртывания применительно к этим кейсам, поэтому критерии ниже - общие соображения под требования регуляторов и ресурсы команды, а не рекомендация конкретного варианта.
Как выбрать вариант развёртывания под свои требования
| Вариант | Где данные | Плюсы | Минусы |
|---|---|---|---|
| Cloud | У вендора | Быстрый старт, минимум операционной работы | Данные уходят за периметр, нужна оценка соответствия |
| Bring-your-own-cloud | В вашем облаке | Данные под вашим контролем, управление через LangSmith | Нужна своя инфраструктура, настройка сети и доступов |
| Self-hosted | Только у вас | Полный контроль и изоляция | Больше операционной нагрузки, обновления на вашей стороне |
Для медицинских данных чаще смотрят в сторону BYOC или self-hosted: PHI остаётся в контуре компании. Cloud выбирают там, где данные обезличены или где регуляторные требования позволяют хранить их у вендора. Выбор упирается в два фактора: что требует регулятор и сколько операционных ресурсов готова выделить команда.
Отдельная проблема - дрейф. Со временем меняется распределение запросов и поведение модели: ассистент сталкивается с новыми типами вопросов, а судья, калиброванный полгода назад, перестаёт ловить свежие ошибки. Проявляется это тихо: метрики стоят на месте, а качество на новых данных падает.
Ловить дрейф помогают метки из очереди аннотации. Если ревьюеры всё чаще ставят ошибки на типах запросов, которых раньше не было, это сигнал перекалибровать судей и расширить датасет. Сам механизм оценки тоже стоит проверять: модели умеют распознавать тестовый контекст и вести себя иначе на проверке, о чём мы писали в разборе evaluation awareness. Для медицинского AI это означает, что гейт нужно регулярно сверять с реальной выборкой, а не только с фиксированным тестовым набором.
Что общего у Abridge и Included Health и что можно перенять
Разные продукты, разные ошибки, одна логика. Общее у Abridge и Included Health:
- клинический обзор организован как инфраструктура, а не как разовые траты;
- метки и датасеты переиспользуются между релизами;
- судьи калибруются по аннотациям экспертов, а не берутся готовыми;
- перед релизом изменения проходят автоматический гейт.
Различия в фокусе. Abridge оценивает генерацию заметок и разбивает судей по типам ошибок: атрибуция, галлюцинации, соответствие требованиям, полнота, стиль. Included Health оценивает маршрутизацию и безопасность агента, включая распознавание экстренных ситуаций и использование полного контекста участника. Разный продукт задаёт разные метрики, но механика одна.
Подход переносится за пределы медицины. Везде, где качество оценивает внешний эксперт с дефицитным временем, работает та же схема: юристы в юртехе, аналитики в финтехе, методисты в образовании. Судья на базе LLM калибруется по разметке доменного специалиста, а гейт снимает с него рутину.
Слепое копирование не сработает. Нужно самому определить типы ошибок, которые критичны именно для вашего продукта, и собрать первую размеченную выборку. Готовых рубрик под медицинский AI в открытом доступе мало, а те, что есть, не учитывают специфику конкретного продукта.
Если хотите начать с малого: возьмите один продукт, один тип ошибки с наибольшей ценой и сделайте под него судью с ручной разметкой клинициста. Первый калиброванный судья и набор меток уже экономят время эксперта в следующем релизе.