The Model Does Not Remember Your Conversation
Even a conversation that flows as smoothly as ChatGPT’s is, from the model’s point of view, brand new on every turn. The application re-attaches the entire prior conversation as a single input each time, and the model reads that block as if seeing it for the first time before predicting one next token. What looks like ‘memory’ is not a property of the model but a consequence of a service design that keeps resending the conversation history.
This structure produces two practical consequences. The longer the conversation grows, the more text has to be resent, filling the context window — and as input tokens increase, so does the cost of every turn. That is why, in any service handling long conversations, deciding how much history to carry and where to summarize it is not a convenience feature but something to design from the outset.
Open the Tokenizer and Korean’s Disadvantage Becomes Visible
A model does not read characters as they are; it slices text into pieces called tokens. Open a tokenizer yourself and the differences between languages come into view. The Korean greeting “안녕” splits into two tokens, “안녕하세요, 어떻게 지내세요?” is cut into eight, while the comparable English “How are you?” ends at six.
Because a tokenizer’s vocabulary is built on English-heavy corpora, Korean spends more tokens to carry the same meaning. As a result, the same-sized context window holds less Korean content than English, and the cost — charged per token — runs higher too. If you are planning a Korean-language AI service, this disadvantage is a constraint to account for at the starting line, before you add a single feature.
Hallucination and Output Variance Can Be Reproduced in a Few Lines of Code
A scene in which the model plausibly describes the contributions of a non-existent 2019 paper can be built directly in just a few lines of code. For the model, continuing with a next token that fits the context is more natural than answering ‘I don’t know.’ Hallucination is not a sign of a broken model; it is the visible surface of a mechanism that chooses the next token by plausibility rather than by truth.
Even for the same question, the output swings widely with settings and instructions. Raise temperature from 0.1 to 1.8 and the same input produces completely divergent answers; change one line of the system prompt and the same black-hole question is answered in one voice by a science teacher and in another by Socrates. Once you grasp that output is not a single correct answer but a function of settings and instructions, your stance toward prompts and parameters changes.
Hearing an Explanation and Seeing It on Screen Carry Different Weight
These phenomena carry different weight when heard as an explanation versus seen firsthand on screen. Someone who has watched, even once, the tokenizer break Korean into finer pieces, or the answers diverge as temperature rises, stops blaming the model for hallucination and instead attaches verification steps to the output and begins treating history management of long conversations as a design task.
This is exactly why SH Consulting’s AX training insists on live code demonstrations even for non-developers. Knowing a principle in the abstract and reproducing that principle yourself in a few lines of code lead to different downstream decisions. Neither mystifying the tool nor vaguely fearing it, but using it with an awareness of its limits and a hand on its controls — that begins here.