A product-brokering agent can be used to search for all kinds of products. In our application, the agent will be used to search for some computer products, namely, CPU, Mainboard, and Memory. It is possible to extend the application to search for other products.
Similar to the information-filtering agents by Sheth and Maes, an initial population of product-brokering agents will be created and evolved using some form of genetic algorithm. However, in this design, the profile of the user is not based on any keywords supplied by the user. In fact, no keywords are required to be entered by the user. Instead, each agent will have an evaluation function that will be used to calculate the value of each product. Products that have a higher value will have a higher chance of being recommended by the agent. This evaluation function has some tunable parameters that characterize the user's preferences for a particular category of products.
In this design, some assumptions were made about the system. One important assumption is that the user is a rational person and will select a product rationally. Another assumption is that the value that a user places on a product can be calculated. The product values that we are focusing on will be those that can be calculated by using some tangible attributes (e.g., price) of the product. The agent will not be able to calculate the intangible value (e.g., branding) that a user placed on the product. If these assumptions are not met, the agent will not be able to track the user's preferences successfully.
Before the product-brokering agent is able to explore the Internet and retrieve product information for the user, the agent needs to have some prior knowledge, such as the URL of some relevant Web sites, keywords, or some quantifiable attributes that can be used to describe the product.
It could be tedious if the user has to enter such information into the agents when he wants to search for a particular product. An alternative to this is to create a product ontology, as shown in Figure 1, that already contains some information (e.g., URL of relevant Web sites). Creating a product ontology involves defining the meaning of each term that is used to describe the product, the valid range of values, and the relationship between one another.
Figure 1: Screenshot of Product Ontology
The product ontology was implemented in a tree-like structure, with the leaf nodes representing the products and the parent node representing the product category. Each leaf node actually contains a class called productInfo, which has some prior information about the product. New products can easily be added as a leaf node to the parent node. When the leaf node is selected, it will pass the product information to the product-brokering agents.
After describing how the agents are going to obtain their product knowledge, the next stage is to define the agent. A unique agent name will be given to each agent so that we can identify and differentiate the agents from one another.
To calculate the fitness of the agent, the proposed fitness function was defined by using the following equation:
This fitness function is basically an unweighted (or simple) moving average of the agent's fitness, where n is the window size of the moving average. Using Equation (1), the agent's fitness is obtained by averaging the number of points earned by the agent in the current and the previous n-1 generations. By varying the value of n, we can effectively control the number of generations under consideration, and the points earned outside this "window" will not be considered. As the fitness of an agent would be used to determine which agent to evolve, we do not want its past performances, which might be irrelevant now, to influence the evolution process.
An agent's fitness will always be a positive value, and a new agent would start off with some default fitness. To keep track of the agent's performances, each agent will have a list called fitness_history, and this will be used to store the fitness of an agent for each generation. Hence, after an agent is awarded some points, it will calculate its new fitness using Equation (1) and insert the value into the fitness historylist.
For our application, the agent's task was designed especially to parse information from a Web site called Hardwarezone.com.  It is a Web site hosted in Singapore, and it displays up-to-date information of various computer products in table form. The task program allows the agent to establish a connection to the Web site and download the HTML document onto a local computer. The program then parses the document and extracts the relevant information for the agent by looking for specific tags within the HTML document. In our application, the program will be able to extract information such as the description of the product, its price, and the name of the shop selling this product.
After an agent retrieved some product information, it needs a place to store this information. As mentioned earlier, when an agent is created, it will register itself to a database. Microsoft Access database is used in this application. Within the database, a table will be created in which each agent can store all the information it retrieved. In addition, the agents will also store this data on a global database. The global database will contain all the products retrieved by the agents in the system.
Before recommending a product to the user, the agent should first be able to evaluate which product would best fit the user's requirements. A proposed method is to use some quantifiable attributes, such as cost, performance, etc., to evaluate the products. An example of an evaluating function could be the following equation:
With the attributes used in Equation (2), we try to model the two types of factors that can influence a user's choice. The first attribute (performance) represents the performance of the product, while the second attribute (cost) represents the cost of the product. It was assumed that the better the product, the higher will be its performance, and a better product usually results in a higher cost. From Equation (2), it can be seen that a product with a higher performance and/or a lower cost will result in a higher product_value.
The two weights—perf_weight and cost_weight—represent the weights that the user could give to each attribute. These two parameters are actually used to represent the user's preferences and are incorporated inside the agent. If perf_weight has a higher value, it means that the user placed more emphasis on the performance of the product. Likewise, if the user has a higher value for cost_weight, it means that the user is more concerned about the cost of the product.
When an agent is created, these two weights will be initialized based on some heuristics and would be used to calculate the value of each product found in the agent's database. The agent will then rank the products according to their values and select the top three products to be presented to the user. The value of perf_weight and cost_weight will be allowed to change during agent evolution.
Each agent has a simple GUI that shows information, such as the name of the agent, its current status, products recommended, etc. It would also allow the user to change some of the parameters inside the agents.
The agent's GUI is implemented as shown in Figure 2. The GUI allows the user to see the top product inside the agent's database and also some of its internal parameters. The user can kill the agent from this GUI by clicking the kill button or update some of the agent's parameters by using the update button.
Figure 2: Agent GUI
A monitoring tool will be provided for the user that will allow the user to observe and control the behavior of the agents while they search for products on the Internet. This tool will be the main interface between the user and agents.
The user can choose from a list of products provided in the product ontology and enter some parameters (e.g., number of agents, etc.) before starting the search. Once all the parameters are entered into the system, the appropriate number of agents will be created to search for the product on the Internet. A screenshot of the implemented system is as shown in Figure 3.
Figure 3: Screenshot of the Monitoring Tool
During user feedback, each agent in the system will select the top three products in its database and add them to a recommended list. A sorting function will be implemented to allow the user to sort the list according to his or her preferences. If the user cannot find any product that he or she fancies in this list, the user can look at the global list, which contains all the products retrieved by the agents in the system. When the user selects a product that is liked, all the agents in the system will be informed about the user's selection.
The agents will take note of the product that the user selected and search for that product inside its own database. At this stage, each agent would have already assigned a product value to every product in its database. To determine the amount of points to award to an agent, it will be asked to rank the products in an ascending order according to this value. Hence, products with a higher value will be located at the bottom of the table. The agent will then determine the position of the user-selected product and take note of its row number. The formula to calculate the exact amount of points to give to an agent is as follows:
As an example, assume that shown in Figure 4 is the agent's product list after being sorted in ascending order.
Figure 4: Screenshot of an Agent's Database after Sorting
In this example, there are a total of 13 products found inside the agent's database, and the product with the highest product value is located at row 13. This will be the top product inside the agent's database. However, during feedback, the user might have actually chosen the product at row 7 instead. Assuming that five is the maximum amount of points awardable, the amount of points that the agent earns in this case will be as follows:
In conventional genetic algorithms, the agent with a higher fitness will have a higher chance of survival as compared to an agent with a lower fitness. However, in this application, there will be a slight variation in the algorithm. Instead of killing the weaker agents, they will simply copy over all the parameters of the fitter agents. Let Agent 1 be the fitter agent and Agent 2 be the weaker one. Shown in Figure 5 is what happens between the agents during evolution.
Figure 5: Evolution Process
However, the parameters inherited by a weaker agent in this evolution process might not be optimal. Therefore, the weaker agent will try to adjust its newly acquired perf_weight and cost_weight to better reflect the user's requirements. First, it will use the newly acquired parameters to reevaluate all the products found inside its new database. Then the agent will select the best product based on these new parameters. If it is the same as the user-selected product, no further changes will be required, but some small and random mutations in the parameters will be allowed.
However, that will not usually be the case. In this case, the agent will compare the performance and cost attributes of the products that are selected by the user and the agent. Let p1 and p2 denote the performance of the products selected by the user and agent, respectively. Also let c1 and c2 denote the cost of the products selected by the user and the agent. Four possible scenarios will have to be considered, and they are as follows:
p1 > p2 and c1 > c2
The user selected a product that has a much better performance but is more expensive than what the agent suggested. The agent can deduce that the user places more emphasis on the performance rather than on the cost of the product. Therefore, it will increase its perf_weight and reduce its cost_weight.
p1 < p2 and c1 < c2
The user selected a product that is of lower performance but is cheaper than what the agent suggested. The agent can deduce that the user places more emphasis on the cost rather than on the performance of the product. Therefore, it will reduce its perf_weight and increase its cost_weight.
p1 < p2 and c1 > c2
The user selected a product that is of lower performance and is more expensive than what the agent suggested. The agent will be confused over such a selection and will prompt the user if it should carry on the evaluation. If the user still wants the agent to carry on, it will either reduce its perf_weight or cost_weight. This might happen when the user placed some form of intangible attributes/values on the product that are not present inside the agent's evaluation function.
p1 > p2 and c1 < c2
The user selected a product that is of higher performance and is cheaper than what the agent suggested. This scenario will not arise during evolution. Looking back at Equation (2), a product with a higher performance and/or a cheaper product will result in a higher value being assigned to that product. Because using p1 and c1 will definitely result in a higher product value as compared to p2 and c2, this scenario will not happen.