SoL-Pi: menos tokens nos agentes de código, poupança a medir

O SoL-Pi altera o funcionamento dos agentes de código: no benchmark dos autores, reduz o tráfego de tokens com um desempenho comparável ao sistema de referência. Esta análise, atualizada a 28 de outubro de 2026, parte do artigo publicado a 17 de setembro e distingue os resultados da investigação das verificações necessárias antes da utilização em código empresarial.

Quatro mecanismos, um harness

O SoL-Pi integra quatro técnicas que, segundo os investigadores, resistiram aos testes num conjunto crescente de ambientes de desenvolvimento: Action Fusion, ObservationPack, um Redutor com Preservação de Evidências e Online Context Compact. Em conjunto, visam a forma como um agente executa ações, compacta o contexto, trata o resultado das ferramentas e decide o que precisa de reler, em vez de alterarem o modelo de linguagem subjacente que faz o raciocínio.

O que o benchmark mostrou

No EdgeBench, uma avaliação com 51 tarefas, os autores referem que o SoL-Pi iguala o desempenho do seu harness de referência, o Pi, em dois modelos de suporte diferentes, reduzindo o tráfego de tokens registado entre 44,7% e 49,0% e diminuindo o custo de API em cerca de um terço. Estes são os números reportados no próprio artigo, no seu próprio benchmark — um sinal útil do que é possível, não uma garantia das mesmas poupanças numa base de código ou cadeia de ferramentas diferente.

O que isto significa para as equipas de engenharia

O código está disponível em código aberto em github.com/NVlabs/SoL-Pi, pelo que as equipas que executam agentes de codificação em escala podem testar o harness nos seus próprios repositórios e ferramentas, em vez de aceitarem os números do benchmark do artigo sem verificação. O interesse inicial no GitHub não é o mesmo que a adoção em produção, e um ganho de eficiência ao nível do harness não altera o que o modelo subjacente consegue ou não fazer — altera o custo de o executar. Quem construir sobre isto deve medir as poupanças de tokens e de custos nas suas próprias cargas de trabalho antes de citar os números do artigo numa proposta para clientes.

Porque é importante: medir o trabalho concluído

Para um ensaio útil, devem escolher-se tarefas que a equipa realmente executa: corrigir um erro, acrescentar uma pequena funcionalidade ou atualizar uma dependência com os respetivos testes. A comparação deve repetir-se com o mesmo modelo, repositório, instruções e critérios de aceitação. Também contam as tentativas falhadas, as esperas e as correções manuais: uma sessão com menos tokens que deixa o trabalho incompleto não representa uma poupança. O estado inicial deve ser preservado para comparar e reverter alterações.

É necessário registar separadamente tokens de entrada e de saída, custo faturado, duração e tarefas aceites após revisão. O preço depende do modelo e das condições do fornecedor: a redução de tráfego não corresponde automaticamente à mesma redução percentual da fatura. Um MSP deve separar as medições por projeto, sem copiar conteúdos de um cliente para os registos ou ensaios de outro. A comparação deve continuar a ser reproduzível após uma atualização, com a configuração utilizada devidamente documentada.

O tratamento das observações merece uma verificação própria. Um erro de compilação, teste falhado ou aviso de segurança deve continuar recuperável após a redução do contexto. É preciso definir onde ficam os arquivos, quem os pode consultar e quando serão eliminados. Antes de ativar um modelo adicional para resumir registos, devem verificar-se o percurso dos dados e as credenciais envolvidas. Um resumo útil tem de preservar as provas necessárias à revisão, incluindo as que contradigam uma resposta final aparentemente bem-sucedida.

O ponto de partida deve ser uma cópia isolada do repositório com dados de teste, sem credenciais de produção. Devem definir-se um limite de despesa e uma condição de paragem, alargando o âmbito apenas se a qualidade e os prazos forem aceitáveis. A decisão diz respeito ao custo de uma tarefa concluída e verificada, não a um contador isolado. Os serviços de inteligência artificial da Altovar ajudam a enquadrar esta avaliação nos processos da empresa, com objetivos e responsabilidade de revisão definidos antecipadamente.

Fontes: arXiv, GitHub.