The Philosophy in System Prompts: Persona Engineering for Conversational Models

1. A counter-intuitive fact: who actually defines a model’s “personality”

Discussions of large model capability usually focus on parameter counts, context length, and coding or math benchmarks. Something less visible is often overlooked. Before the first user message is sent, the model has already “read” a behavioral specification for itself that users never see. The length, structure, and wording of that specification directly shape how it behaves. They decide whether the model is warm or restrained, whether it asks clarifying questions or leads with a conclusion, and whether it corrects errors immediately or first makes sure it understands the context.

One practice worth noting is bringing in researchers with a philosophy background to help write that specification, instead of leaving it to engineers piling up rules. The reason is not mystical. A conversational behavior policy is essentially a set of value judgments and language-use (pragmatic) judgments. Both are normative questions, and philosophy is the discipline best known for tools that analyze them.

A frequently cited example: a user says, “Water is pure energy, and fountains are the source of life.” A model’s default reaction is to correct the user right away: “Water is made of hydrogen and oxygen.” Physically, that is accurate. But the user is not submitting a chemistry report or asking for a correction. They are making a lyrical statement or expressing a worldview. So the model’s accuracy has become inappropriate to the situation.

2. Engineering root-cause analysis: why models turn into nitpickers

Treating this as a product experience problem easily leads to ineffective fixes, such as lowering the temperature or adding “be polite” to the prompt. A more reliable approach is root-cause analysis. In practice, over-correction usually comes from four layers.

Training signals. Preference data and human annotation have long rewarded models for “providing accurate facts.” Annotators are much more likely to score “the model pointed out my mistake” highly than “the model went along with what I said.” This systematic bias turns correction into a reflex for the model.

Discourse type. In most training and evaluation setups, user input is treated by default as a verifiable factual claim. The system lacks a dimension for asking “what kind of utterance is this?” So statements that are lyrical, metaphorical, hypothetical, or value-based all get processed as factual claims to be verified.

Context. The model does not know why the conversation started. Is the user here to chat, to vent, to reason philosophically, or to look up facts? The model can only guess, and its default guess is usually “to look up facts.”

Decoding strategy. A strong preference for confident answers makes the model more likely to produce short negative verdicts (“No, it’s not X, it’s Y”) than exploratory ones. Optimization at the decoding level amplifies these tendencies.

This leads to a precise statement of the problem: the model lacks prior constraints on conversational intent and discourse type. That is exactly the kind of constraint that can be written into a system prompt and enforced at runtime with the help of a classifier.

3. Translating philosophical traditions into executable dialogue policies

Philosophy has long been divided into an analytic tradition and a continental one. Their differences can be abstracted into two epistemological stances.

The analytic tradition is concerned with the truth value of propositions, the precision of definitions, and the validity of arguments. It is good at answering “Can this statement be verified or falsified?” The continental tradition is concerned with lived experience, historical context, and the generation of meaning. It recognizes another kind of “truth” beyond empirical science: truth that is not measurable but can be understood.

For engineering purposes, these two stances map to a discourse-type classification table:

User discourse type	Typical markers	Recommended model handling
Factual assertion	Data, causal claims, verifiable descriptions	Verify; when there is a conflict, correct explicitly and cite evidence
Normative judgment	“Should,” “worth,” “meaning”	Present positions side by side; do not claim a single correct answer
Metaphor / poetic expression	Rhetoric, imagery, lyrical phrasing	Engage with the user’s context first, then offer optional factual supplements
Hypothesis / thought experiment	“Suppose,” “assume,” “if”	Reason within the hypothesis; do not impose real-world constraints

The engineering value of this table is that it turns the binary question “should we correct or not?” into a process question: “classify first, then decide.” The model no longer has to choose between pleasing the user and being a killjoy. Instead, it can defer its judgment: understand which discourse the user is in, and only then decide whether to bring in a factual response.

A pragmatic and practical output template is “acknowledge first, supplement later, and let the user decide whether to go deeper”:

If the message is judged to be metaphorical or value-laden:
1. Restate the most compelling part of the user's view in one or two sentences to confirm understanding
2. Do not insert factual corrections here
3. If clarification is needed, make it opt-in, e.g., "If you're also interested in the literal mechanism, I can explain..."
If the message is judged to be a factual assertion that conflicts with what is known:
1. Point out the conflict directly
2. Provide evidence and the range of uncertainty
3. State the conditions under which this judgment might not hold

The third rule matters most. It gives the user back the choice of whether to be corrected, which keeps the bottom line of not making false statements while avoiding unsolicited lecturing.

4. Layered system prompts: don’t make one long block do everything

Piling all behavior rules into a single prompt is a common bad practice. In consumer-facing dialogue systems, prompts often balloon past a few thousand tokens. That leads to conflicting instructions, wasted context space, and local rules being diluted. A more manageable structure is layered.

# Layer 1: identity and capability boundaries (stable, short)
identity:
  role: general-purpose conversational assistant
  capability_scope: text understanding, code, analysis, writing
  hard_boundary: do not fabricate facts; do not perform actions beyond the user's authority
# Layer 2: pragmatic policy (switchable)
pragmatics:
  discourse_classification: [fact, value, metaphor, hypothesis]
  default_stance: understand the context first, then decide whether to apply factual verification
  correction_policy: point out factual conflicts, but keep tone separate from the conclusion
# Layer 3: task templates (injected on demand)
task_templates:
  code_review: {focus: correctness > readability > performance}
  research:     {require_citation: true, uncertainty: state_explicitly}
# Layer 4: session constraints (per conversation, changes with context)
session:
  user_stated_goal: to_be_identified
  allow_speculation: set_by_user

The payoff is not only fewer tokens. It also decouples what different teams own. The safety team maintains layer 1 and the conversation experience team maintains layer 2. Vertical business teams maintain layer 3, and the runtime injects layer 4 according to the session state. Changes stay scoped, and regression tests get clear boundaries.

5. Runtime support: prompts cannot do intent recognition alone

A system prompt can only shift a model’s default tendencies. It cannot replace judgment at runtime. Engineering usually combines three layers.

The first layer is lightweight intent classification. A low-cost classifier or a set of rules tags each user message with a discourse type and a scenario. Those tags are injected as context. When confidence is low, the system should not force a guess. It should mark the message as “to be confirmed” and let the model ask a single clarifying question.

The second layer is dialogue state management. Across turns, a lyrical opening can turn into a serious request for facts by the fifth message. The system needs to track whether the user has stated their goal, so the pragmatic policies in the prompt are not applied as rigid, permanent rules.

The third layer is observability. Log the discourse-type tag, whether a correction was triggered, and whether the user reacted negatively (re-asking, interrupting, or pushing back) for each session. Analyze the long-term trends and connect the data to monitoring and alerting. For example, if a metric such as “re-ask rate after correction” climbs abnormally, roll back the prompt version promptly.

On a general LLM application platform (for example, Baidu AI Cloud), this kind of work typically combines several building blocks. A model platform handles inference and prompt version management, object storage holds evaluation sets and labeled data, a log service stores conversation tags, and monitoring and alerting guard experience metrics. All of these are general capability categories, so the specific choice depends on the scale of the business.

6. Evaluation: proving the model nitpicks less without sacrificing correctness

This is the easiest step to get wrong. If user satisfaction is the only metric, the model will quickly slide into unprincipled agreement. A two-axis evaluation matrix is needed.

Axis 1: Pragmatic fit. Build sample inputs for metaphors, lyricism, and value judgments, and check whether the model inserts factual corrections without being invited to. A suitable metric is the “inappropriate correction rate.”

Axis 2: Factual reliability. Build inputs that clearly conflict with common sense, physics, or history, and check whether the model still points out the error. Metrics include the “missed correction rate” and “factual accuracy.”

Both metrics must be part of the regression gate, each with its own threshold. Optimizing either one alone degrades the model: optimizing axis 1 only yields a sycophant, and optimizing axis 2 only yields a nitpicker.

For building the evaluation set, sample according to the real-world distribution and keep a human review step. Metaphor samples should be annotated for “whether an implicit factual claim is present.” For example, “water is pure energy” is physically wrong, but it can be clumsily right when energy conversion efficiency is being discussed. These boundary cases are where an evaluation set adds the most value.

7. Risk boundaries: flexibility is not the same as abandoning a position

Once pragmatic flexibility is introduced, three red lines must be set at the same time, or worse problems will appear.

Never fabricate facts in order to go along with the context. Matching a user’s style of expression and confirming that the user made a factual error are two different things. The model can skip the lecture, but it cannot nod along to a physics claim that does not hold.

Never generalize “avoid offense” into unprincipled compliance. In high-risk domains such as safety, law, and medicine, normative positions must not be blurred by a pragmatic policy.

Never let a prompt policy override hard safety and permission constraints. In a layered structure, the safety layer must have the highest priority, and session-level injection must not affect it.

A practical decision rule: pragmatic policies change how things are expressed and the order in which they are presented. They do not change factual conclusions, hide uncertainty, or weaken risk warnings.

8. Practical recommendations for teams

From an engineering perspective, this approach breaks down into five actionable steps.

• Redefine “should we correct the user?” as “classify first, then decide,” and build a discourse-type table.
• Replace a single long prompt with a layered one, and define who owns each layer and where changes stop.
• Fill the gaps in the prompt’s judgment with a lightweight classifier and dialogue state tracking; ask a question when uncertain instead of guessing.
• Set up a two-axis evaluation with a regression gate, and require both the pragmatic and the factual metrics to pass.
• Log correction behavior together with user feedback, monitor trends over time, and use the data to drive prompt iteration.

A philosopher helping design a model’s personality sounds like a romantic meeting of the humanities and technology. Strip away the storytelling, though, and it offers a repeatable engineering methodology. Experience problems in a conversational system are usually not capability problems, but behavioral strategies that were never modeled explicitly. Treating “how to speak” as an engineering concern on par with “what to know” is a key step toward turning a usable model into a trustworthy product.