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

Как да проверя 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 системи често се предпочита по-нисък риск от дискриминация, дори с цена в общата точност, и се добавя човешки контрол.