Você acha que quanto mais você registra, mais você melhora — mas na verdade está cavando uma armadilha.
Hoje li o artigo do time do Google sobre o WikiSkill e, juntando com a minha experiência ao construir um sistema quantitativo, fiquei profundamente tocado.
━━━ A essência do artigo em uma frase ━━━
A falha deve se tornar um ativo permanente, mas a estratégia de execução precisa poder ser revisada.
A maioria das pessoas (inclusive eu) comete o mesmo erro: mistura “por que falhou” com “o que fazer na próxima vez” na hora de registrar. A causa da falha de hoje vai para as anotações; amanhã você ajusta a abordagem, mas não atualiza as anotações; depois de um mês, simplesmente nem sabe o que estava pensando.
No artigo, houve um dado que me chocou: um modelo pequeno de 9B com um manual estruturado, simplesmente derrubou um modelo “cru” de 27B. No modelo de 27B com manual, em algumas tarefas o desempenho disparou de 40% para 81%. A diferença de parâmetros não é tão grande quanto a diferença em “como o conhecimento é organizado”.
━━━ Uma ainda mais cruel ━━━
Para evitar que o pequeno modelo dê errado, os patches conservadores escritos por ele podem derrubar um modelo top de 50% para 18%.
Eu verifiquei isso na prática no meu próprio sistema de trading. No começo, quando a amostra tinha apenas 4 entradas, eu bloqueei uma direção de estratégia. O resultado foi que essa “regra de proteção” pode ter interceptado todas as oportunidades valiosas que poderiam existir. Com 4 amostras, estatisticamente não faz sentido, mas ela sobreviveu como “regra” e continuou rodando no sistema.
━━━ O que eu mudei ━━━
Eu separei todos os registros em três camadas:
Trajetórias originais → arquivamento somente leitura, sem modificação
Cognição sobre os tropeços → apenas adicionar, nunca remover; fica preservada permanentemente
Manual de execução → corrigível a qualquer momento; permite rollback
Ao mesmo tempo, dei etiquetas de tamanho de amostra para todas as regras. n<30 recebe um aviso; n<10 sofre rebaixamento forçado — não é excluir, é impedir que dispare decisões de forma independente.
━━━ Lembre-se disso ━━━
A abordagem pode falhar, mas o entendimento sobre a falha não pode desaparecer junto.
#量化交易 #交易系统 #Gestão do conhecimento
Hoje li o artigo do time do Google sobre o WikiSkill e, juntando com a minha experiência ao construir um sistema quantitativo, fiquei profundamente tocado.
━━━ A essência do artigo em uma frase ━━━
A falha deve se tornar um ativo permanente, mas a estratégia de execução precisa poder ser revisada.
A maioria das pessoas (inclusive eu) comete o mesmo erro: mistura “por que falhou” com “o que fazer na próxima vez” na hora de registrar. A causa da falha de hoje vai para as anotações; amanhã você ajusta a abordagem, mas não atualiza as anotações; depois de um mês, simplesmente nem sabe o que estava pensando.
No artigo, houve um dado que me chocou: um modelo pequeno de 9B com um manual estruturado, simplesmente derrubou um modelo “cru” de 27B. No modelo de 27B com manual, em algumas tarefas o desempenho disparou de 40% para 81%. A diferença de parâmetros não é tão grande quanto a diferença em “como o conhecimento é organizado”.
━━━ Uma ainda mais cruel ━━━
Para evitar que o pequeno modelo dê errado, os patches conservadores escritos por ele podem derrubar um modelo top de 50% para 18%.
Eu verifiquei isso na prática no meu próprio sistema de trading. No começo, quando a amostra tinha apenas 4 entradas, eu bloqueei uma direção de estratégia. O resultado foi que essa “regra de proteção” pode ter interceptado todas as oportunidades valiosas que poderiam existir. Com 4 amostras, estatisticamente não faz sentido, mas ela sobreviveu como “regra” e continuou rodando no sistema.
━━━ O que eu mudei ━━━
Eu separei todos os registros em três camadas:
Trajetórias originais → arquivamento somente leitura, sem modificação
Cognição sobre os tropeços → apenas adicionar, nunca remover; fica preservada permanentemente
Manual de execução → corrigível a qualquer momento; permite rollback
Ao mesmo tempo, dei etiquetas de tamanho de amostra para todas as regras. n<30 recebe um aviso; n<10 sofre rebaixamento forçado — não é excluir, é impedir que dispare decisões de forma independente.
━━━ Lembre-se disso ━━━
A abordagem pode falhar, mas o entendimento sobre a falha não pode desaparecer junto.
#量化交易 #交易系统 #Gestão do conhecimento