mirror of
https://github.com/13hannes11/bachelor_thesis.git
synced 2024-09-04 01:11:00 +02:00
changed he/she to singular they
This commit is contained in:
@@ -157,14 +157,14 @@ Advantages and disadvantages of basic recommendation techniques are listed in \a
|
||||
\subsubsection{Advantages over Collaborative Filtering}
|
||||
|
||||
Collaborative filtering has several issues that content-based filtering doesn't have. According to \citeauthor{likaFacingColdStart2014} \cite{likaFacingColdStart2014} the \emph{cold start problem} is one of the well-known problems of recommender systems. It occurs when there is sparse information for users or items. In the case of collaborative filtering this issue concerns for both items and users. Content-based filtering does not have that issue with items as items are classified based on similarity to other items. The user cold start problem however still persists when a new user has not yet rated any items. Therefore, no similar items can be recommended.
|
||||
Another common issue is the \emph{grey sheep problem}. \citeauthor{grasIdentifyingGreySheep2016} \cite{grasIdentifyingGreySheep2016}. Collaborative filtering approaches assume that users that are similar, have similar preferences. A user that is not similar to any of the current user or community of users fail that assumption. Therefore, good recommendations cannot be made. These users are called \emph{grey sheep users}. Item-based filtering does not have this issue as a user's preference is directly used to find similar items to the ones she liked, not similar users.
|
||||
Another common issue is the \emph{grey sheep problem}. \citeauthor{grasIdentifyingGreySheep2016} \cite{grasIdentifyingGreySheep2016}. Collaborative filtering approaches assume that users that are similar, have similar preferences. A user that is not similar to any of the current user or community of users fail that assumption. Therefore, good recommendations cannot be made. These users are called \emph{grey sheep users}. Item-based filtering does not have this issue as a user's preference is directly used to find similar items to the ones they like, not similar users.
|
||||
Usually, the need for domain knowledge is a disadvantage. However, as product configuration already has domain knowledge baked in to describe features and how they can be combined, this is not a disadvantage and can even be seen as an advantage. Therefore, domain knowledge can directly be used and does not first need to be learned indirectly.
|
||||
Additionally, a collaborative filtering approach spans a larger comparison space, based on preferences, compared to content-based filtering that only uses the item attributes. Thus, for applications with a large solution space, reliance on product features instead of user similarity should be considered.
|
||||
Last, content-based filtering does not depend on historic group preference accuracy. Therefore, malicious actors that try to manipulate the recommendation system do not decrease recommendation accuracy. The same is true for inaccurate preferences. For example if a user's input into a system does not accurately reflect what she actually likes.
|
||||
Last, content-based filtering does not depend on historic group preference accuracy. Therefore, malicious actors that try to manipulate the recommendation system do not decrease recommendation accuracy. The same is true for inaccurate preferences. For example if a user's input into a system does not accurately reflect what they actually like.
|
||||
|
||||
\subsubsection{Advantages over Constrained-Based Recommendation}
|
||||
|
||||
In constrained-based recommendation approaches it is possible that constraints lead to no possible solution \cite[~ p. 44]{felfernigAlgorithmsGroupRecommendation2018}. This then requires further techniques of constrained relaxing and a user is faced with the situation that he has to search for constraints which fulfil less strict requirements. Moreover, in groups a constraint-based approach has to deal with contrary user constraints. Therefore, diverse groups could have issues with it.
|
||||
In constrained-based recommendation approaches it is possible that constraints lead to no possible solution \cite[~ p. 44]{felfernigAlgorithmsGroupRecommendation2018}. This then requires further techniques of constrained relaxing and a user is faced with the situation that they have to search for constraints which fulfil less strict requirements. Moreover, in groups a constraint-based approach has to deal with contrary user constraints. Therefore, diverse groups could have issues with it.
|
||||
|
||||
\subsection{Hybrid Recommendation}
|
||||
A hybrid recommender combines different recommendation approaches to use the strengths of each individual one and to reduce effects of weaknesses \cite{burkeHybridRecommenderSystems2002}.
|
||||
|
||||
@@ -257,7 +257,7 @@ This section gives an example to illustrate how the recommendation works. The ex
|
||||
|
||||
The difference between $S_{F1}$ and $S_{F2}$ is that instead of containing \emph{moderate} for the feature \emph{resilient} $S_{F2}$ contains \emph{high}. The scores for these two characteristics are the same, with a value of $0.55$, as both users have rated them at $0.5$ but since $S_{F2}$ deviates from the configuration state there will be a penalty. There are two characteristics in the configuration state $S$, therefore, the penalty is $(\frac{1}{2})^\alpha = (\frac{1}{2})^1 = 0.5$. This means the score of $S_{F2}$ is half of $S_{F1}$, resulting in a final score of $0.275$ compared to $0.55$.
|
||||
|
||||
The only difference between $S_{F1}$ and $S_{F3}$ is that $S_{F3}$ changes the selection for the feature \emph{effort}. The characteristic \emph{manual} is chosen in $S_{F1}$ and the characteristic \emph{harvester} for $S_{F3}$. The individual score for user one increases as he prefers \emph{harvester} with $0.8$ over \emph{manual} with $0.6$. However, user two has an individual score reduction as her score changes from $0.8$ for \emph{manual} to $0.3$ for \emph{harvester}. The larger decrease in the score of user two causes a decrease in the overall score when comparing $S_{F1}$ to $S_{F3}$ with a score of $0.55$ to $0.53$. The scores for both users are closer together for $S_{F1}$. However, this does not necessarily have to be the case if the preference of user two for harvester were to change to $0.6$ because then both configurations would have the same score. A different user preference aggregation strategy can change that.
|
||||
The only difference between $S_{F1}$ and $S_{F3}$ is that $S_{F3}$ changes the selection for the feature \emph{effort}. The characteristic \emph{manual} is chosen in $S_{F1}$ and the characteristic \emph{harvester} for $S_{F3}$. The individual score for user one increases as they prefer \emph{harvester} with $0.8$ over \emph{manual} with $0.6$. However, user two has an individual score reduction as their score changes from $0.8$ for \emph{manual} to $0.3$ for \emph{harvester}. The larger decrease in the score of user two causes a decrease in the overall score when comparing $S_{F1}$ to $S_{F3}$ with a score of $0.55$ to $0.53$. The scores for both users are closer together for $S_{F1}$. However, this does not necessarily have to be the case if the preference of user two for harvester were to change to $0.6$ because then both configurations would have the same score. A different user preference aggregation strategy can change that.
|
||||
|
||||
Last, $S_{F1}$ and $S_{F4}$ differentiate in terms of the characteristic choice for the feature \emph{indigenous}. The switch from \emph{moderate} to \emph{high} when changing from $S_{F1}$ to $S_{F4}$ causes an increase in the individual scoring function of user two. This is caused because her preference for \emph{moderate} is $0.6$ and for \emph{high} is $0.9$. This results in a score of $0.57$ for $S_{F4}$. Yet, the change that causes the preference scoring function to give a higher score entails a penalty as the characteristic \emph{high} is not part of the configuration state. This penalty causes the overall score to drop to $0.29$ compared to the score of $S_{F1}$ with $0.55$.
|
||||
|
||||
|
||||
@@ -84,5 +84,5 @@ The requirements posed in \autoref{sec:Concept:Requirements} are assessed in thi
|
||||
Additionally, the group scoring function takes into account preferences of each group member and the current configuration state. The recommendation system can be used by multiple users at the same time as all information needed for a recommendation is sent with the recommendation request. Accordingly, multiple group configurators can use the system at the same time. Furthermore, only valid solutions are recommended because the recommender system's configuration database stores finished configurations. Moreover, the system responds in a timely manner with all components running on the same machine, a modern laptop.
|
||||
Consequently, all mandatory requirements have been fulfilled.
|
||||
|
||||
The user interface is simple because a user only has two possible opportunities for action. He can change his preferences with a slider or change the configuration state. Additionally, the system is made to be compatible with other configuration systems. These have to implement the correct APIs calls. However, this requirement was not tested with a different configuration system. Different scoring functions can be used however they can neither be selected through user interface nor through the API. Thus, this requirement is only partially fulfilled but the system allows extension to fulfil this requirement fully.
|
||||
The user interface is simple because a user only has two possible opportunities for action. They can change their preferences with a slider or change the configuration state. Additionally, the system is made to be compatible with other configuration systems. These have to implement the correct APIs calls. However, this requirement was not tested with a different configuration system. Different scoring functions can be used however they can neither be selected through user interface nor through the API. Thus, this requirement is only partially fulfilled but the system allows extension to fulfil this requirement fully.
|
||||
Overall optional requirements have been addressed but they have not been thoroughly evaluated and some of them have been only partially implemented.
|
||||
@@ -75,7 +75,7 @@ To evaluate the recommender, a use case is needed. In this thesis, a forestry us
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
The stakeholders in this use case are: a forest owner, an athlete, an environmentalist, and a consumer. The owner sees the forest as an investment, he is interested in a high long-term profit. On the other hand consumers are interested in reasonable wood price as they use wood for furniture and also for their fireplaces. In contrast, the environmentalist is interested in a healthy forest that is not impacted negatively by human activity. Last is the athlete who is interested in good accessibility of the forest and that there is some plant and animal life.
|
||||
The stakeholders in this use case are: a forest owner, an athlete, an environmentalist, and a consumer. The owner sees the forest as an investment, they are interested in a high long-term profit. On the other hand consumers are interested in reasonable wood price as they use wood for furniture and also for their fireplaces. In contrast, the environmentalist is interested in a healthy forest that is not impacted negatively by human activity. Last is the athlete who is interested in good accessibility of the forest and that there is some plant and animal life.
|
||||
Every group consists of four people which is why they need to try and find a compromise. Diverging preferences make this difficult. All stakeholders have an interest in getting their will but also all parties need others to accept the decision. It is not in the interest of a stakeholder to fully have their preferences met while ending up with protests that arise from the deep dissatisfaction of other group members.
|
||||
|
||||
\section{Data Generation}
|
||||
|
||||
Reference in New Issue
Block a user