In which game theory turns out to be far more interesting than I had thought...
I know this is divergent from the usual subject matter, but I've found it very interesting this past week as a way to model the decision-making process from a very high level. I needed a way to represent the way that in ticketing systems (systems used to assign tasks and their priority in large companies), the priorities of an average assigned task always rise to the maximum allowed, making it eventually impossible to prioritize. For instance, we instituted a new one about 5 months ago in the department where I work. We're not huge, maybe 15-20 people, and another 10 people who can ask us to do things directly. We all know each other, and we're all fairly good at understanding systems. (Most of us are reverse engineers)
When it began, the average priority for a new ticket was 50 on a scale of 0-99. This is because it was the default setting. By now, the average priority of my tickets is in the high 80's, and my top four are all 99. It is to a certain extent obvious why this happens, but I wanted a better way of describing it, so I started reading Wikipedia and then found http://web.mit.edu/14.12/www/. (I love MIT's openness) Now I can talk about the way that in the zero-sum ticketing system game, players have access to complete but imperfect information. They are aware that every player is capable of altering their input in a way that will increase the amount of time (this system's resource in demand) in a manner that reduces the average utility of all other players. This is achieved by selecting a higher number than they think the other players will pick. A player does not, however, know which numbers other players have picked, and so in an attempt to increase their utility, they have to pick numbers higher than what they think everyone else will have picked, knowing that if the other players are rational, they will have picked high numbers in order to maximize the amount of time they get from the person to whom they are assigning work. With perfectly rational players, this leads instantly to the system's only stable state - where all players choose the maximum possible priority for all tickets. This ends up with an exactly even distribution of time, which turns out to be both a terrible way to prioritize, and mentally quite difficult as the number of tickets increases...in the end the priority of a given ticket in the system most often ends up being ignored, because once all players stabilize at the same input, the number ceases to contain any meaningful information, and its utility to the person on the receiving end drops to nothing. And there's probably a way to model that too. :)
What's particularly nifty is that I now have a way to test ideas on how to prevent this stabilization at maximum priority. Offering perfect information would perhaps slow the procession towards the stable state, since a given player would only have to beat all previous players, and might not need to immediately jump to the maximum, but the system still ends up in the same useless place.
It might help to punish players who escalate their input without meeting some set criteria which occurs less than p percent of the time, and from what I've been reading game theory offers a way to determine if there is a value for p which would shift the stable state, and where the different values of it would shift the state.
Another way would be to prevent access to complete information on the part of the players - essentially to prevent them from knowing how to maximize the time spent on their projects. This could be done by having them answer certain questions about a ticket which are then passed to an intermediary agent (either a person or a program) who attempts to assign priorities based on the current goals of the group, the deadlines for each piece, etc. Assuming that the abstraction was effective enough to keep players from discerning a winning strategy, then I think this might prevent stabilization at any particular point, which might actually be what we want, because that way priorities can be made to deal directly with the immediate situation, without having to work counter to natural systemic tendencies.
Anyway, hopefully by the end of the weekend or sometime next week I'll have a better idea how to formally represent all this and prove my ideas. Fun times! :)
When it began, the average priority for a new ticket was 50 on a scale of 0-99. This is because it was the default setting. By now, the average priority of my tickets is in the high 80's, and my top four are all 99. It is to a certain extent obvious why this happens, but I wanted a better way of describing it, so I started reading Wikipedia and then found http://web.mit.edu/14.12/www/. (I love MIT's openness) Now I can talk about the way that in the zero-sum ticketing system game, players have access to complete but imperfect information. They are aware that every player is capable of altering their input in a way that will increase the amount of time (this system's resource in demand) in a manner that reduces the average utility of all other players. This is achieved by selecting a higher number than they think the other players will pick. A player does not, however, know which numbers other players have picked, and so in an attempt to increase their utility, they have to pick numbers higher than what they think everyone else will have picked, knowing that if the other players are rational, they will have picked high numbers in order to maximize the amount of time they get from the person to whom they are assigning work. With perfectly rational players, this leads instantly to the system's only stable state - where all players choose the maximum possible priority for all tickets. This ends up with an exactly even distribution of time, which turns out to be both a terrible way to prioritize, and mentally quite difficult as the number of tickets increases...in the end the priority of a given ticket in the system most often ends up being ignored, because once all players stabilize at the same input, the number ceases to contain any meaningful information, and its utility to the person on the receiving end drops to nothing. And there's probably a way to model that too. :)
What's particularly nifty is that I now have a way to test ideas on how to prevent this stabilization at maximum priority. Offering perfect information would perhaps slow the procession towards the stable state, since a given player would only have to beat all previous players, and might not need to immediately jump to the maximum, but the system still ends up in the same useless place.
It might help to punish players who escalate their input without meeting some set criteria which occurs less than p percent of the time, and from what I've been reading game theory offers a way to determine if there is a value for p which would shift the stable state, and where the different values of it would shift the state.
Another way would be to prevent access to complete information on the part of the players - essentially to prevent them from knowing how to maximize the time spent on their projects. This could be done by having them answer certain questions about a ticket which are then passed to an intermediary agent (either a person or a program) who attempts to assign priorities based on the current goals of the group, the deadlines for each piece, etc. Assuming that the abstraction was effective enough to keep players from discerning a winning strategy, then I think this might prevent stabilization at any particular point, which might actually be what we want, because that way priorities can be made to deal directly with the immediate situation, without having to work counter to natural systemic tendencies.
Anyway, hopefully by the end of the weekend or sometime next week I'll have a better idea how to formally represent all this and prove my ideas. Fun times! :)
posted by PredictionsOfMemory | 12:17 PM
0 Comments:
Post a Comment
<< Home