Unit 1, lesson 2

Features, Targets, and Prediction Time

How to say what one row of a learning table represents, which fields are features available at prediction time, how a target rule gives labels, what the prediction horizon is, and how target leakage arises.

  • Video 2
  • Learning Tasks and Data Tables

A parcel company has a spreadsheet with thousands of rows of dates, customer numbers, routes and delivery times. Before a model can learn anything from it, someone has to say what one row represents, what exactly is predicted and when the prediction is made. This lesson builds a small learning table for one question, whether a parcel will miss its promised deadline, asked at the moment the booking is accepted. It shows which columns may become features, how the labels are defined and why fields recorded after the booking must stay out of the inputs. The bookings on this page are constructed for teaching, and all their times are in one time zone.

Key terms

Unit of observation

Definition The unit of observation is what one row of a learning table represents, the entity together with the prediction made about it, for example one parcel booking with one prediction at the moment the booking is accepted. It fixes the row key, the fields that identify a row, and it fixes what counts as one more observation. Rows are not automatically independent. Two rows can share a customer, an address, a route or a day, and then part of the information they carry is shared. The sampling frame, the set of cases from which the rows were drawn, limits the population that conclusions from the table can describe.

In plain words Say in one sentence what a row is before counting rows. Ten tracking updates for one parcel are ten records about one booking, not ten bookings. Identifiers such as parcel and customer numbers help to link and check records, but they are not automatically inputs to the model. A different question, such as updating the prediction at every tracking event, needs a different unit and therefore a different table.

Example For the question of whether a parcel will miss its original promised deadline, asked when the booking is accepted, the unit is one parcel booking, and the row key is the parcel number together with the booking time. Three constructed bookings are shown below.

ParcelCustomerBookedOriginal deadline
P101C-AOct. 1, 9 a.m.Oct. 2, 5 p.m.
P102C-BOct. 1, 10 a.m.Oct. 2, 3 p.m.
P103C-AOct. 2, 8 a.m.Oct. 3, noon

Bookings P101 and P103 come from the same customer, so they may share an address and access instructions. If the model is meant for new customers, an evaluation with one of them in training and the other in testing can look better than the model will do for customers it has never seen. A table drawn only from priority bookings would likewise say little directly about standard bookings.

Feature

Definition A feature is an input variable of the model, a field defined for every observation whose value is available at the prediction time. With nn observations and pp features, xijx_{ij} denotes the value of feature jj for observation ii. The feature vector of observation ii is

xi=[xi1⋮xip]∈Rp,\mathbf{x}_i = \begin{bmatrix} x_{i1} \\ \vdots \\ x_{ip} \end{bmatrix} \in \mathbb{R}^p ,

with the features in a fixed order, and the design matrix, or feature matrix, XX is the n×pn \times p matrix whose row ii is xi⊤\mathbf{x}_i^{\top}. Numerical features record quantities, such as a distance. Categorical features record membership in a category and enter XX through a numerical encoding. A field with two categories is often coded 0 and 1, a binary encoding, while fields with more categories need more care, since numbering them 1, 2, 3 would invent an order they may not have.

In plain words A column becomes a feature only if the model may use it at the moment of prediction. The order of the features is part of their meaning, because position jj always refers to the same field. The codes 0 and 1 for priority name two categories. They are not one kilogram or one kilometer of anything.

Example Take as features the planned distance in kilometers, the declared mass in kilograms and priority service, coded 1 if selected and 0 if not, all recorded when the booking is accepted. The three bookings give

X=[122081.512030],X = \begin{bmatrix} 12 & 2 & 0 \\ 8 & 1.5 & 1 \\ 20 & 3 & 0 \end{bmatrix},

with rows P101, P102 and P103 in that order. Here n=3n = 3 and p=3p = 3, the first feature vector is x1=(12,2,0)⊤\mathbf{x}_1 = (12, 2, 0)^{\top}, and the entry x23=1x_{23} = 1 says that the second booking chose priority service. Adding a booking adds a row and increases nn. Adding a field recorded for every booking adds a column and increases pp.

Target and label

Definition The target is the quantity or category the model is meant to predict, fixed by a precise rule before any labels are made. A label is the value of the target recorded for one observation. The labels form the target vector y=(y1,…,yn)⊤\mathbf{y} = (y_1, \dots, y_n)^{\top}, and yiy_i must belong to the same observation as row ii of XX. For the lateness task, let did_i be the original promised deadline of booking ii and tit_i its delivery time. For a booking with a trustworthy delivery record,

yi={1,ti>di,0,ti≤di.y_i = \begin{cases} 1, & t_i > d_i, \\ 0, & t_i \le d_i. \end{cases}

Reliable evidence that a parcel was not delivered by its deadline also gives yi=1y_i = 1. A booking with no delivery record while its deadline is still ahead, or with a missing delivery record after the deadline and no such evidence, is unresolved, and that state is kept apart from both 0 and 1.

In plain words The target is the question, and a label is one recorded answer to it. The rule has to settle the edge cases before labeling starts. Here a delivery exactly at the deadline counts as on time, the original deadline is used even if it is later revised, and cancellations would need a stated policy of their own. A blank delivery field is not an on-time delivery.

Example P101 was delivered 20 minutes after its deadline, so t1−d1=20t_1 - d_1 = 20 minutes and y1=1y_1 = 1. P102 arrived 5 minutes early, so t2−d2=−5t_2 - d_2 = -5 minutes and y2=0y_2 = 0. P103 arrived exactly at noon, its deadline, so t3−d3=0t_3 - d_3 = 0 and y3=0y_3 = 0 by the tie rule. The target vector is therefore y=(1,0,0)⊤\mathbf{y} = (1, 0, 0)^{\top}, in the row order of XX. Two further bookings show the unresolved state. When the table is extracted at a quarter past noon on October 3, booking P104 is due at 6 p.m. that day and has no delivery yet, so its outcome is still open. Booking P105 was due at 6 p.m. on October 2, but its delivery record is missing, and the parcel may be undelivered or may have been delivered without the record reaching the database. Both stay unresolved rather than being labeled 0 or 1.

Prediction time and horizon

Definition The prediction time of an observation is the moment at which its prediction must be made. A field may enter the features only if its value is available to the prediction system by that moment, which depends on when the value reaches the system and not only on when the underlying event happened. The prediction horizon is the length of time from the prediction time to the time the target refers to. In the lateness task the prediction time of booking ii is its acceptance time bib_i and the target refers to the deadline did_i, so the horizon is di−bid_i - b_i, which can differ from booking to booking.

In plain words Put every field on a timeline and ask whether it would be in hand at the moment of prediction. Planned distance is known at booking, while the distance actually driven, despite its similar name, is known only after the trip. A traffic count for the hour before the booking that reaches the database the next morning describes an earlier event but is still unavailable at booking. The horizon says how far ahead the prediction looks.

Example P101 was booked at 9 a.m. on October 1 with a deadline of 5 p.m. on October 2, a horizon of 32 hours. P102 was booked at 10 a.m. on October 1 with a deadline of 3 p.m. on October 2, a horizon of 29 hours, and P103 was booked at 8 a.m. on October 2 with a deadline of noon on October 3, a horizon of 28 hours. At each of these booking times the planned distance, the declared mass and the priority choice are known, while the delivery time and any later complaint are not.

Target leakage

Definition Target leakage occurs when a feature carries information about the target that would not be available at prediction time, usually because it is recorded after the prediction time or is computed from the outcome itself. A model trained with such a feature can look accurate on historical data and then fail in use, because for a new case the feature is not yet known when the prediction is made. Target leakage is one form of data leakage, the wider problem of information that would not be available in use reaching a model or its evaluation, treated in Data Leakage and Honest Splitting.

In plain words If a field can only be filled in after the answer is known, or is partly built from the answer, it cannot be an input. To check a field, replay one booking and ask what the system would really have known at that moment. Unexpectedly high accuracy is a common warning sign of leakage.

Example Together with the deadline, the actual delivery time decides the late label exactly, since for a resolved delivery yi=1y_i = 1 precisely when ti>dit_i > d_i. A model given both fields could reproduce every stored label and still be useless at booking, when tit_i does not exist yet. A customer complaint written after delivery is also unavailable at booking and can reveal that something went wrong. So can a deadline that was revised after a delay began, which is one reason the target uses the original deadline and the features use only what was known when the booking was accepted.

Data schema

Definition A data schema is a written description of every field in a learning table, stating its meaning, type, unit, allowed values, treatment of missing values and the time at which it becomes available. It also states the unit of observation and the row key, how duplicate records are handled, how outcomes are matched to bookings, and the exact rule that defines the target, including its edge cases.

In plain words The schema is the agreement about what the numbers mean. Two people who follow the same schema should build the same rows, the same features and the same labels from the same raw records. A carefully computed model cannot repair a target whose meaning changes partway through the table.

Example Here is part of a schema for the lateness table. It has one row per parcel booking, keyed by parcel number and booking time, and all times are in one stated time zone.

FieldType and unitAllowed valuesAvailable
Planned distancenumerical, kmnonnegativeat booking
Declared massnumerical, kgpositiveat booking
Prioritycategorical, coded0 or 1at booking
Original deadlinetimestampafter bookingat booking
Delivery timetimestampafter bookingafter delivery, for the label only
Latebinary target0, 1 or unresolvedonce the outcome is resolved

A missing distance, mass or priority is flagged for review and never silently set to 0. Raw tracking events are assembled into one row per booking, and conflicting outcome records go to review instead of one being chosen without comment.

Check yourself

  1. A new constructed booking is accepted at 8 a.m. on October 5. Its planned distance is 15 kilometers, its declared mass is 4 kilograms and priority service is not selected. The original deadline is 2 p.m. on October 6, and the parcel is later delivered 10 minutes before the deadline. Write its feature vector in the order distance, mass, priority, and find its prediction horizon and its label. How do the shapes of XX and y\mathbf{y} change when this booking joins the three resolved rows?
Show the answer

The feature vector is x4=(15,4,0)⊤\mathbf{x}_4 = (15, 4, 0)^{\top}. The horizon runs from 8 a.m. on October 5 to 2 p.m. on October 6, which is 30 hours. The delivery time minus the deadline is −10-10 minutes, so the label is y4=0y_4 = 0, on time. That label becomes known only after delivery, so it plays no part in the prediction made at booking.

With the new row the design matrix goes from 3×33 \times 3 to 4×34 \times 3 and the target vector from 3 entries to 4. The number of observations becomes n=4n = 4, while p=3p = 3 stays the same.

  1. For the lateness task, with the prediction made when the booking is accepted, say whether each field may be a feature. (a) The number of parcels the customer booked in the 30 days before this booking. (b) The number of delivery attempts. (c) The driver assigned on the evening before delivery. (d) A weather forecast for the delivery day, published and stored before the booking was accepted. (e) The customer’s share of late deliveries, computed over all of that customer’s parcels in the table.
Show the answer

(a) Yes, provided it counts only bookings made before this one and those records reach the system by the booking time.

(b) No. Delivery attempts happen after the prediction time, and a second attempt is itself a sign of trouble with the delivery.

(c) No, as long as drivers are assigned after booking. The assignment does not exist when the prediction is made.

(d) Yes. It describes the future, but the forecast itself is in hand at booking, and availability at the prediction time is what matters.

(e) No, as written. It uses the outcome of this booking and of later bookings, so it leaks the target. A version computed only from that customer’s earlier bookings whose outcomes were resolved before this booking was accepted would be allowed.

  1. An extract run at a quarter past noon on October 3 fills every blank late field with 0. Booking P104 is due at 6 p.m. on October 3 and has no delivery record yet. Booking P105 was due at 6 p.m. on October 2, and its delivery record is missing. What is wrong with the 0 labels, and what should be done instead?
Show the answer

Neither label is supported by the records. For P104 the deadline is still 5 hours and 45 minutes away, so the outcome has not happened yet. Its label is unresolved, and the right step is to wait for the outcome.

For P105 the deadline has passed, but a missing record shows neither an on-time delivery nor a late one. The parcel may be undelivered, or it may have been delivered without the record reaching the database. Its label stays unresolved until the record is repaired, or until reliable evidence shows that it was not delivered by the deadline, which would make the label 1.

Coding the blanks as 0 would teach a model that such bookings were on time. Dropping every unresolved row is not automatically safe either, because if difficult deliveries are more likely to have missing records, the remaining rows can understate how often parcels are late.

How this lesson connects