Доставка систем искусственного интеллекта в условиях жесткого регулирования требует особого баланса между инновационной гибкостью стартапа и строгими стандартами безопасности крупной корпорации. В новом эпизоде подкаста The TWIML AI Podcast Сэм Чаррингтон беседует с Мириам Фридель, старшим директором по машинному обучению в Capital One, о том, как ее команда строит мосты между теоретической наукой и промышленным ML, создавая инструменты, которые упрощают жизнь дата-сайентистам и одновременно удовлетворяют требованиям аудиторов.
🏛️ Архитектура доверия в регулируемой среде 4:13
Работа в крупной финансовой организации накладывает специфические ограничения, которые редко встречаются в мире стартапов. По словам Фридель, ключевым игроком в жизненном цикле модели в Capital One является Model Risk Office (MRO) — подразделение, отвечающее за соблюдение нормативных требований и законов .
Основные аспекты взаимодействия с регулятором включают:
- Документирование: Дата-сайентисты обязаны готовить отчеты (white papers), которые по объему и детализации иногда превосходят докторские диссертации . В этих документах подробно объясняется бизнес-задача, выбор алгоритма и прозрачность процесса принятия решений.
- Прозрачность: Необходимо обеспечить полную прослеживаемость на каждом этапе разработки модели.
- Безопасность данных: В отличие от стартапов, где можно быстро развернуть S3-корзину с тестовыми данными, в Capital One доступ к информации строго ограничен для защиты конфиденциальности клиентов .
Мириам отмечает, что знание о существовании MRO «с самого начала» помогает командам инкорпорировать требования регулятора в процесс разработки, а не воспринимать их как препятствие в конце пути .
🛠️ Внутренние инструменты: от Rubicon до общих библиотек 5:37
Команда Мириам (около 70 инженеров) фокусируется на создании интерфейса между базовой инфраструктурой (которую строит команда Али Роделла на базе Kubeflow) и конечными пользователями-исследователями . Фридель считает, что их задача — инкапсулировать сложные или рискованные расчеты в проверенные библиотеки.
Среди ключевых продуктов команды:
- Rubicon: Инструмент для отслеживания экспериментов (Experiment Tracking). Он был создан внутри компании, так как на момент начала разработки на рынке не было подходящих аналогов, отвечающих требованиям безопасности банка . Позже проект был передан в open source.
- Библиотеки визуализации: Вместо того чтобы каждый дата-сайентист воевал с синтаксисом Matplotlib или Seaborn, команда Фридель создала стандартизированную библиотеку графиков. Это не только экономит время, но и гарантирует, что отчеты для офиса управления рисками выглядят единообразно и содержат корректные расчеты (например, значения Шепли или графики частичной зависимости) .
- Компоненты Kubeflow: Готовые шаблоны пайплайнов, которые позволяют исследователям, не являющимся экспертами в оркестрации, легко масштабировать свои модели .
Фридель приводит пример с «индексом стабильности популяции» (Population Stability Index). В какой-то момент она обнаружила в репозиториях компании семь разных реализаций этого расчета . Централизация таких вычислений снижает вероятность ошибки, которая в регулируемой среде может иметь серьезные последствия .
⚖️ Дилемма «Сделать или купить» и цена владения 27:01
Обсуждая стратегию развития инструментов, Мириам подчеркивает важность оценки долгосрочной стоимости владения (maintenance cost). По ее мнению, разработчики-технологи часто недооценивают затраты на поддержку собственного ПО .
Ее алгоритм принятия решения:
- Поиск в Open Source: Есть ли готовое решение с сильным сообществом? Фридель приводит в пример Scikit-learn как эталон инструмента, которому доверяют .
- Создание оберток вместо велосипедов: Если существуют хорошие библиотеки (например, Hyperopt или Optuna для оптимизации гиперпараметров), но у них разный API, команда предпочитает создать единый интерфейс (wrapper) поверх них, а не писать свой движок оптимизации .
- Внутренняя разработка: Только если потребность уникальна для Capital One или специфична для регуляторных требований .
🦄 Команда как «Единорог» 38:12
Мириам скептически относится к поиску отдельных специалистов-«единорогов», которые знают всё — от глубокой статистики до администрирования Kubernetes. Вместо этого она придерживается стратегии «команды-единорога» .
Идеальный состав команды по мнению Фридель должен включать:
- Специалистов с глубоким бэкграундом в Software Engineering или Kubernetes для работы «глубоко в стеке» .
- Ученых (PhD) со специфическим складом ума для решения теоретических проблем .
- Экспертов в области DevOps и MLOps .
Мириам подчеркивает, что в такой команде критически важна культура открытости, где людям разрешено совершать ошибки и учиться друг у друга .
🚀 Будущее MLOps в эпоху генеративного ИИ 35:48
Фридель признает, что развитие генеративного ИИ и больших языковых моделей (LLM) меняет ландшафт операционализации. По ее мнению, эксплуатация моделей типа Llama 2 или GPT будет требовать иных подходов к MLOps, чем работа с «традиционными» (или «legacy») моделями вроде XGBoost .
Она также затронула тему влияния инструментов вроде GitHub Co-pilot на их работу. Несмотря на потенциал автоматизации написания шаблонного кода, Фридель считает, что в регулируемой среде первичным остается вопрос: «Уверены ли вы, что вычисляете именно то, что думаете?» . Инструменты ИИ могут помочь, но они не снимают ответственности за точность и прозрачность расчетов перед регулятором.
Главный принцип работы команды Фридель — «стимулирование через удобство». Если инструмент плохой — люди не должны его использовать. Задача ML-инженерии — создавать такие продукты, которые дата-сайентисты выбирали бы сами, потому что это делает их работу проще и быстрее .
