TL;DR: Este artigo apresenta o USR-8, uma rubrica de oito métricas para avaliar simuladores de usuário em agentes conversacionais. Desenvolvido pela Microsoft Foundry, o framework separa comportamento de estilo e revela falhas que uma nota composta esconde. Testado em 1.200 conversas, o estudo mostra que o prompt define a qualidade do simulador, não o harness. A principal conclusão: a política do prompt é o ativo mais importante.
Simuladores de usuário se tornaram peça padrão no kit de ferramentas de construção de agentes: mais baratos que pilotos com usuários reais, mais rápidos que diálogos roteirizados e a única maneira de submeter um agente a centenas de conversas plausíveis entre cada mudança de código. A pergunta difícil é a seguinte: como saber se o próprio simulador é bom?
É fácil subestimar o quanto pode dar errado. Um simulador que encerra cada turno com "Muito obrigado pela sua ajuda!" vai inflar silenciosamente as notas do seu agente. Um simulador que orienta o agente ("você poderia verificar as regras de tarifa primeiro?") esconderá falhas por trás de empurrões úteis. Um simulador que tira notas altas em uma métrica holística de "coerência do usuário" ainda pode produzir conversas que se concentram nas mesmas duas aberturas e nos mesmos quatro nomes inventados. Nenhum desses modos de falha é visível na ficha de notas do agente; todos a distorcem. Se o harness de teste não for medido com o mesmo rigor que o agente, você está de volta ao "vibes" — só que com números maiores anexados.
Este post é um estudo de pesquisa sobre como desenvolvemos e medimos a qualidade do simulador de usuário do Microsoft Foundry. O post oferece duas contribuições: 1) uma Rubrica de Oito Métricas para Simulação de Usuário (USR-8), um framework mínimo, ortogonal e suficiente para pontuar um simulador de usuário que separa comportamento de estilo e revela modos de falha que uma única nota composta apaga; e 2) um conjunto de achados empíricos da aplicação dessa rubrica em 1.200 conversas, três domínios e quatro configurações de simulador.
A versão curta, adiantada: em 1.200 conversas abrangendo três domínios e quatro configurações de simulador, o simulador de usuário do Foundry pontuou no teto ou perto dele em todas as métricas por conversa, exceto realismo, e uma pequena revisão no prompt fechou a lacuna de realismo. Mais interessante: o mesmo prompt carregado em um harness de terceiros produziu conversas indistinguíveis em todas as métricas medidas — então a maior parte do que faz um simulador "bom" vive na política do prompt, não no código de orquestração. Esse último achado se generaliza bem além do Foundry, e é o que mais gostaríamos que outros grupos que fazem esse tipo de avaliação testassem contra seus próprios sistemas.
Quais são as duas filosofias de simulação de usuário?
Antes de avaliar um simulador de usuário, você precisa decidir o que quer que ele seja. Existem duas respostas coerentes, e elas puxam em direções opostas.
Filosofia A — Realistic foil. O simulador mantém o personagem e nunca orienta o agente. Se o agente pula uma etapa, o simulador percebe da maneira que um cliente real perceberia — ficando confuso, frustrado ou seguindo em frente — não dizendo "você esqueceu de verificar as regras de tarifa". As falhas de conversa atribuíveis ao agente permanecem visíveis e limpas. Isso é o que você quer quando está medindo a qualidade intrínseca do agente.
Filosofia B — Helpful tester. O simulador faz parte de um benchmark de sucesso de tarefa ponta a ponta. Ele pode empurrar o agente de volta ao caminho certo quando ele sai do script, mas apenas como um usuário cooperativo real faria: respondendo a perguntas esclarecedoras e fornecendo detalhes ausentes, não orientando o agente sobre como fazer seu trabalho. Essa ajuda pode mascarar falhas, então essa configuração mede se a tarefa é concluída pelo agente e simulador juntos. Trate o resultado como uma taxa de sucesso otimista em nível de sistema: ela credita a ajuda do simulador e pode superestimar a capacidade isolada do agente se essa ajuda se transformar em orientação.
Nenhuma filosofia está errada. Elas servem a diferentes casos de uso de produto, e a escolha tem consequências diretas para o que suas pontuações significam.
| Você está tentando... | Use Filosofia A | Use Filosofia B |
|---|---|---|
| Comparar dois prompts de agente | ✅ | ⚠️ (ajuda do simulador pode achatar diferenças) |
| Pegar regressões durante o desenvolvimento | ✅ | ⚠️ |
| Medir sucesso de tarefa ponta a ponta | ⚠️ (sem ajuda pode levar a taxas de aprovação mais baixas) | ✅ |
| Red-team para entradas adversariais | precisa de sementes de persona | ✅ |
| Gerar conversas de amostra realistas | ✅ | ❌ |
O simulador do Microsoft Foundry é construído em torno da Filosofia A: fique no personagem, não oriente. Vários frameworks de simulador de usuário de terceiros amplamente usados padronizam a Filosofia B — um prompt de abertura fixo e instruções explícitas para o usuário simulado corrigir o agente quando ele perde uma etapa. Voltaremos a esse contraste quando examinarmos os resultados.
A primeira coisa a fazer, antes de pontuar qualquer coisa, é escolher a filosofia que corresponde ao seu caso de uso. Caso contrário, você acabará medindo um simulador em uma tarefa para a qual ele não foi projetado.
Oito métricas para pontuar um simulador de usuário
Depois de escolher uma filosofia, você precisa de uma rubrica. Métricas genéricas de agente — adesão à tarefa, resolução de intenção, precisão de chamada de ferramenta — não se aplicam, porque o simulador não está tentando completar a tarefa, está tentando ser um usuário.
Construímos o USR-8: oito métricas de LLM-judge especificamente para avaliar a saída do simulador de usuário. Projetamos essas métricas para serem mínimas, ortogonais e suficientes — cada uma captura um modo de falha distinto que não pode ser inferido de forma confiável a partir das outras. Sete são por conversa; uma é no nível de coorte. Todas pontuam em uma escala inteira de 1 a 5 com uma breve justificativa, e todas foram julgadas por um modelo GPT de última geração rodando com baixo esforço de raciocínio.
Métricas por conversa (cada juiz vê a transcrição completa e o cenário original):
- Clarity — O usuário declara seu pedido com clareza suficiente para que um agente competente possa agir sem adivinhar? Penaliza pedidos ambíguos, fragmentados ou subespecificados.
- Relevance — O usuário permanece no tópico especificado pelo cenário? Penaliza deriva, desvios fora do tópico e trocas de tópico em massa. Não penaliza o usuário quando o agente sai do tópico.
- Steering — O usuário mantém a conversa avançando em direção ao seu objetivo sem orientar o agente — ou seja, sem dizer ao agente como fazer seu trabalho? Uma pontuação alta requer direcionamento produtivo que pare antes de se tornar o gerente do agente. Esta é a barreira de proteção da Filosofia A; espere que um simulador da Filosofia B pontue mais baixo aqui por design.
- Responsiveness — Cada turno do usuário reconhece e responde ao que o agente acabou de dizer, em vez de ignorá-lo ou repetir pedidos anteriores? Capta opções que o agente realmente ofereceu.
- Consistency (coherence) — O usuário mantém uma identidade coerente única, conjunto de fatos e linha de conversação em toda a conversa? Penaliza autocontradição — por exemplo, mudar um código de reserva no meio da conversa.
- Realism — O usuário soa como um humano escrevendo no momento, hesitações, falsos começos, contrações, registro emocional que se encaixa no cenário, imperfeição plausível — em vez de um ghostwriter polido representando um papel? Esta métrica pontua quão humano o texto parece, não se o comportamento está correto.
- Persona fidelity — Quando o cenário especifica uma persona ("cliente frustrado que retorna", "engenheiro de plantão júnior", "consultor jurídico interno"), o usuário a incorpora fielmente? Padrão é 5 quando o cenário não especifica traços particulares.
Métrica de coorte (julgada em toda uma execução de conversas):
- Diversity — Em, digamos, 100 conversas do mesmo simulador no mesmo conjunto de cenários, quão variadas são as conversas? Considera nomes distintos, aberturas distintas, registros emocionais distintos e termos de pontuação únicos. 1 = visivelmente agrupado (mesmos nomes, mesmo modelo de abertura); 5 = alta variedade em todos os eixos.
Algumas notas sobre o design:
- Separe comportamento de estilo. Clareza, relevância, steering, responsividade, consistência e fidelidade de persona descrevem o que o simulador faz. Realismo descreve como soa. Eles tendem a se mover independentemente e confundi-los esconde sinais importantes.
- Inclua uma barreira de não orientação. Se você está na Filosofia A, precisa de pelo menos uma métrica que penalize explicitamente o simulador por orientar o agente. Caso contrário, o viés do juiz sobre turns "úteis" do usuário deixará a orientação passar.
- Pontue o coorte, não apenas a conversa. Métricas por conversa podem estar no teto enquanto o coorte está visivelmente agrupado. A diversidade capta isso.
- Use cenários, não scripts. Um "cenário" em nossa configuração é uma breve descrição de tarefa em prosa (tipicamente 80–200 palavras) dada ao simulador como "a coisa que o usuário está tentando realizar hoje". O simulador inventa detalhes concretos — nomes, códigos de reserva, datas, contagens de erros — que o cenário não especifica. Isso sonda intencionalmente a capacidade do simulador de permanecer no personagem enquanto improvisa de forma plausível.
O subconjunto mínimo, em nossa experiência, é relevance + steering + consistency + realism: cobre comportamento no tópico, não orientação, coerência dentro da conversa e qualidade da prosa. As outras quatro afunilam o quadro, especialmente ao comparar dois simuladores que parecem próximos no conjunto mínimo.
Como colocamos à prova
Três agentes, em três domínios. Criamos três agentes do Microsoft Foundry, cada um em modo de simulação (respostas de ferramenta geradas por um modelo GPT de última geração contra um catálogo de ferramentas em vez de um backend ao vivo), escolhidos para abranger tanto o tom consumidor vs profissional quanto a forma conversacional de turno curto vs turno longo:
- airline-customer-service-sim — reembolsos, rebooking, consultas de regras de tarifa, franquia de bagagem, mudanças de assento, 12 ferramentas.
- sre-incident-triage-sim — engenheiro de plantão que confirma alertas, consulta propriedade de serviço, abre incidentes, pagina runbooks, coordena rollback, 9 ferramentas.
- legal-contract-review-sim — acordos de fornecedores, cláusulas de responsabilidade e indenização, desvios de um modelo de contrato, rascunhos de negociação, 8 ferramentas.
Dez cenários por domínio, dez conversas por cenário. Por configuração de simulador: 10 cenários × 10 conversas × 3 domínios = 300 conversas. Com quatro configurações de simulador, são 1.200 conversas pontuadas. O design 10 × 10 dá meias larguras de IC de 95% de 0,05–0,15 nas métricas por conversa — apertado o suficiente para detectar efeitos acima de ~0,1.
Quatro configurações de simulador. É daí que vêm as alegações comparativas:
- Foundry user simulator, baseline prompt — um prompt anterior, antes da revisão de realismo, incluído aqui como uma linha de base de ablação.
- Foundry user simulator, production prompt — o prompt de produção atual, cuja revisão focada em realismo é a mudança que isolamos abaixo.
- Um framework de simulador de usuário de terceiros publicamente disponível com seu prompt padrão.
- O mesmo framework de terceiros com nosso prompt de produção portado através de seu mecanismo de customização de prompt. Este foi o experimento de isolamento — mesmo modelo subjacente, mesmo harness de terceiros, mesmos cenários; apenas o prompt trocado. Se os resultados mudassem drasticamente, o prompt era a alavanca; se permanecessem estáveis, o harness era.
Cada conversa em todas as quatro configurações foi pontuada pelos oito juízes. Total de julgamentos: aproximadamente 10.000.
O que descobrimos
Três descobertas merecem relato detalhado.
1. O simulador Foundry está no teto ou perto dele em todas as métricas, exceto realismo
Para o prompt de linha de base (antes da revisão de realismo), com n=100 conversas por domínio:
| Métrica | Airline | SRE | Legal |
|---|---|---|---|
| Clarity | 5.00 | 4.89 | 5.00 |
| Relevance | 5.00 | 5.00 | 5.00 |
| Steering | 5.00 | 4.86 | 5.00 |
| Responsiveness | 5.00 | 5.00 | 5.00 |
| Consistency | 5.00 | 5.00 | 5.00 |
| Persona fidelity | 4.48 | 4.89 | 4.86 |
| Realism | 3.97 | 4.13 | 3.34 |
Diversidade, a oitava métrica do USR-8, é no nível de coorte em vez de por domínio, então não aparece nesta tabela por conversa; em nosso conjunto de cenários atual, ainda não discrimina entre simuladores. Cinco das sete métricas por conversa estão essencialmente fixadas em 5,00. Fidelidade de persona é forte sem estar no teto. Realismo é o desempenho consistentemente inferior. As notas do juiz apontam o que está faltando em linguagem simples: fraseado limpo e polido, sem hesitação, sem falsos começos, sem contrações, nomes que parecem cópia de marketing ("Priya Singh", "Olivia Hartwell"), e um tique de fechamento polido que agradece ao agente como um cliente real raramente faz.
Em outras palavras, o simulador soa menos como um cliente e mais como um ghostwriter profissional representando um cliente.
2. Uma única revisão no prompt fechou a lacuna de realismo
A revisão de realismo (agora o padrão de produção) focou inteiramente em registro, hesitação e eliminação do tique de agradecimento de fechamento, moveu o realismo em +0,61 no airline, +0,62 no SRE e +1,06 no legal, sem regressão em nenhuma outra métrica. Os deltas são 4–10 vezes a meia largura do IC de 95% em cada domínio, bem fora do ruído.
Isso diz algo específico sobre como "melhorar um simulador de usuário" realmente se parece na prática: no estágio de prompt de produção, as edições de alta alavancagem são sobre registro de prosa, não sobre comportamento. As métricas de comportamento já estavam fixadas no teto; o trabalho que moveu a agulha foi trabalho de estilo.
3. A maior parte da lacuna estava no prompt, não no harness
Uma descoberta surpreendente veio do experimento de isolamento. O simulador de terceiros com seu prompt padrão pontuou realismo na faixa 1,5–2,0 nos três domínios — 2,5–3,2 pontos abaixo do simulador Foundry. As notas do juiz nomearam duas falhas recorrentes: vazamento de meta-raciocínio no turno do usuário ("Passo 1: Analisar o que o Agente disse. Passo 2: …") e orientação explícita do agente ("Parece que você pulou uma etapa. Você poderia verificar as regras de tarifa primeiro?"). Ambos os comportamentos são exigidos pelo prompt padrão de terceiros e proibidos pelo Foundry.
Quando portamos o prompt de produção do Foundry no hook de customização de prompt do framework de terceiros — mesmo modelo, mesmo harness, mesmos cenários, apenas o prompt trocado — o realismo no harness de terceiros saltou para 4,4–4,6, essencialmente igualando a referência de produção do Foundry (4,4–4,7). Em todas as métricas por conversa, o fechamento da lacuna ficou na faixa de 96–99%. Ambos os modos de falha que havíamos sinalizado na execução padrão — o vazamento de raciocínio e a orientação — desapareceram assim que o prompt do Foundry foi colocado.
Leia isso pelo que realmente significa: o comportamento do simulador é codificado principalmente na política do prompt, não no código de orquestração. Os dois harnesses são semelhantes o suficiente para que, dado o mesmo prompt, produzam conversas indistinguíveis em todas as métricas por conversa medidas. Onde eles divergem é na política padrão que cada um envia — e essa política é editável.
A consequência prática, com a ressalva de que comparamos apenas dois harnesses: dentro desse par, a escolha do framework importou muito menos do que o prompt rodando sobre ele. Não vamos generalizar demais a partir de dois sistemas, mas a direção é clara — a maior parte do comportamento que medimos estava na política do prompt, e esse é o ativo que vale a pena investir.
Uma nota sobre diversidade
Em todas as quatro configurações, a diversidade do coorte pontuou um plano 2/5. Isso é uma característica do conjunto de cenários, não do simulador: quando o simulador recebe os mesmos 10 cenários em prosa 10 vezes, ele produz conversas que se agrupam em nomes, aberturas e registros emocionais. Discriminar entre simuladores em diversidade exigirá cenários muito mais ricos ou um mecanismo de semente de persona que forneça arquétipos de persona nomeados, por exemplo, cooperativo feliz; frustrado; mal informado; adversarial; falante não nativo; baixo esforço. Isso está em nosso roadmap; não é uma correção de curto prazo que você pode colocar em um simulador existente.
Recomendações metodológicas
Uma lista de verificação para qualquer equipe fazendo esse tipo de avaliação — no simulador do Foundry ou em outro — com base nas lacunas que encontramos e nas escolhas que valeram a pena:
- Escolha a filosofia primeiro. Decida se você está medindo um realistic foil ou um helpful tester, escreva essa decisão e projete suas métricas em torno dela. Misturá-las dentro de uma rubrica produz pontuações incoerentes.
- Separe comportamento de estilo. Use pelo menos uma métrica por categoria. Concretamente: em nossa comparação linha de base versus produção, toda a melhoria foi no realismo enquanto todas as métricas de comportamento permaneceram planas — prova de que uma única nota composta teria calculado a média do único sinal que se moveu.
- Adicione uma métrica explícita de não orientação (sob Filosofia A). Juízes LLM tendem a recompensar utilidade; sem uma penalidade explícita, a orientação passa e é pontuada como comportamento consciente.
- Rode com n ≥ 100 por condição. Abaixo disso, os ICs são muito largos para chamar efeitos abaixo de ~0,5 de forma confiável. Pegamos uma aparente falha catastrófica em n=10 que acabou sendo um artefato de amostragem em n=100.
- Pontue o coorte, não apenas a conversa. Um juiz de diversidade no nível de coorte foi o que nos disse que nossa fraqueza de diversidade estava vinculada ao conjunto de cenários, não ao simulador.
- Use cenários, não scripts. Forçar o simulador a improvisar especificidades é o que revela fidelidade de persona e realismo. Diálogos roteirizados deixam um simulador fraco passar por não ter nada para inventar.
- Construa um conjunto de calibração avaliado por humanos. Algumas dezenas de conversas, avaliadas manualmente por pelo menos dois anotadores, é um ponto de partida razoável para limitar o viés do juiz via correlação de Spearman, embora o tamanho certo dependa também da concordância inter-humana e precise ser validado. Não fizemos calibração humana para este estudo e esta é uma lacuna metodológica importante a ser fechada em trabalhos futuros.
- Sempre compare com pelo menos uma linha de base externa. Uma pontuação em uma rubrica personalizada só significa algo em relação a outro simulador pontuado na mesma rubrica. "4,7 de 5" parece excelente isoladamente, mas se um simulador de linha de base também pontua 4,7, você não aprendeu nada sobre seu simulador — apenas que a rubrica é generosa. Linhas de base externas defendem você contra seu próprio otimismo.
- Ao comparar, isole a variável. A saída de um simulador depende de múltiplos componentes — no mínimo o prompt e o harness ao redor, frequentemente também a configuração do juiz e o modelo. Um confronto direto entre dois simuladores muda todos eles de uma vez, então o resultado é ininterpretável: você não pode dizer qual componente impulsionou a lacuna. Rode pelo menos um experimento de troca que mantenha tudo constante, exceto a variável que você importa — porte seu prompt para o outro harness, ou o deles para o seu, e reavalie. Sem uma troca controlada, números de framework vs framework são uma medição confundida, não um resultado.
Onde esse tipo de medição tem limites
Simuladores de usuário não são o instrumento certo para toda avaliação. Três ressalvas honestas:
- Um oráculo determinístico vence uma conversa simulada, quando existe. Se você pode afirmar programaticamente que um registro de reembolso foi criado, essa verificação é mais rigorosa e mais barata do que julgar uma conversa inteira; então reserve a simulação de usuário para o que nenhum oráculo pode ver: tom, persistência e recuperação de confusão.
- Você não pode validar fatos inventados contra um sistema real. Como o simulador de usuário inventará especificidades como códigos de reserva, números de conta e datas, nada que ele afirme pode ser verificado cruzadamente com registros de verdade fundamental; portanto, a simulação não pode testar a correção que depende de identificadores reais. Isso é estrutural, não um defeito do simulador.
- Comportamentos adversariais são um design diferente. Um simulador construído para permanecer no personagem não é, por construção, construído para tentar ativamente quebrar o agente. Red-teaming pertence a uma trilha de avaliação separada com suas próprias métricas.
Dentro desses limites, a metodologia faz o que precisamos: quantifica realismo, coerência, comportamento no tópico e fidelidade de persona em uma escala que a avaliação manual não pode alcançar.
Considerações finais
Três conclusões valem a pena serem levadas deste trabalho, independentemente de você olhar ou não para o simulador de usuário do Foundry especificamente.
- Ferramentas de avaliação também podem estar erradas. Avaliação é recursiva: qualquer ferramenta que você usa para pontuar seu agente é em si um sistema que pode estar errado. Um simulador que soa polido pode lisonjear um agente medíocre; um simulador que orienta quando não deveria pode esconder regressões reais.
- Comportamento e estilo são eixos separados. Falhas de estilo (o problema do ghostwriter polido) e falhas de comportamento (o problema da orientação) se movem independentemente e exigem correções diferentes. Uma única nota composta apaga esse sinal.
- O prompt fez a maior parte do trabalho. Trocar o prompt entre dois harnesses fechou 96–99% da lacuna medida em cada métrica por conversa. Uma comparação justa entre frameworks de simulador tem que controlar o prompt — senão você está medindo prompts, não frameworks. Vimos isso nos dois harnesses que comparamos; um harness com mais lógica de simulação poderia mover os resultados mais, então trate isso como um sinal forte, não uma lei universal.
Simuladores de usuário são como as equipes enviam agentes conversacionais sem esperar por usuários reais. Medí-los com o mesmo rigor que os agentes que eles devem testar é o que mantém a avaliação ponta a ponta honesta.
Perguntas Frequentes
-
O que é o USR-8?
É uma rubrica de oito métricas (sete por conversa e uma por coorte) para avaliar simuladores de usuário, projetada para ser mínima, ortogonal e suficiente. Separa comportamento (clareza, relevância, steering, responsividade, consistência, fidelidade de persona) de estilo (realismo) e inclui uma métrica de diversidade no nível do coorte. -
Qual a diferença entre as Filosofias A e B de simulação?
A Filosofia A (Realistic Foil) mantém o simulador em personagem e nunca orienta o agente — ideal para medir a qualidade intrínseca do agente. A Filosofia B (Helpful Tester) permite que o simulador corrija o agente, medindo a conclusão conjunta da tarefa, mas pode mascarar falhas. A escolha depende do caso de uso. -
Como o estudo mostrou que o prompt é mais importante que o harness?
Ao portar o prompt de produção do Foundry para um harness de terceiros, as diferenças nas métricas por conversa fecharam em 96–99%. Com o mesmo prompt, os dois harnesses produziram conversas indistinguíveis. Isso indica que a política do prompt codifica a maior parte do comportamento do simulador. -
O que fazer se meu simulador tem baixo realismo?
O estudo mostra que uma revisão focada no registro da prosa — hesitações, contrações, eliminação de agradecimentos polidos — pode elevar o realismo em mais de 1 ponto (em escala de 5) sem regredir outras métricas. Invista em ajustes de estilo, não de comportamento, se as métricas comportamentais já estão no teto. -
Qual o tamanho de amostra recomendado para avaliar um simulador?
O estudo recomenda n ≥ 100 conversas por condição para obter intervalos de confiança estreitos (0,05–0,15) e detectar efeitos acima de ~0,1. Amostras menores (n=10) podem gerar artefatos de amostragem que simulam falhas catastróficas.
Artigo originalmente publicado por José Santos, Shuo Qiu, Morteza Ziyadi em Azure Updates - Latest from Azure Charts.
