How can you find out what data an LLM was trained on?

Separate training data from information supplied at answer time

"What was this model trained on?" can mean several different things. A reader might want to know whether a particular work was included, whether the model has broad knowledge of a domain, whether customer prompts are used for future training, whether a licence permits a use case, or whether the model can answer from an approved source instead of from its general training. These questions need different evidence.

First identify the artifact precisely. Record the provider, public model name, version or release date, model identifier or API snapshot, modality, base versus instruction-tuned status, and any fine-tune or adapter applied by your organization. Also record the product path. A model deployed behind a chat application may have retrieval, browsing, tools, system instructions, safety filters, and a changing server-side model snapshot that are not part of the downloadable weights. A statement about a brand is weaker than a statement about that exact released version.

Then separate three things that are often blended together. Training data changes a model's weights during pretraining, continued training, fine-tuning, preference training, or reinforcement learning. Inference context is what the model receives when answering, including the prompt, system instructions, retrieved passages, tool results, and conversation history. Product data use is the provider's policy about whether user inputs, feedback, or outputs may later be retained or used to improve future systems. A policy about your API prompts is not a complete description of the original training corpus, and a training-data card does not by itself establish how a hosted product handles your new data.

What counts as useful evidence

No single document is enough for every purpose. The practical aim is a traceable evidence record in which every claim has a source, scope, date, and confidence level. The most useful documents are below.

Model cards are a good first stop because they are intended to accompany a model with information about its use and evaluation. The original model-card proposal recommends documentation of performance, intended use, and relevant details, but it does not guarantee that every publisher supplies a complete corpus inventory. The model-card paper explains the purpose and limits of the format. On Hugging Face, a model card is normally the repository README and the platform's guidance says it should describe training datasets, parameters, intended uses, limitations, and evaluation results. See the Hugging Face model-card documentation.

For every named training dataset, follow the link one level deeper. A dataset card, datasheet, or data statement can reveal information that a model card cannot: how data was collected, which languages or communities are represented, whether it was modified, and what use restrictions or gaps exist. The Datasheets for Datasets proposal calls for documentation of a dataset's motivation, composition, collection process, and recommended uses. Read the paper. Bender and Friedman's data-statement work similarly argues for documenting language varieties and other context that affects how far a system's claims can generalize. Read Data Statements for NLP.

Read the disclosures for each training stage

The phrase "training data" hides a sequence of distinct data uses. A useful record has a row for each stage.

Pretraining

Pretraining teaches a base model broad patterns of language, code, images, or other modalities using very large collections. A disclosure might name web documents, books, licensed archives, code, academic material, multilingual text, images, or synthetic content. It may give token counts and a cutoff date. This establishes a broad description of inputs, not necessarily a complete list of every URL, document, or data subject.

For example, the Gemma 3 model card describes a mix of web documents, code, mathematics, and images, gives a training-data cutoff date and token totals by model size, and describes filtering. It is more informative than an undocumented release, yet it is still a category-level disclosure rather than a public, item-by-item corpus manifest. This is a useful distinction when a question concerns a specific source.

Continued training and domain adaptation

A provider or downstream organization can continue training a base model on additional domain material. This can change vocabulary, factual associations, style, language coverage, or task performance. A model that began with a documented open corpus may therefore have a later checkpoint with an additional private or licensed data mix. Ask whether the documentation covers the base checkpoint, the continued-training checkpoint, or both.

For a tax, medical, legal, financial, or internal-business use case, this stage often matters more than broad internet coverage. An organization should request the source categories, date range, data owner, licence or other legal basis, filtering, evaluation, and version for each domain adaptation. Do not infer that a model is current in a specialist field merely because it is generally capable with language.

Instruction tuning and preference training

Instruction-tuned models are trained further to follow requests, use a chat format, call tools, refuse unsafe requests, or produce particular styles of response. The additional data can include demonstrations written by people, licensed material, contractor annotations, user data collected under a relevant policy, synthetic examples, preference comparisons, and evaluator feedback. This stage can strongly affect what users see even if the base model is unchanged.

Look for language such as supervised fine-tuning, instruction data, preference data, reinforcement learning, reinforcement learning from human feedback, or synthetic data. Note whether the claim is specific to a model version. A generic provider statement is not proof that any particular product tier used every listed source, but it is still valuable context when correctly labelled as a provider-level disclosure.

Retrieval, tools, and product context

RAG does not retrain the model. It searches an external corpus at answer time, adds selected passages to the context, and asks the model to answer with that evidence. Browsing, databases, code execution, and other tools similarly provide run-time information. They can make an answer more current and auditable, but they may introduce sources the model never saw during training. See Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.

This distinction is especially important for the observed question's tax-return example. A general language model may understand how to write, summarize, and follow an instruction, yet it should not be treated as the authority on current tax rules. A well-designed system retrieves the applicable official tax guidance, identifies the version and jurisdiction, presents citations or excerpts to the user, and declines or escalates cases outside its scope. The model's broad pretraining helps it use the retrieved material, while the retrieval source supplies the current domain evidence.

Open weights and closed models have different evidence paths

"Open model" has no single meaning. A project may publish weights, source code, a licence, an evaluation report, a training recipe, a dataset list, a dataset download, or all of them. Those are separate artifacts. A model with downloadable weights can remain opaque about its data; conversely, a hosted model can publish unusually detailed documentation without releasing its weights.

Use the following comparison as a decision aid.

Fully reproducible projects offer the strongest public path to learning about a training mix. Ai2 describes its OLMo model flow as publishing training data, code, weights, and recipes, and its Dolma documentation describes an openly downloadable pretraining corpus and processing toolkit. See the OLMo 3 documentation and the Dolma data documentation. That does not mean every source document in a web-scale corpus is easy to inspect or that all provenance questions disappear. It does mean an auditor has far more concrete artifacts to examine.

At the other end, proprietary providers often disclose source classes rather than a corpus list. OpenAI says its foundation models are developed from publicly available information, data accessed through third-party partnerships, and data provided or generated by users, human trainers, and researchers. See its foundation-model development explanation. Anthropic's Transparency Hub provides model-specific high-level training-data categories and some cutoff dates for its releases. See the Transparency Hub. These disclosures are meaningful evidence of categories and policies. They should not be rewritten as claims that every included web page or licensed item is publicly known.

Licences, rights, and provenance are separate questions

Training-data provenance asks where material came from and how it moved into the training process. Licensing asks what permissions and conditions attach to a dataset, a source work, the model weights, or a hosted service. A model's download licence may permit use of the weights while saying nothing about licences for every item in the original training set. A dataset's own licence may impose attribution, share-alike, noncommercial, database, or other obligations that do not automatically transfer in a simple way to a model user.

For procurement or legal review, record the exact document rather than reducing it to a word such as "open." Save the model's terms, named dataset terms, provider privacy and data-use policy, documentation date, jurisdiction, and any contract terms offered to your organization. If rights in a particular work, a privacy request, copyright compliance, or regulated use matter, involve qualified legal and privacy professionals. Documentation can inform that work, but it is not a legal conclusion about a disputed training corpus.

Regulatory summaries may become another source of evidence, but their scope matters. In the European Union, the Commission says providers of general-purpose AI models covered by Article 53 must make a public summary of training content using its template. The template calls for general information, data-source categories including public, private, scraped, user, and synthetic data, and relevant processing information. It is a transparency baseline, not a promise of a public list of every individual training item or a determination that every model worldwide falls within the rule. See the Commission's current template FAQ.

What output probing can and cannot tell you

People often ask a model for a rare passage, a private name, a page title, or an unusual error, then treat the answer as evidence of training inclusion. This is not a reliable forensic method. Language models can generalize from related text, infer a likely answer, have information in the current prompt, retrieve information through an enabled tool, imitate a source they were never trained on, or hallucinate a convincing citation. A product's system prompt, browsing feature, retrieval index, safety layer, and sampling settings can all change what appears in output.

Conversely, a refusal, a wrong answer, or an inability to continue a passage does not prove absence. The relevant data might have been filtered, deduplicated, represented only indirectly, forgotten during optimization, inaccessible under the chosen prompt, blocked by a safety measure, or overwhelmed by later training. A single response does not identify all the training examples that may have influenced it.

Research methods such as membership inference and training-data extraction can sometimes identify evidence of memorisation or unusual exposure under controlled conditions. They require a carefully defined threat model, statistical methodology, baselines, and ethical review. They can support an investigation but cannot establish a complete corpus from black-box responses. Do not paste confidential or personal material into a third-party model merely to test a provenance hypothesis, and do not solicit copyrighted text for reproduction. Start with provider documentation and permissioned records instead.

Generated citations deserve the same caution. If a model cites a paper, dataset, or URL, open it and verify that it exists and supports the claim. A citation in output may be a retrieval result, a plausible fabrication, or a known title recalled from training. It is not self-authenticating evidence about the model's source data.

Example

Suppose a team is building a tax-return explainer for residents of one jurisdiction. The team wants a model that can turn a question into plain language, but it must answer only from the tax authority's current guidance. The team sees a general-purpose LLM that performs well in conversation and asks whether it was trained on the tax authority's website.

The team first records the exact model version, deployment date, and provider documentation. It finds a model card that gives only broad training categories, no source-level manifest, and an old knowledge cutoff. The correct conclusion is not "the site was in training" or "the site was absent." It is "the training-data inclusion of this specific site is unknown; the model's general language capabilities are documented at a broad level."

The team then builds a RAG layer over a versioned, approved set of official guidance. Each answer records the source document, date, jurisdiction, and relevant passage. The application tests whether the model cites the retrieved documents, refuses a question when no authoritative source is available, and routes high-stakes cases to a qualified professional. For this application, the team evaluates whether answers follow the current approved guidance. That is a different question from establishing whether a tax page appeared in the model's training data.

A practical documentation workflow

Use this sequence whenever you evaluate a model for a project, procurement decision, research claim, or policy review.

1. Identify the exact artifact. Record the provider, model and version, release date, checkpoint or API snapshot, modality, deployment path, and whether it has been fine-tuned, distilled, quantized, or wrapped in an application.
2. Locate first-party release material. Prefer the model card, technical report, system card, repository, release notes, transparency report, data-use policy, and any regulatory training-content summary. Archive links and access dates because pages and hosted models change.
3. Divide claims by training stage. Make separate entries for pretraining, continued training, instruction tuning, preference or reinforcement stages, synthetic data, and user or contractor data. Write "not disclosed" where a stage is not documented.
4. Follow named data sources. Open the dataset card, data statement, datasheet, repository, manifest, and licence. Record dataset version, collection date, language and geographic coverage, source type, processing, filters, deduplication, sampling, and evaluation-contamination controls if disclosed.
5. Classify each claim. Use labels such as provider statement, version-specific primary documentation, independently reproducible artifact, third-party report, output observation, and unknown. Do not turn a provider statement into verified source-level provenance.
6. Separate training from run-time sources. Document the RAG corpus, search index, tools, system prompt, and product data-retention settings separately from model training. This prevents a current web answer from being misreported as a learned fact.
7. Test the intended task. Evaluate factuality, grounding, language coverage, bias-relevant cases, privacy handling, and failure behaviour against your approved sources. Testing measures fitness for your use, not the contents of a training corpus.
8. Set a refresh trigger. Review the record when the model snapshot changes, the provider updates training disclosures, your RAG corpus changes, a new fine-tune is added, or a relevant law, contract, or licence changes.

Checklist for knowns, claims, and unknowns

The following record is more valuable than an unqualified answer to "what was it trained on?"

Save this record with the model evaluation. It makes a later review possible when a provider changes an API alias, publishes a clearer report, removes a model card, or introduces a new training-data policy. It also helps technical, procurement, legal, privacy, and domain experts discuss the same evidence rather than debating a vague label.

Choosing a model for a RAG application

The observed question asks whether a stock "thin" model can understand language while external RAG provides domain facts. The core idea is sound, with two adjustments. First, there is no universal technical category called thin model. A smaller model may be cheaper and easier to run, but it can have weaker instruction following, reasoning, language coverage, citation use, or ability to synthesize long documents. Second, RAG improves access to current domain evidence only if retrieval finds the right documents and the model uses them faithfully.

Choose candidates based on an evaluation set drawn from the real task. For a tax explainer, include current rules, conflicting historical guidance, ambiguous questions, missing information, multiple languages if relevant, and questions that must be escalated. Measure retrieval recall, citation accuracy, supported-answer rate, harmful overconfidence, latency, cost, and the quality of human handoffs. Compare a smaller general model with a larger one using the same approved corpus and the same system policy. Pick the simplest model and architecture that meet the measured quality and safety requirements.

Require the system to show its work at the product layer: name the source documents, passages, dates, and jurisdiction; distinguish a sourced explanation from a general explanation; and decline to claim a current rule without a source. Do not use model output to decide whether the tax authority's content was in pretraining. Use direct documents for the applied answer, and use training-data disclosures only to understand the base model's provenance, limitations, and procurement fit.