Стремление к надёжному искусственному интеллекту заключается не в достижении произвольных показателей, таких как «90% точности». Речь идёт о понимании того, что каждый дополнительный процент надёжности требует сопоставимых усилий, а зачастую и фундаментального изменения подхода к созданию систем. Как лаконично выражается Андрей Карпати: «Когда вы видите демонстрацию, и что-то работает в 90% случаев, это только начало». Это не ошибка, а основное свойство сложных систем.
Растущая стоимость каждого «процента»
«Шествие девяток» описывает, как быстро уменьшается отдача. Базовая демонстрация ИИ может достичь 90% надёжности относительно легко. Но для достижения 99%, а затем и 99.9%, требуются на порядки больше инженерных усилий. Это особенно важно в корпоративной среде, где даже незначительные сбои могут привести к существенным бизнес-рискам.
Почему это важно: Системы ИИ часто работают в условиях высокого риска, когда даже небольшие ошибки могут привести к финансовым потерям, нарушениям нормативных требований или ущербу репутации. Ошибка в 1% при миллиардодолларовой сделке всё равно остаётся серьёзной проблемой.
От «обычно работает» к «надёжному ПО»
Многие команды ошибочно сосредотачиваются на точности модели, игнорируя общую надёжность системы. Типичный корпоративный рабочий процесс включает в себя несколько этапов: разбор намерений, извлечение данных, планирование, выполнение инструмента, валидация и ведение журнала. Если хотя бы один этап не удаётся, весь рабочий процесс рушится.
Например, 10-этапный рабочий процесс, где каждый этап выполняется с вероятностью 95%, имеет общую вероятность успеха всего 59.9%.
Определение надёжности с помощью измеримых SLO
Ключ к достижению более высокой надёжности заключается не только в лучших моделях, но и в преобразовании надёжности в измеримые цели. Командам необходимо определить индикаторы уровня обслуживания (SLI) и инвестировать в средства контроля, которые уменьшают отклонения. Важные SLI включают в себя:
- Процент завершения рабочих процессов: Процент рабочих процессов, которые выполняются успешно или корректно эскалируются.
- Процент успешного вызова инструментов: Процент выполнения инструментов, которые завершаются в течение указанного времени ожидания, со строгой проверкой схемы.
- Процент выходных данных, соответствующих схеме: Процент структурированных ответов, соответствующих предопределённым схемам.
- Процент соответствия политике: Процент выходных данных, соответствующих требованиям безопасности, конфиденциальности и нормативным ограничениям.
- Задержка и стоимость на рабочий процесс: Обеспечение производительности в допустимых пределах.
- Частота отказов: Эффективность механизмов резервирования при сбое основных систем.
После определения эти SLI должны использоваться для установки конкретных целей уровня обслуживания (SLO) и управления бюджетом ошибок, чтобы эксперименты не подрывали надёжность.
Девять проверенных рычагов для повышения надёжности
- Ограничьте автономию явными рабочими процессами: Ограничьте свободу ИИ, определив строгие конечные автоматы или направленные ациклические графы (DAG), где каждый шаг имеет определённые входы, выходы и обработку ошибок. Используйте идемпотентные ключи для безопасных повторных попыток.
- Применяйте контракты на каждой границе: Используйте схемы (JSON Schema, Protobuf) для проверки всех структурированных данных. Нормализуйте единицы измерения (ISO-8601, SI) и строго соблюдайте типы данных, чтобы предотвратить смещение интерфейса.
- Добавьте слои проверки: Помимо синтаксиса, внедряйте семантические и бизнес-правила, чтобы предотвратить логически правдоподобные, но разрушительные для системы выходные данные.
- Маршрутизируйте по риску, используя сигналы неопределенности: Используйте оценки достоверности или вторичные модели проверки, чтобы направлять действия с высоким уровнем воздействия по более надёжным путям.
- Разрабатывайте вызовы инструментов, как распределённые системы: Применяйте тайм-ауты, стратегии отката, автоматические выключатели и ограничения параллелизма к внешним зависимостям. Версионируйте схемы инструментов, чтобы предотвратить тихие сбои.
- Сделайте извлечение предсказуемым и наблюдаемым: Относитесь к извлечению данных как к версии продукта с метриками покрытия, свежести и коэффициента попадания. Используйте канарейки для изменений индекса.
- Создайте конвейер оценки в рабочей среде: Поддерживайте золотой набор рабочего трафика, чтобы запускать его с каждым изменением. Используйте теневой режим и канарейки A/B с автоматическим откатом при регрессиях.
- Инвестируйте в наблюдаемость и оперативное реагирование: Выводите подробные трассировки, храните анонимизированные запросы и классифицируйте сбои в чёткую таксономию. Используйте руководства по эксплуатации и переключатели безопасного режима для быстрого устранения последствий.
- Выпустите ползунок автономии с детерминированными резервными копиями: Разрабатывайте ИИ-системы с регулируемыми уровнями автономии и детерминированными резервными копиями (ответы только для поиска, кэшированные ответы, проверка человеком), чтобы обеспечить безопасную работу.
Корпоративная реальность: надёжность определяет внедрение
Недавний отчёт McKinsey показывает, что более половины организаций, использующих ИИ, сталкивались с негативными последствиями из-за неточности. Эти риски заставляют предприятия уделять приоритетное внимание более надёжным измерениям, защитным механизмам и оперативным средствам управления. Последние «девятки» — это не просто технические цели, а бизнес-императивы.
В конечном итоге, достижение истинной надёжности ИИ требует дисциплинированного проектирования: чётких рабочих процессов, строгих интерфейсов, устойчивых зависимостей и быстрого извлечения уроков из ошибок. Речь идёт не об избежании ошибок, а об минимизации их последствий и эффективном реагировании на них.
