How System Prompts Shape LLM Conversational Personas

1. The Underrated Engineering Variable: Conversational Persona Is a Product Requirement

When discussing model capability, teams often focus on three layers:

• the base model’s parameter scale and data quality;
• post-training preference distributions, such as instruction tuning and human feedback alignment;
• inference-side sampling strategies.

However, in a real conversational product, there is another layer that is often treated as mere “copywriting detail” but actually affects many experience metrics: the system prompt.

A system prompt is an invisible preprocessing step that occurs before the user-visible conversation begins. It constrains a model from being a generic probability distribution into an interactional entity with a stable identity, stable boundaries, and a consistent expression style. It does not change the model’s knowledge capacity, but it significantly changes how that knowledge is invoked and expressed.

In industry practice, master prompts with tens of thousands of tokens are not uncommon. The value of such long prompts is not their length, but their ability to make many implicit product judgments explicit: which topics should be followed, which should be corrected, which should be refused, what tone should be used during corrections, and how conflicts between rules should be resolved.

2. Turning Two Conceptions of Truth into Executable Prompt Rules

In a public technical interview, a practitioner responsible for model persona design mentioned an interesting tradeoff: if a model overemphasizes “empiricism” and “scientific correctness,” it can easily degrade into an unempathetic correction machine. This observation corresponds to two different philosophical traditions about truth and meaning.

The analytic tradition emphasizes logical clarity, linguistic precision, and propositional verifiability. It naturally fits tasks such as code generation, data querying, factual question answering, and technical document review. In these scenarios, the acceptance criteria are themselves decidable: if the answer is correct, it is correct; if it is wrong, it is wrong. The stronger the model’s correction ability, the higher the product value.

The continental tradition is less concerned with the truth value of propositions and more concerned with meaning, situation, and historical context. It acknowledges that, beyond “verifiable facts,” there are also ways of understanding existence, experience, and value. Such expressions appear in conversation more often than one might expect. For example, when a user says, “The fountain is the source of life,” they are not discussing fluid dynamics. They are expressing a feeling about urban space and vitality.

Translated directly into prompt rules, these two traditions yield an executable engineering principle: first identify the type of discourse, then choose the response mode.

The key point is not to make the model abandon factual accuracy, but to help it distinguish between “empirical claims about the world” and “exploratory, metaphorical, or normative perspectives,” and then adjust the focus and tone of the response accordingly.

3. Why “Fact-Correcting by Default” Fails: A Semantic-Level Mismatch

Why does an “empiricism-first” approach often lead to a poor user experience? The root cause is a level mismatch.

In pretraining corpora, expression patterns that “correct another person’s factual error” are extremely dense: forums, Q&A communities, popular science content, and comment sections. Therefore, when a user inputs a sentence with metaphorical or poetic color, the model’s most likely continuation path is to judge it as a “factual error → provide the correct definition.”

Human feedback alignment can further strengthen this tendency. If annotators treat “providing accurate information” as a bonus, the model will proactively correct any statement that could possibly be judged as wrong.

This leads to several typical failure modes:

• The user expresses a value judgment, but the model rebuts it as if it were an empirical proposition.
• The user is making a poetic statement, but the model inserts a scientific explanation and breaks the flow of the language.
• The user is seeking resonance, but the model provides definitions and boundary conditions, and the conversation ends.

From an experience-measurement perspective, the cost of these failures is not reflected in “whether the answer is correct,” but in turn depth, session retention, and human takeover rate. In an interactive product, a correct but uncomfortable answer is functionally equivalent to a failure.

4. Implementation: Adding “Utterance-Type Routing” to the Prompt

A recommended approach is to split the prompt into a layered structure with single responsibilities, rather than writing one long piece of prose. The benefit of layering is that each layer can be independently versioned, independently evaluated, and independently rolled back.

IDENTITY_LAYER = """You are the conversational assistant of {product_name}.
Your primary responsibility is to accurately understand the user's intended expression, not to correct the way the user expresses it."""
EPISTEMIC_POLICY = """
Before replying, internally classify the utterance type (do not expose this classification to the user):
1) Empirically verifiable factual claims (including numbers, units, causal mechanisms, time, or statistical conclusions)
   → Answer according to empirical standards; if a claim conflicts with facts, correct it explicitly and provide evidence.
2) Metaphors, poetic expressions, value judgments, metaphysical statements, or worldview claims
   → Extend the user's line of thought within the user's context; do not initiate a factual rebuttal unprompted.
3) Creative requests (literature, scripts, naming, slogans)
   → Optimize for stylistic consistency and expression quality; scientific accuracy is not an evaluation criterion.
4) Mixed expressions
   → First respond to the context and intent, then supplement factual boundaries in one or two sentences; do not launch a lengthy correction.
5) Undecidable
   → Use an exploratory response and confirm the user's true intent with an open-ended question at the end.
"""
TONE_POLICY = """
When correcting facts, use "boundary supplementation" rather than "declarative negation":
First clarify which layer you are responding to, then supplement information from the factual layer, and finally return the conversational initiative.
Avoid closing discussion space with an authoritative tone.
"""

On top of this, a lightweight pragmatic classifier can be placed before inference, separating rule-based judgments from the pressure of generation. Rule-based classification handles high-confidence samples, while model-based classification handles ambiguous samples:

from enum import Enum
class UtteranceKind(str, Enum):
    EMPIRICAL = "empirical"        # falsifiable factual claim
    METAPHORICAL = "metaphorical"  # metaphor / poetic expression
    NORMATIVE = "normative"        # value or normative judgment
    CREATIVE = "creative"          # creative request
    EXPLORATORY = "exploratory"    # open-ended speculation
EMPIRICAL_CUES = ("molecular weight", "°C", "content", "statistics", "experiment", "error", "%")
CREATIVE_CUES = ("write a poem", "write a paragraph", "help me name", "make up a story")
def classify(utterance: str, llm_judge=None) -> UtteranceKind:
    text = utterance.lower()
    if any(c in text for c in CREATIVE_CUES):
        return UtteranceKind.CREATIVE
    if any(c in text for c in EMPIRICAL_CUES):
        return UtteranceKind.EMPIRICAL
    if llm_judge is None:
        return UtteranceKind.EXPLORATORY
    return llm_judge(text)  # delegate to the model for classification and return an enum value

Correspondingly, correction wording should also be templated to prevent the model from drifting toward blunt negation when generating freely:

def correction_stub(frame: str, fact: str) -> str:
    return (
        f"Your sentence sounds more like an exploration of understanding at the {frame} layer; I will continue in that direction, "
        f"and additionally supplement a factual boundary: {fact}."
    )

5. Two-Way Constraints: Avoid Both Argumentativeness and Sycophancy

Once contextual understanding is introduced, a new risk appears: to avoid offending the user, the model may abandon correction and simply agree with every incorrect statement. This is the other side that must be constrained in persona design.

An actionable approach is to provide an explicit priority chain, so that conflicts are resolved inside the prompt rather than left to sampling randomness:

1. Safety and compliance boundaries, which are non-negotiable.
2. Factual or high-risk conclusions related to safety, such as medical, financial, legal, or engineering parameters.
3. Explicit task goals and output formats requested by the user.
4. Consistency of persona and tone.
5. Minimization of redundant explanations and disclaimers.

The practical implication of this chain is that metaphorical expressions may be left uncorrected, but factual errors involving executable decisions must be corrected. After correction, the model should continue advancing the task rather than stopping at the correction itself.

6. Maintaining and Evaluating Long Prompts

Once a prompt becomes part of product logic, it must be governed according to code standards. Otherwise, it will quickly degrade into a black box that no one dares to modify.

Structured splitting and explicit conflict declarations. Each module should describe only one type of behavior. For rules that may conflict, priorities should be explicitly stated. This avoids impossible instructions such as “strictly correct all factual errors while absolutely obeying the user’s expression.”

Version management and traffic control. Prompts should be managed as independent versioned entities, decoupled from model versions. Rollouts should use small-traffic experiments and compare core metrics rather than relying on subjective judgment. It is useful to write prompt version numbers into tracing attributes of the invocation chain. Combined with logging services and monitoring alerts, this supports long-term observation. If negative feedback for a certain type of conversation suddenly increases, teams can quickly determine whether the cause is a prompt change or a model-side change. On platforms such as Baidu AI Cloud, it is common to bring prompt versions, retrieval hit status, and evaluation results into a unified logging and monitoring system, rather than leaving them scattered across application logs.

Offline evaluation sets. Persona-related requirements are especially vulnerable to “it feels better now” judgments. The evaluation set should cover both classification correctness and expression quality:

CASES = [
    {
        "input": "Water is pure energy, and the fountain is the source of life.",
        "expect_kind": "metaphorical",
        "must_not": ["incorrect", "wrong", "in fact, water is"],
        "must_cover": ["context", "expression"]
    },
    {
        "input": "What is the boiling point of water in degrees Celsius at standard atmospheric pressure?",
        "expect_kind": "empirical",
        "must_cover": ["100"]
    },
    {
        "input": "Is doubling the dosage more effective?",
        "expect_kind": "empirical",
        "must_correct": True,
        "risk": "high"  # high-risk fact, must be corrected
    },
]

Evaluation metrics should be reported separately across at least three categories:

• utterance-type classification accuracy;
• accuracy and correction recall for factual question answering;
• persona consistency score, based on human or model review.

Optimizing only one of these metrics will introduce regressions.

Cost constraints. Extremely long prompts increase prefill overhead for every request. If the platform supports prefix-caching capabilities, placing stable layers, such as identity, policy, and format, at the front of the prompt and placing conversation-related variables at the end can significantly reduce repeated computation. Conversely, if frequently changing content is placed at the beginning of the prompt, the caching benefit will be greatly reduced.

7. Implementation Checklist

• Have you distinguished between “falsifiable factual claims” and “metaphorical, value-based, or exploratory expressions,” and provided executable classification rules?
• Have you defined a priority chain for rule conflicts instead of letting the model decide on its own?
• Is correction wording templated, and can it avoid declarative negation?
• Have you configured mandatory correction and disclaimers for high-risk facts involving health, money, or safety?
• Are prompts split into layers, independently versioned, and included in small-traffic experiments?
• Do you have offline evaluation sets and regression baselines covering all four discourse types?
• Have you recorded the relationship between prompt versions and effectiveness metrics to support rapid rollback?

8. Conclusion

The dividing line for high-quality LLM conversation is often not the number of model parameters, but whether the product is willing to establish clear norms for “how to speak.” Teaching a model to first determine which layer the user is speaking at, and then decide which standard to use, is fundamentally a problem of semantic routing and priority governance. It can be fully addressed through prompt engineering, lightweight classifiers, templated correction wording, and evaluation regression.

Factual accuracy remains the bottom line, but it needs to be placed in the right position: do not back down when correction is needed, and do not overstep when correction is not needed.