# Dataset

**TL;DR:** A collection of raw or lightly processed data, defined by its contents rather than by any contract about quality, ownership, or support.

A dataset is a bag of data. A table, a set of files, an export, a collection of documents. It has contents and a shape, and that is genuinely all the word promises. Someone produced it, it sits somewhere, and you can read it. Whether it's accurate, current, maintained, or safe to build on is not part of the definition.

That looseness is exactly why the term matters in an era when everything is being called a data product. A dataset is the unit before anyone made commitments about it. There's no owner on the hook, no service level for freshness, no schema stability guarantee, no documentation obligation, and no notice period before it changes or disappears. Plenty of critical business processes are built on datasets that have all of those properties by accident and none of them by agreement, which works right up until the person who happened to maintain it leaves.

In machine learning the word carries additional weight because the dataset is the thing that determines model behavior. Training, validation, and test splits are datasets; so are the eval sets you measure against and the labeled examples you fine-tune on. The properties that matter there are coverage, balance, label quality, and leakage between splits, and the failure modes are subtle: a test set that shares examples with training data reports excellent accuracy right up until deployment.

For teams building AI applications, the practical translation is to be honest about what you have. Most RAG systems are built on datasets, not data products: a folder of PDFs someone assembled, an export from Confluence, a scrape of the support site. Nobody committed to keeping any of it current. When answers start going stale six months later, the root cause is usually that the retrieval corpus was a dataset the whole time and everyone treated it like a maintained product.

The upgrade path is straightforward and mostly organizational rather than technical: name an owner, write down what it contains and excludes, commit to a refresh cadence, version the schema, and tell consumers before you change it. That's the whole distance between a dataset and a data product.

## Why it matters

Confusing datasets with data products is how organizations end up with critical systems resting on unmaintained foundations. Everything looks fine because the data exists and the pipeline runs, and the failure only appears when something upstream changes and nobody was accountable for telling anyone. For AI teams the exposure is higher, because a stale retrieval corpus does not throw an error, it just produces confidently outdated answers.

## Example

A support team builds an AI assistant over a folder of 800 exported help articles. It works well at launch. Fourteen months later, roughly a third of the articles describe a UI that no longer exists, because the export was a one-time snapshot and nobody owned refreshing it. The assistant is not broken and reports no errors. It is faithfully grounding its answers in a dataset that stopped being true.

## Related terms

- [Data Product](https://www.maximem.ai/glossary/data-product)
- [Data Catalog](https://www.maximem.ai/glossary/data-catalog)
- [Data Observability](https://www.maximem.ai/glossary/data-observability)
- [Chunking](https://www.maximem.ai/glossary/chunking)
- [RAG (Retrieval-Augmented Generation)](https://www.maximem.ai/glossary/rag)
- [Knowledge Storage](https://www.maximem.ai/glossary/knowledge-storage)

---

Source: [https://www.maximem.ai/glossary/dataset](https://www.maximem.ai/glossary/dataset)