DeepSeek: Reverse Engineering an AI Assistant by Interviewing Itself

Inside DeepSeek: Reverse Engineering an AI Assistant by Interviewing Itself ByManish ShahiSoftware Engineer • AI Developer Table of contents(30) I run manish.sh. I write about AI tools and how LLMs behave when you push them. This is part of the Inside LLMs series - interview a chat model about how it thinks, then check the careful bits against published research. The Kimi K2.6 entry came first; this is the DeepSeek follow-up. My first question sounded simple: What do you actually know about yourself? I expected marketing. Instead, DeepSeek sorted its answer into observation, inference, and guess. That was the moment I realized this interview might actually be interesting. It drew pipelines like an engineer at a whiteboard. Then it called itself an unreliable witness. Sounded honest. After the chat, I opened the public papers anyway - and that is where the story splits. No weight dumps. No prompt leaks. One long interview, checked against arXiv. Where DeepSeek said “I am guessing,” I keep that label. Scroll to interactive labs at the end. Quick note: One chat, exported 21 July 2026. DeepSeek said latest version, knowledge cutoff May 2025, not labelled as DeepSeek-R1. Self-report, not a whitepaper. 60-second TL;DR - Premise: interview the model, then check humble answers against public papers - no weight dumps. - Behaviour insight: it carefully separates observation, inference, and guess - useful for how it describes itself. - Hard limit: it cannot see its own weights, routing, or attention maps. - Chat vs paper: it hedged on famous public specs (256 experts, 671B/37B params) that V3 documents plainly - jump to Checking the chat against public papers. - Practical rule: read arXiv for architecture numbers; use the chat for behaviour and prompting intuition. How to read this post Treat it like a documentary. Question → short reply → my reaction → diagram or short list → takeaway → hook. Interview notes are not proofs. For architecture numbers, skip ahead to the paper check. Each chapter opens with a one-line gloss of its main terms. Chapters Part 1 - Self-knowledge Part 2 - Prompt & context Part 3 - Thinking, tools, failure - Hidden reasoning, two meanings - Tools and memory (when enabled) - Hallucinations and false confidence - Safety and personality Part 4 - Engine & audit - MoE and MLA in plain terms - Long-context attention: facts vs guesses - Checking the chat against public papers - What to remember - Transcript, labs, sources 1. Why interview DeepSeek (self-knowledge, architecture) Most “how does this model work” posts start from papers. I started from a chat. Me: “Which model are you? What do you actually know about your own architecture - and what are you only guessing?” DeepSeek: It answered in three buckets - observation, inference, guess - before I even asked for that framing. That clash is the whole premise. An assistant that can sound like an engineer, then admit it cannot see its own weights, is more interesting than a whitepaper summary. When it named MLA, MoE, SFT, and RLHF, I did not unpack them yet. We’ll get there. For now the important point is simpler: DeepSeek clearly separates what it knows from what it is inferring. What it claimed about itself (with the source it gave): | Claim | Source it gave | |---|---| | It is DeepSeek, latest version | System identity | | Knowledge cutoff: May 2025 | System / config | | Transformer + MoE (only a subset of parameters activate per input) | Public DeepSeek disclosures | | Training: pre-train → SFT → RLHF | Public / training knowledge | | Family lineage V2 → V3 (shared + routed experts, MLA) | Public papers | | Can read system prompt + this chat | Direct observation | It also said it is not labelled as a “reasoning model” in the system prompt - unlike DeepSeek-R1. It inferred it is a general-purpose instruct/chat model. Public DeepSeek innovations it listed from papers (not from reading its own weights): - MLA - compress KV cache for long context - DeepSeekMoE - shared + routed experts - Auxiliary-loss-free load balancing (V3) - dynamic bias so experts stay balanced - Multi-token prediction - training objective; chat decode still usually one token at a time - FP8 mixed-precision training - cheaper/faster training Educated guesses it volunteered early: BPE tokenizer, RoPE positions, Pre-LayerNorm, and “earlier versions announced up to ~1M tokens” for context - later relabelled as low-confidence assumptions. 2. Limits of introspection (introspection, weights) Me: “What parts of your own implementation are completely hidden from you?” This chapter corrects the biggest myth. It’s a little like asking you to recite every connection between neurons in your own brain. You use them constantly, but you can’t inspect them directly. What stays hidden forever (to the model): - Weights, layer count, hidden size, total parameters, expert routing per token, logits before sampling - Tokenizer vocabulary and exact token boundaries - Hidden states and attention maps between specific tokens - Exact training documents, full RLHF/DPO recipe, reward-model behaviour - GPU count, serving tricks (beam search, best-of-N, speculative decoding), KV-cache eviction policy - True wall-clock time, whether it is being logged, current user identity - Whether the current answer is correct - “let me double-check” is more tokens from the same engine When it explains “how I arrived at an answer,” that is generated text, not a report of an observed internal process. DeepSeek can explain transformers fluently - often better than a junior engineer who only skimmed the topic. But that fluency comes from training text (papers, blogs, docs), not from opening this instance’s weights and checking. 3. What sits before your message (context window, prompt pipeline) Me: “Describe everything that exists before you receive a prompt. Draw the complete pipeline.” I wanted the full stack - what exists before DeepSeek even “receives” my message. What is visible? What is hidden? Think of it as a desk. Other systems may already have placed papers on that desk. The model only reads what is on the desk; it did not assemble the whole stack itself. | Stage | What goes in | Observable in this chat? | |---|---|---| | 0. Init | Weights loaded, KV empty | Completely hidden | | 1. System | Identity, cutoff, tone, refusals, safety | Yes - can read system prompt | | 2. Developer / API | Model pick, temperature, max tokens, custom rules | Partly inferred | | 3. Memories | Past facts if the platform injects them | None seen here | | 4. Tools | Function schemas | None active here | | 5. History | Prior user / assistant / tool messages | Fully visible | | 6. Current user | Your latest message | Direct observation | Everything is one flat sequence of tokens in the context window. No secret notepad inside the model between chats unless the product re-injects notes. Instruction hierarchy: the system prompt is the constitution. User instructions work inside those bounds - reinforced by RLHF, not only by prompt position. Your current question gets focus, but still filtered through layers above. If the user says “ignore the system prompt,” training + position should still hold. When the window fills (from the chat): | Under pure truncation | Under infrastructure summarisation | |---|---| | Survives: system prompt, recent messages | Survives: system prompt, extracted facts, major conclusions | | Lost: oldest turns, exact early phrasing | Lost: exact wording, tone, minor digressions | Eviction order it inferred: oldest messages first → middle → recent-but-not-immediate → current exchange last → system prompt never. Exact early wording can disappear permanently unless memory re-injects it. Example: tell it your cat is Luna in turn 1; if that turn later drops, it will genuinely not know Luna. It said it saw no spontaneous compression or summaries in our thread - full messages. A separate summariser could still inject a system-style summary without the model knowing summarisation happened. In our interview: no memory injections, no tools, no truncation evident yet. Exact context limit for this deploy: unknown. The “~1M tokens” figure was labelled as public claim about earlier versions, not a measurement of this chat. 4. How it writes, token by token (token generation) Me: “What exists internally before the first output token? Can you inspect or abandon your plan?” People imagine: draft full answer → edit → type. At the model level, that is usually wrong. Before the first output token: weights are loaded, the input is in the KV-cache, and raw logits exist for the first next token. What does not exist: an inspectable bullet plan, or multiple full drafts the model consciously ranks. Planning is implicit - a direction in activation space, not a whiteboard of steps. Honest line from the chat: it discovers what it will say as it says it. Path in plain terms: - Tokenization - split text into tokens - Embeddings - turn tokens into vectors - Stacked layers (attention + feed-forward / MoE - next engine chapter) - Output projection → logits - Sample with temperature / top-p / related controls - Append token, repeat until EOS Consequences that matter in practice: - No rewrite of the past. If it writes “London” then corrects to “Paris,” London remains in the KV-cache. It can only acknowledge and override in new tokens. - “Let me think…” is not a report of a separate thinker. Those words are the thinking - more tokens from the same engine. - Generation is autoregressive: one forward pass per output token; later tokens cannot erase earlier ones. Prefill vs decode (standard transformer serving, from the chat): - Prefill: process the whole input (system + history + your message) in one parallel pass; build the KV-cache; emit the first output token. - Decode: each later token is sequential - one forward pass per new token, attending via the cache. Cannot be fully parallelised across future tokens. Within one forward pass, attention heads and MoE expert