Gender-API vs. ChatGPT: hvad skal bestemme kønnet ud fra et navn?
Begge kan fortælle dig, at Sandra typisk er feminint. Kun én af dem kan fortælle dig, hvor den ved det fra, give dig samme svar næste år og prissætte en million navne, før du starter.
Det korte svar
- Tag en LLM, når du har brug for en vurdering af en håndfuld navne, eller tekst der kan læses: en forklaring, en oprindelse, en tiltaleform.
- Tag en navnedatabase, når svaret skal være identisk i morgen, skal komme med dokumentation, skal have en pris pr. post, eller skal holde til et spørgsmål fra databeskyttelsesrådgiveren.
- I stor skala afgøres det ikke af præcision, men af sporbarhed. 9,124,598 fornavne fordelt på 192 lande, hvert svar med sit eget antal stikprøver — mod en generering, der ikke kan vise, hvordan den nåede frem til svaret.
- De to kombineres godt. Giv modellen API'et som værktøj — vi udgiver en hostet MCP-server til det — så kommer mærkatet fra dataene, mens formuleringen kommer fra modellen.
Hvad de to ting faktisk er
Gender-API.com er en opslagstjeneste oven på en navnedatabase. 9,124,598 fornavne, opdelt efter det land de blev observeret i, 192 lande understøttet. Du sender et navn og får et køn, en sandsynlighed og antallet af stikprøver, svaret hviler på. Intet bliver genereret.
ChatGPT — og enhver anden generel sprogmodel — er en tekstgenerator. Den ved, at “Sandra” optræder i feminine sammenhænge, fordi ordet opførte sig sådan i træningsteksten. Det er et virkelig nyttigt signal, og ved almindelige navne giver det det rigtige mærkat. Men der er intet i arkitekturen, der gemmer hvor mange Sandraer i Portugal der var kvinder, så der er intet at citere, intet at sætte en grænse på og intet at revidere.
Netop dette strukturelle forhold forklarer alle de praktiske forskelle nedenfor.
SIDE OM SIDE
De forskelle, der holder uanset hvilken model du vælger.
| Hvad du har brug for | Gender-API.com | Generel LLM |
|---|---|---|
| Samme svar på samme input, hver gang | Ja — det er et databaseopslag | Nej — sampling, promptens ordlyd og modelversion flytter det |
| Dokumentationen bag et enkelt svar | Antal stikprøver og sandsynlighed pr. resultat og pr. land | Ingen; et sikkerhedstal er, hvis du beder om det, selv genereret |
| Dækning du kan angive skriftligt | 9,124,598 navne, 192 lande | Ukendt og ikke oplyst |
| Landespecifikke svar | En parameter for land, locale eller IP ændrer resultatet | Kun hvis du siger det i prompten — og det er stadig et gæt |
| Adfærden om tolv måneder | Samme endpoint-kontrakt, udgivet som OpenAPI; v1 og v2 kører begge stadig | Modeller udfases og erstattes; svarene flytter sig med dem |
| Batchbehandling | 100 navne pr. kald, eller en CSV med op til 10 millioner rækker | Kontekstgrænser, opdeling, rate limits og nye forsøg skriver du selv |
| Omkostningsenhed | En credit pr. opslag, fra en pakke du har købt på forhånd | Token ind og ud — varierer med promptens længde og nye forsøg |
| Hvor dataene behandles | Servere i Tyskland, behandling inden for EU, DPA på forespørgsel | Afhænger af leverandøren, planen og den region du får |
| Opdele et fuldt navn, læse et navn ud af en e-mailadresse | Egne endpoints | Prompt engineering — og i grænsetilfælde fejler det uden at sige det |
| Et navn som ingen har data om | Siger det — result_found er false, eller sandsynligheden er lav | Svarer alligevel, i samme selvsikre tone |
| Forklare et navn, dets oprindelse eller dets varianter | Ikke det, det er til | Virkelig bedre — det er netop det, en sprogmodel er til |
Hvad koster det at bestemme kønnet for en million navne?
Her er regnemetoden i stedet for et markedsføringstal, så du kan regne det om med dagens priser.
Med et API: Ét opslag er én credit. Vores bedste offentliggjorte mængdepris ender omkring €0.35 pr. 1.000 navne, så en million navne koster cirka €349 netto — et fast beløb, kendt inden du starter, på en faktura med moms. Credits fra engangspakker udløber ikke.
Med en LLM: Du betaler pr. token, i begge retninger, for hvert kald og hvert nyt forsøg. At samle flere navne i én prompt sænker prisen pr. navn, men du sender instruktionerne igen med hver portion, lange navne og usædvanlige skriftsystemer koster flere token end korte, og et fejlformet svar koster dig også det nye forsøg. Resultatet er et skøn, ikke et tal du kan skrive i et budget.
For at være fair: ved nogle få tusinde navne er en generel model så billig, at intet af dette betyder noget. Vendepunktet kommer med mængden — og tidligere end tokenprisen antyder, fordi alt udviklingsarbejdet omkring portionering, nye forsøg og validering af output er arbejde, du ikke skal lave mod et opslags-endpoint.
Reproducerbarhed: det punkt, der oftest afgør sagen
Kør en kundeliste to gange, få to forskellige resultater, og nu har du et problem, du ikke kan forklare: hvilken kørsel havde ret, hvad ændrede sig, og hvad siger du til den person, der sidste måned blev tiltalt “hr.” og denne måned “fr.”.
Et opslag er deterministisk. Samme navn med samme land giver samme køn, samme sandsynlighed og samme antal stikprøver. Når de underliggende data vokser, vokser antallet af stikprøver med dem — synligt, i svaret — så en ændring er noget, du kan pege på, frem for noget der blot skete.
Et genereret svar giver ingen sådan garanti. Temperature, en ny modelversion, en omskrevet systemprompt, en sikkerhedsjustering ingen har fortalt dig om: hver af dem kan vippe et grænsetilfælde, og ingen af dem efterlader et spor i dine data.
Hvert svar bærer sin egen dokumentation
Et enkelt kald til v2-endpointet:
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"
}To felter gør det arbejde, som intet genereret svar tilbyder. “samples” er hvor mange observationer svaret hviler på, og “probability” er den andel af dem, der var kvinder. Sammen lader de dig sætte din egen grænse — tag resultater over 0.9 med et anstændigt antal stikprøver, og send resten til manuel gennemgang — i stedet for at acceptere ét sikkerhedsniveau for hele din database.
Fuld reference: dokumentationen til API v2.
Samme navn er ikke samme køn overalt
Andrea er overvejende maskulint i Italien og overvejende feminint i Tyskland. Jean er maskulint i Frankrig og i høj grad feminint i engelsktalende lande. Nikita er maskulint i Rusland og andre steder typisk feminint. Det er ikke eksotiske grænsetilfælde — det er almindelige navne på almindelige kundelister.
Spørg en generel model uden at nævne land, og du får den læsning, der dominerede i træningsteksten, i praksis den engelsksprogede. API'et tager landet eksplicit:
En locale (en_US) eller den besøgendes IP-adresse fungerer lige så godt, og til det omvendte spørgsmål findes et selvstændigt endpoint — hvilket land et navn kommer fra.
GDPR, og hvor de navne du sender faktisk ender
Fornavne på virkelige kunder er personoplysninger, så det er et indkøbsspørgsmål og ikke en fodnote. Hvad vi kan sige lige ud:
- Vi er et tysk selskab; alle vores servere står i Tyskland, og dataene behandles inden for EU.
- En databehandleraftale kan bestilles i din konto.
- Serverlogs indeholder det indsendte navn og opbevares i 14 dage, af regnskabsmæssige grunde.
- Uploadede CSV- og Excel-filer lagres krypteret og slettes efter ti dage.
- Hvert køb giver en korrekt faktura med moms, og EU-momsnumre håndteres rigtigt.
Om en bestemt modelleverandør er acceptabel for de samme data er et spørgsmål til din databeskyttelsesrådgiver — men et længere spørgsmål, og et du skal stille igen, hver gang leverandøren skifter underdatabehandler. Vores svar står i privatlivsoversigten.
Hvornår ChatGPT er det bedste valg
Denne side ville ikke være værd at læse, hvis svaret altid var “køb API'et”. Det er det ikke:
- En engangsopgave. Fyrre navne i et regneark, ingen pipeline, ingen kommer nogensinde til at køre det igen.
- Du vil have begrundelsen, ikke mærkatet: et navns oprindelse, dets varianter, hvordan det normalt forkortes, hvordan man høfligt tiltaler nogen i en given kultur.
- Navne som ingen database har: nydannelser, fiktive figurer, transskriptioner der ikke findes i noget register. En model giver et rimeligt gæt, hvor et opslag simpelthen ikke har noget.
- Det du har brug for som output er fri tekst, ikke et felt: en hilsenslinje frem for en kønskolonne.
Det er ikke gavmildhed, vi bruger dem på samme måde: beskrivelserne af navnenes oprindelse på vores egne navnesider genereres af en sprogmodel, fordi tekst er netop det, en sprogmodel er god til.
Det bedste er begge: lad modellen kalde API'et
Bygger du allerede på en LLM, behøver du ikke vælge. Moderne modeller kalder værktøjer, og et kønsopslag er et ideelt værktøj: et snævert spørgsmål med et faktuelt svar, modellen ikke har data for.
Vi udgiver en hostet MCP-server, så enhver MCP-kompatibel assistent eller agent kan forespørge databasen direkte. Dens værktøjer er query_first_name, query_full_name, query_email, get_country_of_origin og get_statistics.
Til dine egne værktøjsdefinitioner findes officielle klienter til ni sprog (PHP, Python, Node, Java, Go, Ruby, Rust, Perl, .NET), en OpenAPI-beskrivelse, og på /skill.md en færdig implementeringsguide, du kan give direkte til en kodeassistent.
Netop den arbejdsdeling er pointen: modellen bestemmer hvad der skal gøres, databasen bestemmer hvad der er sandt.
Ofte stillede spørgsmål
Kan ChatGPT bestemme kønnet ud fra et navn?
Ja, og ved almindelige fornavne rammer den oftest rigtigt. Hvad den ikke kan: fortælle dig hvor mange poster svaret hviler på, garantere samme svar to gange, eller give et andet svar for samme navn i et andet land. Den svarer også lige så selvsikkert på navne, den aldrig har set, og netop den fejl er det, der betyder noget i stor skala.
Er et køns-API mere præcist end en LLM?
For et navn, der findes i en navnedatabase, er et opslag præcist allerede af konstruktion: det rapporterer den observerede fordeling frem for en slutning. Ved et ukendt navn kan ingen af metoderne stoles på, men kun opslaget indrømmer det. Den pålidelige forskel er ikke en enkelt præcisionsprocent — det er, at hvert opslag kommer med et antal stikprøver og en sandsynlighed, du kan sætte en grænse på.
Hvad koster det at bestemme kønnet for en million navne?
Hos Gender-API koster et opslag en credit, så en million navne er et fast, kendt beløb — omkring €349 netto til vores bedste offentliggjorte mængdepris, på en faktura med moms, aftalt inden du starter. Med en LLM betaler du pr. token for hvert kald og hvert nyt forsøg, så regningen afhænger af promptens længde og kan kun anslås.
Kan jeg bruge en LLM og et køns-API sammen?
Ja, og det er den bedste opsætning. Giv modellen API'et som værktøj — vi udgiver en hostet MCP-server præcis til det — så kommer mærkatet fra databasen, mens formuleringen kommer fra modellen. Modellen holder op med at gætte på fakta, den ikke har data for.
Har det samme navn samme køn i alle lande?
Nej, og det er netop her, en prompt uden land går galt. Andrea er overvejende maskulint i Italien og overvejende feminint i Tyskland; Jean er maskulint i Frankrig og i høj grad feminint i engelsktalende lande. API'et tager et land, en locale eller en IP-adresse og svarer for det land.
Hvad sker der med et navn, databasen ikke kender?
Du får result_found: false, eller en lav sandsynlighed med få stikprøver. Det er et signal, du kan handle på: send de poster til manuel gennemgang, eller fald tilbage på en model. Et generativt svar giver dig ikke noget sådant signal.
Overholder Gender-API GDPR?
Vi er et tysk selskab, alle servere står i Tyskland, og dataene behandles inden for EU. En databehandleraftale kan bestilles i din konto. Kaldlogs, som indeholder det indsendte navn, opbevares i 14 dage af regnskabsmæssige grunde; uploadede CSV- og Excel-filer lagres krypteret og slettes efter ti dage.
PRØV DET PÅ DINE EGNE NAVNE
Hver konto indeholder 100 gratis opslag om måneden — nok til at tjekke de navne, en LLM tog fejl om. Uden kreditkort.
API-dokumentation · Tilføj køn i en CSV- eller Excel-fil · MCP-server
