Design of
Product-Brokering Agent
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.
Ontology
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.
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.
Product-Brokering
Agent
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.
Agent's Fitness
Function
To calculate the fitness of the agent, the proposed fitness
function was defined by using the following equation:
| (1) |
 |
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. [4] 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.
Agent's
Knowledge
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.
Product
Recommendation
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:
| (2) |
 |
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.
Agent's GUI
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.
Monitoring
Tools
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.
User
Feedback
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:
| (3) |
 |
As an example, assume that shown in Figure 4 is the agent's product list after being sorted in
ascending order.
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:
Evolution
Process
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.
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.
Sections
Archive
Syndication
