Lazy Matching – A Personal Example (#Kolicalling 2026)

I hesitate to write this because it might make a bery mildly irksome situation worse but it’s a useful example.

Christmas is coming, which means that Advent Calendars and associated items are showing up everywhere. It turns out that there is a family of murder mystery advent calendars written by someone with a very similar name to mine. I won’t put it in text, for reasons that will become apparent, but you can read it above.

I have commented elsewhere about one of the problems with using generative AI instead of a search engine is that you are generating a result which will resemble the answer to your query, rather than directly using a search function to explore a defined search space. One of the results of this is can be that the GenAI will generate something in response to your query rather than telling you that there is no answer to return. This is far more likely when there is a near match in information that it has already assimilated.

Let’s talk about an example I just saw at a conference, Koli Calling 2026, held in Koli, Finland. I saw a great demonstration at the conference of a Generative Story Telling machine that exposed how the story telling was influenced by the underling stochastic nature of the generator AND the existing data that was used to train it. You can find the abstract here: “Three Lenses for Exploring Training Data and Language Model Outputs in K–12 AI Literacy“. The Little Language Machine uses a browser based tool to train and deploy small language models, but can show you what the options were in the output, allow you to take alternative paths, and make it clear how much stochastic play there really is in the outputs. This makes it easier for learners to use evidence to reason about the relationship between what goes into and what comes out of a generative model.

The specific example started with “Once upon a time, there was a ” and then we got a story about a girl called “Jane” (I think). When you selected “Jane” in the text, you saw all the other names it could have been. “Jane” had a likelihood of 5% and “Lucy” was 15%, which clearly showed that, despite Lucy being more likely, a perfectly valid outcome was Jane. Then the demonstrator typed in something like “Once upon a time, there was a girl called Zendaya” and this generated a story that was fine for the first sentence and then the name suddenly became “Zip” and, as the story went on, Zip’s gender pronoun shifted between male and female. Why? Because the story training had never included the name Zendaya and the machine was matching to what it had been trained on, which included names that were partially matched, with associated gender, but somewhat randomly.

Now, of course, you can all start jumping up and down about how this wouldn’t work in a very large model, or agentic wrappers would fix it, but the point remains that generative solutions rely upon their training data and will often not return a “not found”, instead they stumble around with as close a match as they can manage but their stochastic nature means that even that close-ish match will change from time to time.

Hence, the author of the books above is close enough to me to cause a series of queries from publishers and conferences and promoters all seeking to speak to that author, who does not appear to be as visible on the Internet as I am and so I get the hits – all of which, I hasten to add, smell of AI generated text.

A human would probably look at our names and wonder why I would alter my name in that exact way, given that at no stage have I ever used that as an abbreviation but the LLMs don’t wonder, they just provide something approximating an answer. (I also started getting an abbreviation of my first name I don’t use about two years ago, probably being autocorrect or gen-influenced, and I always reply with my name in my sig block but it doesn’t seem to shift it.)

Approximate matching is not a new thing. Years ago, well before the dawn of computing, we had Soundex Codes for indexing names, where a code is generated from a phonetic English interpretation of a name. The code comes from the leading letter of the name, followed by three numbers that indicate other consonants in the words. The numbers used stand for consonants that sound “similar” in English, so we use the numeral “1” for B, F, P, and V, for example. This would lead to Robert and Rupert both having the code R163. Soundex was valuable back when name spelling was highly inconsistent, search costs were high, computing power was non-existent, and we wanted to be able to find things that should be grouped together.

Soundex was used to make indexing more efficient, not to falsely tell us that Robert and Rupert were the same name. Yes, under Soundex, my full name and the name on the text have the same code, N242, but that should just put us in a convenient index to say “we seem to be phonetically similar”, not that we are the same person. There’s a point where Robert and Rupert are not the same person, and that point is reached before you write to Robert to ask about Rupert’s books.

I really liked the example at Koli because I imagine many people are seeing this happen without realising what is going on and what it means in terms of how things are currently working. The more we understand that a number of results we see are synthetic close matches, rather than true answers, the more cautious we need to be about the information that is returned to us as fact.

Of course, now I have to start writing my own advent calendar murder mysteries to take advantage of this new career direction…