5.1 Overview
We can think of a recommender system as a two-sided market in which the recommendation opportunities that arise from the arrival of a user
\(u\in \mathcal {U}\) to the system, and each are allocated to a set of items
\(v\in \mathcal {V}\) from the system’s catalog. This market has some similarities to various forms of online matching markets including food banks [
2], kidney allocation [
4,
35], and ride sharing [
19] in that users have preferences over the items; however, in our case this preference is known only indirectly through either the prior interaction history or a recommendation function. Additionally, the items are not consumable or rivalrous. For example, a loan can be recommended to any number of users—it is not “used up” in the recommendation interaction.
7 Also, users are not bound to the recommendations provided; in most online platforms including Kiva, there are multiple ways to find items, of which the recommender system is only one.
Once we have a collection of fairness agents we must solve two interrelated problems:
(1)
What agent(s) are allocated to a particular recommendation opportunity?
(2)
How do we balance between the allocated agents and the user’s individual preferences?
We assume a recommendation generation process that happens over a number of timesteps t as individual users arrive and recommendations are generated on demand. Users arrive at the system one at a time, receive recommendations, act on them (or not), and then depart. When a user arrives, a recommendation process produces a recommendation list \(\ell _s\) that represents the system’s best representation of the items of interest to that user, generated through whatever recommendation mechanism is available. We do not make any assumptions about this process, except that it is focused on the user and represents their preferences. A wide variety of recommendation techniques are well studied in the literature, including matrix factorization, neural embeddings, graph-based techniques, and others.
The step of determining which fairness concerns/agents will be active in responding to a given recommendation opportunity is the
allocation phase of the process, the output of which is a set of non-negative weights
\(\beta\), summing to one, over the set of fairness agents, indicating to what extent each fairness agent is considered to be allocated to the current opportunity [
7].
Once the set of fairness agents have been allocated, they have the opportunity to participate in the next phase of the process, which is the choice phase. In this phase, all of the active (non-zero weighted) agents and their weights participate in producing a final list of recommendations for the user. We view the recommender system itself as being an agent that is always allocated and therefore always participates in this phase.
Figure
2 shows the allocation phase of this process. This is an online and dynamic allocation problem where we may consider many factors including the history of agent allocations so far, the generated lists from past interactions with users, and how fair the set of agents believes this history to be. As described in Section
5.2 below, agents take these histories and information about the current user profile and calculate two values:
m, a measure of fairness relative to their agent-specific concern, and
c, a measure of compatibility between the current context and the agent’s fairness concern. The allocation mechanism takes these metrics into account producing a probability distribution over the fairness agents that we call the
agent allocation, which can be interpreted as weights in the choice stage or be used to select a single agent via a lottery, e.g., a randomized allocation scheme [
8].
In the second phase, shown in Figure
3, the recommender system generates a list of options, considered to represent the user’s preferences. The fairness concerns generate their own preferences as well. These preferences may be global in character, i.e., preferences over all items, in which case they may be independent of what the recommender system produces; we call this a recommendation function below. Or, as indicated by the dashed line, these preferences may be scoped only over the items that the recommender system has generated; named a scoring function. In either case, the preference function of the fairness agent, like the one for the user, generates a list of items and scores. The choice mechanism combines these preferences of both the user and fairness agents, along with the allocation weights of the fairness agents, to arrive at a final recommendation list to be delivered to the user. The list itself, and possibly the interactions the user has with it, becomes a new addition to the choice history and the process continues for the next user. Because the output of the base recommender system
\(\mathcal {R}_x\) is an input to this phase, we can think of the entire process as one of fairness-aware re-ranking.
5.3 Formal Description
In our formalization of a recommendation system setting we have a set of n users \(\mathcal {U}= \lbrace u_1, \ldots u_n\rbrace\) and a set of m items \(\mathcal {V}= \lbrace v_1, \ldots , v_m\rbrace\). For each item \(v_i \in \mathcal {V}\) we have a k-dimensional feature vector \(\phi = \langle \phi _{1}, \ldots \phi _{k} \rangle\) over a set of categorical features \(\phi\), each with finite domain. Some of these features may be sensitive, e.g., they are associated with one or more fairness agent concerns, we denote this set as \(\phi ^{s}\). Without loss of generality, we assume that all elements in \(\mathcal {V}\) share the same set of features \(\phi\). Finally, we assume that each user is associated with a profile of attributes \(\omega = \langle \omega _{1}, \ldots \omega _{j} \rangle\), of which some also may be sensitive \(\omega ^{s} \subseteq \omega\), e.g., they are associated with one or more fairness agents.
As in a standard recommendation system we assume that we have (one or more) recommendation mechanisms that take a user profile \(\omega\) and a (set of) items v and produces a predicted rating \(\hat{r}\in \mathbb {R}_+\). We will often refer to a recommendation list, \(\ell = \langle \lbrace v_1, \hat{r}_1\rbrace , \ldots \lbrace v_m, \hat{r}_m\rbrace \rangle\), which is generated for user \(\omega\) by sorting according to \(\hat{r}\), i.e., \(sort(\mathcal {R}_x(\omega , \mathcal {V})) \rightarrow \ell\). Note that this produces a permutation (ranking) over the set of items for that user, i.e., a recommendation. As a practical matter, the recommendation results will almost always contain a subset of the total set of items, typically the head (prefix) of the permutation up to some cutoff number of items or score value. For ease of exposition we assume we are able to score all items in the database.
In the SCRUF-D architecture, fairness concerns are “embodied” as a set of d agents \(\mathcal {F}= \lbrace f_1, \ldots , f_d\rbrace\). For the agents to be able to evaluate their particular concerns, they take account of the current state of the system and voice their evaluation of how fairly the overall system is currently operating, their compatibility for the current recommendation opportunity, and their preference for how to make the outcomes more fair. Hence, each fairness agent \(i \in |\mathcal {F}|\) is described as a tuple, \(f_i = \lbrace m_i, c_i, \mathcal {R}_i\rbrace\) consisting of a fairness metric, \(m_i(\vec{L}, \vec{H}) \rightarrow [0,1]\), that takes a choice history \(\vec{L}\) and allocation history \(\vec{H}\) and produces a value in \([0,1]\) according to the agent’s evaluation of how fair recommendations so far have been; a compatibility metric, \(c_i(\omega) \rightarrow [0,1]\), that takes a particular user profile \(\omega\) and produces a value in \([0,1]\) for how compatible fairness agent i believes they are for user \(\omega\); and a ranking function, \(\mathcal {R}_i(\omega , v) \rightarrow \lbrace v, \hat{r}\rbrace\), that gives the fairness agent preferences/ranking over the set of items.
In the allocation phase (Figure
2), we must allocate a set of fairness agents to a recommendation opportunity. Formally, this is an allocation function,
\(\mathcal {A}(\mathcal {F}, m_\mathcal {F}(\vec{L}, \vec{H}), c_\mathcal {F}(\omega)) \rightarrow \beta \in \mathbb {R}_{+}^{|\mathcal {F}|}\) that takes a set of fairness agents
\(\mathcal {F}\), the agents’ fairness metric evaluations
\(m_\mathcal {F}(\vec{L}, \vec{H}) = \lbrace m_1(\vec{L}, \vec{H}), \ldots , m_d(\vec{L}, \vec{H})\rbrace\), and the agents’ compatibility metric evaluations
\(c_\mathcal {F}(\omega)\) and maps to an agent allocation
\(\beta\), where
\(\beta\) is a probability distribution over the agents
\(\mathcal {F}\). The allocation function itself is allocating fairness agents to recommendation opportunities by considering both the fairness metric for each agent as well as each fairness agent’s estimation of their compatibility.
The allocation function can take many forms, e.g., it could be a simple function of which every agent voices the most unfairness in the recent history [
51], or it could be a more complex function from social choice theory such as the probabilistic serial mechanism [
6] or other fair division or allocation mechanisms. Note here that the allocation mechanisms is directly comparing the agent valuations of both the current system fairness and compatibility. Hence, we are implicitly assuming that the agent fairness evaluations are comparable. While this is a somewhat strong assumption, it is less strong than assuming that fairness and other metrics, e.g., utility or revenue, are comparable, as is common in the literature [
66]. So, although we are assuming different normalized fairness values are comparable, we are only assuming that fairness is comparable with fairness, and not other aspects of the system. We explore options for the allocation function in our empirical experiments below. We track the outputs of this function as the allocation history,
\(\vec{H}= \langle \beta ^1, \ldots , \beta ^t \rangle\), an ordered list of agent allocations
\(\beta\) at time
t.
In the second phase of the system (Figure
3), we take the set of allocated agents and combine their preferences (and weights) with those of the current user
\(\omega\). To do this we define a choice function,
\(\mathcal {C}(\ell , \beta , \ell _\mathcal {F}) \rightarrow \ell _\mathcal {C}\), as a function from a recommendation list
\(\ell\), agent allocation
\(\beta\), and fairness agent recommendation list(s)
\(\ell _\mathcal {F}\) to a combined list
\(\ell _\mathcal {C}\). Each of the fairness agents is able to express their preferences over the set of items for a particular user,
\(\mathcal {R}_i(\omega , v) \rightarrow \lbrace v, \hat{r}\rbrace\), and we take this set of lists,
\(\ell _\mathcal {F}= \lbrace \mathcal {R}_1(\omega , \mathcal {V}), \ldots , \mathcal {R}_i(\omega , \mathcal {V})\rbrace\), as input to the choice function that generates a final recommendation that is shown to the user,
\(\ell _\mathcal {C}\).
We again leave this choice function unspecified as this formulation provides a large design space: We could use a simple voting rule, a simple additive utility function or something much more complicated like rankings over the set of all rankings [
7]. Note that the choice function can use the agent allocation
\(\beta\) as either a lottery to, e.g., select one agent to voice their fairness concerns, or as a weighting scheme. We investigate a range of choice functions in our experiments. For the fairness agents to be able to evaluate the status of the system we also track the choice history,
\(\vec{L}= \langle \ell ^t, \ell ^t_\mathcal {F}, \ell ^t_C \rangle\), as an ordered list of user recommendation list
\(\ell\), agent recommendation list(s)
\(\ell _\mathcal {F}\), and choice function output lists
\(\ell _\mathcal {C}\), indexed by timestep
t.