Se você acompanha o RadIA, já sabe que a proposta do projeto não é colocar apenas mais uma janela de chat dentro do Delphi. O objetivo é permitir que a inteligência artificial participe de fluxos reais de desenvolvimento: inspecionar o projeto aberto, localizar símbolos, alterar arquivos, compilar, executar testes, analisar diffs e apresentar evidências verificáveis.

Esse tipo de experiência tem um desafio que normalmente aparece somente quando o agente começa a executar tarefas longas: o volume de contexto cresce muito rápido.

Uma compilação pode produzir centenas de hints. Uma suíte de testes pode repetir milhares de linhas de sucesso. Um diff pode ter centenas de kilobytes. Uma busca na base de conhecimento pode retornar trechos extensos. Se todo esse conteúdo continuar sendo reenviado integralmente ao modelo a cada nova decisão, a IA passa a gastar contexto, tempo e possivelmente dinheiro relendo informações que já foram processadas.

O RadIA 2.3.0 enfrenta esse problema com um RTK interno, escrito em Delphi e integrado diretamente ao Agent Runtime.

RTK, neste contexto, é uma camada de compactação de resultados de ferramentas. Em vez de entregar ao modelo todo o payload bruto em cada passo, o RadIA cria uma projeção menor, determinística e orientada às evidências que realmente importam. O resultado original não é apagado: ele permanece armazenado e pode ser recuperado por resumo ou por faixa sem executar a ferramenta novamente.

O efeito esperado é simples de explicar: menos ruído no contexto, mais espaço para raciocínio, menos repetição e maior capacidade de sustentar tarefas longas.

A versão 2.3.0 do RadIA reduz o volume de resultados reenviado aos modelos sem descartar a evidência original. Em dez execuções Release, o benchmark controlado mediu 96,71% de redução no corpus completo e 75,65% quando removemos o stress test de 1 MiB. Este artigo explica o que esses números realmente demonstram, o que eles não demonstram e por que tratar contexto como recurso pode ser uma evolução importante na programação assistida por IA.

Mas antes de falar em economia, precisamos responder à pergunta mais importante: os benchmarks são reais e confiáveis?

Os benchmarks são reais? Sim, com uma ressalva importante

Sim. Os números apresentados neste artigo foram produzidos pela implementação compilada do RadIA 2.3.0, em uma build Delphi 13 Win32 Release. Foram executados dez processos independentes, todos concluídos sem falhas. Cada processo executou o fixture DUnitX do benchmark e gerou sua própria evidência JSON.

Os dez resultados brutos estão preservados e a execução é reproduzível. O tamanho original, o tamanho compactado e a redução foram idênticos nas dez rodadas, como esperado de uma transformação determinística. Os tempos variaram dentro de uma faixa pequena.

Também confirmamos que:

• o binário usado corresponde à implementação publicada;
• os três pacotes da release apontam para o commit final c988159cc49397fc50c9c863480788b6b123e58e;
• a tag v2.3.0 aponta para o mesmo commit;
• o benchmark A/B usa as mesmas sete chamadas nos modos integral e compactado;
• nenhuma das dez saídas DUnitX registrou falha ou erro;
• os testes de fidelidade verificam preservação de errors, failures, paths, cabeçalhos e hunks de diff, início e fim dos conteúdos, proveniência, recuperação do resultado integral e rollback com o perfil Off.

A ressalva é igualmente importante: o corpus é sintético e sanitizado.

Ele foi criado para ser determinístico, público e auditável. Isso é ótimo para regressão e comparação A/B, mas não transforma 96,71% em uma média universal do trabalho diário. O corpus contém um stress test de diff com 1 MiB, formado por conteúdo altamente compactável, que representa a maior parte do volume total. Portanto, seria incorreto afirmar que todo desenvolvedor reduzirá sua conta ou seu contexto em 96,71%.

A formulação honesta é esta:

No corpus controlado e reproduzível do RadIA 2.3.0, a compactação reduziu 96,71% do volume total. Removendo o stress test dominante de 1 MiB, o restante do corpus ainda apresentou redução agregada de 75,65%. Resultados reais dependerão da combinação de ferramentas e conteúdos de cada sessão.

Essa distinção não diminui o resultado. Pelo contrário: ela separa engenharia mensurável de marketing exagerado.

O resultado principal: 1.145.022 caracteres viraram 37.630

No benchmark completo, o RTK interno transformou um corpus de 1.145.022 caracteres em 37.630 caracteres.

Isso representa:

• 96,71% de redução de caracteres;
• um payload 30,43 vezes menor;
• queda de 286.256 para 9.408 tokens estimados;
• aproximadamente 276.848 tokens estimados que deixariam de ocupar o replay desse corpus;
• 96,55% de redução no snapshot usado pela próxima decisão do agente;
• 0% de aumento em chamadas repetidas no replay A/B.

A palavra “estimados” é indispensável quando falamos em tokens. A conversão utilizada no benchmark é a aproximação transparente de quatro caracteres por token. Ela não usa o tokenizer de um modelo específico. Idioma, código, espaços, símbolos e provider alteram a tokenização real.

A economia exata medida é a de caracteres. A economia em tokens é uma aproximação útil para compreender ordem de grandeza, não um valor de faturamento.

O stress test não esconde o restante do resultado

Como o diff de 1 MiB domina o corpus completo, fizemos também uma análise de sensibilidade: removemos esse cenário e recalculamos o agregado com os outros seis casos, incluindo o controle que não deve ser compactado.

O resultado passou de 96.400 para 23.470 caracteres.

Isso significa 75,65% de redução mesmo sem o teste extremo de 1 MiB.

Esse segundo número é particularmente útil para o artigo porque mostra que o ganho não depende exclusivamente do maior payload. Ele continua aparecendo em logs de testes, mensagens de build, diffs menores e conteúdo de conhecimento.

Ainda assim, esses casos continuam sendo fixtures controladas. O valor de 75,65% também não deve ser vendido como média garantida de produção. Ele é uma evidência adicional de que a técnica funciona em formatos diferentes.

Resultado por tipo de ferramenta

O último cenário é tão importante quanto os demais. Uma ferramenta sem regra segura de compactação passa pelo sistema sem alterações. O RTK não tenta resumir qualquer conteúdo a qualquer custo. Quando não existe uma transformação determinística apropriada, o comportamento é fail-open: o resultado integral segue para o modelo.

O custo computacional local ficou abaixo de 25 milissegundos

Nas dez execuções Release, o tempo total para processar os sete cenários ficou entre 21,544 e 24,391 milissegundos.

A mediana foi de 22,732 milissegundos e a média de 22,920 milissegundos.

O diff de 1 MiB respondeu pela maior parte desse tempo:

• mínimo de 19,589 ms;
• mediana de 20,745 ms;
• máximo de 22,290 ms.

Nos payloads menores, os tempos medianos ficaram entre 0,062 e 1,221 milissegundo.

Em outras palavras, no ambiente medido, o custo local da compactação foi pequeno quando comparado ao tempo normal de uma requisição de rede para um modelo. Não medimos, porém, a latência ponta a ponta de todos os providers; a comparação deve ser entendida como ordem de grandeza, não como benchmark de rede.

Como essa economia pode aparecer no dia a dia

O benefício não vem apenas de enviar menos dados uma vez. Em um agente, resultados anteriores podem participar de várias decisões seguintes. Um log grande que entra no histórico pode ser relido durante o planejamento da correção, a edição, a recompilação e a validação final.

Quando o runtime troca o payload bruto por uma projeção compactada, ele reduz o volume carregado nesses passos posteriores.

Considere um exemplo meramente ilustrativo: uma ferramenta retorna 100.000 caracteres elegíveis, aproximadamente 25.000 tokens pela mesma aproximação do benchmark.

• Com uma redução de 50,60%, equivalente ao cenário menos favorável medido entre as regras ativas, o resultado cairia para cerca de 49.400 caracteres, economizando aproximadamente 12.650 tokens estimados naquele payload.
• Com uma redução de 75,65%, igual ao agregado do corpus sem o stress test de 1 MiB, o resultado cairia para aproximadamente 24.350 caracteres, economizando cerca de 18.913 tokens estimados.
• Em um caso altamente repetitivo semelhante aos logs DUnitX do benchmark, a redução pode ultrapassar 98%.

Esses exemplos não são promessa de economia financeira. São aplicações matemáticas das taxas observadas sobre um payload hipotético. O impacto monetário real depende de cinco fatores:

1. quanto do contexto da sessão é composto por resultados elegíveis;
2. quantas vezes esses resultados voltariam a aparecer em decisões posteriores;
3. como o provider tokeniza o conteúdo;
4. se o provider utiliza cache de prompt e como cobra esse cache;
5. o preço do modelo e do transporte selecionado.

Por isso, a forma mais responsável de falar sobre a economia cotidiana é: o RTK reduz diretamente o volume de resultados elegíveis que o RadIA entrega ao modelo; quanto maior a participação desses resultados no contexto, maior tende a ser o ganho potencial em capacidade, latência e tokens processados.

Insira logo antes da seção “Como essa economia pode aparecer no dia a dia”.

Executar localmente não consome tokens — enviar o resultado para a IA, sim

Rodar Git, DUnitX ou o compilador Delphi localmente não consome tokens de IA. Essas operações utilizam apenas os recursos da própria máquina.

O consumo começa quando o comando, seu resultado ou parte do histórico é enviado ao modelo para interpretação.

DUnitX executa localmente                     → 0 tokens
Log do DUnitX enviado ao modelo               → consome tokens
Git calcula o diff localmente                 → 0 tokens
Conteúdo do diff enviado ao modelo            → consome tokens
Delphi compila o projeto localmente            → 0 tokens
Mensagens da compilação enviadas ao modelo     → consomem tokens

É justamente nessa fronteira que o RTK interno atua. Git, DUnitX e o compilador continuam executando normalmente na máquina do desenvolvedor. O resultado integral permanece disponível no RadIA, mas o modelo recebe uma projeção compactada com as evidências mais relevantes.

Assim, a funcionalidade não reduz o custo computacional da execução local. Ela reduz o volume de contexto que a inteligência artificial precisa receber e reprocessar para tomar as próximas decisões.

Mais contexto útil, não apenas menos tokens

É tentador analisar a funcionalidade apenas pela redução de tokens, mas o ganho arquitetural pode ser ainda mais importante.

Modelos possuem uma janela de contexto finita. Mesmo quando o limite é grande, preencher essa janela com milhares de linhas repetidas não melhora a decisão. Muitas vezes, faz o oposto: evidências importantes ficam diluídas em ruído operacional.

O RTK interno prioriza o que o agente precisa para decidir:

• errors, failures e mensagens fatais;
• paths e posições;
• cabeçalhos e hunks de diff;
• início e fim de conteúdos truncados;
• contagens e proveniência;
• status e resultado da ferramenta.

Isso permite que o contexto funcione menos como um depósito de logs e mais como memória operacional.

Essa mudança aponta para uma evolução na forma de programar com IA. Na primeira geração de assistentes, o desenvolvedor copiava código para um chat e recebia uma sugestão. Na geração agentiva, a IA observa ferramentas, toma decisões em sequência e acumula evidências. O desafio deixa de ser apenas “como gerar uma boa resposta?” e passa a incluir “como administrar a memória de trabalho do agente?”.

Contexto se torna um recurso de engenharia, assim como memória, CPU, tempo de build ou conexões de banco de dados.

Compactar sem destruir a evidência

Reduzir contexto seria perigoso se significasse apagar o resultado original. Por isso, o RadIA separa três conceitos:

1. resultado integral, que é a fonte de verdade;
2. artefato recuperável, armazenado com SHA-256, quotas e retenção;
3. projeção compactada, usada somente na fronteira de decisão do modelo.

Quando parte de um resultado é omitida, o agente pode usar duas novas ferramentas:

• GetToolResultSummary, para consultar metadados e estrutura do resultado;
• GetToolResultRange, para recuperar uma faixa específica sem repetir a operação original.

Isso é particularmente valioso em ações caras ou mutáveis. Reexecutar um build custa tempo. Repetir uma busca pode retornar dados diferentes. Reexecutar uma ferramenta com efeitos colaterais pode ser inadequado. Recuperar o artefato original mantém a investigação determinística.

O armazenamento aplica:

• hash SHA-256;
• escrita atômica;
• boundary por sessão;
• limite de 8 Mi caracteres por artefato;
• até 100 artefatos por sessão;
• limite de 64 Mi caracteres por sessão;
• retenção padrão de 14 dias;
• ranges de até 65.536 caracteres com boundary Unicode seguro.

Os testes cobrem concorrência, expiração, traversal, spoofing de sessão, quotas, reabertura e recuperação.

Perfis para adotar ou desligar a funcionalidade

O RadIA 2.3.0 oferece três perfis em General / Logs:

• Off: desativa a projeção compactada e funciona como rollback imediato;
• Conservative: perfil padrão, priorizando regras determinísticas e preservação de evidências;
• Balanced: permite uma política mais agressiva dentro do orçamento configurado.

O orçamento global do contexto decisório também pode ser configurado. O comando /status agent mostra o perfil efetivo, o limite e métricas sanitizadas da sessão.

Checkpoints, interface, validações e artefatos continuam usando o resultado integral. A compactação afeta a projeção entregue à próxima decisão do modelo, não a evidência exibida ao desenvolvedor.

Qualidade e compatibilidade da versão 2.3.0

O RadIA 2.3.0 foi validado em:

• Delphi 12 Athens Win32 Release;
• Delphi 13 Win32 Release;
• Delphi 13 IDE64 Win64 Release.

A suíte passou com 892 de 892 testes em cada alvo, sem falhas, erros ou vazamentos de memória. O smoke automatizado do Delphi 13 IDE64 carregou 126 ferramentas e concluiu o ciclo de pause, persistência, retomada e finalização do Agent Runtime.

Também foram aprovados:

• ESLint;
• 40 testes web;
• 14 testes documentais;
• Quality Gate do SonarQube;
• 83% de cobertura no código novo;
• zero issues, bugs, vulnerabilidades, hotspots ou code smells no relatório final.

Metodologia do benchmark

A medição principal utilizou:

• RadIATests.exe compilado com Delphi 13 para Win32 Release;
• Windows 11 Pro 64 bits, versão 10.0.26200;
• Intel Core i9-13900HX, 24 cores e 32 processadores lógicos;
• dez processos independentes;
• sete fixtures sanitizadas cobrindo DUnitX, Git diff, build, conhecimento e passthrough;
• comparação A/B com as mesmas ferramentas e os mesmos payloads;
• evidência JSON individual para cada rodada.

O benchmark mede transformação local de payload e construção do replay decisório. Ele não mede qualidade subjetiva de resposta, preço final de um provider, latência completa da API ou economia em uma amostra de projetos de produção.

Essa última medição — telemetria agregada e sanitizada de sessões reais, sem armazenar código ou prompts — é o próximo passo natural para transformar potencial comprovado em distribuição observada de uso cotidiano.

Como reproduzir

O fixture pode ser executado diretamente na suíte compilada:

Output\37.0\bin\Win32\Release\RadIATests.exe `
  --run:RadIA.Tests.ResultCompactionBenchmark.TRadIAResultCompactionBenchmarkTests.BenchmarkProducesMeasuredSavings `
  --consolemode:Quiet

O repositório também contém o script que executa build, testes e gates do benchmark:

powershell.exe -ExecutionPolicy Bypass `
  -File scripts\Test-RadIA.ResultCompaction.ps1 `
  -DelphiVersion "37.0"

A implementação, as fixtures, a evidência sanitizada e a auditoria de viabilidade estão disponíveis no repositório oficial.

Outras novidades da versão

Além do RTK interno, a versão 2.3.0:

• amplia o catálogo de 124 para 126 ferramentas;
• adiciona diagnóstico explícito de compactação, recuperação e rollback;
• persiste configurações de perfil e orçamento;
• expõe métricas agregadas sem armazenar código, prompts, argumentos ou secrets;
• atualiza backlog, matriz de priorização, roadmap, guias, hints e referências operacionais.

Como instalar

Feche todas as instâncias do Delphi e acesse a página oficial da release:

Baixar o RadIA 2.3.0

Execute RadIA-v2.3.0-Setup.exe e escolha os alvos desejados:

• Delphi 12 Win32;
• Delphi 13 Win32;
• Delphi 13 IDE64.

O SHA-256 do instalador publicado é:

8E604CAFFF6E62501C239B0806A53EB2721DBDAC086E57494EC73A12FFE2467F

O RadIA é open source. O código-fonte, os testes, a documentação e o histórico completo estão no repositório oficial no GitHub.

Conclusão

O principal avanço do RadIA 2.3.0 não é simplesmente “comprimir texto”. É introduzir uma camada de memória entre as ferramentas e o modelo.

O agente continua tendo acesso à verdade completa, mas deixa de carregar todo o peso dessa verdade em cada decisão. Logs repetidos viram evidência concisa. Diffs extensos preservam estrutura e pontos críticos. Conteúdos omitidos permanecem recuperáveis. Ferramentas sem regra segura continuam intactas.

Os benchmarks mostram que a implementação produz reduções grandes e rápidas no corpus controlado: 96,71% no conjunto completo, 75,65% sem o stress test dominante e uma faixa de 50,60% a 99,14% entre as regras exercitadas. Eles não provam uma economia universal de 96,71% em produção — e não precisam provar isso para demonstrar o valor da arquitetura.

A evolução está em tratar contexto como parte do sistema, não como um espaço infinito e gratuito.

Quando fazemos isso, a inteligência artificial pode permanecer útil por mais tempo, trabalhar com menos ruído, preservar mais espaço para raciocínio e acompanhar fluxos de desenvolvimento cada vez mais complexos.

Essa pode ser uma das mudanças mais importantes na próxima geração de ferramentas de programação: não apenas modelos que escrevem código, mas runtimes que sabem administrar o que o modelo realmente precisa lembrar.