# Мириам Фридель из Capital One: «Команда-единорог важнее, чем специалист-единорог» Источник: https://www.youtube.com/watch?v=7dswEKOGQys Канал: The TWIML AI Podcast Опубликовано: 30.10.2023 --- Доставка систем искусственного интеллекта в условиях жесткого регулирования требует особого баланса между инновационной гибкостью стартапа и строгими стандартами безопасности крупной корпорации. В новом эпизоде подкаста **The TWIML AI Podcast** Сэм Чаррингтон беседует с Мириам Фридель, старшим директором по машинному обучению в **Capital One**, о том, как ее команда строит мосты между теоретической наукой и промышленным ML, создавая инструменты, которые упрощают жизнь дата-сайентистам и одновременно удовлетворяют требованиям аудиторов. ## 🏛️ Архитектура доверия в регулируемой среде [[JUMP:04:13]] Работа в крупной финансовой организации накладывает специфические ограничения, которые редко встречаются в мире стартапов. По словам Фридель, ключевым игроком в жизненном цикле модели в Capital One является **Model Risk Office (MRO)** — подразделение, отвечающее за соблюдение нормативных требований и законов [09:47]. Основные аспекты взаимодействия с регулятором включают: * **Документирование:** Дата-сайентисты обязаны готовить отчеты (white papers), которые по объему и детализации иногда превосходят докторские диссертации [10:14]. В этих документах подробно объясняется бизнес-задача, выбор алгоритма и прозрачность процесса принятия решений. * **Прозрачность:** Необходимо обеспечить полную прослеживаемость на каждом этапе разработки модели. * **Безопасность данных:** В отличие от стартапов, где можно быстро развернуть S3-корзину с тестовыми данными, в Capital One доступ к информации строго ограничен для защиты конфиденциальности клиентов [16:05]. Мириам отмечает, что знание о существовании MRO «с самого начала» помогает командам инкорпорировать требования регулятора в процесс разработки, а не воспринимать их как препятствие в конце пути [16:30]. ## 🛠️ Внутренние инструменты: от Rubicon до общих библиотек [[JUMP:05:37]] Команда Мириам (около 70 инженеров) фокусируется на создании интерфейса между базовой инфраструктурой (которую строит команда Али Роделла на базе **Kubeflow**) и конечными пользователями-исследователями [03:14]. Фридель считает, что их задача — инкапсулировать сложные или рискованные расчеты в проверенные библиотеки. Среди ключевых продуктов команды: * **Rubicon:** Инструмент для отслеживания экспериментов (Experiment Tracking). Он был создан внутри компании, так как на момент начала разработки на рынке не было подходящих аналогов, отвечающих требованиям безопасности банка [05:11]. Позже проект был передан в open source. * **Библиотеки визуализации:** Вместо того чтобы каждый дата-сайентист воевал с синтаксисом **Matplotlib** или **Seaborn**, команда Фридель создала стандартизированную библиотеку графиков. Это не только экономит время, но и гарантирует, что отчеты для офиса управления рисками выглядят единообразно и содержат корректные расчеты (например, значения Шепли или графики частичной зависимости) [06:29]. * **Компоненты Kubeflow:** Готовые шаблоны пайплайнов, которые позволяют исследователям, не являющимся экспертами в оркестрации, легко масштабировать свои модели [05:49]. Фридель приводит пример с «индексом стабильности популяции» (Population Stability Index). В какой-то момент она обнаружила в репозиториях компании семь разных реализаций этого расчета [12:38]. Централизация таких вычислений снижает вероятность ошибки, которая в регулируемой среде может иметь серьезные последствия [13:19]. ## ⚖️ Дилемма «Сделать или купить» и цена владения [[JUMP:27:01]] Обсуждая стратегию развития инструментов, Мириам подчеркивает важность оценки долгосрочной стоимости владения (maintenance cost). По ее мнению, разработчики-технологи часто недооценивают затраты на поддержку собственного ПО [27:15]. Ее алгоритм принятия решения: 1. **Поиск в Open Source:** Есть ли готовое решение с сильным сообществом? Фридель приводит в пример **Scikit-learn** как эталон инструмента, которому доверяют [13:46]. 2. **Создание оберток вместо велосипедов:** Если существуют хорошие библиотеки (например, **Hyperopt** или **Optuna** для оптимизации гиперпараметров), но у них разный API, команда предпочитает создать единый интерфейс (wrapper) поверх них, а не писать свой движок оптимизации [24:38]. 3. **Внутренняя разработка:** Только если потребность уникальна для Capital One или специфична для регуляторных требований [28:46]. ## 🦄 Команда как «Единорог» [[JUMP:38:12]] Мириам скептически относится к поиску отдельных специалистов-«единорогов», которые знают всё — от глубокой статистики до администрирования Kubernetes. Вместо этого она придерживается стратегии «команды-единорога» [38:26]. Идеальный состав команды по мнению Фридель должен включать: * Специалистов с глубоким бэкграундом в Software Engineering или Kubernetes для работы «глубоко в стеке» [38:26]. * Ученых (PhD) со специфическим складом ума для решения теоретических проблем [38:52]. * Экспертов в области DevOps и MLOps [39:05]. Мириам подчеркивает, что в такой команде критически важна культура открытости, где людям разрешено совершать ошибки и учиться друг у друга [39:46]. ## 🚀 Будущее MLOps в эпоху генеративного ИИ [[JUMP:35:48]] Фридель признает, что развитие генеративного ИИ и больших языковых моделей (LLM) меняет ландшафт операционализации. По ее мнению, эксплуатация моделей типа Llama 2 или GPT будет требовать иных подходов к MLOps, чем работа с «традиционными» (или «legacy») моделями вроде XGBoost [35:48]. Она также затронула тему влияния инструментов вроде **GitHub Co-pilot** на их работу. Несмотря на потенциал автоматизации написания шаблонного кода, Фридель считает, что в регулируемой среде первичным остается вопрос: «Уверены ли вы, что вычисляете именно то, что думаете?» [11:07]. Инструменты ИИ могут помочь, но они не снимают ответственности за точность и прозрачность расчетов перед регулятором. Главный принцип работы команды Фридель — «стимулирование через удобство». Если инструмент плохой — люди не должны его использовать. Задача ML-инженерии — создавать такие продукты, которые дата-сайентисты выбирали бы сами, потому что это делает их работу проще и быстрее [46:14].