Técnicas

A geração aumentada por recuperação (RAG) é o padrão preferido por nossas equipes para melhorar a qualidade das respostas geradas por um modelo de linguagem de grande porte (LLM). A técnica tem sido utilizada com sucesso em diversos projetos, incluindo a popular plataforma de IA Jugalbandi AI. Com a RAG, informações sobre documentos relevantes e confiáveis - em formatos como HTML e PDF - são armazenadas em bancos de dados que suportam um tipo de dados vetoriais ou pesquisa eficiente de documentos, como pgvector, Qdrant ou Elasticsearch Relevance Engine. Para um comando específico, o banco de dados é consultado para recuperar documentos relevantes, que são então combinados com o prompt para fornecer um contexto mais rico para o LLM. Isso resulta em saídas de alta qualidade e numa grande redução de alucinações (respostas irrelevantes). A janela de contexto - que determina o tamanho máximo da entrada do LLM - é limitada, o que significa que selecionar os documentos mais relevantes é crucial. Melhoramos a relevância do conteúdo que é adicionado ao comando por meio de uma nova classificação. Da mesma forma, os documentos geralmente são grandes demais para calcular um embedding, o que significa que eles devem ser divididos em partes menores. Esse costuma ser um problema complexo, e uma abordagem é fazer com que as partes se sobreponham até certo ponto.

O Backstage da Spotify tem sido amplamente adotado por nossas clientes como a plataforma preferida para hospedar portais de experiência da pessoa desenvolvedora. O Backstage, por si só, é apenas um shell que hospeda plugins e fornece uma interface para gerenciar o catálogo de ativos que compõem o ecossistema de uma plataforma. Toda entidade a ser exibida ou gerenciada pelo Backstage é configurada no arquivo catalog-info, que contém dados como status, ciclo de vida, dependências e APIs, entre outros detalhes. Por padrão, os descritores individuais de entidade são escritos manualmente e geralmente mantidos e versionados pela equipe responsável pelo componente em questão. Manter os descritores atualizados pode ser tedioso e criar uma barreira para a adoção por parte das pessoas desenvolvedoras. Além disso, há sempre a possibilidade de alterações serem negligenciadas ou de alguns componentes serem completamente perdidos. Consideramos a geração automática de descritores de entidade Backstage uma forma mais eficiente e menos propensa a erros. A maioria das organizações possui fontes de informação existentes que podem impulsionar o processo de preenchimento de entradas do catálogo. Boas práticas de desenvolvimento — por exemplo, incluir tags apropriadas em recursos AWS ou adicionar metadados aos arquivos de código fonte — podem simplificar a descoberta de entidades e a geração de descritores. Esses processos automatizados podem então ser executados regularmente - uma vez ao dia, por exemplo - para manter o catálogo atualizado.

Os modelos de linguagem de grande porte (LLMs) são as facas suíças do processamento de linguagem natural (PLN). Porém, eles também são caros e nem sempre são a melhor ferramenta para o tarefa - às vezes, é mais eficaz usar uma tampa mais adequada. De fato, há muito potencial em combinar PLN tradicionais com LLMs , ou construir abordagens de PLN múltiplas em conjunto com LLMs para implementar casos de uso e alavancar suas capacidades para as etapas realmente necessárias. Abordagens tradicionais de ciência de dados e PLN para agrupamento de documentos, identificação e classificação de tópicos e até mesmo sumarização são mais baratas e podem ser mais eficazes para resolver parte do problema do seu caso de uso. Em seguida, usamos LLMs quando precisamos gerar e resumir textos longos, ou combinar vários documentos grandes, para aproveitar a atenção e memória superiores do LLM. Por exemplo, usamos com sucesso essa combinação de técnicas para gerar um relatório de tendências abrangente para um domínio a partir de um grande corpus de documentos de tendências individuais, utilizando agrupamento tradicional juntamente com o poder de geração de LLMs.

A conformidade contínua é a prática de garantir, de forma contínua e com alto grau de automatização, que os processos e tecnologias de desenvolvimento de software estejam em conformidade com regulamentações da indústria e padrões de segurança. Verificar manualmente as vulnerabilidades de segurança e aderir a regulamentações pode retardar o desenvolvimento e introduzir erros. Como alternativa, as organizações podem automatizar verificações e auditorias de conformidade. Elas podem integrar ferramentas aos pipelines de desenvolvimento de software, permitindo às equipes detectar e abordar problemas de conformidade desde o início do processo. A codificação de regras de conformidade e melhores práticas auxilia na aplicação consistente de políticas e padrões em todas as equipes. Isso permite a verificação de alterações de código em busca de vulnerabilidades, a aplicação de padrões de codificação e o rastreamento de alterações na configuração da infraestrutura para garantir que atendam aos requisitos de compliance. Por fim, a geração automatizada de relatórios dos itens acima simplifica as auditorias e fornece evidências claras de conformidade. Já discutimos técnicas como a publicação de SBOMs e a aplicação das recomendações do SLSA — elas podem ser excelentes pontos de partida. Os benefícios dessa técnica são múltiplos. Primeiramente, a automação leva a softwares mais seguros ao identificar e mitigar vulnerabilidades precocemente. Em segundo lugar, os ciclos de desenvolvimento se aceleram com a eliminação de tarefas manuais. Custos reduzidos e consistência aprimorada são vantagens adicionais. Para as indústrias críticas à segurança, como a de veículos guiados por software, a conformidade contínua automatizada pode melhorar a eficiência e a confiabilidade do processo de certificação, resultando em veículos mais seguros e confiáveis nas estradas.

Embora não seja um conceito novo, temos observado a crescente disponibilidade e adoção da execução descentralizada de código por meio de redes de distribuição de conteúdo (CDNs). Serviços como Funções de Edge do Cloudflare Workers ou do Amazon CloudFront Edge Functions fornecem um mecanismo para executar trechos de código sem servidor próximos à localização geográfica da pessoa usuária. As funções de edge não apenas oferecem menor latência se uma resposta puder ser gerada na borda da rede, mas também apresentam a oportunidade de reescrever requisições e respostas de maneira específica para cada localidade, à medida que elas trafegam de e para o servidor regional. Por exemplo, você pode reescrever a URL de uma requisição para rotear para um servidor específico que possui dados locais relevantes a um campo encontrado no corpo da requisição. Essa abordagem é mais adequada para processos sem estado, curtos e de execução rápida, pois a capacidade computacional na borda é limitada.

Os Campeões em segurança são membros da equipe que pensam criticamente sobre as repercussões de segurança em decisões de entrega técnicas e não técnicas. Eles levantam essas questões e preocupações com a liderança da equipe e possuem um sólido entendimento das diretrizes e requisitos básicos de segurança. Eles ajudam as equipes de desenvolvimento a abordar todas as atividades durante a entrega de software com uma mentalidade de segurança, reduzindo assim os riscos gerais de segurança para os sistemas que desenvolvem. Um campeão de segurança não é uma posição separada, mas uma responsabilidade atribuída a um membro existente da equipe, orientado por treinamento apropriado de profissionais de segurança. Equipados com esse treinamento, os campeões de segurança melhoram a consciência de segurança da equipe disseminando conhecimento e atuando como uma ponte entre as equipes de desenvolvimento e segurança. Um ótimo exemplo de atividade que os campeões de segurança podem ajudar a impulsionar dentro da equipe é a modelagem de ameaças, que auxilia as equipes a pensar nos riscos de segurança desde o início do projeto. Indicar e treinar um campeão de segurança na equipe é um ótimo primeiro passo, mas confiar apenas nos campeões sem o comprometimento adequado dos líderes pode levar a problemas. Construir uma mentalidade de segurança, em nossa experiência, requer comprometimento de toda a equipe e gerentes.

Text to SQL é uma técnica que converte as consultas feitas em linguagem natural para consultas e SQL executáveis por um banco de dados. Embora os modelos de linguagem de grande porte (LLMs) consigam entender e transformar linguagem natural, criar um SQL preciso para o seu próprio esquema pode ser desafiador. É neste ponto que entra o Vanna, um framework de código aberto em geração aumentada por recuperação (RAG) em Python para geração de SQL. O Vanna funciona em duas etapas: primeiro você cria embeddings com as instruções da linguagem de definição de dados (DDLs) e amostras de SQL para o seu esquema, e depois formula perguntas em linguagem natural. Ainda que o o Vanna funcione com qualquer LLM, incentivamos a avaliação do NSQL, um LLM específico de domínio para tarefas de texto para SQL.

Estamos observando que as equipes estão melhorando seu ecossistema ao tratar a classificação de saúde da mesma forma que outros objetivos de nível de serviço (SLO) e priorizando as melhorias de acordo, em vez de se concentrarem apenas no rastreamento da dívida técnica. Ao alocar recursos de forma eficiente para resolver os problemas de maior impacto relacionados à saúde, as equipes e organizações podem reduzir os custos de manutenção de longo prazo e evoluir os produtos de forma mais eficiente. Essa abordagem também aprimora a comunicação entre stakeholders técnicos e não técnicos, promovendo uma compreensão comum do estado do sistema. Embora as métricas possam variar entre as organizações (veja este post do blog para exemplos), elas contribuem para a sustentabilidade de longo prazo e garantem que o software permaneça adaptável e competitivo. Em um cenário digital em constante mudança, rastrear a saúde em vez da dívida técnica dos sistemas fornece uma estratégia estruturada e baseada em evidências para mantê-los e melhorá-los.

Ferramentas assistentes de programação por IA, como o GitHub Copilot, atualmente são discutidas principalmente no contexto de auxiliar e aprimorar o trabalho individual. No entanto, a entrega de software é, e continuará sendo um trabalho de equipe. Por isso, é importante buscar maneiras de criar assistentes de equipe por IA para ajudar a construir o time 10x, ao invés de grupos de engenheiros 10x isolados com assistência de IA. Começamos a utilizar uma abordagem de assistência de equipe que pode aumentar a amplificação do conhecimento, a qualificação e o alinhamento por meio de uma combinação de comando e fontes de conhecimento. Os comandos padronizados facilitam o uso de práticas recomendadas acordadas no contexto da equipe, como técnicas e modelos para escrita de histórias de usuários ou a implementação de práticas como modelagem de ameaças. Além dos comandos, as fontes de conhecimento disponibilizadas por meio de geração aumentada por recuperação fornecem informações contextualmente relevantes de diretrizes organizacionais ou bases de conhecimento específicas do setor. Essa abordagem dá aos membros da equipe acesso ao conhecimento e aos recursos de que precisam no momento exato.

Chatbots baseados em modelos de linguagem de grande porte (LLMs) estão ganhando muita popularidade e estamos observando técnicas emergentes para colocá-los em produção. Um dos desafios da produtização é entender como as pessoas estão conversando com um chatbot orientado por algo tão genérico como um LLM, onde a conversa pode seguir por muitos caminhos. Compreender a realidade dos fluxos de conversação é crucial para melhorar o produto e as taxas de conversão. Uma técnica para enfrentar esse problema é a análise de grafos para conversas baseadas em LLM. Os agentes que suportam um chat com um objetivo específico - como uma ação de compra ou a resolução bem-sucedida do problema de uma cliente - geralmente podem ser representados como uma máquina de estados desejada. Ao carregar todas as conversas em um grafo, você pode analisar os padrões reais e procurar discrepâncias em relação à máquina de estados esperada. Isso ajuda a encontrar bugs e oportunidades para melhoria do produto.

ChatOps baseados em LLM é uma aplicação emergente desses modelos por meio de plataformas de chat (principalmente o Slack) que permite a pessoas engenheiras construir, implantar e operar software através de linguagem natural. Isso tem o potencial de simplificar os fluxos de trabalho de engenharia, aprimorando a descoberta e a usabilidade dos serviços de plataforma. Os dois exemplos iniciais na época de redação deste blip são o PromptOps e o Kubiya. No entanto, considerando a precisão necessária para ambientes de produção, as organizações devem avaliar minuciosamente essas ferramentas antes de permitir a inclusão em seu processo de produção.

Agentes autônomos impulsionados por LLM estão evoluindo além de agentes isolados e sistemas multiagentes estáticos com o surgimento de frameworks como o Autogen e o CrewAI. Essas estruturas permitem que as pessoas usuárias definam agentes com funções específicas, atribuam tarefas e habilitem a colaboração entre agentes para concluir essas tarefas por meio de delegação ou conversação. Semelhante aos sistemas de agente único que surgiram anteriormente, como o AutoGPT, agentes individuais podem dividir tarefas, utilizar ferramentas pré-configuradas e solicitar intervenção humana. Embora ainda esteja nos estágios iniciais de desenvolvimento, esta área está se desenvolvendo rapidamente e tem um potencial empolgante para exploração.

A IA Generativa (GenAI) e os modelos de linguagem de grande porte (LLMs) podem auxiliar pessoas desenvolvedoras tanto a escrever quanto a entender código. Na prática, a aplicação atual se limita principalmente a trechos de código menores, mas novos produtos e avanços tecnológicos estão surgindo para utilizar a IA Generativa no entendimento de código legado. Isso é particularmente útil para bases de código antigas mal documentadas ou cuja documentação esteja desatualizada ou imprecisa. Por exemplo, o Driver AI or bloop usam RAGs que combinam inteligência de linguagem e busca de código com LLMs para auxiliar as pessoas usuárias a navegarem em uma base de código. Modelos emergentes com janelas de contexto cada vez maiores também ajudarão a tornar essas técnicas mais viáveis para bases de código de grande porte. Outra aplicação promissora da IA Generativa para código legado está na modernização de mainframes, onde gargalos frequentemente se formam em torno de pessoas engenheiras reversas que precisam entender a base de código existente e transformar esse entendimento em requisitos para o projeto de modernização. O uso da IA Generativa para auxiliar essas pessoas engenheiras reversas pode acelerar a conclusão do seu trabalho.

A Zoom recentemente tornou seu Sistema de Pontuação de Impacto de Vulnerabilidade, ou VISS, em um sistema de código aberto. Esse sistema foca principalmente na pontuação de vulnerabilidades que prioriza medidas de segurança comprovadamente efetivas. O VISS difere do Sistema Comum de Pontuação de Vulnerabilidade (CVSS) ao não se concentrar em cenários de pior caso e tentar mensurar de forma mais objetiva o impacto das vulnerabilidades da perspectiva do defensor. Para isso, o VISS fornece uma interface web (UI) para calcular a pontuação da vulnerabilidade com base em diversos parâmetros - categorizados em grupos de plataforma, infraestrutura e dados - incluindo o impacto na plataforma, o número de tenants afetados, impacto nos dados e muito mais. Embora ainda não tenhamos muita experiência prática com esta ferramenta específica, acreditamos que esse tipo de abordagem de avaliação prioritária baseada no setor e no contexto vale a pena ser praticada.

Apesar de aplaudirmos o foco em testes automatizados, seguimos observando diversas organizações investindo excessivamente no que consideramos testes de integração ampla ineficazes. Como o termo teste de integração é ambíguo, adotamos a classificação ampla do verbete de Martin Fowler sobre o assunto em seu bliki. Ele indica que esse tipo de teste requer versões ativas de todas as dependências de tempo de execução. Obviamente, esse tipo de teste é caro, pois exige um ambiente de teste completo com toda a infraestrutura, dados e serviços necessários. Gerenciar as versões corretas de todas essas dependências demanda uma sobrecarga significativa de coordenação, o que tende a retardar os ciclos de lançamento. Além disso, os próprios testes geralmente são frágeis e pouco úteis. Por exemplo, determinar se a falha de um teste ocorreu devido ao código novo, incompatibilidade de versões de dependências ou ao ambiente pode exigir bastante esforço, e a mensagem de erro raramente ajuda a identificar a origem do problema. Essas críticas não significam que discordamos de testes de integração automatizados do tipo caixa preta em geral. No entanto, consideramos uma abordagem mais vantajosa aquela que equilibra a necessidade de confiança com a frequência de lançamento. Isso pode ser feito em duas etapas, validando o comportamento do sistema sob teste. Primeiro, validamos o comportamento do sistema considerando um determinado conjunto de respostas das dependências de tempo de execução. Utilizamos virtualização de serviços para criar dublês de teste para essas dependências, o que simplifica o gerenciamento de dados de teste e permite testes determinísticos. Em seguida, validamos essas premissas de ambiente com dependências reais usando testes de contrato.

Na pressa para aproveitar o que há de mais recente em IA, muitas organizações estão adotando rapidamente modelos de linguagem de grande porte (LLMs) para diversas aplicações, desde geração de conteúdo até processos complexos de tomada de decisão. O fascínio pelos LLMs é inegável; eles oferecem uma solução aparentemente sem esforço para problemas complexos, e as pessoas desenvolvedoras muitas vezes podem criar tal solução rapidamente e sem a necessidade de anos de experiência em aprendizado de máquina (ML) profundo. Pode ser tentador lançar uma solução baseada em LLM assim que ela esteja mais ou menos funcional e seguir em frente. Embora essas provas de conceito baseadas em LLM sejam úteis, aconselhamos as equipes a analisarem cuidadosamente para que a tecnologia está sendo usada e a considerarem se um LLM é realmente a solução final correta. Muitos problemas que um LLM pode resolver - como análise de sentimento ou classificação de conteúdo - podem ser resolvidos de forma mais barata e fácil usando o Processamento de Linguagem Natural (PLN) tradicional. Analisar o que o LLM está fazendo e, em seguida, analisar outras soluções potenciais não apenas mitiga os riscos associados ao uso excessivo de LLMs , mas também promove uma compreensão e aplicação mais matizadas das tecnologias de IA.

À medida que organizações buscam formas de fazer com que os modelos de linguagem de grande porte (LLMs) funcionem no contexto de seus produtos, domínios ou conhecimento organizacional, estamos vendo uma corrida para o fine-tuning de LLMs. Embora o fine-tuning possa ser uma ferramenta poderosa para aumentar a especificidade de tarefas em um caso de uso, em muitos casos ele não é necessário. Um dos erros mais comuns nessa pressa pelo fine-tuning é tentar tornar um aplicativo baseado em LLM ciente de conhecimento e fatos específicos ou do código-base de uma organização. Na grande maioria desses casos, usar uma forma de geração aumentada por recuperação (RAG) oferece uma solução melhor e uma relação custo-benefício mais vantajosa. O fine-tuning requer recursos computacionais consideráveis e expertise, além de introduzir desafios ainda maiores relacionados a dados sensíveis e proprietários do que a RAG. Há também o risco de subajuste (underfitting), quando não há dados suficientes para o fine-tuning, ou, menos frequentemente, de superajuste (overfitting), quando há dados em excesso, o que resulta em um desbalanceamento na especificidade de tarefas que você precisa. Analise atentamente esses prós e contras e considere as alternativas antes de se apressar para fazer o fine-tuning de um LLM para o seu caso de uso.

Com a adoção de frameworks como Next.js e htmx, observamos um aumento no uso de renderização no lado do servidor (SSR). Como tecnologia do navegador, utilizar web components não é trivial. Frameworks surgiram para facilitar isso, alguns até mesmo usando um motor de navegador, mas a complexidade ainda persiste. Nossas equipes de desenvolvimento se vêem precisando de soluções alternativas e esforço adicional para ordenar componentes de front-end e componentes do lado do servidor. Pior do que a experiência da pessoa desenvolvedora é a experiência da pessoa usuária: o desempenho do carregamento da página é prejudicado quando web components customizados precisam ser carregados e hidratados no navegador, e mesmo com pré-renderização e ajustes cuidadosos do componente, um lampejo de conteúdo sem estilo ou alguma mudança de layout é quase inevitável. Conforme mencionado no Radar anterior, uma de nossas equipes precisou migrar seu design system do Stencil, baseado em web components, devido a esses problemas. Recentemente, recebemos relatos de outra equipe que acabou substituindo componentes gerados no lado do servidor por componentes do lado do navegador devido à complexidade de desenvolvimento. Alertamos contra o uso de web components para aplicações web com SSR , mesmo que sejam suportados por frameworks.