Even if you haven’t seen it, there’s a pretty good chance you’ve heard of Charlie Brooker’s series, Black Mirror. In its first two seasons, Black Mirror used its standalone episodes to explore the dark side of upcoming and speculative technologies. New seasons, however, have included more uplifting episodes that depicts technology actually helping peoples’ lives such as Emmy-award winning San Junipero’s time traveling lesbian tryst or Season 4’s Hang the DJ (HtDJ).
If you haven’t seen it, you should. Otherwise, the Verge has a decent recap of it here and you can watch the trailer below:
As HtDJ came to an end with its twist ending, it dawned on me: the app in HtDJ is very much like the algorithm behind Nanaya! Nanaya’s algorithm was published during January 2015 and publicized by the New Scientist. Maybe it’s wishful thinking, but just maybe it was one of many different things that inspired the script.
Nanaya and the system’s algorithm in HtDJ seemed like they had some similarities. But to actually understand what those similarities are I needed to reverse engineer the HtDJ’s algorithm.
This post offers an overview of how the algorithm behind HtDJ’s system and Nanaya work. Next week, I’ll post the issues with the HtDJ. In the following week I’ll post an even more detailed interpretation of how the HtDJ algorithm works.
How HtDJ’s algorithm works
To really evaluate the effectiveness of the HtDJ system, we need to understand a little bit about how the system’s algorithm works. In short, the algorithm creates matches real-life virtual profiles to see which two matches are most likely to lead to a successful relationship, while comparing it to other possible relationships. That’s not too different from how Nanaya works! The figure below shows the general steps of the HtDJ algorithm.
But to understand how Nanaya’s and HtDJ’s algorithms are different, we need to go into more detail.
For starters, HtDJ’s algorithm creates 1,000 simulations, each one a timeline starting with a 12-hour date between the real-life matches. These real-life users are represented by bots, like virtual Amy and Frank, in a scaled time simulation. After that first date with their real-life matches, both bots are assigned new relationships with different bots for a different duration. Here, the algorithm can be pretty complex – finding the right pairings that force bots to evolve and react the most.
In this way, the simulation can learn more from each relationship and improve accuracy. For any of this to be realistic, the bots need to accurately represent how the real-life user behaves and changes their behavior based on interactions.
After a series of relationships, a certain condition in the algorithm is reached and “pairing day” arrives. That morning, both real-life matches’ bots are given a final opportunity to meet again. Interestingly, at least in HtDJ, the coach said both Amy and Frank would be matched with a “perfect match” they didn’t know. Essentially they have a choice: rebel against the system (which could conceivably be not accepting Frank and giving up on relationships!) or accept a random relationship. This choice as presented in HtDJ is something that is evaluated in Nanaya as well.
Ironically, their decision to be paired or rebel is a simulated emotional decision. Every dating service that uses numerical matchmaking or the Nanaya algorithm, which uses economic, modeling, defines a consistent and absolute standard of what is a good match. Typically, a good match is one that’s close in the highly dimensional matchmaking space (read more about that here). But in HtDJ’s algorithm, a good match is one that your simulated bot “feels” really good about. This is a paradigm shift in dating apps – emphasizing the emotional sensation of good than what is abstractly considered to be good.
But again, it’s simulated emotion. The emotional decision needs to be mathematically calculated. Some theory of decision-making needs to have been coded or numerically achieved such that a finite set of parameters can be fed into its machinery to come to a single, binary decision.
So how would you even go about attempting to simulation emotions? That’s:
The complicated part
In each relationship, the bots’ personalities can remember, evolve, and learn based on the experiences they have within the simulation, leading to the variability between timelines as different types and durations of relationships occur in each one.
These bot identities and personalities must be explicitly defined in a way that accounts for what we understand as identity and personality in real-life. For instance, there’s inevitably some parameter like extroversion. Imagine the designers of the app in HtDJ have found a way to relate your phone conversations, cell phone photos, text messages, and even biometric data like heart rate relate to extroversion. By snooping in, the app can find out how extroverted you are in a bar after a long day of work or at a public park on a sunny day.
Going deeper, the algorithm can do more if their ex’s are also users. With more information about their past relationship, it’s possible to start classifying what combinations of identities and circumstances just don’t result in healthy, long-term partnerships.
After some time, the app can build a very rich profile of not just how you’re extroverted but many other traits, values, and how it defines emotions. To account for all aspects of personality needed for the simulation, more than tens of thousands of variables are needed (The Nanaya algorithm on the site uses about 1,000 variables, depending on the user).
But this fabric of identity and emotion has to evolve in the simulation. Otherwise Amy and Frank would have rebelled at the start. To evolve all these parameters, many equations or numerical routines, like based on machine learning algorithm, would have to define how any interaction changes identity and emotion.
Between tens and thousands of variables and non-linear equations that relate them and how they change, there’s a lot of room for error. There’s also a lot of computation required, which runs up server bills!
In the next post, I’ll talk about the impacts of these errors and server bills as I describe the issues in the algorithm and what solutions exist.