Fairness-in-the-Workflow: How Machine Learning Practitioners at Big Tech Companies Approach Fairness in Recommender Systems

Dit artikel beschrijft op basis van interviews met practitioners bij grote techbedrijven hoe zij eerlijkheid in aanbevelingssystemen benaderen, identificeert de technische en organisatorische uitdagingen die hierbij spelen, en biedt praktische aanbevelingen voor de gemeenschap.

De kern

Stel je voor dat een aanbevelingssysteem (zoals die op Netflix, YouTube of Amazon) een gigantische, onzichtbare bibliothecaris is. Deze bibliothecaris kent je beter dan jezelf en probeert je altijd precies het juiste boek te geven. Maar wat als deze bibliothecaris onbewust vooroordelen heeft? Wat als hij alleen boeken van bepaalde schrijvers laat zien, of juist bepaalde verhalen negeert? Dat is het probleem van "onrechtvaardigheid" in deze systemen.

Deze paper, geschreven door onderzoekers die gesprekken hebben gevoerd met 11 experts van grote tech-bedrijven, kijkt achter de schermen. Ze vragen zich af: Hoe proberen deze bibliothecarissen (de programmeurs) eerlijk te zijn, en waarom is dat zo ontzettend lastig?

Hier is een uitleg in gewone taal, met een paar creatieve vergelijkingen:

1. De Grote Uitdaging: Een Balansoefening

De programmeurs werken niet in een leeg laboratorium. Ze bouwen systemen die twee groepen mensen bedienen: de makers (bijv. YouTubers of verkopers) en de kijkers/kopers.

• De vergelijking: Stel je voor dat je een groot festival organiseert. Je moet zorgen dat de artiesten (makers) genoeg publiek krijgen, maar ook dat het publiek (kopers) tevreden is met wat ze zien.
• Het probleem: Soms willen de makers dat hun content bovenaan staat, maar dat is misschien niet eerlijk voor de kijkers. Soms wil de wet zeggen "geen discriminatie", maar dat is in de praktijk heel moeilijk te vertalen naar een computercode. De programmeurs moeten constant een touwkringswedstrijd spelen tussen deze verschillende belangen.

2. De Werkstroom: Van Tekentafel tot Straat

De paper beschrijft hoe deze experts werken. Het is geen rechte lijn, maar een rondje:

• Fase 1: De Tekentafel (Offline): Hier bouwen ze het model. Ze vragen om data aan de 'data-team' en checken met de 'juristen' of ze bepaalde gegevens mogen gebruiken.
  • Vergelijking: Het is alsof je een auto ontwerpt. De juristen zeggen: "Gebruik geen gevaarlijke materialen." De programmeurs zeggen: "Oké, maar hoe maken we hem dan snel?"
• Fase 2: De Test (Online): Zodra het systeem live gaat, kijken ze hoe echte mensen reageren. Hier komt het 'eerlijkheidsteam' (vaak 'Responsible AI' genoemd) kijken.
  • Vergelijking: De auto rijdt nu op de weg. Plotseling merken ze dat de banden slijten bij regen. Ze moeten de auto aanpassen terwijl hij nog rijdt.

3. De Drie Grote Struikelblokken

De experts noemen drie hoofdproblemen die hen dwarszitten:

A. Wat betekent "eerlijk" eigenlijk?
In de wetenschap zijn er honderden formules voor eerlijkheid. Maar in de praktijk is het vaag.

• Vergelijking: Het is alsof je vraagt: "Wat is een 'gezond' ontbijt?" Voor de ene persoon is dat eieren, voor de ander havermout. De programmeurs weten niet altijd welke "recept" ze moeten volgen, vooral als er geen wet is die het voorschrijft. Ze moeten vaak op hun buikgevoel (intuïtie) vertrouwen, wat gevaarlijk kan zijn.

B. Te veel groepen om in de gaten te houden
De systemen hebben te maken met duizenden verschillende groepen mensen.

• Vergelijking: Stel je voor dat je een leraar bent met 10.000 leerlingen. Je wilt dat iedereen een eerlijke kans krijgt. Maar als je kijkt naar elke combinatie van leeftijd, hobby, woonplaats en achtergrond, word je gek. De programmeurs zeggen: "Het is bijna onmogelijk om voor elke kleine groepje te checken of het eerlijk is."

C. De Dynamische Wereld (Het Feedback-Lusje)
Systeem leren van wat mensen doen. Als mensen op een video klikken, leert het systeem dat die video populair is.

• Vergelijking: Het is als een echo in een bergdal. Als je een geluid maakt, hoor je een echo. Als je die echo weer roept, wordt het steeds harder. Zo werkt het ook met aanbevelingen: als het systeem iets een beetje vaker laat zien, klikken mensen er meer op, en dan laat het systeem het nog vaker zien. Dit kan leiden tot een "rijker wordt rijker"-effect, waarbij populaire dingen nog populairder worden en andere verdwijnen.

4. Organisatorische Problemen: Tijd en Taal

Naast de technische problemen zijn er ook problemen binnen het bedrijf:

• Tijdsgebrek: De programmeurs hebben het druk. Ze moeten zorgen dat de site niet crasht. "Eerlijkheid" is vaak niet zo'n noodsituatie als een crash.
  • Vergelijking: Het is alsof je een huis bouwt. Als het dak lekt, repareer je dat direct. Maar als je denkt: "Misschien is de verf op de muur niet eerlijk verdeeld," schuif je dat vaak naar later, omdat je eerst het dak moet redden.
• Taalbarrière: De technische team en het eerlijkheidsteam praten vaak verschillende talen.
  • Vergelijking: De programmeurs praten in "code en wiskunde", terwijl het eerlijkheidsteam (vaak psychologen of sociologen) praat in "sociale concepten en ethiek". Het is alsof een architect en een kunstenaar proberen samen een huis te ontwerpen, maar ze gebruiken verschillende woorden voor dezelfde dingen. De juristen daarentegen spreken een heel duidelijke taal ("Ja" of "Nee"), wat veel makkelijker is.

5. Wat Kunnen We Doen? (De Oplossingen)

De auteurs geven een paar adviezen om dit beter te maken:

1. Schrijf het op (Documentatie): Bedrijven moeten beter bijhouden wat ze hebben gedaan. Nu is het vaak alsof een programmeur vertrekt en zijn kennis meeneemt, en de volgende moet het wiel opnieuw uitvinden.
2. Begin eerder: Wacht niet tot het systeem live is om over eerlijkheid na te denken. Betrek het eerlijkheidsteam al tijdens het ontwerpen (zoals je een bouwvergunning vroeg vraagt).
3. Een gemeenschappelijke taal: Bedrijven moeten zorgen dat de technische en ethische teams beter met elkaar kunnen communiceren. Misschien door "brugbouwers" aan te stellen die beide talen spreken.
4. Meer tijd: Bedrijven moeten programmeurs tijd geven om na te denken over eerlijkheid, in plaats van alleen maar te jagen op snelheid en winst.

Conclusie

De boodschap is hoopvol maar realistisch. De programmeurs willen graag eerlijke systemen bouwen; ze vinden het belangrijk en "het juiste ding om te doen". Maar ze zitten vast in een web van complexe keuzes, gebrek aan tijd en moeilijke communicatie. Als we de weg vrijmaken voor betere tools, meer tijd en betere samenwerking, kunnen we ervoor zorgen dat deze digitale bibliothecarissen niet alleen slim zijn, maar ook eerlijk.

Technische samenvatting

Probleemstelling

Aanbevelingssystemen (Recommender Systems - RS) zijn cruciaal in hoog-risico domeinen zoals e-commerce en sociale media, maar ze zijn vatbaar voor biases die grote maatschappelijke, ideologische en psychologische impact kunnen hebben. Hoewel de academische wereld veel methoden heeft ontwikkeld om deze biases te meten en te mitigeren, is de vertaling van deze theorie naar de praktijk binnen grote technologiebedrijven ("Big Tech") uiterst complex.

De kernproblemen zijn:

1. Dynamische context: Fairness is geen statisch concept; de betekenis verschuift per context.
2. Multi-stakeholder belangen: RS moeten de belangen van diverse partijen (aanbieders/creators en eindgebruikers) in evenwicht brengen, wat vaak leidt tot conflicterende doelen.
3. Feedback loops: RS genereren data op basis van hun eigen aanbevelingen, wat kan leiden tot versterking van bestaande biases.
4. Kloof tussen theorie en praktijk: Bestaande academische tools en metrics zijn vaak niet direct toepasbaar op de specifieke, schaalbare en dynamische workflows van industriële RS.

Methodologie

De auteurs hebben een kwalitatief onderzoek uitgevoerd om te begrijpen hoe ML-praktici bij grote tech-bedrijven omgaan met fairness.

• Datacollectie: Semi-gestructureerde interviews met 11 technische ML-praktici (Machine Learning Engineers, Researchers, Scientists) die actief betrokken zijn bij het bouwen van RS.
• Deelnemers: Werkten bij zeven verschillende grote technologiebedrijven (allemaal met meer dan 1 miljard gebruikers per jaar). De gemiddelde ervaring was 5,36 jaar.
• Analyse:
  • Workflow Mapping: Het identificeren van gemeenschappelijke patronen in de RS-ontwikkelingsworkflow en hoe deze overlapt met fairness-taken.
  • Inductieve Thematische Analyse: Het coderen van interviewtranscripten om technische en organisatorische uitdagingen te identificeren.
• Focus: De studie richt zich specifiek op de technische workflows en de interactie met juridische, data- en fairness-teams.

Key Contributions (Belangrijkste Bijdragen)

1. Een kaart van de RS-praktijkworkflow: Een gedetailleerd model dat laat zien hoe technische teams fairness integreren, zowel intern als in samenwerking met andere afdelingen.
2. Overzicht van uitdagingen: Een systematisering van de technische en organisatorische barrières die voorkomen dat fairness effectief wordt geïmplementeerd.
3. Actiepunten: Concreet advies voor zowel praktici als HCI-onderzoekers om fairness beter in workflows te integreren.

Resultaten en Bevindingen

1. De RS-Workflow en Fairness Integratie

De workflow wordt onderverdeeld in offline (ontwikkeling) en online (deployments) fases, met drie specifieke fasen voor fairness:

• Prototyping-fase: Technische teams werken samen met juridische en data-teams. Juridische teams geven richtlijnen over welke data (bijv. gevoelige attributen) niet gebruikt mag worden. Praktici formuleren hypotheses over biases en ontwikkelen vaak "intuïtieve" of op maat gemaakte metrics, omdat academische tools als niet direct toepasbaar worden ervaren.
• Interne fase: Tijdens de offline validatie testen teams hun metrics en zoeken handmatig naar onverwachte biases. Dit is lastig omdat RS afhankelijk zijn van gebruikersgedrag, wat moeilijk te simuleren is met historische data alleen.
• Collaboratieve fase: Na het online zetten van het model geeft het fairness-team feedback. Praktici hebben echter vaak de vrijheid om deze feedback al dan niet te implementeren, afhankelijk van de beschikbare tijd en de impact op de uptime van het systeem.

2. Technische Uitdagingen

• Definiëren van Fairness: Er is geen eenduidige definitie. Praktici worstelen met het toepassen van wettelijke regels (die per context verschillen, bijv. dating vs. werk) en het definiëren van fairness voor niet-wettelijk beschermde attributen (zoals populariteit).
• Aanpassen van Metrics: Bestaande academische metrics zijn vaak te star of niet schaalbaar. Praktici bouwen vaak nieuwe, op maat gemaakte metrics ("bespoke metrics") omdat ze geen tijd hebben voor literatuurstudie en interne documentatie vaak ontbreekt ("documentation debt").
• Multi-stakeholder Belangen: Het balanceren van conflicterende belangen (bijv. creators vs. gebruikers) is complex. Ook het prioriteren van niet-conflicterende fairness-doelen (bijv. demografische pariteit én eerlijke advertentiewerving) is een uitdaging.
• Dynamische Omgevingen: Door feedback loops kunnen biases ontstaan die niet in de offline testfase zichtbaar waren. Het meten en corrigeren van biases in een live systeem is riskant omdat het de prestaties kan verstoren.

3. Organisatorische Uitdagingen

• Tijdsgebrek: Praktici besteden minder dan 10% van hun tijd aan fairness. Fairness wordt vaak niet gezien als een "disruptieve noodsituatie" en heeft daarom lagere prioriteit dan uptime of engagement-metrics.
• Gebrek aan een 'Fairness Lingua Franca': Er is een communicatiekloof tussen technische teams en fairness-teams. Fairness-teams gebruiken vaak terminologie uit psychologie of communicatie die ML-ingenieurs niet begrijpen. In tegenstelling tot juridische teams (die duidelijke, harde regels geven), geven fairness-teams vaak vage feedback die moeilijk te vertalen is naar code.
• Late Inbreng: Fairness-teams worden vaak pas betrokken in de late, online fases, terwijl ze eigenlijk al in de prototyping-fase hadden moeten worden ingeschakeld.

Significantie en Aanbevelingen

De studie benadrukt dat het verbeteren van fairness in RS niet alleen een technisch probleem is, maar ook een organisatorisch en communicatief vraagstuk.

Aanbevelingen voor Praktici en Organisaties:

• Documentatie: Het creëren van gestructureerde kennis over eerdere fairness-werkzaamheden om hergebruik van metrics mogelijk te maken.
• Vroege Integratie: Fairness-teams moeten eerder in de workflow worden betrokken (tijdens prototyping) om proactief te kunnen werken in plaats van reactief.
• Investering in Multi-stakeholder Fairness: Bedrijven moeten resources vrijmaken voor onderzoek naar optimalisatie-algoritmen die rekening houden met meerdere, soms conflicterende, stakeholder-doelen.

Aanbevelingen voor HCI-onderzoekers:

• Ontwikkeling van Tools: Het bouwen van tools die ethische overwegingen in de workflow integreren (bijv. "Ethos Lifecycle") en die helpen bij het vertalen van abstracte principes naar concrete technische maatregelen.
• Brugbouwen: Onderzoek naar effectieve manieren om de communicatie tussen technische en niet-technische teams te verbeteren, bijvoorbeeld door "bridging roles" te faciliteren of gemeenschappelijke terminologie te ontwikkelen.
• Value Sensitive Design (VSD): Het toepassen van VSD-methodieken om de spanningen tussen verschillende stakeholder-waarden systematisch te adresseren tijdens het ontwerpproces.

Conclusie:
Hoewel praktici in de industrie vaak gefrustreerd zijn door de complexiteit en het gebrek aan tijd, zien ze fairness als een noodzakelijk en waardevol onderdeel van hun werk. De weg naar effectieve fairness in RS vereist een verschuiving van ad-hoc oplossingen naar gestructureerde, goed gedocumenteerde en vroeg in het proces geïntegreerde workflows, ondersteund door betere communicatie tussen alle betrokken teams.