There’s a reason experienced data scientists spend more time on data than on models: a sophisticated model on bad inputs is worse than a simple model on good ones — it’s confidently wrong. In compliance, confidently wrong means missed risk or unjustified decisions. Profiling is where trustworthy modeling starts.
What to profile
For every field feeding a model, you want to know:
- Completeness — fill rate and missing values. A “risk score” field that’s 40% empty isn’t a feature, it’s a trap.
- Distributions — min, max, median, quartiles. Outliers and impossible values (a birth year of 1017) surface here.
- Cardinality and top values — is a “country” field ten clean codes or three hundred inconsistent strings?
- Zeros and negatives — often a sign of defaulting or data-entry errors masquerading as real values.
- Dates — ranges and gaps that reveal ingestion problems.
KeplerAI computes these per-field KPIs automatically during data ingestion, and again inside the Lab via the Copilot’s Profile tab.
Why profile near the data
Profiling reads every row. Doing it in a vendor cloud means exporting the full dataset — the opposite of what you want. In KeplerAI, profiling runs inside your data plane; only the resulting statistics (not the rows) inform the AI agents. The agents get exactly what they need to generate good code, and nothing they don’t.
Profiling as a control
Beyond model inputs, profiling is a control in its own right. Sudden shifts in fill rate or distribution flag upstream data problems before they corrupt a scenario — the input-side complement to model drift monitoring.
Good models begin with understood data. Profile first, model second. See the platform capabilities.