Почему ИИ мало знать правильный ответ

В разработке оборудования для критической инфраструктуры, например базовых станций, искусственный интеллект (ИИ) постепенно становится новой рабочей силой. Агенты могут сами выполнять задачи, выбирать и использовать инженерные инструменты. Для такой работы нужны знания стандартов, особенностей ПО, требований к испытаниям и ограничений конкретных систем. Один из подходов к специализации – предметно-специфические языковые модели (Domain-Specific Language Models, DSLM), адаптированные для определенной области.

Свой отраслевой ИИ начинается с сильной команды, объединяющей специалистов в соответствующей сфере, разработчиков и экспертов по машинному обучению. Ей предстоит определить задачи, которые можно будет решать с помощью ИИ, подготовить данные и инструменты, выстроить обучение модели и проверку результатов – ее работы.

Обучение модели с нуля дает наибольший контроль над ее устройством и данными. Чтобы поддерживать уровень ведущих базовых моделей, нужна полноценная исследовательская лаборатория, практически недоступная большинству отраслевых компаний по затратам и компетенциям. При этом доступ к параметрам готовой модели не означает доступа к данным, методам и опыту, необходимым для воспроизведения ее обучения.

Более доступный путь – дообучение готовой модели. Небольшие языковые модели, SLM (Small Language Models. – «Ведомости. Инновации и технологии»), особенно интересны для устойчивых, повторяющихся инженерных задач: при достаточном качестве они требуют меньше ресурсов, чем крупные. Но преимущество дообученной модели может оказаться временным: новые версии универсальных моделей способны справляться с теми же задачами не хуже нее. Смена базовой модели требует новой проверки на задачах компании, иногда повторного обучения. Размер и специализация – разные характеристики: SLM необязательно является предметно-специфической, а DSLM необязательно должна быть малой.

Обычно проще и дешевле начать с сильной универсальной LLM (Large Language Model, большой языковой модели. – «Ведомости. Инновации и технологии») в отраслевой рабочей среде – харнессе. Он дает модели доступ к знаниям отрасли, документации проекта и инструментам разработки и испытаний. Это позволяет проверить полезность ИИ до вложений в обучение. Агент может сопоставлять требования, искать противоречия в коде, выдвигать гипотезы о причинах сбоя и готовить программы испытаний. Разработчики задают цель, критерии результата и границы самостоятельности, оставляя выбор способа решения агенту. Жестко расписывая каждый шаг, мы теряем часть возможностей модели. За два-три месяца на рынке успевают появиться новые версии ведущих моделей с заметным ростом результатов в сравнительных испытаниях. Если модель слаба на задачах компании, в следующем квартале стоит проверить ее новую версию на тех же задачах.

Такая среда нужна и дообученным моделям. В нашей целевой архитектуре универсальные LLM работают во всех ролях. Небольшие специализированные модели дополняют их в тестировании, отладке специализированных фреймворков, низкоуровневом программировании и эмуляции сетевого уровня (имитации работы сети для проверки оборудования и ПО. – «Ведомости. Инновации и технологии»). В «Иртее» мы считаем использование как универсальных, так и специализированных моделей практически достижимым с учетом доступных ресурсов и инфраструктуры.

Например, большая модель формулирует гипотезу о причине сбоя, а специализированная готовит сценарий ее проверки под контролем большой. Такое распределение задач и управление их выполнением называют оркестрацией. Эмулятор воспроизводит заданные условия, результаты возвращаются в общий процесс разработки. При этом подготовка сценария испытания еще не гарантирует, что гипотеза подтвердится на практике. Задача команды – настроить мультиагентный харнесс под модели и выработать методологию их совместной работы: распределять задачи, передавать результаты и проверять общий результат.

Самостоятельность агента повышает требования к постановке задачи. То, что инженер понимал из профессионального контекста, приходится формулировать явно: нужный результат, критерии оценки и ограничения. На это может уходить больше времени, чем на привычное поручение разработчику. Если новая функция мешает старой, агент может отключить старую, решив, что новая задача важнее. Новая функция заработает, но согласованное поведение продукта будет нарушено.

В команде агентов нужны роли эксперта по фреймворку (набору готовых программных компонентов и инструментов, упрощающих разработку ПО. – «Ведомости. Инновации и технологии»), проверяющего код, аудитора требований и испытателя. Эксперт помогает выбирать механизмы и учитывать ограничения используемой версии. «Слепой судья» оценивает результат по требованиям и данным испытаний, не зная автора решения и не читая его самооценку.

В тестировании есть ловушка. Модель, которая видит тесты или восстанавливает их по обратной связи, может написать код под известные случаи: он успешно пройдет эти тесты, но при изменении условий решение сломается. Есть и обратная ловушка: тесты повторяют устройство кода, закрепляя особенности, не связанные с исходными требованиями. Их приходится переписывать вместе с кодом, а пропущенные требования остаются непроверенными. Усложняется поддержка и самого кода, и тестов. Наращивание числа тестов перестает быть однозначным вложением в надежность.

Здесь открывается отдельная специализация – ИИ-агент для тестирования и проверки результата. Он должен работать со стандартами, требованиями к оборудованию, испытательными фреймворками и накопленными случаями отказов. Его задача – проверять, какое требование подтверждает тест, искать пропущенные условия и готовить испытания, способные опровергнуть решение. Часть приемочных проверок стоит поручать ИИ-агенту, который не участвовал в разработке решения, и не раскрывать их исполнителю заранее. Качество работы проверяющего агента измеряется пропущенными дефектами и ошибочно отклоненными изменениями.

Человека часто оставляют на согласовании готового решения. Но если специалист передает всю содержательную работу ИИ и следит лишь за итоговыми отчетами, он теряет практику, а с ней и компетенцию. При этом право утверждать результат остается у него. Возникает риск согласования без понимания, хотя внешне процесс по-прежнему выглядит контролируемым. Если же специалист продолжает сам участвовать в выполнении каждой задачи, скорость разработки упирается в него. Нужно сохранять его участие в сложных случаях, проверке гипотез и решений, не превращая человека в обязательного участника каждой задачи.

Противопоставление «ненадежный ИИ – надежный человек» дает испорченную оптику. Появление ИИ не сделало решения людей безошибочными. Надежность приходится строить на уровне всей системы: разделять исполнение и проверку результатов, проверять полноту и корректность требований, сопоставлять выводы проверяющих с требованиями и данными испытаний, воспроизводить испытания и разбирать расхождения. В такой динамической гибридной системе задачи людей и агентов меняются по мере развития моделей. Передача ИИ новых функций должна опираться на проверенную способность системы замечать и исправлять ошибки. Команда определяет требования и допустимые компромиссы, пересматривая решение и способ проверки при появлении нового риска.

Проверять работу агентов тоже приходится с помощью ИИ. Модель того же семейства может завышать оценку исполнителя, поэтому для ответственной разработки стоит использовать агентов не менее чем из трех разных семейств – в ролях исполнителя, критика и приемщика. Разногласие между агентами становится поводом для нового испытания, уточнения требования или пересмотра гипотезы. Результаты инструментальных испытаний дают этой работе общую проверяемую основу.

Экономику стоит считать на всем пути до принятого результата – с учетом подготовки данных, работы ИИ и подключенных инструментов, проверки, исправления ошибок и сопровождения. Маленькая модель не становится выгодной только из-за своего размера, а ответ за секунду еще не доказывает ускорения работы. После смены модели, инструментов или инструкций существенные проверки придется повторять.

Базовые модели будут меняться. Конкурентное преимущество останется у команды, которая умеет перестраивать всю систему и получать предсказуемый результат. У компании должны сохраняться инженерное понимание, накопленные знания, средства испытаний и методология совместной работы людей и агентов.