Medir uma tarefa com IA até à aceitação

Uma tarefa de programação pode exigir chamadas ao modelo durante a implementação, numa nova tentativa após uma verificação falhada e em trabalho adicional durante a revisão. A primeira mensagem de conclusão regista apenas um momento desse percurso. Uma comparação útil acompanha o trabalho até se conhecer o resultado.

Comece por uma tarefa cujo resultado alguém possa avaliar. Numa alteração ilustrativa de uma API, torne obrigatório um campo de entrada e teste valores válidos e em falta. Acorde as respostas esperadas antes de comparar abordagens, mantendo fixos os limites da tarefa e as verificações de aceitação. O exemplo abaixo não contém resultados comparativos.

Figura 1 em texto

A alteração ilustrativa exige um campo numa API e verifica as respostas acordadas para valores válidos e em falta. Registe a utilização do modelo na implementação, nas correções e nas chamadas de revisão. Os testes fornecem evidência; a revisão pode pedir alterações e devolver o trabalho para correção. Uma pessoa decide a aceitação. Inclua também trabalho rejeitado ou abandonado no âmbito da comparação. Não são apresentados resultados medidos.

Acompanhar o trabalho, incluindo as correções

Na prática interna de desenvolvimento da Devmojos, um operador prepara instruções com âmbito definido, contexto relevante e verificações de aceitação. Verificações automáticas analisam essas instruções antes de um agente de execução começar. O agente implementa a alteração atribuída numa cópia isolada do projeto e relata o que alterou e verificou.

A revisão independente e a verificação pelo operador informam a aceitação. Se uma verificação ou revisão detetar um problema, a correção continua a fazer parte do registo da mesma tarefa. Registe o problema encontrado, a tentativa seguinte e o resultado final. Uma tarefa rejeitada, interrompida ou abandonada também pertence ao âmbito declarado da comparação.

Esta estrutura em torno de um agente é um harness: as instruções da tarefa, as ferramentas, o contexto, as passagens de trabalho e a revisão que apoiam a sua execução. Um teste bem-sucedido fornece evidência sobre o comportamento que verificou. Continua a caber às pessoas decidir se o trabalho acordado é aceitável e se deve ser lançado.

Figura 2 em texto

O percurso começa por acordar a tarefa, reunir contexto e escolher um modelo adequado ao trabalho. A implementação segue instruções escritas numa cópia isolada, com testes e revisão independente. Uma pessoa aceita o resultado ou devolve-o. As correções regressam ao trabalho (passo 4); um resultado não aceite pode regressar à definição da tarefa (passo 1). Cada passagem fica registada. Este método interno é ilustrativo e não apresenta poupanças medidas.

Criar um registo com medições distintas

O que se segue é uma proposta de ficha de registo para a alteração ilustrativa da API. Não é um painel de medições já recolhidas pela Devmojos. Assinale como desconhecido qualquer valor cuja fonte não esteja disponível.

Figura 3 em texto

Para cada tarefa, registe tokens de entrada e saída, incluindo novas tentativas e contexto reenviado; ferramentas, computação e armazenamento; tempo até ao resultado, incluindo esperas; tempo de revisão humana e rondas de correções; e o estado final de aceitação. São dimensões distintas, com as respetivas unidades. Um total monetário exige preços ou critérios de imputação explícitos, sem contar o mesmo encargo duas vezes. A ficha proposta no artigo é um registo mais completo a preencher; não demonstra que todas estas medições já são recolhidas.

Tokens, minutos e estados de aceitação descrevem aspetos diferentes. Converta as componentes monetárias com uma base explícita de preços ou de imputação antes de as somar e evite contar o mesmo encargo duas vezes. Subscrições de planos ou hardware local exigem uma decisão de imputação; a falta de dados de custo não é evidência de custo zero.

Alterar uma parte de uma tarefa comparável

O contexto deve dar ao agente os requisitos, o código relevante e as verificações de que precisa. Instruções que omitam uma restrição podem gerar trabalho de correção. Material adicional deve justificar a sua presença por ajudar a tarefa. As orientações da Anthropic sobre engenharia de contexto discutem este problema de seleção.

A escolha do modelo também faz parte da tarefa. A capacidade, o tempo de resposta, as restrições operacionais e a dificuldade do trabalho são relevantes. Compare as tentativas e os problemas encontrados na revisão juntamente com a utilização. A cache deve constar do registo de utilização quando essa informação estiver disponível; uma percentagem de acertos na cache, por si só, não demonstra a alteração numa fatura.

Para uma comparação, declare que tarefas concluídas e sem sucesso estão incluídas, o que se manteve comparável e o que mudou. Registe custos excluídos ou desconhecidos. Se uma abordagem produzir um resultado utilizável mas exigir mais revisão, o registo deve tornar essa relação visível em vez de a reduzir a um total de tokens.

O que a nossa prática interna demonstra

A nossa análise interna do encaminhamento inclui tempos de aceitação verificados, verificações falhadas e trabalho de correção. Não demonstra o custo monetário completo por funcionalidade aceite nem poupanças repetíveis para clientes. A ficha mais completa acima é uma recomendação de medição. A investigação da Anthropic sobre harnesses é uma leitura relacionada útil; não comprova resultados da Devmojos.

Traga uma tarefa de engenharia recorrente, as ferramentas e verificações de aceitação atuais e o ponto em que a revisão ou a correção se torna difícil. A oferta AI Engineering da Devmojos pode começar por uma avaliação do processo e uma experiência de adoção com âmbito definido, ajudando a sua equipa a decidir o que manter.