Comment by derefr | Hacker News Reader

Comment by derefr | Hacker News Reader

Parent Full thread

You already made a faulty assumption — that we're interested in "classifying the data" in the first place.

Maybe we already know everything about the dataset. For example, if it's line-of-business customer data gradually built up by a sales team, then the brains of the salespeople have likely already done all the "implicit classification" needed to generate good questions about the dataset.

And this is, by far, the usual scenario for Business Intelligence questions: someone with "business-domain knowledge", e.g. an executive, has formed an intuitional hypothesis about the data based on their personal experience; and so they ask someone with "data-domain knowledge", e.g. a business analyst or data scientist, to test that hypothesis.

It's actually rare, in my experience, to have a tabular-data dataset that someone is motivated to understand, that doesn't also "come with" a set of people who can already act as (good!) models trained on that dataset, to aid them in that understanding. (Sometimes these people can't find each-other — but they do usually exist.)

AFAIK, having reams of entirely opaque and ill-understood tabular data, such that you need classification/clustering to get started on asking questions, only really happens in the sciences: sensor-network climate data; longitudinal-study medical-outcome data; census data; housing-market data; etc. In other words, it's almost always universities and governments — not businesses — that care about analyzing opaque tabular data.

And that's a key to understanding the constraints in play for choosing models! Because business-driven analyses are usually time-constrained in some way (potentially even needing post-training question-answers to be generated in soft-realtime); while institutional analyses usually aren't. Big difference!

I might be misunderstanding your point, but there's use cases that have repeatedly come up for me in multiple businesses, below being some examples, without getting too specific:

- identify latent features of customers via their behavioral data, to be used for profiling customers or recommending products to them

- within a large amount of customer behavioral data, identify potentially fraudulent behavior

- identify causes of seasonality (e.g. temporal patterns) in the data in order to improve forecasting (sales, traffic, whatever)

In those cases part of the investigation is to initially take a hands-off (unsupervised) approach, so that we can compare our initial top-down hypotheses with actual patterns in the data.

In both of those cases there's considerable (and sometimes adversarial) noise in the data.

Answers to these questions are actually Bayesian statistical models ("what is the probability of Y given a high likelihood of X"), treating these problems as unsupervised classification might work, but that's a very crude way of approaching them.

I wouldn't say it's a crude way of approaching the problem, it's a crude way of solving the problem. Taking the fraud example, taking unsupervised approaches to understanding patterns of the data before you impose assumptions on the data is a very useful process. For example, what might be fraudulent behaviors in the first place, assuming you aren't even sure you know what fraud looks like, or that it's actually all been detected? Your goal there might be to detect latent features period, not look at their predictive power for X.

Having understood that question, and built an understanding of what predicts fraud, you would then graduate to build models to understand the extent to which features predict fraudulence.

My point in context of the conversation is that it's useful in a business context to explore and understand that data.

I'm really not clear on why you're arguing against this. A proper data warehouse tackles the known unknowns, i.e. supervised learning. But you can glean new insights using unsupervised learning, like the textbook example of Target knowing a woman is pregnant based on sales data.

https://www.forbes.com/sites/kashmirhill/2012/02/16/how-targ...

>You already made a faulty assumption — that we're interested in "classifying the data" in the first place.

It's not clear what your point is. If you're not interested in the predictions that tree-based models provide, do not use tree-based models on your tabular data. A predictive model and a SQL query are not the same thing.

Data teams in companies often aim to enable the answering of future questions nobody has asked yet, by creating denormalizations of their data that offer maximum flexibility in what classes of questions they can answer. Maximum "power."

Lately, that means they're often spending a lot of resources (and even novel R&D time!) getting various kinds of ML models trained on the data.

My point is that this is often pointless, because, given the type of data they're working with (tabular, quantitative line-of-business data), they won't actually see "arbitrary questions"; they'll see the strict subset of arbitrary questions that could have been solved just as well — if not much better! — with a SQL query. And for much less capital expenditure — because the LOB data usually already lives in an RDBMS in the first place.

Reply on news.ycombinator.com