Participants submit their agent source code and class files (in a .zip or .jar package).
Please submit your application though the following link:
https://tinyurl.com/GENIUSANAC2020
Each participant has the option to prepare a 2-4 page report describing the design of their agent according to academic standards. The best teams that submit a report will be given the opportunity to give a brief presentation describing their agent at IJCAI. Furthermore, proceedings of the competition are planned to be published in a special issue.
The report will be evaluated by the organisers of this league. For eligibility, the strategy design should provide a contribution to the negotiation community. The report is recommended to address the following aspects:
The challenge for 2020 is to design a negotiating agent that can elicit preference information from a user during the negotiation. The idea is that when a negotiating agent represents a user in a negotiation, it does not know exactly what the user wants, and therefore the agent needs to actively improve its user model through a preference elicitation process.
In previous years of ANAC, and in most literature on automated negotiation, the utility function of the agent is presumed known. As was introduced for the first time in 2019, the preferences of the agent will instead be given in the form of a ranking of a limited number of possible agreements. Additionally, this year, the agent may elicit further information about the ranking against an elicitation cost in order to improve the user model.
The competition takes place during IJCAI 2020, January 2021, in Japan. There is at least $5000 in total available for prize money and for student travel grants which will be made available to participants.
Entrants to the competition have to develop and submit an autonomous negotiating party that runs on GeniusWeb. GeniusWeb is a negotiation platform in which you can develop general negotiating parties as well as create negotiation domains and preference profiles. The platform allows you to simulate negotiation sessions and run tournaments. Example parties and tutorials are available. If you are familiar with the Genius framework, it is easy to develop your agent in this new platform. Performance of the parties will be evaluated in a tournament between all participants, where each party is matched with other submitted parties. All submitted parties will negotiate in a number of negotiation scenarios, with varying levels of preference uncertainty and elicitation costs.
We recommend developing a Java based party but you can also use Python 2 using the python adapter available with GeniusWeb.
GeniusWeb App has been updated to support latest version of the GeniusWeb servers (1.4.2) and with new features (June 26th, 2020).
Changes
Rather than receiving a utility function, the party will receive an initial partial ordered profile. This profile will be an ordering of d bids, picked from an existing linear additive utility function U (see Figure). To help the party, the partial profile will contain the best and worst possible bid. The party negotiates with the partial profile until a certain outcome w* is reached. The score the party will receive for this outcome will be based on the original utility U(w*). So in short, the party receives ordinal information only, but it will be evaluated based on the underlying cardinal ground-truth.
The challenge for the parties is to design preference elicitation techniques in order to reach the best negotiation outcome, using techniques from e.g. machine learning, regression techniques, trade-offs, and linear programming. For details, please refer to the Genius manual and the frequently asked questions.
The negotiations will be run using the SHAOP protocol. In this protocol, the party can elicit more information about the true utility space in order to improve its own partial profile. This is done by requesting/eliciting a comparison from the "User". However, every such request comes at an elicitation cost, and all calls add up to a total bother. At the end of the negotiation, the performance of the party is recorded as the User utility of the final agreement, lowered with the total bother. An elicitation action in the SHAOP protocol is implemented through the ElicitComparison and Compare actions. The ElicitComparison requests a bid to be compared to a set of alternative bids. The Comparison action tells which bids are better and worse than the given bid. The SHAOP and COB party can take these actions at any time, and need not follow the turntaking of the SHAOP protocol.
The SHAOP party knows the cost of each CompareBids request: it is contained in a parameter "elicitationcost" (or if not set, the default is 0.1). Each time CompareBids is called by a party, this cost is added to the total bother. The SHAOP party will have to incorporate the Comparison result into the partial profile. One way to do this is to keep an ordered list, check the simpleshaop example party for details and example code.
Note: As of right now, the total bother is only implemented as constant increments of the elicitation cost. In theory however, it could be a very different function. All such possibilities are what we call bother cost functions. Future developments will explore extensions to support different types of bother cost functions. Rules of Encounter.
Negotiations are bilateral encounters following the SHAOP protocol. Offers are exchanged using a round-based protocol, with a maximum of 200 rounds. Parties do not have any prior knowledge about the preferences and strategy of the opponent. parties are reset after each encounter; that is, agents may negotiate repeatedly on the same domain or with the same opponents, but they cannot learn from their previous negotiations. When no agreement is struck, both parties receive the utility of their reservation bid, which is contained in the received profile. The reservation value can be different for both players. Note that this means a break-off can be preferable to an agreement for one (or both) of the players. This implies that it is risky to wait until the deadline to reach an agreement.
SHAOP specifies that the parties take turns making offers. One party starts the negotiation with an opening bid, after which the other party can take the following actions: Make a counter offer (thus rejecting and overriding the previous offer);
Walk away (i.e. ending the negotiation without any agreement and receiving the reservation value). This process ends when either a party walks away, a party does an incorrect action, an agreement is reached or the deadline is reached (e.g. 200 rounds). In order to make running the tournament feasible, parties are expected to generate their offers in a reasonable amount of time. Currently the GeniusWeb runserver imposes a response timeout of 10 seconds during negotiations.
Agents will be disqualified for violating the spirit of fair play (e.g. hacking the API, starting threads, attempts to access other party’s preference profile). The board of the ANAC 2020 competition will be the judge on these matters (for more information, see http://ii.tudelft.nl/anac/). The competition rules allow multiple entries from a single institution, but require each agent to be developed independently.