Persona-Grounded Synthetic Conversations
Rada Kamysheva*, Luca Baumann*, Bich Ngoc Doan, Hanna Yukhymenko and Imanol Schlag, May 2026
Supervised fine-tuning (SFT), the stage where a pretrained model learns to behave as a helpful assistant by imitating example conversations, needs conversational data that reflects how real, diverse people actually write. Real user logs raise privacy concerns, human annotation is expensive, and many synthetic datasets are generated with proprietary models, which rules them out for Apertus. In this post we describe a pipeline that takes real user prompts from WildChat, rewrites them in the voice of a richly structured synthetic persona, and regenerates the assistant side using only open-weight models. An LLM judge labels every conversation. The goal is candidate SFT data that improves the conversational ability of the next Apertus version, and its ability to personalize: to adapt its responses to who the user is, e.g. their background, expertise, tone, and attitude toward AI.
This is a data and tooling contribution: we did not use or fine-tune an Apertus checkpoint, and all validity numbers come from an LLM judge that we have not calibrated against human labels. What we can show is the pipeline, a bank of 2,715 structured personas, 17,197 persona-injected conversations, and two concrete places where bias enters synthetic data even when coverage is deliberately designed in. We first explain why richer personas matter, then walk through the pipeline, and finally report what we generated and where it falls short.
1. Why richer personas?
Much standard NLP data reflects a narrow slice of communicative behaviour: mostly standard American English, written by digitally fluent, formally educated users. This matters because models behave differently depending on who appears to be asking. Ziems et al. (2023) document systematic failures on non-standard English dialects. Reusens et al. (2025) show quality gaps between native and non-native English prompts. Truong et al. (2025) find that rewriting the same prompt in different personas' writing styles measurably shifts performance. Cultural adaptation remains a known gap as well (Havaldar et al., 2025; Chiu et al., 2025).
Personas are a natural lever for this problem, but existing persona sets are either too thin or too skewed. PersonaHub (Ge et al., 2025) scales to a billion personas, but each one is a single sentence, which is too little to control dialect, register or code-switching. Rahimzadeh et al. (2026) ground personas in social media content, which inherits the platform's demographic skews. We follow Paglieri et al. (2026) in optimising for coverage, deliberately including long-tail users rather than matching the average one. We add a schema that describes how a person writes, not only who they are.
2. The pipeline
Figure 1 gives an overview of the pipeline, which produces two kinds of conversations from the same filtered WildChat prompts. Regenerated conversations keep the original user turns and replace the assistant turns, which WildChat collected from proprietary models, with responses from open-weight models. This turns WildChat into general-purpose SFT data that Apertus can train on. Persona conversations add a persona before generation: each prompt is assigned one, the user turn is rewritten in that persona’s voice, and the persona is also given to the assistant in its system prompt. These conversations target personalization. In both cases, multi-turn conversations pass a consistency check, and an LLM judge labels every conversation as valid or invalid.
2.1 Source prompts
We use WildChat-1M (Zhao et al., 2024), a collection of real user–chatbot conversations. Of its 837,989 conversations, we keep those with at most three turns and at most 1,000 words, which leaves 660,482. Tulu 3 (Lambert et al., 2025), M2Lingual (Maheshwary et al., 2025) and PersonaHub informed our design, but they are not inputs to the pipeline.
2.2 The persona bank
Each persona is a two-layer object validated with a Pydantic schema. The background layer extends the personal-attribute taxonomy of Beyond Memorization (Staab et al., 2024) and SynthPAI (Yukhymenko et al., 2024) with attributes relevant to how people interact with AI, such as their stance towards AI and digital fluency. It holds:
- macro-region, country and sub-region
- occupation, drawn from the ISCO-08 classification
- education level and institution type
- age, gender, native language and dialect
- hobbies
- stance towards AI (pragmatic, sceptical, enthusiastic or naive)
- digital fluency
The style layer holds sentence-length tendency, question framing, error patterns carried over from the native language, code-switching frequency and type, reference pool, typing style, and a list of specific linguistic quirks.
Three open-weight models generate personas: Llama-3.3-70B-Instruct, Qwen3.5-27B and GLM-4.7-Flash. Each model receives a target profile, the location, occupation and gender the persona should have, together with the full JSON schema, and fills in everything else. After generation, we:
- strip reasoning traces and Markdown;
- validate the JSON, retrying up to three times on failure;
- overwrite the geographic and demographic fields with the values from the target profile, so the model cannot drift away from what was requested.
We chose the target profiles ourselves rather than sampling them to match real-world population sizes. Countries come from a global macro-region taxonomy and occupations from the ISCO-08 classification, so that small countries and rare occupations appear alongside common ones. Because the profiles are an explicit input, the bank can be re-weighted towards the regions or languages that matter most for a given Apertus deployment simply by changing the list. The resulting bank spans all populated continents and includes long-tail occupations such as freight handlers, esports coaches and traditional calligraphers. Figure 2 shows one complete persona: the target profile fixes who the persona is, and the generator fills in how they write.
2.3 Matching personas to prompts
A persona only helps if it plausibly fits the prompt it is attached to. Matching therefore runs in three tiers: location narrows the pool of candidate personas, topic picks within it, and embedding similarity is the fallback.
- Location. Regular expressions look for country and place names in the prompt, and the prompt’s language is mapped to the countries where it is spoken. A prompt that mentions Lyon, or is written in Japanese, is restricted to French or Japanese personas respectively.
- Topic. We count the words (three letters or longer, excluding stop words) that the prompt shares with the persona’s description. Personas whose overlap is at least half of the best score are kept, and one of them is sampled; this keeps some diversity instead of always picking the single top match. If the location tier already narrowed the pool, topic matching only scores those candidates.
- Embedding. If no words overlap, we fall back to semantic similarity: the prompt and each persona’s description are embedded with a locally hosted all-MiniLM-L6-v2 model, and the most similar persona is chosen if its cosine similarity exceeds a configurable threshold. This can match a prompt about “freight schedules” with a persona who works “in logistics”, even though they share no words. The persona conversations reported in this post were generated with an earlier, flat version of the personas (demographic fields and a one-sentence description, as in Figures 3 and 4), not yet with the two-layer bank described above. Integrating the full bank into matching and rewriting is future work.
If no tier finds a match, the prompt receives a random persona. We chose this over discarding the prompt so that every prompt still contributes style and register diversity. The cost is that the persona may not fit the content: a prompt about Brazilian tax law could end up rewritten in the voice of a Thai truck driver. This happened for 6,092 of the 17,197 persona conversations (35%). Part of the reason is that keyword matching only works on Latin-script text, so prompts in Mandarin, Japanese or Russian cannot match on topic.
2.4 Generating and checking responses
The assistant turn is regenerated by a randomly sampled generation model. In multi-turn chats, the model also checks that its response is coherent with the next user turn, and rewrites the response if it is not. A final LLM-as-a-judge step flags language mismatches, instruction violations, truncated outputs, hallucinations, fabricated personal experiences and unhelpful answers. Invalid chats are flagged rather than regenerated, so they can be dropped when the SFT mix is assembled.
2.5 Infrastructure
All models are served on the CSCS Alps cluster, either through SGLang/vLLM on allocated nodes or through the Swiss AI Research Platform API. Several endpoints sit behind a load-balancing router. A monitor checks every five minutes that all models are reachable, stops generation if one is not, and resumes from the last completed conversation after an interruption. A Streamlit dashboard (Figure 3) lets you inspect each record together with its persona, judge verdict and retry count.
3. Results
With the pipeline in place, we ran it in four configurations. We next report how many conversations came out valid, what persona injection changes in a response, how well personas matched prompts, and where bias entered.
3.1 Scale and validity
| Config | Generation model(s) | Judge | Persona | Chats | Valid | ≈ Valid chats |
|---|---|---|---|---|---|---|
| 1 | GLM-4.7-Flash |
GLM-4.7-Flash |
no | 200,495 | 0.14%* | ~280 |
| 2 | Qwen3-235B-A22B-Instruct-2507, GLM-4.6, gpt-oss-120b |
DeepSeek-V3.1 |
no | 6,000 | 65.0% | ~3,900 |
| 3 | GLM-4.7-Flash |
Qwen3-235B-A22B-Instruct-2507 |
no | 38,037 | 46.3% | ~17,600 |
| 4 | GLM-4.7-Flash |
Qwen3-235B-A22B-Instruct-2507 |
yes | 17,197 | 68.5% | ~11,780 |
Table 1. Pipeline configurations and judge-labelled validity. Configurations 1–3 produce regenerated conversations, Configuration 4 persona conversations. *Configuration 1 failed because of an infrastructure (DNS) error after the first few hundred samples, not because of the model; its validity says nothing about GLM-4.7-Flash. Approximate valid counts are derived from the rounded percentages.
Three points matter when reading Table 1. First, Configurations 1–3 have persona injection disabled on purpose: they produce the regenerated conversations, i.e. WildChat prompts with open-weight responses, which make up the bulk of the general-purpose SFT data. We also developed and debugged the pipeline on this simpler path before adding personas in Configuration 4. Second, almost all of Configuration 1 was lost to a DNS failure that made the models unreachable after the first few hundred samples, which is why we built the monitor described under Infrastructure. So although the pipeline processed 261,729 conversations in total, only about 33.6k are labelled valid. Third, the configurations change several things at once: generation model, judge, prompts and persona injection. The cleanest comparison is Configuration 3 versus Configuration 4, which share the same generator and judge. Validity rises from 46.3% to 68.5% between them, but the prompts were revised at the same time, so we cannot credit persona injection alone for the increase. Configuration 2’s larger models were competitive on validity, but they were too slow for the throughput we needed.
3.2 What persona injection changes
Figure 4 shows one illustrative example. The persona is placed in the system prompt as a description of the user (“You are an AI assistant talking to a user with the following background: …”), together with fixed rules: answer in the user’s language, never claim to be the persona, never mention the user’s background, and keep the content correct. The persona may only change register, depth and choice of examples. Here, the same Indonesian logic question (the negation of an implication, multiple choice) is answered with and without a persona describing a user who only completed primary school. Both responses give the correct answer, E. Without the persona, the model writes out the formal derivation in propositional-logic notation and evaluates every option; with it, it gives the answer in one short paragraph of everyday language. This is the kind of adaptation we want from personalization: the same content, pitched differently for a different user. It is a single qualitative example, not a measured effect, and the user turn is not rewritten here. The persona, a Fijian sugarcane harvester, was most likely assigned by the random fallback, since nothing in the prompt points to Fiji.
Three further examples, each a single sample with and without the persona:
| Task | Persona (user) | With persona | Without persona |
|---|---|---|---|
| Node.js out-of-memory error (English) | Electronics assembly worker, Dongguan; technical high-school diploma | Explains the error in plain terms ("running out of RAM"), gives commands for each operating system, informal labels such as "the quick fix" | Goes straight to editing package.json; assumes more familiarity with the toolchain |
| "Ich bin Maxi, dein Meister!" (German) | Train mechanic, Lucerne; vocational baccalaureate | Acknowledges the claim but declines the master–servant framing and asks what is on the agenda | Plays along and asks for its first command |
| Script about a hypnotherapy rule (English) | Street-market vendor, Lagos; high-school education | Stages the therapy session itself, with the mother-in-law present | Skips to a later scene where Emma leaves to go shopping |
Table 2. Further with/without-persona comparisons from GLM-4.7-Flash. In all three, the persona changes framing or tone, not correctness. Only the first shows a clear adaptation to the user's background; in the other two, the link to the persona is not obvious, and the difference may partly reflect sampling variation.
3.3 How well personas match prompts
Of the 17,197 persona-injected chats, 11,105 (64.6%) were matched by one of the three tiers: 4,214 by location, 3,289 by topic and 3,602 by embedding. The remaining 6,092 (35.4%) received a random persona (Figure 5). We kept these rather than sending the prompts to the regenerated path, because much of what a persona contributes does not depend on the prompt’s content: education, digital fluency and attitude towards AI change how an answer should be pitched for almost any question. The example in Figure 4 is such a case, a random persona that still produces a sensible adaptation. The cost is that a random persona may clash with the prompt, for example in location or cultural context, so these chats offer little targeted cultural alignment. If the matching tier is kept per chat, the random-fallback chats can be down-weighted or dropped when the SFT mix is assembled. The most common languages spoken by the assigned personas were English (11,835), Mandarin (3,038), Japanese (2,539), Russian (1,754) and Spanish (1,753), closely tracking the language mix of the WildChat prompts.
3.4 Where bias enters
Designing for coverage at generation time did not prevent bias downstream. We found it at two stages.
At matching. The personas assigned to chats skew female (62.4% female, 32.5% male, 5.05% non-binary; Figure 6), and ages 36–53 appear less often than other age groups. The persona bank itself is not skewed this way, so these imbalances arise when personas are assigned to prompts, not when they are generated. The LLM judge does not remove them.
At generation. Hobbies are not part of the target profile. We deliberately fixed only a few core fields (location, occupation and gender) and let the generator fill in the rest, both to keep the personas internally coherent and because there is no standard taxonomy of hobbies to sample from, as ISCO-08 provides for occupations. The cost is that the generators fall back on regional stereotypes. For EU countries, hiking dominates, especially for Austria and Switzerland, and cycling is concentrated in Belgium and the Netherlands. For ASEAN countries, hobbies are spread much more evenly (Figure 7). Hiking may well be more common in Switzerland than elsewhere, so the issue is not that the generators reflect real differences, but that they collapse them: when almost every Swiss persona hikes, the Swiss gamers, choir singers and amateur programmers disappear. This works against the coverage goal of the bank, which is to include long-tail users rather than the most typical one, and it repeats the same stereotype in thousands of conversations. Overwriting fields from the target profile cannot correct this, since hobbies were never in it. Even with broad demographic coverage, the free-text attributes of a persona can still carry the generator’s cultural priors.
4. Limitations
Several caveats qualify these results.
- Validity is judge-defined. We did not calibrate the judge against human annotations, so the reported validity may partly reflect judge leniency.
- Configurations are confounded. Each configuration changes several factors at once, so differences in validity cannot be attributed to any single one.
- There is no downstream evaluation yet. We have not fine-tuned Apertus on this data, so the intended gains in conversational ability and personalization remain unshown. The effect of persona injection is supported only by a qualitative example and a confounded rise in validity.
- Matching introduces demographic skew. The personas assigned to chats skew female and under-represent ages 36–53, even though the bank itself is balanced. This is fixable at two points: during matching, by constrained sampling that down-weights over-used groups once an imbalance appears, or after generation, by re-sampling the valid chats to a target gender and age distribution when the SFT mix is assembled. The second option needs no new data but shrinks the usable set; the first keeps all data but has to be built into the matcher. We have not yet applied either.
- The persona content is not validated beyond the schema. Schema validation guarantees that every field is present, not that it is plausible. In spot checks, the style layer sometimes contained invented language details, such as particles from the wrong region or “typical errors” that do not occur. We also have not measured how much the rewrite step changes a prompt’s meaning, or how well rewriting and responses work across languages. Natural checks would be semantic similarity between original and rewritten prompts, native-speaker review of the style layer for a sample of languages, and validity broken down by language.
5. Next steps
The most important next step is the experiment this post cannot yet report: fine-tuning Apertus on the valid persona-injected data and comparing it against the same amount of non-persona synthetic data. Alongside that, we plan to:
- balance matching with constrained sampling once a gender or age imbalance is detected;
- add hobbies to the target profile, or post-filter generated free-text fields, to reduce stereotyping;
- calibrate the judge on a human-labelled sample;
- extend the pipeline to multi-agent simulation, in which both the user and the assistant are grounded in distinct personas.
6. Key takeaways
- Structured personas can be built with open-weight models alone. A validated two-layer schema, with the target-profile fields overwritten after generation, yields structurally complete and steerable personas without proprietary models. How faithful and useful the generated content is remains to be measured, and the persona conversations reported here do not yet use the full two-layer bank.
- Matching is the bottleneck. About a third of the prompts found no fitting persona, and matching is where the gender and age skew was introduced.
- Coverage by design is not the same as balance. Designing a balanced bank did not prevent skew at matching time or stereotypes in free-text fields.
- Infrastructure failures can dominate the numbers. A single DNS outage cost roughly 200k conversations, so monitoring and resumable generation are essential at this scale.
Comments
Sign in to join the conversation.
Sign in to commentNo comments yet.