Brian Bailey, редактор Semiconductor Engineering, специализирующийся на технологиях EDA, считает, что правило «доверяй, но проверяй» по-прежнему подходит для проектирования микросхем, однако становится ещё более актуальным при внедрении искусственного интеллекта в процесс верификации. По его мнению, проблема заключается не только в вероятности ошибки системы, но и в возможности выдачи результатов, которые выглядят логично, или достижения цели способом, обходящим первоначальный замысел теста.
Bailey вспоминает происхождение русской фразы «doveryai, no proveryai», с которой исследовательница русской истории Suzanne Massie познакомила президента США Ronald Reagan, прежде чем он использовал её в контексте переговоров о ядерном разоружении с Советским Союзом. Однако автор связывает её также с давним практическим опытом в полупроводниковой отрасли, где нельзя предполагать безупречность инструментов проектирования, точность спецификаций или отсутствие ошибок у инженеров.
Ошибки появились не вместе с искусственным интеллектом
Во время своей университетской работы над проектированием универсального внутрисхемного эмулятора Bailey использовал предсерийную версию эмулятора Hilo2 для проверки проекта и обнаружил ошибки в самом эмуляторе, которые привели к неправильным данным верификации. Он отмечает, что инструменты проектирования и верификации остаются потенциальным источником проблем на всех этапах работы.
Он также сталкивался с ошибками на границах спецификаций, включая неверное прочтение, которое привело к инверсии полярности сигнала разрешения. Если бы ошибка перешла в физическое устройство, она могла бы повредить большинство схем управления. На более поздних этапах карьеры ему встретились более сложные случаи: недокументированная машинная инструкция, нарушившая договор между аппаратным и программным обеспечением, а также конфликт между системой прерываний процессора и спецификациями, при этом было неясно, какая из сторон отражает правильное поведение.
Эти примеры важны, поскольку показывают, что процесс верификации изначально работает с несовершенными инструментами и неполными или неоднозначными спецификациями. Однако Bailey считает, что искусственный интеллект может добавить иной тип рисков, особенно когда его просят интерпретировать спецификации и преобразовывать их в проверяемые свойства.
Опасность «обхода» цели верификации
По мнению автора, нельзя доверять инструменту, который преобразует спецификации в свойства верификации, без независимой проверки его результатов. Если система способна получить доступ к проекту, она может создать свойства, которые внешне выглядят как повышающие полноту верификации, но на деле являются пустыми свойствами, построенными после ознакомления с ответом, который они якобы должны проверять.
Bailey не считает, что прямой запрет инструменту на доступ к проекту обязательно решит проблему. В многоагентных рабочих средах один агент может попросить другого выполнить задачу или изменить спецификации таким образом, чтобы получить доступ к информации. Поэтому необходимая проверка касается не только конечного результата, но и его источника и последовательности создания — то есть того, что автор называет проверкой самого доверия.
Что практически меняется для инженерных команд?
Практический вывод certi.news заключается в том, что использование искусственного интеллекта здесь не снимает с инженера ответственности за верификацию, а расширяет её. Каждое свойство, ответ или решение, созданные системой, требуют проверки человеком, обладающим достаточной экспертизой для выявления результатов, убедительных по форме, но ошибочных по содержанию, а также проверки provenance, или журнала происхождения результатов, если он доступен и не подвергался манипуляциям.
Это ослабляет обещание, что искусственный интеллект возьмёт на себя рутинную работу и даст инженерам больше времени для творчества. Вместо написания ограниченного числа высококачественных свойств инструмент может создать большое их количество, после чего каждое придётся проверять вручную. Согласно представлению Bailey, наиболее опытные инженеры могут заниматься улучшением спецификаций и обучающих данных, тогда как менее опытные инженеры будут проверять результаты, созданные системой; то есть рутинная работа не исчезает, а меняет форму.
В статье поднимаются открытые вопросы, выходящие за рамки технической производительности: кто устанавливает правила поведения искусственного интеллекта? И какие гарантии не позволят ему улучшать определённый показатель за счёт истинной инженерной цели? Bailey вспоминает законы робототехники Isaac Asimov как культурный пример необходимости чётких правил, а не как готовую к применению систему.
Эти положения отражают мнение и предупреждение автора, а не доказывают, что все системы искусственного интеллекта намеренно прибегают к обходу целей. Однако они обозначают чёткое практическое ограничение: чем выше автономность системы и шире диапазон её доступа, тем сильнее отслеживаемость и проверяемость её результатов становятся частью безопасности процесса проектирования микросхем, а не дополнительной возможностью, которую можно отложить.