Искусственный интеллект (далее — ИИ) и в целом нейросети в действительности присутствовали в лабораторной деятельности уже достаточно давно, просто пользователи не знали об этом. Как правило, это какие-либо отдельные функции в лабораторном оборудовании (например, функции компьютерного зрения или математической обработки), позволяющие систематизировать большое количество нестандартных данных.
Но если говорить, про автоматизацию лабораторных процессов через системы с применением ИИ в более широком виде, то на сегодняшний день такие возможности сильно ограничены. И дело здесь не в технических возможностях современных ИИ и даже не в финансовой целесообразности подобных проектов.
Основная проблема — достаточно отсталая регуляторная база. Текущие основные стандарты, применяемые в лабораториях (ISO/IEC 17025 и GMP) отстают от современных технологий на не менее, чем 15-20 лет. И здесь нет никакого преувеличения. Данные стандарты в действительности не позволяют (или сильно ограничивают) использование не то, чтобы последние технологии нейросетей, но и уже являющиеся чем-то обыденным — обычные облачные технологии. Данные стандарты сейчас более и менее продуманы только для работы с простым локально установленным программным обеспечением, но и там есть нюансы.
Каковы ограничения и проблемы закладывают стандарты для испытательных лабораторий?
Управление изменениями
Общее требование во многих подобных стандартах — это полное управление планируемыми и происходящими изменениями в компьютеризированных системах.
В ISO/IEC 17025 п.7.11.2 звучит следующим образом:
<…> При любых изменениях, включая изменения конфигурации программного обеспечения лаборатории или модифи кации коммерческого программного обеспечения, они должны быть утверждены, документированы и валидированы до введения их в действие.
Глава 10 Приложения 11 GMP звучит следующим образом:
Любые изменения в компьютеризированной системе, включая конфигурацию системы, должны проводиться только контролируемым способом в соответствии с установленной процедурой.
Под управлением (контролем) изменениями в данном случае понимается, что пользователь:
- полностью планирует предстоящее изменение;
- полность контролируемо его проводит;
- оценивает результат каждого изменения;
- при необходимости — валидирует его;
- документирует все это и само изменение.
При этом, как видно из прямых цитат из стандартов — фразы абсолютны, т.е. касаются АБСОЛЮТНО ЛЮБОГО изменения в программном обеспечении и его окружении, т.к. компьютеризированная (информационная) система, которой необходимо управлять, это комплекс средств, благодаря которым ПО выполняет свои функции (компьютеры, операционные системы, связанное программное обеспечение, сервера, другие элементы сети, периферийные устройства, др.).
Вероятно из-за низкой практической компетентности разработчиков данных стандартов в вопросах ИТ, данные требования казались им вполне логичными, обоснованными и выполнимыми. Если грубо упростить, то логика всех подобных стандартов (во всех вопросах) основывается на том, что мы “что-то” валидируем (доказываем, что это “что-то” выполняет все что надо и подходит для всех задач), а потом не меняем и только мониторим, что все по прежнему остается валидным. И если смотреть через призму этой логики, то описанные нормативные требования к компьютеризированным системам абсолютно соответствуют этому общему подходу.
В чем итого проблема? Проблема во-первых в очень большом количестве элементов современных компьютеризированных систем, которые могут быть изменены. Исходя из требований стандартов необходимо отслеживать (и управлять ими), в том числе, например, такие неожиданные изменения как:
- замена / добавление элементов памяти на серверах;
- замена WiFi роутеров;
- замена кабелей в сети;
- обновление браузера (для web программного обеспечения);
- замена монитора на ПК;
- замена принтера или обновление прошивки принтера;
- обновление различных библиотек, драйверов и другого фонового ПО, не связанного напрямую с операционной системой;
- обновление ПО для чтения PDF файлов.
что очевидно — невозможно.
Специалистам, не занимающимся регуляторикой в вопросах программного обеспечения, кажется что отслеживать и предупреждать только обновление целевого ПО, операционной системы на ПК, где оно установлено и целом все, но как видите это не так.
Во-вторых, про эти изменения как минимум надо знать и иметь возможность отказаться от них хотя бы для того, чтобы сначала “оценить, валидировать и документировать” эти изменения, а только потом обновить и начать с ними работать. Но на практике, для ПО, которое работает на серверах разработчиков и предоставляется для пользования (предоставляется доступ), не предусматривается, что пользователь может как-то влиять на изменения / обновления. Пользователя просто уведомляют, что было совершено обновление (без реальной детализации), и пользователь принимает это к сведению. Или вообще даже не уведомляют.
Также, что касается ИИ, то есть нейросети, которые являются самообучаемыми и соответственно сама суть которых заключается в непрерывном изменении каждый раз после каждого действия с ними.
Валидация и верификация
Перед введением в работу, компьютеризированная система должна пройти подтверждение, что она соответствует требованиям (верификация) и своему назначению (валидация). Если более подробно, то под валидацией понимается некая проверка того, что компьютеризированная система способна воспроизводимо приводить к ожидаемым от нее результатам.
Этот подход основывается на традиционном в технике принципе “черного ящика”:
даже НЕ понимая полностью как работает “черный ящик”, если подтвердить в специальном (зачастую упрощенном) эксперименте, что это “что-то” систематически выдает ожидаемый результат в ответ на определенные действия, то значит и в будущем он будет выдавать тот же самый ожидаемый результат в ответ на те же действия.
Если еще проще:
если я вчера делал X и получал Y, сегодня делал X и тоже получал Y, то я считаю, что нет никаких оснований думать, что, если черный ящик не менялся, то если я завтра сделаю X, что не смогу также получить Y.
Этот подход работает в классической технике, где все части устройств стандартизированы и работают со стандартизированными “входами” — то есть этот подход применим к “алгоритмизированным” машинам.
Но нейросети (включая ИИ) не являются «алгоритмизированными» машинами. Они являются “вероятностными” машинами, которые по своему определению могут выдавать разные результаты на одни и те же “входы”. То есть доказательство работоспособности ИИ не гарантирует, что та же нейросеть будет выдавать тот же ожидаемый и пригодный результат в будущем. Особенно это касается “самообучаемых” нейросетей. Нейросети в этом плане ближе к работе людей.
Перепроверка расчетов
Также есть еще одно рудиментарное максимально неадекватное требование ISO/IEC 17025:
7.11.6 Расчеты и передачи данных должны подвергаться надлежащим систематическим проверкам
Разберем дословно, что написано в этом положении:
- ВСЕ расчеты (здесь не сказано про «критические» или иное сужение списка);
- должны проверяться;
- проверяться систематически — то есть с определенным периодом, а не один раз, что было бы логично для ПО с доказанной валидностью.
Либо разработчикам казалось, что это требование вполне логично из-за непонимания, что расчеты в программном обеспечении — это не только расчеты по формулам в методиках, а они происходят буквально непрерывно даже в самых нематематическом функционале, либо разработчики случайно некорректно выразились в стандарте, но положение написано так как оно есть и накладывает обязательства, которые там указаны.
В современных нейросетях расчетов еще больше, чем просто в обычном алгоритмизированном ПО — сама нейросеть это большая математическая машина со сверх сложными расчетами вероятностей (весовых коэффициентов), которые не то что периодически, но даже один раз проверить невозможно (тем более, что это все скрыто от пользователя).
Кто носитель ответственности?
В этом вопросе, текущая нормативная документация максимально отсталая от сегодняшних реалий. За каждое действие в лабораторной деятельности должен быть ответственный, т.к. (хотя это не написано прямо) предполагается, что результат этого действия связан с действиями подписанта, а значит он и ответственный за него.
Но сегодняшние реалии заключаются в том, что уже сейчас может быть такое, что прибор все делает сам, контролирует сам себя, выдает все результаты, а специалист “просто нажимал на кнопки”, никак не мог повлиять на машину и вообще очень слабо понимает, что делает этот прибор. Но по итогам за результат от этого прибора подписывается именно тот, кто “нажимал на кнопки”, хотя может быть такое, что большее влияние на результат и ответственность за него имеет производитель этого прибора, сервисный инженер или техник в этой лаборатории, а не обычный оператор.
Это типичный пример вопроса из другой более «человеческой» сферы:
“Кто виновен в ДТП с автомобилем, который ехал на автопилоте?”:
- водитель (который только “нажал кнопку” куда ехать);
- производитель автомобиля;
- дилер автомобиля;
- контролирующий орган, который одобрил такой автомобиль;
- никто не виноват.
Если ИИ принимает решение о соответствии или занимается интерпретацией результатов по серии результатов испытаний, то должен ли кто-то подписываться за них? Если ИИ занимается математической обработкой результатов испытаний или мониторинга, то кто ответственен за них? Если нейросеть отслеживает корректность выполнения работ работниками лабораторий, то может ли ИИ утверждать протоколы или подписываться за “проверено” ? На этот вопрос решения нет и скорее всего вам скажут, что даже не понимая что происходит, но надо найти “крайнего”, кто будет за это подписываться и нести ответственность, даже если он ни на что не влияет.
Если вы хотите автоматизировать лабораторию, предлагаем наш LIMS — пока без нейросетей, но зато полностью валидный и максимально снимающий лишнюю рутинную работу с лаборатории:
Reference LIMS (R-LIMS) — у вас НЕ БУДЕТ проблем с валидацией и валидностью LIMS >>
