Dan Turkel (dot com)

Who’s the agent now?

2026-02-11T00:00:00-05:00

Portion of a propaganda poster produced by the US Information Agency some time in the 1950s or ’60s, via The National Archives.

Everyone’s talking about agents these days.

By and large they’re talking about AI agents, a somewhat nebulous term that’s come to mean something like: a large language model which can utilize tools to accomplish its goals.

I want to dwell on the word “agent” for a second because it contains two nearly-contradictory concepts that are getting blurred. The notion described above is that an agent is something with the capacity to act, exerting agency. Anthropic’s definition of agents captures this: “systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.” The emphasis is on exercising control and taking action: we say what we want and the agent figures out how to do it.¹

The different notion of the word emerges when we talk about human agents: a person who acts on behalf of someone else. This is the agent of the “principal-agent relationship,” as in “call my agent.” But popular usage of “agent” in the context of AI seems to favor the first sense, centered on agency.² We’re left with an odd paradox: an inanimate agent is defined by its independence while a human agent is defined by its service of another.³

The blurry distinction between independent operators and obedient proxies is driven home in a recent article by Joshua Yaffa from The New Yorker about human agents committing small acts of sabotage across Europe. In espionage, agents are typically well-placed sources that are carefully recruited and protected for their valuable access to information. Russia’s “single-use agents,” on the other hand, are described as “loners, outsiders, whether in the classroom or society at large, without experience and maybe not so savvy or wise.” They’re found in Telegram group chats looking for odd-jobs:

[I]n nearly all cases, single-use agents are apolitical, in need of money, and ignorant of the cause they’re ultimately supporting. The Polish security officer told me that, of the sixty-two suspects who have been arrested in Poland as part of sabotage investigations in recent years, only two of them were believed to be primarily driven by pro-Russian sentiment.

They operate through several layers of cut-outs and intermediaries (one estimate suggests that, on average, “at least three levels of separation exist between single-use agents” and card-carrying Russian intelligence officers), which creates enough deniability to make prosecution of the masterminds infeasible, even if it’s quickly obvious to law enforcement and intelligence who’s pulling the strings. The ease of recruitment and lack of blowback if they get caught are what make these agents appealingly “single-use.” They’re assigned missions ranging from putting up anti-NATO stickers to setting off incendiary bombs. The long game for Russia is to drive anti-Ukrainian sentiment and tie up investigative resources.

But if you’ve ever had an AI assistant which paled in comparison to a skilled human on complex tasks, you won’t be surprised to learn that the single-use agents also have a tendency to cut corners or go rogue.

“Robots need your body”

RentAHuman is a new AI startup which offers another take on the concept of single-use agents.

Founded by Alexander Liteplo, a twenty-something former crypto engineer, and Patricia Tani, a designer-turned-coder who may in fact still be in undergrad, RentAHuman is a marketplace where AI agents can pay humans in crypto to accomplish tasks that require a physical body. The site, whose homepage declares that “robots need your body,” has gotten some buzz and boasts that hundreds of thousands of humans have signed up to fulfill tasks, but it’s not clear that much human-chatbot commerce is actually happening here.

The site’s list of “bounties” includes a number of tasks that, if they were indeed posted by bots, would have probably been easier to communicate human-to-human, like “Hang signs for our AI fellowship at college campuses.” Others are simply confused (“I do anything,” posted by a self-proclaimed human who seems to be on the wrong side of the site) or just plain scams (“need any human to send eth to this address”).⁴

But I don’t think you have to be totally paranoid to see the potential utility for a tech-savvy intelligence officer. One post seems to be from Romania, offering $150 per hour for someone to take a series of photos of a monument in Mississauga, Ontario. Another, either posted from or looking for humans in Morocco, is lighter on details: “I need a reliable person to go to a specific location and take clear photos as instructed. The task requires following simple instructions, being punctual, and sending photos and notes after completion. This is a short and straightforward task.” Fifteen dollars an hour, 46 applicants. Hanging fliers and taking photos, I should note, were both tasks assigned to Russia’s single-use agents.

A screenshot of a “bounty” posted on RentAHuman.

It isn’t hard to imagine some of the profiles appealing to spy recruiters. One advertises “DEPLOYMENT_ZONE: PAN-NORDIC,” verified Swedish ID, ability to receive and ship packages (another task mentioned in the article) and even purchase of local SIM cards. A reverse image search on one of the profile’s photos points to a Swede who offers courses on Bitcoin and how to ride a Onewheel.

A profile advertising “local field ops” with specialties including “evidence capture” caught my eye. I was able to find the owner of the profile on LinkedIn and reach out. He called his foray into the site a “low commitment experiment” that was driven by curiosity to see if he could make a little extra money and “learn how agents interact with human operators.” As for his profile description, he said that he framed it around physical tasks since those are precisely what an AI agent can’t do.

But so far he’s only heard from two other humans and no AIs, which isn’t quite what he signed up for. Worse, he was put off by one of the messages he received: “It didn’t include any real description of the task and instead directed me to an external link, which raised a red flag.”

He acknowledged that the platform could be utilized to involve unsuspecting humans in crime or intelligence gathering. “Without clear safeguards, there’s potential for misuse.”

Unwitting humans, unaccountable machines

Maybe RentAHuman’s red flags are just red herrings, but the idea of using the gig economy to recruit civilians for low-level surveillance tasks is already a dystopian reality. In 2021, the Wall Street Journal described (archive link) a San Francisco company called Premise whose gig work app has become a resource for military intelligence.

While Premise primarily advertises itself for more savory international development purposes (getting a pulse on vaccine hesitancy or election misinformation), it has received millions in military contracts. A pitch to American forces in Afghanistan proposed measuring information operations, mapping mosques and banks, and monitoring wireless signals. Tasks would be designed to “safeguard true intent,” so taskers wouldn’t know the true purpose of their work. Tasks could even present with a decoy job whose sole purpose was to get users to travel, sucking up signals data through the phone’s sensors.

An Afghan Premise user described seeing tasks on the app seeking photographs of Shiite mosques in an area of Kabul that had been subject to terror attacks. He declined them.

Back in Europe, Russia’s treatment of its soldiers as disposable has attracted attention, but it’s another disposable resource that has changed the face, if not the tide, of the war: drones. Cheap, kamikaze drones have turned out to be a devastating weapon, deployed by both Russia and Ukraine and contributing to most of the million-plus casualties in the conflict. Like AI assistants before them, drones may be crossing the Rubicon of what it means to be an agent—with grim consequences. What began as disposable weapons that acted under full control of their human operators—agents in the principal-agent sense—is turning into weapons that are increasingly autonomous, acting with their own agency:

With A.I.-enhanced weapons, the ethical distinction between two broadly different types of strike — a drone selecting a large inanimate object for attack and a drone autonomously hunting human beings — is large. But the technical difference is smaller, and [Ukrainian manufacturer] X-Drone has already crept from the inanimate to the human. X-Drone has developed A.I.-enhanced quadcopters that, its founder says, can attack Russian soldiers with or without a human in the loop. He said the software allows remote human pilots to abort auto-selected attacks. But when communications fail, human control can become impossible. In those cases, he said, the drones could hunt alone. Whether this is occurring yet is not clear.

There exists a dystopian trajectory toward a world where humans are increasingly out of the loop, relegated only to the tasks that still require them. But I’m not an AI doomer in large part because these are systems built and deployed by humans. If we don’t like the way they’re headed, we have the agency to change course.

It is inevitable to slide into language that anthropomorphizes artificial intelligence systems. For more on that topic, see my post from last year on “Teaching machines to understand.” ↑
Admittedly, Google’s definition of an agent combines the notions of agent-as-actor and agent-as-proxy: “AI agents are software systems that use AI to pursue goals and complete tasks on behalf of users” (emphasis mine). ↑
I’m not the first to notice this odd twist of usage. In a blog post for a SaaS that has something to do with affiliate marketing, Brook Schaaf writes: “The unrefined reference to ‘agent’ will mean both human and nonhuman, accountable and not accountable, and a loyal and disloyal representative.” ↑
It didn’t inspire confidence that, at the time I started writing this post, every supposedly AI-posted bounty said “Posted by User” followed by the label “human.” This bug appears to be fixed now. To the site’s credit, this guy had a success story; but if the tasks were something he needed directly, it’s not clear why he had to have an AI agent intermediary recruit a human for him. ↑

The obligatory “How I'm using LLMs” post

2025-05-26T00:00:00-04:00

Don Juan et la mort (1926) by Alexandra Exter, from Décors de théâtre (1930), via MoMA.

In online spaces dedicated to coding, I often encounter two archtypical tribes, each with a set of go-to talking points.

The bears are convinced that LLMs are destroying software engineering, filling codebases with mistake-filled code that no one understands, and that no competent engineer is using LLMs because their problems are too complex for the models to understand.¹

The bulls, on the other hand, embrace LLMs for nearly all tasks, seeing them as a way not only to automate tedium and tinker on experiments, but as a perfectly good and likely superior way to write production code for their job.

These two groups collide in the comments section of your favorite website, exchanging insults and downvotes, absolutely baffled that anyone could be a member of the other group.

I leaned bearish when I felt the tools were still immature, but those days are nearing their end. The models are powerful enough that to ignore them is to rob yourself of a valuable skill in a contracting job market. And it is a skill. We may not need to prompt-engineer our inputs to death just to get the models to behave, but you still need to learn how to use LLMs effectively, just like you have to learn to use your IDE, your browser, or your command line.

When I peeked my hibernating bear head out of my cave, I’d found that my peers and colleagues had been getting a lot done without me, and I’ve reinvested. I like to think I’m an LLM moderate now: I try to leverage their strengths while keeping an eye out for their weaknesses, and I stay abreast of advancements with cautious optimism.

Rather than fuel the flame wars or ramble on (too much) about the philosophical implications, below I’ve tried to lay out in concrete terms the ways I get things done with LLMs.

Learning

I’m a huge fan of Simon Willison’s “llm” command line tool. I pop open a terminal with alt-tab, and llm chat instantly starts a conversation with Claude, ChatGPT, local models, and so on. I use this throughout the day for my primary LLM use case: treating the model as a personalized one-on-one tutor. (When I’m on the go, I use the Claude app for Android.) Whether it’s a topic that merely strikes my curiosity (“what are the different cables on a telephone pole?”) or something I need to understand better for a project (“what is the difference a message queue, pub/sub, and event stream?”), I lean heavily on language models as an educational resource.

“But Dan,” I can hear you say, “these models make things up all the time!” It’s true, but I’ve found it’s getting better, and you learn to develop a bit of a bullshit detector that needles you to double-check something that seems off. We use that same skill all the time on the internet, right?

LLMs haven’t replaced my Wikipedia addiction, they complement it. Wikipedia and web searches in general are great for learning facts, but I find that talking through concepts with the model has been great for understanding.

Coding

Early on, ChatGPT could blow people away by spitting out a surprisingly competent React app, but it’s been more tightly integrated tools that have allowed programmers to iterate on existing codebases, solving bugs, refactoring, and building new features.

I’ve tried a few of them: GitHub Copilot and Cursor have both gotten extremely good, and I use both in my work. For side projects (where I’m the one paying), I like the “build-your-own assistant” flexibility of Continue, but I’ve also been playing around with Claude Code and I love the experience (just keep an eye on its API usage).

I have to admit that I simply can’t abide the always-on inline suggestions—I find them extremely disruptive and annoying and I disabled them almost immediately. Instead, I use a combination of inline chat (“add a docstring to this function”) and the chat/agent sidebar.

Chat mode is for talking through ideas: “how might I go about refactoring this to support ABC scenario? would XYZ work?” Agent mode excels for actually executing changes. I typically prompt it to execute step by step because I like to read, review, and understand each diff before approving (I often edit them or reject them, explaining my feedback). Getting a huge diff attempting the entire change at once has a lower success rate and is harder to digest.

The aforementioned Simon Willison has a good quote in a recent New York Times piece about the way AI is transforming coding jobs: “It’s more fun to write code than to read code,” and coding with LLMs is more of the latter. The idea of feeling like a “bystander” strikes a chord with me.

In my free time I’m often coding for the joy of it, so when I prompted Claude to help me sketch a design for something I wanted to try and it damn near implemented the whole thing, I couldn’t help but feel a little deflated: where’s the joy in that? On the other hand, I’m typically happy to tackle tedium or get unstuck using LLMs at work. I imagine some photographers were eager to abandon the smelly, temperamental darkroom for Photoshop, while others couldn’t help but feel something important was loft in translation. One man’s joy is another’s drudgery, and maybe we’ll be called luddites to get sentimental about writing code “by hand.”

We’re reckoning with these questions as an industry. In the meantime, I’ve developed a rule of thumb to preserve the joy of coding: let the LLM help you with the boring parts, save the fun parts for yourself, and have even more fun using model to do things you wouldn’t have been able to do on your own.

Something that didn’t resonate with me in the Times piece was Harper Reed’s comment that we may no longer need to be “precious” about understanding the code. In fact, I’d argue that since the AI explosion is likely to bring software into more facets of our lives than ever (AI therapists, brokers, interviewers), the importance of understanding what we’re putting out into the world is only growing.

Writing?

Surprisingly enough, since they are language models, writing is where I’ve gotten the least value from LLMs. I’m not interested in having a model produce text on my behalf because my writing is an expression of my thoughts which I want to come directly from me—plus the prose always comes out with that obsequious LLM voice. I tried using Claude code to edit this post for brevity (always a struggle for me) and found it eager to excise multiple paragraphs at a time and rewrite my points in a way that felt foreign to me. Maybe I’m just being “precious,” maybe those edits are what I needed, but for now I’ll draw the somewhat arbitrary line here.

The bear case is not to be confused with the doomers, who believed AI will bring about the end of the world. I’ve written about that group before here. ↑

Teaching machines to understand

2025-03-10T00:00:00-04:00

Illustration from the Life publication of Vannevar Bush's "As We May Think" (1945), via Google Books.

Last year, I saw that Ignite was holding a night of AI talks at Betaworks, a startup incubator and co-working/event space that happens to be about a block from my office, and they were soliciting pitches for talks. I’d recently gotten back from SIGIR in D.C. and my mind was still spinning with new ideas, so I haphazardly filled out the Google Form with a one sentence pitch for a talk about how “AI is embeddings” [sic].

A few days later I found out that I’d been selected to speak and that the event was in a week. At this point, I took a closer look at Ignite’s signature talk format: 5 minutes, 20 slides, 15 seconds per slide—what had I gotten myself into? Nonetheless, I decided it was a good opportunity to shape some vague thoughts I’d been having into something coherent and to practice public speaking, so I got to work on my slides and drilled my talk over and over.

The event ended up being a huge success. Lots of people showed up to hear ten speakers give a really wide-ranging selection of AI-themed talks on psychedelic art, cyborg teams, canine personhood, and more. While I learned that I apparently speak a bit quietly (whoops), I didn’t panic and forget my notes like I’d feared I would—in fact, my talk went really well!

You can watch the video recording of the talk or read an adapted and slightly expanded version below.

“Teaching machines to understand.” Right off the bat I’m breaking a rule that bothers some people in the AI space: anthropomorphizing algorithms, suggesting that computers do things that humans do like learn and understand.

In fact, we’ve been treating computers like people for as long as we’ve had computers. In the 1960s, MIT professor Joseph Weizenbaum developed an early chatbot called ELIZA which could behave like a therapist. Here’s a conversation I had with a modern re-implementation of ELIZA:

> Hello, I am Eliza. I'll be your therapist today. 
* I'm nervous about giving a talk
> How long have you been nervous about giving a talk? 
* Since a few days ago. The talk is next week.
> Can you elaborate on that? 
* I only have a few days to prepare, and the format is tricky. 
  I'm worried I'll forget what I want to say.
> Do you believe it is normal to be worried you'll forget what you want to say?

You get the idea. While ELIZA used fairly primitive logic, Weizenbaum was surprised at the way users quickly felt that the program understood them not just linguistically but emotionally. Weizenbaum called this experience “powerful delusional thinking”—now we call it the ELIZA effect—but sixty years later everyone and their mother is having similar uncanny experiences with ChatGPT: conversations that feel meaningful, fluid, and human.¹

I can send ChatGPT a screenshot of a conversation of ELIZA and ask “What’s happening in this image?” and it’s able to respond with an explanation of exactly what ELIZA was.

Surely this is closer to some notion of “understanding,” but what happened in the decades between ELIZA and ChatGPT to make it possible?

Let’s back up to 1945. Scientist and engineer Vannevar Bush published an essay called “As We May Think” where he described something called the “memex,” a memory-expanding device that would store all of your information and ease the process of retrieving it in a more logical manner. There’s a lot of associated gadgetry described to make this possible, but I’m more interested in the underlying paradigm Bush describes to enable navigating through this new massive data store (emphasis mine).

Our ineptitude in getting at the record is largely caused by the artificiality of systems of indexing. When data of any sort are placed in storage, they are filed alphabetically or numerically, and information is found (when it is) by tracing it down from subclass to subclass. It can be in only one place, unless duplicates are used…

The human mind does not work that way. It operates by association. With one item in its grasp, it snaps instantly to the next that is suggested by the association of thoughts, in accordance with some intricate web of trails carried by the cells of the brain…

Man cannot hope fully to duplicate this mental process artificially, but he certainly ought to be able to learn from it. … Selection by association, rather than indexing, may yet be mechanized.

“The process of tying two items together,” Bush wrote, “is an important thing.”

Modern note-taking software and “personal knowledge bases” let us do just that. Obsidian maintains a graph of your notes, connecting the notes which link to each other. The video below demonstrates how you can browse that graph to see which articles are connected in the Obsidian Help site.

Looping video demonstrating how Obsidian generates graphs connecting together articles which link to each other.

The problem with this is that manually linking together notes is difficult and tedious—I should know, I’ve tried. It’s really valuable when I remember to tie together things like conference talks on similar concepts or with overlapping authors, but most of the notes in my Obsidian database are unlinked orphans, or else linked only to a single hub that lists out a bunch of related pages.

Worse yet, manual links don’t solve the issue of discovery. I can find information I’ve previously filed away as related, but how can I find new topics similar to the ones I care about?

Enter search. Our massive accumulation of digital documents has necessitated the development of tools for retrieving needles from the information haystack. Early digital documents were primarily textual so early search tools relied on term matching, which is useful when you know exactly what you’re looking for but not so great when you’re trying to explore or if you can’t quite remember the right term. When I was trying to recall Bush’s phrase “associative indexing” in “As We May Think,” my searches for “link,” “relation,” and “search” didn’t cut it.

Once again we reach back into history for a foundational insight, this time to 1975 for Gerard Salton, who pioneered the vector space model of indexing.² Remember how Bush specifically bemoaned the artificial nature of alphabetized or numerical organization of documents? Salton’s insight was to represent documents as vectors—basically lists of numbers, similar to coordinates in space—such that documents which are related to each other have vectors which are near each other in the vector space.

Two figures from Gerard Salton's "A vector space model for automatic indexing" (1975).

Early methods of generating these vectors relied on enumerating specific terms in the document (so it’s no wonder that early search methods relied on term matching). The simplest variant is the bag-of-words vector, where each position in the vector corresponds to a specific word in a predetermined vocabulary. The number in that position is 0 if the term does not appear in the document and 1 if it does—or it could be set to the number of times the term occurs, or some other weighting scheme.

This paradigm of term-based vectors (also called lexical vectors, or sparse vectors since they contain many zeros) survives in updated and augmented forms today, in part because it’s highly effective but also because we’ve figured out how to make it insanely fast, which is important for web-scale search applications. But more recently an alternative approach, with its own advantages and disadvantages, has flourished: rather than deterministically generating vectors based on terms in a document, we can learn them by training a statistical model to capture patterns in massive text corpuses.

One of the best-known versions of learned vectors came in 2013 with word2vec, which fittingly learns vectors for individual words. Given a sentence from a large text dataset, for instance “the fluffy dog barks loudly,” we should be able to remove a word from that sentence, then predict which word was missing. In other words, a very simple model should be able to take the vectors for “the,” “fluffy”, “barks,” and “loudly,” and assign a high probability to the missing word being “dog” (and correspondingly a low probability to words thta don’t fit, like “ingenuity”). Since we start with random vectors, this model will perform terribly at first. But the trick is that each time we try it on a new sentence we nudge the vectors very slightly so that they’ll give a slightly more correct answer next time. This is why we say that the vectors are “learned.”

Learned embeddings capture relationships between words.

What exactly do they learn? One famous property of these learned vector spaces is that they capture analogies. As shown above, taking the vector for “king” then subtracting “man” and adding “woman” gets us a vector close to the one for “queen.” This is a cool trick, but the more important property is that synonymous and related terms end up near each other in the space: the nearest neighbors to “happy” are “glad,” “pleased,” and “ecstatic,” while the nearest neighbors to “dog” are “dogs,” “puppy,” and “pit_bull.” We say that the vector space captures “semantic similarity,” which was Salton’s goal from the start.³

In his linear algebra textbook, Sheldon Axler remarks: “So far our attention has focused on vector spaces. No one gets excited about vector spaces.” If the guy who wrote a book on the topic finds this all a bit dry, I’ll forgive you for thinking that perhaps I’ve lost the point. But the fact is that these vectors (often called “embeddings” in modern AI contexts) serve as the fundamental building block for all the ways we use AI to understand. We use it everywhere.

For example, you can see how we’ve begun to free ourselves from exact term matching as well: if representations for similar words (and by extension, similar documents) are located near each other, then search queries no longer have to contain exactly the right word. A query that captures the same meaning will still land near the relevant results.

But we’re not limited to learning vector embeddings for just words or text documents—we can learn them for just about anything, so long as we have a dataset that allows us to say which things are similar and thus should have nearby vectors.

Embeddings of trending TikTok videos from Nomic Atlas.

We’re able to navigate massive datasets in ways that are useful and pleasing to humans. Nudge vectors together for movies that were watched by the same people and you’ll learn a recommendation model like the one that powers your Netflix homepage. In fact, learning movie embeddings for recommendation predates the Word2Vec paper and was a key development for researchers working on the Netflix Prize, a competition to design a recommendation system for Netflix.

The Netflix prize didn’t contain any metadata about the movies (director, year of release, genre), relying only on knowledge of which users liked the same movies—think “people who liked this also liked that.” But in reality we often do have additional information available and we can use it to learn even more robust representations, especially when we leverage multi-modal data like images or audio. Etsy rolled out a “search by image” feature which finds items on Etsy which are “visually similar” to the photo the user provided. Their model aimed to capture both categorical accuracy (an image of a doll should return doll products) as well as visual similarity (an image of a green doll should return products that are also green). Accomplishing this required a model which leverages both the image data and product categories provided by Etsy sellers.

A query image and the top results when searching in two different vector spaces using Etsy's search by image models.

I argue that this is a form of understanding because we’ve narrowed the gap between the qualities of data that we care about (I want a movie that’s similar to Die Hard or a doll that looks like the one I had as a kid) and the representation of that data that our computers understand—we’ve built digital reprsentations that encode semantic qualities that are meaningful to humans.⁴ The photos I take on my phone aren’t just a collection of pixels anymore because I can search “antiques” in Google Photos and it’s able to return to me photos of weird stuff I’ve found in antique shops through the years.

The experiences we’ve built with this technology can feel straight out of science fiction, like snapping a quick photo of a bookshelf, selecting one of dozens of spines, and then instantly pulling up a website to buy the identified book. It might not be as showy as the computers from Minority Report or Blade Runner, but it’s something that simply wasn’t possible not so long ago and now it barely registers as novel.

The 2014 xkcd comic “Tasks” demonstrates how the line between easy and difficult technical tasks can be subtle. Identifying whether a photo was taken in a national park is easy: “Sure, easy GIS lookup. Gimme a few hours.” Identifying whether the photo is an image of a bird is hard: “I’ll need a research team and five years.” One month later, engineers at Flickr had built a prototype to do just that. Ten years later, you can buy binoculars which identify the bird species you’re looking at.

We’ve undoubtedly fulfilled some of the goals Bush envisioned with the memex—organizing data based on its meaning and relationships to other information—but I think we should keep pushing the envelope and dreaming up ways to build machines which better map to the way that we think about the world and which understand what we mean and desire. We’ve come a long way from needing to try out different keyword combinations to find what we’re looking for online, but as long as I still have to learn “best practices for prompt engineering”—as long as we still have adapt our behavior and our inputs in order for computers to understand us—then there’s still room to improve.

So I’m exited for us to keep pushing towards the next bird-identifying binoculars: tasks that seem hard today, that require even richer notions of machine understanding. What points would make a persuasive argument for my thesis? What chemicals would be able to treat this disease? What decisions could help me flourish?

In the course of my writing this blog post, I’ve come across a few more alarming ELIZA effect anecdotes. OpenAI released their new GPT-4o model and dedicated a section in the model’s system card to “anthropomorphization and emotional reliance,” noting that “During early testing […] we observed users using language that might indicate forming connections with the model. For example, this includes language expressing shared bonds, such as ‘This is our last day together.’”
A more chilling moment comes from an article Laura Preston wrote for n+1. At an AI convention, the author witnessed the CEO of a veterinary chatbot explain how their bot had convinced a woman to euthanize her pet dog: “The CEO regarded us with satisfaction for his chatbot’s work: that, through a series of escalating tactics, it had convinced a woman to end her dog’s life, though she hadn’t wanted to at all. ‘The point of this story is that the woman forgot she was talking to a bot,’ he said. ‘The experience was so human.’”
The models keep getting better, and the impact of anthromoporphization grows stronger. ↑
Gerard Salton was referenced constantly at SIGIR—the conference’s biggest award is even named after him. The vector space model remains fundamental to information retrieval, with many of the field’s contributions amounting to new ways of crafting the vectors. It was the conference’s ubiquitous throughline of vectors—dense, sparse, learned, hand-crafted—that inspired me to take this on as a topic for a talk. ↑
You can look at more nearest neighbors with this web app, and play a Worldle-clone based on semantic similarity at Semantle. ↑
The Wikipedia article on the semantic gap contains a great illustrative example: it’s very easy to find a document on my computer containing the word funny, but very difficult to find an image on my computer that I will find funny. Our digital representations have historically offered poor allowances for us to navigate them in ways that we might like to. ↑

Brooklyn, summer 2017

2024-07-26T00:00:00-04:00

Taken in and around Crown Heights, New York, in the summer of 2017. Kodak Ultramax 400 film in a Canon AE-1 Program. Minimally post-processed.

Paris, spring 2024

2024-07-22T00:00:00-04:00

Taken in Paris in April 2024 on a Nikon D7200.

Amsterdam, spring 2024

2024-07-13T00:00:00-04:00

Taken in Amsterdam in April 2024 on a Nikon D7200.

Ethical AI in The New Yorker (and elsewhere)

2024-04-02T00:00:00-04:00

New York City: Bird's Eyes View (1920) by Joaquín Torres-García, via the Yale University Art Gallery.

In a recent issue of The New Yorker, Andrew Marantz takes a detailed look into two prominent communities in an ideological battle over AI. “Doomers” are convinced that advances in AI may spell the (possibly literal) end of the world, while the “accelerationists” believe that it’s the doomers who are threatening humanity by stifling innovation and world-improving technological progress.¹ “Among the A.I. Doomsayers” (or, as it’s titled in the print issue, “O.K., Doomer”) is an engrossing and well-reported piece that I recommend to anyone interested in the present and future of artificial intelligence, but it left me feeling that important voices were missing.

After reading the piece, I dashed off an email to The New Yorker with a few of my own thoughts on the topic. I was pleased to learn that my letter was chosen for publication in the April 8th, 2024, issue. My somewhat slapdash note was edited from a rambling 300 words to a tight 199, which you can find on the New Yorker website or below, quoted in full:

Ethical A.I.

Andrew Marantz’s appraisal of two Silicon Valley camps that hold conflicting ideas about A.I.’s development—“doomers,” who think it may spell disaster, and “effective accelerationists,” who believe it will bring unprecedented abundance—offers a fascinating look at the factions that have dominated the recent discourse (“O.K., Doomer,” March 18th). But readers should know that these two vocal cliques do not speak for the entire industry. Many in the A.I. and machine-learning worlds are working to advance technological progress safely, and do not suggest (or, for that matter, believe) that A.I. is going to lead society to either utopia or apocalypse.

These people include A.I. ethicists, who seek to mitigate harm that A.I. has caused or is poised to inflict. Ethicists focus on concrete technical problems, such as trying to create metrics to better define and evaluate fairness in a broad range of machine-learning tasks. They also critique damaging uses of A.I., including predictive policing (which uses data to forecast criminal activity) and school-dropout-warning algorithms, both of which have been shown to reflect racist biases. With this in mind, it can be frustrating to watch the doomers fixate on end-of-the-world scenarios while seeming to ignore less sensational harms that are already here.

(To Marantz’s credit, he makes a passing parenthetical reference to the less sensational middle-ground of the AI culture war: “And then there are the normies, based anywhere other than the Bay Area or the Internet, who have mostly tuned out the debate, attributing it to sci-fi fume-huffing or corporate hot air.”)

The talented editors at The New Yorker deftly excised the wordy fluff from my letter, so I’ll try not to add it all back here and instead direct you to others who have written incisively on the work done to uncover and remediate harms created by AI systems today.

A guest essay for The New York Times by Bruce Schneier and Nathan Sanders contrasts the doomers and the accelerationists (they call the latter “the warriors” and highlight a tendency to cite national security concerns which may or may not mask simpler economic motives), with the third group of “reformers” who hope to reshape AI via research, education, and regulation to reduce disparate impacts and automated exploitation. “The doomsayers think A.I. enslavement looks like the Matrix,” they write, while “the reformers point to modern-day contractors doing traumatic work at low pay for OpenAI in Kenya.”
On predictive policing, see The New York Times’ “The Disproportionate Risks of Driving While Black,” ProPublica’s “Machine Bias” and two major stories from The Markup (2021 and 2023).
The school-dropout-warning system referenced in the letter is the one detailed in another fantastic investigation by The Markup, which was found to have substantially higher false positive rates for minority students (though it wasn’t particularly accurate for any group, nor effective at impacting outcomes).
Another thoughtful look at the perils of automated decision-making comes from The Markup’s look at a potentially unfair policy for the allocation of donated organs.
Henry Farrell wrote an apt critique of the doomers-versus-accelerationists for The Economist: “This schism is an attention-sucking black hole that makes its protagonists more likely to say and perhaps believe stupid things. Of course, many AI-risk people recognize that there are problems other than the Singularity, but it’s hard to resist its relentless gravitational pull.”
If, for some reason, you need to read even more about the sometimes horseshoe-shaped world of the doomers and accelerationists, Kevin Roose has written about both groups for The New York Times, here and here.
To close things out, I recommend science fiction author Ted Chiang’s “Will A.I. Become the New McKinsey? in The New Yorker: “Some might say that it’s not the job of A.I. to oppose capitalism. That may be true, but it’s not the job of A.I. to strengthen capitalism, either. Yet that is what it currently does. If we cannot come up with ways for A.I. to reduce the concentration of wealth, then I’d say it’s hard to argue that A.I. is a neutral technology, let alone a beneficial one.”

Confusingly and sometimes frustratingly, these groups often overlap. A one-sentence “Statement on AI Risk” that compares the risks of AI to nuclear war is signed by Sam Altman (among many others), whose company OpenAI exists in a quantum superposition of preaching about the risks of AI while also making a lot of money off of the technology, and lobbies both for and against regulation. Several OpenAI employees quit the company in part due to safety concerns in order to form their own AI behemoth, Anthropic, where employees agonize daily over the implications of their work. Marantz quotes “rationalist” blogger Scott Alexander on how the factions have become strange bedfellows: “Imagine if oil companies and environmental activists were both considered part of the broader ‘fossil fuel community.’“ ↑

Data science: From classroom to industry

2024-04-01T00:00:00-04:00

L IV (1936) by László Moholy-Nagy, via Kunstmuseum Basel.

I recently gave a brief informal talk to a group of students and alumni at the NYU Center for Data Science, where I did my masters in 2019–2021. Alumni were invited to speak on data science in industry, and I focused my talk on the ways that data science in industry differs from data science in the classroom. So far as I could tell, the presentation was well received, so I’ve (loosely) adapted it into a blog post in the hopes that it might be useful to others interesting in transitioning into a job “doing data science.”

Disclaimer: While the content of this post is drawn from my work experience, the opinions throughout are mine alone and not those of my present or past employers.

When I studied math in undergrad, “data science” as a field of study—or a profession—didn’t quite exist yet. Much of what I know about data science in the abstract, I learned while doing my masters in courses on machine learning, statistics, optimization, and ethics. But most of what I’ve learned about being a data scientist has come from hard-won lessons on the job. This post aims to help fill in some of the gap between what you learn about data science in a textbook and what it takes to be an effective data professional in industry.

Some of these insights, though not all, are particular to the subset of the industry which I’ll call “medium-sized consumer-facing tech” companies where I’ve spent my short career thus far. These are companies with a few hundred employees that build apps and services for mass consumption (rather than business-to-business or research lab settings). Even if that’s not the type of place you work (or want to work) at, I suspect you’ll still find the majority of this post valuable.

It’s worth noting at the outset that working in data science and adjacent functions at companies like these can mean a lot of different things. There are data analyst, business intelligence analyst, data engineer, data scientist, machine learning engineer, machine learning platform engineer, and machine learning researcher roles, plus probably a few I haven’t heard of and a few more that haven’t been invented yet. People in these roles may work with different technologies on different problems and interface with different teams.

I won’t belabor the sometimes subtle differences between the roles because there are plenty of good resources on that topic, and because they can vary wildly from company to company or even quarter to quarter as teams get renamed. Best practice would be to focus less on the title and more on the day to day of a particular role. Assume that the coolest 10-25% of the job description is purely aspirational stuff that the company isn’t doing yet—does the role still appeal to you? (If it does, then you should apply!) Supplement that by asking the hiring manager about the specific problems people currently in that role are solving.

The whole job in one diagram

The other reason I won’t split hairs over the differences in different data role details is because they all tend to abide by the diagram below. Whether your business card says “BI ninja” or “ML wizard,” your jobs roughly consists of the following:

The entire career of a data professional is contained in this diagram.

A business stakeholder comes to you with a problem.¹ Maybe they want to figure out how many users were affected by a bug, which of the three features launched in the last quarter is having the greatest impact on a metric of interest, or which users to offer discounts to.
You take the problem and reframe it as a data problem. Finding out how many users were affected by a bug might be just a SQL query away, while figuring out the most impactful feature could require some causal analysis, and predicting which users to offer discounts could require an uplift analysis.
Now that you’ve reframed the business problem as a data problem, you do your best to solve that data problem and suss out the results, still in the raw language of the data.
Lastly, you bring it all home by reframing one more time, taking the answer as it appears in your analysis and translating it back into the language of the business and returning to the context of the original framing. That causal analysis you did on which feature had the biggest impact spat out a whole bunch of coefficients, p-values, and confidence intervals in the last step—this is where you condense that nuance down back into a one-pager that doesn’t require a math degree to understand.

What the diagram (hopefully) makes evident is that you are a conduit between the business goals and some mysterious data, and it’s your job to dive into that data breach and pull something out that you can proudly present to solve a problem. The other thing the diagram shows is that there are really two separate sets of skills needed here: steps 2 and 3 are what we often think of when we think of “doing data science,” the part where you’re hunched over your laptop deep in a query or debugging a model. But it’s crucial not to forget steps 1 and 4—the part where you need listen to and speak with other human beings. Let’s dive into that part first.

The soft skills (which are actually hard)

Your communication skills form the bookends of the actual data work you do to accomplish a task. At the offset, you need to understand what’s being asked of you—what does your stakeholder want? At the end, you need to explain what it is you’ve done.

When it comes to understanding others, it’s valuable to ensure that you’re operating at the correct level of detail. If someone comes to you with a highly specific question—how many users interacted with button X on iOS or button Y followed by button Z on Android within the last N days?—it’s often helpful to pause and zoom out for a second. Yes, you could certainly pull that number, but you wouldn’t be in the position to confidently say that you’ve answered the underlying problem because you don’t know what they’re really asking about.

Instead, ask “what is the context here?” They might follow up with “I’m trying to figure out how many users were affected by bug A, which causes symptom B.” Maybe there’s actually a really easy way to find everyone who experienced symptom B, which is not only easier to query for, but reveals that there were users affected by the bug that wouldn’t have been captured by a literal interpretation of the original request. In this case, zooming out lets us see the full picture. The stakeholder was trying to make your job easier, attempting to do a little of that translation from business problem to data problem, but there is always room for error in that translation, so it helps to “trust but verify.”

In other cases the request may have too little detail and it’s your responsibility to fill in the gaps. If someone asks you to simply “predict which users are likely to churn,” you need to find out what time horizon you’re predicting over, how much inactivity constitutes a churn, what the threshold for “likely to churn” is, and probably a dozen other questions. In other words, you need to gather requirements. Your stakeholder will be able to fill in some of these for you, while others you may have to decide on your own and simply document the decision you made (and why).

Das Park-Konzert (circa 1908) by Ernst Ludwig Kirchner, via Ketterer Kunst.

Once you’ve done all your fancy data work, it’s time to communicate back what you’ve done and this time you’re the one who needs to be understood. It can be natural for data folks to want to include every bit of detail and nuance available: every assumption, caveat, p-value, confidence interval, and edge case. That’s all great stuff, and it will be invaluable in helping your peers review your work, but most of it should be relegated to the appendix of your final deliverable, if it’s included at all. This may be a controversial take, but at the end of the day it’s not your product manager’s job to interpret p-values, or your director’s job to understand the nuance of a causal model—that’s your job, and it’s also your job to communicate it to the statistical layperson.

There is no silver bullet here. In fact, there are a lot of ways for things to go wrong. Tossing away the nuance and caveats is exactly how statistics end up getting misused and misunderstood, and you may even face pressure at times to provide the interpretation that is most desirable to your stakeholder. On the other hand, if you try to shove a full dissertation into your report, no one is going to understand it (if they even try to read it at all).²

Instead, try to delineate the conclusions that your work does support, while also highlighting the (possibly tempting) claims that it doesn’t support. Your stakeholders won’t always do what you felt the data was telling them to do—a frustrating lesson to learn the first few times—but so long as you’ve provided them with accurate and complete information, you’ve done your job.

Practicing these soft skills is hard, but they’ll pay dividends in just about any role (not to mention in interviews).³ Unfortunately, they’re just one piece of the puzzle.

The hard skills (which are also hard)

Detail of a plate from The Mineral Kingdom (1859) by Johann Gottlob von Kurr, via the Science History Museum.

If this post is about the things that make up data science work that you don’t learn in a course, then why do we need to talk about hard skills? Aren’t those the skills you do learn in a course? The answer is yes, sort of, but also no.

Yes, you’ll learn about cross-validation, gradient descent, activation functions, and all that fun stuff in your books and classes, but the every day work of a data professional contains about a million other technical tasks that are just as important. A textbook is great for teaching you the things that never change—the formulas and high-level concepts—but they tend not to focus on the associated work that’s needed to operationalize that knowledge.⁴

A good chunk of your time is going to be spent on technical work that’s not the technical work you’ve studied, things like: experimental design, version control annoyances, dealing with really big datasets, job scheduling and orchestration, dependency hell, code review (giving and receiving it), defining and QAing metrics, and a whole lot more. You will likely need to learn at least the basics of command line tools, containers, cloud computing services, testing frameworks, and CI/CD frameworks.⁵

Furthermore, the above work is going to require you to become acquainted with tools you may not have encountered in your studies, for example:

dashboarding: Tableau and Looker
data warehouses: Snowflake, BigQuery, and Redshift
cloud offerings: EC2, S3, Lambda, SageMaker, ECS and EKS, or their Google/Azure equivalents
MLOps: Comet, WandB, Neptune
distributed computing: Spark, Flink, Ray, and Dask
infrastructure, automation, and observability tools: CircleCI, Kubernetes, Prometheus

Maybe you’re looking at this list and thinking, “Why would I need to know about dashboarding tools? I’m a machine learning engineer—I build models, not dashboards!” If you’re at a sufficiently big company, it’s possible that you’ll be specialized enough to only the technologies particular to your niche, but it will certainly be helpful to at least be familiar with them so you can communicate with the people that do use them. On the other hand, at most small and medium-sized companies, there’s typically enough (human) resource contention that you’re likely going to have to occasionally put on your BI hat and build your own dashboard. Embrace the opportunity to be a bit of a generalist: the ability to unblock yourself will come in handy over and over again.

You don’t need to be an expert in all or even any of these tools, but you should at least be generally familiar with the ones relevant to your role—i.e. you know what problem they’re meant to solve, even if you’ve never touched them in your life. The point of this section is not to encourage you to look at the list of tools above as a list of things you need to learn right now in order to get a job.⁶ (These are tools that early-career applicants typically won’t be expected to know because you’re not likely to have encountered them in a classroom or even in a personal project.) But if you find out on the first day of your job that you’re going to be using Tool XYZ, you should be able to learn about it. Can you go the homepage and find the “getting started” docs for the SDK in your language of choice? Can you find the API reference to help you understand an unfamiliar function in your codebase? Pick one of the above at random and give it a shot.

To round out this section, I’ll note that the tools you use are not the only change you’ll need to prepare for as you enter industry:

working in one big Jupyter notebook → working in a shared codebase with pull requests, code review, and merge conflicts
single scripts that run in one environment → modular packages with managed dependencies
tests? → tests
evaluation is offline → evaluation is offline and online
one metric to optimize → multiple potentially contradictory metrics to optimize
you own all of the code → your code has hand-offs with systems owned by others
your dataset fits in memory on your laptop → your dataset doesn’t even fit in your laptop hard drive
no restrictions on data usage → privacy and data retention compliance needs
code runs on your machine → code is deployed onto live services which must be monitored, maintained, and scaled

Again, you don’t need to master all of the above ahead of time because these are things you will get to learn on the job. I bring them up to highlight that you should expect things to work a little differently in a new job than they do even in your most polished personal project. Keep an open mind to the fact that a little bit of process (and bureaucracy) can go a long way toward keeping data and software projects manageable at industrial scale.

Closing thoughts

The Rock in the Pond (c. 1903) by Joaquim Mir, via the Google Arts and Culture.

I’ve highlighted a number of things that are different between industry and the classroom, but it’s worth noting a few important things that are the same. Whether you’re a student or a professional—at any point in your career—you should:

look things up and read the docs
ask other people for help
be open-minded and humble
keep learning constantly

This last one is the most important, and there is really no wrong way to do it. Read books and blog posts, attend conferences and meet-ups, talk to people about what they’re working on, contribute to open source, build side projects for fun, watch YouTube videos, get involved with data science communities. Share what you learn with others: write blog posts and make YouTube videos, publish your own open source libraries. Find out what resources your company offers for learning and development and take advantage of them.

On the other hand, data science does not need to be your life. Programmers are often expected to write code for fun on their own time—and many do—but be sure to leave room in your life for the things that bring you excitement and fulfillment outside of your career. Take language lessons, go bowling, see a show, spend time with friends and family. You can always read that blog post about “data science in industry” some other time.

Resources

Interested in reading more about data science (and software engineering) in industry but not sure where to find it? Look no further.

On soft skills: Building a Career in Software by Daniel Heller, 7 types of difficult coworkers and how to deal with them by Jordan Cutler and Raviraj Achar, Traits I Value by Andrew Bosworth, Letters to a Young Cog by Claire Stapleton, The Two Healthbar Theory of Burnout by Jeff Dwyer, Addy Osmani’s blog and Ethan Rosenthal’s blog.

Industry blogs: Airbnb, Doordash, Dropbox, Etsy, Github, Meta , Netflix, Pinterest, Spotify engineering and research, Stripe, Yelp.

Blogs: Eugene Yan, Francois Chollet, Xavier Amatriain, Lilian Weng, Vicki Boykis, Simon Willison, Julia Evans, and Sebastian Raschka.

Other websites: ML System Design resources, Applying ML, Made with ML, and Yannic Kilcher’s YouTube channel.

Communities: ML Collective, MLOps Discord, MLUX, Full Stack Deep Learning Slack, MLOps Community, and Locally Optimistic.

Eventually, once you’ve developed a strong sense of the business, you may begin to proactively propose projects in response to business problems you’ve detected, or in anticipation of likely future concerns. The key here is that your proposals should always be rooted in a legitimate problem for the business. It’s great if you can also make it an opportunity to learn something or try a new method/technology, but your primary objective is to serve the interests of the business. ↑
Lakshmanan, Robinsonn, and Munn have a good line on this topic in their book Machine Learning Design Patterns: “Model performance is typically stated in terms of cold, hard numbers that are difficult for end users to put into context. Explaining the formula for MAP, MAE, and so on does not provide the intuition that business decision makers are asking for.” ↑
Communication is not the only soft skill you should invest in. Many professional (non-technical) skills are covered in Daniel Heller’s excellent Building a Career in Software. For an even shorter take, there’s Jacob Kaplan-Moss, who writes that developers have two jobs: 1) write good code, and 2) be easy to work with. ↑
Of course, there are exceptions and you can find plenty of great resources out there on these topics like Chip Huyen’s Designing Machine Learning Systems and the aforementioned Machine Learning Design Patterns (see footnote 1, above). However, the literature and especially the academic coursework on theory tends to vastly outnumber the material on operations. ↑
A popular resource on command line tools is “The Missing Semester of Your CS Education” from MIT, which features lectures on a bunch of common utilities you’re likely to need at one point or another. If you’re in a hurry, ChatGPT comes in handy for generating quickie one-liners for “AWS CLI command to get the total file size for all files in an S3 bucket.” ↑
The only technology I’d really encourage someone to learn proactively as part of a data career search is SQL. It’s ubiquitous, it’s straightforward, you’re likely to use it every day, and you can learn it in a few weekends. ↑

Highlights from KDD 2023

2023-10-31T00:00:00-04:00

California Spring Landscape (circa 1920) by Elmer Wachtel, via the Smithsonian American Art Museum.

In August I attended ACM’s 29th Conference on Knowledge Discovery and Data Mining, better known as KDD, in Long Beach, California. Nearly three months later (whoops), my head is still overflowing with everything I saw there: I watched more than 50 paper talks, plus keynotes, invited talks, and workshops—and I still ended up missing several things I wanted to see. In this post, I’ll give an overview of what I saw and run down some of my favorite papers and talks from the conference.¹

Themes and trends

There were a few themes that I came across repeatedly at the conference. The first is no surprise: everyone is talking about large language models. Google’s Ed Chi gave a keynote on “The LLM Revolution,” there was even an “LLM day”, featuring a great talk from OpenAI’s Jason Wei on new paradigms that LLMs have ushered in. That being said, I couldn’t help but notice that (with a few exceptions) the vast majority of work I saw presented was not leveraging LLMs.

Another recurring motif was scale and the issues it raises. Problems that are tractable on a small scale raise new algorithmic and engineering challenges when scaled to millions of users and items.

Lastly, I noticed that the majority of recommender papers formulated the problem as multitask. It’s no longer sufficient to optimize for click rate alone: authors acknowledge that users and businesses have multiple goals and those goals can potentially be mutually satisfied by a single model.

Recommender systems

Because my work focuses on recommender systems and personalization, I spent a disproportionate amount of time attending talks on the topic. These talks typically, though not always, come from an industry setting and are much easier for me to transplant onto concepts and problems I’m already working on.

EvalRS workshop on evaluating recommender systems

I had a blast attending the EvalRS workshop on well-rounded evaluation of recommender systems, which consisted of two keynotes, lightning talks, and a hackathon.

Luca Belli gave a keynote on Practical Considerations for Responsible RecSys, where he outlined the challenges in evaluating recommender systems for fairness (what even is it?), picking metrics, and untangling personalization and discrimination. He mentioned that he has some upcoming work on “nutrition labels” for recommenders with standardized metrics, impacts beyond discrimination, transparency requirements, and more.

I was particularly fond of one of the lightning talks: Metric@Customer N: Evaluating Metrics at a Customer Level in E-Commerce by Mayank Singh et al from Grubhub. The gist is that using a fixed “N” for metrics like precision and recall from the top N recommendations per user is likely overly simplistic, neglecting to account for the fact that users’ browsing behaviors vary, and user A might realistically only ever consider the top 5 items while user B might browse 25. They propose adapting metrics to use a user-personalized N for each user, based on that user’s median or maximum items consumed in previous sessions.

In fact, I liked this idea so much that my colleagues and I implemented it for the EvalRS hackathon, which had the broad task of contributing to the well-rounded evaluation of the target dataset.² My team consisted of myself, my colleagues Eyan Yeung and Dev Goyal from Hinge, and Alexandra Johnson of Rubber Ducky Labs, and we managed to snag second place!³ First place went to the team from GrubHub, who made several contributions including implementing metrics@N.

Jacopo holding court at the EvalRS workshop, via Mattia Pavoni.

Joey Robinson wrapped up the workshop with the second keynote, Ask and Answer: A Case Study in ML Evaluation at Snap. I really liked his central thesis, which is that a model evaluation framework has to be able to mode than just tell us “is this model good or bad?”—it has to provide a means for us to ask and answer questions about how model’s behavior.

I want to give a huge thank you to the EvalRS organizers for putting together a great workshop (and afterparty), with an extra special thanks to Jacopo Tagliabue, who’s always been generous with his time and insights on all things RecSys and ML.

Joint Optimization of Ranking and Calibration with Contextualized Hybrid Model

Xiang-Rong Sheng et al, Alibaba. Paper at ACM and arXiv.

Many recommender systems have moved from estimating user ratings or click probabilities to focusing on learning relative rankings between items, since a ranked list is often the user-facing output of the system. However, a well-calibrated estimate of click-through rate is often still desirable (especially in online advertising contexts), and ranking loss functions (which typically pass logits for each item through a softmax to measure relative importance) aren’t well-suited to well-calibrated point estimates of probabilities. The authors of this work want to have their ranking performance cake and eat their click rate estimates too.

The go-to solution for tasks with competing loss functions is to just optimize for some weighted sum of the two losses, but the authors note that it’s been done and still fails to produce interpretable probabilities. Their solution is a bit more complex, but also clever. Rather than producing one logit per item, they produce two: one representing a click and one representing a non-click. The probability estimate is the sigmoid of the difference between the click and non-click logits (equivalent to the softmax of the two logits) and its calibration is optimized with log loss. Simultaneously, the ranking performance is optimized with contrastive loss encouraging a high logit for the positive sample and a log logit for the negative samples within a session (and there may be multiple sessions within a batch). The final loss function is a convex sum of these two.

A figure from the paper comparing pointwise loss, listwise loss, and the joint ranking and calibration loss.

It’s a nice trick, and separating out negative examples by session within the batch is something I hadn’t seen before (and required some work to ensure that entire sessions would be placed together in a batch during distributed training). The authors evaluated it against pointwise, pair/listwise, and convex sum losses on two open source datasets and their own logged data from production and found it (typically) outperformed the baselines on both ranking and calibration metrics. More importantly, the model was evaluated in a user-level A/B test against a pointwise baseline and brought a 4.4% lift in CTR, 2.4% increase in revenue per thousand impressions, and a 0.27% drop in log loss.

Recommender quick hits

Impatient Bandits: Optimizing Recommendations for the Long-Term Without Delay by Thomas McDonald et al, Spotify and University of Manchester. When recommending podcasts, Spotify found it was more valuable to model long-term engagement outcomes over short-term ones and developed a model for just that purpose. However, collecting data on long-term success of podcasts doesn’t work when you want to recommend new content. This work adapts the task of recommending podcasts for long-term engagement to the cold-start bandit setting. Using a short-term engagement proxy is not sufficient, but a continuously updated estimate of long-term engagement helps the bandit converge speedily on long-term optimal recommendations. Code available on Github.
Controllable Multi-Objective Re-ranking with Policy Hypernetworks by Sirui Chen et al, Renmin University and Alibaba (code on Github). One of many papers on multi-task recommendation, this one aims to improve on the fact that a weighting of different objectives is often chosen during or before training time and cannot easily be changed without re-training. Their contribution is a re-ranking model which leverages a hypernetwork that can adapt the model to a new set of objective weights on the fly, allowing the same model to be used across multiple surfaces where it may have slightly different use-cases.
Fresh Content Needs More Attention: Multi-funnel Fresh Content Recommendation by Jianling Wang et al, Google. At the core of this paper is a fairly obvious take-away for recommendation UX: it’s beneficial to set aside a slot to surface new content in order to learn more about it. However, there are modeling and engineering insights here as well, like omitting item ID embeddings from a network in order to encourage better generalization and avoid cold start problems, and designing a “user corpus co-diverted experiment” which splits both users and items in order to prevent leakage between treatment groups.
Text is All You Need: Learning Language Representations for Sequential Recommendation by Jiacheng Li et al, UCSD and Amazon. This work presents Recformer, a sequential recommender model which encodes items as textual descriptions based on their metadata. The work doesn’t explicitly leverage the brand-name foundation LLMs we all love to talk about these days (though there are people doing that work) and instead adapts a bidirectional transformer architecture not unlike that of Longformer. The authors talk about how recommenders which rely on embeddings of item IDs lose the ability to generalize or transfer since representations linked to IDs can’t easily be shared from item to item, but I am skeptical that we need to entirely abandon item IDs.
RankFormer: Listwise Learning-to-Rank using Listwide Labels by Maarten Buyl et al, Amazon. Read that title slowly: we’re talking about list-wise loss (measurements of ranking that consider every element in the ranked list) and list-wide signal (a label indicating whether the user received value from the entire list of recommendations). The former has existed for a while as an extension of pairwise loss functions for ranking, but the notion of listwide signal is fairly novel and comes into play particularly in cases where the user didn’t click any items in a list. Existing ranking metrics cannot learn from the case where a user doesn’t interact with any of the returned results, but the authors argue that this situation is both very frequent and a valuable source of user data. Thus the incorporation of this listwide signal allows them to augment more traditional LTR methods—indeed, their best performance was with a blend of listwise and listwide loss, rather than just one or the other.

Search

Search is intrinsically tied to recommendation and increasingly personalization, so I’ve been taking more and more of an interest in the topic.⁴ As large language models have blown up, search has seen a surge of interest, with particular focus on semantic search methods (which operate on embeddings rather than on text itself) and hybrid methods for tying semantic and more “classical” approaches.

Optimizing Airbnb Search Journey with Multi-task Learning

Chun How Tan et al, Airbnb. Paper at ACM and arXiv.

Just like in the Spotify Impatient Bandits paper mentioned above, Airbnb deals with optimizing outcomes with substantial delays between user actions and measured rewards—in this case, search journeys which may take weeks before a final reservation is made. Their method, Journey Ranker, is a multi-task model that leverages intermediate milestones to improve search personalization along this journey.

Airbnb searchers often abandon search sessions before ultimately making reservations later down the line, so clicks on search results are really only the first of many steps that must occur before an actual booking. Journey Ranker considers not only clicks but payment page visits, booking requests, host acceptance of booking request, and whether or not either the host or booker cancels the booking.

A shared representation embeds both the listing and search context, while the “base module” leverages this representation to make several intermediate probability estimates (probability of click given impression, booking given click, etc.) whose product is the final desired probability, as inspired by the Entire Space Multi-Task Model approach. A “Twiddler” module scores listings based on negative milestones like cancellation or booking rejection, using the same shared representation. Lastly, a combination module produces a learned linear combination the base and Twiddler module outputs.

A figure from the paper visualizing the Journey Ranker combination module.

The paper goes into detail on design decisions taken and not taken, and demonstrates the interpretability of the combination module’s linear task weights. They evaluated the method in offline and online settings, with the online test leading to a 0.61% increase in uncancelled bookers. They also applied the same method to other Airbnb use cases, netting a 9.0% increase in uncancelled bookers for online experiences (a newer and less optimized flow) and a 3.7% reduction in email unsubscribes.

End-to-End Query Term Weighting

Karan Samel et al, Google. Paper at ACM and Google Research

As sexy as “semantic search” may be, deep learning models are expensive to run at massive scale. As a result, bag-of-words and n-gram methods are often still deployed, with tokens weighted by scoring functions like BM25, which has proven to be a formidable baseline.

The authors of this paper wanted to adapt newer deep learning methods to operate within the bounds of a bag-of-words system by using a language model to learn weights (end-to-end) for query terms that are used as part of the input to the BM25 scoring function.

A masked language modeling task is used for pre-training an open source BERT checkpoint. Then a second pre-training task is used to learn uniform term weights as a starting point for the actual term weighting tasks. The fine-tuning is the end-to-end step which leverages the entire information retrieval pipeline: the query is fed to the BERT model to produce term weights, which are combined with document statistics as input to BM25. A combination of pointwise and ranking loss is then back-propagated all the way back to the BERT model to update the term weights.

A figure from the paper visualizing the architecture of the end-to-end weighting system.

There’s other fancy bits in here, like using a T5 model to generate soft labels for negative examples as well as a query expansion solution which weights both the original query terms as well as expanded terms. Another challenge was reconciling the wordpieces from BERT’s tokenizer with the world-level terms used by the existing system, which required additional masking and pooling.

The model performs well on the evaluation datasets, with some tough competition from SPLADE. They don’t mention any online experiments, but note that since their model only incurs a single forward pass on BERT, it’s “tractable to perform during serving.” Nonetheless, I admire the pragmatism underlying the approach. Replacing the existing retrieval system with deep learning would be a massive infrastructural change with integration costs, not to mention monetary and performance costs, but leveraging a deep learning model within the existing system can potentially get the best of both worlds.

Search quick hit

UnifieR: A Unified Retriever for Large-Scale Retriever by Tao Shen et al, University of Technology Sydney, Microsoft, and Ohio State University. This paper was presented right after End-to-End Query Term Weighting and practically threw down the gauntlet by claiming that methods which use a non-learnable function like BM25 to combine dense and sparse representations cannot possibly provide rich enough interaction between those representations. UnifieR learns both dense and sparse representations which share global context and supports both dense and sparse retrieval, as well as a select-then-re-rank “uni-retrieval” paradigm.

Software and engineering challenges

These papers focused less on novel algorithms (though they do include some) and more on building new solutions to improve performance and resilience. Software engineering is a fairly rare topic at ML conferences, but when it does come up it often provides a unique look behind the curtain at engineering challenges faced by some of the biggest tech companies on the planet.

Yggdrasil Decision Forests

Matthieu Guillaume-Bert et al, Google and Pinecone. Paper at ACM and arXiv, code on Github.

Yggdrasil is a new decision forest library in C++ and Python (as TensorFlow Decision Forests), with support for inference in Go and JavaScript.

I have a thing for talks about new libraries, like Transformers4Rec at RecSys 2021 or TorchRec at RecSys 2022.⁵ But what I really loved about the Yggdrasil talk wasn’t the discussion of features (a bazillion different tree-based models, evaluation methods, distributed training, etc.) but the focus on the design principles that went into making the library:

Simplicity of use: helpful interactions and messages at the appropriate level of abstraction, sensible defaults, clarity and transparency
Safety of use: warnings and errors that make it hard for users to make mistakes, easily-accessible best practices
Modularity and high-level abstraction: sufficiently complex pieces of code should be understandable independently, with well-defined interfaces between them
Integration with other ML libraries: avoid limiting users to methods available within their chosen library, favor composability

It reminds me of Vim’s design principles, and re-affirms my belief (partially inspired by my employer) that having principles from the outset is a good way to guide decision-making during any large project.

An excerpt from the Yggdrasil paper showing the library's approach to helpful, humane errors.

As you can see in the example from the paper shown above, these principles manifest in a library that attempts to guide you to use it correctly and effectively. The authors note that machine learning systems are often at risk of running without error, while silently doing something totally wrong, so this approach is valuable in preventing some of those potentially insidious errors.

Revisiting Neural Retrieval on Accelerators

Jiaqi Zhai et al, Meta. Paper at ACM and arXiv.

Deep learning has gained popularity in recommendation, older methods like matrix factorization have proven to be a hard baseline to beat.⁶ But even as matrix factorization has been largely supplanted neural alternatives, it has survived in the fundamental structure of most dense retrieval models: representing similarity as the dot product of learned vectors for users (or queries) and items. By saving all the vectors to an index, retrieval can be done with approximate nearest neighbors methods which scale to massive datasets while remaining highly performant.

But dot products just aren’t good enough for Zhai et al. They write: “The relationship between users and items in real world, however, demonstrates a significant level of complexity, and may not be approximated well by dot products,” citing the fact that interaction likelihoods are often frequently much higher-rank than these low-rank approximations can model, and noting that ranking models have mostly moved forward to more complex neural architectures. Nonetheless, there haven’t yet been solid alternatives to the maximum-inner-product search formulation. The authors seek to change this, and their contribution is threefold: a “mixture of logits” similarity function designed to outperform dot products and generalize better to the long tail, a hierarchical retrieval strategy that employs GPUs and TPUs to scale this method to corpora of hundreds of millions of items, and experiments demonstrating improvements on baseline datasets and Meta production traffic.

The authors go on to discuss not only their novel similarity function but the various tricks they employ to make it run efficiently on the GPU, bringing to mind a similar blend of algorithmic and engineering wizardry in Meta’s DLRM paper.

Improving Training Stability for Multitask Ranking Models in Recommender Systems

Jiaxi Tang et al, Google and Deepmind. Paper at ACM and arXiv, code on Github.

I mentioned that scale and multitask recommenders were major themes at KDD this year, and this paper (which was the winner on the Best Paper Award for Applied Data Science) has both. This paper is all about techniques to prevent instability (loss divergence) while training a multitask recommender for YouTube.

Training failures had clearly become a major issue for the team, and they found it hard to reproduce (models didn’t always diverge, even with the same configuration), hard to detect (divergence might occur before metrics are logged), and hard to measure. Rolling back to earlier training checkpoints didn’t address the heart of the problem and wasn’t even guaranteed to work.

A (cropped) figure from the paper demonstrating temporary and permanent loss divergence.

They found that the root cause of loss divergence was “step size being too large when loss curvature is steep” (they even bolded it in their paper). Recommendation models are particularly susceptible because they’re trained on many features in sequential data, which means there’s a very large probability of distribution shift during training, which in turn requires a consistently large learning rate to continue adapting to these shifts. Furthermore, ranking models diverged more than retrieval models seemingly due to their larger size and their tendency to be multitask (big gradients for one task can spoil performance on others through shared layers).

The solution ends up being a fancy variant of gradient clipping, affectionately dubbed “Clippy.” What makes Clippy unique is that it controls the size of the model update rather than the size of the gradient itself—these two values are synonymous in SGD, but can be very different with more sophisticated optimizers. They also measure the size of the update using the L-infinity norm, which is sensitive to large updates in even just a few coordinates.

Engineering quick hit

LightToken: A Task and Model-agnostic Lightweight Token Embedding Framework for Pre-trained Language Models by Haoyu Wang et al, Amazon and Purdue University. Everyone using language models likely needs to store and access a bunch of embeddings, but this can be challenging for deployment on edge devices. LightToken is a new embedding compression method which claims the state of the art in shrinking embedding tables. The four-step approach can be applied to any model backbone without the need for retraining while preserving model performance.

Grab bag

Not every paper I liked fits neatly into the themes above. Below are a few more papers of note that I wanted to highlight:

Variance Reduction Using In-Experiment Data by Alex Deng et al, Airbnb. Variance reduction methods increase the power of controlled experiments and allow experimenters to detect smaller effects. The work is a conceptual evolution of CUPED, which leverages pre-experiment covariates for variance reduction. This paper instead uses in-experiment data, particularly leading indicator metrics which estimate the desired (but delayed) ultimate outcome. The idea is similar at a high level to the Spotify “impatient bandit” mentioned earlier: using intermediate estimates of delayed outcomes.
Fair Multilingual Vandalism Detection System for Wikipedia by Mykola Trokhymovych et al, Wikimedia (code on Github). Wikipedia wanted to improve vandalism detection across languages, while preventing undue bias against anonymous editors who might become future repeat contributors.
Uncertainty-Aware Probabilistic Travel Time Prediction for On-Demand Ride-Hailing at DiDi by Hao Liu et al, Didi. The authors outline how travel time prediction has evolved at the Chinese ride-hailing app, starting with gradient boosted trees, evolving to RNNs, and then to graph-based methods. But all of these techniques estimated time as a single numerical output and failed to account for potential uncertainty. Their new model estimates a travel time distribution instead, reformulating the problem as multiclass classification, where the labels are discretized bins of travel times.
Extreme Multi-Label Classification for Ad Targeting using Factorization Machines by Martin Pavlovski et al, Yahoo and eBay. I have a big soft spot for factorization machines, a non-neural recommendation model that adds metadata features to classical collaborative filtering and which has stood as a strong baseline against (not to mention inspiration for) much fancier methods. In this work, the authors leverage a multi-label variant of FMs for ad targeting in a setting where neural methods produce an unacceptable amount of latency. Their dataset had 200,000 features, 1098 labels, and the model had only marginal memory costs versus a linear baseline, with inference in 0.16 milliseconds.
New Paradigms in the Large Language Model Renaissance by Jason Wei, OpenAI. I’ve got to share at least one LLM talk from the conference, and my favorite was Jason’s, which discussed the ways that LLMs have led to changes in the ways ML research happens. The massive scale needed for LLMs means individual researchers can’t easily to bottom-up ideation because they need a team with specialized skills, infrastructure, and resources to test out ideas. Emergent abilities of LLMs mean that researchers constantly need new benchmarks and evaluation methods, but also mean that new use cases don’t always necessitate new models. Lastly, advances in so-called LLM “reasoning” with methods like chain-of-thought allow models to handle bigger, more complex problems which are specified in natural language.

Wrapping up

There are around 20 papers in this write-up, and I left plenty of cool talks on the cutting room floor too. I’m thankful for my employer for sending me to conferences like KDD and Recsys where I’m able to hear so many ideas and take away so much. If you think I missed a particularly cool paper or talk, or just want to share your thoughts, don’t hesitate to reach out, and thanks for reading ‘til the end! If you liked this post and want to hear more from me in the future, you can follow my RSS feed.

I’ll note that this selection will be pretty biased by what I chose to attend. For instance, KDD features a ton of content on graph learning, the mast majority of which I didn’t attend because I don’t do much work with graph data. On the other hand, you’ll find recommender systems and search over-represented here, as those are areas of particular interest to me. I also missed the some workshops that I would’ve loved to have seen, like Decision Intelligence and Analytics for Online Marketplaces and Online and Adaptive Recommender Systems. ↑
It turns out that personalizing the metric can be quite harsh: the baseline model had a hit rate at 100 of 4.8% but a hit rate at median listens/day of only 0.03%! ↑
Second place…though I’m not sure if more than two teams submitted 😅. ↑
For others interested in search basics, I’d highly recommend the Search Fundamentals course from Uplimit, taught by Grant Ingersoll and Daniel Tunkelang. It’s a great intro into key search concepts and a whirlwind tour of basic Elasticsearch/OpenSearch functionality. I took the course in February and it opened my eyes to a lot of the parallels between search and recommendation. ↑
I never did get around to writing that highlights of RecSys ‘22 post… ↑
For example, see the work of Steffen Rendle, who has contributed factorization machines and Bayesian personalized ranking to the pre-neural era of recsys. He has continued to demonstrate the performance of non-neural recommendation models several times. See also Are We Really Making Much Progress? and Reenvisioning the comparison between Neural Collaborative Filtering and Matrix Factorization. ↑

Math and code for Are You the One?

2023-01-25T00:00:00-05:00

A Lover's Tryst (undated, 19th century) by Luděk Marold, via Christie’s.

I have an unusual fondness for the reality TV dating show Are You the One? What appeals to me is not (just) the drama and drunken antics of watching a bunch of twenty-somethings compete for love and screen-time. What I really like is the math.

The math

The math on AYTO derives from its premise: 11 men and 11 women have been paired up by mysterious matchmakers into 11 “perfect matches” and the contestants need to identify their perfect match for a chance at love and (their share of) 1 million dollars (split 22 ways). The group has two ways of finding information to determine all 11 couples. The first is the straightforward “Truth Booth,” where a chosen couple gets to find out definitively whether or not they are a match. The second is the “Matchup Ceremony,” where the group pairs up into their guess at the 11 couples and finds out how many couples are correct, but not which ones, a bit like the game MasterMind or even Wordle.¹ Each episode typically has one Truth Booth and one Matchup Ceremony.

With 11 men and 11 women paired into 11 heterosexual couples, there are a total of 11! (or about 40 million) possible pairings.² Every bit of information winnows the set of possible pairings down a bit. For instance, if a lucky Truth Booth on the first episode confirms a couple, then there would only be 10! = 3.6 million pairings left—an impressive 91% reduction. If that same Truth Booth revealed that the couple wasn’t a match, then there would be 10 × 10! = 36 million pairings left, a measly 9% reduction.

The math behind figuring out the impact of one Truth Booth on the first episode isn’t so bad, but it gets a bit tricky after that. And if you’re imagining the contestants seated around a table working through the possibilities, well…it’s not exactly that kind of show. The contestants aren’t even allowed pen and paper, much less computers. Instead, they’re provided with the slightly less useful tool of seemingly unlimited amounts of alcohol.

Nevertheless, they almost always succeed in figuring it all out by the end of the season.

The code

A fan favorite way to track the group’s progress throughout the season is with a spreadsheet, like this one I made for season 4 in 2017 (check out the different tabs to see the impact of progressively more information). With some thorough book-keeping, you can deduce perfect matches and sometimes even solve the entire thing before the season is over. It’s fun, but it’s also a bit tedious.³

In 2017, when Season 5 was airing, I made ayto-calculator, a script that tracked couple probabilities as information came in. In 2019, I made pyto to handle Season 8’s unique format (see footnote 2) and gave a presentation about it at work.⁴

A couple of weeks ago I got an email from a fan of the German version of the show seeking help on running my code. Getting my 2017 code working again was…unpleasant, so I started thinking about how I might implement this 6 years later, with a lot more Python knowledge under my belt. A few days later when I found out that the show was coming back for another season after a three-year hiatus, I knew I had to do a real rewrite to prepare.

And so a third repo, ayto, was born. It’s available on PyPI and can be installed by anyone with pip install ayto. This is what it looks like in action:

from ayto import AYTO

guys = ["Albert", "Bob", "Charles", "Devin", "Eli"]
girls = ["Faith", "Gina", "Heather", "Ingrid", "Joy"]

season = AYTO(guys, girls)

print(season.num_scenarios)
# 120

print(season.probabilities)
#          Albert  Bob  Charles  Devin  Eli
# Faith       0.2  0.2      0.2    0.2  0.2
# Gina        0.2  0.2      0.2    0.2  0.2
# Heather     0.2  0.2      0.2    0.2  0.2
# Ingrid      0.2  0.2      0.2    0.2  0.2
# Joy         0.2  0.2      0.2    0.2  0.2

# Bob and Heather go to the Truth Booth and learn they're not a match
scenarios_remaining = season.apply_truth_booth("Bob", "Heather", match=False)
print(scenarios_remaining)
# 96

# A Matchup Ceremony with 2 beams of light (i.e. 2 correct couples)
scenarios_remaining = season.apply_matchup_ceremony(
    [
        ("Albert", "Faith"),
        ("Bob", "Gina"),
        ("Charles", "Heather"),
        ("Devin", "Ingrid"),
        ("Eli", "Joy"),
    ],
    beams=2,
)
print(scenarios_remaining)
# 17

print(season.probabilities)
#          Albert   Bob  Charles  Devin   Eli
# Faith      0.35  0.18     0.12   0.18  0.18
# Gina       0.12  0.47     0.18   0.12  0.12
# Heather    0.18  0.00     0.47   0.18  0.18
# Ingrid     0.18  0.18     0.12   0.35  0.18

All we have to do to calculate the couple probabilities is keep track of every possible scenario and eliminate those which contradict Truth Booths and Match Ceremonies. Processing Truth Booths is straightforward: if the pair is a match, we eliminate every scenario that doesn’t feature that pair; if the pair was not a match, we eliminate every pair which does have that scenario. Matchup Ceremonies are only slightly more complex: we keep only the scenarios that share B couples in common with the couples from the Matchup Ceremony, where B is the number of beams of light (correct couples) from the ceremony.

The data structure

There are a few considerations for doing this efficiently, the first of which is how to store the scenarios. A simple and effective way to do this is to think of all the men as always being in the same fixed order. We can then represent a set of pairings by ordering the women such that the first woman in that ordering is paired with the first man, the second with the second, and so on. That is, if there are three men and three women, we can call the men 1, 2, and 3 and the women A, B, and C. Then a pairing of 1 with C, 2 with B, and 3 with A would be written CBA, and the 6 total possible pairings are ABC, ACB, BAC, BCA, CAB, and CBA.

In reality, we use integers (not letters) to represent the women, and so the starting set of all scenarios is a NumPy array 11 integers wide and roughly 40 million rows long. At first I was generating this list with Python’s itertools.permutations function, but this turned out to be rather slow, taking over 6 seconds to generate the 40 million scenarios. Luckily, Daniel Giger provides a faster NumPy permutation algorithm on Stack Overflow that reduces the time to about a quarter of a second.

Thus the above 6 combinations of 3 men and 3 women would be stored as:

[[0, 1, 2],
 [1, 0, 2],
 [0, 2, 1],
 [1, 2, 0],
 [2, 0, 1],
 [2, 1, 0]]

Pruning scenarios

Reasoning about matches plays out a little differently in the show than it does in code.

The second major consideration is how to prune the scenarios. My previous projects and my first iteration of ayto would all loop through all scenarios and loop through each pair in a scenario, checking to see how many pairs match between a scenario and a Truth Booth or Matchup Ceremony. This is very slow.

I realized that a much better way to do this would be with some clever vectorized NumPy operations. Now the pruning process for a Matchup Ceremony is effectively three lines:

sums = (scenarios == matchup_list).sum(axis=1)
idx = sums == beams
scenarios = scenarios[idx]

What’s going on here? The variable matchup_list is a 1-by-11 array of integers representing the pairing we are evaluating (e.g. the pairing chosen at the Matchup Ceremony), and scenarios is the aforementioned N-by-11 array of possible remaining pairings. Performing the comparison scenarios == matchup_list broadcasts the smaller array along the first axis of the longer one, meaning we compare the test pairing against every possible pairing in scenarios and we end up with an N-by-11 array indicating element-wise equality.

When we take the sum(axis=1) of that result, we count the number of True elements in each row and end up with an array of these counts N elements long.

Lastly, the comparison sums == beams compares the number of Trues in each row to the number of beams produced at the Matchup Ceremony (broadcasting the comparison again). We end up with a length-N array idx of booleans, with True for the indices of scenarios that remain and False for those that have been eliminated. We can update our list of scenarios with scenarios = scenarios[idx].

Compared to naive looping, this method is about 36 times faster at applying a Matchup Ceremony to the full list of starting scenarios for 11 men and 11 women (0.9 versus 32.1 seconds). A slightly simplified version of the same logic is used for Truth Booths.

Calculating probabilities

The last step is to take this list of scenarios and calculate all 11×11=121 couple probabilities. We can cheat when we initialize the probabilities because we know they’re all 1/11, but otherwise our strategy is to see how many times each woman is paired with each man and divide it by the total number of remaining scenarios.

My first attempt at this was (once again) plain old Python loops, building up a counting dictionary. This method takes over 70 seconds to calculate probabilities after the first Truth Booth.

To speed it up, NumPy saves the day again. We still use a dictionary (a defaultdict actually) to count up how many times each woman is paired with each man, but we use NumPy’s unique function to count all the women simultaneously for each man. It looks like this:

probs = defaultdict(lambda: defaultdict(float))

for guy_idx, guy in enumerate(guys):
    # get that guy's column of the scenarios dataframe
    col = scenarios[:, guy_idx]
    # construct a dictionary counting how many times each girl_idx appears
    unique, counts = np.unique(col, return_counts=True)
    count_dict = dict(zip(unique, counts))
    for girl_idx, girl in enumerate(girls):
        # populate probs dict with probaility = counts / num_scenarios
        probs[guy][girl] = count_dict.get(girl_idx, 0) / num_scenarios

At a little over 6 seconds (the slowest operation in the library by far), this is 10 times faster than the naive loop version.⁵

Other niceties

Since I knew that I wanted to publish my work on PyPI, I figured I might as well adopt some best practices when it comes to Python packaging. The project is set up with pyproject.py, as defined in PEP 518, rather than the setup.py of yore. It’s got a test suite with 100% code coverage and benchmark tests that I used to compare the performance of different implementations as I iterated.

I also used GitHub Actions for CI: when I create a pull request, it automatically runs my tests and mypy on three versions of Python, and when I create a new tag, it automatically publishes it to PyPI.

And believe it or not, I haven’t even mentioned every feature in this blog post. Check out the demo notebook for a full tour of the library’s capabilities.

Parting thoughts

Whether you’re eager to get the latest probabilities each week, or you’re just curious to toy around with some code, feel free to check out the ayto repo.

I hope I’ve convinced you that Are You the One? is more than just another reality TV show. Fans of the coding project may not love the show, and fans of the show may not care about the code, but I find there to be something enjoyable in both.

Of course there is the third way of learning information which is the contestants getting to know each other and trying to determine—based on genuine human connection—who their matches might be. The show places an, I think, undue amount of emphasis on this component. I prefer to focus on the hard facts over the caprices of the contestants. ↑
The format has varied slightly over the years. Early seasons had 10 men and 10 women, reducing the space of possible pairings by an order of magnitude to 10! (or 3.6 million) pairings. Season 8 had 16 contestants, but all contestants were bisexual so anyone could be paired with anyone else, for a total of 16!/(2⁸×8!) or about 2 million pairings. ↑
Or maybe it’s fun because it’s tedious. The manual spreadsheet-ing certainly provides a sense of accomplishment, while automating the work can feel a bit too easy at times. ↑
I’m not the only one to have this idea. Alex at Are You The One? Math has been dutifully blogging mathematical commentary since 2014 and, while he hasn’t published his code (to my knowledge), I owe him a debt for inspiring me to write my own. ↑
I also tried two alternatives: 1) Getting the count for each girl by doing count = (col == girl_idx).sum(), which was marginally slower than using np.unique. 2) Getting the counts of women for all men simultaneously with np.unique(scenarios, return_counts=True, axis=1) is insanely slow and might not even do what I want (I never let it run long enough to finish). ↑

What I learned through Advent of Code 2022

2022-12-27T00:00:00-05:00

Landscape with Stars (c. 1905–1908) by Henri-Edmond Cross, via The Met.

December is a time for bringing out the winter jacket, curling up by the fire with a book, and—for many—participating in Advent of Code, an annual set of 25 daily two-part programming puzzles.

The puzzles are in roughly ascending order of difficulty. In 2020, I gave up after 18 days. Last year I did 15. This year (though I skipped a few along the way) I made it all the way to the end, completing 43 of the 50 total puzzles.

Some people like to do AoC in a language that’s fairly new to them, learning as they go. Others try to do every day in a different language, or to ensure that all solutions run in under a second. The guy who finished in first place on the leaderboard this year did the puzzles in a programming language he invented…so there’s that too.

I did the puzzles in Python, the language I know best, but I still managed to learn and try out quite a few new things along the way.

All my solutions are on Github, for the curious reader’s perusal.

Warning: If you’re planning on doing the challenges this year and you haven’t already, a) what are you waiting for?, and b) this post contains some mild spoilers.

The power of friendship

The first 5 or so days of AoC are pretty simple, the next five are reasonable, and after that they start to take a little time. I got a ton of value out of chatting with others about the problems and our approaches, whether that was in my work’s #advent_of_code Slack channel, the NormConf Slack daily puzzle threads, or on Reddit.

I did my best to finish or substantially attempt all the puzzles before resorting to discussion and hints, but there were a few cases where I couldn’t have done it without the wisdom of others (or, in one case, basically just stealing a few lines after banging my head against the wall for too long). It’s really fun to see the sometimes wildly different approaches that people take, whether it’s based on their level of experience, their background, or their choice of language.

Classic algorithms and data structures

Speaking of background knowledge and experience: I only ever took intro to computer science in undergrad, and most of my programming skills are self-taught, so I have a lot of gaps around things you learn college CS courses that you might not pick up in day-to-day programming, namely around algorithms and data structures.

Day 12 involved some pathfinding, and I was able to reuse what I wrote for Day 15 of last year, which I believe is an acceptable attempt at the A* algorithm (though I didn’t know that at the time) that I cobbled together.

Several other problems this year were well-suited to breadth-first search, which is just not something I’ve ever formally learned. I managed to make my way through the problems without a real BFS implementation until day 24 when I was faced with a more complex path-finding problem. I took the Wikipedia pseudocode and turned it into a reasonable solution in Python.

En route, I learned a bit more about queues, a data structure I’d never had much use for before. The advantage of a queue over a list comes when we frequently need to a) add to the end and b) take from the front. Adding to the end of a Python list is fast, but removing an item from the front is O(n). Queues, on the other hand, can give you O(1) insertion and removal from the ends.

You’d think that the best way to implement a queue in Python would be the built-in class called queue.Queue, but this is actually quite slow. It turns out that Queue is better suited to general-purpose communication between threads and incurs overhead to insure thread-safety with locks. On the other hand, collections.deque implements a double-ended queue without the locks needed for fancy multithreading, and serves our purposes at a much faster clip. In my solution, swapping Queue out for deque took the solution from 2.5 to 1.5 seconds.

Match/case statements

New in Python 3.10 is structural pattern-matching, aka the match/case statement. On the surface, it might seem like a fancy way of rewriting if/else statements, and it basically is. However, the syntax allows for substantially more legible code when dealing with complex sets of conditions.

I gave pattern-matching a shot and ended up using it in three puzzles, to great success.

On Day 7, you have to parse a set of faux command line commands and output that look something like this:

$ cd a
$ ls
dir e
29116 f
2557 g
62596 h.lst
$ cd e
$ ls
584 i
$ cd ..

Using pattern-matching made writing my parsing code much neater than writing a bunch of awkward if/elif statements (gratuitously commented here for exposition):

# for each line, we split the line into separate words
match line.split():

    # if we've got 3 words where the second is "cd" and the third is ".."
    case [_, "cd", ".."]:
        # deal with the "go up a directory" case
        folder_sizes.append(node.get_size())
        node = node.parent # type: ignore

    # if we've got 3 words where the second is "cd" and the third is something else
    case [_, "cd", dir_name]:
        # deal with the "go down a directory" case
        node.children[dir_name] = Node(name=dir_name, parent=node)
        node = node.children[dir_name]

    # if we've got 2 words and the second is "ls" *or* the first is "dir"
    case [_, "ls"] | ["dir", _]:
        # deal with those cases (which actually don't require anything)
        pass

    # if we've got any other case of 2 words, it's a filesize and a file
    case [size, name]:
        node.children[name] = Node(name=name, parent=node, size=int(size))

A line like case [_, "cd", dir_name] simultaneously checks that line.split() is three values long, and that the second one is the string "cd", and then lets us use the variable dir_name to capture the third value for the contents of the clause. This is great syntactic sugar for a fancy if statement and, in my opinion, very readable.

On Day 11, we’re once again parsing a predictable series of inputs with different semantics, and this time I used the wildcard pattern to capture an indeterminate number of values:

case ["Starting", "items:", *nums]:
    items_str = f"[{' '.join(nums)}]"

And on Day 13, I had the chance to use type-based pattern-matching to distinguish between cases based on the types of the values:

match left[i], right[i]:
    case [int(), int()]:
        # do int comparisons
        if left[i] != right[i]:
            this_comparison = left[i] < right[i]
        else:
            this_comparison = None
    case [int(), list()]:
        this_comparison = compare([left[i]], right[i])
    case [list(), int()]:
        this_comparison = compare(left[i], [right[i]])
    case [list(), list()]:
        this_comparison = compare(left[i], right[i])

All in all, I was impressed with the flexibility and power of the syntax and I’m looking forward to using this in the future for making complex conditionals more human-readable.

Swifts: Paths of Movement + Dynamic Sequences (1913) by Giacomo Balla, via MoMA.

Python’s built-in profilers

Python is somewhat infamous for prioritizing ergonomics and dynamism over raw performance (though it’s getting faster), but that doesn’t mean it has to be slow. There were a number of problems this year where your approach, choice of data structures, and implementation decisions could make the difference between the code completing in less than a second or maybe not at all.

I got a ton of value out of Python’s cProfile. For my purposes, a simple python -m cProfile my_script.py was all it took to get a bunch of output on which functions or operations were taking the longest. Even if you kill the script before it finishes (because maybe it won’t finish…), you still get the profiler output to figure out what your program is stuck on. It was a great way to find the bottlenecks in my solutions, like an inefficient loop, a list where I could’ve used a set, or a class where I could’ve just used a tuple. In fact, it was the profiler that showed me that the aforementioned Queue was spending lots of time on functions imported from threading.py and revealed that it wasn’t the right data structure I needed.

A quick-and-dirty cache

A common source of grief for beginning Python developers is mutable default arguments. It can be surprising to find that your function has become stateful and the results are changing with each call.

However, this same behavior also lets us easily add a cache to a function. For instance, on Day 24, you have to deal with a 2D grid and you’ll frequently want to generate a list of the points which neighbor a given point without going out of bounds. This is a fairly simple operation, but caching it gives us a nice performance boost:

class Grid:
    def __init(self, lines: list[str]):
        # omitted for brevity

    def neighbors(self, point: Point, cache: dict = {}) -> list[Point]:
        if point in cache:
            return cache[point]

        x, y = point
        candidates = [point, (x - 1, y), (x + 1, y), (x, y - 1), (x, y + 1)]
        result = [
            (x, y)
            for x, y in candidates
            if ((0 <= x < self.width) and (0 <= y < self.height))
            or ((x, y) == self.start)
            or ((x, y) == self.end)
        ]
        cache[point] = result

        return result

That cache: dict = {} in the function signature is where the magic happens. An empty dictionary is created when the neighbors function is defined, and that same dictionary (along with anything that gets added to it inside the function) is reused on every subsequent call, allowing us to skip the function body for a dictionary lookup if we’ve already computed the result we need.

With the cache, the script solves the puzzle in about 1.5 seconds (admittedly, one of my slower solutions for all of AoC). Without the cache, it finishes in 3.1 seconds. Removing the cache from another more expensive function in the same solution brings the runtime to 382.0 seconds. Caching matters, and this is a very low-lift way to add one.¹

Type hinting is getting better all the time

Since version 3.5, Python has supported optional type hints: annotations in source code that indicate the type of a variable. This is somewhat tricky business in a language as dynamic as Python, but when combined with type-checking tools like mypy and clever IDE integrations, it can surface bugs early and also serve as great documentation for your future readers.

But typing was a late addition to Python, and the original implementation was a bit less-than-ergonomic, requiring frequent imports from the typing library for anything beyond the most basic annotation. Language enhancements in recent Python versions have made the process much more seamless, and I took advantage of some of those features to add annotations to all my solutions and ensure they all passed mypy checks.

Python 3.9 added “type hinting generics in standard collections,” which is a fancy way of saying that if you want to annotate a list of ints, you can just write numbers: list[int] rather than needing to import List from the typing module to annotate List[int]. It’s a small thing, but it goes a long way in making typing feel more like a first-class feature of the language rather than this odd thing that you can do with an extra module.

Along the same lines, Python 3.10 added the union operator, so a variable that could be a float or a list of floats can be annotated foo: float | list[float] rather than number: Union[float, list[float]] (after importing Union from typing). This also lets you avoid importing Optional: instead you just write foo: float | None.

I also heavily used type aliases, which have apparently been around for a while but which I seem to have missed. It was pretty common to be dealing with tuples of two ints representing coordinates on a grid, and maybe a function returns a list of these coordinates. Without type aliases, we’d annotate the return type as list[tuple[int, int]]. However, with a simple Point = tuple[int, int], we can annotate this as list[Point] instead. Much better!

…but it still has some rough edges

The above notwithstanding, all is still not perfect in Python type world. For one thing, forward references (annotations referring to types not yet defined) still have to be annotated as strings, as was the case in a graph node class I implemented for day 7:

class Node:
    def __init__(self, name: str, parent: "Node | None", size: int | None = None):
        ...

The "Node | None" annotation is the forward reference and it feels hacky. Arguably it should at least be "Node" | None, which seems to be under discussion but isn’t yet supported. Edit: Joel Grus pointed out that this can be fixed with from __future__ import annotations, after which the Node | None annotation works fine. This fixed behavior will be added to a future version of Python. Thanks, Joel!

Worse yet, at least twice I had to cast mypy asside witih a # type: ignore comment to dismiss some nagging edge case I couldn’t fix. In that same puzzle, there is a case where I’m dealing with that same troublesome Node.parent attribute, which is either a Node or None. In the context, I know it’s a real Node and I happily assign its value to a variable which is also a Node, but the type-checker still thinks it could be None (it has no way of knowing it’s not) and throws an error. I believe the canonical solution is to add an if foo is not None: clause in there so that mypy is sure the attribute is non-null in this case, but it feels wrong to add logic to the code just to satisfy the type-checker.

I also found that the value of adding type hints to my puzzle solutions was fairly low. In production code, I’ve had mypy detect sneaky bugs where I was unknowingly relying on behind-the-scenes type coercion rather than being careful about what I pass around. But in Advent of Code the annotations mostly end up being overkill—at best they helped me with rapid refactorings as I rewrote a solution-in-progress.

Walrus Hunt (1801) by Elizabeth Fitzgerald, via the Art Institute of Chicago

Classes as a last resort

It’s easy to make a habit of reaching for a class whenever you start dealing with instances of structured data. I resisted the instinct to class-ify everything during AoC. In one instance, I refactored a solution to remove a class, replacing it with a tuple: the profiler showed me that the overhead of millions of __init__ calls were slowing my solution down and I wasn’t even getting much value out of the class.²

I ended up writing custom classes for 7 of the 25 days, 5 of which were Grid or Board classes that I used to manage movement, storage, and display of points around 2D/3D spaces. The presence of structured data alone is not enough to warrant a class, but when you start to accumulate functions to act on that data and have state that you need to keep track of, a class comes in handy to keep things tidy.

Some people are big fans of Python’s dataclasses, which allow you to easily define classes for structured data with less boilerplate, but I’m not sure I count myself among them just yet. I originally had a dataclass in one or two of my solutions, but I must have refactored them out before finishing. I found that if I only needed a dataclass, I likely didn’t need a full class at all and could replace it with a tuple. In the instances where I did need a class, I had enough initialization logic that I needed to write my own __init__ function, and the dataclass didn’t offer me much.

The walrus operator: Still not for me

Python 3.8 introduced assignment expressions or, as they’re more commonly known, the “walrus operator”. It looks like := and if you squint it kinda looks like a sideways walrus. It’s proposal was the source of near-infinite controversy and drama and the whole affair contributed to Python’s creator Guido van Rossum stepping down from his role as the language’s Benevolent Dictator for Life.

The walrus operator lets you assign a value mid-expression. It’s best demonstrated with an example (adapted from the docs):

# Without walrus operator
# a) separate line for assigning a variable that we will reuse
n = len(a)
if n > 10:
    print(f"List is too long ({n} elements, expected <= 10)")

# b) calculate the length twice
if len(a) > 10:
    print(f"List is too long ({len(a)} elements, expected <= 10)")

# With the walrus operator
if (n := len(a)) > 10:
    print(f"List is too long ({n} elements, expected <= 10)")

Option (b) is potentially bad for performance if you’re doing something more intense than calculating a length. Option (a), however, suits me perfectly fine and all the walrus operator really does is save us a line.

I wanted to keep an open mind and give it a shot if a reasonable use case came up, but I never saw the occasion to use it and even while going back through my solutions I couldn’t find a place where it would make sense to swap it in. I have no strong feelings one way or another about the feature, but my code remains walrus-free, maybe because of my last point…

Verbose is better than terse

Okay, so this isn’t something I learned this time around, but its importance was apparent again and again, especially as I was writing this post and rereading solutions from weeks ago but also as I was debugging almost-working solutions. Your colleagues and future you will appreciate and better understand code that is written clearly, not code that is golfed to a minimum number of lines or characters.

To be fair, for some people a big part of the fun is writing their solutions in as few lines as possible, and that’s okay too! I often checked out r/adventofcode after completing a puzzle and was shocked to find that someone else had written a Python solution in a dozen lines that I’d finished in 100, and I invariably learned something new from those solutions—if I could make sense of them. But as someone who was using AoC to practice and enhance my better programming practices, I found it valuable to take the long road. More verbose code makes code comprehension and debugging easier.

This is arguably captured by few of the lines of the Zen of Python: “Beautiful is better than ugly,” “Explicit is better than implicit,” “Simple is better than complex,” and especially “Readability counts.”

I hope that I stayed true enough to this principle that others can learn something from my solutions if they’d like.

Of course, there’s a limit to just how verbose one needs to be, and so I think I’ll end this post here. See you all again next Advent of Code.

Special thanks to Tim Hochberg and Peter Baumgartner who gave this post an early read.

Early reader Tim Hochberg pointed out that Python also provides a similar caching solution in the form of functools.cache, a decorator which implements the same caching logic for you. This is a great catch and I had simply forgotten about it. The default argument method offers slightly more flexibility, for example: when you need to manipulate your function arguments before using them as cache keys (maybe the function takes a list, but you need to convert it to a tuple before it can be a dict key) or if you want to be able to pre-populate the cache. I used a prepopulated cache (though not via a default argument) in one solution. ↑
Actually, it was worse than that. In this problem, we have to find the shortest path through a storm. I had initially been keeping track of paths as linked lists of nodes where each node knew its coordinates and pointed to its parent. The length of the path could then be calculated as 1 if there was no parent, or else 1 plus the length of the parent. This felt clever at the time, but led to tons of recursion just to get the path length. My next step was to just manually add 1 to a static length attribute each time I created a node, and it was at that point that I realized that I could drop the class and just switch to a tuple of coordinates and length. ↑

Late 2016, early 2017

2022-06-13T00:00:00-04:00

Taken in and around Crown Heights, New York, roughly around the end of 2016 and start of 2017. Kodak Ultramax 400 film in a Nikon N65. Gently post-processed.

Goals for 2022

2021-12-31T00:00:00-05:00

A New Year on the Cimarron (1903) by Frederic Remington, via Wikimedia Commons.

I’m typically pretty averse to making “new year’s resolutions,” but in the spirit of learning in public and holding myself accountable, I figured I’d put a few goals out there that I can check in against throughout the year.

Write more

I’d like to write at least 12 posts on this site. There are no strict rules on what constitutes a “post,” so it can be as simple as a monthly update or as in-depth as my last post. I’ve got a few topics of varying degrees of complexity in my backlog and it stands to reason that inspiration should strike at least a few more times between now and next January.

You can keep up on what I end up writing via RSS. If you’d prefer to be notified via email, you can paste the RSS feed URL into a service like Feedrabbit or Blogtrottr.

According to Goodreads, I finished 20 books in 2021. My goal for last year was 30, which was probably a bit ambitious. Splitting the difference, I’ll set a goal to read 25 books.

Furthermore, I’d like at least 3 of those books to be nominally “technical,” i.e. vaguely related to my work (statistics, machine learning, software engineering, and so on). I’m already a good chunk of the way into The Programmer’s Brain by Felienne Hermans, so that’s a nice head start. I also make progress in fits and starts through Designing Data-Intensive Applications, but it’s a heady 600+ pager, so we’ll see how that goes. If you’ve got a suggestion for a good read on anything loosely related to production data science, I’d love to hear it.

Learn more

I have access to Udemy and Ardan Labs through work, so this past year I took a Go course and a short course on Protobuf, as well as the Ardan Labs’ Docker course.

Next year I’d like to take (at least) one online course—and that’s not counting the Ardan Labs Kubernetes course that I’ll also be taking through work. Maybe this is the year I’ll finally finish Bayesian Methods for Hackers!

I’d also like to start having conversations in French. I’ve been learning very basic French on Babbel, but it’s about time I take the next step and start taking classes with a human teacher (in some pandemic-friendly format). I want to be able to spontaneously produce sentences rather than just being able to slowly make sense of written text.

Take more photos

A photo I took on a trip to Budapest in the summer of 2018—just one of thousands I've yet to properly go through.

I love to take photographs, and I take photos on my phone all the time. However, I also have a Nikon D7200 that I’m not taking advantage of nearly enough, so I’d like to shoot two new batches of photos and post the highlights to this site this year.

I’ve also got thousands of years-old photos from trips to Hawaii, Budapest, Prague, and Berlin that I haven’t yet processed, so it’d be nice to make some progress sorting through that backlog too.

See you in 2022

That seems like plenty to take on already, so I’ll stop here. If you want to keep up with me in 2022, you can find me on Twitter or follow my writing via RSS.

Happy new year! 🎊 🎉

Belated highlights from RecSys 2021

2021-12-06T00:00:00-05:00

From Scene of Amsterdam (19th century) by Charles Euphrasie Kuwasseg, via Dorotheum.

In September, I virtually attended ACM’s RecSys conference, which was held in Amsterdam this year. I watched nearly 70 talks, ranging from keynotes to quick poster sessions, and below I’ve collected thoughts on some of the talks that I most enjoyed. I’ll also come back and add links to the talk videos once they’ve been posted.

For those unfamiliar, RecSys focuses on all things related to recommender systems: models which (roughly speaking) predict what items a user will like. Not only are recommenders what I’ve been working on for the last couple of years, but it’s also a topic I find personally fascinating, and I hope you will too.

P.S. Some other folks also published their highlights of the conference. Check out Eugene Yan’s “Papers and Talks to Chew on”, Vicki Boykis’ RecSys 2021 Recap, Balázs Hidasi’s Impressions and Summary for more.

Practical issues

These talks focus on issues surrounding recommender systems in production and, as a result, come largely from industry.

Twee jongens en een ezel (20th century) by Julie de Geluk, via the Rijksmuseum.

Jointly optimize capacity, latency, and engagement in large-scale recommendation systems

Presented by Hitesh Khandelwal from Facebook. Paper at ACM and Facebook Research.

Facebook has been in the news a lot lately for failing to prevent harms caused by their platform, even when their research shows that those harms are real. A user’s experience with Facebook (and Instagram) is heavily mediated through their interaction with a number of different recommender systems, which makes Facebook’s present situation an important case study for anyone interested in ethical issues surrounding recommender systems.

Facebook did give a talk on mitigating long-term effects of recommenders during the conference (they concluded that even weak preferences for borderline content would inevitably be amplified and that the best you can do is try to slow this process down) but that’s not paper I want to talk about.

This particular paper focuses on scale, something Facebook knows better than almost anyone. In particular, how can recommendation models behind Facebook Marketplace be optimized to perform well for their first-order task (presumably engagement, conversion, etc.) while reducing latency and the computational cost of serving over one billion users per month?

The first step of the solution is the obvious one: cache recommendations from the “sophisticated and computationally expensive” ranking model to save on CPU cycles and latency that would result from online inference.
The world and the user are always changing, so a lighter-weight “adjuster model” corrects for changes in user and item features since cache time. The adjuster model is distilled from the full ranker but takes into consideration a) the latest features, b) the “gap time” between caching and the present, and c) deltas in important features between caching time and present.
Lastly, pre-fetch recommendations to device upon opening the Facebook app (but before navigating to the Marketplace pane). In particular, results are only pre-fetched if indicated by the results of two more models: one which estimates the probability of opening marketplace, and another model which estimates latency of generating the rankings.

All in all, it’s eye-opening to see the amount of engineering that goes into delivering computationally-intensive recommendations at massive scale.

Recommendations at a reasonable scale in a (mostly) serverless and open stack

Presented by Jacopo Tagliabue from Coveo Labs. Paper and video at ACM, code on Github, a similar talk from the same author on YouTube, and a similar blog post from the same author on Towards Data Science.

We just saw how much technical muscle Facebook throws at their scale issues, but the chances are that you’re not Facebook, and you don’t need solutions which scale to billions of users.

Tagliabue defines “reasonable scale” as companies with a finite commodity cloud budget, dozens (not hundreds) of engineers, making 9 (not 10) figures per year, with terabyte (not petabyte) scale data. If this sounds like you, then the talk’s accompanying repo offers an architecture for a non-trivial recommender system, including data validation, deployment, monitoring, and orchestration, using open-source tools like dbt, Metaflow, and so on.

Regardless of whether you intend to use any of the architecture, Tagliabue’s principles are valuable. He stresses the importance of data quality and leveraging the many high-quality SaaS/PaaS offerings so you can avoid time-consuming infrastructure maintenance.

RecSysOps: Best practices for operating a large-scale recommender system

Presented by Ehsan Saberian from Netflix. Find the paper at ACM and a video of the talk on YouTube.

This talk was one of a few that stressed the importance of having a good ops backbone when building and maintaining recommender systems. “RecSysOps” is broken into issue detection, prediction, diagnosis, and resolution, all of which are easier said than done.

I particularly liked that a team could take on these suggestions in an iterative approach. For starters, implement best practices and end-to-end monitoring, with a focus on the types of issues that are important to your stakeholders. Once issue detection is (relatively) under control, you might try your hand at predicting future issues.

My favorite piece of advice was: “with every issue, make your RecSysOps better.” In other words, if detection was hard for this type of issue, try to predict it in the future. If resolution was hard, build a tool to automate the solution in the future.

Three talks on organizational issues

If “RecSysOps” is about the software practices which support recommender systems, these two talks are about the communication and cultural practices which support doing data science in a large organization:

Scaling enterprise recommender systems for decentralization by Maurits van der Goes, Heineken. The “decentralization” in this case is not about distributed systems or cloud architectures, it’s about decentralized organizations and how to build valuable ML infrastructure for a large company with heterogenous needs.
Challenges experienced in public service media recommendation systems, presented by Andreas Grün for ZDF. Grün discusses the need to meet different teams within the organization where they were, exposing the appropriate abstractions and levels of control. He also brought up a topic rarely addressed at the conference: reducing energy consumption by (for example) replacing deep sequential recommenders with heuristics.
Building public service recommenders, presented by Christina Boididou for the BBC. Another great talk about recommenders in the public service sector, with insight on the organizational, infrastructural, and cultural challenges of brinigng recommendations to a 99-year-old organization which previously relied on editorial curation.

Algorithmic advances

These talks are focused more on new ideas, methods, and algorithms, as well as new perspectives on issues related to recommender systems.

Roeiboot op zee (19th century) by Frans Arnold Breuhaus de Groot, via the Rijksmuseum.

Top-k contextual bandits with equity of exposure

Presented by Oliver Jeunen for University of Antwerp. Paper at ACM and the author’s website, code on Github.

Olivier Jeunen and Bart Goethals won the Best Student Paper award for their other RecSys paper Pessimistic reward models for off-policy learning in recommendation, but I particularly liked this one on bandits with equitable exposure.

The key idea is that a small difference in the computed relevance between two items might mean a big difference in exposure if one item gets knocked out of the top k items shown in a module. You may have any number of reasons for wanting to ensure equitable exposure among your item population, which makes this a potential issue.

The paper’s exposure-aware arm selection (EARS) algorithm attempts to ensure that a probability of an item being clicked is proportional to its relevance and not unduly confounded by extraneous exposure effects. The math gets a bit above my pay-grade, but the experimental results on Deezer’s carousel dataset suggested that EARS improves equitable exposure with minimal impacts to expected reward. There’s even a hyperparameter to control the fairness-reward trade-off.

Cold start similar artists ranking with gravity-inspired graph autoencoders

Presented by Guillaume Salha-Galven from Deezer. Paper at ACM and Arxiv.

This paper tackles the task of generating a “similar artists” module for new artists on Deezer, who have metadata but few streams.

The authors formulate the problem as a weighted, directed graph of top-k similar artists, and they want to predict edges linking to the cold-start nodes. A graph autoencoder is used to learn graph embeddings from the topology of the graph and the artist features, but graph autoencoders are typically for undirected graphs, learning a metric space where d(x,y)=d(y,x) for any pair of items.

To adapt the method for their directed graph, they learn a vector and a mass for each node, where directed edges are modeled as accelerations due to “gravity” and popular artists end up having larger mass. This makes sense: the Beatles might be a top similar artist for many artists, but there’s a high bar to make it into the similar artists list for the Beatles. I thought this was a particularly intuitive and clever solution and according to the paper it beat a long list of baseline approaches.

Reverse maximum inner product search

Presented by Daichi Amagata from Osaka University. Paper at ACM and Arxiv.

Many recommender systems are variants of matrix factorization or other factorized models: you learn a vector for the user, a vector for the item, and the score for that pair is the dot-product of those vectors. We can take a user vector, multiply it by the entire item matrix, and rank the scores to get an ordered list of recommendations for that user.

But what if you’ve got a new item vector and you want to know which users would have that in their top k recommendations (to know how well a product might perform, or who to market it to)? You could generate the top recommendations for every user, but that’s expensive. This is the gist of the reverse maximum inner product search problem.

The paper proposes an algorithm for doing this quite quickly, without any approximation. I’ll leave the heavy-lifting to the paper, but the trick is to avoid computing the full top-k result set by building a data structure to support computing upper- and lower-bounds on the kth largest inner product for a user. The end result is miles faster than any other exact solution…mostly because the alternatives all involve solving the (forward) maximum inner product search problem for every user.

Given the prevalence of factorized models for recommendation, this seems like a very promising tool to have.

Transformers4Rec

Presented by Gabriel de Souza Pereira Moreira from NVIDIA, with co-authors from NVIDIA and Facebook. Paper at ACM and Facebook Research, with a blog post on Medium and code on Github.

I am not an expert in NLP and I will not attempt to explain attention and transformers to you (though here’s a good walkthrough if you want one). If you’ve heard folks talking about the incredible things that BERT and GPT-3 can do, well the T in those names stands for transformers.

Transformers operate on sequential data, which is a natural fit for language (i.e. sequences of words), but has now been adapted for sequential recommendation contexts: given a sequence of user-item interactions, predict the next item that the user will interact with. Since transformers have quickly become the de facto backbone of the latest state of the art in language models, we shouldn’t be surprised to find that this paper boasts wins in the WSDM and SIGIR recommendation challenges.

Given the model performance, the pedigree of the NVIDIA and Facebook, and the fact that they offer Tensorflow and PyTorch implementations, I suspect that we’ll be seeing a lot of Transformers4Rec in new sequential recommenders and various deep learning architectures for recommendation.

Two talks on theory

Two of my favorite talks were both presented by Minmin Chen, from the Google Brain team.

The first talk creates a foundational framework for discussing exploration in recommender systems (which is also the name of the paper). Chen breaks this down into system exploration (surfacing tail content content to benefit content providers and to improve the model), user exploration (discovering serendipitous content for users), and online exploration (reducing model uncertainty on rarely seen items without hurting the user), and she offers ideas on how to measure each of these facets.
The second talk, Values of user exploration in recommender systems, elaborates on the user exploration facet. The authors performed offline and online tests on several REINFORCE-based models which emphasize exploration and measured results for accuracy, diversity, novelty, and serendipity. The paper does a great job building on the principles laid out in the previous paper and putting them to work by demonstrating value on real users.

Other talks of note

At the risk of outlining every single talk from the conference, below I list just a few more talks that all deserve a look for one reason or another.

Explainable attribute-aware item-set recommendations from Yang Li et al at Amazon. This paper shows off a model which generates a module of similar recommended items alongside relevant attributes that the user might want to compare between them (see image above). It’s one thing to hand-pick the attributes to show if you’re a small retailer with only a few types of goods, but Amazon needs a solution that can adapt to basically any type of product. Also available from Amazon.
Recommendation on live-streaming platforms: Dynamic availability and repeat consumption from Jérémie Rappaz and his colleagues at EPFL and UC San Diego. Live-streaming platforms like Twitch are becoming one of the largest sources of video content, and this paper discusses some of the unique challenges they pose for recommendation. In particular, recommenders must learn to recommend intelligently among the streamers currently broadcasting and understand dependencies between them. Also on the author’s website.
I’ve seen a lot of talk about Negative interactions for improved collaborative filtering: Don’t go deeper, go higher from Harold Steck and Dawen Liang from Netflix. The paper contributes to the ongoing conversation around the extent to which deep learning has been or will be useful for recommendation (as did another paper this year). I don’t have a horse in that race, but I found the choice of model inputs (using a user’s previous items and item pairs as inputs) clever, and I particularly like the fact that they focused on inputs that led to negative scores—learning these types of anti-recommendations is often difficult for many traditional models.
Page-level optimization of e-commerce item recommendations from Chieh Lo et al from eBay. I mostly like this paper because it focuses on an atypical recommendation setting: personalizing the modules on an item display page. The page is even modeled as a sequence of modules with an RNN. The paper’s got offline and online experiments, a detailed end-to-end architecture, and real-world results: 2.48% increase in click-through and 7.34% increase in purchase-through. Also on Arxiv.
Burst-induced multi-armed bandit for learning recommendation from Rodrigo Alves et al at TU Kaiserlautern. This paper adds a neat twist to the context-free multi-armed bandit by accounting for “bursty” activity (e.g. tons of searches for David Bowie after his death). The bandit has a stationary distribution it updates for ordinary activity, but switches to modeling a separate burst distribution when unusually high activity is detected.

I loved getting to hear a wide variety of perspectives on issues in recommendation and I’m looking forward to attending next year, ideally in person.

Watch this space

2021-06-01T00:00:00-04:00

Eye of Maria Miles Heyward (c. 1802) by Edward Greene Malbone, via the Metropolitan Museum of Art.

Pretty soon I’ll be launching a new blog around these parts, so keep your eyes peeled. If you want to make sure you don’t miss out, feel free to subscribe to the RSS feed.

See you soon.