Ricursive lança o Ripple-65B: modelo atinge 80,5% no Terminal-Bench 2.1

Quando um agente corrige um bug, dinheiro e tempo são gastos em todo o percurso: ler arquivos, encontrar a causa, fazer a alteração, executar testes e lidar com um novo erro. A Ricursive propõe o Ripple-65B Preview para esse tipo de trabalho. O interesse prático é claro: verificar se o modelo dá conta do seu repositório com latência e custo aceitáveis. Por exemplo, se ele consegue consertar sozinho um manipulador de API quebrado e confirmar o resultado com um teste.

É um modelo de pesos abertos com 65 bilhões de parâmetros. Na avaliação publicada pelos desenvolvedores, ele atingiu 80,52% no Terminal-Bench 2.1. O Reflection Beam tem 80,1% na mesma tabela. A diferença é pequena, então uma manchete sobre vitória incontestável seria exagerada aqui. O mais interessante é a possibilidade de ter mais um candidato para um agente de programação. Fonte: Ricursive.

O que exatamente foi lançado

O Ripple usa uma arquitetura densa: diferentemente dos modelos de mistura de especialistas, ele emprega todos os seus parâmetros ao processar cada token. Por isso, comparar apenas pelo tamanho total pode ser enganoso. Num modelo maior de mistura de especialistas, apenas parte dos parâmetros funciona ao mesmo tempo; um número menor no nome não promete, por si só, uma resposta mais barata.

Os desenvolvedores declaram um contexto de até 1.048.576 tokens. Os pesos foram publicados sob Apache 2.0, com variantes BF16 e NVFP4 disponíveis. Para equipes com exigências sobre onde o código é hospedado, isso amplia a escolha: é possível considerar a implantação própria. Mas o tamanho do contexto ainda não mostra com que segurança o agente encontrará a dependência certa entre centenas de arquivos. Fonte: ficha do modelo.

É útil separar aqui duas tarefas. A primeira é hospedar o modelo e obter uma velocidade de resposta aceitável. A segunda é montar um agente que use corretamente a busca, o terminal e os testes. Um bom resultado na primeira não garante sucesso na segunda. Um contexto longo também não elimina a necessidade de escolher quais arquivos passar ao modelo.

Por que o resultado do teste não pode ser transferido diretamente para o repositório

Os próprios autores descrevem a sensibilidade das avaliações agênticas às condições de execução. A ficha indica que mudar o programa de controle e as configurações de contexto alterava os resultados do Terminal-Bench. A tabela comparativa deles reúne números oficiais de outros laboratórios e medições próprias onde faltavam dados publicados. Isso limita a precisão da comparação direta. Metodologia de avaliação.

Imagine um bug comum: depois da atualização de uma dependência, o login de usuários parou de funcionar. O agente precisa ler a mensagem de erro, encontrar a chamada que mudou, corrigir o manipulador e executar um teste adequado. Uma explicação bem escrita da causa não basta aqui. É preciso uma correção que funcione e preserve o comportamento anterior dos demais cenários.

Agora acrescentemos condições reais: o banco de dados de teste está indisponível, a documentação está desatualizada e o erro só se reproduz com uma certa configuração. É aqui que aparecem as diferenças entre modelos e configurações de agente. Um precisará de uma dica humana, outro começará a alterar arquivos desnecessários, um terceiro apontará corretamente quais dados lhe faltam. A pontuação geral de um benchmark não substitui essa verificação.

Como verificar a utilidade para a equipe

Eu começaria com uma pequena seleção de tarefas já resolvidas: correção de erro, adição de teste, mudança de API e trabalho com um módulo desconhecido. Cada uma precisa do estado inicial do projeto e de um critério de sucesso claro. Depois, vale dar ao Ripple e ao modelo atual as mesmas ferramentas, limites de tempo e acesso ao ambiente.

O melhor é contar o custo de uma correção aceita. Nele entram novas tentativas, tempo de execução dos comandos e revisão humana. Tokens baratos ajudam pouco se o desenvolvedor depois passa meia hora removendo alterações desnecessárias. Separadamente, vale registrar os casos em que o agente declarou a tarefa resolvida, embora a verificação do resultado não tenha ocorrido.

Para um produto, é uma forma de tomar uma decisão concreta: se o Ripple serve para a classe de tarefas escolhida, se é necessária verificação adicional e quando passar o trabalho a uma pessoa. Os pesos abertos tornam esse experimento mais acessível em termos de controle da implantação. A base para a migração devem ser os resultados no seu próprio código, junto com tempo, custos e qualidade das correções.