Última revisão: junho de 2026
Uma referência rápida dos padrões arquiteturais que o exame C1000-180 avalia. Leia de cima a baixo ou pule para uma seção.
Novo assistente; escolhendo o paradigma de autoria.
Construa com o editor de Ações, não com a skill legada de Diálogo. As Ações modelam conversas orientadas a tarefas como etapas, condições e variáveis sem gerenciar uma árvore de nós.
Por quê: As Ações são o modelo de autoria atual e recomendado da IBM; o Diálogo é legado e mais difícil de manter. Os exames profissionais pressupõem um design focado em ações.
Decidir como dividir um grande domínio de suporte em unidades.
Defina uma ação por objetivo discreto do usuário (redefinir senha, verificar saldo, agendar consulta). Mantenha as ações com um único propósito e reutilizáveis.
Por quê: Ações mais específicas e com escopo de tarefa são mais fáceis de testar, analisar e melhorar do que fluxos monolíticos que tentam lidar com tudo.
A entrada do usuário pode acionar várias ações semelhantes.
Habilite a desambiguação para que o assistente apresente um menu esclarecedor de ações candidatas em vez de adivinhar.
Por quê: A desambiguação reduz erros de ações incorretas e revela a intenção real do usuário, melhorando a taxa de conclusão.
O assistente não compreende o usuário após várias tentativas.
Projete um caminho "Nenhuma ação corresponde" / "qualquer outra coisa" com uma resposta esclarecedora e, após N falhas, uma escalada para um agente humano.
Por quê: Um fallback definido evita loops sem saída e protege o CSAT; a falta de correspondência não detectada é um dos principais motivos de abandono.
A conversa excede a competência do assistente ou o usuário está frustrado.
Adicione uma etapa de "conectar ao agente" que transfere para um service desk (por exemplo, Zendesk, Genesys, Salesforce) com o contexto da conversa anexado.
Por quê: Passar a transcrição e as variáveis coletadas para o agente evita forçar o usuário a se repetir.
As partes interessadas querem uma voz de marca consistente em todas as respostas.
Defina uma persona e um guia de tom desde o início; crie o texto das respostas de forma consistente e reutilize variações para evitar repetições robóticas.
Por quê: Um tom consistente constrói confiança; misturar frases formais e informais em diferentes ações parece desconexo.
Um detalhe necessário é ambíguo ou está faltando na frase do usuário.
Faça uma pergunta esclarecedora direcionada por meio de um slot, em vez de assumir um valor padrão.
Por quê: A confirmação explícita de parâmetros de alto risco (valor, conta, data) evita ações erradas caras.
Projetando um novo fluxo com muitos casos de borda.
Crie o "caminho feliz" de ponta a ponta primeiro, depois adicione validações, digressões e ramificações de erro.
Por quê: Construir casos de borda antes do fluxo principal leva a ações super-engenhosas e difíceis de testar.
Ação precisa de várias informações antes de poder ser concluída.
Colete cada valor em sua própria etapa como um slot; o assistente solicita por qualquer um ainda não fornecido e pula os já fornecidos.
Por quê: O preenchimento de slots baseado em etapas lida com entradas fora de ordem e com múltiplos valores sem ramificações manuais.
Um valor deve persistir após o término da ação atual.
Armazene-o em uma variável de sessão, não em uma variável de etapa/ação. As variáveis de ação têm escopo para a ação; as variáveis de sessão vivem para toda a conversa.
Por quê: Escolher o escopo errado é um bug clássico: o valor desaparece quando a ação é concluída ou falha ao ser compartilhado entre ações.
Uma etapa pede ao usuário para escolher entre um conjunto conhecido e fixo.
Use um tipo de resposta de "opções" com escolhas definidas em vez de texto livre, e mapeie cada opção para um valor.
Por quê: As opções restringem a entrada, eliminam a ambiguidade de análise e são renderizadas como botões nos canais suportados.
Um valor coletado (e-mail, data, quantia) pode estar malformado.
Adicione uma condição de validação na etapa; se inválida, mantenha o usuário na etapa com um prompt corretivo.
Por quê: A validação no momento da captura evita passar dados incorretos para extensões e etapas subsequentes.
Etapas posteriores devem ser executadas apenas para certos usuários ou valores.
Defina condições de etapa em variáveis já coletadas para que as etapas sejam ignoradas quando a condição for falsa.
Por quê: As condições expressam ramificações sem duplicar ações; o editor as avalia de cima para baixo.
Múltiplas ações precisam do mesmo subfluxo (por exemplo, verificar identidade).
Fatore a lógica compartilhada em uma sub-ação e chame-a de cada ação pai.
Por quê: As sub-ações mantêm a lógica de verificação DRY e consistente; a duplicação de etapas causa dessincronização.
Usuário faz uma pergunta não relacionada no meio do fluxo ("quais são o seu horário?").
Permita a digressão para que o assistente responda à pergunta secundária e depois retorne à ação interrompida.
Por quê: Bloquear digressões força um roteiro rígido que frustra os usuários com solicitações secundárias legítimas.
Precisa calcular ou transformar um valor dentro de uma etapa.
Use a linguagem de expressão integrada (por exemplo, funções de string e matemática em variáveis) na etapa ou resposta.
Por quê: Transformações leves pertencem a expressões; recorrer a um webhook para matemática trivial é um exagero.
Uma ação de acompanhamento precisa de um valor que o usuário forneceu anteriormente.
Referencie a variável de sessão existente em vez de solicitar novamente.
Por quê: Pedir novamente por dados já conhecidos parece quebrado; levar o contexto adiante é uma característica de um bom fluxo.
Um fluxo deve parar ou pular para outra ação sob uma condição.
Use "finalizar a ação" ou uma transição "ir para uma etapa em outra ação" para controlar o fluxo explicitamente.
Por quê: Transições explícitas evitam a passagem inesperada para a próxima etapa após uma condição terminal.
O assistente deve chamar uma API REST documentada para buscar dados em tempo real.
Importe a especificação OpenAPI da API como uma extensão personalizada e, em seguida, adicione uma etapa de "chamar uma extensão" que mapeia variáveis para parâmetros.
Por quê: Extensões personalizadas são a forma suportada e sem código de chamar APIs externas a partir de uma etapa com entradas/saídas tipadas.
Escolhendo entre um webhook e uma extensão personalizada.
Use uma extensão personalizada para chamar uma API externa de dentro de uma etapa específica; use um webhook (pré/pós-mensagem) para executar lógica em cada mensagem ou transformar o payload inteiro.
Por quê: Webhooks são acionados globalmente por mensagem; extensões são escopadas e mapeadas por parâmetro por etapa. Escolher o errado é uma armadilha comum em exames.
A API de destino requer autenticação.
Configure a autenticação (chave de API, OAuth, básica) ao adicionar a extensão personalizada; armazene segredos na configuração da extensão, não no texto do diálogo.
Por quê: Incorporar credenciais em variáveis ou respostas as expõe em logs e transcrições.
Uma chamada de extensão retorna um erro ou excede o tempo limite.
Ramifique na resposta/status da extensão na próxima etapa e exiba uma mensagem de fallback ou caminho de repetição.
Por quê: Falhas de extensão não tratadas deixam o usuário preso; sempre projete o caminho não-200.
Precisa enriquecer ou redigir cada mensagem antes de processar ou antes de enviar.
Use um webhook de pré-mensagem para pré-processar a entrada e um webhook de pós-mensagem para transformar a resposta antes da entrega.
Por quê: Webhooks de pré/pós-mensagem centralizam preocupações transversais (mascaramento de PII, log) sem editar todas as ações.
Usuários fazem perguntas abertas que podem ser respondidas a partir de um corpus de documentos.
Habilite a pesquisa conversacional (RAG): recupere passagens de uma integração de pesquisa e faça com que um modelo fundamental watsonx.ai gere uma resposta fundamentada com citações.
Por quê: A pesquisa conversacional cobre a cauda longa de perguntas que você não pode criar como ações discretas.
Escolhendo o armazenamento de recuperação por trás da pesquisa conversacional.
Conecte watsonx Discovery / Elasticsearch (ou outra integração de pesquisa suportada) como o índice para recuperação.
Por quê: A qualidade da fundamentação depende do índice de recuperação; um corpus não indexado ou mal dividido retorna passagens fracas.
A pesquisa conversacional não encontra passagens relevantes.
Configure a resposta de "nenhum resultado de pesquisa" para que o assistente diga que não sabe em vez de alucinar, e ofereça escalonamento.
Por quê: Um caminho de "nenhum resultado" definido é o que mantém um assistente RAG honesto e fundamentado.
A conformidade exige que as respostas generativas sejam rastreáveis.
Habilite citações de fonte para que as respostas geradas exibam os documentos dos quais foram extraídas.
Por quê: As citações permitem que os usuários verifiquem as respostas e satisfazem a auditabilidade em indústrias regulamentadas.
Ajustando a qualidade e o custo das respostas generativas.
Selecione o modelo fundamental watsonx.ai (por exemplo, um modelo Granite) para pesquisa conversacional e ajuste as configurações de geração para o caso de uso.
Por quê: A escolha do modelo e dos parâmetros envolve um tradeoff entre qualidade da resposta, latência e custo; os padrões nem sempre são ótimos.
Decidindo se uma consulta é tratada por uma ação ou por pesquisa.
Direcione tarefas transacionais e parametrizadas para ações; direcione perguntas informativas abertas para a pesquisa conversacional.
Por quê: Forçar perguntas tipo FAQ em ações rígidas, ou transações em RAG, degrada a experiência.
O assistente deve atender chamadas telefônicas recebidas.
Use a integração de telefone/voz (gateway de voz sobre SIP) para conectar um provedor de telefonia, com STT para entrada e TTS para respostas.
Por quê: O gateway de voz conecta a telefonia SIP ao assistente; sem ele, não há canal telefônico.
Respostas faladas soam erradas ou não reconhecem corretamente o chamador.
Ajuste o modelo/idioma de fala para texto e a voz de texto para fala nas configurações de integração telefônica.
Por quê: Vozes/modelos padrão podem não corresponder ao idioma ou vocabulário do domínio, prejudicando o reconhecimento e a clareza.
Um fluxo construído para chat tem baixo desempenho em voz.
Adapte fluxos de voz: evite botões/listas longas, mantenha os prompts curtos e confirme valores falados explicitamente.
Por quê: A voz não consegue renderizar UI rica; fluxos otimizados para texto com menus quebram quando lidos em voz alta.
Alcançar usuários via SMS / mensagens de texto.
Configure a integração de SMS (telefone/texto); projete para respostas em texto simples sem elementos ricos.
Por quê: O SMS remove tipos de resposta ricos; as respostas devem degradar-se graciosamente para texto.
O chat da web deve exibir imagens, cartões ou botões.
Use tipos de resposta ricos (imagem, opções, cartão) na ação; o canal renderiza os tipos suportados e, caso contrário, usa um fallback.
Por quê: Respostas ricas melhoram a experiência do usuário na web, mas devem ter um fallback de texto simples sensato para voz/SMS.
Medindo se o assistente está realmente ajudando.
Use o painel de Análises para rastrear a taxa de conclusão, cobertura e entradas reconhecidas versus não reconhecidas ao longo do tempo.
Por quê: Métricas de vaidade como contagem de sessões não refletem o sucesso da tarefa; a conclusão e a cobertura sim.
Procurando por que os usuários abandonam um fluxo.
Leia logs/transcrições de conversas, filtre por ação e identifique etapas de abandono e frequentes "nenhuma correspondência".
Por quê: Transcrições reais revelam as lacunas que as métricas agregadas apenas sugerem.
As sugestões de desambiguação frequentemente estão na ordem errada.
Habilite o autoaprendizado para que o assistente reordene as sugestões com base na opção que os usuários realmente escolhem.
Por quê: O autoaprendizado melhora a relevância a partir de seleções reais sem necessidade de retreinamento manual.
Muitas entradas resultam em "nenhuma ação corresponde".
Extraia entradas não reconhecidas das análises, agrupe-as e crie novas ações ou adicione exemplos às existentes.
Por quê: Lacunas de cobertura são a melhor alavanca de melhoria; são as consultas que você está falhando completamente.
Uma solicitação válida não está acionando sua ação de forma confiável.
Adicione frases reais de usuários como exemplos de treinamento à etapa dessa ação para que o reconhecimento melhore.
Por quê: O reconhecimento se fortalece com exemplos representativos extraídos de logs, não com frases inventadas.
Validando que uma mudança melhorou os resultados.
Faça uma alteração de cada vez, publique e compare a conclusão/cobertura antes e depois em um período significativo.
Por quê: Mudar muitas coisas de uma vez torna impossível atribuir o movimento das métricas.
Autores editam enquanto usuários finais interagem com o assistente.
Crie no ambiente de rascunho; os usuários interagem com o ambiente ativo. Publique uma versão do rascunho para o ambiente ativo quando estiver pronto.
Por quê: A divisão rascunho/ativo permite iterar com segurança sem expor trabalho inacabado à produção.
Um conjunto de alterações testado está pronto para produção.
Crie uma versão (instantâneo) e publique-a no ambiente ativo; as versões anteriores permanecem disponíveis para rollback.
Por quê: O versionamento oferece um histórico auditável e um rollback rápido se uma versão regredir.
Rascunho e ativo devem apontar para diferentes endpoints de back-end (teste vs. produção).
Defina configurações de extensão/integração específicas do ambiente para que cada ambiente direcione os sistemas corretos.
Por quê: Compartilhar um único endpoint entre ambientes pode fazer com que o tráfego de teste atinja sistemas de produção.
Implementando o assistente para chat web, telefone, Slack e WhatsApp.
Adicione e configure cada integração de canal no ambiente de destino; os canais são anexados por ambiente.
Por quê: Um canal habilitado apenas no rascunho não atenderá usuários de produção até ser configurado no ambiente ativo.
Membros diferentes da equipe precisam de diferentes níveis de acesso.
Use o IBM Cloud IAM para atribuir acesso baseado em função (por exemplo, visualizador, editor, operador, gerente) ao serviço watsonx Assistant ou ao grupo de recursos.
Por quê: O acesso com privilégio mínimo via funções IAM é a maneira suportada de controlar quem pode criar versus operar.
Organizando serviços e limites de acesso entre equipes ou projetos.
Coloque o serviço do assistente em um grupo de recursos e defina o escopo das políticas de acesso do IAM para esse grupo.
Por quê: Grupos de recursos fornecem limites claros de faturamento e acesso; contas planas tornam-se inadministráveis em escala.
Um aplicativo externo precisa chamar o assistente via API.
Gere credenciais de serviço / uma chave de API e o URL do assistente, e chame a API de tempo de execução v2 com eles.
Por quê: O acesso programático usa credenciais com escopo definido; reutilizar logins pessoais é inseguro e não suportado.
Regras de residência de dados ou "air-gap" proíbem a nuvem pública.
Implante watsonx Assistant no Cloud Pak for Data (on-premise ou nuvem privada) em vez do IBM Cloud SaaS.
Por quê: Indústrias regulamentadas frequentemente exigem on-premise/CP4D para isolamento de dados e conformidade.
Escolhendo um plano para um lançamento em produção com alto volume.
Selecione o plano de serviço apropriado (por exemplo, Plus/Enterprise) para o volume, recursos e SLA necessários.
Por quê: Planos Lite/trial limitam o uso e carecem de recursos de produção; dimensione corretamente o plano antes do lançamento.
Dados sensíveis aparecem em conversas e logs.
Use isolamento de dados, redação de logs/mascaramento de PII (por exemplo, via webhooks) e configure as configurações de retenção/segurança de logs.
Por quê: PII não mascarado em transcrições é uma responsabilidade de conformidade; mascare na ingestão e controle a retenção.