Как да проверя AI за дискриминация?

За да провериш AI система за дискриминация през 2026, трябва да дефинираш защитените групи и контекста на решението, да измериш разлики в грешките и резултатите между групи (fairness метрики), да тестваш със сценарии и контрафактуални примери, и да документираш какво правиш и защо. Дискриминацията в AI рядко е „бъг в модела“; най-често е резултат от данни, дефиниции и процеси.

Въведение

„Дискриминация“ означава, че система третира хора или групи неравнопоставено по начин, който е несправедлив или незаконен. В AI това може да се прояви като:

  • Различна точност (по-висок error rate за една група).
  • Различен шанс за одобрение/отказ при еднакви условия.
  • Различна вероятност за „погрешно положително“ (false positive) или „погрешно отрицателно“ (false negative).

Важно: fairness не е само за таблични модели. Генеративните модели (LLM) също могат да проявяват bias чрез по-стереотипни отговори, различен тон или по-ниско качество за определени групи.

Ако не измерваш fairness по групи, нямаш основание да твърдиш, че системата е „неутрална“.

Стъпка 1: Определи домейна, решението и защитените атрибути

Започни с ясна рамка:

  • Какво решение взема AI (скоринг, подбор, кредит, тарифа, приоритизация)?
  • Кой е засегнат (кандидати, клиенти, ученици, пациенти)?
  • Кои атрибути са защитени/чувствителни в твоя контекст (пол, възраст, етнос, инвалидност, религия и т.н.)?

Внимавай за „прокси“ атрибути. Понякога не държиш директно чувствителен атрибут, но имаш индиректни сигнали (пощенски код, училище, работодател, име), които корелират и могат да пренесат исторически bias.

Практика: направи списък с потенциални проксита и ги тествай като отделни групирания.

Стъпка 2: Направи data audit и провери представителността

Преди метрики, провери данните:

  • Има ли достатъчно примери за всяка група?
  • Има ли систематични липсващи стойности?
  • Как са етикетирани данните и кой е „истината“?

Чести проблеми:

  • Исторически bias: миналите решения са били несправедливи и моделът ги „учил“.
  • Sampling bias: някои групи са слабо представени.
  • Measurement bias: измерванията са по-неточни за една група.

Мини подход:

  • Изчисли брой и базови статистики по групи.
  • Провери дали label-ите имат различна надеждност по групи.
  • Ако група е малка: използвай доверителни интервали и не прави категорични изводи.

Стъпка 3: Избери fairness метрики според вредата (harm)

Няма една метрика, която „решава“ всичко. Избираш според домейна и вредата.

Типични метрики:

  • Demographic parity: еднаква честота на положителен изход по групи.
  • Equal opportunity: еднакъв true positive rate (TPR) по групи.
  • Equalized odds: еднакви TPR и FPR по групи.
  • Calibration: вероятностите означават същото за всички.

Практичен избор:

  • Ако вредата от false positives е висока (напр. неправомерен отказ): гледай FPR по групи.
  • Ако вредата от false negatives е висока (напр. пропусната помощ): гледай FNR/TPR по групи.
  • Ако резултатът е „скоринг“: калибрацията става критична.

Fairness е компромис между метрики; твоята задача е да избереш компромис, който е оправдан и документиран.

Стъпка 4: Изчисли метриките по групи (и по прагове)

Създай „fairness отчет“, който включва:

  • Метриките по групи.
  • Разликите между групи (gap).
  • Доверителни интервали (ако е възможно).
  • Анализ по прагове (threshold sweep).

Мини процес:

  1. Раздели тестовия набор по групи.
  2. За всяка група изчисли confusion matrix.
  3. Сравни TPR/FPR/precision/recall.
  4. Провери как се променя gap при различни прагове.

Практика: не гледай само средните стойности. Гледай и „най-лошата група“.

Стъпка 5: Стрес тестове и контрафактуални проверки

Само статистика по групи не стига. Добави:

  • Контрафактуални тестове: държиш всичко същото, сменяш чувствителен атрибут (или прокси) и гледаш дали изходът се променя.
  • Сценарии: групи, които се различават по един ключов фактор.
  • Adversarial примери: „гранични“ случаи.

За LLM тестът е различен:

  • Даваш еднакви промптове с различни имена/контекст.
  • Мериш токсичност, стереотипи, различна учтивост/качество на съвет.
  • Повтаряш тестовете при различни „температури“ и формати, за да видиш стабилност.

Стъпка 6: Използвай инструменти и библиотеки (за да не измисляш всичко)

Два популярни open-source подхода:

  • Fairlearn: фокус върху fairness метрики и оценяване.
  • AIF360: набор от метрики и техники за mitigation.

Дори без да внедряваш библиотека, структурата им помага: метрики -> анализ -> mitigation -> повторен тест.

Стъпка 7: Mitigation: pre-, in- или post-processing

Типични стратегии:

  • Pre-processing: ребалансиране, корекция на етикети, премахване/намаляване на прокси сигнали.
  • In-processing: fairness ограничения при обучението.
  • Post-processing: корекция на прага, калибрация (внимание: правни/етични последици).

Не търси „перфектно равенство“ на метрики. Търси разумно намаляване на вредата и ясна документация.

Стъпка 8: Документация и governance (как да го направиш устойчиво)

Дори най-добрият тест е безполезен, ако не е част от процес.

  • Опиши целта на системата и ограниченията.
  • Опиши данните и потенциалните bias източници.
  • Опиши fairness метриките, праговете и избраните компромиси.
  • Въведи мониторинг в production: метрики по групи (когато е законно/възможно), drift, инциденти.

Като ориентир могат да служат рамки като NIST AI RMF и регулаторни изисквания като EU AI Act (особено за high-risk системи).

Стъпка 9: Мониторинг в production

Fairness може да се влоши след launch:

  • Входните данни се променят (drift).
  • Потребителите адаптират поведението си.
  • Променят се бизнес правила или прагове.

Практика:

  • Следи метрики по групи периодично.
  • Следи „жалби“ и негативни сигнали.
  • Прави ретроспекции при инцидент и обновявай тестовете.

Съвети за по-добри резултати

  • Тествай fairness още на прототип, не след launch.
  • Дръж „golden set“ от тестове за регресия.
  • Включи домейн експерти и комплайънс при висок риск.
  • За LLM: използвай сценарии, които проверяват стереотипи и различно качество.
  • Не забравяй „прокси“ атрибути.

Чести грешки, които да избягваш

  • Да мериш само обща accuracy и да игнорираш групите.
  • Да нямаш достатъчно данни за малки групи (нестабилни изводи).
  • Да „поправиш“ метрика без да оцениш странични ефекти.
  • Да промениш прагове и да счупиш бизнес логика.
  • Да липсва документация: защо избра този компромис.

Мини пример: как изглеждат числата (TPR/FPR) по групи

Да кажем, че имаш бинарен модел „одобри/откажи“ и две групи A и B. За всяка група изчисляваш:

  • TPR (True Positive Rate): от всички реално „подходящи“, колко одобряваме.
  • FPR (False Positive Rate): от всички реално „неподходящи“, колко погрешно одобряваме.

Примерни резултати:

  • Група A: TPR 0.82, FPR 0.10.
  • Група B: TPR 0.71, FPR 0.18.

Интерпретация:

  • По-ниският TPR за група B означава, че системата по-често „пропуска“ подходящи кандидати от тази група (вреда чрез false negatives).
  • По-високият FPR за група B означава, че системата по-често одобрява неподходящи (вреда, ако това води до санкции/разходи).

Следващата стъпка е анализ по праг: понякога един праг е лош за едната група и добър за другата. Това не значи автоматично, че трябва да имаш различни прагове, но означава, че прагът е ключово решение и трябва да е документиран.

Шаблон за „fairness отчет“ (който да използваш всеки път)

За да стане процесът повторяем, поддържай отчет със стандартни секции:

  • Контекст: какво решение взема моделът и за кого.
  • Данни: snapshot ID, период, представителност по групи.
  • Метрики: TPR/FPR/precision/recall по групи, плюс gap.
  • Праг и обосновка: защо е избран.
  • Тестове: контрафактуални примери, сценарии, LLM тестове (ако е релевантно).
  • Mitigation: какво е променено и какъв е ефектът.
  • Остатъчен риск: какво остава като слабост.
  • План за мониторинг: какво следиш след launch.

Когато нямаш чувствителни атрибути: какво можеш да направиш

Понякога не е законно или практично да събираш чувствителни атрибути. Това не означава, че трябва да игнорираш риска.

  • Тествай прокси групи (например региони/тип училище) и търси големи разлики.
  • Използвай доброволни, агрегирани данни (ако имаш политика и съгласие).
  • Усили стрес тестовете и контрафактуалните сценарии.
  • Въведи човешки контрол за рискови решения.

Целта е да имаш разумни доказателства, че си търсил и управлявал проблема, а не си го „премълчал“.

Минимални технически контроли (за да не се връщаш назад)

За да не „изчезне“ fairness работата след първия релийз:

  • Пази тестов пакет (golden set) и го пускай автоматично при всяка промяна.
  • Следи метриките по групи в staging, преди production.
  • Логвай версия на модел, праг и preprocessing за всяка заявка.
  • Въведи аларма при скок на gap между групи.

Тези контроли правят дискриминацията откриваема, а не „невидима“.

Бързо правило

Ако не можеш да обясниш избраната fairness метрика с едно изречение, процесът ти е прекалено сложен.

Често задавани въпроси

1) Каква е най-важната метрика за дискриминация?

Няма една. Изборът зависи от риска и вредата. Често се гледат разлики в TPR/FPR по групи и калибрация.

2) Мога ли да тествам fairness, ако не събирам чувствителни атрибути?

Понякога да, чрез доброволни данни, агрегирани анализи или прокси проверки, но трябва да се съобразиш със законови и етични изисквания.

3) Контрафактуалните тестове надеждни ли са?

Полезни са като сигнал, но не са перфектни. Работят най-добре, когато можеш да изолираш промяна в атрибут без да нарушиш реалистичността.

4) Как да тествам LLM за дискриминация?

Създай набор от промптове с контролирани вариации (имена, контекст), мери различия в качество, токсичност и стереотипи и повторяй тестовете при всяка промяна.

5) Какво да направя, ако fairness подобрението намалява точността?

Избери компромис според риска: при high-risk системи често се предпочита по-нисък риск от дискриминация, дори с цена в общата точност, и се добавя човешки контрол.