What is the training-serving skew here?

The mismatch when a feature is computed by different logic in training and live use, a classic silent production failure.

Where do feature functions live?

In shared libraries or feature stores, with versioning and ownership, rather than embedded in individual model scripts.

How granular should a function be?

One clear definition per function; compound logic is built by composing simple tested functions.

Who owns a shared feature function?

A named owner, usually in the data team, with domain review for the definition; shared logic without an owner decays.

AI Glossary / AI and machine learning / Intermediate

Feature Function

Definition

A feature function is the reusable piece of logic that computes one feature from raw data: given the inputs, here is exactly how this field gets its value.

What it means

Between raw data and a feature value sits a computation: count the orders in the last thirty days, extract the hour from the timestamp, map the country code to a region. Encapsulated and named, that computation is a feature function.

Writing features as functions rather than one-off scripts makes them testable: given known inputs, the output is checkable, and the edge cases, empty history, missing values, daylight saving, can be pinned down before they corrupt a model.

Functions are shared assets. The same days-since-last-contact function can serve the churn model, the support prioritizer and the marketing suppressions, computed once, defined once, changed once.

They also define lineage: each feature function names its inputs, so when a raw source changes, you can trace which features, and therefore which models, are about to move.

For a business, feature functions are where data logic becomes manageable: a library of reviewed, tested definitions instead of a tangle of personal queries that disagree about what the same word means.

Feature functions are also the natural unit of documentation: each one carries its definition, edge cases and examples in one place, which makes onboarding a new analyst a reading exercise instead of an archaeology dig.

How it works

Define each feature as a named function with declared inputs, output type and a written definition of the computation.

Unit-test the function on hand-built cases: normal inputs, empties, boundary values and known historical quirks.

Register the function in a shared library or feature store, so teams reuse the same definition rather than re-implementing it.

Compute features through the same function in training and serving, eliminating the classic mismatch where the model was trained on one definition and scored by another.

Version functions: a change to the definition is a new version, and models record which version they were built against.

Three practical examples

A days-since-last-purchase function shared by churn, marketing and support models.
A normalized-income function that handles currencies, missing values and outliers in one tested place.
A session-count function with an explicit, tested definition of what counts as a session.

Think of it this way

Think of the recipe card in a restaurant chain. Every branch cooks the sauce the same way because the recipe is written down, tested and versioned. Feature functions are recipe cards for data: without them every kitchen improvises.

The limit: a recipe can be consistently wrong. Shared definition means shared error, so review and test carry extra weight when reuse is wide.

Worked example

one definition of active customer

Suppose a bank finds its churn and marketing models disagree about how many active customers exist. The figures are illustrative.

The cause: two teams implemented active differently, one counting a login, the other requiring a transaction in thirty days.

The team writes one active-customer feature function, tests its edge cases, and rebuilds both models on it.

The headline number now matches across teams, and the argument moves from whose query is right to what the business should do.

Illustrative case study

A fictional retailer discovered, in a pricing post-mortem, that the model's margin feature was computed differently in training and live scoring: one divided by price including tax, the other excluding.

The mismatch had silently discounted every live margin by the tax rate for months.

The invented lesson: the most dangerous feature bug is not a wrong value but a right-looking one. Identical functions in training and serving are the only defense.

Common misconceptions and mistakes

A SQL query is a feature function. It becomes one when it is named, tested, versioned and reused; an ad hoc query is a private recipe.
Feature functions are only for big platforms. A shared, tested function library pays off at three models; the tangle grows faster than the model count.
Once tested, always trusted. Functions sit on moving raw data; they need monitoring and periodic retesting like everything else.

Business use

Require named, tested feature functions for any feature used by more than one model; reuse without review is how one bug becomes five models' problem.

Trace model inputs back to functions and functions to sources, so upstream changes have a blast-radius map.

Keep the function library reviewable by analysts, not only engineers; the definitions are business logic, and the business should be able to read them.

Fund the function library as shared infrastructure, not as a side effect of individual projects; project-funded logic is exactly how five definitions of the same word accumulate.

Check your understanding

Why does computing training and serving features through the same function matter so much?

Answer: Because any difference between the two definitions silently shifts the model's live inputs away from what it was trained on, degrading it without any error message.

Related terms

Learn next

AI Agents and Automation for Small Business covers the versioning and testing disciplines that keep shared automation logic safe: https://aiforbusinessandlife.com/academy/ai-agents-automation-small-business. [C4]

Sources

[S7] Hopsworks, MLOps Dictionary. Full URLs are in the source ledger. Verified 11 October 2026.

Previous: Feature Freshness Next: Feature hashing