17923
>> Eric Horvitz: Ece is a Ph.D. candidate in the School of Engineering and Applied Science at Harvard
University, working with our colleague, Professor Barbara Grosz there. She's been exploring some
interesting topics and challenges at the intersection of core AI agents in HCI. In particular, looking at
notions of how computers can reason about and support teamwork in mixed networks.
And Ece was a Microsoft Research Fellow here, and she was a two-time intern, each time doing two or
three projects. And one would have been great. And it's been a pleasure to get to know Ece. And this is
going to be a job talk today.
>> Ece Kamar: Thank you, Eric. Thank you for the nice introduction. And thank you for coming to the talk.
It's a pleasure to be here today again for the third time, and this time talking about the research I've been
doing for the past few years at Harvard University.
Today's talk is about making collaboration work in real life. Collaboration is a special kind of group activity
in which participants come together and try to accomplish something that they cannot do alone easily.
We see examples of collaboration in our everyday life. One example is when we cook dinner with our
friends or when we go to them to a concert, we see different artists playing different instruments but
contributing to the same musical piece.
And our example is sports games, we see different players with different capabilities playing at different
positions but having the same goal of winning the game at the end of the day.
There are also more organizational structures and dynamic examples of collaboration. Rescue themes is
one example. The other one is many people working in these big companies contributing, big companies
like Microsoft contributing to the next big software product.
Lately, with increasing connectivity, we started to see different examples of collaboration. We started to
see collaboration between people that are located at different parts of the world and between people that
are not connected with social or organizational structures but still contributing to generate something big.
Wikipedia is one of my favorite examples for showing how much value we can generate by the
collaboration of people. Another nice example is looking at home projects by the University of Delaware
and Berkeley that motivates people to donate their idle time on their computers to solve some
computationally expansive research problems.
However, still in these systems that are assisted by computers, these collaborations are assisted by
computer systems, computers are naturally taking part in this collaboration. They don't have incentive to
help this collaboration much or they are not solving a piece of this collaboration.
So in today's computer systems, people have -- computer agents have -- computer systems have better
interfaces. They have more computational power. They know more about each other and about the world.
But, still, at the deeper problem-solving level, we need to tell these computer systems what to do and when
to do it.
One such interaction is the search engines. When I type an ambiguous word like "Turkey", where I'm from,
to Google search engine, it gives me all these different precomputed fixed answers. The system doesn't
know about the context I'm in and my intentions why I'm doing this search.
So it doesn't really help me to accomplish my task easier. It's just giving me a precomputed answer.
Another example is these error screens, the computer is notifying the user a big problem happened in the
computer but it's not easily readable message, but in fact the computer agent is capable of going into the
computer system, solving the problem for the computer system, and taking the initiative but it's not doing
that.
This is why I believe that if you can have computer agents that are partners that are not servers we can
improve the efficiency of computer systems.
In fact, even in today's systems, computers are no longer alone. They act in mixed complex networks with
other computer agents and people. In these mixed networks, each participant has diverse needs. They
have diverse information about the world and about each other. This is why we need collaborative
teamwork models that will bring these diverse partners together to accomplish something.
I believe that having these computer agents as partners in the future will have a lot of potential to bring
people together so that they can work more effectively and also to build computer systems that can interact
with people better and also have to solve some key problems of today's such as traffic, energy allocation,
information overload.
The talk I'll be giving today will address some key challenges in building these computer agents that can
work effectively with people. The first part of the talk will focus on representations and decision theoretic
models for building agents that can work effectively with people. And then I will show how we can use
these representations and decision theoretic models to manage household behavior and communication
better in collaborative activities.
In the second part of the talk, I will show you what happens if we have people in the loop and how people
perceive these utilities as computed by these computational models. And I will conclude my talk with a real
world application of collaboration.
There's been work on collaboration by formally defining what collaboration is. One such model is joint
intentions proposed by Cohen and Levesque. Another one is [indiscernible] proposed by Barbara Grosz
and Kraus. What these models do is they in detail define the requirements to have a good successful
teamwork.
They are all vertical models. They don't have notions of cost and utilities and probabilities. This is why
they define new requirements for a while but it's very difficult to apply them to real life.
There's been some work on getting these models and deploying them into real world. [indiscernible]
worked on this. He tried to apply these formulaisms into military training and [indiscernible] domains, but
his approach is domain-specific and doesn't generalize to many domains we see in real life.
My work is based on the shared platform. This is why I want to give you a quick summary of the
requirements that it states to have a successful collaborative activity.
The first requirement is bringing agents together and forming groups that will work together. The second
requirements are interleaved. It's about how agents, given that they come together, how can they divide
tasks among each other so that each participant can go plan apart from its own part of the plan.
One important observation here is that the agents do not require to know what partners are doing. They
are just obligated to plan for their own task and accomplish it successfully.
However, there's a fourth requirement. The fourth requirement says that collaboration is more than these
agents divide their task and then performing their own parts. But they still need to reason about what their
partners are doing and support each other when needed, because collaboration is more than the sum of its
individual parts.
So the focus of this part of the talk is designing decision making strategies for supporting the supportive
behavior and collaborative activities given that we have answer [indiscernible] information in the real world.
Let's visit an example of a complex mixed network that we can have in real life. Here we have a person
driving in traffic and he's connected to a computer agent that knows a lot about this person, this computer
agent has access to the person's calendar. It has access to traffic prediction services and satellites. And
this computer agent is helping this person about making this commute much more effective by the mobile
opportunistic planning or informing the person about some surprises that might happen in the traffic.
The person might be also connected to a different computer agent that is scheduling his meeting for the
next day. And at the same time the person's talking with his colleague on the phone and these computer
agents might be connected to another agent that is working at home to coordinate for dinner plans.
These complex mixed networks have different characteristics that they have some important
characteristics. First of all, the participants are distributed. They have partial information about the world
and about what each other is doing.
But still they need to reason about their partners so that they can help each other when needed. Through
this talk I will be focusing on one particular example of mobile opportunistic planning. This example is
influenced by work I've done with Eric Horvitz and Christopher Meek. And this system is called mobile
opportunistic planning. In this system we have a computer agent that is learning about the products that
the user is interested in. And while the user is driving searches the area looking for some good deals for
the person and generating mobile opportunistic plans for these users.
So here in this example we have a collaboration between the person that is driving on the way and also the
computer agent that is doing mobile opportunistic planning. This person and the agent are collaborating to
have the most effective commute as possible.
Here the person picks a plan. He has multiple choices if he's going from Redmond to Kirkland, he might
choose to take Redmond Way or I-405. Similarly, the computer agent can come up with multiple options
for this person. One might be a gas station. Another is stopping at a different gas station. The third one
might be a combination of a gas station and grocery store.
So in this collaboration the agents has partial information about what this person is doing because the
person cannot really tell what he's planning to do at each step. It's too distractive. The person picks a
plan. He might pick the Redmond Way plan and the computer agent may have a belief about the plan that
this person is choosing.
The agent might believe that this person is likely to take the Redmond Way with 90 percent chance, with 10
percent chance he might take the highway.
So we need representations to represent this agent's uncertainty about the probable plans that the partners
are doing and also we need decision theoretic models that will work given this belief and uncertainty.
Here I'm proposing a probabilistic representation called probablistic trees. That will be a solution to this
problem.
In this representation, the top node is the collaborative plan that these participants are collaborating on.
Then this collaborative plan decomposes into subtasks of this plan. This might be driving and the other
might be mobile opportunistic planning.
And then each task stochastically decomposes into possible plans for doing this activity. Here, these
probabilities on these branches represent the likelihood that this agent who is doing this task is doing this
plan.
And I reopen this tree until we have all basic level tasks on the leaves. So it's a hierarchical representation
that is showing agents' beliefs about what their partners are doing.
So here we have a probabilistic repository for the mobile opportunistic planning example showing the
agent's belief about the evening commute plan. Here, the evening commute plan branches into subtasks
which are driving and opportunistic planning and driving tasks stochastically branches into possible plans
for doing this task which are Redmond Way and I-405. And here the basic level tasks are the short
fragments that the user needs to drive.
We can also represent constraints on these PRTs. For example, these two tasks are sharing the same
resource of a person, so they are connected with the resource constraint. And then the basic level task
may have some time constraints between them.
So here now I showed you a representation for agent's beliefs. Now I will show you that we can use this
representation to reason about the utility of probabilistic plans. The important thing is by having these cost
and utilities and utility calculations on these PRTs, now we will be able to enable decision theoretic
reasoning on these vertical teamwork models. So how do we do that?
We insert cost and success probabilities to the leaves of this probabilistic repository. They represent the
cost of doing a basic level action and success probability of a basic level action. The agents are able to
estimate these things and I will show you an example of how they can do so.
Then to capture the cost and success probability of a plan, we propagate these cost and success
probabilities to upwards. So the cost of a plan is the summation of the cost of the basic level tasks.
Similarly, the success probability of a plan is the product of the success probability of the children.
So here we have a way to calculate the cost and utilities of plans. Similarly, we can propagate these cost
and success probabilities from the plan level to the task level. So here the success probability on cost of a
task is the weighted average of the success probabilities and cost of the children. And, finally, when we
reached the top level, which is the collaborative activity that these participants are collaborating around,
now we are able to predict expected utility of accomplishing this plan. It is the value that these participants
have to see this collaborative activity being performed times the success probability of the collaborative
plan minus the cost.
>>: So in the example, you're branching on the drive versus the ancillary activities with -- I'm assuming
probabilities but you can imagine an agent convincing the user to change their plan so some of the tasks
might be on the agent side generated alternative and convince the user that this is a better idea, thus the
opportunity part of it and folding -- convincing the probability of change into the actual model. Do you have
that in there or do you start a new probability [indiscernible] as goals.
>> Ece Kamar: I would have operations to modify these PRTs in real time, and also decision theoretic
rules about when they need to communicate meshed plans to have a more successful plans and how
agents can learn about what the person is doing in real time and how they can convince. And I will share
both points in the next slides.
So you can ask, okay, it's nice to have these basic level cost and success probabilities, but where do these
probabilities come from? Here I will show you how we can extract this knowledge for this mobile
opportunistic planning example. In fact, to act in a world like this and help people, the computer agents
already have access to a lot of information about the people in the world.
It knows the calendar, have access to clear flow to get the live prediction and may access to the time cost
function for this person.
So when this computer agent needs to relate the probabilistic plan, it looks like the basic level action. So
here the basic level actions for the driving task are the short fragments the user needs to drive. So to get
how long it takes to drive on Redmond Way, it can access the clear flow and get these values. And then
access to the time cost function to get a dollar value for these basic level actions.
Similarly, to estimate the cost of doing different mobile opportunistic plans, the computer agent can use the
cost analysis components of the mobile opportunistic planning system and can guess the divergent cost for
going to a grocery store, spending time there, including the fuel that will be spending and also the time
they'll be spending.
To get these probabilities on these branches, in this example the computer agent can access to the
predestination system. This is the work by John Cohen and Eric Horvitz to predict where the user is going
at a given particular time.
But as Eric pointed out a few minutes ago, these rules are not static. They will be changing in the real
world. This is why I define operations that can modify PRTs. One way of modifying a PRT is editing a new
task and at the end we end up with an updated plan with a new task added to it. Another way of updating a
PRT is subtraction where we decide not to do a part of the plan, get rid of it and have come up with an
updated plan with less, in which we have less to do.
Another way of updating a PRT is replacement. We take a part of the PRT and we predict what a new way
can be for doing that task. For example, the agent may convince the person that taking the highway is a
better option than Redmond Way, so we can see these probabilities changing. We put this updated plan
here and come up with an updated plan for the collaborative activity.
So the nice thing about PRTs is if you have some good independence relations between the task, then they
are very efficient. They are modular because we can just get some part of it, change something about it,
plug it in, without changing the different parts of the PRT.
So here I show you this nice representation and I also show you that we can estimate utility of a plan, then I
will show you how we can reason by using PRTs.
>>: Is the list of tasks that's underneath each plan deterministic given the plan?
>> Ece Kamar: Yeah, not really talking about what kind of planning algorithms you can use to get PRTs.
The only requirement is the agent should have access to a planning algorithm that will predict what the
user will be doing.
>>: But let's say I have a plan, like I'm looking at the Redmond Way and there may be more than one way
to break it down breaking it down to different tasks there are a lot of routes I can take. So can you
represent that?
>> Ece Kamar: You can also have another level of stochastic branching that is the composing this
Redmond Way plan to all different plans for doing the Redmond Way plan.
You can open this tree as much as you can and you can have different levels of stochastic branchings from
plans, to different plans of different tasks.
So here I will show you different ways we can reason using PRTs. One possible way is commitment
reconciliation. So here we have a PRT and the agent reasons about adapting or abandoning a
commitment. An example is the computer agent's reasons about whether we should pick up a passenger
on the way and do a carpool rather than sticking with our original plan. And here the computer agent can
put this new updated plan in, see how it changes the rest and get an expected utility for doing this new
plan, with respect to the old one.
Another way we can use PRTs is for measuring plans. It's exactly what Eric mentioned. Here the
computer agents have a probabilistic belief for what the team is doing and then the computer agent can
reason about how this plan should change given this new information about the world. Here if the
computer agent observes that the person is taking a different route than expected, the computer agent can
use this representation to update part of the plan or to communicate with the agent, the person to motivate
him to update his part of the plan.
Another possible way is to reason about the future to estimate the expected utility of this plan in the real
world. Agents can also use this for coordination. And the part I will be focusing on will be for managing
helpful behavior including communication decisions.
So here I will show that we can use these PRTs to build decision theoretic models for managing helpful
behavior and I will empirically show that by having these decision theoretic models we can improve the
performance of teamwork.
So these behavior models are decision theoretic rules about when agents need to help people. The main
idea is really simple. It says that the agent should calculate the expected utility of helping and help if the
utility is bigger than the cost.
One way of helping is communicating. The agents can help people by informing them about an
observation or responding when they ask for an observation. And another way of helping is performing a
helpful act. For example, in the mobile opportunistic planning domain, the agent realizes there is big traffic.
The person will be late to the next meeting, the computer agent can take the initiative, send a message to
the person that the user is supposed to meet in half an hour, a very helpful act.
So just to show an example of how informed decisions work for this mobile opportunistic planning domain,
here is the computer agent finds out that there's a big traffic, there's an accident on Redmond Way and
there's traffic on Redmond Way. And now the agent is reasoning about interrupting this person with this
new information given that the person will have some big cost of interruption for getting this message.
Here the computer agent will capture the expected utility of informing compared with the interruption costs.
So how does the agent do this? First, the computer agent reasons about the original plan that these
participants are doing. Here the person is likely to take the Redmond Way and the expected duration for
this plan is 90 minutes.
Next, the computer agent reasons about how the expected utility of this plan changes given this new
information about the world. So here we see that the cost of taking the Redmond Way increases a lot, and
the expected duration of this plan increases to 48 minutes.
Next, the agent reasons what will happen if the person is notified about the surprise? Here the person will
update the plan so that he wouldn't take the Redmond Way anymore, he will take the highways not to get
stuck in the traffic. And here the expected duration of this new updated plan will be 28 minutes.
So putting all these together to make an informed decision, the computer agent compares the expected
utility of the original plan with the updated plan that will be created after this informed action, compared with
the cost of interruption, and inform if the utility gain we get from this informed action is larger than the cost
of interruption.
>>: How does the agent know when the update [indiscernible] are after the formation? I mean, here it's
very clear. But in general it could be someone is [indiscernible] and that the agent might tell you about
something, how do I know when to release when?
>> Ece Kamar: So the computer agent has a way to predict what the person is doing, which plan the
person's taking. It is an assumption we are making to implement probabilistic repositories in the first place.
And the computer agent also have an estimate for the context that the person is working on, what the
person is believing. So in fact the computer agent uses its belief about the person and the planning
algorithm to get this part of the plan.
>>: So I think what John's asking is what's the -- if you work in the perception that's a box, I'll give you
these things [indiscernible] how might you build that box? Is that going to be a hard challenge to come up
with the probability some day? Is it a machine learning problem?
>> Ece Kamar: It is a combination ->>: I'm curious like how do you decide 0.0 or 1.0? We give them this information and they do something
else.
>> Ece Kamar: So it is a combination of a machine learning and planning challenge to see given
information how the plan changes. And here I'm assuming that the computer agent have those resources
to reason about what the person is doing.
But it is something that the domain expert that is implementing these PRTs to a particular domain, he
needs to reason about how this will work.
>>: Imagine these kind of interpretations are [indiscernible] learning challenges depending on how well you
can do with those challenges, can influence [indiscernible].
>> Ece Kamar: So here the idea is given that we can predict what the person is doing and we can predict
how the plan will change given some information, we can use these PRTs to capture the expected utility of
giving this information to the user.
To empirically test these models, I designed a game on the color trails task pass system. This color trails
task pass system is a game setting that is derived by Harvard. It enables the study of task oriented group
activities. The nice thing about color trails is it abstracts away from particular task domains and can create
a nice analogy without building the characteristics of a real world domain, which is really, really expensive
to do.
And these game settings are used extensively so the various research problems such as negotiation, team
formation and reputation in many countries all over the world. And in fact they are using this game setting
to train as astronauts that will go to space these days. It's a good mediator between a very simple behavior
game such as prisoner's dilemma and more complex hard-to-implement real world domains.
So you can ask why I'm not doing these experiments on, for example, the mobile opportunistic planning
domain. First of all, it's very difficult to implement those kind of domains in real life successfully. And even
if we implement that, it's very difficult to analyze the results that we've got from that kind of a domain
because there's so many domain characteristics we need to think about, and there's a domain knowledge
that we need to reason about.
But by mapping these real world task domains to an abstract game setting, it is much easier to reason
about -- it's much easier to reason about just the problems that we want to investigate and get rid of the
domain details.
So here we have this game board and this game. We have two players that are representing the person
driving on the way and the computer agent. They are collaborating on an activity such that one player, the
supreme player is trying to get to one of the goals which may represent driving challenge, and the other
player, the observer player, is trying to get to its own goal, this might represent the mobile opportunistic
planning.
And here these agents have resources that they have to move on this game board and reach to their goals.
These resources may represent the field that the person needs to spend to go to a particular destination or
the time that this user needs to spend.
To reflect the partial information the participants might have about each other, these players are not able to
see what chips the other players have, so they really don't know which plan these agents will be taking to
get to their individual goals. And also to reflect an agent's [indiscernible] about the world. Some positions
on this game board may stochastically turn into threat positions which may prevent from these players
moving on this game board. This analogy to having a traffic condition on the way which prevents the
person from driving ahead.
So on this game setting, we observe a player is able to observe these trap locations as they appear. You
can think of this as a computer agent having access to the traffic prediction services and getting notified
when something important happens in the traffic.
But the recipient player cannot observe these stochastic events. And there are two different uncertainties
that happen in this world. One uncertainty is the observer is answering about the recipient's chips and the
other is uncertainty about the world how frequently these traps appearing in the game board.
And there are three different ways that the observer player can help the recipient by informing him about
these trap locations by responding to him if he asks about these trap locations and by giving away some
resources [indiscernible].
Here I will just show you the results I got for the communication protocols, but I have similar results I got for
comparing different half life protocols available in the papers. Here I'm comparing two decision theoristic
protocols for informing and asking. These are using PRTs to make decisions. And I'm comparing these
decision theoretic protocols to vertical protocols proposed by the previous work, because in this work the
theoretic reasoning was not possible.
So here I compare these four different communication protocols with different levels of observer
uncertainty, world uncertainty. The height of these bars represents the score that we get from these games
given that we follow these different protocols.
So here the important ->>: The score of fracture of time that the goal is reached.
>> Ece Kamar: It is a factor. And also whether the agents can achieve these rules and how many
resources they are spending to get to the goals. So it's a combination of different factors.
Here the important result is by having decision theoristic reasoning for managing helpful behavior, we are
able to improve the performance of the collaborative activity because for all communication costs
uncertainty levels, the decision theoretical protocols perform equally good compared to the axioms
because these decision theoretic protocols are able to adapt to the change and costs of uncertainties in
real life.
Another important result is we can see where one protocol is better than the other. For example, if the
uncertainty is low, it is better to inform each of them about the changes, whereas when answering these
really, really high it's better to be [indiscernible].
So in this part of the talk I presented to you a new representation for agent's beliefs about what partners
are doing. And on this representation enables decision theoretic reasoning on formal teamwork models.
And I also demonstrated that we can use this representation to build decision theoretic rules about helpful
behavior and show that we can improve the performance of the collaborative activity by doing this decision
theoretic reasoning.
So at this point you can ask, okay, we have these computational models, we have these representations,
but what happens when these computer agents use these computational models to interact with people?
Because people may not see this utility in the way that computer agents calculate them.
So the second part of the talk I will mention what happens when we have people in the loop and how they
perceive the utility that are calculated by these computational models. The previous approach that I
presented in the helpful behavior models use this flow to decide when to communicate. It first tracks the
changes and distinguishes these changes as a way, as an opportunity to communicate, and then captures
the collaborative benefit of communicating, and also if this benefit is positive.
However, when we have people in the loop, there's a different decision that the computer agent needs to
make. The computer agent also needs to reason about whether the partner is willing to communicate or
not.
Because when we have people in the loop, even if we have computer agents using the best computational
models and capturing the utility correctly, if the person is not able to see this benefit, it's just an
unnecessary disturbance for the user and the user will be unhappy with this computational system.
Going back to the mobile opportunistic planning challenge, here again we have the computer agent and the
person but this time the computer agent needs some information from the user.
For example, the computer agent may ask about what do you see in the traffic, how are you feeling? Are
you nervous? Are you busy? Can ask these kind of questions. And if we do so, if the expected utility is
larger than the cost, if the next utility is positive, however here we have the person as a black box we really
don't know what the person is doing. But we know that this person will accept some of these interruptions
and classify them as valuable and reject some of these interruptions. In this part of the talk we will try to
understand how this filter works.
To investigate this problem, I'm also using a game setting that's built on the color trails infrastructure. Here
we have these gameboards and we have two players on this gameboard. One representing the person,
the other representing the computer agent.
They have individual goals that they are trying to achieve. They come up one step at a time to get closer to
their goal location. However, these goal locations made stochastically on the gameboards representing the
answer that these players may have about the real world.
The person player is able to observe whether these goals are moving, but the agent player doesn't know
where its goal is moving. So at some times in the game the computer agent may interrupt a person and
ask where its goal is to be more successful in this game setting.
So I used a combination of the centralized MDP techniques and helpful behavior models to capture this full
iteration of expected utility of interruption.
Then in the empirical analysis, I'm comparing the human responses to this decision theoretic baseline to
see where the person perception, the first run computational models. I [indiscernible] 26 subjects from
Craig's List, housewives, college students and each subjects were given 26 cases of this interruption game.
They received 26 different interruptions. These interruptions were two factors. One is the magnitude of the
interruption outcome as computed by an oracle that knows where goals are. So this is a full iteration of
estimate of how beneficial an interruption is for the collaborative activity.
And as a second factor we investigated what is the effect of the presented partner type on the likelihood
that the people will be accepting these interruptions.
So through all these theoretic interruptions, the people were always paired with the same computer agent
that is using this full iteration estimate to make interruption decisions. But sometimes we told the subjects
that they are playing with a person sitting in the next room so that we can investigate this partner effect.
And there are two hypotheses we investigated. The first one is I believe people will be more likely to
accept interruptions if the outcome is higher. Because if it's more beneficial, so the person will be able to
see this especially in this abstract game setting and respond to interruptions respectively.
As a certain hypothesis, I believe that the people's responses will not be affected by the partner type,
because I believe utility is such a clear reason to accept or reject an interruption, the partner type should
not have an effect. My partner didn't agree with me on this. She said I believe the partner type will have an
effect because the previous work tells us that the way people see their partners affect how they collaborate
with them.
>>: Let me understand, this is one -- what you're saying beyond what people think [indiscernible] I mean,
people accept the outcomes, if the computer outcome is higher you're saying?
>> Ece Kamar: Collaborative outcome as computed by these collaborations.
>>: So it can be a measure of how well your miles are performing, right, because the due credit
assignment, you can have a bunch of reasons why that won't happen, one, for example, that people don't
understand the value to something is wrong with the model and it's less valuable than the model than the
system thinks it is. And the people who know that very well and so on. So it's many possibilities that would
influence whether this is [indiscernible] or not. That usually is verified.
>> Ece Kamar: Because we have these abstract game settings, we are able to exactly capture the
expected utility of interruption by using the centralized MDP methods and using the helpful behavior
models to get the expected utility of interruption. Because in this game setting we're able to control where
the goals are moving and where the people are and use, map this game to an MDP and capture what is the
expected utility of the state.
>>: Real people, crisis people?
>> Ece Kamar: Yeah.
>>: We don't have a model for the cost reduction, for example?
>> Ece Kamar: Given that, we assume that these people will be fully operational and be acting in a way
that these computer models predict, we're able to capture the full iteration of the baseline for the outcome.
However, here we're testing how these computational models, how well they can predict human responses
in real life.
>>: I'm still not clear. Even with this iterative model that's computing that ideal values, it could be wrong
about the estimates based upon not understanding the cost interruption in the context with the user at the
moment.
>> Ece Kamar: Oh, I forgot to mention one thing. Here in this game setting, the cost of interruption is
mapped to these players not moving for one game round. So here we are assuming there's no cognitive
cost for interruption because these people are only focusing on this game setting, they are not doing
something else. And we are mapping the cost of interruption to something about the game, about not
being able to move one game forward. Given that the cost ->>: Is that reasonable? You pay less people ->> Ece Kamar: The reason that we do it this way is so that we will be able to capture the expected utility of
interruption, currently given for this game board, and so that we can analyze where the human perception
differs from these computational models.
>>: I think what he's asking is when you get an interruption, do you lose a turn?
>> Ece Kamar: You lose a turn.
>>: I think there's the matter about the personal agenda, theoretic game and what's [indiscernible], for
example, if I have a game I'm playing, I have a goal I'm trying to achieve. You interrupt me. So would I
rationally act so I would have a high collaborative outcome versus whether I want to have my own personal
gain?
>> Ece Kamar: The game is designed so that the final score of the game is the cumulative score of the
agent and the person. So the person should be focusing on the collaborative outcome to make decisions
so it can perform better in the game. However, after I show the empirical results, I'll show that even in this
equilibrative setting, people care about their own part of the utility more than the agents. And I'll show you
results about that.
>>: I think there might be an issue of timing. So maybe I'm in the middle of making a decision in my own
game and the interruption might develop [indiscernible].
>> Ece Kamar: To get rid of that artifact in the game, we have different phases. For example, one phase
was about only interruptions and the other phase was about moving on the game board and the third phase
was about showing how the world changes to the people so that we try to distinguish these decisions from
each other.
But, again, even in this game setting there might be other factors that are coming into effect. But we try to
get rid of all these different factors as much as possible so we can capture a full iteration of baseline of the
interruptionnal outcome.
So the final results look like this. Here the Y axis is the interruption acceptance rate and the X axis is the
expected value of interruption as computed by these computational models. The red line is the acceptance
rate on the partner type, is a person and the blue line is when the partner type is an agent.
Here we see that when the interruption outcome is obvious, for example, it's negative or it's significantly
positive, people are very good at seeing this and rejecting these interruptions and accepting these
interruptions in a good person touch.
So we see that even if this game setting, calculating the full iteration out estimate of the interruption
outcome is a good estimate of what people are doing, how they do their decisions.
However, in this region where the outcome is not obvious, it's positive but slight, they're having a hard time
understanding whether it's beneficial or not. You see that the partner type has an effect. People are more
likely to accept interruptions coming from a partner than a computer system.
And this agrees with the previous work on the way people behave in collaborative domains. They are more
likely to collaborate with systems that look more like people. And then in the next work I will not be talking
about that here in detail, but the next work I apply some basic learning algorithms to see why that happens.
And I realize that people are more likely to overestimate their own outcome and underestimate the agent's
outcome even in these collaborative settings.
So to revisit the hypothesis, we show that the acceptance rate increases as outcome increases in this, until
the outcome reaches to a significant value and people are good at seeing the utilities as computed by
computational models. But still their decisions are affected by the way they perceive their partners,
especially around the outcome is not significant.
So here in this part of my work I design computational models to effectively capture the utility of the
utilization and design an abstract game setting to map a real world domain to a game setting so we can
analyze the outcome easily and do the human experiments. And conducted a user study showing that the
collaborative utility matters, but still we need to reason about how people perceive these utilities. So it's not
enough to have computational models; you still need to reason about how people see these benefits and
these domains.
So at this part I want to briefly talk about the real world application of collaboration that I do over there,
while I was doing my internship. This system does not use PITs or my theoretical models, but it captures
the main ideas of collaborative activities and the value we can generate by having these collaborative
plans.
So here we see people distributed in the city. They may have different preferences about their morning
commute to come to work that day. And they are computer agents working on their sites capturing their
preferences about these commutes. They can capture the time cost, delay cost, where they're going from
where they are in the city. The computer agents are delivering all these different prices into a central
optimization system, the optimizationnal system is generating a collaborative plan for these users and
giving them the right incentives to collaborate in such a system in terms of payments.
So the ABC mechanism, the agent-based carpooling mechanism, is a nice combination of user modeling,
optimization and payment.
Here we have the user model giving the preferences as to the optimization component. The optimization
component creates the payment plans. And the payment component gives away payments.
How does this system work? First, the agents learn about people's preferences by looking at their
calendars and then generates the initial individual plans, calculates a total cost for these individual plans
including the fuel cost, the time cost, the delay cost and how much cost they have for driving in traffic.
Then the optimization component searches multiple factors including stop ordering, stop timing, stop
location, possible routes to come up with the best possible collaborative plan so that it can minimize the
total cost of transportation and notifies the users about these new plans.
However, when we have people in the loop as self-interested agents it's not enough to build the best
collaborative plans, you need to give them incentives so they will burden the extra cost for picking people
on the way and bringing them to work. However, because our collaborative plans depends on the
preferences, design preferences of people, it is important to have a payment mechanism that has some
nice properties such as truthfulness, because we don't want these users lying to the system about the
preferences they have so that they can adapt their plans according to their own preferences, for example. I
can say I have an important meeting at 9:00 a.m. and arrange all these car pools according to my
preferences, although I don't have this important meeting.
So in this part of the work, we design payments that induce this good behavior about maximizing the total
utility and being truthful and then making every user happy in the system.
We started with a BCG payment mechanism. In this payment mechanism, each agent pays the effect that
it is bringing to the other agents, the value it generates for the other users. And then experimented with
different payment mechanism to see which payment mechanism works better in real life.
Just to show you a brief summary of the results we got from this ABC system, we used GPS data collected
from Microsoft employees in a five-year period and then extracted morning commutes from these GPS data
and used the adaptive carpooling system to generate carpooling plans. The picture on the left is showing
the traffic for these 215 users before the carpooling system and the picture on the right is showing the
traffic for these 215 users after the carpooling system.
So here by having -- by bringing these users together in carpooling plans, we are able to reduce the
number of commutes by 41 percent, reduce the total cost by 15 percent. This cost includes a time cost,
field cost and a combination of cost factors and get admissions by 22 percent.
So in this real world application, we went out and tested a complete computational model for self-interested
agents to bring the self-interested agents together in collaborative plans.
And also we experimented with different challenges and trade-offs we need to make this collaborative
planning work in real life. Also demonstrated how much value can we generate for these users and this
environments if we can apply these ideas into real world problems.
>>: But you didn't actually deploy it so you couldn't test to see if the victory payments actually worked?
>> Ece Kamar: We didn't test that. Yeah. We kind of calculated a baseline, how much value we can
generate if people adapt these plans, they trust the system and they start using the system.
And it is a challenge to deploy these systems in the real world, see how they perform in the real world.
In fact, none of my future interests match John's point in that. To employ these computational models in
real life there are different factors we need to investigate. One of them is understanding how people
perceive these systems, how they accept these systems. Do they trust these systems, or how we can
generate in these systems? It is a problem that I'm very interested in for further investigation into future
work.
So I believe to make such a system work in real life, we need to understand how social an organizational
structure's matter in collaborative plans.
And how we can use this structure to build better models of collaborative plans. By addressing people's
concerns about sharing information or by utilizing the information that exists in social networks,
reputationnal [indiscernible], for example, the picture here is showing my Facebook network as a graph and
we can extract distances from this graph to show the set of people I want to collaborate with and the set of
people I don't want to collaborate with and we can include this to the optimization component to reflect my
preferences about different people in my network.
And finally it is very important to trust systems, to generate systems that build trust with people so that the
people will be happy to be involved in the systems and adapt these systems.
The next challenge that I want to focus on is generating incentives for collaboration. These CG payments
that we build into the carpooling system have very nice properties on paper but we really don't know if they
will work with real people. And there's not much work shopping how these payment mechanisms work in
real life. It's a further challenge to understand what kind of incentives work in real life and what kind of
incentives are good for what kind of domains. For example, in the agent-based carpooling systems, I used
monetary payments. But in Wikipedia there are no payments and people are still collaborating because
they want to contribute to something big. It's part of the utility function. Or we know that altruism,
reciprocity are factors making people collaborate in the real world. It's very important for them to
understand these incentives when one incentive is better than the other.
Finally, I'm very interested in building these computational models but also apply them to real world. The
agent-based carpooling system was a very nice first step in applying these ideas to real world. But I
believe we have a lot of opportunity to use these ideas to other problems such as traffic or managing
resources in real world how we manage energy or making every day tasks easier, how computer agents
helping people in better ways.
And, finally, although we have these very beautiful computational models, payment components, we still
need to understand whether people are happy to share responsibility with these computer agents and
when they're going to share responsibility and control with them so we can always see how people
perceive our systems and rebuild our systems.
So just to summarize my contributions and the work I presented here, I presented a probabilistic
representation for agents, police about the probable plans that teammates are doing, and then use this
representation to enable decision theoretic reasoning on teamwork models.
I also presented a complete computational model to guide self-interested agents to collaboration in the
agent-based carpooling system. I also presented empirical studies of reasoning about helpful behavior.
And the way people perceive collaborative utility as computed by community by these computational
systems, and the value we can generate by applying these collaborative teamwork ideas to the real world,
both for users and the environment.
So the time I spent at Harvard doing my Ph.D. and also during my internships at Microsoft Research show
me the value of collaboration in the real world.
So at this point I want to thank all of my collaborators to make this research possible. And thank you for
listening, and if you have questions I'm happy to answer now.
[applause]
>>: Quick question. How would you -- I know you followed a little bit about directions to make
[indiscernible] to the real, real world versus real data. But what do you think you can do to field a real
world -- how much do you see as being difficult with good challenges [indiscernible].
>> Ece Kamar: Probably the first challenge is modeling user preferences in a better way. Our cost
function was a simplification. It just cared about the field cost and time cost and the lay costs and also
cognitive costs for driving. But as I mentioned in the future work session we need to think about
preferences that people want to collaborate with or how happy they will be for leaving their cars at home
and not having a car with them at work that day.
And also representing incentives for people's incentives for reducing carbon emissions or Microsoft's
incentives for reducing car emissions as a company that can be part of the total cost function that we're
trying to minimize.
And also here we draw up a system that knows about these carpooling plans beforehand. We also have a
dynamic system that's still a simplification of the real world. In the real world, sometimes we'll fail. There
will be unpredicted events such as traffic or accidents, things like that, that will make these plans stochastic
and unpredictable. In an observational system doesn't reason about what happens in the real world when
a plan fails or one of the participants decide not to contribute at all and how we can make this payment
system and the carpooling system dynamic.
It's a big optimization challenge to make it work in the real life.
>>: I wonder if you can model the effect of leadership in a collaboration, a leader does a couple things.
They gather and disseminate information. So that's one way it changes. Your recipe tree. And the other
way to change a recipe tree is to alter the costs, if we're not doing things or better support for doing things.
The vice verse is to have some cost. Would that be an easy thing to model?
>> Ece Kamar: I don't think it will be an easy task to model. In the models I presented, I assumed that
each participant has equal responsibility and they're contributing equally to have the collaborative plan
work. But once we have different organizations such as one is a messenger that's defining other users and
the one is a listener that is adopting the plans accordingly. One person predicts the cost playing utilities for
different tasks. You have a different division of labor and we should adopt these decision heuristic models
to reflect these different responsibilities and change how agents reason about these household behavior
models, for example, would given this new hierarchical structure in the plan.
>>: So in our work, for example, we didn't do a lot of thinking about the [indiscernible] for each structure.
But that kind of reasoning was [indiscernible] directed to the decision model, directed to the influences
diagrams.
How valuable do you think real world will be [indiscernible] versus the modeling approach in terms of how
much do they give us to determine it's true?
>> Ece Kamar: Planning approach, applied mobile approach planning, we're assuming that the world is not
changing much. There's not partial information nor the answer in the real world. We assume we know
where the person is going and we did mobile opportunistic planning given that we know about the person.
But in real life we had applied these mobile opportunistic systems in real life. The computer system will not
know what the person is doing. They'll have an answer about it. We'll also have an answer in the about
the world. I believe that's why PITS will be important to move this mobile opportunistic planning application
to the next step so that the application will not fail under answer and impression information. And also in
the mobile opportunistic planning challenge we didn't really reason about when these agents need to
communicate with the person or what is the utility of communicating, what is useful to informing. These
were all some questions that we didn't answer. And here I show that, by having these nice representations,
we can do more sophisticated reasoning on when an agent needs to update its plan or when the agent
needs to communicate.
>>: But in reality, there are times, for example, where the search tree involves a mega search with the
drag strip, with a plan that we call as a block box. Is this person reaching an opportunity, annotating it with
the details, interleaving of a few men and machine actions.
So am I interested in talking the max, if they are planning, they're a very optimized engine that does the
search to -- it calls and I think it's a big challenge. I think of breaking that open, breaking open that route
planner and making that part of the representation. So I guess the challenge, I guess.
>> Ece Kamar: So here I'm not saying we can just get PRTs applied to real world very easily without even
thinking about how they work in a particular domain. Here I'm just proposing a general representation that
is giving us new ways for reasoning about teamwork which was not possible before.
When we get these PRTs and try to implement them in real world such as mobile opportunistic planning,
you have to think about how we get these plans, how we get these probabilities, what do these black boxes
represent in real life and how do we make it work and what were the complex challenges, intractability
challenges, there are questions that need to be answered. But still we have some tools here that we didn't
have before to make this collaboration more successful on the information.
>> Eric Horvitz: Okay. Thanks very much.
[applause]