Модель работает на входе в жёсткой обвязке (harness), в продуктивном контуре работают только проверяемые правила. Хватит ли этого для доверия ИИ, покажут годы работы.
«Модель так решила». После этой фразы разбор инцидента в реанимации заканчивается, не начавшись.
Сцена ниже вымышлена, но вопрос в ней настоящий. Утро после ночной смены в отделении реанимации и интенсивной терапии (ОРИТ). Ночью к монитору пациента была подключена система поддержки решений на основе искусственного интеллекта. Так называют программу, которая следит за показателями и подсказывает врачу. В какой-то момент она промолчала там, где тревога была нужна. Заведующий спрашивает: почему система так решила? На каком основании? Ответит ли она так же, если подать ей те же данные ещё раз?
Для системы на обучаемой модели ответ один: повторить нельзя. Модель могли с тех пор дообучить. Даже неизменная модель при повторном запуске способна ответить иначе. Проследить ответ до медицинского правила тоже нельзя. Внутри модели нет правил, которые кто-то прочитал и утвердил.
Первое желание — купить модель получше. Авторы платформы HealthOS, в которую входит решение для реанимации, смотрят иначе: барьеры не делают модель лучше, они определяют, где ей место. Доверие к машине у постели больного нельзя сформировать «голым» обещанием точности. Его формирует опыт использования системы. Отсюда вывод автора этой статьи: купить доверие вместе с более точной моделью нельзя — доверие накапливается вместе с опытом. Без исключений.
Почему «модель получше» не помогает
Большая языковая модель — программа, обученная на огромных массивах текста. Она умеет порождать связные ответы. Разработчики HealthOS свели её слабые места в таблицу из семи строк. Три из них объясняют сцену из утреннего разбора в реанимации.
Невоспроизводимость. Одинаковые данные на входе не гарантируют одинакового ответа. Вчерашний вывод повторить нельзя.
Вымышленные выводы. Модель способна уверенно сообщить то, чего нет ни в одном источнике.
Непрозрачный след. Нельзя показать, из какого правила и какого источника вырос ответ.
Остальные четыре строки таблицы: дообучение модели неуправляемо, генерация обгоняет проверку, каждое новое подключение к прибору или системе становится ещё одним каналом влияния на систему. Наконец, круглосуточная работа модели у постели каждого пациента стоит дорого.
Ни один из этих пунктов не претензия к качеству. Даже очень хорошая модель остаётся невоспроизводимой и непрозрачной по своей природе. Сколько ни поднимай её точность, на вопрос заведующего отделением она не ответит.
Есть и производные беды, врачу знакомые лучше, чем инженеру. Первая — искушение поручить модели самой читать руководства и пополнять базу медицинских знаний. В учебных материалах платформы это названо прямым путём к катастрофе. Ошибка, попавшая в базу, дальше расходится по всем заключениям уже как истина.
Вторая — вырождение проверки. Машина предлагает изменения быстрее, чем эксперт успевает их прочитать. Очередь растёт, и её проще всего разгрести, ускорив одобрение. Формально человек проверяет всё. Фактически его подпись превратилась в штамп.
Из этого обычно делают один из двух выводов: «не применять ИИ» или «доверять ИИ». Авторы подхода считают оба ответа одинаково слабыми. Их третий путь: каждому недостатку модели противопоставлен свой архитектурный барьер. Барьер — не инструкция, которую можно нарушить. Это устройство, при котором нежелательному действию просто нельзя случиться.
Главная формулировка звучит так. Барьеры не делают модель лучше. Они определяют, где ей место и куда её выход не может попасть.
Границу разработчики HealthOS проводят так. Может ли врач сам проверить, на чём основана рекомендация, не разбираясь в устройстве программы? Модель, работающая как «чёрный ящик», этот тест не проходит по своей природе. Правило, утверждённое человеком и переведённое в исполняемую форму, проходит. Врач видит правило, находит, из какого источника оно взялось, и может возразить по клиническим соображениям. На вопрос «почему порог именно такой» должны отвечать цитата из источника и версия утверждённого знания, а не программный код анализатора.
Модель на входе, правило у постели больного
Чтобы увидеть, где модели место, проследим два пути, которые сходятся у постели больного.
Первый путь — путь данных. Прикроватные приборы непрерывно шлют показания. Приборы передают показания в разных форматах, поэтому сначала показания проходят через шлюз — программу-переводчик, которая приводит их к единому виду. Дальше данные попадают в вычислительное ядро — программу, которая применяет к ним правила.
Второй путь — путь знания. Откуда берутся сами правила? Сначала программа-помощник на основе языковой модели собирает источники: клинические руководства, терминологические словари. Она выписывает дословные цитаты с точным местом — издание, раздел, страница. Из этого получается черновик правила. Черновик проходит автоматическую проверку на противоречия. Потом его читает врач. Силу правилу даёт только его утверждение. Утверждённое правило переводится в форму, которую компьютер исполняет быстро и однозначно.
Похоже на клинический протокол и карту назначений. Протокол пишут, обсуждают и подписывают. По нему составляют карту, и медсестра работает по карте. Каждая строка карты восходит к пункту протокола. Помощник на основе модели приносит черновик протокола. Подписать его он не может. Вписать строку в карту — тоже.
Вернёмся к ночной смене. У постели работало одно из таких правил. Чтобы на утреннем разборе найти его, нужны четыре механизма.
Граф знаний — хранилище медицинских правил в виде сети понятий и связей. Условный пример: «синусовый ритм» — «имеет условие» — «частота в таких-то границах». Машина может проверить граф на противоречия, врач — прочитать и утвердить. У каждого правила в графе есть версия и автор.
Снимок — утверждённое состояние графа на определённый момент. Как редакция протокола с датой и подписью: протокол потом дорабатывают, а эта редакция уже не изменится.
Компиляция — перевод утверждённого снимка в исполняемую форму. Её результат называют пакетом. У постели больного работает пакет, а граф и модель остаются в стороне.
Детерминированное исполнение — свойство вычислительного ядра всегда давать один ответ на одни и те же данные при одном и том же пакете. Как таблица умножения или откалиброванные весы.
Всю эту среду вместе с её границей разработчики HealthOS называют операционной системой деятельности (ОСД). Слова «операционная система» здесь не про программу на компьютере. ОСД определяют как закрытый информационный периметр, который по своему устройству делает воспроизводимой всю цепочку работы со знанием. Знание в нём создаётся, утверждается, применяется и уточняется, и каждый шаг можно повторить и проверить.
Слово «закрытый» стоит пояснить. Из периметра доступны только заранее объявленные направления связи. Всё остальное недоступно. В учебных материалах академии HealthOS для разработчиков сказано так: закрытый периметр переносит доверие с процедуры на конструкцию. Раньше говорили «сотрудник не станет выносить данные». Теперь говорят «вынести некуда».
Схема ОСД целиком. Стрелки показывают, куда движутся данные и знание.
Схема операционной системы деятельности: слева — путь данных от прикроватных приборов через шлюз и анализаторы к вычислительному ядру; справа — путь знания: модель работает только на входе, силу снимку графа даёт человек, компилятор превращает снимок в пакет для ядра; внизу — запись: журнал аудита и журнал квитанций, откуда разобранные наблюдения возвращаются кандидатами на изменение. Источник: учебный курс Академии HealthOS.
Модель стоит только на входе пути знания: обработка внешних источников и при разборе наблюдений, вернувшихся из практики. Всё устройство вокруг неё — периметр, проверки, подпись врача, запрет записи — можно назвать жёсткой обвязкой. По-английски такую оболочку вокруг модели называют harness. Модель работает только внутри этой обвязки. Ту часть системы, что работает с живыми пациентами, — путь данных и ядро у постели больного — назовём продуктивным контуром. В нём исполняются только утверждённые правила, которые можно проверить. На путь данных и в ядро у постели больного модель не попадает. Её черновик попадает в граф только после проверки. Силу правило получает, когда врач утверждает снимок графа. Квитанция — запись, которая сопровождает каждый вывод: какое правило его дало и на каких данных.
Сколько места остаётся модели? Авторы делят весь путь знания на одиннадцать звеньев: от перечня доверенных источников до цикла, который возвращает наблюдения на рассмотрение. Модели работают на трёх из них: при работе с источниками, при подборе опорных цитат и при разборе наблюдений как кандидатов на уточнение. Утверждение, компиляция и применение у постели им не принадлежат. Всё, что производит помощник, — черновик. Он поставляет материал для решения, но решать не вправе. Права записи в действующую базу знаний у него нет.
У подписи врача есть тонкость. Врач подписывает не изменение само по себе, а пару: новые правила и то состояние базы знаний, которое они обеспечивают. Допустим, врач полчаса читал предложение уточнить порог, а за это время коллега утвердил другое изменение в соседнем правиле. База уже не та, которую видел первый врач. Его подпись не имеет силы, и предложение проверяют заново. Так врач никогда не подписывается под тем, чего не видел.
Проблема очереди из первого раздела решается тем же способом. Если предложения копятся быстрее, чем эксперты их читают, система приостанавливает их производство. Ускорять одобрение нельзя. Пакет правил у постели сам себя не обновляет: новое правило попадает туда только через утверждённый выпуск.
У такой архитектуры ОСД есть еще одно положительное качество — низкое энергопотребление. У постели больного в реальном времени работают модули оценки и безопасности. Обращений к языковой модели там нет. Модель трудится раньше, при подготовке знания, и затраты на эту подготовку раскладываются на все часы наблюдения. Авторы подсчитали, сколько электричества тратят три варианта анализатора за один пациенто-час, то есть за час непрерывного наблюдения за одним пациентом. Это модельная оценка, а не измерение: сами авторы называют свои числа модельными допущениями, стенда для замера пока нет.
| Вариант | Джоулей на пациенто-час | Мультипликатор |
|---|---|---|
| Анализатор на правилах | ~ 3 600 | 1 |
| Малая языковая модель | ~ 59 400 | 16,5 |
| Большая языковая модель | ~ 545 400 | 151,5 |
Чтобы почувствовать масштаб, переведём первый ряд в ватт-часы. 3 600 джоулей — один ватт-час: столько расходует светодиодная лампа на 10 ватт за шесть минут. Большая модель за тот же час наблюдения тратит около 151 ватт-часа — та же лампа горела бы пятнадцать часов. При круглосуточном наблюдении эта разница умножается на каждую койку и каждый час.
Подписанная ошибка
Каждый вывод ядра сопровождается записью: какая версия правил сработала, кто её утвердил, на каком отрезке сигнала. Запись привязана к пакету так, что подмену видно сразу. Из содержимого пакета вычисляется короткая строка символов. Одинаковое содержимое всегда даёт одинаковую строку, малейшее изменение — совсем другую. Такую строку называют цифровым отпечатком. Журнал аудита неотрекаем: от записи в нём нельзя отказаться задним числом.
Разработчик заявляет, что любой прошлый эпизод можно перезапустить с тем же пакетом и получить тот же результат. Это нужно для исследований, разбора инцидентов и проверок регулятором. Второе свойство разработчик называет «иммунитетом к дрейфу»: пакет правил не меняется сам собой. Решение, принятое в первый год с пакетом версии 1.0, при воспроизведении на третий год с тем же пакетом повторится. Оба свойства — заявления разработчика о своей архитектуре. Независимого измерения за ними нет. Но их легко опровергнуть: достаточно одного повтора с тем же пакетом, давшего другой вывод.
Кажется, что доверие достигнуто. Здесь концепция сама ставит себе предел.
Представьте правило с неверным порогом. Кардиолог ошибся, утвердил его, ошибку не заметили. Правило скомпилировано и исполняется безупречно. Журнал подтвердит, что сработало именно оно, в утверждённой версии, на этом отрезке сигнала. Каждый повтор даст тот же ответ. И каждый раз ответ будет неверным.
Концепция называет это прямо: подписанный документ может оказаться подписанной ошибкой. Подпись и журнал доказывают целостность — что именно исполняется и откуда оно взялось. Правильность — верно ли правило с медицинской точки зрения — они не доказывают. Её доказывают отдельно: воспроизводимыми свидетельствами, испытаниями, рассмотрением людьми. Система, которая смешивает эти два вида гарантий, по словам авторов HealthOS, обманывает.
Второй принцип называется отказом в безопасную сторону: любая неразрешимая ситуация останавливает процесс. Для понятия нет правила перевода при компиляции — компиляция стоп. Непройденная проверка при выпуске — выпуска нет. Система предпочитает отсутствие ответа неподтверждённому ответу.
В учебных материалах для разработчиков то же правило сказано коротко: проверка сообщает результат, а заслон не пропускает. Разница видна в момент, когда сломалась сама проверка. Представим: программа, сверяющая отпечаток пакета перед выпуском, упала с ошибкой. Проверка сообщит о сбое, и выпуск пойдёт дальше. Заслон обязан выпуск остановить. Заслон, который при сбое мягко пропускает, защищает ровно до первого сбоя.
Как доверие накапливается
Если механизм не гарантирует правильности, что же он даёт? Ответ виден на одном обороте цикла уточнения знания. Пример условный — так его подают сами авторы, — но каждый шаг в нём штатный.
Признак «синусовый ритм» на электрокардиограмме. Программа-помощник собирает определения из клинических руководств и терминологических словарей. Она отмечает, где формулировки расходятся. Затем предлагает определение с явными условиями: границы частоты, требования к зубцу P (участку кардиограммы, который отражает работу предсердий), допустимую вариабельность. Кардиолог сверяет черновик с источниками. Он сужает область применения — например, исключает ритм электрокардиостимулятора — и утверждает. Определение компилируется и начинает работать. Приходит фрагмент кардиограммы. Сначала проверяется, применимо ли правило: достаточно ли качество сигнала, соблюдены ли предпосылки. Затем ядро выносит заключение «синусовый ритм: подтверждён». Вместе с заключением появляется свидетельство: какая версия знания и какой выпуск пакета его дали.
Проходит время. При разборе накопленных записей обнаруживается систематическое расхождение. У пациентов с определённой сопутствующей терапией признак срабатывает на самой границе частотного условия. Помощник группирует такие случаи и готовит предложение уточнить границу. Предложение — кандидат, у него нет силы. Эксперт его рассматривает и принимает. Уточнение проходит те же проверки, что и исходное определение. Собирается новый снимок. Повторный прогон на контрольных записях показывает: расхождение устранено, остальные случаи не затронуты.
Старый снимок при этом не стирается. Он остаётся в истории рядом с новым. В любой момент можно ответить на четыре вопроса: какое определение действовало, кто его утвердил, почему его уточнили и чем подтверждено уточнение. Авторы называют этот оборот замкнутым циклом дистилляции истины. Перегонка отделяет вещество от примесей. Цикл раз за разом отделяет проверенное от догадок.
Так работает формула, которую разработчики вынесли на страницу кардиологического продукта: несогласие врача улучшает систему. Замечание врача не пропадает в разговоре в ординаторской. Оно превращается в обезличенное предложение, без сведений, по которым можно узнать пациента. По нему исправляют правило, записывая, кто внёс исправление и в какой версии. Исправление действует для всех будущих заключений.
Отсюда позиция этой статьи. Сразу оговорим: это оценка автора, а не результат измерения.
Механизм сам по себе даёт только предпосылки доверия. Доверие, по убеждению автора, появляется, когда механизм долго работает без исключений. Каждый прогон добавляет в журнал проверяемую запись. Каждый оборот цикла добавляет обоснованное уточнение. Каждый остановленный выпуск и каждое отклонённое предложение остаются записью с причинами. Через год по такому архиву видно, что система знает. Видно и другое: почему она знает именно это и какие варианты отвергла. История не переписывается, а уточнения идут тем же путём, что и исходное знание. Поэтому новый оборот прибавляет к истории, а не заменяет её. Концепция говорит об этом короче: доверие — не событие, а поддерживаемое состояние.
С обучаемой моделью, по нашему предположению, так не получается. Доверие к ней привязано к конкретной версии. Каждое дообучение даёт новый чёрный ящик, и проверенное для старой версии приходится проверять заново. В архитектуре ОДС HealthOS доверие привязано к механизму, а механизм от версии к версии не меняется.
Так доверяют опытному коллеге. Обещания тут ни при чём: годами видели, как он работает, и каждый раз могли проверить.
Границы
Подход, построенный на проверяемости, обязан мерить себя той же меркой. Границы такие.
Архитектура — не регистрация медицинского изделия и не клиническое испытание. Учебные материалы академииHealthOS требуют различать три вещи. Архитектура — это барьеры, периметр и журналы как свойства системы. Регистрация медицинского изделия — решение регулятора в конкретной стране. Клиническое испытание медицинского изделия — авторизованные измерения с участием пациентов. Одно не заменяет другое. Концепция ОДС HealthOS не заявляет о своей клинической эффективности и влиянии на исходы лечения. Эти гарантии может дать регулятор в результате прохождения государственной регистрации медицинского изделия.
Энергозатраты — модельные оценки. На данный момент они остаются расчётом.
Повтор эпизодов и «иммунитет к дрейфу» — архитектурные следствия. На данный момент они остаются экспертным мнением.
Одна область реализована, остальные — план. Основная реализованная область применения — кардиология. Дыхание, кровообращение и неврология описаны как расширения на тех же принципах, запланированные на будущее.
Перенос на другие области высокого риска — план. Соблазнительно сказать, что таблица барьеров из реанимации подойдёт для госуправления, правосудия или оценки кредитоспособности. Сами учебные материалы академии HealthOS называют это гипотезой, которая из работы в реанимации не следует.
Команда медицинскому прибору — отдельная ответственность. Подсказать врачу и изменить параметры аппарата — разные вещи. Авторы описывают поэтапный путь. Сначала система учится читать данные, потом советовать, затем она выполняет узко ограниченные команды под строгим контролем.
Заключение
Вернёмся к вымышленному разбору после ночной смены. В описанной архитектуре на вопрос заведующего есть ответ. Сработало правило такой-то версии. Утвердил его такой-то врач. Вывод получен на таком-то отрезке сигнала. Эпизод можно запустить ещё раз и получить тот же результат.
Если же при том же пакете и тех же данных вывод окажется другим, это уже не особенность работы. Это доказательство ошибки — нарушен барьер.
Предотвратила бы архитектура ОСД HealthOS само ночное молчание? Этого она не обещает. Если правило было неверным, система промолчит так же. Архитектура говорит другое: где искать ошибку и кто вправе её изолированно исправить. Исправление станет новой версией и пойдёт тем же путём в работу.
Остаётся вопрос, который архитектура не закрывает. Вырастет ли доверие врачей к ОСД HealthOS вместе с этой историей — через год, через пять лет? Это не измерено. Проверить это может только время работы без исключений. Поэтому, по убеждению автора, доверие нельзя купить вместе с моделью. Его можно только накопить.
Если вы работаете в реанимации или пишете о медицине, какой ответ на утреннем разборе убедил бы вас? Мы ищем соавторов, напищите нам на accel@rtlab.ru.