В статье, опубликованной сайтом Semiconductor Engineering 27 августа 2026 года, предлагается рассматривать внедрение искусственного интеллекта в проектирование радиочастотных схем RF как поэтапный процесс, а не как проект, требующий замены существующей платформы или полной перестройки рабочего процесса. В основе этой идеи лежит практическая проблема: значительная часть возможностей команд RF и микроволновой техники опирается на накопленные институциональные знания опытных инженеров, включая методики проектирования усилителей мощности, характеристику устройств и решения, принимаемые в процессе работы и не зафиксированные в форме, пригодной для повторного использования.
Согласно статье, утрата этих знаний увеличивает срок подготовки новых инженеров, замедляет оценку пространства проектирования и может привести к повторному проектированию, необходимость которого можно было бы выявить посредством проверки большего числа кандидатов. Поэтому первым вопросом должно быть не то, будет ли команда внедрять искусственный интеллект, а то, как создать такую возможность, не нарушая работу инструментов, на которые инженеры опираются при создании реальных конструкций.
Три этапа, которые можно выполнять параллельно
Автор Daren McClearnon, которого источник представляет как руководителя направления продуктов искусственного интеллекта и машинного обучения в Keysight, предлагает структуру из трех этапов: фиксация знаний, координация инструментов и ускорение исследования вариантов. Эта структура не требует завершать один этап до начала другого.
Фиксация опыта и превращение его в активы, пригодные для повторного использования
Источник отмечает, что опыт в области RF обычно существует не только в коде, но и распределен между инструментами, уравнениями и практическим опытом сопоставления результатов моделирования с тем, что проявляется в измеренном аппаратном обеспечении. На этапе фиксации эти знания следует преобразовать в формы, которые команда сможет запускать и совместно использовать, а позднее передавать программным агентам.
- Экспортировать схемы и топологии в Python-код с настраиваемыми параметрами.
- Записывать процедуры экспертов в виде исполняемых скриптов.
- Преобразовывать блок-схему моделирования в документированный код, понятный агентным системам.
Практическая ценность этого шага заключается не в самом использовании языковой модели, а в том, чтобы сделать внутреннюю методологию видимой и воспроизводимой, вместо того чтобы оставлять ее в памяти отдельных людей.
От написания скриптов к постановке цели
Этап координации использует зафиксированные знания. Вместо того чтобы инженер вручную писал и запускал каждый скрипт, он может задать требуемый результат, например спроектировать MMIC-усилитель мощности с коэффициентом усиления более 20 dB и выходной мощностью более 28 dBm, а затем предоставить языковой модели, подключенной к инструментам, задачу найти и вызвать подходящие инструменты.
Согласно статье, это не означает немедленного перехода к полной автономности. В настоящее время организации часто находятся между ручным программированием и использованием ранних совместных помощников, понимающих намерение инженера, при сохранении тесного человеческого контроля. Следующим шагом становятся специализированные агенты, выполняющие многоэтапные задачи с частичным делегированием и опирающиеся на ту же основу координации.
Ускорение исследования при сохранении контроля над физикой
Третий этап сосредоточен на увеличении числа конструкций, которые можно исследовать, и сокращении времени ожидания. Источник упоминает два основных инструмента: суррогатное моделирование, заменяющее ресурсоемкие электромагнитные симуляции быстрыми приближениями на основе нейронных сетей, которые для некоторых структур могут быть быстрее на два или три порядка; и оптимизацию с поддержкой искусственного интеллекта, способную одновременно работать с большим числом параметров и находить подходящие решения, используя меньшее количество симуляций.
Однако ускорение не имеет практической ценности, если результат ненадежен. Риски особенно заметны в упаковке, межсоединениях, связи, целостности питания и заземления, а также в трехмерных токах; эти факторы могут сделать быстрый и уверенный ответ далеким от поведения реального аппаратного обеспечения, а затем осложнить анализ первопричины отказов. Поэтому перед расширением масштабов делегирования физику, используемую в моделировании, необходимо сопоставить с фактическими измерениями.
Что необходимо проверить перед расширением масштаба?
В рамках этого подхода также подчеркивается важность отслеживания источника данных, а не только качества модели. Команде необходимо знать источник данных для обучения суррогатной модели, каким образом они размечались и очищались, а также какие известные предположения и ограничения в них существуют. Именно такая прозрачность определяет границы ускорения и не позволяет ему превратиться в невидимый риск.
Источник приводит пример компании Sphere Semi — разработчика RFIC, столкнувшегося с проблемой исследования только одного варианта конструкции за раз. Компания внедрила полностью определяемый кодом процесс на базе Python для выполнения этапов генерации, моделирования, ранжирования и оптимизации, запуская от сотен до тысяч кандидатов посредством совместного моделирования схем и электромагнитных процессов. Согласно приведенным в статье цифрам, этот подход обеспечил повышение производительности в 5–10 раз, улучшение изоляции на 6 dB и сокращение площади фильтра на 30% по сравнению с традиционными ручными процессами проектирования.
Редакция certi.news: фактическое изменение, предлагаемое в статье, заключается не в замене инженера независимым агентом, а в переносе разрозненных знаний в исполняемые процессы, а затем в их связывании с четкими целями проектирования и измеримыми инструментами проверки. Это делает внедрение менее зависимым от решения о выборе одной платформы и более зависимым от качества документации, данных и измерений. Однако приведенные результаты относятся к одному примеру, представленному источником, и сами по себе не доказывают, что такие же преимущества будут повторяться в каждом проекте или среде. Кроме того, вопросы, например возможность обобщения суррогатных моделей и границы их применимости при изменении упаковки, структур и данных, по-прежнему требуют отдельной проверки каждой командой.