Github user MLnick commented on a diff in the pull request:
https://github.com/apache/spark/pull/17102#discussion_r103757139
--- Diff: docs/ml-collaborative-filtering.md ---
@@ -59,6 +59,34 @@ This approach is named "ALS-WR" and discussed in the
paper
It makes `regParam` less dependent on the scale of the dataset, so we can
apply the
best parameter learned from a sampled subset to the full dataset and
expect similar performance.
+### Cold-start strategy
+
+When making predictions using an `ALSModel`, it is common to encounter
users and/or items in the
+test dataset that were not present during training the model. This
typically occurs in two
+scenarios:
+
+1. In production, for new users or items that have no rating history and
on which the model has not
+been trained (this is the "cold start problem")
+2. During cross-validation, the data is split between training and
evaluation sets. When using
+simple random splits as in Spark's `CrossValidator` or
`TrainValidationSplit`, it is actually
+very common to encounter users and/or items in the evaluation set that are
not in the training set
+
+By default, Spark assigns `NaN` predictions during `ALSModel.transform`
when a user and/or item
+factor is not present in the model. This can be useful in a production
system, since it indicates
+a new user or item, and so the system can make a decision on some fallback
to use as the prediction.
+
+However, this is undesirable during cross-validation, since any `NaN`
predicted values will result
+in `NaN` results for the evaluation metric (for example when using
`RegressionEvaluator`).
+This makes model selection impossible.
+
+Spark allows users to set the `coldStartStrategy` parameter
+to `drop` in order to drop any rows in the `DataFrame` of predictions that
contain `NaN` values.
+The evaluation metric will then be computed over the non-`NaN` data and
will be valid.
+Usage of this parameter is illustrated in the example below.
+
+**Note:** currently the supported cold start strategies are `nan` (the
default behavior mentioned
--- End diff --
Yeah here I wanted to explicitly mention the "drop" option. Ideally will
remove this note section when further strategies are added (like the average
user vector idea).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]