Eu também pensei na questão do custo, e pelo visto ele realmente varia bastante conforme a resolução da imagem de entrada. E eu nem tinha pensado na relação entre o tamanho da imagem de entrada e a velocidade de processamento, então achei isso bem interessante. Ao fazer o crop, a velocidade de processamento também aumenta.
E o ganho de precisão é realmente impressionante!
O desempenho dos VLMs melhorou muito, mas mesmo assim eles ainda não conseguem superar o desempenho de um modelo YOLO treinado para um único objetivo?
Obrigado por registrar em texto o know-how que você adquiriu em situações reais.
Se eu me deparar com um problema parecido, com certeza vou consultar os métodos que você usou.
Eu também tenho sentido muito isso ultimamente..
Acho que muitos textos de blogs não estão sendo escritos com base na própria experiência da pessoa + ajuda de IA.
Os textos são lógicos demais e escritos de um jeito muito fácil de ler.
1) Dúvidas sobre a credibilidade do texto: tem cheiro de marketing/conteúdo gerado por IA
Resumo
“Isso está arrumadinho demais, quase como uma peça com moral da história” → gerou suspeita de que o texto foi otimizado para o tipo de ‘conto moral’ que o HN gosta
O corpo do texto está cheio de links para material pago, então muita gente reagiu com “no fim das contas isso não é só um texto de vendas?”
O estilo com listas em excesso/emojis foi apontado como sinal de “AI slop” (conteúdo de IA feito nas coxas)
Citação contundente (tradução)
“Parece que o texto inteiro existe só para te vender os materiais linkados. E passa uma vibe de AI slop com todas essas listas.”
(original: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)
Resumo em uma linha
“Antes mesmo de discutir se o conteúdo está certo ou errado, o cheiro de venda + cheiro de IA está forte demais” foi a reação nº 1.
2) Críticas à liderança/arquitetura: o problema não era técnico, era a ‘estrutura de decisão’
Resumo
Muita gente reagiu com “arquiteto em um time de 4 pessoas?” como sinal de que já começou torto
Em especial, houve muita crítica ao arquiteto que não programa / função de DevOps separada, vistos como “gargalo + otimização de currículo”
O tom era de que o que quase afundou a empresa não foi microservices, e sim uma estrutura em que “ninguém assume de fato deploy/operação/incêndio”
Citação afiada (tradução)
“Arquitetos cujo trabalho é definir ‘regras’ e ‘padrões’ sem de fato implementar nada quase sempre são uma péssima ideia. Foquem em entregar logo... Quem não vai escrever nem 10 linhas de código não pode monopolizar as decisões.”
(original: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)
Resumo em uma linha
Foi forte a visão de que o problema não era MSA, e sim um desenho de papéis com poder de decisão, mas sem responsabilidade.
3) Perspectiva de negócio: a startup realmente quase morreu por causa de MSA?
Resumo
Houve comentários que simplesmente não compraram a narrativa de “quase morremos por causa da arquitetura”
Ponto central: se PMF/demanda/lock-in de clientes são fracos, qualquer stack vai fracassar
Em especial, detalhes como “o cliente vai embora só porque ficou dois dias mais lento?” foram usados para questionar se o valor do produto já não era fraco desde o início
Também apontaram contradições internas do texto: “MSA matou a startup” mas no fim “ela sobreviveu?” → suspeita de dramatização da narrativa
Citação contundente (tradução)
“Tenho quase certeza de que o que matou a startup foi fazer um produto que as pessoas não queriam. Isso é tão sem sentido quanto dizer que Python vs Go matou a startup...”
(original: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)
Resumo em uma linha
Existe claramente a visão de que arquitetura é desculpa, e que a causa real pode ter sido mercado/produto/fluxo de caixa.
4) Insight técnico: conselhos práticos baseados em experiência sobre monólito vs MSA (a parte realmente útil)
Resumo
“MSA cobra um imposto fixo de complexidade operacional” → vários relatos dizem que isso pode ser fatal para times pequenos
Palavras-chave centrais: Premature distribution (distribuição cedo demais), monólito modular/modulith, “ganhe seus limites (boundaries)”
Também apareceram condições realistas para quando MSA faz sentido: quando o time cresce e problemas reais de conflito/deploy/organização começam a aparecer
Por outro lado, houve o conselho de que problemas de performance/escala geralmente não se resolvem com “vamos para MSA”, e que o melhor é olhar primeiro para algoritmo/gargalos/sharding/partitioning
Citação afiada (tradução)
“O que quase matou a startup não foram microservices, e sim a ‘distribuição cedo demais’. Vocês dividiram antes de existirem limites reais e só pagaram o custo de latência/coordenação. Comecem com um monólito modular, ganhem seus limites e só então extraiam.”
(original: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)
Resumo em uma linha
A lição com que a comunidade realmente concordou foi esta: “Comece com um monólito e só separe serviços quando os limites surgirem de forma ‘natural’.”
Avaliação geral da comunidade em uma frase
A maioria concordou com “nós não somos a Netflix”, mas ao mesmo tempo houve forte suspeita de que o próprio texto possa ser uma narrativa vendendo a doença de querer ser a Netflix (= marketing/IA).
Acho que a expressão "transformar em um problema estrutural" pode ter soado um pouco abstrata.
O que eu quis dizer no texto foi:
Before: "rotulagem = entrada de pessoas = custo proporcional"
After: "rotulagem = pipeline = custo variável minimizado após a construção inicial"
Ou seja, o problema deixou de ser um custo pontual e passou a ser um problema de construção de sistema.
A expressão "criamos um novo modelo de trabalho" também está correta!
Mais precisamente, acho que dá para dizer que "substituímos o trabalho humano por um pipeline de software" rsrs
Concordo com o ponto que você mencionou. É uma observação válida que um VLM tem desempenho melhor que o YOLO, mas informações importantes podem se perder por causa de erros de julgamento do YOLO. Ainda assim, incluímos a etapa de recorte pelos motivos abaixo.
Primeiro, a questão do custo. Se usarmos a imagem inteira diretamente no VLM, o custo aumenta rapidamente por causa do processamento de imagens em alta resolução. Esse foi o principal motivo para introduzir o recorte.
Segundo, a questão da velocidade de processamento.
Para processar um dataset de grande volume em um tempo viável, esse ganho de velocidade era indispensável.
Terceiro, a melhoria de precisão.
O recorte, na verdade, aumenta a precisão de julgamento do VLM. Na imagem completa, podem aparecer juntos fundos complexos, vários personagens, textos, enfeites etc., o que pode confundir o VLM sobre qual objeto ele deve avaliar. Por exemplo, pode surgir a ambiguidade entre um personagem em um pôster no fundo, a boneca principal ou outro personagem ao lado. Já com o recorte, apenas o objeto-alvo fica claramente isolado, permitindo que o VLM se concentre somente nele ao fazer a avaliação.
Claro, isso não resolve completamente os problemas de falsos negativos e falsos positivos do YOLO. Mas mitigamos isso definindo o confidence threshold do YOLO em 0.5 para aumentar o recall e, depois, filtrando os falsos positivos nas etapas de filtragem com CLIP e verificação com o Verifier. Além disso, como lidamos com dados em grande volume, mesmo que ocorram alguns falsos negativos, ainda conseguimos garantir estatisticamente uma quantidade suficiente de dados de alta qualidade.
No fim, o objetivo era construir um pipeline prático encontrando um ponto de equilíbrio entre custo, velocidade e precisão, e a etapa de recorte trouxe efeitos positivos em todos esses três aspectos.
Olá, winterjung, obrigado pelo interesse no meu trabalho. Para a confiabilidade, uso o valor de confidence retornado diretamente pelo VLM (GPT-4o). Como você mencionou, existe a limitação de que a base de cálculo do confidence do GPT-4o é pouco clara e não pode ser reproduzida. Ainda assim, de uma perspectiva prática, parti da premissa de que o confidence retornado pelo VLM é razoavelmente preciso e implementei a etapa final de verificação (Verifier) para decidir, com base em um threshold, se a validação deve ou não ser realizada.
Eu realmente não fazia ideia de que os tokens de entrada de imagem do modelo got-4o-mini eram caros demais. Obrigado por me avisar. Já apliquei isso no código na hora haha
Este é um texto que explica a arquitetura de como o produto é realmente composto.
Aproveitando que estabilizei na versão 1.0 e organizei a documentação, resolvi também organizar este texto.
Também é uma boa migrar de vez para a linguagem C3. Como é um projeto que mantém a sintaxe de C com mudanças mínimas e adiciona recursos modernos, a transição também é fácil.
Pelo título, acho que vocês provavelmente nem clicariam… mas, entre os textos sobre as relações entre EUA e China que li recentemente, este foi o mais interessante.
Todo ano sai em novembro, mas este ano acabei compartilhando um pouco mais tarde
Previsões tecnológicas do CTO da Amazon para depois de 2025
Previsões tecnológicas do CTO da Amazon para depois de 2024
Previsões tecnológicas do CTO da Amazon para depois de 2023
Previsões tecnológicas do CTO da Amazon para depois de 2022
O que eu queria dizer é que este texto parece muito gerado por IA e não tem referências, então acho melhor não compartilharem esse tipo de conteúdo.
Excelente ^^
Obrigado pela resposta.
Eu também pensei na questão do custo, e pelo visto ele realmente varia bastante conforme a resolução da imagem de entrada. E eu nem tinha pensado na relação entre o tamanho da imagem de entrada e a velocidade de processamento, então achei isso bem interessante. Ao fazer o crop, a velocidade de processamento também aumenta.
E o ganho de precisão é realmente impressionante!
O desempenho dos VLMs melhorou muito, mas mesmo assim eles ainda não conseguem superar o desempenho de um modelo YOLO treinado para um único objetivo?
Obrigado por registrar em texto o know-how que você adquiriu em situações reais.
Se eu me deparar com um problema parecido, com certeza vou consultar os métodos que você usou.
Eu também tenho sentido muito isso ultimamente..
Acho que muitos textos de blogs não estão sendo escritos com base na própria experiência da pessoa + ajuda de IA.
Os textos são lógicos demais e escritos de um jeito muito fácil de ler.
Hum... acho que tem algo estranho aqui.
Parece que este texto foi escrito por IA.
1) Dúvidas sobre a credibilidade do texto: tem cheiro de marketing/conteúdo gerado por IA
Resumo
Citação contundente (tradução)
Resumo em uma linha
2) Críticas à liderança/arquitetura: o problema não era técnico, era a ‘estrutura de decisão’
Resumo
Citação afiada (tradução)
Resumo em uma linha
3) Perspectiva de negócio: a startup realmente quase morreu por causa de MSA?
Resumo
Citação contundente (tradução)
Resumo em uma linha
4) Insight técnico: conselhos práticos baseados em experiência sobre monólito vs MSA (a parte realmente útil)
Resumo
Citação afiada (tradução)
Resumo em uma linha
“Comece com um monólito e só separe serviços quando os limites surgirem de forma ‘natural’.”
Avaliação geral da comunidade em uma frase
A maioria concordou com “nós não somos a Netflix”, mas ao mesmo tempo houve forte suspeita de que o próprio texto possa ser uma narrativa vendendo a doença de querer ser a Netflix (= marketing/IA).
Porque os EUA ainda têm IPv4 suficiente. Aqui no nosso país também é assim.
Os roteadores iptime não oferecem suporte a IPv6, né.
Quando vejo o preço do IPv4, só dá vontade de suspirar, mas já é suficiente...
É mais utilizável do que parece, mas acabo não usando porque o suporte de terceiros é melhor no Mac.. haha
Ótima observação, obrigado!
Acho que a expressão "transformar em um problema estrutural" pode ter soado um pouco abstrata.
O que eu quis dizer no texto foi:
Before: "rotulagem = entrada de pessoas = custo proporcional"
After: "rotulagem = pipeline = custo variável minimizado após a construção inicial"
Ou seja, o problema deixou de ser um custo pontual e passou a ser um problema de construção de sistema.
A expressão "criamos um novo modelo de trabalho" também está correta!
Mais precisamente, acho que dá para dizer que "substituímos o trabalho humano por um pipeline de software" rsrs
Olá, obrigado por ler o texto com interesse!
Concordo com o ponto que você mencionou. É uma observação válida que um VLM tem desempenho melhor que o YOLO, mas informações importantes podem se perder por causa de erros de julgamento do YOLO. Ainda assim, incluímos a etapa de recorte pelos motivos abaixo.
Primeiro, a questão do custo. Se usarmos a imagem inteira diretamente no VLM, o custo aumenta rapidamente por causa do processamento de imagens em alta resolução. Esse foi o principal motivo para introduzir o recorte.
Segundo, a questão da velocidade de processamento.
Para processar um dataset de grande volume em um tempo viável, esse ganho de velocidade era indispensável.
Terceiro, a melhoria de precisão.
O recorte, na verdade, aumenta a precisão de julgamento do VLM. Na imagem completa, podem aparecer juntos fundos complexos, vários personagens, textos, enfeites etc., o que pode confundir o VLM sobre qual objeto ele deve avaliar. Por exemplo, pode surgir a ambiguidade entre um personagem em um pôster no fundo, a boneca principal ou outro personagem ao lado. Já com o recorte, apenas o objeto-alvo fica claramente isolado, permitindo que o VLM se concentre somente nele ao fazer a avaliação.
Claro, isso não resolve completamente os problemas de falsos negativos e falsos positivos do YOLO. Mas mitigamos isso definindo o confidence threshold do YOLO em 0.5 para aumentar o recall e, depois, filtrando os falsos positivos nas etapas de filtragem com CLIP e verificação com o Verifier. Além disso, como lidamos com dados em grande volume, mesmo que ocorram alguns falsos negativos, ainda conseguimos garantir estatisticamente uma quantidade suficiente de dados de alta qualidade.
No fim, o objetivo era construir um pipeline prático encontrando um ponto de equilíbrio entre custo, velocidade e precisão, e a etapa de recorte trouxe efeitos positivos em todos esses três aspectos.
Olá, winterjung, obrigado pelo interesse no meu trabalho. Para a confiabilidade, uso o valor de
confidenceretornado diretamente pelo VLM (GPT-4o). Como você mencionou, existe a limitação de que a base de cálculo doconfidencedo GPT-4o é pouco clara e não pode ser reproduzida. Ainda assim, de uma perspectiva prática, parti da premissa de que oconfidenceretornado pelo VLM é razoavelmente preciso e implementei a etapa final de verificação (Verifier) para decidir, com base em um threshold, se a validação deve ou não ser realizada.Eu realmente não fazia ideia de que os tokens de entrada de imagem do modelo got-4o-mini eram caros demais. Obrigado por me avisar. Já apliquei isso no código na hora haha
Parece que está criticando só por criticar
Este é um texto que explica a arquitetura de como o produto é realmente composto.
Aproveitando que estabilizei na versão 1.0 e organizei a documentação, resolvi também organizar este texto.
Também é uma boa migrar de vez para a linguagem C3. Como é um projeto que mantém a sintaxe de C com mudanças mínimas e adiciona recursos modernos, a transição também é fácil.
É o texto explicativo de Show GN: 자연어 명령을 Intent → Effect → Snapshot으로 실행하는 AI Task 데모, que você publicou no ShowGN.
Pelo título, acho que vocês provavelmente nem clicariam… mas, entre os textos sobre as relações entre EUA e China que li recentemente, este foi o mais interessante.
Isso é interessante...