Why Large Language Models Misidentify Their Own Identity: Knowledge Distillation, Synthetic Data, and Corpus Pollution

    A large language model does not actually "know" who it is; when it describes itself as a different model, the cause is almost always a polluted training pipeline rather than emerging self-awareness. This article examines the three main technical causes of identity misattribution — model-generated text mixed into the training corpus, residual teacher signals from knowledge distillation, and mixed-provenance instruction-tuning data — and then works through the related concepts of knowledge distillation, the synthetic-data quality paradox, recursive training and model collapse. It closes with a sample synthetic-data filtering pipeline, a set of corpus governance practices (source traceability, quality tiering, deduplication, human review, and distribution monitoring), an explanation of how domain specialization forms, and practical recommendations for developers.

    Large language models do not actually “know” who they are. What they emit is a probability sample drawn from the training distribution. When a model repeatedly claims to be a different model, there are usually a few technical causes behind it.

    Over the past several years, as training methodology has evolved, one phenomenon has attracted considerable attention: certain models exhibit “identity misattribution” when describing themselves, mistakenly believing they belong to a different model family. The behavior looks like a curiosity, but it is in fact an excellent entry point for understanding how modern LLM training works. It sits at the intersection of knowledge distillation, synthetic data, and corpus pollution. This article analyzes these concepts systematically from an engineering and algorithm perspective, and discusses how developers should respond to them rationally.

    1. The Technical Nature of “Identity Misattribution”

    A large language model does not genuinely know its own identity. Its output is the result of probability sampling from the training distribution. When a model frequently claims to be another model, the causes are typically technical:

    • Model-generated text has entered the training corpus. If responses produced by other models were introduced during data collection without adequate cleaning, self-referential statements such as “I am model X” are learned as ordinary corpus content.
    • Residual teacher signals from distillation. Knowledge distillation makes a student model imitate the output distribution of a teacher model. If the teacher’s identity statements are imitated along with everything else, the student may misattribute its own identity when describing itself.
    • Mixed provenance in alignment and instruction-tuning data. If the question-answer pairs used for instruction tuning come from third-party models, identity-related answers are inherited as well.

    Identity misattribution is therefore not evidence of self-awareness. It is a symptom of identity signal pollution somewhere in the training data pipeline. Understanding this is the prerequisite for the discussion that follows.

    2. Knowledge Distillation: The Common Path for Capability Transfer

    Knowledge distillation is a technique for transferring the capability of a larger model (the teacher) to a smaller model (the student). Its core idea is to have the student learn the teacher’s “soft labels” — the probability distribution the teacher assigns to possible outputs — rather than hard labels alone.

    Distillation is widely adopted for three reasons:

    1. Lower deployment cost. The student model has fewer parameters and lower inference latency, which suits resource-constrained deployment scenarios.
    2. Retained generalization ability. Compared with learning only hard labels, soft labels carry information about the relative relationships between classes, which helps the student generalize better.
    3. Fast acquisition of specific capabilities. In vertical directions such as programming and reasoning, distillation lets a small model approach teacher-level performance comparatively quickly.

    It is worth emphasizing that distillation is a mature and legitimate technique in the industry. Capability transfer across models and across teams is not unusual in itself; what matters is the quality and compliance of the transferred data. When the distillation corpus has clear provenance and controllable quality, distillation is an effective way to improve model efficiency.

    3. Synthetic Data: Opportunity and the Quality Paradox

    Synthetic data refers to data generated automatically by models for training or fine-tuning. It has clear value in alleviating real-data scarcity, reducing cost, and protecting privacy. However, synthetic data carries a frequently overlooked “quality paradox”:

    • High-quality synthetic data, produced with rigorous generation, filtering, and validation, can effectively supplement the training distribution and improve model performance on specific tasks.
    • Low-quality synthetic data, introduced in large volumes without filtering, can inject noise, bias, and factual errors, diluting the value of the originally high-quality corpus.

    The key issue is that the quality of synthetic data depends heavily on the model that generated it. Using a flawed model to generate data and then training a new model on that data amplifies and hardens the flaws.

    4. The Risks of Recursive Training: Model Collapse and Corpus Pollution

    When low-quality synthetic data is used repeatedly to train subsequent models, it creates the vicious cycle of “recursive training,” which the research literature calls “model collapse.” Its symptoms are:

    • Output diversity declines progressively, and long-tail content gradually disappears;
    • Factual errors are reinforced repeatedly as errors accumulate;
    • The model converges toward a small number of high-frequency patterns, degrading creativity and accuracy at the same time.

    This phenomenon reveals an important principle: the value of a corpus lies not in its size but in its quality and diversity. Repeatedly “re-consuming” low-quality synthetic data does not improve a high-quality corpus — it pollutes it. A healthy training-data ecosystem must be built on continuous monitoring of data sources, generation methods, and quality distribution.

    The following illustrative pipeline shows how synthetic data can be gated at the engineering level:

    1. # Illustrative pipeline: deduplication and quality filtering of synthetic data
    2. def filter_synthetic_samples(samples, quality_scorer, threshold=0.8):
    3. """
    4. Score and near-duplicate-filter synthetic samples.
    5. - quality_scorer: quality evaluation function returning a score in [0, 1]
    6. - threshold: quality threshold; samples scoring below it are discarded
    7. """
    8. kept, fingerprints = [], set()
    9. for sample in samples:
    10. score = quality_scorer(sample)
    11. fp = near_duplicate_fingerprint(sample) # near-duplicate fingerprint
    12. if score >= threshold and fp not in fingerprints:
    13. kept.append(sample)
    14. fingerprints.add(fp)
    15. return kept

    The core idea here is that before synthetic data enters the training pipeline, it must pass two gates: quality evaluation and deduplication, so that low-quality and duplicate samples do not pollute the corpus.

    5. Building High-Quality Corpora and Data Governance

    Avoiding model collapse requires a systematic corpus-building mechanism at the data governance level:

    1. Traceable provenance. Every record should capture its source, generation method, and collection time so that it can be audited and traced back.
    2. Quality tiering. Data should be graded by quality, with high-value corpora prioritized for core training and low-quality data used only as a supplement or after cleaning.
    3. Deduplication and denoising. Near-duplicate detection, anomaly detection, and similar methods should be used to remove redundant and erroneous samples.
    4. A human validation loop. For critical domains, human review should be introduced to form a “generate — evaluate — correct” loop.
    5. Continuous distribution monitoring. Monitor drift in the training-data distribution to prevent any single pattern from becoming over-concentrated.

    Implementing this governance system on the cloud typically relies on general-purpose capability categories: object storage to hold raw and processed corpora, a message queue to drive asynchronous execution of data-processing pipelines, a container platform to host training and evaluation workloads, and logging and monitoring/alerting services for continuous observation of data-quality metrics. General cloud products of this kind, such as those offered by Baidu AI Cloud, can serve as the underlying foundation for a data governance system.

    6. How Domain Expertise Forms

    A common observation is that different models excel in different domains. Some models perform notably on Chinese text creation, while others invest continuously in programming. This is not accidental; it is determined by the distribution of training data:

    • Data mixture determines capability orientation. If one domain accounts for a large, high-quality share of the training corpus, the model will naturally be stronger there.
    • Specialization requires targeted optimization. Programming capability depends on large amounts of high-quality code corpora and execution feedback, while Chinese writing depends on rich natural-language corpora and an understanding of cultural context.

    This also explains why cross-domain capability transfer is rarely “free” — when a platform calls or distills corpora from another source for a specific direction, that is a reasonable engineering trade-off, provided the source is compliant and the quality is controllable.

    7. Practical Recommendations for Developers

    Drawing the discussion together, here are several practical recommendations for developers:

    • Distinguish distillation from plagiarism. Distillation is a legitimate technique, but corpus provenance must be clear and compliant.
    • Put data quality first. It is better to train on less but higher-quality data than to retrain repeatedly on massive volumes of low-quality synthetic data.
    • Build a closed data governance loop. Form a complete chain from collection and cleaning to evaluation and monitoring.
    • Take a rational view of capability gains. Improvements in model capability come from the combined effect of data, algorithms, and compute; there are no shortcuts.

    Conclusion

    “Model identity misattribution” is only the surface phenomenon. Behind it lie real technical topics: knowledge distillation, synthetic data, and corpus governance. The real lesson for developers is this: what determines the ceiling of a model has never been the quantity of data, but its quality and the level of governance applied to it. Establishing trust in data sources, control over quality distribution, and vigilance against degradation risk is what puts large-model capability improvement on a sustainable footing.