Gender-API vs. ChatGPT: wat moet het geslacht van een naam bepalen?
Beide kunnen je vertellen dat Sandra meestal vrouwelijk is. Slechts één van de twee kan je vertellen hoe het dat weet, je volgend jaar hetzelfde antwoord geven en een miljoen namen vooraf begroten.
Het korte antwoord
- Neem een LLM als je een beoordeling over een handvol namen nodig hebt, of tekst die je kunt lezen: een uitleg, een herkomst, een aanhef.
- Neem een namendatabase als het antwoord morgen identiek moet zijn, met bewijs moet komen, per record een prijs moet hebben, of een vraag van de functionaris gegevensbescherming moet doorstaan.
- Bij grote aantallen beslist niet de nauwkeurigheid maar de verantwoording. 9,124,598 voornamen verdeeld over 192 landen, elk antwoord met zijn eigen aantal samples, tegenover een generatie die haar rekenwerk niet kan laten zien.
- Ze combineren goed. Geef het model de API als tool — wij publiceren daar een gehoste MCP-server voor — dan komt het label uit de data en de formulering van het model.
Wat die twee dingen eigenlijk zijn
Gender-API.com is een opzoekdienst op een namendatabase. 9,124,598 voornamen, uitgesplitst naar het land waarin ze zijn waargenomen, 192 landen ondersteund. Je stuurt een naam en krijgt een geslacht, een kans en het aantal samples waarop het antwoord rust. Er wordt niets gegenereerd.
ChatGPT — en elk ander algemeen taalmodel — is een tekstgenerator. Het weet dat “Sandra” in vrouwelijke contexten voorkomt omdat het woord zich zo gedroeg in de trainingstekst. Dat is een echt nuttig signaal, en bij veelvoorkomende namen levert het het juiste label. Maar er is niets in de architectuur dat opslaat hoeveel Sandra's in Portugal vrouwelijk waren, dus er is niets om te citeren, niets voor een drempel en niets om te controleren.
Dat ene structurele feit verklaart alle praktische verschillen hieronder.
NAAST ELKAAR
De verschillen die blijven staan, welk model je ook kiest.
| Wat je nodig hebt | Gender-API.com | Algemeen LLM |
|---|---|---|
| Hetzelfde antwoord bij dezelfde invoer, elke keer | Ja — het is een database-lookup | Nee — sampling, formulering van de prompt en modelversie veranderen het |
| Bewijs achter één afzonderlijk antwoord | Aantal samples en kans per resultaat en per land | Geen; een betrouwbaarheidsgetal is, als je erom vraagt, zelf ook gegenereerd |
| Dekking die je schriftelijk kunt vastleggen | 9,124,598 namen, 192 landen | Onbekend en niet vermeld |
| Landspecifieke antwoorden | Een parameter voor land, locale of IP verandert het resultaat | Alleen als je het in de prompt zegt — en het blijft een gok |
| Het gedrag over twaalf maanden | Hetzelfde endpointcontract, gepubliceerd als OpenAPI; v1 en v2 zijn beide nog actief | Modellen worden uitgefaseerd en vervangen; de antwoorden schuiven mee |
| Batchverwerking | 100 namen per verzoek, of een CSV van maximaal 10 miljoen rijen | Contextlimieten, chunking, rate limits en nieuwe pogingen schrijf je zelf |
| Kosteneenheid | Eén credit per lookup, uit een pakket dat je vooraf hebt gekocht | Tokens in en uit — afhankelijk van promptlengte en nieuwe pogingen |
| Waar de data wordt verwerkt | Servers in Duitsland, verwerking binnen de EU, DPA op aanvraag | Hangt af van de leverancier, het abonnement en de regio die je krijgt |
| Een volledige naam splitsen, een naam uit een e-mailadres halen | Eigen endpoints | Prompt engineering, en bij randgevallen gaat het stil mis |
| Een naam waarover niemand data heeft | Zegt het — result_found is false, of de kans is laag | Antwoordt toch, in dezelfde zelfverzekerde toon |
| Een naam, zijn herkomst of zijn varianten uitleggen | Daar is het niet voor | Echt beter — hier is een taalmodel voor gemaakt |
Wat kost het om het geslacht van een miljoen namen te bepalen?
Hier staat de rekenmethode in plaats van een marketinggetal, zodat je het met de tarieven van vandaag kunt narekenen.
Met een API: Eén lookup is één credit. Ons beste gepubliceerde volumetarief komt uit op ongeveer €0.35 per 1.000 namen, dus een miljoen namen kost ruwweg €349 netto — een vast bedrag, bekend voordat je begint, op een factuur met btw. Credits uit eenmalige pakketten verlopen niet.
Met een LLM: Je betaalt per token, in beide richtingen, voor elk verzoek en elke nieuwe poging. Meerdere namen in één prompt bundelen verlaagt de kosten per naam, maar je stuurt de instructies bij elke batch opnieuw mee, lange namen en ongebruikelijke schriftsystemen kosten meer tokens dan korte, en een fout gevormd antwoord kost je ook nog de nieuwe poging. Het resultaat is een schatting, geen getal dat je in een begroting kunt zetten.
Eerlijk gezegd: bij een paar duizend namen is een algemeen model zo goedkoop dat niets hiervan uitmaakt. Het omslagpunt komt met de aantallen — en eerder dan de tokenprijs suggereert, omdat al het werk rond bundelen, nieuwe pogingen en het valideren van de uitvoer bij een lookup-endpoint gewoon wegvalt.
Reproduceerbaarheid: het punt dat meestal de knoop doorhakt
Verwerk een klantenlijst twee keer, krijg twee verschillende resultaten, en je hebt een probleem dat je niet kunt uitleggen: welke run had gelijk, wat is er veranderd, en wat zeg je tegen de persoon die vorige maand met “de heer” en deze maand met “mevrouw” is aangeschreven.
Een lookup is deterministisch. Dezelfde naam met hetzelfde land geeft hetzelfde geslacht, dezelfde kans en hetzelfde aantal samples. Als de onderliggende data groeit, groeit het aantal samples mee — zichtbaar, in het antwoord — zodat een verandering iets is dat je kunt aanwijzen in plaats van iets dat gewoon gebeurde.
Een gegenereerd antwoord geeft die garantie niet. De temperature, een nieuwe modelversie, een herschreven systeemprompt, een veiligheidsaanpassing waarover niemand je iets heeft verteld: elk daarvan kan een grensgeval laten kantelen, en geen ervan laat een spoor achter in je data.
Elk antwoord brengt zijn eigen bewijs mee
Eén enkel verzoek aan het v2-endpoint:
POST https://gender-api.com/v2/gender/by-first-name
{ "first_name": "Sandra" }{
"input": { "first_name": "Sandra" },
"details": {
"credits_used": 1,
"samples": 464,
"country": null,
"first_name_sanitized": "sandra",
"duration": "436ms"
},
"result_found": true,
"first_name": "Sandra",
"probability": 0.85,
"gender": "female"
}Twee velden doen het werk dat geen gegenereerd antwoord biedt. “samples” geeft aan op hoeveel waarnemingen het antwoord rust, en “probability” welk deel daarvan vrouwelijk was. Samen kun je daarmee je eigen grens leggen — resultaten boven 0.9 met een behoorlijk aantal samples overnemen en de rest naar handmatige controle sturen — in plaats van één betrouwbaarheidsniveau voor je hele database te accepteren.
Volledige referentie: de v2-API-documentatie.
Dezelfde naam is niet overal hetzelfde geslacht
Andrea is in Italië overwegend mannelijk en in Duitsland overwegend vrouwelijk. Jean is in Frankrijk mannelijk en in Engelstalige landen grotendeels vrouwelijk. Nikita is in Rusland mannelijk en elders meestal vrouwelijk. Dit zijn geen exotische randgevallen — dit zijn gewone namen in gewone klantenlijsten.
Vraag een algemeen model zonder land te noemen en je krijgt de lezing die in zijn trainingstekst overheerste, wat in de praktijk de Engelstalige is. De API neemt het land expliciet:
Een locale (en_US) of het IP-adres van de bezoeker werkt net zo goed, en voor de omgekeerde vraag is er een apart endpoint: uit welk land een naam komt.
GDPR, en waar de namen die je stuurt echt heen gaan
Voornamen van echte klanten zijn persoonsgegevens, dus dit is een inkoopvraag en geen voetnoot. Wat wij duidelijk kunnen zeggen:
- Wij zijn een Duits bedrijf; al onze servers staan in Duitsland en de data wordt binnen de EU verwerkt.
- Een verwerkersovereenkomst kun je in je account aanvragen.
- Serverlogs bevatten de ingestuurde naam en worden 14 dagen bewaard, om boekhoudkundige redenen.
- Geüploade CSV- en Excel-bestanden worden versleuteld opgeslagen en na tien dagen verwijderd.
- Elke aankoop levert een correcte factuur met btw op, en EU-btw-nummers worden juist verwerkt.
Of een bepaalde modelleverancier acceptabel is voor dezelfde data is een vraag voor je functionaris gegevensbescherming — maar een langere vraag, en een die je opnieuw moet stellen elke keer dat de leverancier een subverwerker wisselt. Onze antwoorden staan in het privacyoverzicht.
Wanneer ChatGPT de betere keuze is
Deze pagina zou niet het lezen waard zijn als het antwoord altijd “koop de API” was. Dat is het niet:
- Een eenmalig klusje. Veertig namen in een spreadsheet, geen pipeline, niemand doet het ooit opnieuw.
- Je wilt de onderbouwing, niet het label: de herkomst van een naam, zijn varianten, hoe hij normaal wordt afgekort, hoe je iemand in een bepaalde cultuur hoffelijk aanspreekt.
- Namen die geen database heeft: nieuwe verzinsels, personages uit fictie, transliteraties die in geen enkel register staan. Een model maakt een redelijke gok waar een lookup simpelweg niets heeft.
- Wat je nodig hebt als uitvoer is vrije tekst, geen veld: een aanhefregel in plaats van een geslachtskolom.
Dat is niet vrijgevig bedoeld, wij gebruiken ze net zo: de beschrijvingen van de naamherkomst op onze eigen naampagina's worden door een taalmodel gegenereerd, omdat tekst precies is waar een taalmodel goed in is.
Het beste is beide: laat het model de API aanroepen
Als je al op een LLM bouwt, hoef je niet te kiezen. Moderne modellen roepen tools aan, en een geslachtslookup is een ideale tool: een nauwe vraag met een feitelijk antwoord waarvoor het model geen data heeft.
Wij publiceren een gehoste MCP-server zodat elke MCP-geschikte assistent of agent de database direct kan bevragen. De tools zijn query_first_name, query_full_name, query_email, get_country_of_origin en get_statistics.
Voor je eigen tooldefinities zijn er officiële clients voor negen talen (PHP, Python, Node, Java, Go, Ruby, Rust, Perl, .NET), een OpenAPI-beschrijving, en op /skill.md een kant-en-klare implementatiehandleiding die je direct aan een codeerassistent kunt geven.
Juist die taakverdeling is het punt: het model bepaalt wat er moet gebeuren, de database bepaalt wat waar is.
Veelgestelde vragen
Kan ChatGPT het geslacht van een naam bepalen?
Ja, en bij veelvoorkomende voornamen heeft het meestal gelijk. Wat het niet kan: je vertellen op hoeveel records het antwoord rust, twee keer hetzelfde antwoord garanderen, of voor dezelfde naam in een ander land een ander antwoord geven. Het antwoordt ook net zo zelfverzekerd bij namen die het nooit heeft gezien, en juist die fout telt op grote schaal.
Is een gender-API nauwkeuriger dan een LLM?
Voor een naam die in een namendatabase staat, is een lookup per constructie exact: hij geeft de waargenomen verdeling weer in plaats van een gevolgtrekking. Bij een onbekende naam is geen van beide aanpakken te vertrouwen, maar alleen de lookup geeft dat toe. Het betrouwbare verschil is geen enkel nauwkeurigheidspercentage — het is dat elke lookup komt met een aantal samples en een kans waarop je een drempel kunt zetten.
Wat kost het om het geslacht van een miljoen namen te bepalen?
Bij Gender-API kost één lookup één credit, dus een miljoen namen is een vast, bekend bedrag: ongeveer €349 netto tegen ons beste gepubliceerde volumetarief, op een factuur met btw, afgesproken voordat je begint. Bij een LLM betaal je per token voor elk verzoek en elke nieuwe poging, dus de rekening hangt af van je promptlengte en valt alleen te schatten.
Kan ik een LLM en een gender-API samen gebruiken?
Ja, en dat is de beste opzet. Geef het model de API als tool — wij publiceren daar een gehoste MCP-server voor — dan komt het label uit de database en de formulering van het model. Het model gokt niet langer over feiten waarvoor het geen data heeft.
Heeft dezelfde naam in elk land hetzelfde geslacht?
Nee, en precies daar gaat een prompt zonder land de mist in. Andrea is in Italië overwegend mannelijk en in Duitsland overwegend vrouwelijk; Jean is in Frankrijk mannelijk en in Engelstalige landen grotendeels vrouwelijk. De API neemt een land, een locale of een IP-adres en antwoordt voor dat land.
Wat gebeurt er bij een naam die de database niet kent?
Je krijgt result_found: false, of een lage kans met weinig samples. Dat is een signaal waarmee je iets kunt doen: stuur die records naar handmatige controle, of val terug op een model. Een generatief antwoord geeft je zo'n signaal niet.
Is Gender-API GDPR-conform?
Wij zijn een Duits bedrijf, alle servers staan in Duitsland en de data wordt binnen de EU verwerkt. Een verwerkersovereenkomst kun je in je account aanvragen. Requestlogs, die de ingestuurde naam bevatten, worden om boekhoudkundige redenen 14 dagen bewaard; geüploade CSV- en Excel-bestanden worden versleuteld opgeslagen en na tien dagen verwijderd.
PROBEER HET OP JE EIGEN NAMEN
Elk account bevat 100 gratis lookups per maand — genoeg om de namen te controleren die een LLM verkeerd had. Zonder creditcard.
API-documentatie · Geslacht toevoegen aan een CSV- of Excel-bestand · MCP-server
