É realmente muito interessante, mas dá um pouco de medo pensar que quem fez isso não foi nem o governo nem uma empresa como o Google
Dá para sentir como o mundo está transbordando de dados
"O CTO da Amplitude, Wade Chambers, mostrou de forma experimental a alguns colegas a ferramenta de IA que criou internamente"
Assim como no post da Naver mencionado nos materiais da apresentação do Ha Yong-ho, parece que a transformação com IA também precisa de intenção ou metas no nível C-level para se espalhar bem por toda a empresa.
Se for um líder organizacional com compreensão profunda e visão, ok, mas quando entra essa postura de AI resolve tudo por parte de líderes que ficam fazendo joguinho de números por causa de custo??? Dá até para ouvir as pessoas sendo moídas ;_;
Ah, eu também fiz algo parecido!
É um serviço que traduz e resume posts do Hacker News para coreano com IA e os envia para um canal no Telegram.
Se eu soubesse que isso já existia, não teria feito.. haha. Assinei!
Dizem que, se adotarmos IA, a produtividade dobra, mas aí também dobram o trabalho... o salário continua o mesmo e, pior, nem ajudam a cobrir os custos da IA...
Ótima observação, obrigado. Como você mencionou, acredito que não é adequado para casos de uso de RDB e que deve ser entendido como uma posição para mecanismos de busca (Elasticsearch) e DB de vetor (Pinecone). Internamente também utilizamos o Lucene, comprovadamente estável ao longo de muito tempo, para suportar funções como indexação, classificação e agregação. Obrigado :)
Como você mencionou, parece que, em vez de um banco de dados de uso geral, isso poderá ser uma solução que pode ser usada como "serverless de verdade" em situações específicas.
Não esperava receber uma resposta em coreano! (Acabei escrevendo de forma bem cínica...)
Eu inicialmente pensei que era uma ideia revolucionária. Na verdade, o maior problema dos bancos de dados serverless é que há um servidor real sendo executado em um local em que isso não fica aparente. Então, quando o tráfego aumenta demais, ocorre a situação de indisponibilidade até que aquele servidor seja alocado (cerca de 5 minutos). Por isso, é difícil usar DBs serverless existentes em nuvem (AWS etc.) em nível de produção.
Pensei em testar, mas a razão da preocupação era esta: então teríamos que implementar a lógica binária de indexação, ordenação etc., que já foi feita no MySQL, PostgreSQL, e assim por diante. Pensei em como seria difícil reconstruir sobre o Lambda um projeto de banco de dados open source confiável.
Já que vocês estão criando diretamente o produto, espero que ele evolua bastante~!
Obrigado pelo ótimo feedback. O ponto que você mencionou, de que é necessário um estado para reduzir a latência, captura perfeitamente um dos trade-offs centrais da nossa arquitetura.
Primeiro, quanto à latência de consulta, em nossos benchmarks o p99 (99º percentil) fica em torno de 130–210 ms. Acho que a observação sobre uma diferença de 100x provavelmente veio da situação limite citada no texto — que o cold start pode levar alguns segundos. Como você destacou, essa parte é claramente uma desvantagem da nossa arquitetura, e como mencionado no texto, ela ocorre em menos de 0,01% do total (P99.99) em ambiente de produção. Fora isso, a maioria das consultas foi projetada para usar o cache da memória local e do disco de cada Lambda, garantindo desempenho estável.
Portanto, como você disse, essa arquitetura pode não ser adequada para sistemas de transação financeira de latência ultrabaixa onde todas as consultas precisariam ficar abaixo de 10 ms. Porém, para a maioria das aplicações de busca e recomendação baseadas em IA, uma latência de 100–200 ms no P99 é um desempenho suficientemente bom, e acredito que o ganho de reduzir em mais de 90% os custos de infraestrutura e a sobrecarga operacional é muito maior.
Agradeço novamente pela sua contribuição aprofundada.
É realmente muito interessante, mas dá um pouco de medo pensar que quem fez isso não foi nem o governo nem uma empresa como o Google
Dá para sentir como o mundo está transbordando de dados
Como o código foi disponibilizado publicamente, acho que pode ser útil dar uma olhada nele!
"O CTO da Amplitude, Wade Chambers, mostrou de forma experimental a alguns colegas a ferramenta de IA que criou internamente"
Assim como no post da Naver mencionado nos materiais da apresentação do Ha Yong-ho, parece que a transformação com IA também precisa de intenção ou metas no nível C-level para se espalhar bem por toda a empresa.
Se for um líder organizacional com compreensão profunda e visão, ok, mas quando entra essa postura de AI resolve tudo por parte de líderes que ficam fazendo joguinho de números por causa de custo??? Dá até para ouvir as pessoas sendo moídas ;_;
Na primeira linha do texto, há um link de imagem bem organizado e fácil de visualizar de relance.
Não concordo muito; parece um truque que só funciona em circunstâncias bem específicas.
Ah, eu também fiz algo parecido!
É um serviço que traduz e resume posts do Hacker News para coreano com IA e os envia para um canal no Telegram.
Se eu soubesse que isso já existia, não teria feito.. haha. Assinei!
https://t.me/hnaisummarykr
Talvez, do que isso se trata?
Tenho curiosidade sobre como vocês verificaram a execução local.
Nos comentários do Hacker News e também no fórum LocalLLaMA do Reddit, parece que o GLM está sendo bem elogiado
GLM 4.5 AIR IS SO FKING GOODDD
Ah..
Dizem que, se adotarmos IA, a produtividade dobra, mas aí também dobram o trabalho... o salário continua o mesmo e, pior, nem ajudam a cobrir os custos da IA...
Ótima observação, obrigado. Como você mencionou, acredito que não é adequado para casos de uso de RDB e que deve ser entendido como uma posição para mecanismos de busca (Elasticsearch) e DB de vetor (Pinecone). Internamente também utilizamos o Lucene, comprovadamente estável ao longo de muito tempo, para suportar funções como indexação, classificação e agregação. Obrigado :)
Como você mencionou, parece que, em vez de um banco de dados de uso geral, isso poderá ser uma solução que pode ser usada como "serverless de verdade" em situações específicas.
Não esperava receber uma resposta em coreano! (Acabei escrevendo de forma bem cínica...)
Eu inicialmente pensei que era uma ideia revolucionária. Na verdade, o maior problema dos bancos de dados serverless é que há um servidor real sendo executado em um local em que isso não fica aparente. Então, quando o tráfego aumenta demais, ocorre a situação de indisponibilidade até que aquele servidor seja alocado (cerca de 5 minutos). Por isso, é difícil usar DBs serverless existentes em nuvem (AWS etc.) em nível de produção.
Pensei em testar, mas a razão da preocupação era esta: então teríamos que implementar a lógica binária de indexação, ordenação etc., que já foi feita no MySQL, PostgreSQL, e assim por diante. Pensei em como seria difícil reconstruir sobre o Lambda um projeto de banco de dados open source confiável.
Já que vocês estão criando diretamente o produto, espero que ele evolua bastante~!
Obrigado, com certeza vai ajudar bastante ✌️
No começo eu tinha montado com n8n, mas depois migrei para AWS Lambda + @ 🙇♂️
Estou gerenciando assim kkk
Recomendo tentar fazer uma vez, é divertido 👍
Obrigado pelo ótimo feedback. O ponto que você mencionou, de que é necessário um estado para reduzir a latência, captura perfeitamente um dos trade-offs centrais da nossa arquitetura.
Primeiro, quanto à latência de consulta, em nossos benchmarks o p99 (99º percentil) fica em torno de 130–210 ms. Acho que a observação sobre uma diferença de 100x provavelmente veio da situação limite citada no texto — que o cold start pode levar alguns segundos. Como você destacou, essa parte é claramente uma desvantagem da nossa arquitetura, e como mencionado no texto, ela ocorre em menos de 0,01% do total (P99.99) em ambiente de produção. Fora isso, a maioria das consultas foi projetada para usar o cache da memória local e do disco de cada Lambda, garantindo desempenho estável.
Portanto, como você disse, essa arquitetura pode não ser adequada para sistemas de transação financeira de latência ultrabaixa onde todas as consultas precisariam ficar abaixo de 10 ms. Porém, para a maioria das aplicações de busca e recomendação baseadas em IA, uma latência de 100–200 ms no P99 é um desempenho suficientemente bom, e acredito que o ganho de reduzir em mais de 90% os custos de infraestrutura e a sobrecarga operacional é muito maior.
Agradeço novamente pela sua contribuição aprofundada.
Como tem 65 GB... é uma pena T_T
Eu também pensei em tentar fazer, mas acabei não conseguindo.. haha
Por acaso foi montado com n8n??