Формална верификация: единственият начин да удовлетворите AI регулаторите
Разговорът, който никога не минава добре
Представете си тази сцена. Тя се случва всяка седмица в зали за заседания из цяла Европа, на прегледи в Агенцията по храните и лекарствата, в офиси за застрахователна оценка на риска. Инженер по изкуствен интелект представя най-новата си система пред регулатори, адвокати или оценители на риска.
„Нашата автоматична инсулинова помпа постигна точност от 99,97% в 50 милиона тестови сценария“, обявява гордо инженерът, кликвайки към слайд, пълен с впечатляващи показатели. „Най-съвременното постижение. По-добро от всеки човешки ендокринолог.“
В залата настъпва тишина. Регулаторът се навежда напред.
„Значи ми казвате“, казва тя бавно, „че от всеки 10 000 инсулинови дози, които това устройство прилага... три от тях може да са грешни?“
Инженерът се понамества неловко. „Ами, статистически погледнато...“
„Само в Германия около 7 милиона души имат диабет, който изисква инсулинова терапия. Ако всеки човек получава само четири дози на ден, това прави 28 милиона приложения дневно. При вашия процент на грешка от 0,03%...“ Тя прави изчисленията в бележника си. „Това са 8 400 потенциални грешки в дозирането. Всеки ден.“
„Но повечето от тях няма да са клинично значими...“
„Можете ли да ми кажете кои ще са?“
Тишина.
„Можете ли да ми кажете кога ще настъпи следващата повреда? Можете ли да ми кажете защо ще се повреди?“
Отново тишина.
„Тогава, боя се, не можем да одобрим това устройство.“
Този разговор, в различни форми, се повтаря постоянно, докато ИИ преминава от изследователските лаборатории към физическия свят. И той разкрива фундаментална епистемологична пропаст между това как инженерите по ИИ мислят за безопасността и как регулаторите, юристите и съдилищата мислят за нея.
Езиковата бариера, която не е свързана с езика
Когато инженерът по изкуствен интелект каже „99,97% точност“, той искрено вярва, че описва нещо впечатляващо и безопасно. В света на показателите за машинно обучение това число би било празнувано. Щяха да се публикуват научни статии. Инвеститорите щяха да са развълнувани.
Но регулаторът чува нещо съвсем различно. Той чува: „Съществува малка, но различна от нула вероятност тази система да се провали катастрофално, и нямаме представа кога, къде или защо ще се случи това.“
Това не е комуникационен проблем. Не става въпрос за това, че инженерите се нуждаят от по-добри презентационни умения или че регулаторите се нуждаят от техническо обучение. Това е фундаментален сблъсък между две различни концепции за това какво всъщност означава „да знаеш, че нещо работи“.
В потребителския софтуер вероятностните подходи са напълно приемливи. Ако Netflix препоръча филм, който мразите, никой не умира. Ако Spotify предложи песен, която не отговаря на вкуса ви, най-лошият случай е леко раздразнение. Тези системи могат да си позволят понякога да грешат, защото цената на грешката е тривиална.
Но изкуственият интелект бързо излиза извън рамките на потребителските препоръки и навлиза в области, където грешката има физически, правни и морални последици: автономни превозни средства, вземащи решения за част от секундата относно пешеходци, медицински устройства, изчисляващи дозите на лекарства, индустриални роботи, работещи рамо до рамо с човешки работници, финансови системи, одобряващи или отказващи кредити, които определят дали семействата могат да си купят дом.
В тези области „доста сме сигурни, че работи“ не е достатъчно. Съдилищата не приемат вероятностни разпределения като доказателство. Застрахователните актюери не могат да остойностят полици за неизвестни видове повреди. Регулаторните органи не могат да одобрят устройства, които биха могли да убият хора по причини, които никой не може да обясни.
Защо тестването, колкото и обширно да е, не може да гарантира безопасност
Доминиращата парадигма в оценката на изкуствения интелект днес е емпиричното тестване върху отделени набори от данни. Обучавате модела си върху набор от данни A, след което го оценявате върху набор от данни B. Ако се представи добре на B, приемате, че е „научил“ основната задача и ще се справи в реални условия на внедряване.
Този подход има три основни проблема, които никакво количество тестване не може да реши.
Проблем първи: Безкрайното входно пространство
Тестването може да демонстрира само наличието на грешки, никога тяхното отсъствие. Колкото и тестови случаи да изпълните, вие вземате проби от безкрайно входно пространство. Система, управляваща медицинско устройство, трябва да се справи не само с тестовите сценарии, които сте си представили, но и с всяка възможна комбинация от физиологии на пациенти, условия на околната среда, показания на сензори и гранични случаи, които реалният свят в крайна сметка ще създаде.
Представете си, че се опитвате да докажете, че в купа сено няма игли, като произволно вдигате шепи сено. След като прегледате милион шепи и не намерите игли, не можете да заключите, че купата е без игли. Можете само да кажете, че все още не сте намерили такава. Тестването работи по същия начин. Колкото и сценарии да преминат, следващият може да се провали.
Проблем втори: Уязвимостта към противникови атаки
Дълбоките невронни мрежи са особено уязвими към противникови входни данни. Това са внимателно създадени смущения, които карат моделите да се провалят катастрофално, докато изглеждат нормални за човешките наблюдатели.
Моделът може да разпознава правилно знаците „Стоп“ в 99,99% от случаите, но малък стикер, поставен на точно определено място, може да го накара уверено да разпознае знака като знак за ограничение на скоростта. Моделът може да разпознава точно медицински състояния в хиляди рентгенови снимки, но специфичен модел на шум, невидим за човешките рентгенолози, може да го накара да пропусне очевидни тумори.
Това не са само теоретични притеснения. Изследователи са демонстрирали adversarial атаки срещу всеки основен клас архитектури на невронни мрежи. Атаките стават все по-лесни за изпълнение, докато защитите остават непълни.
Тестването не може да предпази от adversarial уязвимости, защото повърхността за атака е безкрайна. Ще трябва да тествате не само нормалните входни данни, но и всяко възможно изменение на всеки нормален вход. Това е математически невъзможно.
Проблем трети: Разпределителна промяна
Реалният свят не стои на едно място. Разпределението на данните, върху които е обучен вашият модел, ще се промени с времето. Популациите на пациентите се променят. Условията на шофиране се развиват. Производствените процеси варират. Настъпва влошаване на сензорите.
Модел, който се представя перфектно с днешните данни, може да се провали мълчаливо, когато утрешните данни се отклонят извън неговото тренировъчно разпределение. И за разлика от явните грешки, които сриват програмите, тези провали често произвеждат уверени, правдоподобни, но грешни резултати.
Тестването с днешните данни не ви казва нищо за утрешното представяне. Докато забележите провала в производствена среда, вредата вече е настъпила.
Формална верификация: математиката като универсален език на безопасността
Формалната верификация предлага съвсем различен подход. Вместо да пита „работеше ли системата върху тези тестови случаи?“, тя пита „можем ли математически да докажем, че системата ще изпълни дадено свойство за всички възможни входни данни?“
Разликата е дълбока. Тестването взема проби от входното пространство. Верификацията разсъждава изчерпателно върху цялото пространство.
Представете си роботизирана ръка, която работи заедно с хора във фабрика. Искаме да гарантираме свойство за безопасност: „Ръката никога не трябва да надвишава 2 метра в секунда, когато в радиус от 1 метър е засечен човек.“
Подходът на тестване прогонва ръката през хиляди сценарии със симулирани хора на различни позиции и скорости, като измерва дали ограничението за безопасност някога е нарушено. Ако не се наблюдават нарушения, системата се обявява за „безопасна“. Но следващият сценарий, този, който не е бил тестван, може да е този, който нарани работник.
Подходът на верификация е коренно различен. Вземаме математическия модел на системата за управление, включително невронната мрежа, която обработва сензорните данни, и контролера, който генерира команди за двигателите. Изразяваме свойството за безопасност като формално ограничение. След това използваме специализирани алгоритми, наречени SMT (Satisfiability Modulo Theories) решаватели, за да отговорим на точен въпрос: „Съществува ли НЯКАКВА входна конфигурация, в рамките на валидния работен диапазон, за която изходната скорост надвишава 2 m/s, когато е засечено присъствие на човек?“
Решавателят не тества случайни точки. Той анализира математическата структура на цялата система. Разсъждава върху геометрията на функционалното пространство. Ако върне „UNSAT“ (неудовлетворимо), имаме математическо доказателство, че такъв нарушаващ вход не съществува. Свойството за безопасност важи не само за случаите, които сме тествали, а за всеки възможен случай, който би могъл да се появи.
Това е разликата между „проверих много мостове и нито един не се срути“ и „физиката на тези материали математически гарантира, че този мост не може да се срути под това натоварване“. Едното е емпирично наблюдение, подлежащо на преразглеждане. Другото е логическа сигурност.
Защо съвременният ИИ се съпротивлява на верификацията
Ако формалната верификация е толкова мощна, защо не я използват всички? Защо компании като OpenAI и Google разчитат на „red teaming“ (хора, които се опитват да разбият модела) вместо на математически доказателства?
Отговорът се крие в архитектурните избори, които индустрията е направила. Съвременните големи езикови модели и дълбоките невронни мрежи са проектирани за изразителност, а не за верифицируемост. Те са оптимизирани да генерират творчески резултати, а не да бъдат математически анализируеми.
Типичен трансформен модел има милиарди или трилиони параметри. Той използва сложни, нелинейни активационни функции като GeLU или Swish. Математическата сложност на верифицирането на такава система нараства експоненциално с броя на невроните и дълбочината на мрежата.
Доказването на свойство върху трансформен модел с милиард параметри е изчислително неосъществимо. Вселената би достигнала топлинна смърт, преди решавателят да приключи с изследването на всички математически клонове. Индустрията е изградила системи, толкова сложни, че дори техните създатели не могат да ги анализират напълно.
Това е дизайнерско решение, а не неизбежност. Индустрията се фокусира върху впечатляващи демонстрации и резултати от бенчмаркове, без да обмисля дали получените системи някога биха могли да бъдат безопасно внедрени в регулирани среди.
Архитектурата на Dweve: Проверима по дизайн
В Dweve взехме различни архитектурни решения. Проектирахме системите си от самото начало да бъдат проверими, защото разбрахме, че корпоративните и индустриалните клиенти в крайна сметка ще трябва да удовлетворят регулаторите, а не просто да ги впечатлят.
Нашият подход съчетава две ключови иновации, които правят проверката осъществима.
Откриване на двоични ограничения: Проста математика
Вместо масивни невронни мрежи с плаваща запетая с милиарди непрекъснати параметри, системите на Dweve използват Откриване на двоични ограничения. Знанието се представя като дискретни логически ограничения, а не като научени непрекъснати тегла.
Нашата библиотека Dweve Core съдържа 1 937 хардуерно оптимизирани алгоритъма, изградени върху двоични операции: XNOR, AND, OR, POPCNT. Тези операции имат прости и добре разбрани математически свойства. Едно двоично ограничение или е изпълнено, или не е. Няма вероятностна несигурност.
Като ограничаваме математиката до прости линейни зависимости и булева логика, драстично намаляваме пространството за търсене при проверката. Проблеми, които биха били неразрешими за непрекъснати невронни мрежи, стават разрешими за нашите системи с двоични ограничения. Проблемът с проверката се трансформира от невъзможна нелинейна оптимизация в разрешими проблеми от типа на смесено целочислено линейно програмиране (MILP) или SAT.
Това все още са изчислително трудни проблеми, но за размера на системите, които внедряваме в критични за безопасността приложения, съвременните решаватели могат да се справят с тях за секунди или минути, а не за векове.
Архитектура с шест слоя на ограничена автономия
Не се опитваме да проверяваме всеки аспект на AI възприятието. Признаването, че „пикселна мрежа представлява човек“, по своята същност е размита, вероятностна преценка. Не можете формално да докажете, че разпознаването на образи винаги е правилно, защото правилността зависи от субективни определения.
Вместо това прилагаме слоеста архитектура за безопасност, при която вероятностните AI компоненти са ограничени от формално проверени логически ограничения. AI може да предлага действия, но тези предложения трябва да преминат през проверени порти за безопасност, преди да бъдат изпълнени.
Dweve Nexus прилага шест слоя на прилагане на безопасността:
- Проверка на намеренията: Потвърждава, че AI действията съответстват на заявените цели
- Ограничена автономия: Твърди граници за това кои действия са допустими, независимо от предложенията на AI
- Модерация на съдържанието: Филтрира изходите за безопасност и уместност
- Прилагане на етиката: Гарантира спазването на определени етични ограничения
- Откриване на аномалии: Идентифицира кога поведението на AI се отклонява от очакваните модели
- Наблюдение в реално време: Непрекъсната проверка, че инвариантите за безопасност се поддържат
Ключовият извод е, че трябва само формално да проверим слоевете за безопасност, а не цялата AI система. Дори ако основният AI допусне грешка, слойът за ограничена автономия математически гарантира, че опасните команди никога не достигат до изпълнителните механизми.
Регулаторната математика: защо верификацията създава бизнес стойност
За нашите клиенти формалната верификация не е академично упражнение. Тя е конкурентно предимство, което се превръща пряко в бизнес резултати.
По-бързо регулаторно одобрение
Когато производител на медицински изделия се обърне към FDA или EMA със система, задвижвана от изкуствен интелект, регулаторите са резонно предпазливи. Те знаят, че изкуственият интелект може да бъде непредсказуем. Стандартните процедури за одобрение изискват години клинични изпитвания, за да се докаже статистически безопасността.
Но производител, използващ формално верифицирани Dweve компоненти, може да промени разговора. Вместо да представи резултати от тестове, които показват „не сме наблюдавали откази досега“, той може да представи математически доказателства, които показват „отказите са невъзможни в тези граници“.
„Не просто смятаме, че тази инсулинова помпа няма да предозира пациентите. Ето формалното доказателство, че изходната доза е математически ограничена от теглото на пациента и ограниченията на глюкозата. Нарушението не е просто малко вероятно. То е логически невъзможно.“
Това позволява ускорени пътища за преглед. Регулаторите могат да проверят доказателството независимо. Те не трябва да се доверяват на процеса на тестване; те могат да разгледат математиката директно.
Намалени застрахователни премии
Застрахователните актюери са изправени пред невъзможен проблем с традиционните AI системи. Как оценявате риска за режими на отказ, които не можете да предвидите или обясните? Резултатът е или изключително високи премии за покриване на неизвестни рискове, или клаузи за изключване, които правят застраховката практически безполезна.
Верифицираните системи променят актюерското изчисление. Ако математическо доказателство гарантира, че определени видове откази не могат да възникнат, тези режими на отказ могат да бъдат изключени от рисковия модел. Останалите рискове са количествено измерими. Премиите съответно намаляват.
Някои от нашите клиенти са видели разходите за застраховка „Гражданска отговорност“ да спаднат с 40-60% след внедряване на верифицирани защитни слоеве, просто защото застрахователите вече могат да изчислят ограничени рискове, вместо да определят цени за неограничена несигурност.
Правна защитимост
Когато AI системи причинят вреда, следват съдебни дела. При традиционните AI внедрявания защитата на системата е почти невъзможна. „Как вашата система взе това решение?“ „Не знаем точно, това е невронна мрежа с милиарди параметри...“ Този отговор не удовлетворява нито съдия, нито съдебни заседатели.
Верифицираните системи предлагат различна защита: „Ето ограничението за безопасност. Ето математическото доказателство, че ограничението не може да бъде нарушено. Вредата е настъпила извън верифицираната граница, което показва външни фактори, а не отказ на системата.“
Тук не става въпрос за избягване на отговорност. Става въпрос за способността да се демонстрира точно какви гаранции са дадени и дали те са спазени. Съдилищата разбират формалната логика. Те разбират математическите доказателства. Те не разбират вероятностните доверителни интервали.
Законът за ИИ на ЕС: Проверката става задължителна
Теоретичните предимства на формалната проверка се превръщат в практически изисквания. Законът за ИИ на ЕС, който влезе в сила през 2024 г. с поетапно прилагане до 2027 г., фундаментално променя законовите изисквания за внедряването на ИИ в Европа.
За системите с ИИ с „висок риск“, които включват медицински изделия, решения за наемане на работа, оценки на кредитоспособността и много индустриални приложения, законът изисква:
- Системи за управление на риска, които идентифицират и смекчават предвидимите рискове
- Висококачествени обучителни данни с документиран произход
- Възможности за регистриране, които позволяват проследяване на поведението на системата
- Прозрачност за потребителите относно решенията, взети от ИИ
- Механизми за човешки надзор, които позволяват намеса
- Точност, стабилност и киберсигурност, съобразени с приложението
Забележете езика: „предвидими рискове“, „проследимо поведение“, „точност, съобразена с приложението“. Това не са неясни пожелания. Те са законови изисквания с правоприлагащи механизми, включително глоби до 35 милиона евро или 7% от глобалния оборот.
Как доказвате, че сте идентифицирали и смекчили „предвидимите рискове“ за невронна мрежа с милиарди параметри, чийто процес на вземане на решения е непрозрачен дори за създателите ѝ? Как показвате, че поведението е „проследимо“, когато системата произвежда резултати чрез неразбираеми матрични умножения?
Традиционните архитектури за ИИ не могат да удовлетворят тези изисквания само чрез документация и тестване. Но проверените системи могат. Доказателството е документацията. Математическата гаранция е смекчаването. Логическите ограничения са проследимостта.
456-те домейн специалисти: Проверим мащаб
Често възражение срещу проверения ИИ е, че проверката не се мащабира. За прости системи с няколко правила, да, проверката работи. Но ИИ в реалния свят трябва да се справя със сложно възприятие и разсъждение. Как проверката може да работи в мащаб?
Dweve Loom демонстрира, че проверката и способностите не се изключват взаимно. Нашият основен модел използва 456 специализирани набора от ограничения, всеки съдържащ 64-128MB двоични ограничения. Но само 4-8 домейн специалисти се активират за всяка дадена заявка.
Тази архитектура, която наричаме ултра-разредено активиране, означава, че усилията за проверка се мащабират с активния подмножество, а не с целия модел. Не е необходимо да проверяваме всички 456 комбинации от домейн специалисти едновременно. Проверяваме логиката за маршрутизиране, която избира домейн специалистите, и проверяваме набора от ограничения на всеки домейн специалист независимо.
Системата за маршрутизиране Permuted Agreement Popcount (PAP) използва откриване на структурни модели, за да избере подходящите домейн специалисти. Този слой за маршрутизиране сам по себе си е формално проверим, защото работи с дискретни двоични операции с добре дефинирани математически свойства.
Резултатът е система, която може да се справя със сложни задачи от реалния свят, като същевременно запазва практическата осъществимост на проверката. Получаваме ползите от способностите на архитектурите с смесица от експерти, заедно с ползите за безопасност от формалната проверка.
Внедряване: Как всъщност изглежда проверката
За организациите, които обмислят внедряването на проверен ИИ, практическият процес включва няколко етапа.
Етап 1: Спецификация на свойствата
Преди да започне проверката, трябва да определите кои свойства трябва да бъдат проверени. Това често е най-трудната стъпка, изискваща тясно сътрудничество между експерти в областта, инженери и екипите по право и съответствие.
Свойствата трябва да бъдат точни и математически изразими. „Системата трябва да е безопасна“ не е проверимо свойство. „Командата за скорост на мотора не трябва да надвишава V_max, когато сензорът за близост показва разстояние по-малко от D_min“ е проверимо.
В Dweve помагаме на клиентите в този процес на спецификация чрез Spindle, нашата платформа за корпоративно управление на знания. Йерархията от 32 агента включва специалисти по регулаторно съответствие, които помагат за превръщането на правните изисквания във формални ограничения.
Етап 2: Картографиране на архитектурата
Архитектурата на системата с изкуствен интелект трябва да бъде картографирана във формален модел, който инструментите за верификация могат да анализират. За системите на Dweve това картографиране е лесно, защото нашата архитектура с двоични ограничения е проектирана за верифицируемост.
За организации със съществуващи внедрявания на невронни мрежи този етап може да изисква архитектурни промени. Добавяне на слоеве с ограничена автономия около съществуващите модели, прилагане на ограничения за безопасност като верифицирани обвивки или в някои случаи замяна на неверифицируеми компоненти с еквиваленти на Dweve.
Етап 3: Изпълнение на верификацията
Съвременните SMT решаватели и инструментите за формална верификация анализират системния модел, за да докажат зададените свойства или да идентифицират контрапримери. Контрапримерите са безценни, тъй като разкриват точно кои входни данни биха могли да нарушат ограниченията за безопасност, което позволява целенасочени корекции.
За системите на Dweve верификацията обикновено отнема от минути до часове, в зависимост от сложността на ограниченията. 1 937-те алгоритъма в Dweve Core са предварително верифицирани за общи свойства на безопасност, така че верификацията често включва комбиниране на предварително верифицирани компоненти, вместо започване от нулата.
Етап 4: Сертификация и документация
Верифицираните свойства генерират доказателствени артефакти, които служат като доказателство за сертификация. Тези доказателства могат да бъдат проверявани машинно, което означава, че регулаторите могат независимо да ги проверяват със стандартни инструменти за проверка на доказателства, без да се доверяват на първоначалния процес на верификация.
Dweve Fabric, нашият обединен панел на платформата, генерира документация за съответствие автоматично от резултатите от верификацията. Същите доказателства, които удовлетворяват решавателя, се превръщат в пакета от доказателства за регулаторно подаване.
Бъдещето: Верифицираният ИИ като стандартна практика
Намираме се в повратна точка за внедряването на изкуствен интелект. Ерата на „движи се бързо и чупи неща“ приключва за приложенията с високи залози. Регулаторната среда се затяга. Отговорността нараства. Застрахователните предизвикателства се увеличават.
Организациите, които внедряват изкуствен интелект в регулирани индустрии, са изправени пред избор. Те могат да продължат с традиционните архитектури и да се сблъскат с нарастващо триене: по-дълги процеси на одобрение, по-високи застрахователни разходи, по-голяма правна експозиция, потенциално изключване от пазара, когато регулациите влязат в сила.
Или могат да приемат верифицирани архитектури, които удовлетворяват регулаторите с математическа сигурност, вместо със статистическа надежда.
Революцията във верификацията не е за това да направи изкуствения интелект по-малко способен. Тя е за това да направи изкуствения интелект надежден по начини, които имат значение за всички извън изследователската лаборатория: пациенти, оператори, застрахователи, регулатори и съдилища. Тя е за изграждането на изкуствен интелект, който хората наистина могат да внедряват с увереност.
В Dweve вярваме, че бъдещето принадлежи на системите с изкуствен интелект, които могат да докажат своята безопасност, а не просто да я обещават. Нашата архитектура, от 1 937-те верифицирани алгоритъма в Core до шестслойната ограничена автономия в Nexus до 456-те набора от ограничения за предметни области в Loom, е изградена от самото начало за това бъдеще.
Математиката на сигурността не е ограничение за напредъка на ИИ. Тя е основата за внедряване на ИИ в мащаб.
Готови ли сте да внедрите ИИ, който регулаторите могат да одобрят? Формално верифицираната архитектура на Dweve предоставя математическите гаранции, които превръщат регулаторните пречки в конкурентни предимства. Свържете се с нас, за да обсъдим как верификацията може да ускори пътя ви до пазара, като същевременно намали експозицията ви към отговорност.