REDA One Centro de ajuda
PT
Idioma
English EN Español ES Português PT Italiano em breve Français FR Deutsch em breve العربية em breve
reda.one ↗
Início / REDA AI / Conversas e transcrições / Depurador de conversas

Depurador de Conversas

Depurador de Conversas O Depurador de Conversas lê a transcrição completa de uma única conversa — mensagens, chamadas de ferramentas, prompts, contexto — e usa o modelo para identificar a causa raiz de um turno problemático. Ele retorna uma análise estruturada com a sequência responsável, as evidências e recomendações concretas.

O que ele faz

Depurar manualmente uma conversa longa de um agente é tedioso. O Debugger automatiza a parte que você faria manualmente: ler cada turno, encontrar onde o problema começou e explicar o que deu errado em termos da configuração do agente.

É uma análise assistida por IA — o modelo lê a conversa e produz um veredito estruturado. Você fornece o Id da conversa e, opcionalmente, uma instrução (por exemplo, “por que o agente não enviou o e-mail?”); o Debugger retorna sua análise como um objeto estruturado.

O Resultado da Análise

Campo Significado
rootCause Uma breve declaração do que realmente deu errado — não o sintoma, a causa subjacente.
problemAtSequence O número de sequência da mensagem onde o problema se originou. Clique para ir até esse turno na transcrição e ver a troca responsável.
evidence A citação específica, chamada de ferramenta, contexto ausente ou fragmento de prompt montado que sustenta o diagnóstico.
recommendations Uma lista curta de correções concretas — por exemplo, adicionar uma ferramenta, editar um prompt, expandir uma configuração de campo de contexto.
severity low, medium ou high — o quão grave é o problema encontrado, não o quanto o analisador está certo. Não existe pontuação de confiança.
stopReason O motivo de parada do modelo para a execução do agente analisada (end_turn, max_tokens, stop_sequence). A interface exibe isso para que você identifique respostas truncadas imediatamente.
creditsUsed Créditos consumidos pela chamada de análise.
rawAnalysis Se o JSON estruturado não pôde ser interpretado, a saída bruta do modelo é retornada aqui como alternativa.
error Preenchido para falhas que não são exceções — limite de créditos atingido, restrições de licença, problemas de configuração.

O Que o Debugger Inspeciona

Para a conversa em análise, o Debugger vê os mesmos dados que orientaram a execução original, além das saídas dessa execução:

  • O prompt de sistema montado do agente — persona, instruções, esquema e diretrizes de idioma
  • As ferramentas que o agente tinha disponíveis, com categorias, níveis e canais
  • A configuração dos campos de contexto e o contexto de registro efetivamente carregado
  • Cada mensagem de usuário e de assistente em sequência
  • Cada chamada de ferramenta — nome da ferramenta, entrada, saída (ou erro)
  • O uso de tokens e o motivo de parada de cada turno do agente
  • Sua instrução opcional em linguagem natural (por exemplo, “por que a resposta está vazia?”)

Esse é o panorama completo que o Debugger precisa para chegar a uma conclusão útil — nada fica escondido em uma caixa-preta.

  • Pré-visualização de Execução do Agente mostra o que um agente vai carregar na próxima conversa. Gratuita e somente leitura. Use-a para verificar a configuração antes que qualquer conversa aconteça.
  • Transcrição de Conversas mostra as mensagens brutas e as chamadas de ferramentas. Gratuita, sem análise.
  • Depurador de Conversas aplica análise de IA à transcrição e retorna um diagnóstico. Consome créditos, mas produz uma declaração real de causa raiz e recomendações.

Use a Transcript quando você conseguir ler uma conversa curta mentalmente; use o Debugger quando a conversa for longa, o sintoma for sutil ou você quiser uma segunda opinião.

Como Funciona uma Execução

  1. Abra a conversa

    Seja pela lista de conversas da guia REDA AI Admin, seja diretamente por um link do Salesforce para o registro de Conversation subjacente.

  2. Clique em Debug Conversation

    A interface do Debugger carrega a transcrição e o histórico de ferramentas.

  3. Adicione uma instrução

    Se você tiver uma pergunta específica (“por que não chamou send_email?”, “por que a resposta veio no idioma errado?”), digite-a. Sem uma instrução, o Debugger procura qualquer problema óbvio ao longo da conversa.

  4. Execute a análise

    A plataforma envia o contexto da conversa para o modelo e aguarda a resposta estruturada.

  5. Leia o resultado

    Causa raiz, sequência do problema, evidências, recomendações e severidade são exibidos ao lado da transcrição, para que você possa verificar a análise em relação à troca real.

  6. Aplique as recomendações

    As correções costumam ser feitas na definição do agente, em um Prompt personalizado, em uma configuração de campo de contexto ou em uma ferramenta. Execute novamente uma conversa semelhante após a correção para confirmar.

Severidade e stopReason

A análise traz uma severidade — high, medium ou low — que descreve o quão grave é o problema encontrado, não o quanto o Debugger está certo dele. Não existe uma pontuação de confiança separada. high aponta para um problema de configuração claro que vale corrigir agora; medium, algo que merece atenção; low normalmente significa que a conversa foi um caso extremo, e não um bug.

Junto com ela você recebe Problem at sequence — o número da mensagem em que, segundo a análise, as coisas deram errado, para ir direto àquele turno da transcrição — e Evidence, o trecho em que a conclusão se apoia. Leia a evidência antes de agir sobre a recomendação: é o que permite discordar do Debugger quando ele erra.

Preste atenção separada ao stopReason:

  • end_turn — o modelo terminou de forma limpa. O diagnóstico é sobre conteúdo, não sobre infraestrutura.
  • max_tokens — a resposta foi truncada pelo orçamento de resposta. Costuma ser a causa real quando o agente “não responde”. Aumente o orçamento de saída do agente ou simplifique o prompt.
  • stop_sequence — o modelo atingiu uma parada configurada. Menos comum; geralmente esperado.

A interface exibe o stopReason diretamente, para que você reconheça o truncamento antes de ler o restante da análise.

Não confunda os limites do visualizador com os do modelo. Para manter o relatório legível, o Depurador encurta o que exibe: o conteúdo das mensagens em cerca de 500 caracteres e o contexto das ferramentas em cerca de 2.000. Um texto que termina no meio da frase no relatório costuma ser apenas esse limite de exibição — o truncamento que importa é o que o stopReason informa como max_tokens.

Custo em Créditos e Tempo

Cada análise é uma chamada de modelo. O custo em créditos escala com a extensão da conversa e o tamanho do contexto montado que o Debugger vê. A plataforma reporta os créditos efetivamente consumidos.

Conversas longas com muitas chamadas de ferramentas custam mais créditos e demoram mais para serem analisadas, porque mais transcrição é enviada ao modelo.

O Que o Debugger Não Faz

  • Não corrige nada automaticamente. A saída é um diagnóstico com recomendações; você aplica as correções manualmente na definição do agente, nos prompts, nas ferramentas ou nos campos de contexto.
  • Não executa a conversa novamente. A análise é feita sobre a transcrição já existente. Para validar uma correção, execute uma conversa semelhante e (opcionalmente) depure essa também.
  • Não garante uma única causa raiz. Algumas conversas têm vários problemas; o Debugger escolhe a causa raiz mais provável, mas deve ser combinado com o seu julgamento.
  • Não substitui o Registro de incidentes. Falhas graves (exceções Apex, erros de callout) são registradas no Registro de incidentes. O Debugger é para problemas comportamentais em que a conversa foi concluída, mas o resultado ficou errado.

Boas Práticas

Comece com uma instrução. Uma execução vazia do Debugger produz uma análise genérica. Dizer ao Debugger o que te incomodou na conversa foca o diagnóstico.

Leia o stopReason primeiro. Se a resposta foi truncada, corrigir o orçamento costuma ser uma mudança de um único caractere, não uma reescrita do prompt.

Verifique a citação de evidência. O Debugger nomeia a sequência responsável e cita evidências. Clique para ir até esse turno antes de aceitar a recomendação; às vezes o modelo interpreta errado.

Aplique uma recomendação por vez. Aplique a recomendação mais acionável, execute uma conversa semelhante e depois itere. Várias mudanças simultâneas confundem a relação causa-efeito.

Combine com a Runtime Preview depois das correções. Depois de ajustar o agente, abra a Runtime Preview para confirmar que a correção realmente mudou o que o agente vê.

Perguntas frequentes

Não. Ele produz um diagnóstico com recomendações concretas. Você aplica as correções manualmente — geralmente pequenos ajustes em um prompt, uma ferramenta ou uma configuração de campo de contexto.

Sim. As execuções assíncronas produzem registros de conversa e mensagem idênticos aos das execuções síncronas; o Debugger os inspeciona da mesma forma. Veja Processamento assíncrono de agentes.

Ocasionalmente o modelo retorna um texto que não pode ser interpretado no formato JSON esperado. Quando isso acontece, o texto bruto é retornado em rawAnalysis como alternativa para que a análise não se perca. Executar novamente geralmente produz uma resposta estruturada limpa.

Sim. Todo canal produz os mesmos registros de conversa e mensagem. O Debugger lê esses registros diretamente, então o canal não importa.

Execute novamente com uma instrução mais específica informando ao Debugger o que estava errado. Severidade low geralmente significa que o analisador não conseguiu identificar o problema sem mais contexto. Uma instrução direcionada costuma elevar a severidade se o bug for real.

Falhas graves são registradas no Registro de incidentes. Para esses casos, use a ferramenta de depuração de incidentes. O Depurador de Conversas trata os casos em que a conversa foi executada, mas o resultado ficou errado.

As recomendações do Debugger apontam para coisas que você pode alterar — prompts, contexto, ferramentas. Se a análise disser “o modelo se comportou corretamente dada a configuração”, isso é uma dica direta de que você precisa mudar a configuração, não culpar o modelo.

Próximos passos

Leia Transcrições de conversas para entender a estrutura de registros subjacente que o Debugger lê, ou Debug with AI on Incidents para o mesmo padrão aplicado a falhas graves.