DeepSeek-V4.1 Data Recipe and Key Features

From DeepSeek-V4.1-Flash:

Instead, our efforts are concentrated almost entirely on what the model is trained on rather than how it is optimized: we invest in large- scale, automated pipelines for data synthesis and environment construction.

Pretraining Data Recipe

Text Data

A shift in philosophy: from the quality of individual samples to the interactions between different corpora and their unique information gains. A few highlights:

1. Design a scaling ladder across model parameter counts x training data volumes;

   • My guess is that they run a series of small models with different combinations of (N parameters, D data volume), measure performance on a common evaluation suite, and fit the trends as scale changes to infer the optimal data mixture before training the full-scale model;
   • This is key to faster iteration, but its effectiveness depends on how well the fitted trends hold up;

2. Filter out content with “low information gain”

   • They give two examples: 1) outputs from weak models and 2) low-quality machine-translated text. They call this content “implicit duplication”: it restates existing information and offers very little information gain for the model.
   • My guess is that they use perlexity + semantic deduplication. For the perplexity approach, FastText could be used for classification and confidence scoring to remove poorly defined content (another option is Fast-DetectGPT). For semantic deduplication, see Large-Scale Text Deduplication Techniques for LLMs.

3. Explore a Model-in-the-loop approach

   • The Report does not explain this in detail. I suspect it concerns text rewrite: introducing a model to continuously improve rewrite quality or the quality of QA data;

4. Introduce more fine-grained domain experts to build more fine-grained quality assessments

Multi-Modal Data

Multimodal data falls into three main categories: Image-Text Pair, Image-Text Interleave, and Domain Specific Data. DS found that its crawler was overly biased toward Text content, so it went back to CommonCrawl to expand multimodal coverage;

• Image-Text Pair: Extract images and alt text from web pages, filter by an image-text relevance threshold, and deduplicate based on image semantics.

  • Image-text relevance can be assessed with CLIP/DataComp (mapping to the same emb space). There are other approaches too, such as SIEVE, which has a model describe an Image and then uses the caption for semantic comparison, or BLIP. Semantic filtering for images is no different from semantic filtering for text;

• Image-Text Interleave: Primarily sourced from web pages and PDFs. Since multimodal processing has high CPU/disk overhead, the construction pipeline is split into stages: heuristic + statistical filtering -> deduplication -> quality model screening -> assembling interleave data -> a second round of filtering and deduplication -> strict quality scoring with SmolVLM;

Post-Training Data Recipe

Data Synthesis Methodology

The biggest challenge in data synthesis is “finding good Tasks.” This capability essentially forms each foundation model company’s moat in a particular domain, such as Zhipu’s Coding capabilities or Kimi’s knowledge tasks.

Deepseek addresses this by training two models:

• Task Constructor: The goal is to construct Tasks that are neither too hard nor too easy;
• Task Solver: The goal is to assess Task difficulty;

This resembles the idea in Absolute Zero: Reinforced Self-play Reasoning with Zero Data: have the same model both propose and solve problems, verify coding tasks with an execution environment, and estimate success rates through multiple solution attempts.

• No reward if all attempts succeed or all attempts fail
• Otherwise, the lower the task success rate, the higher the reward

General Agent

1. Encourage employees to integrate the latest models into their daily workflows and submit interaction data and feedback.
2. Based on the interfaces observed in the submitted data, construct a large collection of mocked tools that replicate the input formats, output structures, APIs, behavioral constraints, and other properties of real tools/systems, covering common SaaS products, enterprise applications, and specialized business backends.
3. Collect negative feedback and failure cases submitted by internal employees at scale, then generate environments for single-turn and multi-turn Agents. This systematically exposes the model to failure cases and enables targeted RL on its weaknesses.

I think there is a useful insight here: In everyday conversations, most data/questions are actually “junk data,” such as vague instructions or simple factual questions. Data drawn from employees’ day-to-day work, by contrast, is already high-quality data grounded in real use cases.

Anthropic’s records from that period offer a useful reference:

The Summer 2025 Sabotage Risk Report explicitly states:
- Employees use Claude.ai and Claude Code in their daily work.
- They report unusual behavior through in-product thumbs-down buttons and internal feedback Slack channels.
- Automated offline monitoring also covers most internal Claude Code usage, with a small sample of records audited manually.

For reconstructing environments from trajectory data, see Alibaba’s earlier work, Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments: instead of aiming for large, all-encompassing environments, reconstruct the conditions necessary for a trajectory and synthesize from there. This better reflects customers’ real use cases.

Coding Agent

Two data sources:

1. Select highly complex tasks or tasks where the model performs poorly from employees’ and partners’ Coding Agent sessions, then deduplicate by trajectory.
2. Public Github repositories that meet a star count threshold

Specialized Agents collaborate to construct the environments:

• One Agent determines whether a project can build and run in a container and whether it can be verified automatically. If so, it selects a commit as the starting point, designs several sufficiently complex implementation directions, produces evaluation criteria and a build report, and retrieves external resources as needed.
• Another Agent configures dependencies in the container, sets up the initial working directory, prepares test code and task descriptions, runs its own tests, and removes traces that would reveal the answer before packaging everything into a new image layer.
• Multiple different Agents attempt the task. An independent quality-control Agent then reviews the environment and solution trajectories for environment issues, factual errors, mismatches between evaluation criteria and task descriptions, and Hack risks.
• If validation fails, a repair Agent fixes the issues, adjusts evaluation criteria that are too easy or too hard, and sends the environment through validation again.

OPD

OPD operates over the full vocabulary with 40+ Teacher models, because the best teacher for each domain may come from a different development stage and may even have a different architecture from the student. The infrastructure supports an almost unlimited number of teachers, with low-cost switching between heterogeneous teachers (enabled by inference infra optimizations such as caching Teacher inference hidden states and rearranging samples).

There are substantial improvements over V4 here:

A single OPD cycle

Student generates its own solution trajectory
           ↓
Teacher reads the trajectory and predicts distributions for the same prefixes
           ↓
Compute reverse KL between the Student and Teacher full-vocabulary distributions
           ↓
Backpropagate and update the Student