Leanstral 1.5 e o banco de testes para raciocínio verificável

Muitos lançamentos de modelos são julgados por um ritual familiar: examinar a tabela de benchmark, comparar a classificação, decidir se o lançamento é importante. Leanstral 1.5 merece um teste diferente.

Mistral apresenta o Leanstral 1.5 como um modelo construído para raciocínio e trabalho de prova orientado ao Lean, com referências de apoio no anúncio do Mistral, na visão geral do modelo e no cartão do modelo Hugging Face. Isso não significa que os operadores devam tratá-lo como pronto para produção para todas as tarefas sensíveis. Isso significa que a questão de avaliação muda. A pergunta útil não é apenas: “O modelo respondeu corretamente?” A questão mais incisiva é: "O modelo pode produzir um artefato que outro sistema possa rejeitar, verificar, reparar ou aprovar?"

As tabelas de classificação ainda são importantes. Eles emitem um sinal aproximado e um perfil de benchmark fraco deve retardar qualquer conversa de implantação. Mas as pontuações de benchmark são um proxy limitado para fluxos de trabalho onde a resposta depende de uma derivação, uma estrutura de prova, um teste repetível ou uma regra que deve sobreviver à auditoria. Para esses fluxos de trabalho, uma explicação persuasiva não é suficiente. Você quer uma resposta, um artefato verificável, um verificador independente e uma regra clara sobre o que acontece quando o verificador diz não.

As fontes usadas para este enquadramento incluem a postagem Leanstral 1.5 de Mistral em https://mistral.ai/news/leanstral-1-5/, Visão geral do modelo de Mistral em https://docs.mistral.ai/models/overview, o cartão de modelo Hugging Face em https://huggingface.co/mistralai/Leanstral-1.5-119B-A6B, Stanford HELM em https://crfm.stanford.edu/helm/latest/, Hugging Face Avaliar em https://huggingface.co/docs/evaluate/index, OpenAI Evals em https://github.com/openai/evals, Pesquisa de pensamento estendido visível da Anthropic em https://www.anthropic.com/research/visible-extended-thinking, e Lean 4 em https://github.com/leanprover/lean4.

Raciocínio do verificador no circuito em termos simples

O raciocínio verificador em loop é um fluxo de trabalho em que um modelo propõe uma resposta mais algo inspecionável: uma prova, derivação, caminho de código, rastreamento estruturado, objeto preenchido com esquema ou plano restrito. Um verificador separado avalia o artefato em relação às regras definidas. O verificador pode ser Lean 4, um conjunto de testes unitários, um verificador de tipo, um analisador estático, um solucionador simbólico, um mecanismo de política, um validador de dados ou uma ferramenta de revisão específica de domínio.

Os traços de raciocínio em linguagem natural são úteis, mas não são a mesma coisa que verdade. O trabalho da Antrópico sobre o pensamento ampliado visível é um bom lembrete de que expor o raciocínio requer cuidado. Um rastreamento pode ajudar na inspeção, depuração e avaliação, mas ainda pode ser incompleto, post-hoc ou enganoso. A regra operacional é simples: confie mais no resultado do verificador do que na explicação do modelo, e não confie em nenhum deles sem um conjunto de avaliação específico da tarefa.

Uma maneira prática de ver os modelos de raciocínio é julgá-los menos como escritores e mais como analistas juniores trabalhando em testes. Se o trabalho não puder ser verificado, o modelo está produzindo principalmente confiança. Se o trabalho puder ser verificado, o sistema poderá rejeitar resultados ruins, medir padrões de falha e decidir se as tentativas de reparo são úteis.

O banco de testes de raciocínio Optijara Verifier-in-the-Loop

Use uma bancada de testes pequena e repetível antes de adicionar o Leanstral 1.5, ou qualquer modelo orientado a provas, a uma pilha de IA privada ou local. A bancada de testes deve forçar três saídas em cada execução: a resposta final, o raciocínio ou artefato de prova e o resultado do verificador. Se um deles estiver faltando, você não estará testando o raciocínio do verificador no circuito. Você está testando a persuasão do modelo.sereia fluxograma TD A[Tarefa do usuário] -> B[Modelo propõe resposta] B --> C[artefato estruturado] C --> D[verificador independente]

F --> C

O estágio 1 é a geração de candidatos. Dê ao modelo uma tarefa restrita e peça uma resposta mais uma prova, derivação, mudança de código testável ou artefato de decisão estruturado. Não comece com instruções estratégicas amplas. Escolha um trabalho onde o fracasso seja visível.

O estágio 2 é a normalização. Converta o artefato no formato que o verificador realmente entende. Para o trabalho no estilo Lean, isso pode significar uma declaração formal e uma tentativa de prova. Para código, pode significar um patch, testes e execução reproduzível. Para lógica de negócios, pode significar um objeto JSON que pode ser validado em relação a um esquema e regras de política.

A fase 3 é a verificação independente. O modelo não deve se avaliar. Execute o verificador externo e registre o resultado bruto. Se o verificador tiver cobertura parcial, registre isso também. Uma aprovação em testes restritos não é prova de que a resposta esteja globalmente correta.

O estágio 4 é a medição do reparo. Um modelo que falha uma vez, mas é reparado com precisão após o feedback do verificador, ainda pode ser útil para fluxos de trabalho assistidos. Um modelo que continua a produzir provas inválidas e confiáveis ​​é um candidato de maior risco, mesmo que a prosa pareça polida.

O estágio 5 é o posicionamento. Decida se o fluxo de trabalho pode ser automatizado, assistido ou interrompido. A automação precisa de alta cobertura do verificador, baixa gravidade de falhas, latência estável e um caminho de reversão. O uso assistido pode tolerar mais falhas se a revisão humana for realista. Algumas tarefas devem permanecer fora do escopo.

Rastreie a taxa de aprovação, a taxa de artefatos inválidos, a taxa de sucesso de reparos, a latência, o custo, a reprodutibilidade, a carga de revisão humana, o ajuste de privacidade e a gravidade da falha. Essas métricas são mais importantes do que um único número de benchmark público.

Onde a verificação ajuda

A verificação é mais forte quando a saída pode ser verificada por um processo externo confiável. A matemática formal e semiformal é o exemplo mais claro. O Lean 4 pode validar um artefato de prova formal, mas não pode garantir que a pergunta original do mundo real foi traduzida na declaração formal correta. Essa etapa de tradução precisa de revisão humana.

O código costuma ser mais prático. Um modelo orientado a provas ou com muito raciocínio pode propor uma implementação e, em seguida, testes, verificações de tipo, análise estática, scanners de segurança e execução reproduzível podem retroceder. O resultado não é qualidade automática. É um ciclo de feedback melhor do que ler uma explicação confiável e esperar que o código funcione.

O planeamento científico e de engenharia também pode beneficiar, mas apenas quando o verificador for claro. Verificações de restrições, validação de equações, validação de citações, revisão assistida por simulação e verificações de consistência unitária podem detectar certos erros. Eles não estabelecem um julgamento científico aberto.

Os fluxos de trabalho empresariais podem usar o mesmo padrão quando as regras são explícitas. Exemplos hipotéticos: aprovações de faturas verificadas em relação às regras de ordem de compra, decisões de elegibilidade verificadas em relação à lógica da política, importações de dados verificadas em relação a esquemas ou extração de cláusulas contratuais verificada em relação a uma taxonomia controlada. Estas não são reivindicações de clientes. São exemplos do tipo de fluxo de trabalho em que o feedback do verificador tem algo concreto para inspecionar.

Onde a verificação enganaO verificador pode verificar a coisa errada. Esse é o modo de falha mais comum. Uma prova formalmente válida pode ser irrelevante se a questão comercial tiver sido formalizada incorretamente. Um conjunto de testes pode ser aprovado e perder o caminho que interrompe a produção. Um verificador de política pode aprovar uma saída porque a própria política está obsoleta.

Trabalhos de avaliação pública, como Stanford HELM, Hugging Face Evaluate e OpenAI Evals, apontam para a mesma lição: a avaliação deve ser específica da tarefa e multidimensional. A precisão não é suficiente. Você precisa inspecionar confiabilidade, calibração, latência, custo, comportamento de recusa, tendência, segurança e capacidade de manutenção no contexto onde o modelo será executado.

Fique atento a Goodharting contra testes, formalização frágil, problemas ocultos de qualidade de dados, contexto obsoleto, tentativas de ignorar o verificador e excesso de confiança ao passar em verificações restritas. Os traços de raciocínio adicionam observabilidade parcial. Eles não expõem um registro causal completo do motivo pelo qual o modelo produziu uma resposta.

Não utilize modelos orientados para provas como o principal sistema de decisão para julgamento subjetivo, negociação de alto contexto, aconselhamento médico não verificado, aconselhamento jurídico, aconselhamento financeiro, decisões estratégicas ambíguas ou qualquer tarefa onde não exista um verificador confiável e os erros não possam ser revisados ​​com segurança. Nesses casos, o circuito verificador pode criar uma falsa sensação de controle.

Matriz de decisão para colocação de pilha privada

Existem três opções de posicionamento sensatas. Primeiro, execute localmente um modelo aberto orientado a provas para tarefas confidenciais restritas com verificações claras de aprovação ou reprovação. Em segundo lugar, use-o como um especialista em raciocínio ao lado de um modelo geral, onde ele elabora artefatos que verificadores e humanos inspecionam. Terceiro, manter o modelo geral e melhorar os verificadores externos sem adicionar ainda um novo modelo.

A implantação privada ou local pode ser atraente para cargas de trabalho confidenciais, mas não elimina os controles de segurança, a revisão de acesso, o monitoramento, os testes de equipe vermelha ou a avaliação. Os modelos locais ainda podem vazar através de logs, permissões fracas, injeção imediata, manuseio inadequado de dados ou maus hábitos operacionais.

json { "model_category": "modelo_de_reasonamento_orientado_prova", "candidato_modelo": "Leanstral 1.5", "best_initial_use_cases": ["assistência à prova formal", "código com testes", "regras de negócios verificadas pelo esquema"], "verifier_types": ["Lean 4", "unit_tests", "type_checks", "static_análise", "policy_rules", "data_validators"], "nível_de risco": "medium_until_task_specific_evaluation_passes", "go_no_go_criteria": ["a cobertura do verificador é conhecida", "o comportamento de reparo é medido", "o limite de revisão humana está definido", "existe caminho de fallback"] }## Lista de verificação de implementação e plano de medição

Comece pequeno. Defina um limite de tarefa, um verificador e um conjunto de avaliação antes de discutir a implantação ampla. Prepare avisos representativos, resultados esperados e exemplos de falhas. Registre a resposta, o artefato, o resultado do verificador, as tentativas de reparo, a latência e as notas de revisão humana.

Execute um LLM geral de linha de base, um modelo local menor, se relevante, e um fluxo de trabalho somente de verificador, sempre que possível. Em seguida, teste o Leanstral 1.5 no mesmo conjunto. Compare a qualidade da primeira passagem e a qualidade da saída reparada. Um modelo que precisa de três circuitos de reparo para casos fáceis pode ser muito caro para operar, mesmo que acabe sendo aprovado.

Inclua avisos adversários e de casos extremos: entradas malformadas, instruções ambíguas, contexto ausente, tentativas de ignorar o verificador e casos em que a resposta correta é recusar ou escalar. Registre a gravidade da falha, não apenas a contagem de falhas. Uma prova gravemente inválida pode ser mais importante do que vários erros de formatação inofensivos.

O monitoramento da produção deve rastrear a taxa de falhas do verificador, desvios na combinação de tarefas, loops de reparo repetidos, taxas de tempo limite, motivos de substituição humana, obsolescência do cache e resultados de revisão de incidentes. Defina regras de reversão antes do lançamento. Se o verificador falhar repetidamente, o sistema não deverá voltar a confiar silenciosamente no modelo.

Para as equipes que avaliam esta categoria, o papel da Optijara é ajudar a projetar plataformas de avaliação práticas, circuitos de verificação e planos de implantação privados em torno de restrições reais. Isso significa escolher a tarefa, definir o verificador, comparar linhas de base, medir o comportamento do reparo e decidir onde a revisão humana permanece no circuito.

Erros comuns

O primeiro erro é tratar os traços de raciocínio como verdade fundamental. Corrija-o exigindo artefatos verificáveis ​​e validação externa.

A segunda é testar apenas tarefas de classificação. Corrija-o construindo um conjunto interno a partir do trabalho que o sistema realmente verá.

A terceira é pular a revisão de formalização. Corrija o problema pedindo a um proprietário de domínio que inspecione se a declaração formal, esquema, teste ou regra corresponde ao problema original.

A quarta é permitir que novas tentativas escondam raciocínios fracos. Corrija-o medindo a contagem de reparos, padrões de falhas repetidas e carga total de revisão.

A quinta é a implantação antes que os caminhos alternativos sejam definidos. Corrija o problema decidindo antecipadamente quando o sistema tentará novamente, escalará, mudará de modelo ou parará.