Merge pull request #2445 from fbsolo-ms1/feature-set-specification-transformation-concepts-branch

Freshness update for feature-set-specification-transformation-concepts.md . . .

Author: prmerger-automator[bot]

articles/machine-learning/feature-set-specification-transformation-concepts.md

@@ -8,15 +8,15 @@ ms.topic: how-to
 ms.author: franksolomon
 author: fbsolo-ms1
 ms.reviewer: yogipandey
-ms.date: 12/06/2023
+ms.date: 01/23/2025
 ms.custom: template-concept
 ---
 
 # Feature transformation and best practices
 
-This article describes feature set specifications, the different kinds of transformations that can be used with it, and related best practices.
+This article describes feature set specifications, the different kinds of transformations that can be used with them, and related best practices.
 
-A feature set is a collection of features generated by source data transformations. A feature set specification is a self-contained definition for feature set development and local testing. After its development and local testing, you can register that feature set as a feature set asset with the feature store. You then have versioning and materialization available as managed capabilities.
+A feature set is a collection of features generated by source data transformations. A feature set specification is a self-contained definition for feature set development and local testing. After development and local testing of a feature set, you can register that feature set as a feature set asset with the feature store. You then have versioning and materialization available as managed capabilities.
 
 ## Define a feature set
 
@@ -85,7 +85,7 @@ The calculation happens in these steps:
 - Apply the feature transformer, defined by `feature_transformation.transformation_code`, on the data, and get the calculated features
 - Filter the feature values to return only those feature records within the feature window `[feature_window_start_ts, feature_window_end_ts)`
 
-In this code sample, the feature store API computes the features:
+In this code sample, the feature store API calculates the features:
 
 ```python
 # define the source data time window according to feature window
@@ -137,7 +137,7 @@ class UserTotalSpendProfileTransformer(Transformer):
            .withColumn("is_low_spend_user", col("total_spend") < 20.0)
 ```
 
-This feature set has three features, with data types as shown:
+The feature set has three features, with data types as shown:
 
 - `total_spend`: double
 - `is_high_spend_user`: bool
@@ -153,9 +153,9 @@ This shows the calculated feature values:
 
 ### Sliding window aggregation
 
-Sliding window aggregation can help handle feature values that present statistics (for example, sum, average, etc.) that accumulate over time. The SparkSQL `Window` function defines a sliding window around each row in the data, is useful in these cases.
+Sliding window aggregation can help handle feature values that present statistics (for example, sum, average, etc.) that accumulate over time. The SparkSQL `Window` function defines a sliding window around each row in the data, which is useful in these cases.
 
-For each row, the `Window` object can look into both future and past. In the context of machine learning features, you should define the `Window` object to look only the past, for each row. Visit the [Best Practice](#prevent-data-leakage-in-feature-transformation) section for more details.
+For each row, the `Window` object can look into both the future and the past. In the context of machine learning features, you should define the `Window` object to look only in the past, for each row. Visit the [Best Practice](#prevent-data-leakage-in-feature-transformation) section for more information.
 
 Start with this source data:
 
@@ -329,7 +329,7 @@ Data leakage in the feature transformation definition can lead to these problems
 
 ### Set proper `source_lookback`
 
-For time-series (sliding/tumbling/stagger window aggregation) data aggregations, properly set the `source_lookback` property. This diagram shows the relationship between the source data window and the feature window in the feature (set) calculation:
+For time-series (sliding/tumbling/stagger window aggregation) data aggregations, set the `source_lookback` property correctly. This diagram shows the relationship between the source data window and the feature window in the feature (set) calculation:
 
 :::image type="content" source="./media/feature-set-specification-transformation-concepts/illustration-source-lookback.png" lightbox="./media/feature-set-specification-transformation-concepts/illustration-source-lookback.png" alt-text="Illustration showing the concept of source_lookback.":::
 
@@ -338,7 +338,7 @@ Define `source_lookback` as a time delta value, which presents the range of sour
 | Transformation type | `source_lookback` |
 |---|---|
 | Row-level transformation | 0 (default) |
-| Sliding window | size of the largest window range in the transformer.<br> e.g.<br> `source_lookback` = 3 days when the feature set defines 3 day rolling features <br> `source_lookback` = 7 days when the feature set defines both 3 day and 7 day rolling features |
+| Sliding window | size of the largest window range in the transformer.<br> e.g.<br> `source_lookback` = 3 days when the feature set defines three day rolling features <br> `source_lookback` = 7 days when the feature set defines both three day and seven day rolling features |
 | Tumbling/stagger window | value of `windowDuration` in `window` definition. e.g. source_lookback = 1day when using `window("timestamp", windowDuration="1 day",slideDuration="6 hours)` |
 
 Incorrect `source_lookback` settings can lead to incorrect calculated/materialized feature values.