Работа в области искусственного интеллекта во многом напоминает традиционную разработку программного обеспечения. Как инженер-программист, специализирующийся на ИИ, я сочетаю в своей деятельности классическую инженерию ПО, инженерию ИИ, интуицию в области продуктов и понимание нужд пользователей.
В условиях бурного развития отрасли я решил вернуться к фундаментальным аспектам и поразмышлять о навыках и подходах, которые помогут инженерам оставаться на шаг впереди. Недавнее ознакомление с книгой Инженерия ИИ от O’Reilly побудило меня углубиться в тему оценок — ключевого элемента любой системы ИИ.
Особо выделяется то, что инженерия ИИ в основном сводится к работе с ПО, а не с самим ИИ.
Вне исследовательских лабораторий, таких как OpenAI или Anthropic, большинство специалистов не занимаются обучением моделей с нуля. Основная задача — решение бизнес-задач с использованием существующих инструментов: предоставление моделям достаточного контекста, работа с API, создание конвейеров RAG, вызов инструментов — все это поверх стандартных вопросов инженерии ПО, включая развертывание, мониторинг и масштабирование.
Таким образом, инженерия ИИ не вытесняет инженерию ПО, а добавляет новые уровни сложности.
В этой статье я разбираю некоторые из этих идей.
Три уровня стека приложений ИИ
Представьте приложение на базе ИИ как систему, построенную на трех уровнях: 1) разработка приложения, 2) разработка модели, 3) инфраструктура.
Большинство команд начинают с верхнего уровня. Поскольку мощные модели доступны готовыми, логично сначала сосредоточиться на создании продукта, а потом, по мере необходимости, переходить к разработке моделей или инфраструктуре.
Как отмечает O’Reilly, «инженерия ИИ — это просто инженерия ПО с добавлением моделей ИИ в стек».
Почему оценки важны и почему они сложны
В разработке ПО одна из главных проблем для команд, работающих в быстром темпе, — это регрессии. Вы внедряете новую функцию и случайно ломаете что-то другое. Через недели ошибка проявляется в отдаленной части кода, и ее отладка превращается в кошмар.
Комплексный набор тестов помогает выявлять такие регрессии на ранних этапах.
Разработка ИИ сталкивается с аналогичной проблемой. Любое изменение — корректировка промпта, обновление конвейера RAG, дообучение или инженерия контекста — может улучшить производительность в одной области, но незаметно ухудшить в другой.
По сути, оценки в ИИ выполняют роль тестов в ПО: они позволяют обнаруживать регрессии заранее и дают инженерам уверенность в быстром развитии без риска поломок.
Однако оценка ИИ не так проста. Во-первых, чем умнее модели, тем труднее их оценивать. Легко понять, что сводка книги плохая, если она бессмысленная, но гораздо сложнее, если она coherentна. Чтобы проверить, охватывает ли она ключевые моменты, а не просто звучит убедительно или фактологически верно, может потребоваться перечитать книгу самостоятельно.
Во-вторых, задачи часто открыты. Редко бывает единственный «правильный» ответ, и невозможно собрать полный перечень корректных выходов.
В-третьих, базовые модели рассматриваются как черные ящики, где детали архитектуры, данных для обучения и процесса обучения обычно не раскрываются публично. Эти детали многое говорят о сильных и слабых сторонах модели, а без них оценка сводится только к анализу выходных данных.
Как подходить к оценкам
Я разделяю оценки на два основных типа: количественные и качественные.
Количественные оценки имеют четкие, однозначные ответы. Решена ли математическая задача верно? Выполнился ли код без ошибок? Такие проверки часто автоматизируются, что делает их масштабируемыми.
Качественные оценки, напротив, находятся в серой зоне. Они требуют интерпретации и суждения — например, оценка эссе, тона чат-бота или того, звучит ли сводка убедительно.
Большинство оценок сочетают оба типа. Например, при оценке сгенерированного сайта нужно не только проверить выполнение функций (количественно: может ли пользователь зарегистрироваться, войти и т.д.), но и оценить интуитивность пользовательского опыта (качественно).
Функциональная корректность
В основе количественных оценок лежит функциональная корректность: выполняет ли выход модели то, что от нее ожидается?
Если модель генерирует сайт, ключевой вопрос — соответствует ли он требованиям. Может ли пользователь выполнить основные действия? Работает ли он стабильно? Это напоминает традиционное тестирование ПО, где продукт проверяется набором тестовых случаев для верификации поведения. Часто это автоматизируется.
Сходство с эталонными данными
Не все задачи имеют такие явные, проверяемые выходы. Перевод — хороший пример: нет единственного «правильного» перевода французского предложения на английский, но можно сравнивать с эталонными данными.
Минус: это сильно зависит от наличия эталонных наборов данных, создание которых дорого и времязатратно. Данные, сгенерированные людьми, — золотой стандарт, но все чаще эталоны создаются другими ИИ.
Существует несколько способов измерения сходства:
- Суждение человека
- Точное совпадение: проверка, совпадает ли сгенерированный ответ точно с одним из эталонных. Это дает булевские результаты.
- Лексическое сходство: измерение визуального сходства выходов (например, пересечение слов или фраз).
- Семантическое сходство: проверка, имеют ли выходы одинаковый смысл, даже при разной формулировке. Обычно это включает преобразование данных в эмбеддинги (числовые векторы) и их сравнение. Эмбеддинги применяются не только к тексту — платформы вроде Pinterest используют их для изображений, запросов и даже профилей пользователей.
Лексическое сходство проверяет только поверхностное сходство, в то время как семантическое углубляется в смысл.
ИИ в роли судьи
Некоторые задачи почти невозможно оценить чисто с помощью правил или эталонных данных. Оценка тона чат-бота, coherentности сводки или убедительности рекламного текста — все это требует субъективного подхода. Люди справляются, но человеческие оценки не масштабируются.
Вот как организовать процесс:
- Определите структурированные и измеримые критерии оценки. Будьте конкретны в том, что важно — ясность, полезность, фактическая точность, тон и т.д. Критерии могут использовать шкалу (оценка 1–5) или бинарные проверки (прошел/провалил).
- Исходный ввод, сгенерированный выход и любой поддерживающий контекст передаются ИИ-судье. Судья возвращает оценку, метку или даже объяснение.
- Агрегируйте по множеству выходов. Запуская процесс на больших наборах данных, можно выявить паттерны — например, заметить, что полезность снизилась на 10% после обновления модели.
Поскольку это автоматизируется, возможно непрерывная оценка, заимствованная из практик CI/CD в инженерии ПО. Оценки запускаются до и после изменений в конвейере (от корректировок промпта до обновлений модели) или используются для постоянного мониторинга, чтобы ловить дрейф и регрессии.
Конечно, ИИ-судьи неидеальны. Как и мнение одного человека не стоит полностью доверять, так и модели нельзя. Но с тщательным дизайном, несколькими моделями-судьями или запуском на множестве выходов они дают масштабируемые приближения человеческого суждения.
Разработка на основе оценок
O’Reilly описывает концепцию разработки на основе оценок, вдохновленную тест-дривен-девелопментом в инженерии ПО, и я считаю, что это стоит отметить.
Идея проста: определяйте оценки до начала строительства.
В инженерии ИИ это значит решить, что такое «успех» и как его измерить.
Влияние остается приоритетом — не хайп. Правильные оценки гарантируют, что приложения ИИ приносят ценность, релевантную пользователям и бизнесу.
При определении оценок учитывайте следующие аспекты:
Знания домена
Существуют публичные бенчмарки по многим доменам — отладка кода, юридические знания, использование инструментов — но они часто общие. Самые значимые оценки возникают из обсуждений со стейкхолдерами: определите, что действительно важно для бизнеса, и переведите это в измеримые результаты.
Корректность недостаточна, если решение непрактично. Например, модель текст-в-SQL может сгенерировать верный запрос, но если он выполняется 10 минут или потребляет огромные ресурсы, он бесполезен в масштабе. Время выполнения и использование памяти — важные метрики.
Способности генерации
Для генеративных задач — текста, изображений или аудио — оценки включают плавность, coherentность и специфические метрики, такие как релевантность.
Сводка может быть фактологически верной, но пропустить ключевые моменты — оценка должна это улавливать. Все чаще такие качества оцениваются другим ИИ.
Фактическая согласованность
Выходы нужно проверять на соответствие источнику истины. Это происходит двумя способами:
- Локальная согласованность
Проверка выходов на соответствие предоставленному контексту. Это полезно для специфических доменов с ограниченным охватом. Например, извлеченные insights должны соответствовать данным. - Глобальная согласованность
Проверка выходов на соответствие открытым источникам знаний, таким как фактчекинг через веб-поиск или маркетинговые исследования. - Самопроверка
Это когда модель генерирует несколько выходов и измеряет их согласованность друг с другом.
Безопасность
Помимо стандартных аспектов безопасности, таких как отсутствие нецензурной лексики и откровенного контента, безопасность можно определять по-разному. Например, чат-боты не должны раскрывать конфиденциальные данные клиентов и должны защищаться от атак типа инъекции промпта.
В заключение
По мере роста возможностей ИИ надежные оценки станут еще важнее. Они служат барьерами, позволяющими инженерам двигаться быстро, не жертвуя надежностью.
Я наблюдал, насколько сложно обеспечивать надежность и как дороги регрессии. Они подрывают репутацию компании, раздражают пользователей и создают мучительные сценарии разработки, когда инженеры бесконечно гоняются за одними и теми же ошибками.
По мере стирания границ между ролями инженеров, особенно в малых командах, мы переживаем фундаментальный сдвиг в подходах к качеству ПО. Необходимость поддерживать и измерять надежность теперь распространяется за пределы правил-основанных систем на вероятностные и стохастические.