Bias в решениях AI-агентов: как его выявить до внедрения

Летом 2024 года стало нормой доверять LLM-агентам задачи, которые раньше делал человек: отсев резюме, первичную оценку заявки на кредит, модерацию отзывов, распределение обращений в поддержке. Проблема в том, что агент на базе большой языковой модели не «беспристрастная машина». Он воспроизводит закономерности обучающих данных — и там, где в данных зашита дискриминация, агент выдаёт её на автомате, но с интонацией уверенного эксперта. Ниже — про то, как это проявляется и чем измеряется.

Что такое bias у языковой модели

Под bias¹ понимают не одну вещь, а несколько разных явлений, которые в статьях часто сваливают в кучу. Разделять их важно, потому что ловятся они по-разному.

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

Для агента, который принимает или готовит решения, критично второе. Именно оно превращается в юридический и репутационный риск.

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

Откуда bias попадает в агента

Источников несколько, и они складываются. Базовая модель уже несёт смещения корпуса. Поверх — дообучение² на ваших внутренних данных, где отражены прошлые решения компании (если раньше отсеивали кандидатов по возрасту, агент это выучит). Дальше — промпт и системная инструкция, которые могут неявно подсказывать модели «правильный» ответ. И наконец — RAG³: если агент подтягивает документы из базы, где перекос уже есть, он его усилит.

Именно поэтому проверять нужно не «модель вообще», а конкретную сборку: модель плюс промпт плюс данные плюс инструменты. Один и тот же GPT-4o в двух разных пайплайнах даёт разный уровень смещения.

Как выявлять: три подхода

1. Контрфактические тесты

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

Пример: два резюме, отличающиеся только именем «Александр» и «Гульнара», при равном опыте. Если агент чаще рекомендует к собеседованию первое — это измеримый факт, а не подозрение.

2. Групповые метрики справедливости

Заимствованы из классического ML. Смотрят не на отдельные пары, а на распределение решений по группам:

• Demographic parity — доля положительных решений одинакова между группами.
• Equal opportunity — доля верно одобренных одинакова среди тех, кто «заслуживал» одобрения.
• Equalized odds — совпадают и доли верных одобрений, и доли ошибочных отказов.

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

3. Аудит на бенчмарках

Существуют открытые наборы для оценки смещений LLM — например BBQ (Bias Benchmark for QA) и WinoBias для гендерного смещения в разрешении местоимений. Они дают сравнимую цифру, но проверяют модель «в вакууме», а не вашу сборку. Использовать их стоит как отправную точку, а не как финальную гарантию — реальное поведение агента в вашем пайплайне может отличаться.

Инструменты для проверки

На практике связка выглядит так: контрфактический набор под вашу задачу для поиска смещения в решениях, плюс групповые метрики через Fairlearn на исторических данных, плюс прогон на BBQ как sanity-check базовой модели.

Кому это пригодится и кому нет

Обязательно нужно, если агент влияет на людей и их доступ к ресурсам:

• HR-скрининг резюме и первичные интервью — риск дискриминации при найме;
• кредитный или страховой скоринг — здесь смещение может нарушать закон;
• модерация пользовательского контента — где перекос бьёт по одним группам сильнее, чем по другим;
• медицинская и юридическая поддержка — цена неверного совета высокая.

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

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

Что делать с найденным смещением

1. Зафиксируйте базовую цифру — долю расхождений в контрфактических парах до любых правок. Без неё вы не докажете, что стало лучше.
2. Начните с промпта — часто явный запрет учитывать нерелевантные признаки снижает смещение дешевле, чем дообучение.
3. Почистите данные для RAG и дообучения — уберите или сбалансируйте перекос в источниках.
4. Добавьте человека в контур для решений с высокой ценой ошибки — и логируйте, как часто человек меняет решение агента.
5. Повторяйте замер после каждого обновления модели — новая версия базовой LLM может вернуть смещение, которое вы уже победили.

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

¹ Bias — систематическая ошибка модели, при которой её выводы стабильно смещены в одну сторону из-за перекоса в данных или обучении, а не случайны.

² Дообучение (fine-tuning) — дополнительная тренировка готовой модели на своих данных, чтобы адаптировать её под конкретную задачу.

³ RAG (retrieval-augmented generation) — схема, где модель перед ответом подтягивает релевантные документы из внешней базы и опирается на них.