Construindo uma empresa AI-Native

xguru · 2024-07-01T11:22:02+09:00

No início da década de 2020, muita atenção se concentrou na IA generativa A discussão se concentrou principalmente em como as ferramentas de IA generativa nos moldariam e em que impacto teriam na escrita, na programação, na animação e na forma como consumimos informação No entanto, quase não se falava sobre a forma das nossas ferramentas No fim da década de 1960, os sistemas de informação passaram a enfrentar o problema de que o processo de buscar informações relevantes se tornava cada vez mais caro devido ao enorme volume de dados Nas décadas de 1980 e 1990, os bancos de dados relacionais se tornaram a solução dominante Eles ofereciam indexação intuitiva e garantiam eficiência nas consultas Os bancos de dados relacionais permitiam representar dados como um conjunto de tabelas com relações estruturadas Por meio de linguagens de consulta como SQL, possibilitaram uma recuperação de dados mais rápida À medida que a arquitetura de bancos de dados evoluiu, certas empresas como IBM, Oracle, Sun Microsystems e MongoDB consolidaram sua posição em cada mercado emergente Embora a Oracle tenha liderado o mundo dos bancos de dados relacionais, a forma como as pessoas armazenam e acessam informações continuou mudando Sempre que surgia um novo tipo de trabalho, as pessoas criavam uma nova arquitetura para gerenciá-lo A evolução mais recente dos bancos de dados surgiu da necessidade de lidar com dados não estruturados Ao longo de mais de 50 anos, os esquemas foram organizados principalmente em torno de relações de dados estruturados Mas cada vez mais pessoas passaram a precisar de ferramentas capazes de lidar muito melhor com a ambiguidade dos dados Foi nesse contexto que surgiram os bancos de dados vetoriais Modelos de linguagem de grande porte (LLMs) baseados em transformers, como o GPT, conseguem capturar dependências de longo prazo no texto No entanto, manter a compreensão de textos longos pode ser computacionalmente caro Bancos de dados vetoriais podem expandir a janela de contexto desses modelos Embora bancos de dados vetoriais possam ser poderosos em casos de uso de IA, eles ainda são uma infraestrutura burra que opera com base em entradas e saídas Falta a eles a capacidade de entender ou interpretar dados Eles apenas funcionam como repositórios que armazenam e recuperam dados conforme instruídos, sem inteligência intrínseca nem consciência de contexto Com o lançamento do GPT-3 em 2020, a IA passou a poder ser usada cada vez mais como núcleo, e não como apêndice, dos produtos corporativos A arquitetura transformer, o aumento no volume de dados e a melhora de desempenho criaram a base para o desenvolvimento de produtos impulsionados por IA À medida que empresas AI-Native (baseadas em IA) aumentam em número e escala, cresce também a necessidade de ferramentas que deem suporte a casos de uso baseados em IA A primeira onda de empresas centradas em IA se concentrou principalmente em inferência usando modelos já existentes No entanto, com modelos de melhor desempenho — especialmente modelos open source de fácil acesso —, as empresas passaram a conseguir desenvolver com mais profundidade suas capacidades como negócios baseados em IA Essa escalabilidade está abrindo um mundo de oportunidades sobre como pode ser uma stack tecnológica baseada em IA As ferramentas que nos moldam (The Tools that Shape Us) Em 1967, John M. Culkin, amigo de Marshall McLuhan, disse: "Nós moldamos nossas ferramentas e depois nossas ferramentas nos moldam" Com a criação de tecnologia, não é diferente A infraestrutura que usamos para criar software evoluiu constantemente para se adaptar às nossas necessidades de construção, e depois aquilo que construímos passa a ser moldado pela infraestrutura que estabelecemos No início da década de 2020, muita atenção se concentrou na IA generativa O foco estava especialmente nos resultados: o texto ou código gerado, as imagens renderizadas, os deepfakes produzidos e a música sintetizada A discussão se concentrou principalmente em como essas ferramentas nos moldariam e em que impacto teriam na escrita, na programação, na animação e na forma como consumimos informação As pessoas debatiam o desempenho comparativo entre modelos de linguagem de grande porte abertos e proprietários, os riscos de alucinação, a discussão entre plataforma e funcionalidade, e o debate entre empresas estabelecidas e startups No entanto, quase não se falava sobre a forma das nossas ferramentas Em essência, a maneira como construímos tecnologia sempre foi moldada pela infraestrutura preparada para essa construção A disseminação do SaaS foi acelerada pela internet, o desenvolvimento mobile se tornou possível com a popularização dos smartphones, e a escalabilidade das gerações de aplicações foi impulsionada pela computação em nuvem A ubiquidade da IA nas aplicações depende de computação, das capacidades dos modelos e da orquestração desses modelos dentro dos casos de uso de negócios Este texto se concentrará no elemento de orquestração Um dos elementos centrais na orquestração de todos os casos de uso de IA é o banco de dados da empresa O local onde os dados são armazenados, manipulados e chamados é uma parte importante do quebra-cabeça No entanto, como será mostrado, a história dos bancos de dados foi em grande parte a história de uma infraestrutura burra Para maximizar a utilidade da IA, será preciso construir bancos de dados que façam parte da equação generativa Uma base para os dados (A Base For Data) Em maio de 1959, a CODASYL (Conference on Data Systems Languages) foi convocada pela primeira vez com o objetivo de criar uma “linguagem de propósito geral para construir aplicações de negócios” No fim dos anos 1960, os sistemas de informação passaram a enfrentar o problema de que, devido ao enorme volume de dados, o processo de buscar informações relevantes se tornava cada vez mais caro O uso de computadores mainframe normalmente levava ao aumento do custo por MIPS (milhões de instruções por segundo), à medida que o aproveitamento dos mainframes crescia por causa de custos de manutenção de aplicações, patches e upgrades necessários para manter o desempenho Devido à complexidade da gestão de bancos de dados, hierarquias rígidas e mapeamentos complexos de estruturas de navegação, as empresas frequentemente precisavam de conhecimento técnico para acessar as informações desejadas, e alguns desenvolvedores chegavam a ter que escrever programas inteiros para acessar dados relevantes Em 1970, E.F. Codd publicou “A Relational Model of Data for Large Shared Data Banks”, propondo um modelo em que tabelas poderiam ser conectadas por características compartilhadas (ou seja, chaves primárias que identificam registros únicos e chaves estrangeiras que estabelecem relações entre tabelas) Isso permitiu recuperar dados de tabelas heterogêneas com uma única consulta O banco de dados relacional de Codd, baseado nas relações entre itens de dados, possibilitou flexibilidade na manipulação e no uso dos dados Em 1973, um grupo de programadores do IBM San Jose Research Laboratory iniciou o projeto System R, demonstrando que um sistema de banco de dados relacional poderia integrar todas as funcionalidades necessárias para uso em produção e ainda assim oferecer alto desempenho Essa equipe desenvolveu um otimizador baseado em custo para eficiência de banco de dados, e os avanços derivados do System R mais tarde levaram ao lançamento do SQL/DS, o primeiro produto de banco de dados relacional da IBM Nas décadas de 1980 e 1990, os bancos de dados relacionais se tornaram a solução dominante Ofereciam indexação intuitiva e garantiam eficiência nas consultas Os bancos de dados relacionais permitiam representar dados como uma coleção de tabelas com relações estruturadas Também possibilitavam recuperação de dados mais rápida por meio de linguagens de consulta como SQL Os bancos de dados relacionais foram construídos com a premissa de rodar em uma única máquina Porém, a adoção em massa da internet nos anos 1990 e 2000 trouxe uma enxurrada enorme de dados, gerando workloads pesadas demais para um único computador suportar Os bancos de dados SQL tradicionais foram projetados para rodar em um único servidor, exigindo que os usuários aumentassem o hardware físico de acordo com a necessidade de armazenamento, o que se mostrou muito caro para empresas operando workloads maiores Na década de 2010, os dados e os usuários de OLTP (processamento de transações online) cresceram exponencialmente, levando a um aumento generalizado de bancos de dados distribuídos, data warehouses e OLAP (processamento analítico online) Bancos de dados relacionais e SQL já não eram mais adequados para a escala e a complexidade das aplicações necessárias, e os bancos de dados NoSQL surgiram como uma forma de aumentar o desempenho (abrindo mão de recursos ACID) Bancos de dados relacionais conseguiam armazenar e manipular dados estruturados, mas era difícil manter relações entre os dados quando se consideravam o overhead de joins e o custo de operações CRUD Eles eram adequados para lidar com dados relacionais com requisitos lógicos ou discretos, mas em geral estavam alinhados a sistemas legados construídos especificamente para estruturas relacionais O NoSQL surgiu como uma forma de lidar com big data não estruturado, oferecendo persistência de dados aos desenvolvedores por meio de uma abordagem não relacional Em vez de usar SQL como linguagem de consulta padrão, o NoSQL oferece acesso via APIs, garantindo maior escalabilidade, computação distribuída, redução de custos e flexibilidade de schema Bancos de dados NoSQL funcionam com arquiteturas eficientes que podem escalar horizontalmente, então, para ampliar capacidade de armazenamento ou computação, basta adicionar mais servidores ou instâncias em nuvem Para empresas com workloads de dados voltadas a processamento ou análise mais rápida de dados não estruturados, bancos de dados NoSQL passaram a ser a opção preferida As OG database wars À medida que a arquitetura de bancos de dados evoluía, certas empresas consolidaram sua posição em cada mercado emergente Logo após a IBM lançar o System R, Larry Ellison, então com 33 anos, leu o mesmo artigo de Codd sobre bancos de dados relacionais Ellison e seus dois cofundadores tentaram criar uma empresa compatível com o System R, mas a IBM tornou isso muito difícil Como resultado, o trio construiu o negócio em torno de um novo produto principal de banco de dados: o Oracle Databases Desde então, o banco de dados da Oracle se tornou o produto líder e, em maio de 2024, sua participação de mercado era de cerca de 28,7% Nos anos que antecederam o IPO da Oracle em 1986, outra empresa entrou no setor de bancos de dados A Sun Microsystems começou em 1982 vendendo vários componentes de computador, mas ficou conhecida por contribuições como a linguagem de programação Java, o Network File System e outras O ponto importante é que, em 2008, a Sun Microsystems adquiriu o MySQL, um sistema de gerenciamento de banco de dados de código aberto Apenas dois anos depois, a Oracle adquiriu a Sun Microsystems (incluindo o MySQL) Quase 15 anos depois, em maio de 2024, os bancos de dados líderes são Oracle (28,7% de participação de mercado) e MySQL (cerca de 17,3%) Embora a Oracle tenha liderado o mundo dos bancos de dados relacionais, a forma como as pessoas armazenam e acessam informações continuou mudando A cada novo tipo de trabalho, surgia uma nova arquitetura para administrá-lo De document stores como MongoDB (2007) e Databricks (2013) a bancos de dados de séries temporais como InfluxDB (2013) e Prometheus (2012), e bancos de dados em grafo como Neo4j (2007) e Cosmos (2017), a lista de bancos de dados especializados continua crescendo À medida que a popularidade dos bancos de dados relacionais diminuía de forma constante, várias soluções foram surgindo para atender a essas novas necessidades de nicho A evolução mais recente dos bancos de dados surgiu da necessidade de lidar com dados não estruturados Ao longo dos últimos mais de 50 anos, schemas foram organizados principalmente em torno de relações de dados estruturados Mas cada vez mais pessoas passaram a precisar de ferramentas capazes de lidar muito melhor com a ambiguidade dos dados Assim surgiram os bancos de dados vetoriais A ascensão dos bancos de dados vetoriais Com a ampla disseminação dos grandes modelos de linguagem (LLMs) e da IA generativa, os bancos de dados vetoriais surgiram como ferramentas capazes de processar dados multimodais não estruturados Enquanto os bancos de dados relacionais tradicionais (Postgres, MySQL) são mais adequados para esquemas estruturados, os bancos de dados vetoriais são adequados para armazenar e consultar embeddings vetoriais (representações numéricas de dados que incluem significado em relação aos pesos de um modelo de linguagem) Em vez das linhas e colunas normalmente usadas em bancos de dados relacionais, os bancos de dados vetoriais representam os dados como pontos em um espaço multidimensional, fazendo a correspondência com base em similaridade, e não em valores exatos Dependendo do modelo de embedding, os dados podem ser representados em diferentes espaços vetoriais e com várias dimensões Embeddings vetoriais capturam o significado dos pontos de dados, permitindo buscar objetos semelhantes ao recuperar os objetos mais próximos em um banco de dados vetorial Por exemplo, o Word2Vec mapeia palavras em vetores, ajudando a capturar significado, similaridade semântica e relações contextuais com outros textos Esse algoritmo usa uma rede neural rasa para inferir o significado de uma palavra específica a partir de um corpus textual mais amplo e identifica sinônimos por meio de regressão logística Também existem métodos que ajudam a extrair embeddings sem depender de redes neurais profundas, como decomposição em valores singulares (SVD) e análise de componentes principais (PCA) Métricas de distância ajudam a determinar a “distância” relativa entre pontos em um espaço vetorial, e métodos comuns incluem distância euclidiana, distância Manhattan, distância cosseno e similaridade de Jaccard K-vizinhos mais próximos (KNN) e vizinhos mais próximos aproximados (ANN) ajudam a simplificar a busca por similaridade em imagens, vídeos ou outras entradas multimodais, melhorando o tempo de execução Bancos de dados dedicados a vetores, como Weaviate, Chroma, Qdrant e Pinecone, ajudam desenvolvedores a lidar com dados em larga escala, especialmente no que diz respeito a facilitar buscas sobre entradas não estruturadas Diferentemente dos bancos de dados relacionais tradicionais ou dos bancos de dados NoSQL, os bancos de dados vetoriais são projetados especificamente para lidar com embeddings vetoriais Enquanto os bancos de dados tradicionais armazenam dados como escalares, os bancos de dados vetoriais armazenam apenas vetores e utilizam técnicas de indexação como quantização e clustering para otimizar operações de busca LLMs baseados em transformers, como o GPT, conseguem capturar dependências de longo prazo no texto No entanto, manter a capacidade de compreensão de textos longos pode ser computacionalmente caro Os LLMs mais recentes conseguem capturar dependências globais entre pares de tokens ao longo da entrada, mas problemas de recursos computacionais causados pela complexidade de tempo e espaço limitam o comprimento do texto de entrada durante o treinamento e a janela de contexto efetiva durante a inferência Em casos multidimensionais, a codificação posicional relativa é difícil de implementar, e a maioria das abordagens para codificar posições relativas exige mecanismos robustos de embedding posicional, o que contribui para degradação de desempenho durante a inferência Mesmo quando o comprimento do texto aumenta, os bancos de dados vetoriais podem ser importantes por funcionarem como memória de longo prazo do modelo O uso de bancos de dados vetoriais pode simplificar tarefas como completação de texto ou sumarização, nas quais o contexto completo da sentença pode ser necessário para gerar resultados precisos Bancos de dados vetoriais podem dar suporte à geração aumentada por recuperação (RAG), em que podem ser usados para enriquecer prompts enviados ao LLM com contexto adicional junto com a consulta original Como os LLMs muitas vezes dependem de modelos de aprendizado auto-supervisionado, frequentemente têm dificuldade com tarefas específicas de domínio que exigem conhecimento especializado ou limiares mais altos de precisão O RAG pode ajudar a verificar, rastrear ou explicar como as respostas são derivadas, ao mesmo tempo em que mitiga alucinações que podem surgir da falta de contexto para a consulta em questão Desenvolvedores podem combinar grafos de conhecimento com busca vetorial para expandir os LLMs além dos dados com os quais foram treinados Ferramentas como o GraphRAG, da Microsoft Research, facilitam o aumento de prompts ao realizar buscas em conjuntos de dados privados O RAG básico frequentemente tem dificuldade para compreender de forma holística conceitos semânticos resumidos em grandes coleções de dados, por isso ferramentas como LlamaIndex e GraphRAG constroem grafos de conhecimento com base em conjuntos de dados privados Dependendo dos requisitos específicos ou do caso de uso, pode ser melhor para desenvolvedores usar grafos de conhecimento em vez de RAG Bancos de dados vetoriais são adequados para busca por similaridade e mais indicados para busca de documentos ou imagens e geração de recomendações, enquanto grafos de conhecimento são adequados para raciocínio (especialmente úteis na coleta de dados, extração de entidades junto com relações interconectadas e navegação por essas relações) Para aplicações que exigem processamento de dados em tempo real ou quase em tempo real, bancos de dados vetoriais podem ser preferidos devido a consultas de menor latência Ao coletar e armazenar embeddings, os bancos de dados vetoriais facilitam buscas mais rápidas por similaridade, fazendo a correspondência entre o prompt de entrada e embeddings semelhantes O ranqueamento por similaridade ajuda a dar suporte a várias tarefas de machine learning, desde sistemas de recomendação até busca semântica, reconhecimento de imagem e outras aplicações de processamento de linguagem natural Os bancos de dados vetoriais desempenham um papel importante na melhoria do desempenho dos LLMs ao possibilitar o armazenamento e a recuperação eficientes de embeddings vetoriais Isso permite compreender automaticamente a linguagem natural em larga escala No entanto, embeddings vetoriais representam uma inovação N+1 Trata-se de uma forma de dados anterior, como dados relacionais ou séries temporais Fornecedores legados de bancos de dados começaram a lançar recursos vetoriais, como o Atlas Vector Search do MongoDB, o banco de dados vetorial da SingleStore e o índice de busca vetorial da Neo4J Embora bancos de dados vetoriais possam ser poderosos em casos de uso de IA, eles ainda são uma infraestrutura burra operada por entradas e saídas Eles não têm capacidade de entender ou interpretar dados Apenas atuam como repositórios que armazenam e recuperam dados conforme instruído, sem inteligência intrínseca nem consciência de contexto Para aplicações modernas baseadas em IA, isso por si só não será suficiente As empresas estão cada vez mais construindo com modelos de IA no centro Portanto, à medida que as aplicações passam a exibir capacidades cada vez mais inteligentes, a infraestrutura também precisará dessas mesmas capacidades inteligentes Empresas AI-Native de 1ª geração Desde que a academia começou a pesquisar inteligência artificial pela primeira vez no Dartmouth College em 1956, casos de uso práticos vêm impulsionando o avanço desse campo Por exemplo, no fim dos anos 1960, Joseph Weizenbaum criou um programa de computador chamado ELIZA, cuja abordagem simples de simulação de conversa por correspondência de padrões foi usada para conversas rudimentares semelhantes a terapia (o primeiro chatbot) Na maior parte da história do uso de AI em casos de uso de negócios, as melhorias foram graduais Antes de o termo AI virar moda, o termo machine learning era usado com mais frequência para se referir à mesma tecnologia Ou seja, “algoritmos estatísticos que podem aprender com dados e generalizar para dados não vistos, podendo executar tarefas sem instruções explícitas” Do ponto de vista da percepção pública, a AI atingiu um ponto de inflexão em 30 de novembro de 2022, quando a OpenAI lançou o ChatGPT, mas do ponto de vista técnico a virada aconteceu muito antes Em novembro de 2017, o órgão regulador internacional Financial Stability Board (FSB) elaborou uma visão geral sobre o impacto do machine learning nos serviços financeiros Empresas de serviços financeiros puderam usar cada vez mais machine learning para executar tarefas como “avaliação da qualidade de crédito” e assim “contribuir para um sistema financeiro mais eficiente” Em outras palavras, isso podia aumentar a eficiência, mas não constituía uma necessidade existencial Enquanto isso, o machine learning continuou melhorando e, em maio de 2018, a OpenAI publicou um estudo sobre a história do poder computacional necessário para treinar modelos de grande escala, mostrando que, desde 2012, ele vinha dobrando a cada 3,4 meses, totalizando um aumento de 300 mil vezes No mês seguinte, em junho de 2018, a OpenAI publicou a primeira apresentação do modelo GPT Um debate começou a se formar entre dois campos De um lado, muitos acreditavam que o crescimento contínuo de modelos cada vez maiores estaria sujeito à lei dos retornos decrescentes O outro campo, do qual a OpenAI fazia parte, acreditava que o desempenho continuaria melhorando à medida que a escala aumentasse Em janeiro de 2020, Jared Kaplan, pesquisador da OpenAI e professor da Johns Hopkins University, publicou com outros autores o artigo “Scaling Laws for Neural Language Models”, que afirmava o seguinte: “O desempenho de modelagem de linguagem melhora de forma suave e previsível à medida que escalamos adequadamente o tamanho do modelo, os dados e a computação. Esperamos que modelos de linguagem maiores tenham desempenho melhor e maior eficiência amostral do que os modelos atuais.” Em maio de 2020, a OpenAI publicou o artigo sobre o GPT-3 intitulado “Language Models are Few-Shot Learners”, que mostrou um escalonamento suave de desempenho conforme a computação aumentava A OpenAI também descobriu que ampliar a escala melhora a capacidade de generalização, argumentando que “o escalonamento de modelos de linguagem de grande porte melhora muito o desempenho few-shot independente de tarefa, às vezes a ponto de competir com abordagens anteriores de fine-tuning de ponta” O pesquisador independente Gwern Branwen formulou a hipótese de scaling em um post de blog, dizendo o seguinte: “O GPT-3, publicado pela OpenAI em maio de 2020, é a maior rede neural já treinada até hoje, por mais de uma ordem de magnitude... Ao contrário do que muitos esperavam (inclusive eu), esse enorme aumento de escala continuou mostrando os benefícios do tamanho, como a OpenAI previa, e não bateu nos retornos decrescentes nem em retornos negativos que muitos esperavam.” A surpresa sentida por Branwen refletia uma mudança no cenário A AI podia ser usada cada vez mais como núcleo do produto de uma empresa, e não apenas como apêndice A arquitetura Transformer, o aumento no volume de dados e os níveis mais altos de desempenho criaram a base para o desenvolvimento de produtos baseados em AI Logo após o lançamento do GPT-3, em maio de 2020, empresas como Writer e Jasper criaram produtos de copywriting com modelos de AI no centro do negócio Empresas como Harvey e EvenUp construíram legal tech em torno de AI Empresas como DeepScribe e Freed construíram transcrição médica em torno de AI No entanto, assim como novos casos de uso no passado levaram à evolução dos bancos de dados, o surgimento de produtos baseados em AI significava que a infraestrutura por trás da stack tecnológica de cada empresa precisaria mudar e se adaptar Banco de dados AI-Native À medida que empresas baseadas em AI aumentam em número e escala, cresce também a necessidade de ferramentas que deem suporte a casos de uso baseados em AI A primeira onda de empresas cujo núcleo era AI focou principalmente em inferência usando modelos existentes Com ferramentas de workflow orientadas a objetivos para aplicações, copywriting, transcrição médica e outros usos O núcleo do produto é a saída, como texto gerado pelo modelo ou imagens geradas Após o DevDay da OpenAI em novembro de 2023, começou a se espalhar o meme “OpenAI killed my startup” GPTs especializados ou agentes de AI pareciam assumir o papel dessas startups iniciais baseadas em AI, já que focavam na inferência de modelos existentes A OpenAI acabou se tornando, por acaso, fornecedora tanto do modelo quanto da aplicação A inovação em torno das capacidades dos modelos avançou tão rapidamente que começou a parecer uma ameaça para startups Mas, por outro lado, modelos com desempenho melhorado — especialmente modelos open source de fácil acesso — passaram a permitir que empresas construíssem de forma mais profunda suas capacidades como negócios baseados em AI Construir uma stack tecnológica baseada em AI é mais do que adicionar componentes ao redor de um modelo Por exemplo, como seria um banco de dados criado especificamente para AI? Se a inferência é uma saída importante, um banco de dados AI-Native não deve apenas armazenar e recuperar dados, mas também ser capaz de receber instruções contextuais sobre o que fazer com os dados armazenados Um exemplo pode ser a personalização de descrições de produtos para e-commerce Um banco de dados vetorial pode armazenar não apenas embeddings vetoriais de SKUs e descrições de produtos, mas também embeddings de personas de usuários Usando todos esses dados contextuais do banco de dados, a infraestrutura pode aproveitar um loop de feedback generativo em que uma consulta por uma descrição de produto também aciona uma consulta pela persona de usuário relevante, e então redige a descrição do produto com base nessa persona relevante Da mesma forma, a linguagem pode ser usada como um loop de feedback generativo Por exemplo, o usuário pode querer gerar descrições de produtos em vários idiomas É possível gerar descrições de produtos não apenas personalizadas para o usuário, mas também traduzidas para o idioma escolhido por ele Esse tipo de instrução pode ser incorporado diretamente ao banco de dados, porque casos de uso como AI generativa estão se tornando cada vez mais uma funcionalidade central das aplicações Evoluir a infraestrutura para se adequar aos casos de uso não é novidade Originalmente, os desenvolvedores usavam JavaScript para criar aplicações no navegador e tornar os sites interativos e dinâmicos Mas, quando perceberam que podiam levar isso para o backend, surgiu o node.js Depois, à medida que os desenvolvedores começaram a criar mais aplicações móveis, surgiu o JSON (JavaScript Object Notation), permitindo aplicações mais dinâmicas, responsivas e orientadas por dados A MongoDB surgiu como uma empresa para atender a essas necessidades de infraestrutura em evolução, encaixando-se perfeitamente nessa onda Com AI, a história está se repetindo À medida que os requisitos mudam, a infraestrutura precisa evoluir para atendê-los A grande questão será que tipo de empresa as pessoas querem construir e que tipo de infraestrutura é mais adequado para essas empresas Como Bob disse em uma entrevista com Matthew Lynley: “Eu acredito fortemente que todas as aplicações do futuro terão AI. Em algumas aplicações, haverá um pouco de AI espalhado; em outras, a AI estará no centro da aplicação. Se você tirar a AI, ela deixa de existir. Se você quer construir um web app e colocar AI por cima, use MongoDB. Especialmente se você já o utiliza... Se quiser construir uma aplicação AI-Native, em que a AI é o núcleo da aplicação, é hora de considerar a Weaviate.” Daqui para frente, as empresas decidirão se vão construir produtos com AI como apêndice — ou, como Bob disse, como um “sprinkle” — ou se ela será o núcleo do produto Stack tecnológica AI-Native Para empresas que querem construir a IA como componente central do produto, a infraestrutura existente provavelmente não será adequada Com ferramentas legadas, o armazenamento, a organização e a execução dos dados são construídos em um silo, enquanto a automação é construída em outro A desvantagem dessa abordagem é que o contexto se perde em coisas como loops de feedback gerativo, que podem informar e melhorar melhor o produto Para empresas que vêm de uma stack “adjacente à IA”, a inferência de um modelo específico muitas vezes fica limitada pela janela de contexto Alguns acreditam que, se a capacidade de uma determinada janela de contexto aumentar, ela poderá substituir os bancos de dados vetoriais No entanto, é mais provável que seja verdade o cenário oposto, no qual os bancos de dados vetoriais evoluam para substituir a janela de contexto Embeddings vetoriais são extremamente importantes para modelos generativos, e a infraestrutura para resultados generativos deve tratar embeddings vetoriais como cidadãos de primeira classe Em vez de simplesmente aumentar o tamanho da janela de contexto, é possível incorporar um banco de dados vetorial ao modelo para oferecer a compreensão contextual da janela de contexto junto com a confiabilidade e a escalabilidade do banco de dados Isso é especialmente relevante porque, quanto mais geral for o modelo, menor a probabilidade de ele ser feito sob medida para uma tarefa específica Bancos de dados vetoriais com IA permitirão funcionalidades mais específicas Modelos generalistas como o GPT-4 foram construídos para generalizar conhecimento de forma intencional Se o produto depender de um pouco de fine-tuning simples, o modelo base não será a parte singularmente valiosa daquele negócio Construir um produto baseado em IA envolverá, além de aproveitar o modelo, construir o produto em torno de uma stack mais estreitamente conectada Essa stack fornecerá a escala do banco de dados e as capacidades do modelo para criar produtos mais competentes

(research.contrary.com)

23 pontos por xguru 2024-07-01 | 1 comentários | Compartilhar no WhatsApp

No início da década de 2020, muita atenção se concentrou na IA generativa
- A discussão se concentrou principalmente em como as ferramentas de IA generativa nos moldariam e em que impacto teriam na escrita, na programação, na animação e na forma como consumimos informação
- No entanto, quase não se falava sobre a forma das nossas ferramentas
No fim da década de 1960, os sistemas de informação passaram a enfrentar o problema de que o processo de buscar informações relevantes se tornava cada vez mais caro devido ao enorme volume de dados
Nas décadas de 1980 e 1990, os bancos de dados relacionais se tornaram a solução dominante
- Eles ofereciam indexação intuitiva e garantiam eficiência nas consultas
- Os bancos de dados relacionais permitiam representar dados como um conjunto de tabelas com relações estruturadas
- Por meio de linguagens de consulta como SQL, possibilitaram uma recuperação de dados mais rápida
À medida que a arquitetura de bancos de dados evoluiu, certas empresas como IBM, Oracle, Sun Microsystems e MongoDB consolidaram sua posição em cada mercado emergente
Embora a Oracle tenha liderado o mundo dos bancos de dados relacionais, a forma como as pessoas armazenam e acessam informações continuou mudando
- Sempre que surgia um novo tipo de trabalho, as pessoas criavam uma nova arquitetura para gerenciá-lo
A evolução mais recente dos bancos de dados surgiu da necessidade de lidar com dados não estruturados
- Ao longo de mais de 50 anos, os esquemas foram organizados principalmente em torno de relações de dados estruturados
- Mas cada vez mais pessoas passaram a precisar de ferramentas capazes de lidar muito melhor com a ambiguidade dos dados
- Foi nesse contexto que surgiram os bancos de dados vetoriais
Modelos de linguagem de grande porte (LLMs) baseados em transformers, como o GPT, conseguem capturar dependências de longo prazo no texto
- No entanto, manter a compreensão de textos longos pode ser computacionalmente caro
- Bancos de dados vetoriais podem expandir a janela de contexto desses modelos
Embora bancos de dados vetoriais possam ser poderosos em casos de uso de IA, eles ainda são uma infraestrutura burra que opera com base em entradas e saídas
- Falta a eles a capacidade de entender ou interpretar dados
- Eles apenas funcionam como repositórios que armazenam e recuperam dados conforme instruídos, sem inteligência intrínseca nem consciência de contexto
Com o lançamento do GPT-3 em 2020, a IA passou a poder ser usada cada vez mais como núcleo, e não como apêndice, dos produtos corporativos
- A arquitetura transformer, o aumento no volume de dados e a melhora de desempenho criaram a base para o desenvolvimento de produtos impulsionados por IA
À medida que empresas AI-Native (baseadas em IA) aumentam em número e escala, cresce também a necessidade de ferramentas que deem suporte a casos de uso baseados em IA
- A primeira onda de empresas centradas em IA se concentrou principalmente em inferência usando modelos já existentes
No entanto, com modelos de melhor desempenho — especialmente modelos open source de fácil acesso —, as empresas passaram a conseguir desenvolver com mais profundidade suas capacidades como negócios baseados em IA
- Essa escalabilidade está abrindo um mundo de oportunidades sobre como pode ser uma stack tecnológica baseada em IA

As ferramentas que nos moldam (The Tools that Shape Us)

Em 1967, John M. Culkin, amigo de Marshall McLuhan, disse: "Nós moldamos nossas ferramentas e depois nossas ferramentas nos moldam"
- Com a criação de tecnologia, não é diferente
- A infraestrutura que usamos para criar software evoluiu constantemente para se adaptar às nossas necessidades de construção, e depois aquilo que construímos passa a ser moldado pela infraestrutura que estabelecemos
No início da década de 2020, muita atenção se concentrou na IA generativa
- O foco estava especialmente nos resultados: o texto ou código gerado, as imagens renderizadas, os deepfakes produzidos e a música sintetizada
- A discussão se concentrou principalmente em como essas ferramentas nos moldariam e em que impacto teriam na escrita, na programação, na animação e na forma como consumimos informação
- As pessoas debatiam o desempenho comparativo entre modelos de linguagem de grande porte abertos e proprietários, os riscos de alucinação, a discussão entre plataforma e funcionalidade, e o debate entre empresas estabelecidas e startups
No entanto, quase não se falava sobre a forma das nossas ferramentas
- Em essência, a maneira como construímos tecnologia sempre foi moldada pela infraestrutura preparada para essa construção
- A disseminação do SaaS foi acelerada pela internet, o desenvolvimento mobile se tornou possível com a popularização dos smartphones, e a escalabilidade das gerações de aplicações foi impulsionada pela computação em nuvem
A ubiquidade da IA nas aplicações depende de computação, das capacidades dos modelos e da orquestração desses modelos dentro dos casos de uso de negócios
- Este texto se concentrará no elemento de orquestração
- Um dos elementos centrais na orquestração de todos os casos de uso de IA é o banco de dados da empresa
- O local onde os dados são armazenados, manipulados e chamados é uma parte importante do quebra-cabeça
- No entanto, como será mostrado, a história dos bancos de dados foi em grande parte a história de uma infraestrutura burra
- Para maximizar a utilidade da IA, será preciso construir bancos de dados que façam parte da equação generativa

Uma base para os dados (A Base For Data)

Em maio de 1959, a CODASYL (Conference on Data Systems Languages) foi convocada pela primeira vez com o objetivo de criar uma “linguagem de propósito geral para construir aplicações de negócios”
- No fim dos anos 1960, os sistemas de informação passaram a enfrentar o problema de que, devido ao enorme volume de dados, o processo de buscar informações relevantes se tornava cada vez mais caro
O uso de computadores mainframe normalmente levava ao aumento do custo por MIPS (milhões de instruções por segundo), à medida que o aproveitamento dos mainframes crescia por causa de custos de manutenção de aplicações, patches e upgrades necessários para manter o desempenho
- Devido à complexidade da gestão de bancos de dados, hierarquias rígidas e mapeamentos complexos de estruturas de navegação, as empresas frequentemente precisavam de conhecimento técnico para acessar as informações desejadas, e alguns desenvolvedores chegavam a ter que escrever programas inteiros para acessar dados relevantes
Em 1970, E.F. Codd publicou “A Relational Model of Data for Large Shared Data Banks”, propondo um modelo em que tabelas poderiam ser conectadas por características compartilhadas (ou seja, chaves primárias que identificam registros únicos e chaves estrangeiras que estabelecem relações entre tabelas)
- Isso permitiu recuperar dados de tabelas heterogêneas com uma única consulta
- O banco de dados relacional de Codd, baseado nas relações entre itens de dados, possibilitou flexibilidade na manipulação e no uso dos dados
Em 1973, um grupo de programadores do IBM San Jose Research Laboratory iniciou o projeto System R, demonstrando que um sistema de banco de dados relacional poderia integrar todas as funcionalidades necessárias para uso em produção e ainda assim oferecer alto desempenho
- Essa equipe desenvolveu um otimizador baseado em custo para eficiência de banco de dados, e os avanços derivados do System R mais tarde levaram ao lançamento do SQL/DS, o primeiro produto de banco de dados relacional da IBM
Nas décadas de 1980 e 1990, os bancos de dados relacionais se tornaram a solução dominante
- Ofereciam indexação intuitiva e garantiam eficiência nas consultas
- Os bancos de dados relacionais permitiam representar dados como uma coleção de tabelas com relações estruturadas
- Também possibilitavam recuperação de dados mais rápida por meio de linguagens de consulta como SQL
Os bancos de dados relacionais foram construídos com a premissa de rodar em uma única máquina
- Porém, a adoção em massa da internet nos anos 1990 e 2000 trouxe uma enxurrada enorme de dados, gerando workloads pesadas demais para um único computador suportar
- Os bancos de dados SQL tradicionais foram projetados para rodar em um único servidor, exigindo que os usuários aumentassem o hardware físico de acordo com a necessidade de armazenamento, o que se mostrou muito caro para empresas operando workloads maiores
Na década de 2010, os dados e os usuários de OLTP (processamento de transações online) cresceram exponencialmente, levando a um aumento generalizado de bancos de dados distribuídos, data warehouses e OLAP (processamento analítico online)
Bancos de dados relacionais e SQL já não eram mais adequados para a escala e a complexidade das aplicações necessárias, e os bancos de dados NoSQL surgiram como uma forma de aumentar o desempenho (abrindo mão de recursos ACID)
- Bancos de dados relacionais conseguiam armazenar e manipular dados estruturados, mas era difícil manter relações entre os dados quando se consideravam o overhead de joins e o custo de operações CRUD
- Eles eram adequados para lidar com dados relacionais com requisitos lógicos ou discretos, mas em geral estavam alinhados a sistemas legados construídos especificamente para estruturas relacionais
- O NoSQL surgiu como uma forma de lidar com big data não estruturado, oferecendo persistência de dados aos desenvolvedores por meio de uma abordagem não relacional
- Em vez de usar SQL como linguagem de consulta padrão, o NoSQL oferece acesso via APIs, garantindo maior escalabilidade, computação distribuída, redução de custos e flexibilidade de schema
- Bancos de dados NoSQL funcionam com arquiteturas eficientes que podem escalar horizontalmente, então, para ampliar capacidade de armazenamento ou computação, basta adicionar mais servidores ou instâncias em nuvem
- Para empresas com workloads de dados voltadas a processamento ou análise mais rápida de dados não estruturados, bancos de dados NoSQL passaram a ser a opção preferida

As OG database wars

À medida que a arquitetura de bancos de dados evoluía, certas empresas consolidaram sua posição em cada mercado emergente
- Logo após a IBM lançar o System R, Larry Ellison, então com 33 anos, leu o mesmo artigo de Codd sobre bancos de dados relacionais
- Ellison e seus dois cofundadores tentaram criar uma empresa compatível com o System R, mas a IBM tornou isso muito difícil
- Como resultado, o trio construiu o negócio em torno de um novo produto principal de banco de dados: o Oracle Databases
- Desde então, o banco de dados da Oracle se tornou o produto líder e, em maio de 2024, sua participação de mercado era de cerca de 28,7%
Nos anos que antecederam o IPO da Oracle em 1986, outra empresa entrou no setor de bancos de dados
- A Sun Microsystems começou em 1982 vendendo vários componentes de computador, mas ficou conhecida por contribuições como a linguagem de programação Java, o Network File System e outras
- O ponto importante é que, em 2008, a Sun Microsystems adquiriu o MySQL, um sistema de gerenciamento de banco de dados de código aberto
- Apenas dois anos depois, a Oracle adquiriu a Sun Microsystems (incluindo o MySQL)
- Quase 15 anos depois, em maio de 2024, os bancos de dados líderes são Oracle (28,7% de participação de mercado) e MySQL (cerca de 17,3%)
Embora a Oracle tenha liderado o mundo dos bancos de dados relacionais, a forma como as pessoas armazenam e acessam informações continuou mudando
- A cada novo tipo de trabalho, surgia uma nova arquitetura para administrá-lo
- De document stores como MongoDB (2007) e Databricks (2013) a bancos de dados de séries temporais como InfluxDB (2013) e Prometheus (2012), e bancos de dados em grafo como Neo4j (2007) e Cosmos (2017), a lista de bancos de dados especializados continua crescendo
- À medida que a popularidade dos bancos de dados relacionais diminuía de forma constante, várias soluções foram surgindo para atender a essas novas necessidades de nicho
A evolução mais recente dos bancos de dados surgiu da necessidade de lidar com dados não estruturados
- Ao longo dos últimos mais de 50 anos, schemas foram organizados principalmente em torno de relações de dados estruturados
- Mas cada vez mais pessoas passaram a precisar de ferramentas capazes de lidar muito melhor com a ambiguidade dos dados
- Assim surgiram os bancos de dados vetoriais

A ascensão dos bancos de dados vetoriais

Com a ampla disseminação dos grandes modelos de linguagem (LLMs) e da IA generativa, os bancos de dados vetoriais surgiram como ferramentas capazes de processar dados multimodais não estruturados
- Enquanto os bancos de dados relacionais tradicionais (Postgres, MySQL) são mais adequados para esquemas estruturados, os bancos de dados vetoriais são adequados para armazenar e consultar embeddings vetoriais (representações numéricas de dados que incluem significado em relação aos pesos de um modelo de linguagem)
- Em vez das linhas e colunas normalmente usadas em bancos de dados relacionais, os bancos de dados vetoriais representam os dados como pontos em um espaço multidimensional, fazendo a correspondência com base em similaridade, e não em valores exatos
Dependendo do modelo de embedding, os dados podem ser representados em diferentes espaços vetoriais e com várias dimensões
- Embeddings vetoriais capturam o significado dos pontos de dados, permitindo buscar objetos semelhantes ao recuperar os objetos mais próximos em um banco de dados vetorial
Por exemplo, o Word2Vec mapeia palavras em vetores, ajudando a capturar significado, similaridade semântica e relações contextuais com outros textos
- Esse algoritmo usa uma rede neural rasa para inferir o significado de uma palavra específica a partir de um corpus textual mais amplo e identifica sinônimos por meio de regressão logística
- Também existem métodos que ajudam a extrair embeddings sem depender de redes neurais profundas, como decomposição em valores singulares (SVD) e análise de componentes principais (PCA)
Métricas de distância ajudam a determinar a “distância” relativa entre pontos em um espaço vetorial, e métodos comuns incluem distância euclidiana, distância Manhattan, distância cosseno e similaridade de Jaccard
- K-vizinhos mais próximos (KNN) e vizinhos mais próximos aproximados (ANN) ajudam a simplificar a busca por similaridade em imagens, vídeos ou outras entradas multimodais, melhorando o tempo de execução
Bancos de dados dedicados a vetores, como Weaviate, Chroma, Qdrant e Pinecone, ajudam desenvolvedores a lidar com dados em larga escala, especialmente no que diz respeito a facilitar buscas sobre entradas não estruturadas
- Diferentemente dos bancos de dados relacionais tradicionais ou dos bancos de dados NoSQL, os bancos de dados vetoriais são projetados especificamente para lidar com embeddings vetoriais
- Enquanto os bancos de dados tradicionais armazenam dados como escalares, os bancos de dados vetoriais armazenam apenas vetores e utilizam técnicas de indexação como quantização e clustering para otimizar operações de busca
LLMs baseados em transformers, como o GPT, conseguem capturar dependências de longo prazo no texto
- No entanto, manter a capacidade de compreensão de textos longos pode ser computacionalmente caro
- Os LLMs mais recentes conseguem capturar dependências globais entre pares de tokens ao longo da entrada, mas problemas de recursos computacionais causados pela complexidade de tempo e espaço limitam o comprimento do texto de entrada durante o treinamento e a janela de contexto efetiva durante a inferência
Em casos multidimensionais, a codificação posicional relativa é difícil de implementar, e a maioria das abordagens para codificar posições relativas exige mecanismos robustos de embedding posicional, o que contribui para degradação de desempenho durante a inferência
- Mesmo quando o comprimento do texto aumenta, os bancos de dados vetoriais podem ser importantes por funcionarem como memória de longo prazo do modelo
- O uso de bancos de dados vetoriais pode simplificar tarefas como completação de texto ou sumarização, nas quais o contexto completo da sentença pode ser necessário para gerar resultados precisos
Bancos de dados vetoriais podem dar suporte à geração aumentada por recuperação (RAG), em que podem ser usados para enriquecer prompts enviados ao LLM com contexto adicional junto com a consulta original
- Como os LLMs muitas vezes dependem de modelos de aprendizado auto-supervisionado, frequentemente têm dificuldade com tarefas específicas de domínio que exigem conhecimento especializado ou limiares mais altos de precisão
- O RAG pode ajudar a verificar, rastrear ou explicar como as respostas são derivadas, ao mesmo tempo em que mitiga alucinações que podem surgir da falta de contexto para a consulta em questão
Desenvolvedores podem combinar grafos de conhecimento com busca vetorial para expandir os LLMs além dos dados com os quais foram treinados
- Ferramentas como o GraphRAG, da Microsoft Research, facilitam o aumento de prompts ao realizar buscas em conjuntos de dados privados
- O RAG básico frequentemente tem dificuldade para compreender de forma holística conceitos semânticos resumidos em grandes coleções de dados, por isso ferramentas como LlamaIndex e GraphRAG constroem grafos de conhecimento com base em conjuntos de dados privados
Dependendo dos requisitos específicos ou do caso de uso, pode ser melhor para desenvolvedores usar grafos de conhecimento em vez de RAG
- Bancos de dados vetoriais são adequados para busca por similaridade e mais indicados para busca de documentos ou imagens e geração de recomendações, enquanto grafos de conhecimento são adequados para raciocínio (especialmente úteis na coleta de dados, extração de entidades junto com relações interconectadas e navegação por essas relações)
Para aplicações que exigem processamento de dados em tempo real ou quase em tempo real, bancos de dados vetoriais podem ser preferidos devido a consultas de menor latência
Ao coletar e armazenar embeddings, os bancos de dados vetoriais facilitam buscas mais rápidas por similaridade, fazendo a correspondência entre o prompt de entrada e embeddings semelhantes
O ranqueamento por similaridade ajuda a dar suporte a várias tarefas de machine learning, desde sistemas de recomendação até busca semântica, reconhecimento de imagem e outras aplicações de processamento de linguagem natural
Os bancos de dados vetoriais desempenham um papel importante na melhoria do desempenho dos LLMs ao possibilitar o armazenamento e a recuperação eficientes de embeddings vetoriais
- Isso permite compreender automaticamente a linguagem natural em larga escala
No entanto, embeddings vetoriais representam uma inovação N+1
- Trata-se de uma forma de dados anterior, como dados relacionais ou séries temporais
Fornecedores legados de bancos de dados começaram a lançar recursos vetoriais, como o Atlas Vector Search do MongoDB, o banco de dados vetorial da SingleStore e o índice de busca vetorial da Neo4J
Embora bancos de dados vetoriais possam ser poderosos em casos de uso de IA, eles ainda são uma infraestrutura burra operada por entradas e saídas
- Eles não têm capacidade de entender ou interpretar dados
- Apenas atuam como repositórios que armazenam e recuperam dados conforme instruído, sem inteligência intrínseca nem consciência de contexto
Para aplicações modernas baseadas em IA, isso por si só não será suficiente
- As empresas estão cada vez mais construindo com modelos de IA no centro
- Portanto, à medida que as aplicações passam a exibir capacidades cada vez mais inteligentes, a infraestrutura também precisará dessas mesmas capacidades inteligentes

Empresas AI-Native de 1ª geração

Desde que a academia começou a pesquisar inteligência artificial pela primeira vez no Dartmouth College em 1956, casos de uso práticos vêm impulsionando o avanço desse campo
- Por exemplo, no fim dos anos 1960, Joseph Weizenbaum criou um programa de computador chamado ELIZA, cuja abordagem simples de simulação de conversa por correspondência de padrões foi usada para conversas rudimentares semelhantes a terapia (o primeiro chatbot)
Na maior parte da história do uso de AI em casos de uso de negócios, as melhorias foram graduais
Antes de o termo AI virar moda, o termo machine learning era usado com mais frequência para se referir à mesma tecnologia
- Ou seja, “algoritmos estatísticos que podem aprender com dados e generalizar para dados não vistos, podendo executar tarefas sem instruções explícitas”
Do ponto de vista da percepção pública, a AI atingiu um ponto de inflexão em 30 de novembro de 2022, quando a OpenAI lançou o ChatGPT, mas do ponto de vista técnico a virada aconteceu muito antes
Em novembro de 2017, o órgão regulador internacional Financial Stability Board (FSB) elaborou uma visão geral sobre o impacto do machine learning nos serviços financeiros
- Empresas de serviços financeiros puderam usar cada vez mais machine learning para executar tarefas como “avaliação da qualidade de crédito” e assim “contribuir para um sistema financeiro mais eficiente”
- Em outras palavras, isso podia aumentar a eficiência, mas não constituía uma necessidade existencial
Enquanto isso, o machine learning continuou melhorando e, em maio de 2018, a OpenAI publicou um estudo sobre a história do poder computacional necessário para treinar modelos de grande escala, mostrando que, desde 2012, ele vinha dobrando a cada 3,4 meses, totalizando um aumento de 300 mil vezes
No mês seguinte, em junho de 2018, a OpenAI publicou a primeira apresentação do modelo GPT
Um debate começou a se formar entre dois campos
- De um lado, muitos acreditavam que o crescimento contínuo de modelos cada vez maiores estaria sujeito à lei dos retornos decrescentes
- O outro campo, do qual a OpenAI fazia parte, acreditava que o desempenho continuaria melhorando à medida que a escala aumentasse
Em janeiro de 2020, Jared Kaplan, pesquisador da OpenAI e professor da Johns Hopkins University, publicou com outros autores o artigo “Scaling Laws for Neural Language Models”, que afirmava o seguinte:
- “O desempenho de modelagem de linguagem melhora de forma suave e previsível à medida que escalamos adequadamente o tamanho do modelo, os dados e a computação. Esperamos que modelos de linguagem maiores tenham desempenho melhor e maior eficiência amostral do que os modelos atuais.”
Em maio de 2020, a OpenAI publicou o artigo sobre o GPT-3 intitulado “Language Models are Few-Shot Learners”, que mostrou um escalonamento suave de desempenho conforme a computação aumentava
A OpenAI também descobriu que ampliar a escala melhora a capacidade de generalização, argumentando que “o escalonamento de modelos de linguagem de grande porte melhora muito o desempenho few-shot independente de tarefa, às vezes a ponto de competir com abordagens anteriores de fine-tuning de ponta”
O pesquisador independente Gwern Branwen formulou a hipótese de scaling em um post de blog, dizendo o seguinte:
- “O GPT-3, publicado pela OpenAI em maio de 2020, é a maior rede neural já treinada até hoje, por mais de uma ordem de magnitude... Ao contrário do que muitos esperavam (inclusive eu), esse enorme aumento de escala continuou mostrando os benefícios do tamanho, como a OpenAI previa, e não bateu nos retornos decrescentes nem em retornos negativos que muitos esperavam.”
A surpresa sentida por Branwen refletia uma mudança no cenário
A AI podia ser usada cada vez mais como núcleo do produto de uma empresa, e não apenas como apêndice
A arquitetura Transformer, o aumento no volume de dados e os níveis mais altos de desempenho criaram a base para o desenvolvimento de produtos baseados em AI
Logo após o lançamento do GPT-3, em maio de 2020, empresas como Writer e Jasper criaram produtos de copywriting com modelos de AI no centro do negócio
Empresas como Harvey e EvenUp construíram legal tech em torno de AI
Empresas como DeepScribe e Freed construíram transcrição médica em torno de AI
No entanto, assim como novos casos de uso no passado levaram à evolução dos bancos de dados, o surgimento de produtos baseados em AI significava que a infraestrutura por trás da stack tecnológica de cada empresa precisaria mudar e se adaptar

Banco de dados AI-Native

À medida que empresas baseadas em AI aumentam em número e escala, cresce também a necessidade de ferramentas que deem suporte a casos de uso baseados em AI
A primeira onda de empresas cujo núcleo era AI focou principalmente em inferência usando modelos existentes
- Com ferramentas de workflow orientadas a objetivos para aplicações, copywriting, transcrição médica e outros usos
- O núcleo do produto é a saída, como texto gerado pelo modelo ou imagens geradas
Após o DevDay da OpenAI em novembro de 2023, começou a se espalhar o meme “OpenAI killed my startup”
- GPTs especializados ou agentes de AI pareciam assumir o papel dessas startups iniciais baseadas em AI, já que focavam na inferência de modelos existentes
- A OpenAI acabou se tornando, por acaso, fornecedora tanto do modelo quanto da aplicação
A inovação em torno das capacidades dos modelos avançou tão rapidamente que começou a parecer uma ameaça para startups
Mas, por outro lado, modelos com desempenho melhorado — especialmente modelos open source de fácil acesso — passaram a permitir que empresas construíssem de forma mais profunda suas capacidades como negócios baseados em AI
Construir uma stack tecnológica baseada em AI é mais do que adicionar componentes ao redor de um modelo
- Por exemplo, como seria um banco de dados criado especificamente para AI?
- Se a inferência é uma saída importante, um banco de dados AI-Native não deve apenas armazenar e recuperar dados, mas também ser capaz de receber instruções contextuais sobre o que fazer com os dados armazenados
Um exemplo pode ser a personalização de descrições de produtos para e-commerce
- Um banco de dados vetorial pode armazenar não apenas embeddings vetoriais de SKUs e descrições de produtos, mas também embeddings de personas de usuários
- Usando todos esses dados contextuais do banco de dados, a infraestrutura pode aproveitar um loop de feedback generativo em que uma consulta por uma descrição de produto também aciona uma consulta pela persona de usuário relevante, e então redige a descrição do produto com base nessa persona relevante
Da mesma forma, a linguagem pode ser usada como um loop de feedback generativo
- Por exemplo, o usuário pode querer gerar descrições de produtos em vários idiomas
- É possível gerar descrições de produtos não apenas personalizadas para o usuário, mas também traduzidas para o idioma escolhido por ele
- Esse tipo de instrução pode ser incorporado diretamente ao banco de dados, porque casos de uso como AI generativa estão se tornando cada vez mais uma funcionalidade central das aplicações
Evoluir a infraestrutura para se adequar aos casos de uso não é novidade
- Originalmente, os desenvolvedores usavam JavaScript para criar aplicações no navegador e tornar os sites interativos e dinâmicos
- Mas, quando perceberam que podiam levar isso para o backend, surgiu o node.js
- Depois, à medida que os desenvolvedores começaram a criar mais aplicações móveis, surgiu o JSON (JavaScript Object Notation), permitindo aplicações mais dinâmicas, responsivas e orientadas por dados
- A MongoDB surgiu como uma empresa para atender a essas necessidades de infraestrutura em evolução, encaixando-se perfeitamente nessa onda
Com AI, a história está se repetindo
- À medida que os requisitos mudam, a infraestrutura precisa evoluir para atendê-los
- A grande questão será que tipo de empresa as pessoas querem construir e que tipo de infraestrutura é mais adequado para essas empresas
- Como Bob disse em uma entrevista com Matthew Lynley:
  - “Eu acredito fortemente que todas as aplicações do futuro terão AI. Em algumas aplicações, haverá um pouco de AI espalhado; em outras, a AI estará no centro da aplicação. Se você tirar a AI, ela deixa de existir. Se você quer construir um web app e colocar AI por cima, use MongoDB. Especialmente se você já o utiliza... Se quiser construir uma aplicação AI-Native, em que a AI é o núcleo da aplicação, é hora de considerar a Weaviate.”
Daqui para frente, as empresas decidirão se vão construir produtos com AI como apêndice — ou, como Bob disse, como um “sprinkle” — ou se ela será o núcleo do produto

Stack tecnológica AI-Native

Para empresas que querem construir a IA como componente central do produto, a infraestrutura existente provavelmente não será adequada
- Com ferramentas legadas, o armazenamento, a organização e a execução dos dados são construídos em um silo, enquanto a automação é construída em outro
- A desvantagem dessa abordagem é que o contexto se perde em coisas como loops de feedback gerativo, que podem informar e melhorar melhor o produto
Para empresas que vêm de uma stack “adjacente à IA”, a inferência de um modelo específico muitas vezes fica limitada pela janela de contexto
- Alguns acreditam que, se a capacidade de uma determinada janela de contexto aumentar, ela poderá substituir os bancos de dados vetoriais
- No entanto, é mais provável que seja verdade o cenário oposto, no qual os bancos de dados vetoriais evoluam para substituir a janela de contexto
- Embeddings vetoriais são extremamente importantes para modelos generativos, e a infraestrutura para resultados generativos deve tratar embeddings vetoriais como cidadãos de primeira classe
Em vez de simplesmente aumentar o tamanho da janela de contexto, é possível incorporar um banco de dados vetorial ao modelo para oferecer a compreensão contextual da janela de contexto junto com a confiabilidade e a escalabilidade do banco de dados
- Isso é especialmente relevante porque, quanto mais geral for o modelo, menor a probabilidade de ele ser feito sob medida para uma tarefa específica
- Bancos de dados vetoriais com IA permitirão funcionalidades mais específicas
Modelos generalistas como o GPT-4 foram construídos para generalizar conhecimento de forma intencional
- Se o produto depender de um pouco de fine-tuning simples, o modelo base não será a parte singularmente valiosa daquele negócio
- Construir um produto baseado em IA envolverá, além de aproveitar o modelo, construir o produto em torno de uma stack mais estreitamente conectada
- Essa stack fornecerá a escala do banco de dados e as capacidades do modelo para criar produtos mais competentes

1 comentários

savvykang 2024-07-01

Espero que surjam mais casos de uso para geração de embeddings vetoriais e uso de bancos de dados vetoriais, para que apareça um fluxo de trabalho padrão. Será que basta esperar cerca de um ano?