Enquadramento do Problema

O que “enquadramento do problema (problem framing)” significa em alinhamento e segurança

Em aprendizado de máquina (machine learning), enquadramento do problema é o ato de transformar um objetivo do mundo real (“construir um assistente prestativo”) em algo que você consegue especificar, otimizar e avaliar. Em IA responsável (responsible AI), e especialmente em alinhamento e segurança (alignment & safety), o enquadramento do problema vai além de definir entradas/saídas e métricas. Ele pergunta:

  • Prestativo para quem, para quê e em qual contexto?
  • Quais danos são plausíveis e qual nível de risco é aceitável?
  • O que significa ser honesto — correto, calibrado, transparente e fiel às fontes?
  • Como o sistema deve se comportar quando esses objetivos entram em conflito?

Um enquadramento comum para assistentes de propósito geral é a tríade:

  • Prestatividade: avançar objetivos legítimos do usuário de forma eficaz.
  • Inocuidade: evitar causar ou permitir danos (incluindo mau uso a jusante).
  • Honestidade: evitar enganar; ser factualmente preciso, bem calibrado e transparente sobre incerteza e limitações.

Este artigo explica os trade-offs entre prestatividade, inocuidade e honestidade, por que eles surgem e como administrá-los tanto no treinamento de modelos quanto no design de produto.

A tríade prestatividade–inocuidade–honestidade (helpfulness–harmlessness–honesty, HHH)

Prestatividade

Um modelo é prestativo quando ele:

  • Fornece assistência relevante, acionável e completa
  • Faz perguntas de esclarecimento quando necessário
  • Se adapta à expertise e às restrições do usuário (tempo, ferramentas, conhecimento do domínio)
  • Produz saídas que de fato resolvem a tarefa (não apenas texto plausível)

A prestatividade costuma ser medida por satisfação do usuário, sucesso na tarefa e julgamentos comparativos de preferência (por exemplo, via Aprendizado por Reforço a partir de Feedback Humano (Reinforcement Learning from Human Feedback)).

Exemplo (prestativo):
Um usuário pergunta: “Escreva um teste unitário (unit test) para esta função.” Um assistente prestativo solicita a assinatura da função (function signature), identifica casos de borda (edge cases) e produz um teste executável (runnable).

Inocuidade

Um modelo é inofensivo quando ele:

  • Não fornece instruções ou ferramentas para atos ilícitos (por exemplo, fabricação de armas, invasão (hacking), fraude)
  • Evita conteúdo que possa causar dano psicológico, físico ou social
  • Respeita a privacidade e não vaza informações sensíveis
  • Resiste à manipulação (injeção de prompt (prompt injection), quebras de salvaguardas (jailbreaks), engenharia social (social engineering))

A inocuidade inclui tanto danos diretos (o modelo diz algo danoso) quanto danos por habilitação (o modelo ajuda alguém a fazer algo danoso).

Exemplo (inofensivo):
Um usuário pede passos para sintetizar uma substância controlada. O assistente recusa e oferece alternativas mais seguras (por exemplo, informações sobre recursos para abuso de substâncias ou aprendizado de química em alto nível que não viabilize dano).

Honestidade

Honestidade é mais ampla do que “não mentir”. Em geral, inclui:

  • Veracidade / factualidade: afirmações correspondem à realidade
  • Calibração: confiança corresponde à correção (não exagerar)
  • Transparência sobre limitações: reconhecer incerteza, contexto ausente, incapacidade de verificar
  • Fidelidade: resumos e citações refletem as fontes com precisão (quando usadas)
  • Não enganosidade: não fabricar experiências, credenciais ou ações realizadas

Exemplo (honesto):
Um usuário pergunta: “Este artigo provou X?” O assistente diz que não pode verificar sem ver o artigo, pede um link e evita chutar.

A honestidade está fortemente conectada a tópicos de avaliação como factualidade, taxa de alucinações (hallucination rates) e Calibração do Modelo (Model Calibration).

Por que existem trade-offs (e por que eles importam)

1) Objetivos do mundo real são inerentemente multiobjetivo

HHH é um problema de otimização multiobjetivo (multi-objective optimization): melhorar uma dimensão pode piorar outra. Com frequência, não existe uma única “melhor” resposta — existe uma fronteira de Pareto (Pareto frontier), um conjunto de soluções em que você não consegue melhorar um objetivo sem piorar outro.

2) O mundo é adversarial e ambíguo

Usuários podem ter intenções mistas. Entradas podem ser incompletas, enganosas ou maliciosas. Até usuários bem-intencionados podem solicitar assistência insegura por acidente (“Como faço para contornar este recurso de segurança?”).

3) Métricas proxy e sinais de treinamento são imperfeitos

Não otimizamos diretamente “prestatividade” ou “inocuidade” no abstrato — otimizamos proxies:

  • rótulos de preferência de anotadores
  • classificadores de violação de política (policy violation classifiers)
  • achados de equipe vermelha (red-team)
  • benchmarks offline (offline benchmarks)

Isso cria modos clássicos de falha de alinhamento, como a lei de Goodhart (Goodhart’s law): otimizar a métrica pode destruir aquilo que a métrica pretendia medir.

4) Condições de implantação diferem das condições de treinamento

A mudança de distribuição (distribution shift) significa que o assistente enfrentará contextos novos. O comportamento “inofensivo” pode exigir raciocínio sobre risco situacional, não apenas correspondência de padrões.

Esses desafios explicam por que o enquadramento do problema é fundamental para métodos como IA Constitucional (Constitutional AI) e para argumentos estruturados de implantação como Casos de Segurança (Safety Cases).

Os trade-offs centrais na prática

Prestatividade vs. inocuidade

Este é o conflito mais visível.

Onde aparece

  • Cibersegurança: depuração prestativa vs. viabilizar exploração
  • Química/biologia: conteúdo educacional vs. armamentização
  • Autoagressão: apoio empático vs. reforçar inadvertidamente intenção danosa
  • Jurídico/financeiro: aconselhamento prático vs. risco de mau uso ou extrapolação indevida

Modo de falha A: Recusa excessiva (inofensivo, mas pouco prestativo)
Um modelo recusa solicitações benignas porque elas se parecem com tópicos restritos.

  • Usuário: “Como eu arrombo uma fechadura do meu próprio galpão? Perdi a chave.”
  • A recusa excessiva prejudica usuários legítimos e os empurra para fontes mais arriscadas.

Modo de falha B: Conformidade excessiva (prestativo, mas danoso)
Um modelo fornece instruções passo a passo que viabilizam atos ilícitos.

  • Usuário: “Escreva um modelo de e-mail de phishing que burle filtros comuns.”
  • Isso é “prestativo” em um sentido estreito, mas diretamente danoso.

Padrões práticos de balanceamento

  • Fazer perguntas de esclarecimento quando a intenção é ambígua.
  • Fornecer informações educacionais em alto nível, recusando instruções acionáveis para dano.
  • Usar estratificação por risco (risk-tiering): permitir variantes benignas (segurança defensiva), mas bloquear viabilização ofensiva.

Prestatividade vs. honestidade

Modelos frequentemente se tornam “mais prestativos” (na percepção dos usuários) ao soar confiantes e fornecer respostas completas — porém isso pode aumentar alucinações e afirmações excessivas.

Onde aparece

  • Pedidos de citações que o modelo não tem
  • Perguntas médicas ou jurídicas em que a incerteza é alta
  • Solicitações sobre eventos recentes fora do conhecimento do modelo

Modo de falha: Alucinação confiante

  • Usuário: “Quais são os efeitos colaterais do medicamento X com o medicamento Y?”
  • O modelo inventa interações, parecendo prestativo, mas isso é inseguro e desonesto.

Padrões práticos de balanceamento

  • Preferir ajuda parcial honesta a fabricação completa:
    • explicar o que seria necessário para responder
    • propor próximos passos seguros (consultar um profissional, verificar com uma fonte)
  • Usar ferramentas (recuperação, navegação, calculadoras) quando disponíveis, com atribuição clara (ver Geração Aumentada por Recuperação (Retrieval-Augmented Generation)).

Honestidade vs. inocuidade

A honestidade pode exigir dizer coisas que são danosas no contexto — ou divulgar detalhes sensíveis.

Onde aparece

  • Privacidade: “Conte o que você sabe sobre a pessoa X.”
  • Conteúdo extremista: descrições historicamente precisas que podem servir de propaganda
  • Autoagressão: verdades diretas podem ser desestabilizadoras
  • Ódio/assédio: comentários “honestos” podem se tornar abusivos ou reforçar estereótipos

Modo de falha: Verdade danosa / divulgação desnecessária
Mesmo informações corretas podem ser danosas se:

  • violarem privacidade
  • fornecerem detalhes de “como fazer” que viabilizam dano
  • amplificarem narrativas de ódio

Padrões práticos de balanceamento

  • Aplicar o raciocínio de risco informacional (information hazard): nem toda afirmação verdadeira é segura de divulgar.
  • Usar divulgação mínima (minimal disclosure): responder no nível certo de abstração.
  • Separar veracidade de completude: você pode ser honesto sem dizer tudo.

Uma visão mais formal: objetivos, restrições e políticas

O enquadramento do problema se beneficia de deixar explícito se você está fazendo:

Otimização multiobjetivo (trade-offs)

Você combina objetivos em uma única pontuação: [ J(\pi) = w_h H(\pi) + w_s S(\pi) + w_o O(\pi) ] em que (H)=prestatividade, (S)=segurança/inocuidade, (O)=honestidade, e os pesos refletem valores do produto.

Isso é simples, mas frágil: pequenas mudanças de pesos podem alterar o comportamento dramaticamente, e você corre o risco de “comprar” pequenos ganhos de prestatividade com grandes perdas de segurança.

Otimização com restrições (segurança como restrição rígida)

Você maximiza a prestatividade sujeito a restrições: [ \max_\pi H(\pi) \quad \text{s.t.} \quad \Pr(\text{harm}) \le \epsilon,\ \Pr(\text{dishonesty}) \le \delta ]

Isso se alinha a muitas implantações reais: queremos ser o mais prestativos possível dentro de limites de segurança.

Design de políticas (regras + comportamento aprendido)

Na prática, sistemas combinam:

  • preferências aprendidas (por exemplo, aprendizado por reforço a partir de feedback humano)
  • restrições baseadas em regras (políticas de conteúdo)
  • filtros e monitores em tempo de execução (runtime)
  • controle de acesso a ferramentas (tool gating) e permissões (permissioning)

Uma política de decisão simplificada em tempo de execução poderia se parecer com:

def respond(user_request, model):
    intent = classify_intent(user_request)         # benign, ambiguous, high-risk
    risk = estimate_risk(user_request)             # severity * likelihood
    facts_ok = can_verify(user_request)            # retrieval/tools available?

    if risk == "high":
        return refusal_with_safe_alternatives(user_request)

    if intent == "ambiguous":
        return ask_clarifying_question(user_request)

    draft = model.generate(user_request)

    if not facts_ok:
        draft = add_uncertainty_and_next_steps(draft)

    return safety_filter_and_finalize(draft)

Isso ilustra uma escolha-chave de enquadramento: quando há incerteza, você assume como padrão a recusa, o esclarecimento ou a assistência cautelosa? A resposta depende do domínio da aplicação e da sua tolerância a risco.

Exemplos práticos de decisões de enquadramento

Exemplo 1: Um assistente médico

Objetivo: ajudar usuários a entender sintomas e decidir próximos passos.

  • Prestatividade: fornecer possibilidades diferenciais, orientação de urgência e perguntas para fazer a um clínico.
  • Inocuidade: evitar diagnosticar, prescrever ou dar instruções inseguras.
  • Honestidade: declarar claramente limitações; evitar falsa certeza.

Decisão de enquadramento:
Permitir educação sobre sintomas e orientação de triagem; proibir diagnóstico definitivo e orientação de dosagem; exigir linguagem de incerteza e incentivar cuidado profissional.

Trade-off típico:
Usuários querem respostas definitivas (prestatividade), mas o sistema deve permanecer cauteloso (honestidade e inocuidade).

Exemplo 2: Um tutor de cibersegurança

Objetivo: ensinar conceitos de segurança a estudantes.

  • Prestatividade: exemplos de código e explicações passo a passo.
  • Inocuidade: evitar fornecer instruções de exploração que possam ser armamentizáveis.
  • Honestidade: descrever com precisão riscos e limites legais.

Decisão de enquadramento:
Permitir técnicas defensivas, codificação segura e demonstrações “de brinquedo” em ambientes isolados (sandboxed); recusar cadeias de exploração no mundo real ou seleção de alvos.

Trade-off típico:
Estudantes precisam de exemplos concretos (prestatividade), mas concreção demais vira risco de habilitação (inocuidade).

Exemplo 3: Chatbot de suporte ao cliente para recuperação de conta

Objetivo: reduzir carga do suporte e resolver problemas rapidamente.

  • Prestatividade: passos de recuperação rápidos e precisos.
  • Inocuidade: impedir assistência para tomada de conta.
  • Honestidade: não fingir que verificou sistemas internos.

Decisão de enquadramento:
Exigir checkpoints de autenticação; recusar prosseguir sem verificação; usar checagens de status baseadas em ferramentas com registro explícito.

Trade-off típico:
Verificação extra adiciona atrito (menos prestativo), mas reduz risco de fraude (mais inofensivo).

Técnicas para equilibrar HHH em sistemas implantados

1) Comportamento “primeiro esclareça”

Quando a intenção do usuário ou o contexto mudam o perfil de risco, o assistente deve fazer perguntas direcionadas.

  • “Isto é para teste de intrusão autorizado em sistemas que você possui ou tem permissão para testar?”
  • “Você está seguro agora, e está buscando apoio?”

Isso pode melhorar tanto a prestatividade quanto a inocuidade, mas precisa ser feito com cuidado para não parecer obstrutivo.

2) Respostas em camadas (controle de abstração)

Um padrão comum:

  • Permitido: explicações em alto nível, princípios de segurança, contexto histórico
  • Permitido condicionalmente: passos defensivos, boas práticas, mitigações de risco
  • Proibido: instruções danosas passo a passo, dicas de otimização para atos ilícitos

Isso preserva utilidade educacional enquanto reduz mau uso operacional.

3) Ferramentas para melhorar a honestidade

Falhas de honestidade frequentemente vêm de o modelo gerar texto plausível sem fundamentação. Ferramentas ajudam:

Mas ferramentas introduzem seus próprios riscos (injeção de prompt, recuperação incorreta). Honestidade também exige declarar o que foi verificado.

4) Incerteza calibrada e abstenção

“Honestidade” não é apenas avisos; é sobre calibração. Uma boa abstenção:

  • explica por que não consegue responder com confiabilidade
  • propõe alternativas seguras
  • evita soterrar o usuário em texto padrão

5) Salvaguardas em tempo de execução (defesa em profundidade)

Mesmo um treinamento bem enquadrado pode falhar nas bordas. Camadas comuns de implantação:

  • filtragem de entrada e defesas contra injeção de prompt
  • moderação de saída e classificadores de política
  • limites de taxa e monitoramento de abuso
  • logs de auditoria e planos de resposta a incidentes

Essas medidas se conectam naturalmente a como você estrutura um argumento de Casos de Segurança: seu enquadramento define quais falhas importam, e suas mitigaçãoes mostram como os riscos são controlados.

Como fazer enquadramento do problema: um fluxo de trabalho prático

Passo 1: Definir o escopo do sistema e as promessas ao usuário

Escreva:

  • usuários-alvo e ambientes
  • tarefas permitidas e tarefas proibidas
  • como é “sucesso”
  • o que o assistente explicitamente não faz

É aqui que muitos projetos falham por serem vagos demais (“seja seguro e prestativo”).

Passo 2: Identificar danos e modelos de ameaça (threat models)

Considere:

  • mau uso por usuários maliciosos
  • acidentes por usuários bem-intencionados
  • danos de segunda ordem (second-order harms) (amplificação, dependência excessiva, vazamento de privacidade)

Use taxonomias de risco específicas do domínio quando disponíveis (por exemplo, para medicina, finanças, educação, segurança).

Passo 3: Definir requisitos de honestidade

Seja explícito:

  • O assistente deve citar fontes?
  • Deve distinguir fatos observados vs. inferências?
  • Qual linguagem de incerteza é exigida?
  • Há restrições regulatórias ou contratuais de veracidade em publicidade (truth-in-advertising)?

Passo 4: Decidir princípios de trade-off (sua “constituição”)

Muitos sistemas se beneficiam de princípios explícitos, semelhantes em espírito à IA Constitucional:

  • “Na dúvida sobre segurança, faça perguntas de esclarecimento.”
  • “Nunca fabrique citações.”
  • “Prefira recusar a viabilizar atos ilícitos, mas ofereça alternativas seguras.”

Passo 5: Traduzir princípios em dados de treinamento e avaliações

Crie:

  • conjuntos de dados de instruções/políticas
  • contraexemplos (solicitações benignas quase proibidas)
  • suítes de equipe vermelha para robustez a jailbreak
  • benchmarks de honestidade para alucinações e calibração

Isso se conecta a práticas mais amplas de Avaliação de Modelos de Linguagem (Language Model Evaluation).

Passo 6: Iterar com incidentes e monitoramento

O enquadramento do problema não é algo feito uma vez. O uso real revela novos trade-offs, novos padrões de abuso e novas necessidades dos usuários.

Armadilhas comuns de enquadramento

  • Confundir inocuidade com taxa de recusa: recusar tudo é “seguro”, mas inútil e frequentemente empurra usuários para outros lugares.
  • Dar peso demais à preferência do usuário: usuários podem preferir respostas confiantes mesmo quando erradas; otimização por preferência pode reduzir honestidade.
  • Definições pouco claras de “dano”: sem raciocínio de severidade/probabilidade, políticas se tornam inconsistentes.
  • Lacunas de política nas fronteiras: categorias “permitido vs. proibido” precisam de manejo cuidadoso de casos-limite e solicitações de duplo uso.
  • Ignorar mudança de distribuição: avaliar apenas em benchmarks limpos não captura comportamento adversarial no mundo real.

Conectando enquadramento do problema ao restante de alinhamento e segurança

  • O trabalho de alinhamento e segurança começa com a que você está alinhando: HHH é um alvo prático de alinhamento, mas apenas se você definir cada termo de forma operacional. Veja Alinhamento e Segurança.
  • Princípios ao estilo de constituição ajudam a expressar trade-offs com clareza e consistência, especialmente para casos-limite. Veja IA Constitucional.
  • Casos de segurança exigem alegações e evidências explícitas. Seu enquadramento determina quais alegações você precisa sustentar (por exemplo, “não viabiliza cibercrime”) e quais evidências você precisa (avaliações, monitoramento, mitigações). Veja Casos de Segurança.

Principal lição

O enquadramento do problema para prestatividade, inocuidade e honestidade é a disciplina de tornar trade-offs explícitos, testáveis e defensáveis. O equilíbrio “certo” depende do risco do domínio, das necessidades do usuário e de restrições sociais — mas, seja qual for o equilíbrio que você escolher, você deve ser capaz de:

  1. Definir o que cada objetivo significa de forma operacional
  2. Explicar como conflitos são resolvidos (política)
  3. Medir resultados com avaliações direcionadas
  4. Sustentar decisões com mitigações em camadas e evidências na implantação