Benchmark - Harumi vs um modelo puro
Como o Harumi AI Chat se compara ao mesmo modelo chamado diretamente em problemas de pesquisa operacional e como cada número é medido.
O que é comparado
Cada problema é dado a dois concorrentes que usam o mesmo modelo:
- Harumi é o Harumi AI Chat como o cliente o recebe. Ele roda dentro de um projeto real, pode escrever e executar código no sandbox do projeto, ler e escrever os arquivos do projeto e corrigir os próprios erros antes de responder. A base de conhecimento está ligada, com o problema em teste removido do que ele pode recuperar, então ele não consegue procurar a resposta.
- Modelo puro é uma única chamada ao mesmo modelo com o mesmo texto do problema. Não tem ferramentas, sandbox nem segunda tentativa: escreve o código uma vez e essa é a resposta.
Os dois recebem o mesmo pedido, uma função Python com Gurobi que devolve o valor ótimo da função objetivo, e os dois são avaliados da mesma forma. A única diferença entre eles é a plataforma em volta do modelo.
Resultados
Os números abaixo vêm da execução publicada mais recente. O resultado principal conta os níveis 1 a 4; o nível de sanidade aparece na tabela por nível, mas fica fora do resultado principal, porque esses problemas de enunciado são antigos, pequenos e muito provavelmente já vistos por todos os modelos no treinamento.
Resultado principal
Nenhuma execução do benchmark foi publicada ainda. Esta página é preenchida a partir da primeira execução completa; até lá, não mostra números.
"Só o Harumi" e "Só o modelo puro" contam problemas, os mesmos para ambos, em que exatamente um dos dois acertou. O valor-p é um teste do sinal exato bilateral sobre esses problemas: com que probabilidade uma diferença tão grande apareceria se nenhum dos concorrentes fosse melhor.
Por nível
Nenhuma execução do benchmark foi publicada ainda. Esta página é preenchida a partir da primeira execução completa; até lá, não mostra números.
Um nível marcado com asterisco é mostrado, mas não entra no resultado principal.
Cada problema
Nenhuma execução do benchmark foi publicada ainda. Esta página é preenchida a partir da primeira execução completa; até lá, não mostra números.
Os problemas são listados apenas pelo caminho. O texto dos problemas reservados e dos licenciados não é publicado.
Como uma solução é avaliada
Uma solução é avaliada executando o código, não lendo-o:
- O código roda em um sandbox do Harumi com Gurobi, o mesmo ambiente para os dois concorrentes, sobre a entrada do problema.
- O valor objetivo que ele devolve precisa bater com a resposta conhecida dentro de uma tolerância relativa de 0,01% (ou absoluta de 0,000001).
- Se o código executou um solver, ele precisa ter terminado em uma solução ótima.
- Para problemas feitos para não ter solução (inviáveis ou ilimitados), o status final do solver precisa ser esse. Uma solução que relaxa o problema em silêncio para obter um número está errada.
- Em conversas com pedidos de acompanhamento, todas as etapas precisam estar certas.
O tempo é o tempo de relógio desde a primeira mensagem até uma resposta avaliada. O custo é estimado em dólares americanos a partir dos preços de tokens do modelo, contando todas as chamadas de modelo da execução (incluindo leituras e gravações do cache de prompt, e qualquer chamada do Harumi a um modelo mais forte para pedir conselho). Não é o mesmo número que os créditos, que são a unidade em que seu plano é cobrado.
Os problemas
| Nível | O que contém | Por que está aqui |
|---|---|---|
| Sanidade | Problemas de enunciado pequenos, lineares e inteiros | Uma verificação de regressão. Os modelos vão bem aqui com ou sem ajuda, então não entra no resultado principal. |
| Problemas difíceis consagrados | Problemas mais longos de coleções clássicas de pesquisa operacional, em escalonamento, dimensionamento de lotes, roteamento e projeto de redes | Onde uma primeira tentativa costuma precisar de correção. |
| Benchmarks públicos | IndustryOR, MAMO ComplexLP e OptMATH-Bench | Reconhecidos fora do Harumi. Só são usados problemas cuja resposta foi reproduzida de forma independente (veja abaixo). |
| Instâncias ampliadas | Os mesmos tipos de problema regenerados de 10 a 100 vezes maiores | A resposta depende de ler muitos dados corretamente. Não exige esforço do solver: eles resolvem em milissegundos. |
| Reservados | Problemas escritos pelo Harumi e nunca publicados: dados em arquivos CSV ou JSON, problemas sem solução e conversas que mudam o problema | Não podem estar no treinamento de nenhum modelo e são os mais próximos de como os clientes usam o Harumi. |
Rótulos dos benchmarks públicos
Benchmarks públicos reconhecidamente têm respostas erradas. Um modelo marcado como errado por discordar de um rótulo errado tornaria a comparação sem sentido, então cada problema público foi resolvido de forma independente por um modelo forte, com algumas tentativas (a tabela mostra quantas), e só foi mantido se uma delas reproduziu a resposta publicada.
Nenhuma execução do benchmark foi publicada ainda. Esta página é preenchida a partir da primeira execução completa; até lá, não mostra números.
Isso mantém os problemas que puderam ser verificados, então a parte pública do benchmark tende a ser mais fácil que as coleções originais. O número de descartados é mostrado para que você veja quanto foi removido.
O que isto não mostra
- Um modelo de cada vez. Toda comparação mantém o modelo fixo. Ela diz o que a plataforma acrescenta a um modelo, não qual modelo é o melhor.
- Sem laço de repetição para o modelo puro. O concorrente puro tem uma tentativa de propósito, que é o que chamar um modelo diretamente significa. Um laço caseiro que devolva os erros ao modelo fecharia parte da diferença; essa variante não é medida aqui.
- Um retrato do momento. Os modelos e a plataforma mudam. A data da execução e a versão que produziu os números são registradas junto com os dados.
- Problemas com resposta conhecida. Trabalho de modelagem aberto, em que nenhum número único define o sucesso, não é coberto.
- Custo estimado. Ele segue os preços de lista dos tokens e não inclui o tempo de computação do sandbox.