DeepSeek R1 em produção: como testar o template de prompt sem quebrar a aplicação

As recomendações são um ponto de partida, não uma garantia

Um template de prompt pode melhorar a resposta do modelo e, ao mesmo tempo, prejudicar a integração. Por exemplo, uma instrução que estimula uma explicação mais detalhada pode ser útil em uma tarefa de análise, mas descumprir o contrato de uma API que espera uma resposta breve em JSON. Por isso, ao implantar o DeepSeek R1, a questão prática não é apenas saber qual configuração o fornecedor recomenda, mas se ela melhora as tarefas reais sem introduzir regressões que afetem o produto.

O repositório oficial do DeepSeek R1 apresenta recomendações de uso relacionadas à posição das instruções, à mensagem de sistema e ao início da resposta do assistente. Também aconselha realizar várias execuções durante a avaliação. Essas orientações oferecem uma base para projetar experimentos, mas não provam, por si só, que determinada prática seja superior em qualquer aplicação. Cabe à equipe que define as tarefas, os critérios de aceitação e as consequências de cada erro validá-la.

Este artigo propõe uma ablação controlada: mudar um fator por vez, manter os demais constantes e registrar não apenas se a resposta parece correta, mas também se respeita o contrato de saída. O objetivo é avaliar o DeepSeek R1 em uma aplicação específica. Não se trata de uma comparação com outros modelos nem de um estudo sobre se o R1 raciocina melhor que o DeepSeek V3.2. Também não se pressupõe que o texto gerado entre etiquetas de raciocínio descreva fielmente um processo interno.

Primeiro, fixe a versão e a configuração que você está testando

Antes de comparar prompts, registre qual modelo e qual caminho de inferência são usados em cada execução. A página oficial do modelo no Hugging Face, o arquivo de configuração de geração e o template de chat do repositório servem como referências para documentar esses elementos. Em particular, o arquivo do template ajuda a determinar como as mensagens são serializadas. Duas condições que parecem diferentes em uma interface podem acabar convertidas em sequências de tokens diferentes; da mesma forma, duas avaliações podem deixar de ser comparáveis se o template mudar entre elas.

Anote o identificador ou a revisão exata dos pesos, o runtime e sua versão, o template de chat, os parâmetros de geração e qualquer mecanismo adicional da aplicação: ferramentas, validadores, novas tentativas ou transformações posteriores. Não altere o template, a temperatura e o runtime ao mesmo tempo. Se várias variáveis mudarem simultaneamente, não será possível atribuir com clareza uma melhora ou uma piora ao fator que se pretendia avaliar.

Se você usar um serviço compatível em vez dos pesos em um runtime próprio, documente quais parâmetros ele aceita e quais ficam fora do controle da equipe. Uma interface compatível não garante, por si só, que a serialização ou todos os detalhes de inferência sejam idênticos. Se algum dado não puder ser verificado, registre essa incerteza no relatório em vez de apresentá-lo como uma condição conhecida.

Transforme as recomendações em fatores comparáveis

Projete as condições de modo que cada comparação responda a uma pergunta definida. Para estudar a posição das instruções, mantenha o conteúdo equivalente e compare, por exemplo, uma condição que as coloca na mensagem de sistema com outra que as inclui na mensagem do usuário. Se também quiser comparar posições diferentes dentro da mensagem do usuário, crie uma condição à parte e mantenha o texto da instrução. Assim, você evita atribuir à posição um efeito que talvez tenha sido causado por uma mudança na redação.

O prefixo «<think>» deve ser avaliado como um fator separado. Compare uma condição em que o início da resposta do assistente não é forçado com outra em que se acrescenta o prefixo indicado pela documentação. Verifique como ele é serializado no prompt efetivamente utilizado. Não combine essa comparação com uma mudança na mensagem de sistema: se uma condição alterar as duas coisas, a diferença observada não revelará qual delas a causou.

A recomendação de usar um prefixo não demonstra que ele melhore todas as tarefas nem que seja necessário em todos os runtimes. Também não permite concluir que o texto de raciocínio visível seja uma medida direta do funcionamento interno do modelo. Avalie aquilo que a aplicação recebe e pode verificar: resposta final, estrutura, latência, erros e consistência.

Inclua tarefas que representem contratos diferentes

Um conjunto de testes composto apenas por problemas matemáticos não representa necessariamente uma aplicação que também extrai dados, responde a perguntas breves e processa documentos. Monte um conjunto pequeno, mas variado, com tarefas próprias do produto. A variedade não é apenas decorativa: ela permite identificar se uma configuração ajuda em um tipo de tarefa e prejudica outro.

Para uma resposta factual breve, defina antecipadamente quais informações devem aparecer e que conteúdo adicional constituiria uma falha. Na extração estruturada, especifique o esquema, os campos obrigatórios e como tratar dados ausentes. Em uma tarefa matemática verificável, mantenha a resposta correta e o procedimento de conferência. Em uma tarefa baseada em documentos, forneça as mesmas evidências a todas as condições e avalie se a resposta se apoia nelas, se distingue aquilo que não está documentado e se evita acrescentar informações externas.

Inclua também casos em que o comportamento correto seja se abster ou indicar que as evidências disponíveis são insuficientes. Sem esses casos, uma avaliação pode premiar respostas confiantes, mas sem fundamento. Preserve exemplos de erros conhecidos e casos-limite, mas separe os dados usados para ajustar um template daqueles reservados para a avaliação final. Se as instruções forem revisadas durante o experimento, registre a mudança e execute novamente as condições comparáveis.

Meça a qualidade e a compatibilidade separadamente

A pontuação principal deve refletir se a resposta resolve corretamente a tarefa de acordo com critérios definidos antes de analisar os resultados. Não reduza tudo a uma impressão geral. Registre também o cumprimento das instruções, a validade do formato, os campos ausentes ou inesperados, as abstenções apropriadas e as indevidas. Em aplicações com parsers, inclua como métrica operacional a possibilidade de processar a resposta sem reparos manuais.

Meça a latência com um método consistente e defina qual intervalo está sendo medido: geração, chamada completa ou tempo percebido pelo usuário. Registre também erros de execução e novas tentativas. Respostas repetitivas ou vazias merecem uma categoria própria, com regras claras de identificação; não as esconda em uma média de qualidade. Uma resposta pode conter uma parte correta e ainda assim ser inutilizável se repetir texto, não fechar uma estrutura ou violar o formato exigido.

Faça várias execuções por condição quando o sistema apresentar variação. Preserve os resultados individuais além de qualquer média ou resumo. Mesmo para entradas determinísticas e condições de geração que permitam esse comportamento, repetir a avaliação pode ajudar a verificar a estabilidade do ambiente; quando houver aleatoriedade, informe o número de execuções e a dispersão observada. Não apresente uma diferença pequena como um efeito sólido sem mostrar quantos casos a sustentam.

Interprete resultados mistos sem esconder regressões

Imagine que uma condição melhora a pontuação nos problemas matemáticos, mas aumenta as falhas de formato na extração. Não é correto descrevê-la simplesmente como «melhor». A decisão depende de qual tarefa é crítica, de quanto custa a falha e de a aplicação dispor ou não de mecanismos confiáveis para detectá-la e se recuperar. Uma melhora na média pode esconder uma regressão grave em uma função específica.

Primeiro, compare cada tarefa separadamente; depois, apresente um resumo geral e explique o método de agregação. Se forem usados pesos, declare quem os escolheu e que importância eles representam. Em conjuntos pequenos, inclua contagens absolutas junto com porcentagens: passar de zero para uma falha e passar de dez para onze não descreve a mesma situação, mesmo que alguma taxa agregada pareça semelhante. Não altere os pesos depois de descobrir qual condição foi favorecida.

A documentação da DeepSeek recomenda várias execuções durante a avaliação. Na prática, isso significa preservar a variação entre as execuções, em vez de selecionar apenas uma resposta favorável. Também significa não generalizar além do conjunto testado: resultados obtidos em um grupo de tarefas de um produto constituem evidências para aquela aplicação e aquelas condições, não uma garantia universal sobre o R1.

Evite confundir o texto de raciocínio com uma explicação confiável

A etiqueta «<think>» faz parte da interface textual de certos formatos de conversa do R1, mas observar texto sob essa etiqueta não demonstra que se esteja vendo uma transcrição completa ou literal de um processo interno. A avaliação deve se concentrar em resultados observáveis e verificáveis. Em uma resposta matemática, confira a resposta; em uma extração, compare os campos com o documento; em uma abstenção, confirme se as evidências disponíveis eram insuficientes.

O trabalho publicado com o título DeepSeek-R1 Thoughtology analisa características do comportamento de raciocínio do R1 e aborda questões como extensão, controlabilidade e ruminação. Esse contexto ajuda a justificar a observação de respostas repetitivas e da extensão, mas não substitui as medições da aplicação nem demonstra antecipadamente o que acontecerá quando o template mudar. Uma explicação longa não prova, por si só, que a resposta é melhor; uma explicação breve tampouco prova que a tarefa foi resolvida sem raciocínio.

Se o produto não deve exibir ou armazenar esse conteúdo, verifique separadamente o que o runtime expõe, o que a aplicação salva e o que o usuário recebe. Não suponha que ocultar uma string na interface equivale a removê-la dos registros ou rastreamentos. Essas propriedades dependem da integração e exigem verificações próprias.

Documente a decisão como um relatório de regressão

Um relatório útil permite repetir o experimento e entender por que uma condição foi escolhida. Inclua as revisões exatas do modelo e do template, a configuração de geração, os prompts completos, o conjunto de tarefas e as regras de pontuação. Resuma os resultados por tipo de tarefa, não apenas com um número agregado. Guarde exemplos representativos de acertos e erros, tratando dados sensíveis de acordo com as políticas da equipe.

Descreva o que mudou entre as condições e o que permaneceu constante. Registre também as limitações: por exemplo, se o serviço não informa a revisão dos pesos ou se determinados parâmetros não podem ser controlados. Se o resultado não for conclusivo, essa é uma conclusão válida; é possível ampliar o conjunto, repetir o teste ou manter a configuração atual enquanto a questão é investigada. Não transforme a falta de evidências de regressão em evidência de que não há regressão.

A recomendação operacional final deve ser específica: qual template foi aprovado, para quais tarefas, com qual versão e sob quais limites. Se uma variante funcionar bem apenas em um fluxo, restrinja seu uso a esse fluxo em vez de apresentá-la como um template universal para o DeepSeek R1.

Critério prático: mantenha o que passar no teste da aplicação

O prompting mais útil para uma aplicação com DeepSeek R1 é aquele que melhora suas tarefas sem enfraquecer os contratos de saída nem os mecanismos de segurança e recuperação. Para descobrir qual é, estabeleça uma referência, isole as mudanças, inclua tarefas variadas, repita os testes quando necessário e apresente os resultados discriminados. Um prefixo, a posição de uma instrução ou a ausência de uma mensagem de sistema não devem ser aceitos por hábito nem descartados por intuição: é preciso verificar seus efeitos em condições documentadas.

Quando os resultados forem consistentes e atenderem aos limites definidos, implante a configuração e acompanhe as métricas que embasaram a decisão. Se o ambiente, os pesos, o template ou as tarefas mudarem, reavalie as condições relevantes. Assim, as recomendações oficiais continuam úteis como hipóteses iniciais, enquanto as evidências da aplicação determinam a configuração final.

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.