DeepSeek R1 vs. DeepSeek V3.2: como decidir entre raciocínio explícito e eficiência em um fluxo revisável

A decisão não é qual modelo parece melhor, mas qual risco o fluxo reduz

A comparação entre DeepSeek R1 e DeepSeek V3.2 deve partir de uma decisão operacional concreta. Por exemplo: analisar um dossiê técnico, identificar requisitos aplicáveis em documentos fornecidos pelo usuário, emitir uma recomendação estruturada e preparar uma ação posterior. Essa ação pode ser criar um rascunho, abrir um caso ou propor uma rota de aprovação, mas não deve ser executada sem as validações humanas e de sistema exigidas pelo processo.

Nesse tipo de fluxo, uma resposta extensa ou um raciocínio visível não constituem, por si só, uma vantagem. O que importa é se reduzem um erro material: uma recomendação incompatível com as evidências, uma citação documental incorreta, uma ferramenta chamada com parâmetros errados, a ausência de abstenção diante de dados insuficientes ou uma saída que o sistema receptor não consegue processar.

A pergunta de compra ou implantação pode ser formulada de forma falseável: o R1 reduz suficientemente os erros materiais e a carga de revisão humana em casos ambíguos e de várias etapas para compensar seu tempo de resposta, seus tokens e sua complexidade? Se o V3.2 alcançar o mesmo patamar de correção, evidência, abstenção e estrutura com menos recursos, um raciocínio mais longo não justifica, por si só, encaminhar a tarefa para ele.

Este texto não pressupõe que um dos dois modelos seja um substituto universal do outro. Propõe um teste para responsáveis por produto, plataforma e engenharia que precisam escolher uma rota por caso e preservar uma aprovação humana para decisões com consequências operacionais.

Identifique exatamente o que está sendo comparado antes de medir resultados

“DeepSeek V3.2” não basta como identificador experimental. A documentação de lançamento apresenta o DeepSeek-V3.2 como sucessor do V3.2-Exp, enquanto o registro de alterações indica uma atualização dos aliases deepseek-chat e deepseek-reasoner para DeepSeek-V3.2 em 1º de dezembro de 2025. Portanto, um relatório reproduzível deve registrar o identificador solicitado, o alias efetivamente usado, a data e hora da execução, o canal de acesso e a versão ou revisão do artefato local, caso um checkpoint seja executado.

A ficha publicada do DeepSeek-V3.2 permite fixar um artefato para uma avaliação local, mas um teste local e um teste por API não são automaticamente intercambiáveis. Podem diferir em hardware, runtime, quantização, servidor de inferência, limites de contexto, filas, controles de segurança, política de novas tentativas e tarifa. O modelo de chat ou o processamento de ferramentas também pode mudar. A comparação deve declarar essas diferenças, e não atribuí-las ao modelo.

O DeepSeek R1 também exige que o procedimento utilizado seja documentado. O repositório oficial descreve um contexto de 128K e, para sua avaliação publicada, indica uma geração máxima de 32.768 tokens, temperatura de 0,6 e top_p de 0,95 na amostragem. Esses valores não garantem que sejam ideais para todas as tarefas, mas constituem uma referência importante. Se o ensaio se afastar deles, deve justificá-lo e avaliar se a mudança favorece ou prejudica o R1.

Não convém impor uma configuração idêntica quando as interfaces documentadas tiverem restrições distintas. A igualdade relevante é a de oportunidade para resolver a tarefa: mesmo corpus, mesmas ferramentas disponíveis, mesmas regras de sucesso, mesmo limite de tempo de negócio e uma política de novas tentativas definida antes de observar os resultados. As configurações específicas de cada modelo devem ser registradas como parte do experimento.

Formule uma hipótese que possa perder

A hipótese não deve ser que o R1 “raciocina melhor” nem que o V3.2 “é mais eficiente”. Ambas as expressões são imprecisas demais para uma decisão de plataforma. Uma hipótese útil poderia ser esta: em dossiês com evidências contraditórias, dependências entre documentos e necessidade de consultar ferramentas simuladas, o R1 obtém uma taxa maior de decisões corretas e de abstenções corretas, reduzindo o número de revisões humanas de forma operacionalmente relevante.

A hipótese contrária também deve ser definida: em solicitações diretas, com evidência suficiente e uma única etapa de decisão, o V3.2 atinge o patamar de qualidade acordado com menor latência, menos tokens de saída ou menor custo por resultado aceito. Nesse caso, o V3.2 seria a rota preferencial para esse estrato, ainda que o R1 alcance uma pontuação média ligeiramente superior.

Convém estabelecer antecipadamente qual resultado invalida cada proposta. Por exemplo, o R1 não justifica uma rota especializada se sua melhoria em erros materiais não superar a margem estabelecida, se a melhoria desaparecer ao repetir os casos ou se resultar de um formato de prompt, de uma recuperação documental ou de uma infraestrutura diferentes. O V3.2 não deve ser a rota padrão se mantiver uma taxa inaceitável de recomendações sem sustentação ou se não se abstiver adequadamente.

Os limiares devem ser próprios do processo. Um fluxo que prepara respostas internas de baixo impacto pode tolerar uma revisão por amostragem. Um fluxo que afeta compromissos contratuais, operações ou pessoas pode exigir evidência obrigatória, bloqueio por regras e aprovação humana em todos os casos. A avaliação mede o desempenho em condições determinadas; ela não transforma o modelo em uma autoridade autônoma.

Projete o experimento para medir uma tarefa, não a capacidade de impressionar

Construa um corpus congelado antes de executar o primeiro modelo. Cada caso deve conter os documentos e metadados que ambos os sistemas receberão, uma chave de avaliação elaborada de modo independente e uma etiqueta de estrato. O corpus pode incluir tarefas diretas, dossiês extensos, ambiguidades deliberadas, contradições, informações incompletas e casos em que a resposta correta seja abster-se ou escalar para uma pessoa.

A chave de avaliação deve separar fatos verificáveis de critérios de especialistas. Os fatos podem incluir uma decisão correta, campos obrigatórios, referências a evidências permitidas, parâmetros esperados de ferramentas e condições de abstenção. Os critérios de especialistas podem pontuar clareza, priorização ou qualidade da explicação. Estes últimos devem ser revisados sem conhecimento do modelo, com instruções e resolução de discordâncias documentadas.

Forneça aos dois modelos exatamente o mesmo conteúdo de negócio e o mesmo esquema de saída. Se ferramentas forem habilitadas, simule respostas determinísticas para que uma diferença não decorra de sistemas externos variáveis. O guia de chamadas de ferramentas documenta suporte a ferramentas em modo thinking a partir do V3.2 e um modo estrito voltado à conformidade com JSON Schema. Se essa opção for usada, aplique-a de forma coerente onde houver compatibilidade e meça separadamente a validade sintática do JSON e a validade semântica dos valores.

Registre temperatura, top_p, limite de saída, semente quando disponível, número máximo de chamadas, limite de tempo e política de novas tentativas. Para o R1, a documentação publicada recomenda uma configuração específica para sua avaliação e aconselha múltiplas execuções em determinados cenários. Portanto, uma única resposta por caso não basta se a intenção for estimar estabilidade: repita cada caso um número predefinido de vezes e comunique a distribuição dos resultados, e não apenas a melhor tentativa.

Não misture mudanças de prompt com mudanças de modelo. Se o formato falhar, mantenha uma rodada diagnóstica separada da comparação principal. Se o prompt ou o parser for alterado após a observação de uma falha, execute novamente ambos os modelos com a nova configuração. Caso contrário, o experimento deixa de distinguir o efeito do modelo do efeito da iteração da equipe.

Meça separadamente correção, evidência, abstenção e custo

A exatidão final é necessária, mas não suficiente. Uma recomendação pode coincidir por acaso com a chave e, ainda assim, citar uma evidência errada ou preparar uma ação com parâmetros inseguros. Meça a correção da decisão, a cobertura dos elementos obrigatórios e a fidelidade da evidência: cada afirmação relevante deve poder ser vinculada a um trecho permitido do corpus do caso.

A abstenção requer uma métrica própria. Diferencie a abstenção correta — o modelo identifica que não pode decidir com os dados disponíveis — da abstenção excessiva — ele encaminha casos solucionáveis — e da falsa segurança — decide quando deveria escalar. Esta última costuma ser mais relevante do que uma queda moderada de produtividade em processos com impacto. A rubrica deve indicar quais dados ausentes, conflitos ou limites de autoridade exigem escalonamento.

Para ferramentas, meça ao menos quatro aspectos: seleção da ferramenta adequada, parâmetros válidos, interpretação correta da resposta e decisão posterior coerente com essa resposta. Uma chamada com JSON válido não é necessariamente útil; da mesma forma, uma resposta com formato imperfeito pode conter uma decisão correta que o sistema não consegue aceitar. Mantenha as métricas de estrutura e de conteúdo separadas.

A medição operacional deve incluir latência de ponta a ponta por percentis, tokens de saída, número de chamadas de ferramentas, novas tentativas e custo por caso aceito. O denominador importa: dividir o custo por todas as respostas pode ocultar o custo das que, após validação, são realmente utilizáveis. Informe também o volume de revisão humana exigido e o tempo de correção por tipo de falha.

Diagnostique a causa de uma diferença antes de atribuí-la ao raciocínio

Apresente resultados por estrato, além de uma média total. Uma média pode ocultar que o R1 só agrega valor em uma minoria de dossiês ambíguos ou que o V3.2 resolve adequadamente a maior parte das solicitações simples. Cruze os resultados com extensão de contexto, número de documentos, necessidade de ferramenta, contradição entre fontes e condição de abstenção.

Quando houver uma diferença, classifique o primeiro ponto de falha. Ela pode estar na recuperação de evidência, na compreensão de uma instrução, no planejamento de uma chamada, na geração de argumentos, no parser, no tempo esgotado, na nova tentativa ou na infraestrutura. Revise os rastros sem revelar ao avaliador qual modelo os produziu, quando isso for viável. O guia do modo thinking trata o conteúdo de raciocínio como um elemento com tratamento específico e estabelece requisitos para determinados fluxos com ferramentas; o harness deve respeitar esse contrato, em vez de misturar conteúdos de raciocínio com o histórico de forma improvisada.

Não use o raciocínio exposto como prova de verdade. Ele pode ajudar no diagnóstico se o canal e a política de dados permitirem registrá-lo, mas a validação deve se apoiar na saída final, na evidência fornecida e nos eventos das ferramentas. Além disso, reter rastros pode ter implicações de privacidade, segurança e governança que devem ser avaliadas separadamente.

Se a diferença desaparecer ao igualar quantização, servidor, extensão máxima ou novas tentativas, o resultado não demonstra uma superioridade geral do modelo. De modo semelhante, se um modelo obtiver vantagem por receber um prompt especializado, a conclusão válida é que a combinação modelo-configuração funciona melhor sob esse harness, não que o modelo isolado seja superior em qualquer ambiente.

Transforme os resultados em uma regra de roteamento e mantenha controles humanos

A saída do experimento deve ser uma regra operacional, não uma declaração genérica de vencedor. Uma política possível é encaminhar ao V3.2 os casos diretos que superem o limiar de correção, evidência e estrutura dentro de um orçamento definido; encaminhar ao R1 os dossiês com ambiguidade, múltiplas dependências ou planejamento de ferramentas quando ele tiver demonstrado uma redução material de erros; e escalar para uma pessoa os conflitos de evidência, as ausências de dados críticas e os casos fora da autoridade delegada.

Antes da implantação, teste a regra em modo sombra. O sistema pode produzir uma recomendação e uma ação preparada sem que ela tenha efeito, enquanto um revisor compara os resultados com o processo existente. Estabeleça alertas para aumento de abstenções omitidas, queda de evidência válida, degradação de latência e mudanças de comportamento após uma atualização de alias ou infraestrutura.

A aprovação final não deve ser delegada apenas porque o modelo superou um ensaio. A avaliação não prova conhecimento atualizado fora do corpus, segurança de ferramentas reais, conformidade regulatória, resistência a entradas adversariais nem generalização para outro domínio. Tampouco elimina a necessidade de privilégios mínimos, validação determinística de parâmetros, registros auditáveis e mecanismos de reversão.

O DeepSeek V3.2 oferece disponibilidade documentada em App, Web e API, e a documentação da API descreve capacidades de thinking e ferramentas. Esses fatos facilitam a definição de um ensaio, mas não provam que um canal, por si só, satisfaça requisitos de residência de dados, retenção, capacidade, preço ou disponibilidade. Essas condições devem ser confirmadas para a conta, a região e a data de contratação específicas antes de uma decisão de compra.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.