Полуавтоматические исследования: перенос узкого места с реализации на методологию

Фото: NEW DATA SERVICES (Unsplash) — https://unsplash.com/photos/white-printer-paper-on-white-wall-Ar-iTL4QKl4?utm_source=dev48&utm_medium=referral

Источник: AI Search Blog•

Полуавтоматические исследования: перенос узкого места с реализации на методологию

Полуавтоматические исследования: адаптация автоисследований Карпати для промышленного машинного обучения, ускорение экспериментов и суровые уроки утечки данных.

Что произошло, когда мы адаптировали агентские «автоисследования» для прикладного машинного обучения в продакшене.

В концепции автоисследований Андрея Карпати есть неотразимая простота. Дайте агенту машинного обучения модель, измеримую цель и способ запуска экспериментов. Пусть он меняет код, оценивает результат и повторяет процесс. Вместо помощи с одной изолированной задачей агент теперь сам участвует в научном цикле обратной связи, автономно работая над улучшением модели.

У команд, занимающихся прикладной наукой, редко наблюдается дефицит идей. Дефицитным ресурсом обычно является время, необходимое для превращения каждой идеи в достоверные доказательства. Мы хотели узнать, сможем ли мы адаптировать автоисследования для улучшения Search Page Optimizer (SPO) — системы ранжирования Coveo для электронной коммерции. Наша реальность гораздо сложнее идеализированных лабораторных условий, в которых родились автоисследования. Наши эксперименты — это не пятиминутные локальные запуски обучения по одной однозначной метрике. Они включают в себя код производственного качества, удаленную инфраструктуру, защищенные данные, тщательный дизайн экспериментов и часы выполнения.

Поэтому мы создали нечто заведомо менее автономное: полуавтоматические исследования.

Идеи стоят недорого, но время ограничено

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

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

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

Добавление приставки «полу» к автоисследованиям

Прелесть автоисследований заключалась в том, что мы могли бы перепоручить этот бэклог агенту и позволить ему работать с ним. Дизайн был близок к тому, что нам было нужно, но не идентичен, поэтому мы адаптировали его в осознанно контролируемый цикл — то самое «полу» в полуавтоматических исследованиях. Мы организовали работу как повторяющийся цикл из пяти этапов, который соответствует нашему обычному процессу работы над любой идеей.

Выдвижение гипотезы → реализация → выполнение → анализ → документирование → повторение

Мы разделили ответственность за различные этапы этого рабочего процесса между экспертами-людьми и агентами.

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

Люди по-прежнему отвечали за выбор гипотезы для проверки, утверждение метода эксперимента, запуск его выполнения и принятие решения о том, достаточны ли доказательства для принятия или отклонения результата.

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

Мы заложили надежность в систему, потребовав проверки под руководством агента после каждого критического этапа, используя метод, который мы назвали «проверкой персонами»: несколько параллельных LLM, каждая из которых настроена на определенную точку зрения, выносят независимые вердикты о качестве конкретного этапа. Переход к следующему этапу требовал убеждения этой экспертной панели.

Не мгновенные исследования, но гораздо меньше человеческих усилий

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

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

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

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

Более быстрые эксперименты также приводят к более быстрым ошибкам

Тем не менее, все было не так идилично, как казалось поначалу. Самые очевидные проблемы проявились, когда мы перешли от локальных изменений модели к созданию новых признаков. Проверка человеком выявила изъяны в нескольких наших экспериментах.

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

Этот тип проблемы известен как утечка данных: модель получает доступ во время обучения или оценки к информации, которая не была бы справедливо доступна при создании реального предсказания.

В другой задаче мы столкнулись с результатом, который выглядел так, будто имел неверный знак, причем агент добавил правдоподобное объяснение того, как этот знак мог быть инвертирован на более ранних этапах. Это объяснение выглядело как проявление усердия, поэтому вопрос был временно закрыт. Более поздняя проверка показала, что никакой инверсии не существовало. Необъяснимая аномалия заставила бы нас продолжить поиски; связное же объяснение снизило вероятность того, что мы станем проверять дальше.

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

Сложность × Проверяемость

Для отдельного эксперимента наиболее полезным способом прогнозирования надежности оказалось рассмотрение двух измерений: насколько сложно изменение и насколько легко его проверить?

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

Создание новых признаков было совсем другим. Новый признак может быть синтаксически корректным и статистически предсказательным, но при этом быть временнó невозможным, недоступным во время обслуживания (serving) или полезным лишь из-за случайной разницы между покрытием в обучающей и тестовой выборках. Его проверка требует понимания процесса генерации данных и инструментирования признака так, чтобы можно было подтвердить его поведение, а не слепого вычисления среднего значения и принятия факта прохождения теста или улучшения метрики обучения.

То, что хорошо структурированные задачи с проверяемыми критериями успеха дают лучшие результаты работы агентов — наблюдение не новое. Исследовательский цикл добавляет к нему более острый вопрос о том, какой именно тип проверяемости имеет значение. Дело не в том, корректен ли код; дело в том, корректно ли сравнение. Успешно пройденный набор тестов ничего не говорит о том, мог ли признак существовать в момент прогнозирования.

Совершенствование процесса

Здесь были перспективы: многие эксперименты оказались удачными, а сокращение времени цикла было реальным, поэтому мы вложились в улучшение процесса.

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

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

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

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

От офлайн-кандидата к онлайн-тесту

Здесь мы немного упростили ситуацию, но после нескольких итераций этой программы мы были вполне уверены в ее качестве. Самым очевидным результатом, пережившим ужесточение процесса, стала замена алгоритма модели: переход с нашего прежнего подхода на CatBoost с целевой функцией YetiRank. Это дало небольшое, но заслуживающее доверия улучшение в офлайне, которое выдержало все наши перекрестные проверки и стабильно воспроизводилось во многих экспериментах. Мы были достаточно уверены в себе, чтобы вынести эту модель на реальное испытание: в онлайн с реальными пользователями. К счастью, наши методы сделали это простым: агенты уже реализовали признак с высоким качеством, поэтому процесс его развертывания в продакшн оказался тривиальным. Что касается окончательных онлайн-результатов, они были скромными, но мы действительно наблюдали небольшой эффект в некоторых наших метриках. Это согласуется с областью маржинальных улучшений, в которой мы, по нашему мнению, находились. Что еще более важно, у команды не было бы времени самостоятельно исследовать этот небольшой прирост — а по пути мы отбросили десятки других идей.

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

Если вы хотите попробовать это

Если вы захотите попробовать что-то подобное, наш опыт можно свести к нескольким практическим принципам:

  • Пишите долговечный контекст. Относитесь к журналам исследований и артефактам передачи результатов как к части системы.
  • Декомпозируйте длинные рабочие процессы. Дайте каждой фазе контекст и определение готовности (definition of done), которые ей действительно нужны. Сосредоточьтесь.
  • Автоматизируйте рутинную работу. Сберегите человеческое внимание для методологии, суждений и судьбоносных решений.
  • Предпочитайте локализованные, проверяемые эксперименты. Сложность безопаснее, когда сбой легко обнаружить.
  • Сделайте важные соглашения исполняемыми. Работающая проверка сильнее, чем еще один агент, перечитывающий правдоподобную прозу.
  • Масштабируйте контроль вместе с пропускной способностью. Большее количество экспериментов требует более жесткого контроля за утечками, сопоставимостью и выбором результатов.

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

О чём эта статья