Почему SFT data filtering плохо убирает поведение LLM
SFT data filtering кажется простым способом убрать нежелательное поведение LLM, но новые эксперименты показывают: черты могут переноситься через teacher model, prompt distribution и соседние сигналы в SFT-данных.
Почему SFT data filtering плохо убирает поведение LLM
По состоянию на 7 июля 2026 года SFT data filtering - это попытка убрать нежелательное поведение языковой модели через удаление или замену подозрительных примеров supervised fine-tuning. Логика кажется прямой: нашли плохие ответы в обучающей выборке, выкинули похожие документы, переобучили модель и получили более чистое поведение. Новые эксперименты на Alignment Forum показывают, почему этот план часто ломается.
Проблема в том, что поведение LLM не всегда лежит в одном очевидном документе. Его может задавать модель-учитель, распределение подсказок, слабые повторяющиеся сигналы или более общий ассистентский стиль. Поэтому фильтрация SFT-данных иногда удаляет текст, но не удаляет причину поведения.
Базовый контекст о дообучении мы разбирали в материале про fine-tuning LLM. В этой статье фокус уже другой: не когда дообучать модель, а почему после дообучения нежелательную черту нельзя всегда вылечить простым удалением примеров.
Что проверили исследователи
7 июля 2026 года Dohun Lee, J Rosser, Josh Engels и Neel Nanda опубликовали на Alignment Forum разбор Data filtering works a lot worse than you would expect. Они взяли упрощённый OLMo-3 SFT-сценарий и проверили, можно ли убрать широкие ассистентские привычки модели через targeted filtering.
Эксперимент был небольшим, но достаточно конкретным для проверки гипотезы:
- модель: OLMo-3 7B mid-train;
- обучение: rank-64 LoRA на всех 32 MLP и attention layers;
- датасет: 1% stratified sample из Dolci-Think-SFT-7B;
- фильтрационный тест: sampled SFT set из 25 000 documents;
- удаление: top 10% и top 25% документов по attribution score;
- контроль: random-removal baseline того же размера;
- после удаления LoRA adapter переобучался на оставшейся выборке.
Чтобы найти документы, которые вроде бы отвечают за поведение, авторы сравнили четыре подхода: EKFAC как gradient-based attribution method, probes на activation space, LLM judge, который читает training documents, и activation-based методы в духе Goodfire. В качестве LLM judge, по словам авторов, использовался Gemini-3 Flash.
Проверяемые поведения были не только про безопасность. В список вошли bold formatting, both-sides framing, ссылки на ethical frameworks, liberal lean, China friendly, validate feelings и refuse+redirect. Такой список важен: речь о широких поведенческих паттернах после SFT, а не только о токсичности или запрещённом контенте.
Главный результат: targeted filtering часто не лучше случайного удаления
По данным авторов, фильтрация документов, найденных attribution-методами, почти не убирала широкие SFT-поведения. На уровне 10% removal методы обычно не превосходили random baseline и не давали значимого падения относительно custom SFT. Главное исключение - refusal: склонность отказывать и перенаправлять запросы оказалась заметно более filterable.
Самый наглядный пример в посте связан с привычкой модели валидировать чувства пользователя. Авторы пишут, что примерно 0,2% documents содержали паттерн valid вместе со словами вроде feelings или concern, а 1,2% содержали слово feeling. Но удаление top 10% документов не снизило склонность модели произносить фразу Your feelings are valid.
Так рушится простая версия data hygiene. Если поведение сидит в явных строках датасета, их можно найти и удалить. Если оно восстанавливается из множества слабых сигналов или из ассистентской persona, то список подозрительных документов перестаёт быть хорошей ручкой управления.
Почему фильтр может не сработать
Ранний пост Josh Engels и Neel Nanda Why Do Naive SFT Filters For Safety Properties Fail?, опубликованный 14 июня 2026 года, даёт полезную рамку. Авторы разбирают, почему filtering safety-relevant SFT rollouts может работать хуже ожиданий: поведение может переноситься через teacher model, prompt distribution и persona selection, а не только через очевидно плохие ответы.
Для практики это означает: после фильтрации надо проверять не только датасет, но и всю цепочку, в которой появился пример. Кто был teacher model? Какие prompts задавали распределение? Не остались ли слабые версии того же trait в других задачах? Не закрепляет ли обучение более широкую ассистентскую роль?
| Гипотеза | Почему фильтр не сработал | Что это значит для ML-команды |
|---|---|---|
| Teacher model rollouts | Черта приходит из стиля модели-учителя, а не из одного плохого примера | Сравнивать разных teacher models и не считать удаление prompts достаточным тестом |
| Prompt distribution | Подсказки недоопределяют нужное поведение, и модель достраивает ответ из prior | Аудировать сами prompts, а не только assistant outputs |
| Слабые сигналы | Поведение размазано по множеству мягких примеров, которые трудно поймать фильтром | Проверять результат через retrain + evals, а не через красивый attribution score |
| Persona selection | Модель выбирает ассистентскую роль, где несколько привычек идут пакетом | Мерить не одну фразу, а связку поведенческих traits |
| Refusal как особый случай | Отказы могут быть более явно связаны с конкретным типом SFT-сигналов | Не переносить успех refusal filtering на все safety и style behaviors |
Почему coding-only данные тоже дают ассистентские привычки
В июльском эксперименте авторы сделали ещё одну проверку: вместо удаления документов они переобучили LoRA adapter на узких slices датасета, только на coding problems или только на reasoning/STEM problems. Если broad behavior действительно зависит от прямых примеров этого поведения, узкий датасет должен был бы дать намного меньше таких привычек.
Результат оказался неудобным: большинство broad SFT behaviors всё равно появлялись. В посте отдельно отмечено, что refusal, наоборот, не усиливался на narrow-domain SFT и в coding-only варианте даже проседал ниже base. Refusal снова отделяется от других ассистентских паттернов.
Для команд, которые строят собственные post-training датасеты, это неприятный сигнал. Нельзя просто сказать: "в coding examples нет политических или safety-поведений, значит они не появятся". Если модель уже умеет выбирать ассистентскую роль, SFT может активировать целый набор привычек через косвенные признаки.
Чего из этого не следует
Этот результат не доказывает, что фильтрация данных бесполезна. У неё остаются нормальные задачи: убрать персональные данные, лицензируемые фрагменты, дубликаты, явный мусор, токсичные примеры, data contamination и небезопасные инструкции. Вопрос уже: можно ли одной фильтрацией управлять сложным поведением модели после SFT.
Здесь ответ осторожнее: иногда можно, но нельзя считать фильтр достаточным. Refusal в работе выглядит более управляемым, но validate feelings, both-sides framing и другие broad behaviors ведут себя иначе. Это похоже на соседнюю проблему из безопасности ИИ и alignment: модель может проходить часть явных проверок, но сохранять поведение в менее прямых сценариях.
Похожая осторожность нужна и к evals. В свежей arXiv-работе Auditing the Audit авторы разбирают, как выводы benchmark-validity audits могут зависеть от скрытых деталей pipeline. Для SFT filtering урок тот же: итоговый график мало что значит без понятного маршрута от данных к поведению и обратно.
Близкий урок есть и в статье про OpenAI beneficial trait training. Поведенческие черты в post-training могут переноситься шире, чем конкретный пример или benchmark. Хорошие traits и нежелательные привычки надо проверять как свойства системы, а не как отдельные строки в датасете.
Что делать вместо одной фильтрации
Если команда использует SFT data filtering как часть post-training, ей нужен контур проверки после каждого фильтра, а не только отчёт о том, сколько примеров удалили. Минимальный набор выглядит так:
- Разделить типы проблем. PII, лицензии и дубликаты чистятся иначе, чем behavioral traits.
- Проверять teacher model. Если examples сгенерированы моделью-учителем, сравнивать rollouts от разных учителей.
- Аудировать prompts отдельно от outputs. Плохое поведение может прийти из распределения задач, даже если ответы выглядят чистыми.
- После фильтрации переобучать и прогонять evals. Attribution score сам по себе не доказывает, что поведение ушло.
- Смотреть на bundles. Если модель получила ассистентскую persona, одна удалённая фраза не гарантирует исчезновение соседних привычек.
- Отдельно тестировать refusal. В этой работе refusal ведёт себя иначе, поэтому его нельзя смешивать в один вывод с broad style behaviors.
Для production-команды это скучнее, чем "очистили датасет и закрыли задачу", зато ближе к реальности. SFT data filtering полезен как слой hygiene и диагностики. Как единственная safety-ручка он слишком слабый.
FAQ
Что такое SFT data filtering?
SFT data filtering - это удаление или замена примеров supervised fine-tuning, которые могут закреплять нежелательное поведение модели. Обычно такие примеры ищут через правила, классификаторы, LLM-judges, probes или attribution methods.
Почему нельзя просто удалить плохие SFT-примеры?
Потому что поведение может задаваться не одним плохим примером. Его могут переносить модель-учитель, распределение prompts, слабые повторяющиеся сигналы или более широкая ассистентская persona. В таком случае фильтр удаляет часть симптомов, но модель после retrain восстанавливает похожую привычку.
Что лучше одной фильтрации данных?
Фильтрацию надо сочетать с retrain-экспериментами, независимыми evals, проверкой teacher model rollouts, аудитом prompt distribution и отдельными тестами на behavioral traits. Для некоторых задач, например refusal, filtering может быть заметно полезнее, но это надо доказывать на конкретном поведении.
Вывод
SFT data filtering плохо удаляет поведение LLM, когда это поведение задаётся распределением данных или teacher model, а не отдельными очевидно плохими примерами. Июльский эксперимент на OLMo-3 SFT показывает это на практике: targeted filtering часто не обгоняет random removal, а narrow-domain SFT всё равно воспроизводит broad assistant-like behaviors.
Хорошая новость в том, что такие работы делают post-training менее магическим. Командам дают не готовую кнопку "убрать поведение", а более честный список проверок: откуда пришёл trait, что именно удаляет фильтр, что меняется после retrain и не вернулось ли поведение через другой канал.
Источники
- Alignment Forum: Data filtering works a lot worse than you would expect, опубликовано 7 июля 2026 года; использовано для setup OLMo-3 SFT, TDA methods, результатов 10/25% filtering, narrow-domain SFT и графиков.
- Alignment Forum: Why Do Naive SFT Filters For Safety Properties Fail?, опубликовано 14 июня 2026 года; использовано для гипотез о teacher model, prompt distribution и persona selection.
- arXiv: Auditing the Audit: Five Failure Modes in Benchmark-Validity Audits, submitted 1 July 2026; использовано как соседний контекст о fragility of evaluation evidence.
