Когда AI становится диетологом: как Omada Health заставила Llama 3.1 говорить о питании как человек

Проблема: миллионы людей и один диетолог

Представьте: у вас 500 тысяч пациентов с диабетом 2 типа. Каждому нужна персонализированная программа питания. Каждому - мотивационные беседы, поддержка, ответы на вопросы. И все это - в реальном времени, 24/7.

Omada Health столкнулась именно с этим. Их программа цифровой терапии диабета работала, но масштабировать человеческую поддержку было невозможно. Коучи-нутрициологи физически не могли общаться с каждым пациентом ежедневно. А ведь именно регулярность - ключ к успеху в изменении пищевых привычек.

Первый вариант - использовать готовые LLM вроде GPT-4. Но сразу три проблемы:

• Конфиденциальность медицинских данных (HIPAA в США)
• Отсутствие специализации в нутрициологии
• Непредсказуемость ответов ("галлюцинации" в медицинском контексте - это не шутки)

Решение пришло от Meta и их открытой модели Llama 3.1 70B. Но сырая Llama - это как выпускник медучилища без практики. Знает теорию, но не умеет работать с реальными пациентами.

Архитектура: как собрать AI-диетолога на AWS

Omada выбрала AWS SageMaker не просто так. Нужна была инфраструктура, которая:

1. Соответствует HIPAA
2. Масштабируется под нагрузку
3. Позволяет экспериментировать с разными подходами к fine-tuning
4. Интегрируется с существующей платформой Omada

1 Подготовка данных: что говорить и как

Здесь началась настоящая работа. Собрали 50 тысяч анонимизированных диалогов между коучами-нутрициологами и пациентами. Каждый диалог - это не просто текст, а структурированная сессия мотивационного интервьюирования.

Разметили данные по ключевым компонентам:

Ключевой момент: модель должна была не просто давать советы, а вести диалог в стиле мотивационного интервьюирования. Это принципиально другой подход - не навязывать решения, а помогать пациенту найти свои.

2 Fine-tuning: какие техники сработали

Начали с базовой Llama 3.1 70B. Почему именно 70B, а не меньшая версия? Потому что для медицинского контекста нужна глубина понимания, а не просто скорость.

Использовали несколько подходов параллельно:

• Supervised Fine-Tuning (SFT): классическое обучение на размеченных диалогах
• Instruction Tuning: явное обучение следовать инструкциям в формате "[ROLE] Nutrition Coach"
• RLHF с экспертами-нутрициологами: коучи оценивали ответы модели, создавая рейтинги для reinforcement learning

На SageMaker использовали распределенное обучение на 8 экземплярах p4d.24xlarge. Каждая эпоха - около 6 часов. Всего провели 15 эпох, отслеживая потерю на валидационной выборке.

Интересный момент: обнаружили, что модель начинает "переобучаться" на конкретные фразы коучей. Решение - добавили аугментацию данных: парафразы, синонимы, разные формулировки одних и тех же концепций.

3 Оценка качества: как измерить эмпатию

Здесь началось самое интересное. Традиционные метрики типа BLEU или ROUGE бесполезны. Нужно было оценивать:

1. Клиническую точность (не дает вредных советов)
2. Эффективность мотивационного интервьюирования
3. Естественность и эмпатию
4. Соответствие тону бренда Omada

Создали многоуровневую систему оценки:

MITI-шкала стала ключевой. Она измеряет:

• Соотношение открытых и закрытых вопросов (должно быть 2:1 в пользу открытых)
• Количество сложных и простых отражений
• Поддержку автономии пациента
• Избегание конфронтационного стиля

Модель, дообученная на диалогах экспертов, показала MITI-оценку 3.8 из 5. Для сравнения: начинающие коучи обычно получают 2.5-3.0.

Развертывание: от эксперимента к 500k пациентам

Обученная модель - это только начало. Теперь нужно было:

1. Оптимизировать для инференса
2. Создать систему мониторинга
3. Интегрировать с платформой Omada
4. Обеспечить откат на человеческих коучей при необходимости

Для оптимизации использовали AWQ квантование до 4-бит. Почему AWQ, а не GPTQ? Потому что AWQ лучше сохраняет качество на краевых случаях, а в медицине краевые случаи - это как раз самые важные.

На SageMaker Endpoints развернули две версии модели:

• Быстрая: 4-битная для большинства запросов
• Точная: полная 16-битная для сложных случаев (определяемых классификатором сложности)

Система мониторинга отслеживает:

# Упрощенный пример мониторинга
monitoring_metrics = {
    "toxicity_score": check_toxicity(response),
    "medical_safety": validate_medical_advice(response),
    "mi_quality": calculate_mi_score(response),
    "confidence": model_confidence,
    "response_time": inference_latency
}

# Если любой показатель выходит за пределы - флаг для ревью
if any(score < threshold for score in [
    monitoring_metrics["medical_safety"],
    monitoring_metrics["mi_quality"]
]):
    escalate_to_human_coach(conversation_id)

Интеграция с платформой Omada прошла через API Gateway + Lambda. Каждый диалог сохраняется в DynamoDB с полной историей для последующего анализа и возможного ревью коучами.

Результаты: цифры, которые заставляют задуматься

Через 6 месяцев после запуска OmadaSpark (так назвали AI-агента):

• 84% пациентов не заметили разницы между AI и человеческим коучем в слепых тестах
• Увеличение вовлеченности: пациенты стали чаще общаться с платформой (в среднем 3.2 сессии в неделю против 1.8 ранее)
• Высвобождение времени коучей: 40% рутинных вопросов теперь обрабатывает AI, коучи фокусируются на сложных случаях
• Снижение затрат: при масштабировании до 1 млн пациентов экономия оценивается в $8-12 млн ежегодно

Но самое интересное - качественные изменения. Пациенты в отзывах пишут: "Чувствую, что меня действительно слушают", "Не чувствую осуждения, когда признаюсь в срывах", "Получаю поддержку именно тогда, когда она нужна".

Ошибки, которые почти совершили (и как их избежали)

В процессе было несколько критических моментов, которые могли все испортить:

Ошибка 1: Слишком много данных, слишком мало качества

Первоначально хотели использовать 200k диалогов. Но при анализе обнаружили, что 30% из них - низкого качества (коучи уставали к концу дня, использовали шаблонные фразы).

Решение: создали систему фильтрации диалогов. Использовали уже обученную модель для оценки качества каждого диалога по MITI-шкале. В итоге оставили 50k, но все - высокого качества.

Ошибка 2: Игнорирование краевых случаев

В начале тестирования модель прекрасно работала с типичными сценариями. Но когда пациент написал "У меня депрессия и я не могу готовить", модель начала давать советы по планированию питания. Полный провал эмпатии.

Решение: создали отдельный классификатор для выявления психологических кризисов. Если модель детектирует депрессию, суицидальные мысли, тяжелый стресс - немедленный переход к человеческому коучу.

Ошибка 3: Оптимизация скорости в ущерб безопасности

Инженеры предлагали использовать более агрессивное квантование для ускорения инференса. Но тесты показали, что при 3-битном квантовании модель начинает "галлюцинировать" в 5% медицинских вопросов.

Решение: остановились на 4-битном AWQ. Латентность немного выше, но безопасность - абсолютный приоритет.

Что дальше? Будущее AI в здравоохранении

Omada уже работает над следующими шагами:

• Мультимодальность: анализ фотографий еды от пациентов (с соблюдением privacy, разумеется)
• Персонализация на основе генетики: интеграция с данными ДНК-тестов (только с явного согласия пациентов)
• Прогнозирование срывов: анализ паттернов в диалогах для предсказания, когда пациенту понадобится дополнительная поддержка

Но главный урок этого кейса не технический. Он философский: AI в здравоохранении работает только когда:

1. Его обучают на качественных данных экспертов
2. Есть жесткая система валидации и мониторинга
3. Он дополняет, а не заменяет человеческую экспертизу
4. Пациент всегда может перейти к живому специалисту

Если вы думаете о подобном проекте, начните не с выбора модели, а с ответа на вопрос: "Какие 20% работы экспертов можно автоматизировать без потери качества?" У Omada это были ответы на частые вопросы и базовая мотивационная поддержка. У вас может быть что-то другое.

И последнее: не пытайтесь сделать все идеально с первой итерации. Omada потратила 9 месяцев на первые эксперименты, 6 на дообучение и еще 3 на внедрение. В здравоохранении скорость важна, но безопасность - важнее.