O mais absurdo é: não tenho nenhuma formação em aprendizado de máquina, não conheço o fluxo padrão de treinamento de modelos nem muitos detalhes técnicos. O que eu fiz foi basicamente pedir constantemente ao Sol para resolver problemas, fornecer feedback sobre os resultados, permitindo que ele próprio identifique os problemas, projete experimentos e continue iterando.Autor do artigo: Anshu
Artigo compilado, fonte: ME News
Esta é a primeira vez que realmente senti que a AGI parece já ter chegado.
Treinei um modelo automático de correção própria usando GPT-5.6 Sol. Por fim, este modelo local com apenas 1,7 bilhão de parâmetros apresentou desempenho ligeiramente superior ao GPT-5.6 Sol no conjunto de teste.
O mais absurdo é: não tenho nenhuma formação em aprendizado de máquina, não conheço o fluxo padrão de treinamento de modelos nem muitos detalhes técnicos. O que eu fiz foi basicamente pedir constantemente ao Sol para resolver problemas, fornecer feedback sobre os resultados, permitindo que ele próprio identifique os problemas, projete experimentos e continue iterando.
O processo custa zero.
Tudo começou com um problema de digitação cada vez mais grave
Após conversar por muito tempo com IA, percebi que minha habilidade de digitar está ficando cada vez pior.
Já me acostumei a digitar rapidamente e deixei de verificar cuidadosamente erros de ortografia, ordem das letras ou letras omitidas. Em vez de treinar novamente minha habilidade de digitação, decidi adotar uma solução mais alinhada à era da IA: continuar usando mais IA para resolver problemas.
A correção automática tradicional modifica constantemente o texto durante a digitação, o que facilmente interrompe o fluxo de pensamento. Minha ideia é permitir que o usuário digite rapidamente sem interrupções, mesmo que contenha muitos erros, e apenas após a conclusão da digitação, a IA realiza uma limpeza unificada.
Ao mesmo tempo, desejo que este modelo seja o menor possível.
Quanto menor o modelo, mais rápido ele executa, menor é o consumo de energia e mais adequado é para execução totalmente local. Seja por eficiência, duração da bateria ou apenas por interesse experimental, quero ver até que ponto um modelo local suficientemente pequeno pode realizar a correção automática.
Então, decidi treinar um eu mesmo.
Faça o Sol se tornar um pesquisador automático de experimentos
A inspiração para este projeto veio do experimento "autoresearch" de Andrej Karpathy.
I used Codex's /goal mode to design a cyclical workflow for Sol:
Escolha um experimento, execute-o e registre os resultados no documento; se falhar, abandone essa abordagem; em seguida, planeje o próximo experimento, evitando repetir erros já verificados.
Eu forneceu apenas alguns exemplos de entrada obrigatórios, metas rigorosas de latência e o efeito final desejado, depois deixei o Sol operar por conta própria.
O que aconteceu a seguir ultrapassou minhas expectativas.
Sol primeiro buscou e comparou vários modelos base candidatos, incluindo Qwen 3.5, Gemma 4 e Liquid LFM 2.5. Em seguida, encontrou um conjunto de dados no Hugging Face relacionado a textos de digitação reais.
Mas os dados reais ainda não são suficientes.
Para gerar erros de digitação mais próximos das entradas reais dos usuários, Sol desenvolveu um simulador de “batidas dos dedos no teclado Mac”. Ele simula o ponto de impacto dos dedos com uma distribuição gaussiana, com base na disposição física do teclado, e gera diversos erros comuns, como:
- Pressione as teclas adjacentes;
- Letras invertidas;
- Repeat input;
- Caractere ausente;
- Toque vários botões ao mesmo tempo com os dedos.
Com o modelo base, os dados de texto e o simulador de erros de teclado, o Sol foi ajustado diretamente no meu MacBook usando MLX.
Em menos de uma hora, ele criou um protótipo funcional.
O problema é que a precisão da primeira versão não foi ideal.
Primeiro gargalo: o Tokenizer não entende erros de digitação
Sol leu os artigos relacionados e projetou uma série de testes, concluindo finalmente que o principal gargalo do modelo não está nos dados de treinamento, mas no Tokenizer, ou seja, no tokenizador.
Os grandes modelos de linguagem geralmente não entendem o texto letra por letra, mas primeiro dividem o texto em tokens. Palavras normais podem ser decompostas em unidades semânticas estáveis, mas erros de digitação frequentemente quebram a estrutura original dos tokens.
Isso significa que um erro de letra óbvio para os humanos pode, aos olhos do modelo, se tornar um conjunto de tokens completamente desconhecidos.
Os modelos têm dificuldade em realmente “compreender” erros, limitando-se a memorizar mecanicamente a correspondência entre grafias incorretas e corretas. Isso não apenas reduz a capacidade de generalização, como também impede o pleno aproveitamento do conhecimento linguístico original do modelo.
Sol primeiro tentou o ByT5 do Google.
ByT5 é um modelo que não depende de Tokenizadores tradicionais e processa sequências de bytes diretamente. Esta tentativa trouxe melhoras significativas, mas como o ByT5 foi lançado há algum tempo, o modelo possui conhecimento linguístico limitado, e seu desempenho final ainda não alcança o nível do GPT-5.6 Sol.
Após pesquisar mais, Sol percebeu que o problema não precisava ser resolvido necessariamente "cancelando completamente o Tokenizer".
Ele escolheu em vez disso o T5Gemma, um modelo de arquitetura Encoder-Decoder.
Diferentemente de modelos que apenas preveem o próximo token, o modelo Encoder-Decoder pode primeiro compreender completamente a entrada por meio do codificador e, em seguida, gerar o texto corrigido pelo decodificador. Mais importante ainda, o Sol também pode realizar pós-treinamento adicional no codificador, permitindo que o modelo identifique melhor entradas com erros de digitação.
This route significantly raises the model's performance ceiling.
Segundo gargalo: funções de perda tradicionais incentivam o modelo a "não modificar"
Após a alteração da arquitetura do modelo, um novo problema surgiu.
O modelo já consegue corrigir com precisão alguns erros, mas frequentemente ignora outros problemas ortográficos óbvios. Mesmo quando há erros na entrada, ele tende a copiá-los exatamente como estão.
Sol finalmente descobriu que o problema vinha da função de perda de entropia cruzada mais comum.
Nos dados de correção automática, a maioria dos caracteres já está correta, e apenas uma pequena proporção realmente precisa ser modificada. Se o treinamento for feito diretamente com entropia cruzada padrão, a estratégia mais segura para o modelo será “tentar não fazer alterações”.
Porque copiar o texto original fornece a resposta correta na maioria dos locais, enquanto modificar ativamente pode introduzir erros.
Em outras palavras, os objetivos de treinamento tradicionais estão recompensando o modelo por permanecer inalterado.
Para resolver esse problema, Sol desenvolveu um conjunto de funções de perda personalizadas.
Ele primeiro alinha o texto original com o texto de destino em nível de byte e, em seguida, calcula o caminho de edição mínimo entre os dois textos por meio de um algoritmo de programação dinâmica, identificando quais posições são cópias e quais são inserções, exclusões ou substituições reais.
Nesse contexto, o Sol aumentou significativamente o peso de treinamento correspondente à “correção correta”, enquanto reduziu os ganhos provenientes da simples cópia de caracteres.
Após várias rodadas de ajuste de parâmetros, a precisão da correção do modelo melhorou significativamente.
Terceiro gargalo: uma vez que o modelo erre, não poderá voltar atrás
A última questão principal vem do mecanismo de geração autoregressiva.
O modelo, ao gerar texto, só pode prever o próximo token com base no conteúdo já gerado. Uma vez que um erro ocorra em algum passo anterior, as gerações subsequentes serão construídas sobre o resultado incorreto, e o modelo não pode realmente voltar atrás e corrigir.
Teoricamente, é possível treinar o modelo para primeiro “pensar” antes de responder, como um modelo de raciocínio, mas isso aumentaria significativamente a latência e não seria adequado para cenários de correção automática que exigem respostas imediatas.
Sol finalmente encontrou uma solução mais elegante: Beam Search, também conhecido como busca em feixe.
O modelo não seleciona mais apenas o caminho único com a maior probabilidade em cada etapa, mas mantém simultaneamente múltiplas ramificações possíveis de geração, explorando em paralelo diferentes resultados de correção. Após a busca, é selecionado o caminho completo com a maior probabilidade logarítmica acumulada.
Isso equivale a substituir a inferência linear por busca paralela.
O Beam Search melhorou claramente o resultado final, mas introduziu um problema de experiência: o usuário não vê nenhuma saída até que a busca esteja concluída.
Sol em seguida fez uma observação muito inteligente.
Após cada rodada de busca, é possível comparar todos os ramos atualmente mantidos. Sempre que esses ramos compartilharem o mesmo início, esse “prefixo comum mais longo” aparecerá necessariamente no resultado final.
Portanto, o sistema pode exibir imediatamente este conteúdo ao usuário.
À medida que a busca continua, os caminhos mais fracos são gradualmente descartados, e o prefixo comum dos ramos restantes também se torna cada vez mais longo. Por fim, o usuário não vê resultados que aparecem de repente de uma só vez, mas sim um texto de correção gerado continuamente à medida que avança.
Sol transformou todo o processo em uma linha de raciocínio MLX personalizada, utilizando a GPU do MacBook para decodificação paralela.
Finalmente, a latência de saída do primeiro token foi de apenas cerca de 40 ms, suficientemente rápida, e todo o processo foi concluído totalmente localmente.
Resultado final: modelo de 1,7 bilhão de parâmetros supera o GPT-5.6 Sol
A avaliação final utiliza a "taxa de redução de erros" como métrica; quanto maior o valor, mais erros de entrada o modelo corrige.
Os resultados da avaliação são os seguintes:
- Correção automática da Apple: 49,66%
- GPT-5.6 Luna: 82,47%
- GPT-5.6 Terra: 87,64%
- GPT-5.6 Sol: 90,56%
- Nosso modelo treinado com 1,7 bilhão de parâmetros: 91,02%
Este modelo local superou o GPT-5.6 Sol por uma vantagem muito pequena.
Também verifiquei cuidadosamente se havia vazamento de dados ou “cola” do modelo. Durante os testes, excluímos ativamente palavras presentes nos dados de treinamento para verificar se o modelo não está simplesmente memorizando mapeamentos entre erros e respostas.
O custo final do projeto é:
Uma redefinição de limite de modelo e despesa em dinheiro de 0 dólares.
O que realmente me impressionou não foi apenas a pontuação final
Durante o projeto, houve muitos experimentos não expandidos, incluindo diferentes abordagens como aprendizado por comparação, GRPO, DPO e mascaramento dinâmico.
Nem todas as tentativas tiveram sucesso, mas o Sol conseguiu ler ativamente os materiais, identificar problemas, formular hipóteses, projetar experimentos, analisar resultados e planejar as próximas tentativas com base nas experiências de falha.
Para mim, o que realmente me impressiona não é o fato de que “um modelo de 1,7 bilhão de parâmetros superou o GPT-5.6 Sol”.
Mais importante ainda, uma pessoa sem nenhuma experiência em aprendizado de máquina já pode usar IA para realizar fluxos de experimento que antes exigiam equipes de pesquisa especializadas.
Eu não dominava todos os conhecimentos subjacentes nem planejei antecipadamente uma rota técnica completa. Eu apenas identifiquei claramente qual problema queria resolver e continuei incentivando o Sol a buscar respostas.
Ele não apenas escreve código, mas também assume os papéis de pesquisador, engenheiro e projetista de experimentos.
Este pode ser o momento em que senti pela primeira vez verdadeiramente a IAG.
Don't let inexperience stop you from starting to experiment.
Quando a IA pode ajudar pessoas comuns a superar barreiras profissionais, muitos projetos tecnológicos que antes pareciam inatingíveis podem já não estar tão distantes.