Beyond Cooperative Simulators: Generating Realistic User Personas for Robust Evaluation of LLM Agents
Abstract: LLM agents are increasingly deployed in settings where they interact with a wide variety of people, including users who are unclear, impatient, or reluctant to share information. However, collecting real interaction data at scale remains expensive. The field has turned to LLM-based user simulators as stand-ins, but these simulators inherit the behavior of their underlying models: cooperative and homogeneous. As a result, agents that appear strong in simulation often fail under the unseen, diverse communication patterns of real users. To narrow this gap, we introduce Persona Policies (PPol), a plug-and-play control layer that induces realistic behavioral variation in user simulators while preserving the original task goals. Rather than hand-crafting personas, we cast persona generation as an LLM-driven evolutionary program search that optimizes a Python generator to discover behaviors and translate them into task-preserving roleplay policies. Candidate generators are guided by a multi-objective fitness score combining human-likeness with broad coverage of human behavioral patterns. Once optimized, the generator produces a diverse population of human-like personas for any task in the domain. Across tau2-bench retail and airline domains, evolved PPol programs yield 33-62% absolute gains in fitness score over the baseline simulator. In a blinded evaluation, annotators rated PPol-conditioned users as human 80.4% of the time, close to real human traces and nearly twice as frequently as baseline simulators. Agents trained with PPol are more robust to challenging, out-of-distribution behaviors, improving task success by +17% relative to training only on existing simulated interactions. This offers a novel approach to strengthen simulator-based evaluation and training without changing tasks or rewards.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
This paper is about making “fake users” for AI assistants more realistic. Today, many AI assistants are tested with computer-made users (called simulators). These simulators are usually very friendly, always clear, and quick to share information—unlike real people, who can be vague, impatient, skeptical, or busy. Because of this, an assistant that looks great in tests can struggle with real users. The authors introduce Persona Policies (they call it PPol), a way to give simulators believable personalities and communication styles so AI assistants are tested in tougher, more life-like conversations.
What questions did the researchers ask?
The researchers focused on a few simple questions:
- Can we automatically create a wide variety of realistic “user personalities” that still follow the task’s goal (like changing a flight or returning an item)?
- Will these new personas make simulated conversations look more like real human conversations?
- If we train AI assistants using these harder, more varied users, will the assistants become more robust and successful with tricky users later?
How did they do it?
Think of their system as a coach that writes playbooks for pretend customers and keeps improving them over time.
Here’s the basic approach in everyday terms:
- They start with “behavior axes” that describe how a user might act, such as being terse (short replies), skeptical (doubts the assistant), frustrated, or vague.
- A Python program (the “generator”) combines these behaviors to create many different user personas. Each persona becomes a short set of instructions added to the simulator, telling it how to talk (tone, pacing, what to share first, when to push back).
- They run test conversations between an AI assistant and these persona-driven simulators.
- They score the conversations in two main ways: 1) Human-likeness: Do these conversations statistically look like real human chats? They measure this using a simple “fingerprint” of each conversation (19 features like average message length, how often the user asks clarifying questions, shows emotion words, pushes back, etc.). A small classifier (a Random Forest) gives a probability that a conversation seems human-like. 2) Coverage: Do all the personas together spread out across the range of real human styles? Imagine plotting each conversation as a point; coverage checks that these points cover the “cloud” of real human behaviors without drifting into weird, non-human corners.
- They combine these two scores into one fitness score.
- Then they improve the generator code using an “evolutionary” loop: an LLM suggests code edits (like adding new behavior axes or refining instructions), they test again, keep the better versions, and repeat. A “reflection” step summarizes what worked or failed (for example, “personas weren’t asking enough clarifying questions”) to guide the next edits.
- A technique called MAP-Elites helps them keep a variety of good solutions instead of just one type of persona.
In short: Generate personas → run conversations → score realism and diversity → update the persona generator → repeat.
What did they find?
The main results show Persona Policies work well:
- Much more realistic simulations: Their evolved personas scored 33–62 percentage points higher than the default simulators on the combined fitness score across retail and airline tasks.
- People thought they were human: In a blind study, annotators judged conversations using these personas as “human” 80.4% of the time—close to real human chats and nearly double the default simulator.
- Better coverage of human behavior: The evolved personas didn’t just imitate one style; they spread across styles seen in real users (e.g., varied clarity, patience, and reactions to errors).
- More robust assistants: When they fine-tuned an AI assistant on these tougher, more varied conversations, it did better later on challenging users (like confused or skeptical ones)—about a 17% relative improvement in success on average compared to training on default simulations alone.
They also noticed that simple, hand-written traits like “be impatient” weren’t enough. The evolutionary search discovered more concrete, useful rules, like:
- “Don’t share your order number in the very first message.”
- “Answer only one piece of info at a time.”
- “Use short, bursty messages like someone on a phone.” These details changed how the conversation flowed without changing the user’s actual goal.
Why does this matter?
If we only test AI assistants with super-cooperative fake users, we get a false sense of security. Persona Policies make those tests tougher and more realistic—closer to how people actually talk. That means:
- Fairer, stronger benchmarks: Scores better reflect how an assistant will behave with real customers.
- More robust assistants: Training with diverse, life-like personas helps assistants handle unclear, impatient, or skeptical users.
- Faster progress: Collecting huge amounts of real conversation data is expensive. This method gives a practical way to simulate realistic variety without changing the original tasks.
In the long run, this approach can help AI tools interact more safely and smoothly with all kinds of people, not just the easy cases.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
The paper leaves several concrete issues unresolved that future work could address:
- External validity across domains and tasks
- Does a generator evolved on one domain (e.g., retail) transfer to new domains (e.g., banking, healthcare, technical support) without re-optimization? Quantify zero-shot and few-shot transfer of evolved generators and their axes.
- How does performance change on other interactive benchmarks (e.g., MINT, WebArena, ToolSandbox) with different tooling, state dynamics, and reward definitions?
- Dependence on human reference data
- How much real human dialogue is needed to train stable discriminators and coverage references? Provide data-size vs. performance curves and failure thresholds.
- Robustness to demographic, cultural, and linguistic composition of the human corpus: do evolved personas overfit to the specific population in the reference data? Evaluate across multiple human datasets with varied distributions.
- Multilingual and cross-cultural generalization: can the framework induce realistic behaviors in languages other than English or culturally distinct communication norms?
- Human-likeness metric design and validation
- The 19 regex/lexicon-based features and Random Forest classifier may miss discourse-level structure, pragmatics, and dialogue-act patterns. Compare against learned, conversation-level representations (e.g., turn-encoder transformers) and probe which features drive judgments.
- Sensitivity of the discriminator to paraphrasing and lexical gaming: can personas artificially inflate human-likeness by matching surface features while remaining unnatural? Stress-test the metric with adversarial examples and report robustness.
- Domain and simulator shift: assess whether a discriminator trained against a specific base simulator remains valid when new simulators or model versions are introduced.
- Coverage metric assumptions and alternatives
- The Chamfer distance in standardized Euclidean space implicitly weights all features equally and uses a fixed scaling constant. Perform sensitivity analyses on feature weighting, normalization, and the 2·d_ref scaling.
- Distributional coverage vs. mean alignment: show whether improved coverage reflects capturing rare but important human behaviors or merely spreading uniformly. Consider density-weighted coverage or importance-weighted regions (e.g., user states that commonly cause agent failures).
- Compare Chamfer-based coverage to alternatives (e.g., Earth Mover’s Distance, energy distance, or coverage on learned manifolds) and quantify metric agreement.
- Task preservation and controllability
- “Task-preserving persona policies” are assumed but not verified programmatically. Introduce automatic checks ensuring personas do not change goals, invent facts, or violate benchmark rules; measure how often personas cause unrecoverable failures by withholding essential information indefinitely.
- Controllability and stability of axes: quantify whether toggling an axis consistently moves the same behavioral features (effect size, variance) across tasks and simulator backends; report axis interpretability and independence.
- Generator evolution mechanics
- Reproducibility and stability: how sensitive are results to random seeds, model versions, mutation rate, and archive hyperparameters (e.g., MAP-Elites binning strategy)? Provide multiple independent runs and confidence intervals.
- Ablation of reflection-guided mutation: what fraction of gains comes from reflection vs. score-only evolution? Compare code-edit strategies (e.g., rule-based mutations, gradient-free black-box optimization).
- Budget and efficiency: report compute/token costs per iteration, rollout counts, and convergence behavior vs. budget; explore sample-efficient variants (e.g., surrogate models, partial-episode scoring).
- Interaction with the assistant agent
- Co-adaptation risk: generators are evolved against a fixed assistant. Do personas remain effective and realistic when paired with different assistants (sizes, vendors, tool-usage policies)? Evaluate cross-assistant generalization and ranking stability.
- Training-regime sensitivity: SFT with success-only trajectories showed modest gains. Compare with alternative objectives (DPO, RLHF, offline RL, curriculum learning), data-mixing ratios, and inclusion of failure cases for robustness.
- Downstream trade-offs: do gains in robustness come at the cost of other axes (e.g., politeness, helpfulness, safety)? Track auxiliary metrics to detect regressions.
- Human evaluation scope and rigor
- Scale and breadth: the human study is small (87 conversations, one domain) and uses a coarse human/bot/ambiguous label. Increase domains, tasks, and annotator pools; collect fine-grained judgments (naturalness, coherence, effort, satisfaction, perceived patience/skepticism).
- Inter-annotator agreement and calibration: report agreement statistics and analyze factors that drive disagreement; validate that instructions isolate the “user” side effectively.
- Holistic conversation quality: beyond human-likeness, measure whether personas elicit helpful agent behaviors and realistic user satisfaction trajectories.
- Safety, ethics, and bias
- Stereotype and bias risks: evolving personas may implicitly encode demographic stereotypes or offensive behaviors. Introduce bias audits (e.g., persona content analysis, disparate impacts on agent policies) and safety filters for persona generation.
- Harmful or abusive user behaviors: define guardrails that permit realistic friction without generating toxic or unsafe content; evaluate agent safety performance under such personas.
- Robustness and generalization of personas
- Cross-simulator portability: do persona policies discovered with one user-simulator LLM transfer to others without degradation? Evaluate same persona prompts across backends.
- Long-horizon and high-stakes tasks: test whether personas remain realistic over longer sessions, with delayed rewards or irreversible actions; examine recovery and escalation behaviors.
- Benchmarking methodology
- Statistical testing: provide significance tests and confidence intervals for metric differences across methods; include bootstrap analyses on task sets.
- Hyperparameter sensitivity: report how N (number of personas), λ_h/λ_b scheduling, and axis-count affect performance; characterize diminishing returns with larger N.
- Baseline breadth: compare against stronger persona baselines (e.g., profile-grounded, trait-calibrated simulators, or simulators trained on real dialogues) beyond direct prompts and the initial generator.
- Practical deployment questions
- Online A/B with real users: can persona-augmented training/evaluation predict real-world improvements? Pilot small-scale studies to validate sim-to-real gains.
- Tooling for practitioners: guidelines for selecting reference datasets, choosing features/embeddings, and setting risk-adjusted coverage targets per application domain.
Practical Applications
Summary
The paper introduces Persona Policies (a plug‑and‑play control layer for LLM user simulators) that uses evolutionary program search to generate diverse, human‑like user personas while preserving task goals. It optimizes a Python persona generator against two objectives—human‑likeness and behavioral coverage—measured from multi‑turn interaction “fingerprints.” The approach improves simulator realism, strengthens stress‑tests, and boosts agent robustness (+17% task success on challenging users), enabling more trustworthy training and evaluation of LLM agents.
Below are actionable applications, organized by immediacy. Each item notes relevant sectors, potential tools/workflows, and key assumptions/dependencies.
Immediate Applications
The following can be deployed with current tools and typical enterprise/academic resources.
- Robustness QA for customer‑facing conversational agents (retail, airlines, telco, travel)
- What: Inject diverse, realistic user personas into pre‑deployment test suites to expose failure modes (impatience, ambiguity, skepticism, fragmented disclosure) that cooperative simulators miss.
- Tools/workflows: Integrate the persona generator into existing benchmarks (e.g., τ²‑bench, MINT) and CI pipelines; run N‑persona rollouts per task; track human‑likeness and coverage dashboards; gate releases on coverage thresholds.
- Assumptions/dependencies: Access to a corpus of real dialogues in the domain to calibrate fingerprints and the discriminator; sufficient compute for multi‑persona rollouts; access to an LLM user simulator.
- Safety and policy stress‑testing of assistants (safety/compliance across sectors)
- What: Systematically probe guardrails and escalation policies by simulating users who withhold, push back, or exhibit confusion; validate that irreversible actions require clear consent.
- Tools/workflows: Persona packs that emphasize error reaction and clarification behaviors; red‑team suites that vary disclosure and tone; automated reports mapping failure types to persona axes.
- Assumptions/dependencies: Clearly defined safety policies; reviewers to triage surfaced issues; careful prompts to ensure task preservation.
- Training data augmentation via persona‑conditioned rollouts (software, customer support, internal IT/helpdesk)
- What: Use persona‑diverse interactions as “domain randomization” for SFT/RL, improving generalization to non‑cooperative users (+17% relative success shown).
- Tools/workflows: Mix default and persona‑augmented conversations into SFT; curriculum that increases persona diversity over epochs; monitor in‑dist vs OOD gains.
- Assumptions/dependencies: Balanced training to avoid overfitting to rare behaviors; reproducible rollouts; data labeling for success criteria.
- Vendor/model selection under realistic user variation (procurement, platform teams)
- What: Rank assistant models not only on average success but on robustness across behavioral coverage bins; choose models less sensitive to user idiosyncrasies.
- Tools/workflows: MAP‑Elites‑style scorecards; heatmaps of success across persona axes; procurement checklists including coverage thresholds.
- Assumptions/dependencies: Comparable evaluation stacks per model; consistent persona generator across candidates.
- UX and conversation design evaluation (product, CX research)
- What: Test prompt templates, tone, and turn‑taking policies against personas with bursty cadence, incremental disclosure, or low patience; reduce friction and escalation rates.
- Tools/workflows: A/B tests with matched tasks and N personas; analysis of clarification and pushback rates; copy iteration loops driven by fingerprint deltas.
- Assumptions/dependencies: Clear success metrics beyond task completion (e.g., perceived helpfulness); product telemetry for follow‑up.
- Privacy and minimal‑data handling checks (finance, healthcare admin, government services)
- What: Simulate privacy‑conscious users to ensure agents don’t over‑request PII and can proceed with partial information.
- Tools/workflows: Persona axes for selective disclosure; tests for front‑loading versus incremental ID requests; automated detection of unnecessary PII prompts.
- Assumptions/dependencies: Policy baselines (e.g., HIPAA/PCI) and acceptable‑use criteria; domain‑specific task schemas.
- Education: AI tutor robustness to diverse student behaviors (education technology)
- What: Evaluate/train tutors to handle ambiguity, fragmented questions, and repeated second‑guessing; improve clarification strategies and frustration handling.
- Tools/workflows: Persona libraries for learner archetypes; per‑dimension (D1–D4) alignment reports; targeted SFT on tutoring interactions.
- Assumptions/dependencies: Access to anonymized tutoring dialogues; alignment with pedagogy and safety guidelines.
- Finance onboarding/KYC and support bots (finance)
- What: Ensure agents succeed under sparse or reluctant disclosure and resolve misunderstandings without repeated ID requests.
- Tools/workflows: Tasks with KYC‑specific steps; personas tuned for cautious/skeptical users; success audits across personas before go‑live.
- Assumptions/dependencies: Accurate task rules for compliance; robust fallback/escalation paths.
- Healthcare portals and scheduling assistants (healthcare administration)
- What: Stress‑test appointment and benefits flows with confused, terse, or anxious users; reduce drop‑offs and escalations.
- Tools/workflows: Persona‑augmented regression tests; monitoring of clarification and error‑reaction features; SFT on high‑friction cases.
- Assumptions/dependencies: Non‑clinical scope (administrative only) unless additional safety oversight; de‑identified reference dialogues.
- Internal tooling and dev‑assistants (software engineering, IT)
- What: Test issue‑triage or IT chatbots against terse tickets, incomplete reproduction steps, or impatient users; improve follow‑up question quality.
- Tools/workflows: Integrate persona rollouts into tool QA; measure pushback and clarification rates; fine‑tune on difficult interactions.
- Assumptions/dependencies: Access to internal ticket/chat logs (anonymized); secure evaluation environments.
- Academic research on HCI and agent evaluation (academia)
- What: Use the open Persona‑Policies generator and fingerprint metrics to study how interaction styles impact agent performance; replicate and extend benchmarks.
- Tools/workflows: Public datasets + τ²‑bench/MINT; plug‑in persona generation for new domains; open evaluation leaderboards with coverage metrics.
- Assumptions/dependencies: IRB approvals for any new human data; transparent reporting of reference corpora and features.
- SMB and indie chatbot builders (daily life/SMB)
- What: Quickly stress‑test bots with ready‑made persona packs before deploying on websites or messaging channels.
- Tools/workflows: Lightweight CLI/API that appends persona policies to the simulator prompt; canned reports with human‑likeness and coverage scores.
- Assumptions/dependencies: Cloud LLM access and small sample of real user chats for calibration (or use community defaults with caveats).
Long‑Term Applications
These require further research, scaling, domain expansion, or standardization.
- Regulatory audit frameworks using behavioral coverage metrics (policy, governance)
- What: Standardize human‑likeness and coverage as required pre‑deployment checks for public‑facing AI services.
- Tools/workflows: Compliance test suites; third‑party attestations; sector‑specific persona libraries certified for audits.
- Assumptions/dependencies: Consensus on metrics; regulator guidance; accessible, representative reference corpora per sector/locale.
- Simulation‑as‑a‑Service platforms (industry platforms)
- What: Managed services that evolve persona generators against each client’s (privacy‑preserving) dialogue logs and provide continuous robustness testing.
- Tools/workflows: Enterprise data connectors, DP/federated updates, automated evolution pipelines, dashboards.
- Assumptions/dependencies: Strong privacy and legal frameworks; cost‑effective compute orchestration.
- Multimodal and speech/voice expansion (call centers, voice assistants, robotics/HRI)
- What: Extend personas to prosody, latency, interruptions, and non‑verbal cues; test voice bots and robots under realistic conversational friction.
- Tools/workflows: Speech synthesis/ASR hooks; multimodal fingerprints; tool‑use latency modeling.
- Assumptions/dependencies: New feature sets beyond text; multimodal datasets; careful user safety design.
- Cross‑lingual, cross‑cultural persona libraries and fairness auditing (global deployments)
- What: Generate and validate personas that reflect cultural and linguistic variation; detect disparate performance across groups.
- Tools/workflows: Locale‑specific reference corpora; translation‑aware fingerprints; fairness reporting by persona clusters.
- Assumptions/dependencies: High‑quality multilingual human data; domain expertise; bias and harm assessments.
- Learned behavioral representations beyond handcrafted fingerprints (research, platform teams)
- What: Replace 19 regex‑based features with learned embeddings trained on human dialogues to improve realism and reduce gaming.
- Tools/workflows: Self‑supervised or contrastive models; robust discriminators; calibration to interpretable axes.
- Assumptions/dependencies: Larger, diverse datasets; interpretability methods; safeguards against adversarial drift.
- Real‑time adaptive training and “shadow‑mode” coaching (contact centers, SaaS copilots)
- What: Dynamically generate hard personas during training or live shadow sessions to coach agents and human operators.
- Tools/workflows: Online evolution with safety rails; performance‑triggered persona injection; feedback loops.
- Assumptions/dependencies: Low‑latency infra; clear separation from live customer interactions; monitoring.
- Continual simulator updating from live data (MLOps)
- What: Periodically evolve personas as user behavior shifts (seasonality, product changes) to avoid evaluation drift.
- Tools/workflows: Scheduled retraining; data versioning; drift detection on fingerprint distributions.
- Assumptions/dependencies: Ongoing access to de‑identified interaction logs; governance for update cadence.
- Personalization and user‑state inference modules (product innovation)
- What: Train agents to infer and adapt to user states (patience, skepticism) learned from persona diversity—improving alignment and satisfaction.
- Tools/workflows: Auxiliary classifiers for user state; policy adapters conditioned on inferred state; offline evaluation with personas.
- Assumptions/dependencies: Careful privacy and ethics; calibration to avoid stereotyping or harmful profiling.
- Curriculum learning for agent robustness (research/engineering)
- What: Structured progression from cooperative to increasingly challenging personas to stabilize training and improve generalization.
- Tools/workflows: Auto‑curricula keyed to coverage targets; early‑stopping on overfit to single styles.
- Assumptions/dependencies: Reliable difficulty measures; large‑scale training budgets.
- Certified sector‑specific “persona packs” and marketplaces (ecosystem)
- What: Curated, audited persona sets for healthcare, finance, education, etc., bundled with compliance checks and success criteria.
- Tools/workflows: Distribution portals; versioned packs; integration guides for common frameworks.
- Assumptions/dependencies: Community governance; liability and IP clarity for persona definitions and data.
- Crisis communications and emergency response training (public sector, NGOs)
- What: Simulate high‑stress, anxious, or confused users to train and evaluate information triage agents and SOPs.
- Tools/workflows: Scenario libraries; after‑action reports tied to behavioral axes; joint human‑AI drills.
- Assumptions/dependencies: Expert‑curated scenarios; alignment with emergency protocols; ethical oversight.
Cross‑cutting assumptions and risks
- Availability and representativeness of real human dialogue corpora strongly influence calibration and fairness.
- Underlying LLM simulator quality constrains realism; weaker simulators may limit gains.
- Compute and cost considerations for multi‑persona rollouts and evolution loops.
- Risk of adversarial drift if using a single proxy metric; the paper’s combined human‑likeness + coverage helps mitigate this but requires careful monitoring.
- Privacy, consent, and compliance: any use of real dialogues must be de‑identified and governed by policy/IRB as appropriate.
- Generalization to new domains, modalities, and cultures requires further validation.
Glossary
Agent--User Rollout: A procedure involving interaction between an autonomous agent and a user (simulated or real) within a specific task context. Example: "We evaluate candidate generators through actual agent--user rollouts."
Behavioral Fingerprint: A vector representation of user interaction characteristics, tracking aspects like communication style and information disclosure. Example: "We convert each trajectory into a behavioral fingerprint."
Behavioral Gap: The difference in performance or behavior between simulated environments and real-world conditions. Example: "This creates a behavioral gap: agents can appear strong against cooperative simulators but fail..."
Behavioral Variation: Differences in behavior exhibited by user simulators to reflect real human diversity. Example: "A plug-and-play control layer that induces realistic behavioral variation in user simulators."
Chamfer Error: A metric used to assess the distance between two sets of points in behavioral space, applied to measure coverage realism. Example: "The two-sided Chamfer error is..."
Clarification Behavior: Interaction Pattern where users ask questions or confirm details to clarify misunderstandings during dialogues. Example: "Clarification-question rate and pushback rate (D3)."
Communication Style: The way users convey information, including politeness, ambiguity, and terseness. Example: "Organized across communication style, information disclosure, clarification behavior, and error reaction."
Control Layer: A mechanism that influences an underlying system, guiding its behavior or output without altering foundational aspects. Example: "We design as a plug-and-play control layer that injects realistic behavioral diversity."
Evolutionary Program Search: An optimization process leveraging iterative adaptations to find optimal program configurations. Example: "Learning these policies is framed as evolutionary program search."
Fitness Score: A measure of how well a system meets predefined objectives during optimization, combining multiple evaluation criteria. Example: "Candidate generators are guided by a multi-objective fitness score."
Human-likeness: A measure of how closely simulated user interactions resemble real human interactions. Example: "Human-likeness, measured as the probability of being classified as human."
MAP-Elites Archive: A strategy of partitioning solutions into diverse bins to maintain variety during evolution. Example: "A MAP-Elites archive over these objectives keeps the population diverse..."
Multi-Objective: An approach considering several evaluation criteria (such as human-likeness and coverage) simultaneously during optimization. Example: "Combining human-likeness with broad coverage of human behavioral patterns."
Natural-language Reflection: Feedback generated in human-readable form to guide system adaptations. Example: "The resulting critique guides targeted code edits, gradually pushing the simulator away..."
Roleplay Policies: Guidelines that determine how a simulated persona interacts in various scenarios, influencing communicative actions. Example: "Expands each profile into task-preserving roleplay instructions."
Simulator--Human Gap: The discrepancy between outcomes or behaviors from simulated environments versus real human interactions. Example: "Evolved personas narrow the simulator--human gap."
Task-preserving Roleplay: A scenario where user behavior is varied while ensuring task objectives and contexts remain constant. Example: "While preserving objectives and private knowledge provided in $s_{\mathrm{base}(t)$."
Two-sided Chamfer Error: A metric incorporating distances from both simulated and reference behaviors to assure realistic diversity. Example: "Two-sided Chamfer error checks proximity to the human behavior distribution."
Collections
Sign up for free to add this paper to one or more collections.