TECH Signal 500
DeepSeek: Reverse Engineering an AI Assistant by Interviewing Itself
↗
Engineers interviewed DeepSeek to elicit its self-description of architecture and behaviour, then compared those statements to publicly available papers.
This practice shows how a model’s own introspection can guide prompt design and trust calibration. It also highlights the gap between what a model can safely report and what must be verified in the literature. Engineers learn where to rely on the chat for behavioural cues and where to consult papers for precise specifications.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
The model separates its answers into observation, inference, and guess when describing itself.
It explicitly states that it cannot see its own weights, routing, or attention maps.
For exact architecture numbers engineers should refer to arXiv papers, using the chat mainly for intuition about behaviour and prompting.
THE READ
What the cluster adds up to.
The interview prompted DeepSeek to organise its self-knowledge into three buckets: what it directly observes, what it infers, and what it guesses. This structuring makes it easier for an engineer to spot where the model is confident and where it is uncertain. By treating the chat as a source of behavioural insight rather than a specification sheet, engineers can avoid over-reliance on self-reported numbers.
When asked about hidden internals, the model said it has no access to its weight matrices, expert routing, or attention maps. This limitation means any claim about internal dimensions or precision must be taken as inference or guess, not fact. Consequently, attempts to derive exact layer counts or expert counts from the interview alone will be unreliable.
Public papers provide the concrete architecture details that the model only hints at, such as the mixture-of-experts layout, multi-latent attention, and training pipelines like SFT and RLHF. The chat, however, offers useful cues about tokenisation choices (e.g., BPE tokenizer, RoPE positions), normalisation style (Pre-LayerNorm), and precision tricks (FP8 mixed-precision) that can inform prompt engineering and deployment trade-offs.
Adopting this interview-based method requires time to run the dialogue, parse the model’s self-categorisation, and cross-reference each claim against the literature. It works well for understanding how the model talks about its behaviour and for generating prompting hypotheses. It stops working when precise numeric specifications, internal weight distributions, or low-level implementation details are needed, because the model cannot reveal those and will label them as guesses.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER