AI transcription got good. It still gets every name wrong.
The general prose is fine now, genuinely. The problem is that a genealogy interview is mostly surnames and place names, which is exactly the part these tools fumble.
Let’s start with the good news, because a lot of writing on this subject is weirdly negative. AI transcription has got genuinely good. Ordinary conversational speech, even with an accent, even with background noise, comes back readable. You can hand it ninety minutes of a kitchen table conversation and get back something you can search, skim and quote from. Five years ago that was not true.
So no, transcription is not the weak link any more.
Except in one specific place, and unfortunately it’s the place family history lives.
The names come back wrong. All of them!
Well, not all of them. But enough of them that it gets annoying.
Surnames, given names, townlands, parishes, farm names, ships, the small place three miles from the town nobody outside the county has heard of. Some come through fine, usually the ones that are also ordinary words. The rest land somewhere between “close enough to recognise” and “what on earth was that supposed to be”.
Everything else in the sentence is fine. The grammar is fine. The meaning is fine. And then your great-grandmother’s birthplace has been rendered as two ordinary English words that sound roughly similar.
If you think about how these models work, this is not surprising. They predict likely words from sound. Common words are easy because they are common. A surname that appears in one parish register and nowhere else on the internet has almost no chance, so the model reaches for the nearest thing that sounds like it and moves on, confidently, without any signal that it just guessed.
This is worth sitting with, because it’s the opposite of the failure people expect. You do not get garbled text you can spot. You get clean, fluent, plausible text with the load-bearing words quietly replaced.
And you get to do it again tomorrow
Here is the part that turns a small annoyance into a real one.
Transcription tools do not remember anything. Every job starts from zero. So you sit down with interview one, work out that the surname is Colclough and not “coal cluff”, fix it everywhere, and feel quite pleased with yourself.
Then you transcribe interview two. Same family. Same surname. Same townland, mentioned eleven times. And the tool has no idea it has ever encountered any of it, because it hasn’t. You correct the exact same words again.
Then interview three. Then the follow-up with the cousin who remembered something later. The names in a family history project repeat constantly, by definition. That is what makes it a family. And every session you are re-solving a problem you already solved, by hand, from scratch.
One interview, this is ten minutes of find-and-replace and no big deal. Across a project with a dozen recordings it is genuinely tedious, and tedious is how things stop getting done. Plenty of half-finished family history projects died at exactly this kind of task.
The maddening bit is that this is the easiest problem on the list to fix. The names are sitting right there in your notes from last time.
The fix exists. That’s the frustrating part.
None of this is unsolvable. There are several known ways to get names right, and they all work:
Give the tool the vocabulary up front. Most serious transcription services accept a list of expected terms, or a prompt where you can put the names you know will come up. Feed it your surnames and place names beforehand and accuracy on exactly those words jumps.
Connect it to what you already know. If a system can see your family tree, it knows that this speaker’s relatives are called Brack and Colclough, and that they came from a specific parish. That context turns an impossible guess into an easy one.
Let it look things up. Wire a model to a search tool or a gazetteer, via something like MCP, and it can check whether the place it just heard actually exists in the county being discussed. A townland either appears in the records or it doesn’t.
Do a verification pass afterwards. Run the transcript back through with the specific job of flagging every proper noun it is unsure about, rather than silently committing.
Any of those meaningfully improves the situation. Combined, they mostly solve it.
And now the actual problem
Look at that list again and notice what it asks of you.
Maintaining a custom vocabulary file. Exporting your tree into a format a model can consume. Setting up an MCP connection. Chaining a second pass over the output of the first. Knowing that any of this is possible in the first place.
That is developer work. Not hard developer work, but it assumes you are comfortable with APIs, config files and a terminal.
Now think about who is actually doing family history research. Overwhelmingly, it is people with time, patience and deep subject knowledge, who are not necessarily technical at all. Someone who knows nine generations of a family and can read nineteenth-century handwriting is not automatically someone who will wire up a tool chain to fix proper nouns.
So we have arrived somewhere slightly absurd. The technology to transcribe a family interview accurately, names included, exists today and works. The people who most need it largely cannot assemble it, and the people who can assemble it mostly are not doing genealogy.
That gap is the real story, and nobody has packaged the answer well yet.
What to do in the meantime
If you are not going to build a pipeline, and most people reasonably will not, these get you most of the way:
Write your name list once, then keep it. Every surname, town, townland and farm you expect to hear. Ten minutes with a pen the first time. If your tool takes a vocabulary hint or a prompt, paste it in. If it doesn’t, you have a find-and-replace list instead.
The important half is the keeping. Save it as a plain text file next to your recordings and add to it after every interview. The tool won’t remember your names, so you have to be the memory. That one file turns the same tedious job into a paste, every time after the first.
Treat every proper noun as unverified. Ordinary sentences you can trust. Names you check. That single habit prevents almost all the harm, because a wrong name that gets copied into a tree is the error that propagates.
Never delete the audio. The transcript is a working copy. The recording is the record. Storage is cheap and this is the one thing you cannot recreate.
Spot check a few passages against the audio. Pick five at random, listen while reading. You are checking for confidently invented content, which is a documented failure mode of these systems and does not announce itself.
The honest summary
Use it. The time saved is enormous and the general accuracy is genuinely there now.
Just be clear about what you have got: a searchable, skimmable version of the conversation, in which every fact worth recording still needs a human to confirm it. That is a very useful thing. It is just not the same thing as a record.