Debugging AI With Adversarial Validation
Статья описывает метод Adversarial Validation — простой способ обнаружения дрифта (внезапных изменений) в данных для AI/ML-моделей. Суть метода: два набора данных размечаются метками 0 и 1, затем обучается бинарный классификатор; если AUC ≥ 0.60, значит дрифт присутствует. Автор представляет CLI-инструмент ft_drift для обнаружения расхождений между двумя JSONL-файлами с данными для файн-тюнинга OpenAI. Метод не требует сложной инфраструктуры и позволяет через интерпретируемые модели (логистическая регрессия, случайный лес) определить первопричину дрифта. Hamel Husain рекомендует регулярно проверять все AI/ML-проекты на дрифт как высокоэффективную практику.
For years, I’ve relied on a straightforward method to identify sudden changes in model inputs or training data, known as “drift.” This method, Adversarial Validation1, is both simple and effective. The best part? It requires no complex tools or infrastructure.
На протяжении многих лет я полагался на простой метод для выявления внезапных изменений во входных данных модели или обучающих данных, известных как «дрифт». Этот метод — Adversarial Validation1 — одновременно прост и эффективен. И лучшее в нём? Он не требует сложных инструментов или инфраструктуры.
Examples where drift can cause bugs in your AI:
Примеры того, как дрифт может вызывать баги в вашем AI:
Ваши данные для оценок существенно отличаются от входных данных, которые модель получает в продакшене, из-за чего результаты оценок вводят в заблуждение. Обновления промптов, функций, RAG и аналогичных элементов не учитываются в ваших данных для файн-тюнинга или обучения, что приводит к неожиданному поведению модели в продакшене.
No matter how careful you are, bugs can still slip through the cracks. A a high ROI activity is to routinely audit all your AI/ML projects for drift.
Как бы тщательно вы ни работали, баги всё равно могут проскользнуть. Высокоэффективная практика — регулярно проверять все ваши AI/ML-проекты на дрифт.
How It Works
Как это работает
This method is so simple that it might seem uncool. You aren’t going to impress any data scientists. Despite this, it’s too valuable to ignore.
Метод настолько прост, что может показаться несерьёзным. Вы точно не впечатлите им дата-сайентистов. Тем не менее он слишком ценен, чтобы его игнорировать.
This slide from my talk on MLOps tools explains the technique behind Adversarial Validation2:
Этот слайд из моего доклада об инструментах MLOps объясняет технику Adversarial Validation2:
The process is as follows:
Процесс выглядит следующим образом:
- Training data from two different fine-tuning runs
- Training data vs. evaluation data
- Training data vs. production data (organized into the same format)
- Data from two different time-periods
Соберите два набора данных для сравнения. Например: Обучающие данные из двух разных запусков файн-тюнинга Обучающие данные vs. данные для оценки Обучающие данные vs. данные из продакшена (приведённые к одному формату) Данные из двух разных временных периодов Создайте признаки из набора данных. Базовый пример создания признаков из токенов показан здесь.3 Присвойте набору данных №1 метку 0, а набору данных №2 — метку 1. Обучите бинарный классификатор (случайный лес, логистическую регрессию и т.д.) различать два набора данных. Если классификатор демонстрирует достаточную предсказательную способность (например, AUC ≥ 0.60), значит дрифт присутствует. Если вы использовали интерпретируемую модель (логистическую регрессию, случайный лес и т.д.), можно изучить метрики важности признаков, чтобы понять первопричину дрифта. Если вы используете более сложную модель (например, нейронную сеть), можно применить SHAP values или другие методы для понимания причин дрифта. Я рекомендую начинать с простой интерпретируемой модели.
If this process doesn’t detect drift, it doesn’t mean there isn’t drift. It just means that we couldn’t detect it with the model and features we used.
Если этот процесс не обнаружил дрифт, это не означает, что дрифта нет. Это лишь значит, что мы не смогли его обнаружить с помощью выбранной модели и признаков.
Minimal Example: ft_drift
Минимальный пример: ft_drift
I work with lots of folks who are fine-tuning models using the OpenAI API. I’ve created a small CLI tool, ft_drift, that detects drift between two multi-turn chat formatted jsonl files. Currently, ft_drift only detects drift in prompt templates, schemas and other token-based drift (as opposed to semantic drift). However, this is a good starting point to understand the general concept of adversarial validation. Here is a demo of this tool at work:
Я работаю со множеством людей, которые файн-тюнят модели через OpenAI API. Я создал небольшой CLI-инструмент ft_drift, который обнаруживает дрифт между двумя JSONL-файлами в формате многоходового чата. На данный момент ft_drift обнаруживает дрифт только в шаблонах промптов, схемах и другой токен-основанный дрифт (в отличие от семантического дрифта). Тем не менее это хорошая отправная точка для понимания общей концепции adversarial validation. Вот демонстрация работы инструмента:
The demo is from a real-world example where an unintentional change in a prompt template caused unexpected behavior in a model. The demo shows the tool detecting a difference between two datasets, file_a.jsonl and file_b.jsonl. Afterward, a table of important tokens that account for the drift are shown, such as END-UI-FORMAT, UI-FORMAT, etc. We were able to apply the tool and quickly find the root cause of the issue. The modeling code is embarrassingly simple and located at ft_drift/model.py. The point is you don’t need sophisticated techniques to get started. You can then take this approach further by adding embeddings to your features to also detect semantic drift. Similarly, you could add additional features by hand like the number of conversation turns, length of messages, etc.
Демонстрация основана на реальном случае, когда непреднамеренное изменение шаблона промпта вызвало неожиданное поведение модели. Демо показывает, как инструмент обнаруживает различие между двумя наборами данных — file_a.jsonl и file_b.jsonl. Затем выводится таблица важных токенов, объясняющих дрифт, таких как END-UI-FORMAT, UI-FORMAT и т.д. Мы смогли применить инструмент и быстро найти первопричину проблемы. Код моделирования предельно прост и находится в ft_drift/model.py. Суть в том, что для начала не нужны сложные техники. Затем вы можете развить этот подход, добавив эмбеддинги в признаки для обнаружения семантического дрифта. Аналогично можно добавить дополнительные признаки вручную — количество ходов в разговоре, длину сообщений и т.д.
Footnotes
Примечания
I first learned of this technique in 2016 from this blog post by Zygmunt Zając. Throughout the years, I’ve seen this technique used in a variety of contexts, sometimes with different names.↩︎
This slide uses the word “skew” which is interchangeable with “drift” in this context.↩︎
For classic ML, if you are already training a model on this data, you likely have a feature engineering pipeline that you can reuse.↩︎
Впервые я узнал об этой технике в 2016 году из этого поста Zygmunt Zając. На протяжении многих лет я видел, как эта техника применяется в различных контекстах, иногда под другими названиями.↩︎ В этом слайде используется слово «skew», которое в данном контексте взаимозаменяемо с «drift».↩︎ Для классического ML, если вы уже обучаете модель на этих данных, у вас, вероятно, есть пайплайн создания признаков, который можно переиспользовать.↩︎