AWS связала 3 ИИ-агента для проверки замены авиационных компонентов

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

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

Как устроен маршрут запроса

Представим, что реакционное колесо для спутника стало недоступно. Инженер просит проверить риск снятия модели с производства, найти альтернативы и сравнить их с исходной деталью.

Сначала небольшой планировщик определяет последовательность действий. Агент каталога ищет кандидатов в базе деталей. Агент оценки сравнивает их характеристики. Агент знаний достаёт сведения из технических описаний, чертежей и веб-источников. Если работали несколько специалистов, отдельная модель объединяет результаты в один ответ.

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

Где модели не доверяют считать

Самая сильная часть решения — проверку допусков выполняет обычный Python-код. Для каждой категории деталей заранее задаются критические параметры и правила: точное совпадение напряжения, допустимое превышение массы, совместимость интерфейса и другие ограничения.

На одинаковых входных данных проверка всегда выдаёт одинаковый результат. Языковая модель может объяснить таблицу и оформить записку, но не вправе переписать статус «пройдено», «нарушение» или «нужна проверка». После каждой оценки система сохраняет журнал действий, поэтому рецензент видит не только вывод, но и путь к нему.

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

Зачем здесь мультимодальный поиск

Часть инженерных данных живёт не в таблицах. Крутящий момент может быть показан только на графике, расположение разъёма — на фотографии, а монтажные размеры — на чертеже. Amazon Nova Multimodal Embeddings помещает текст и изображения в общее пространство поиска. Поэтому запрос по характеристике способен вернуть нужную диаграмму, а загруженная картинка — похожую деталь.

Фотографии двух компонентов также сравниваются по косинусной близости, после чего модель описывает видимые различия: крепления, разъёмы и форму корпуса. Но визуальная похожесть остаётся вспомогательным доказательством. Итог проверки определяется заданными инженерными требованиями.

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

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