Inteligência Artificial Segurança Cibernética SOC RAG Alucinações

Agentes de IA em Segurança Cibernética: O Caminho para um Membro Confiável da Equipe

Este artigo explora como agentes de Inteligência Artificial (IA) podem ser integrados em equipes de segurança cibernética, destacando os desafios e as estratégias para garantir sua confiabilidade. Aborda a sobrecarga de trabalho dos SOCs, o potencial da IA, e os riscos de alucinações em modelos de linguagem.

MundiX News·09 de maio de 2026·23 min de leitura·👁 4 views

64K+ Alcance em 30 dias Yandex Cloud & Yandex Infrastructure Construindo uma plataforma B2B e infraestrutura da Yandex 258,12 Avaliação 35 310 Assinantes Assinar nesteru 3 minutos atrás Agentes de IA em Segurança Cibernética: O Caminho para um Membro Confiável da Equipe 23 min 4 Blog da Yandex Cloud & Yandex Infrastructure Segurança da Informação * Inteligência Artificial Aprendizado de Máquina * Padrões de TI * No controlador de domínio, o sistema EDR registra atividade suspeita. Parece nada demais. Um alerta comum, um dos vários milhares que o SOC processa diariamente. No entanto, em 15 minutos, esse incidente levará ao caos completo no departamento de segurança da informação e congelará as operações de toda a empresa.

Meu nome é Sergey Nesteruk, e sou responsável pela segurança da aplicação da inteligência artificial na Yandex Cloud. Neste artigo, contarei como evitar a situação que acabei de descrever.

SOC vs. IA Um SOC moderno opera em condições de sobrecarga, com até 1.000 alertas por dia por analista, com até 95% deles sendo falsos positivos. Com essa carga de trabalho, a investigação de incidentes reais, especialmente ataques complexos de várias etapas, corre o risco de levar meses, o que aumenta o risco de danos aos negócios.

A utilização de assistentes de IA na área de segurança parece um passo lógico. No entanto, é importante avaliar corretamente suas capacidades. Em março de 2026, a Anthropic publicou o estudo " Labor market impacts of AI: A new measure and early evidence " (autores - Maxim Massenkoff e Peter McCrory), no qual analisaram como várias profissões podem ser automatizadas com IA:

Em vermelho está a exposição observada (observed exposure) - a proporção de tarefas que já estão sendo realmente automatizadas com IA com base em dados sobre o uso do Claude. Em azul está a exposição teórica (theoretical exposure): com base no banco de dados O*NET, que cobre cerca de 800 profissões nos EUA, e dados sobre o uso do Claude, os especialistas estimaram quais tarefas podem, em princípio, ser aceleradas com a ajuda de LLMs. Por exemplo, para profissões nas áreas de ciência da computação e matemática, a exposição teórica atinge 94%, enquanto a observada é de apenas 33%. A lacuna entre os setores azul e vermelho é o potencial de automação não realizado, que está sendo gradualmente reduzido.

Justificativa: o estudo descobriu que, embora os modelos teóricos sugiram uma exposição de 94% das tarefas na área de "computadores e matemática", a cobertura real do Claude é de cerca de 33%. O banco de dados O*NET lista tarefas relacionadas a cerca de 800 profissões exclusivas nos EUA.

No entanto, com o crescimento espontâneo do uso da IA, a proteção não pode crescer tão espontaneamente, ela precisa ser implementada, sistematicamente e de forma planejada, levando em consideração todas as limitações de aplicabilidade na área de segurança. Há uma lacuna entre a velocidade de desenvolvimento da IA e a velocidade de implementação de novas formas de proteção.

Por que os antigos métodos de proteção não funcionam aqui? A questão é a mudança na própria lógica dos sistemas e o desfoque da fronteira entre código e dados, seguido pelo problema da interpretabilidade.

As antigas ameaças, contra as quais foram usados analisadores de código estáticos e dinâmicos, não foram a lugar nenhum. Para esses ataques, as ferramentas existentes ainda são aplicáveis, mas por si só já são insuficientes.

Mas o uso de IA por invasores cria uma dificuldade adicional. No novo cenário, surge a possibilidade de prompt injections - manipulação do comportamento do modelo usando solicitações em linguagem natural. Esta é uma vulnerabilidade fácil de implementar e, ao mesmo tempo, fundamental: para o modelo, uma solicitação normal e um prompt malicioso são o mesmo conjunto de tokens. Um invasor pode, por exemplo, inserir uma instrução nos dados processados pelo agente (digamos, na descrição de um ticket ou nos logs), e o agente a executará como parte de seu contexto, sem distingui-la da tarefa legítima.

Problemas como glitch tokens - tokens anormais no dicionário do modelo que causam comportamento imprevisível quando aparecem no prompt - também estão relacionados às características da tokenização. Esses tokens geralmente surgem devido à representação insuficiente nos dados de treinamento: o modelo "não sabe o que fazer com eles", o que leva a alucinações, respostas sem sentido ou até mesmo à geração de conteúdo ofensivo. Um exemplo clássico: ao pedir para repetir a palavra "SolidGoldMagikarp", o modelo Text-Davinci-003 respondeu com a palavra "Distribute"; e ao pedir para repetir "Mediabestanden", o modelo Llama2-7b-chat produziu "hello world". Aqui estão mais alguns exemplos:

Um assistente de segurança da informação em tal situação deve ser considerado como um assistente iniciante: sim, ele é capaz de processar rapidamente terabytes de dados, conhece as vulnerabilidades do MITRE ATT&CK® de cor e pode trabalhar continuamente, sem se cansar. Mas ele não entende as especificidades de uma infraestrutura específica, não conhece os processos de negócios internos da empresa e não é capaz de distinguir de forma independente a atividade legítima de um ataque em cenários limítrofes. O agente é inicialmente confiante nos dados de entrada, percebe o contexto sem avaliação crítica e pode ser enganado.

A situação é adicionalmente complicada pela tendência geral dos modelos de linguagem a alucinações: dependendo da tarefa e do contexto, uma proporção significativa das respostas pode estar incorreta, e o próprio modelo não está ciente do erro.

Anatomia de um assistente de IA Vamos considerar a arquitetura de tal assistente de IA. O componente central - seu "cérebro", onde todo o "pensamento" ocorre - é um modelo de linguagem que é responsável por analisar os dados de entrada e formar conclusões. Para fornecer ao modelo conhecimento atual e específico do domínio, são usados mecanismos RAG, que permitem misturar dinamicamente informações de fontes internas.

A capacidade de fazer solicitações ao SIEM , executar scanners, verificar IoC e outras ações são fornecidas por meio de acesso a ferramentas e sistemas externos via API. E, como no caso de qualquer novato na equipe, é necessário um mentor - uma espécie de camada de controle para que uma pessoa possa intervir nos processos sob supervisão adequada.

É assim que pode parecer em um diagrama.

O que é mais importante aqui para nós? Que toda a interação do assistente com o mundo externo ocorre através de suas "mãos", através de ferramentas. E podemos e devemos controlá-las.

Quando o assistente funcionou corretamente Voltemos à história que contei no início. No nó DC01 , o EDR registra atividade suspeita do PowerShell. No caso ideal, o assistente de IA recebe um alerta e determina que o comando foi transmitido de forma codificada, após o que executa a decodificação Base64.

Após analisar o conteúdo do comando, o agente classifica corretamente a atividade em termos de MITRE ATT&CK® e forma uma hipótese de que o comportamento observado corresponde à etapa de reconhecimento de privilégios. Se houver sinais adicionais de confirmação, essa atividade pode indicar uma tentativa de movimentação lateral, na qual o invasor tenta passar de um nó comprometido para um recurso com mais privilégios dentro da infraestrutura.

Em seguida, o assistente verifica as políticas de segurança e os regulamentos operacionais da empresa e, de acordo com eles, solicita dados adicionais do sistema SIEM e logs de eventos em uma janela de tempo limitada - geralmente dentro de ±5 minutos do evento original. Os dados recebidos são correlacionados pelo agente com base em recursos como LogonId/User, host de origem, processos pai/filho, tipo de eventos, o que permite restaurar o contexto correto do que está acontecendo e entender a sequência de ações.

Como o nó DC01 pertence a recursos críticos Tier-0 (controladores de domínio, servidores PKI, servidores de autenticação), as políticas de segurança proíbem explicitamente o agente de executar quaisquer ações de resposta automáticas em tais recursos. Em vez disso, o agente é obrigado a iniciar a aprovação HITL

transferir a decisão para uma pessoa.

Portanto, o assistente gera um relatório estruturado que registra a atividade detectada, o contexto reconstruído, as hipóteses levantadas e as recomendações para as próximas etapas para o analista de SOC.

Algoritmo de ações [Cérebro]: recebo um alerta no DC01 sobre o lançamento suspeito do PowerShell com um comando Base64. Registro o tempo, nó, usuário e linha de comando. [Cérebro]: decodifico Base64. Vejo Get-ADGroupMember "Domain Admins". Salvo a decodificação e os parâmetros de execução como artefatos. [Cérebro]: classifico a atividade como MITRE ATT&CK® T1069.002 (Domain Groups Discovery). Formulo uma hipótese: esta é a etapa de reconhecimento de privilégios, se coincidir por sessão/contexto, pode indicar movimentação lateral. [Memória (RAG)]: verifico políticas e conhecimentos internos: login interativo sob SVC_Admin é proibido; DC01 pertence ao Tier-0; quaisquer ações no Tier-0 apenas via HITL; na ausência de evidências - política de abstenção (Abstain). [Mãos]: solicito eventos no SIEM para DC01 para a janela de ±5 minutos. Correlaciono por recursos: LogonId/User, host de origem, processos pai/filho, tipos de eventos. [Cérebro]: conecto a sequência: login bem-sucedido SVC_Admin com WS-FIN-05 → criação do processo powershell.exe → ScriptBlock com Get-ADGroupMember. [Cérebro]: avalio a suficiência das evidências (vários artefatos independentes confirmam a sequência). Incluo a política de abstenção (Abstain) para quaisquer ações no Tier-0. Preparo um relatório e o transmito para aprovação HITL antes de qualquer ação.

Em poucos segundos, o agente executa a quantidade de trabalho que levaria dezenas de minutos de intensa carga cognitiva para um analista. Ao mesmo tempo, a escalabilidade é alcançada executando agentes em paralelo, enquanto o número de analistas qualificados permanece limitado.

Na prática, o mesmo cenário pode levar a um resultado fundamentalmente diferente - se o sistema for projetado sem os guardrails descritos acima: sem uma política de abstenção (Abstain), sem diferenciação de autoridade por criticidade de ativos e sem o envolvimento obrigatório de uma pessoa para recursos Tier-0. Vamos considerar o que acontecerá nesse caso.

Quando algo deu errado O contexto inicial permanece o mesmo: o agente processa o mesmo alerta e solicita o mesmo conjunto de dados do sistema SIEM. No entanto, na etapa de correlação, ele usa uma lógica diferente. Em vez de restaurar a cadeia de processos por IDs de sessão e LogonId, ele executa a correlação por tempo e nó. Como resultado, eventos não relacionados que aconteceram na mesma janela de tempo são incluídos na análise.

Entre esses dados, o agente detecta uma solicitação DNS, que interpreta como suspeita. Ele se volta para o sistema de inteligência de ameaças e recebe confirmação de que o domínio correspondente é classificado como malicioso. Com base nessas informações, o agente conclui sobre uma possível exfiltração de dados e passa para ações de resposta ativa.

Sem envolver uma pessoa e sem levar em consideração a criticidade do recurso, o agente isola o host DC01 .

À primeira vista - perfeito: o incidente é processado automaticamente e sem atrasos. Mas DC01 é um controlador de domínio. Ele é responsável pela autenticação de todos os serviços da empresa. Seu isolamento leva instantaneamente à indisponibilidade do Kerberos/LDAP, à parada dos serviços e ao congelamento real dos processos de negócios de toda a organização. Isso é exatamente o oposto do que o assistente de IA foi implementado.

Vamos analisar os motivos.

Alucinações - uma nova superfície de ataque Ao adicionar um agente de IA à infraestrutura, uma nova superfície de ataque e uma nova classe de falhas aparecem. Os modelos de linguagem são propensos a alucinações

este é um termo estabelecido que descreve uma situação em que o modelo forma conclusões plausíveis, mas incorretas. Em nosso caso, o agente inventou uma relação de causa e efeito errônea e, com base nela, iniciou uma ação incorreta.

A característica do LLM é o alto grau de confiança no contexto de entrada. Qualquer informação que entre na janela de atenção do modelo é percebida como potencialmente significativa. Se dados irrelevantes forem acidentalmente incluídos no contexto, o modelo pode usá-los em raciocínios como base para tomada de decisão. Se o agente tiver amplos poderes, isso leva ao fato de que uma interpretação errônea é transformada diretamente em uma ação crítica, formando um cenário de falha do sistema.

De onde vêm as alucinações e que tipos existem? Alucinação e viés (Hallucination & Bias). O modelo inventa fatos para preencher lacunas no contexto. "Ela não sabe o que ela não sabe." Por exemplo, o agente inventou uma conexão entre PowerShell e nslookup. Veneno de "memória" (RAG Poisoning). O modelo confia em quaisquer dados de sua base de conhecimento, mesmo que sejam falsos ou desatualizados. Por exemplo, se houvesse um relatório falso sobre baddomain.com na base de conhecimento, o erro se tornaria "confirmado". Abuso de "mãos" (Tool Abuse). O agente tem direitos excessivos e pode realizar ações destrutivas sem controle. Por exemplo, se o agente tivesse a capacidade técnica de isolar imediatamente um ativo crítico.

As causas das alucinações são fundamentais e estão relacionadas à arquitetura e aos métodos de treinamento dos modelos de linguagem. No processo de treinamento, os modelos são recompensados pela proporção de respostas corretas, e não pela abstenção correta de uma resposta. Em condições de incerteza, é estatisticamente mais vantajoso para o modelo gerar uma suposição do que se abster de responder, pois mesmo um resultado parcialmente adivinhado aumenta a pontuação final em comparação com a opção sem resposta.

Ao treinar o modelo, a resposta "Não sei" reduz as métricas de qualidade, portanto, a estratégia ideal do modelo é adivinhar. Isso leva a respostas confiantes, mas errôneas, em vez de uma honesta admissão de incerteza Um fator adicional está relacionado à própria natureza dos modelos de linguagem. Os LLMs modernos não operam com o conceito de verdade. Sua tarefa é gerar sequências plausíveis de tokens, nas quais a probabilidade do próximo token é maximizada em cada etapa com base no contexto. O modelo não tem uma representação interna de se uma declaração gerada é verdadeira ou falsa, ele apenas avalia sua plausibilidade estatística.

Mesmo em situações em que o modelo realmente "entende" que a confiança na resposta é baixa, ele ainda dá uma resposta: a maioria dos modelos universais não tem um mecanismo embutido para se recusar a gerar. Ela não pode deixar de responder à pergunta. Como resultado, o sistema recebe de qualquer forma uma certa sequência gerada, em vez de registrar a incerteza e escalar a solicitação para uma pessoa. Esta é uma característica arquitetônica dos LLMs modernos, e não um defeito de uma implementação específica.

Ao mesmo tempo, é importante ressaltar que, em nosso caso, o problema fundamental não estava no próprio fato da alucinação. As alucinações do modelo são uma determinada. Não vamos lidar com isso em um futuro próximo. Você só precisa aprender a trabalhar com isso. A tarefa do engenheiro não é eliminar as alucinações, mas construir um sistema resistente a erros do modelo. Nesse caso, a falha foi causada pelo processamento incorreto da saída do modelo e pelos poderes excessivamente amplos do agente.

Observo que o incidente ocorreu sem qualquer influência externa no agente. Ele funcionou no modo normal. Em condições de um ataque direcionado a tal agente, as consequências poderiam ser muito mais sérias.

Em sistemas multi-agentes, isso pode levar a alucinações em cascata, quando o erro de um modelo se espalha para outros devido à interação entre agentes, formando uma cadeia de confirmação mútua de conclusões falsas. Por exemplo, se um agente analista classifica erroneamente a atividade como tráfego C2 e transmite essa conclusão ao agente respondente, ele pode aceitá-la como um fato confirmado e iniciar o isolamento, e o agente auditor, tendo recebido relatórios de ambos os agentes, registrará um "incidente confirmado" com duas fontes independentes. Como resultado, um falso consenso surge no sistema, e restaurar as causas do incidente se torna extremamente difícil - cada agente se refere às conclusões do outro.

É precisamente por essa razão que existem muitas taxonomias de ameaças à segurança para sistemas de IA e agentes.

Como fazer tudo certo, e errado - não fazer Como, então, manter a IA em seus processos, mantendo a capacidade de gerenciamento e a confiança no sistema?

A proteção em camadas nos ajudará, ou seja, o controle em diferentes estágios do ciclo de vida do sistema.

Verificação de dados de entrada que entram no modelo Nesta fase, identificamos prompt injections e tentativas de usar o modelo de forma inadequada. Além disso, os dados de entrada são limpos de informações pessoais, médicas e confidenciais que não devem entrar no contexto do modelo. O objetivo desta etapa é excluir a entrada de informações potencialmente perigosas ou irrelevantes no modelo.

O controle da frequência e da natureza das solicitações também pertence a este nível. As solicitações aos modelos de linguagem exigem recursos significativos de GPU e são significativamente mais caras do que as operações de servidor regulares, portanto, é necessário implementar a limitação de taxa em conjunto com o monitoramento do uso anormal. Isso permite proteger a infraestrutura tanto contra abuso quanto contra o desperdício de recursos.

Como já dissemos, o modelo, ao receber uma solicitação, sempre se esforça para formar uma resposta e, na ausência de contexto suficiente, começa a alucinar. Uma maneira óbvia de reduzir esse risco é fornecer ao modelo informações relevantes e atualizadas. Na prática, isso é implementado por meio de RAG (Retrieval-Augmented Generation) - uma abordagem na qual fragmentos de conhecimento adequados, encontrados em fontes internas, são misturados dinamicamente no contexto do modelo: políticas de segurança, regulamentos, informações sobre infraestrutura, dados de inteligência de ameaças.

Tudo funciona da seguinte forma. A solicitação que entra no sistema é usada não apenas como entrada para o modelo de linguagem, mas também como base para pesquisar fragmentos relevantes na base de conhecimento. Os fragmentos de texto encontrados são adicionados ao contexto junto com a pergunta original, o que permite que o modelo se baseie em dados atuais e específicos do domínio e aumenta a probabilidade de uma resposta correta.

Ao mesmo tempo, o trabalho confiável e seguro do RAG requer configurações de engenharia adicionais. As solicitações que entram no sistema são frequentemente formuladas em forma livre e podem não corresponder em estrutura e terminologia à forma como os dados são apresentados na base de conhecimento. Para aumentar a precisão da pesquisa, a reformulação da solicitação é usada, o que permite que ela seja trazida para uma forma mais adequada para extrair documentos relevantes.

A eficiência da pesquisa é significativamente aumentada com o uso de uma abordagem híbrida que combina pesquisa por palavras-chave, proximidade semântica de incorporações e filtragem por metadados. Em sistemas práticos, também há a necessidade de diferenciar o acesso de diferentes agentes à base de conhecimento. Isso é implementado por meio de controle de acesso baseado em função no nível de documentos ou blocos individuais, o que permite restringir o contexto dependendo da função do agente.

A classificação dos fragmentos encontrados é adicionalmente aplicada. Em vez de passar todo o conjunto de resultados para o modelo, sua relevância para uma solicitação específica é avaliada, e apenas os blocos que são realmente úteis e não poluem a janela de atenção do modelo entram no contexto. Uma tarefa separada é a validação da relevância dos documentos na base de conhecimento. Quando novas informações aparecem que contradizem os dados carregados anteriormente, tais conflitos devem ser resolvidos no estágio de formação e manutenção da base de conhecimento, para que o modelo não se baseie em fontes mutuamente exclusivas.

Um elemento crítico de toda a cadeia é a auditoria e o registro. Em cada etapa, é necessário registrar solicitações de entrada, chamadas de ferramentas executadas e respostas recebidas. Isso é necessário não apenas para fins de segurança e investigação de incidentes, mas também para melhorar o sistema posteriormente. Os logs permitem que você entenda em que estágio ocorre o erro: nos dados originais, na interpretação da solicitação, na lógica de extração de conhecimento ou nas instruções passadas para o agente.

Controle dos pensamentos do agente de IA O próximo nível arquitetônico é o reasoning firewall. Não estamos falando de um algoritmo ou produto específico, mas de um paradigma para construir sistemas de agentes, que combina várias direções inter-relacionadas.

Uma das áreas mais importantes de desenvolvimento do sistema é a organização da interação dos agentes entre si. Isso inclui a definição de funções de agentes, conjuntos de dados disponíveis para eles, distribuição de tarefas e formalização do comportamento esperado. Uma abordagem comum é uma arquitetura hierárquica, na qual o agente supervisor é responsável pela lógica de negócios e pelo controle da execução de tarefas, e os executores especializados resolvem subtarefas estreitas e não transferem contexto redundante para o supervisor. Essa estrutura reduz o nível de ruído e reduz a probabilidade de raciocínio descontrolado no nível superior.

No âmbito do reasoning firewall, também são considerados métodos para fixar o comportamento esperado do modelo. Isso é alcançado tanto por meio de treinamento adicional com base no feedback humano quanto por meio da incorporação de restrições comportamentais diretamente no modelo de linguagem.

A auto-organização no nível dos cenários de interação com o modelo é adicionalmente usada. Por exemplo, você pode usar uma abordagem neuro-simbólica, cuja ideia é primeiro processar dados não estruturados com um modelo e, em seguida, tomar decisões com base em dados estruturados. Depois disso, todas as decisões são tomadas de forma determinística, com base em regras e lógica formal. Essa abordagem remove a responsabilidade do modelo pela tomada de decisões críticas, reduz a variabilidade do comportamento e torna o processo de tomada de decisão transparente e reproduzível.

O mesmo nível inclui a organização das próprias solicitações ao modelo. A agregação de várias solicitações, a verificação mútua das respostas de um modelo por outro, bem como a avaliação do grau de confiança do modelo em suas próprias conclusões são possíveis. Com baixa confiança, o resultado recebe um nível de confiança menor ou uma escalada para uma pessoa é iniciada.

Fine-tuning e Alinhamento para o agente de IA Permitam-me lembrá-lo de como o bloco de Alinhamento (alinhamento) é geralmente organizado.

As três primeiras etapas são executadas no lado do provedor de LLM e podem não estar disponíveis para o usuário final. Portanto, vamos do fim. A ferramenta básica e mais acessível para ajustar o comportamento do modelo é o prompting, no qual a formulação das solicitações é selecionada de forma a corresponder ao máximo ao estilo esperado de raciocínio e respostas.

Uma das maneiras mais eficazes de melhorar a qualidade do trabalho do modelo é usar exemplos em prompts. As abordagens zero-shot e few-shot sugerem que não apenas uma instrução, mas também exemplos de casos típicos com as respostas esperadas são passados para o modelo. Isso permite definir explicitamente o formato e o estilo do resultado e reduz a incerteza na interpretação da tarefa por parte do modelo.

Prompting para tarefas de segurança da informação Prompt básico Analise este alerta de segurança e forneça recomendações Prompt estruturado Você é um analista sênior de SOC. Analise o alerta usando a seguinte estrutura: OBSERVAÇÃO: o que você vê nos dados brutos? HIPÓTESE: quais métodos de ataque isso pode representar? Use MITRE ATT&CK® CORRELAÇÃO: quais dados adicionais ajudarão a confirmar ou refutar a hipótese? RECOMENDAÇÃO: quais ações devem ser tomadas, considerando: Tier-0 requer aprovação HITL Incerteza > 20% requer escalonamento Sempre especifique uma pontuação de confiança Alerta: {alert_data} Contexto: {siem_data} Políticas: {corporate_policies} Para tarefas mais complexas, a decomposição é aplicada. A tarefa é dividida em várias etapas, cada uma das quais é resolvida separadamente. Essa abordagem reduz a carga cognitiva no modelo e aumenta a estabilidade do resultado. Se o problema não estiver no comportamento do modelo, mas na falta de conhecimento, o RAG é usado. Ao mesmo tempo, o RAG pode ser implementado em várias formas, incluindo RAG baseado em agente, solicitações sequenciais para uma base de conhecimento ou apelos paralelos a diferentes fontes, incluindo recursos externos.

Quando o ajuste de prompts e RAG não produz o efeito desejado, o treinamento adicional do modelo é aplicado. Na prática, geralmente não se trata de treinar do zero, mas de fine-tuning. Os métodos parameter-efficient, como LoRA e suas modificações, são mais frequentemente usados, nos quais apenas pequenas camadas adicionais com um número limitado de parâmetros são treinadas. Isso é suficiente para alterar o comportamento do modelo sem a necessidade de treinar toda a arquitetura multibilionária.

Abstention-training - quando ensinamos o modelo a dizer explicitamente "não" - é de importância separada. No âmbito dessa abordagem, o modelo é punido por respostas incorretas com mais força do que recompensado por respostas corretas, o que reduz a tendência de adivinhar em condições de incerteza. Melhorando o raciocínio Deve-se considerar