Seria ótimo se os sistemas fossem projetados com folga e flexibilidade para conseguirem oferecer boa qualidade. E, sem dúvida, em média isso deve ser mais verdade hoje do que em épocas em que a engenharia organizacional e as metodologias de desenvolvimento eram menos avançadas do que agora.
Ainda assim, aos meus olhos, isso soa como alguém cujo ego como engenheiro é inflado, mas cujo senso de responsabilidade como membro da organização é fraco, tentando justificar que nada disso é culpa sua, e sim erro da diretoria.
Engenheiros civis, designers industriais e animadores não têm prazo de entrega, e são avaliados apenas por criatividade e qualidade, não por produtividade, enquanto só os programadores é que têm prazo?
Pela minha experiência, se a base em CS, especialmente em PLT, for sólida, no fim a pessoa escreve código relativamente melhor em qualquer ambiente.
Mesmo sem um conhecimento tão extraordinário, se a pessoa pelo menos entende os princípios mais básicos, com tempo suficiente e num código com o qual esteja familiarizada, ela consegue produzir uma certa qualidade de código. Se fizer n refatorações, até se a IA escrever, o resultado acaba ficando minimamente convincente.
Por mais tempo que se passe em cima de um único código-fonte, também há muita gente com 20 anos de carreira que só sabe produzir espaguete e nem entende por que não deveria fazer isso.
A menos que seja possível ter um ambiente perfeito com tempo e orçamento infinitos, isso me soa como um conteúdo vazio, sem grande significado. Em qualquer época e em qualquer função, isso não é sempre a mesma coisa?
Escrever código melhor dentro do mesmo sistema é claramente, sim, uma capacidade do engenheiro.
Os textos postados aqui podem estar em um ambiente um pouco diferente de algumas perspectivas ou experiências do mercado nacional de SI, que em geral até ignoram o OCP.
De qualquer forma, Linus Torvalds não é júnior, né...
Gemini:
Sim, no RAG (Retrieval-Augmented Generation), o uso de banco de dados vetorial (Vector Database) teve sua base conceitual estabelecida quando o primeiro artigo relacionado foi publicado em 2020.
O RAG basicamente combina recuperação (Retrieval) e geração (Generation), e nessa etapa de recuperação os embeddings vetoriais e um banco de dados vetorial capaz de armazená-los e consultá-los com eficiência passam a ter um papel essencial.
💡 O ponto de partida do RAG e dos bancos de dados vetoriais
A ideia de que um banco de dados vetorial é necessário no RAG surgiu dos seguintes artigos e conceitos principais.
O nascimento do RAG: artigo de Lewis et al. (2020)
Título do artigo: "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (geração aumentada por recuperação para tarefas de PLN intensivas em conhecimento)
Ponto central: foi nesse artigo que o termo e o framework RAG foram apresentados pela primeira vez.
Papel do Retriever: o modelo RAG proposto no artigo é composto por Retriever e Generator. O Retriever busca documentos (latent documents) relacionados à consulta em grandes conjuntos de dados, como a Wikipédia.
Uso de índice vetorial: esse modelo inicial de RAG usava um índice vetorial (Vector Index) no conjunto de dados para buscar documentos, permitindo que um retriever pré-treinado (pretrained retriever) recuperasse os documentos.
Conclusão: como a etapa central do RAG, a "recuperação", é realizada calculando similaridade com base nas representações vetoriais da consulta e dos documentos, o conceito de um armazenamento vetorial (Vector Store) ou índice vetorial já estava implicitamente incorporado como algo essencial para uma busca eficiente.
Embeddings vetoriais e busca por similaridade
A razão fundamental pela qual um banco de dados vetorial se tornou um elemento essencial do RAG é a seguinte.
Embedding: em um sistema RAG, tanto o conhecimento externo (documentos, texto) quanto a consulta do usuário (pergunta) são convertidos em representações matemáticas chamadas vetores (Vector). Esses vetores representam o significado do texto como um arranjo denso de números em um espaço de alta dimensão.
Busca por similaridade (Similarity Search): encontrar no espaço vetorial os vetores de documentos mais próximos do vetor da consulta significa encontrar os documentos semanticamente mais semelhantes, ou seja, mais relevantes.
Papel do banco de dados vetorial: um banco de dados vetorial é especializado em armazenar essa grande quantidade de vetores de documentos e em localizar de forma rápida e eficiente os vetores mais semelhantes para um vetor de consulta dado. Por isso, ele é indispensável para maximizar o desempenho de recuperação do RAG.
Resumo: por que um banco de dados vetorial é necessário
Para permitir que um LLM acesse conhecimento recente ou específico de um domínio que não foi aprendido no treinamento, é preciso buscar informações com base em similaridade semântica, e não apenas em correspondência de palavras-chave (busca tradicional). O banco de dados vetorial é a tecnologia central que foi naturalmente integrada ao framework RAG para executar com eficiência essa busca baseada em similaridade semântica.
Tem um monte de baboseira aí... esse papo de código ruim ou código bom é coisa que júnior fica discutindo, e o mais importante é: existe ou não existe um sênior que saiba fazer bem o design de software adequado para aquele setor?
Os anúncios são só o começo, e vão oferecer uma experiência de usuário que leva à compra de produtos e serviços. Vai saber. Talvez até passem a oferecer Worldcoin.
Como o orçamento estava folgado, quando a gente acabou tirando a taxa de entrada, a falta de comparecimento ultrapassou a metade. Tem tanta gente que se inscreve sem pensar e nem aparece...
> Não sou desenvolvedor, então não conheço os detalhes internos, mas tenho a impressão de que antigamente software não era feito nem operado desse jeito. Parecia haver mais “adultos” tentando evitar problemas com mais cuidado.
> Levando em conta que todas essas discussões já surgiram inúmeras vezes desde muito tempo atrás, não quero ser pessimista demais
A migração de assembler para linguagens de alto nível, a adoção de OOP, arquitetura de componentes/COM/CORBA, o surgimento do navegador web, a adoção de Java etc.; 2018 não foi o "ponto em que o declínio começou", mas apenas um entre vários pontos de dados que vêm se acumulando desde o passado
Fazendo uma contestação: parece que a pessoa que escreveu o comentário não entendeu a definição do problema de que o texto está falando. A migração para linguagens de alto nível mencionada acima não tem absolutamente nada a ver com as vulnerabilidades do código gerado por IA nem com uma estrutura em que engenheiros sêniores não conseguem surgir. No fim, o próprio comentário da pessoa acabou comprovando o problema apontado no texto principal. O texto está falando da importância da engenharia, mas a pessoa parece só não gostar de engenharia difícil e também não querer aprender, então fica dando desculpas demais. Está falando demais.
No geral, concordo bastante
Especialmente a troca de contexto? Você faz o pedido do prompt e, no tempo de espera, perde o foco, o que acaba reduzindo a produtividade. Talvez isso se resolva se a velocidade dos LLMs aumentar e as respostas vierem de forma imediata
Parece fortemente que o próprio texto já parte de uma conclusão pronta e foi escrito para confirmá-la. A questão da remoção do senso de ownership dos desenvolvedores, independentemente dos LLMs, me soa mais como uma discussão sobre "a era do espírito artesão vs. a era da industrialização".
Também baixei e usei no dia em que foi lançado, e confirmei o mesmo comportamento que os colegas acima.
Como se trata de um erro, acho que vai haver uma correção.
Seja vetor DB ou qualquer outra coisa, no fim das contas provavelmente basta implementar apenas a busca...
Seria ótimo se os sistemas fossem projetados com folga e flexibilidade para conseguirem oferecer boa qualidade. E, sem dúvida, em média isso deve ser mais verdade hoje do que em épocas em que a engenharia organizacional e as metodologias de desenvolvimento eram menos avançadas do que agora.
Ainda assim, aos meus olhos, isso soa como alguém cujo ego como engenheiro é inflado, mas cujo senso de responsabilidade como membro da organização é fraco, tentando justificar que nada disso é culpa sua, e sim erro da diretoria.
Engenheiros civis, designers industriais e animadores não têm prazo de entrega, e são avaliados apenas por criatividade e qualidade, não por produtividade, enquanto só os programadores é que têm prazo?
Pela minha experiência, se a base em CS, especialmente em PLT, for sólida, no fim a pessoa escreve código relativamente melhor em qualquer ambiente.
Mesmo sem um conhecimento tão extraordinário, se a pessoa pelo menos entende os princípios mais básicos, com tempo suficiente e num código com o qual esteja familiarizada, ela consegue produzir uma certa qualidade de código. Se fizer
nrefatorações, até se a IA escrever, o resultado acaba ficando minimamente convincente.Por mais tempo que se passe em cima de um único código-fonte, também há muita gente com 20 anos de carreira que só sabe produzir espaguete e nem entende por que não deveria fazer isso.
A menos que seja possível ter um ambiente perfeito com tempo e orçamento infinitos, isso me soa como um conteúdo vazio, sem grande significado. Em qualquer época e em qualquer função, isso não é sempre a mesma coisa?
Escrever código melhor dentro do mesmo sistema é claramente, sim, uma capacidade do engenheiro.
Os textos postados aqui podem estar em um ambiente um pouco diferente de algumas perspectivas ou experiências do mercado nacional de SI, que em geral até ignoram o OCP.
De qualquer forma, Linus Torvalds não é júnior, né...
Gemini:
Sim, no RAG (Retrieval-Augmented Generation), o uso de banco de dados vetorial (Vector Database) teve sua base conceitual estabelecida quando o primeiro artigo relacionado foi publicado em 2020.
O RAG basicamente combina recuperação (Retrieval) e geração (Generation), e nessa etapa de recuperação os embeddings vetoriais e um banco de dados vetorial capaz de armazená-los e consultá-los com eficiência passam a ter um papel essencial.
💡 O ponto de partida do RAG e dos bancos de dados vetoriais
A ideia de que um banco de dados vetorial é necessário no RAG surgiu dos seguintes artigos e conceitos principais.
A razão fundamental pela qual um banco de dados vetorial se tornou um elemento essencial do RAG é a seguinte.
Resumo: por que um banco de dados vetorial é necessário
Para permitir que um LLM acesse conhecimento recente ou específico de um domínio que não foi aprendido no treinamento, é preciso buscar informações com base em similaridade semântica, e não apenas em correspondência de palavras-chave (busca tradicional). O banco de dados vetorial é a tecnologia central que foi naturalmente integrada ao framework RAG para executar com eficiência essa busca baseada em similaridade semântica.
Tem um monte de baboseira aí... esse papo de código ruim ou código bom é coisa que júnior fica discutindo, e o mais importante é: existe ou não existe um sênior que saiba fazer bem o design de software adequado para aquele setor?
Os anúncios são só o começo, e vão oferecer uma experiência de usuário que leva à compra de produtos e serviços. Vai saber. Talvez até passem a oferecer Worldcoin.
De onde surgiu essa ideia absurda de que RAG precisa de um banco de dados vetorial…
Gostei muito de ler. Espero que continuem publicando haha
Como o orçamento estava folgado, quando a gente acabou tirando a taxa de entrada, a falta de comparecimento ultrapassou a metade. Tem tanta gente que se inscreve sem pensar e nem aparece...
> Não sou desenvolvedor, então não conheço os detalhes internos, mas tenho a impressão de que antigamente software não era feito nem operado desse jeito. Parecia haver mais “adultos” tentando evitar problemas com mais cuidado.
Parece que nem desenvolvedor ele é..
> Levando em conta que todas essas discussões já surgiram inúmeras vezes desde muito tempo atrás, não quero ser pessimista demais
A migração de assembler para linguagens de alto nível, a adoção de OOP, arquitetura de componentes/COM/CORBA, o surgimento do navegador web, a adoção de Java etc.; 2018 não foi o "ponto em que o declínio começou", mas apenas um entre vários pontos de dados que vêm se acumulando desde o passado
Fazendo uma contestação: parece que a pessoa que escreveu o comentário não entendeu a definição do problema de que o texto está falando. A migração para linguagens de alto nível mencionada acima não tem absolutamente nada a ver com as vulnerabilidades do código gerado por IA nem com uma estrutura em que engenheiros sêniores não conseguem surgir. No fim, o próprio comentário da pessoa acabou comprovando o problema apontado no texto principal. O texto está falando da importância da engenharia, mas a pessoa parece só não gostar de engenharia difícil e também não querer aprender, então fica dando desculpas demais. Está falando demais.
O conselho mais importante lá no final é realmente excelente.
No geral, concordo bastante
Especialmente a troca de contexto? Você faz o pedido do prompt e, no tempo de espera, perde o foco, o que acaba reduzindo a produtividade. Talvez isso se resolva se a velocidade dos LLMs aumentar e as respostas vierem de forma imediata
Força, Naver Cloud!
Parece fortemente que o próprio texto já parte de uma conclusão pronta e foi escrito para confirmá-la. A questão da remoção do senso de ownership dos desenvolvedores, independentemente dos LLMs, me soa mais como uma discussão sobre "a era do espírito artesão vs. a era da industrialização".
Que obra de arte.
Também baixei e usei no dia em que foi lançado, e confirmei o mesmo comportamento que os colegas acima. Como se trata de um erro, acho que vai haver uma correção.
Acabei de instalar e testar e, para mim, a separação de jamo não funcionou. Estou usando a versão Tahoe (26.0.1).
É fácil criticar. Então traga algo diferente e prove.