- Muitos produtos de IA acabam sendo apenas wrappers que chamam modelos externos via API, como o ChatGPT, trazendo para dentro do produto riscos de diferenciação, custo, velocidade e customização
- A abordagem de simplesmente chamar um LLM permite construir rápido, mas qualquer um pode copiar, e se a OpenAI colocar a mesma função no ChatGPT, fica difícil preservar o valor único
- LLMs de uso geral têm alto custo de execução, e isso pode levar a uma estrutura como a do GitHub Copilot, que cobra US$ 10 por mês enquanto custa em média US$ 20, chegando a US$ 80 por mês para alguns usuários
- O Visual Copilot da Builder tentou usar apenas LLMs no processo de converter designs do Figma em código, mas migrou para uma toolchain própria por causa da latência nas respostas e das limitações de qualidade
- Na prática, costuma ser mais rápido, barato e controlável resolver primeiro o problema com código convencional e usar modelos de IA especializados apenas em áreas restritas que são difíceis de tratar com código padrão
Limites da abordagem de wrapper simples com LLM
- Muitos dos produtos de IA criados hoje são mais próximos de wrappers sobre outros modelos, funcionando ao enviar entradas em linguagem natural para a API do ChatGPT e receber saídas em linguagem natural
- É fácil de implementar e permite criar recursos interessantes rapidamente, mas se o valor único do produto estiver em tecnologia avançada de IA, o risco de cópia cresce bastante
- Em apps como os de chat com PDF, quando uma pessoa cria, várias outras fazem algo parecido, e depois a OpenAI coloca isso diretamente no ChatGPT; esse fluxo surge quando falta tecnologia realmente diferenciada
- Se o produto se resume a um botão que envia uma solicitação ao ChatGPT e mostra a resposta ao usuário, sua capacidade de defesa é a mais fraca possível
- Se houver bastante tecnologia própria e o LLM ajudar apenas em uma parte pequena, mas importante, a posição é melhor, embora os problemas de custo e velocidade ainda continuem
Custo e velocidade são restrições reais na hora de virar produto
- Os LLMs ficaram grandes e complexos para ganhar ampla generalidade, e com isso o custo de execução também aumentou
- Segundo o Wall Street Journal, o GitHub Copilot cobrava US$ 10 por mês dos usuários, mas tinha custo médio de US$ 20, e alguns usuários geravam até US$ 80 por mês em custo para o GitHub
- Muitos produtos não precisam de um modelo gigantesco treinado em toda a internet, e 99,9% do escopo de treino pode não ter relação com o caso de uso específico
- Pode acontecer de o custo operacional de um serviço baseado em LLM ser maior do que o valor que o usuário está disposto a pagar
- A velocidade também afeta fortemente a experiência do produto
- Em experiências como a do ChatGPT, em que as palavras aparecem uma a uma, uma saída lenta é relativamente tolerável
- Em apps que precisam da resposta completa antes de seguir para a próxima etapa do fluxo, a latência vira imediatamente perda de usabilidade
- O Visual Copilot da Builder tentou usar transformação por LLM para converter designs em código de alta qualidade, mas o processo de inserir toda a especificação do design e receber uma nova representação token por token levava vários minutos, o que não era prático
- A representação retornada pelo LLM não era algo legível por humanos, então o estado de carregamento acabava parecendo apenas um spinner, prejudicando a experiência do usuário
Só fine-tuning não basta para customizar de verdade
- LLMs oferecem suporte a fine-tuning, então é possível ajustá-los parcialmente para ficarem mais próximos do resultado desejado
- A Builder aplicou fine-tuning à abordagem de usar designs do Figma como entrada e código como saída, mas a qualidade não melhorou mesmo com muitos exemplos
- No fim, virou uma abordagem lenta, cara e de baixa qualidade, o que exigiu outro caminho
- A alternativa escolhida foi criar uma toolchain própria
- fine-tuned LLM
- compilador customizado criado pela própria equipe
- modelo treinado internamente
- Hoje em dia, treinar um modelo próprio não é mais algo restrito a cientistas de dados ou Ph.D.s em machine learning; desenvolvedores com experiência razoável também conseguem fazer isso
- Essa abordagem ajuda a criar produtos mais rápidos, confiáveis, baratos e diferenciados
Produtos de IA complexos são compostos por uma toolchain, não por um único modelo gigante
- Um equívoco comum sobre produtos de IA é achar que toda a tecnologia central fica concentrada em um único modelo inteligente
- Nem carros autônomos funcionam recebendo entradas de câmera, sensores e GPS em uma única IA gigante para então gerar diretamente uma ação como virar à direita
- Na prática, há vários modelos especializados conectados junto com código convencional
- modelos de visão computacional encontram e identificam objetos
- modelos preditivos de decisão estimam o comportamento de outras pessoas
- modelos de processamento de linguagem natural entendem comandos de voz
- muito código e lógica convencionais produzem o resultado final
- Carros autônomos são um caso muito mais complexo, e esse nível de complexidade não é necessário ao iniciar um produto de IA comum
- As funções automotivas também não surgiram prontas de uma vez; começaram com recursos como estacionamento automático e parada automática por proximidade, e depois ganharam camadas como correção de saída de faixa e decisões completas de direção
- Assim como no software, recursos de IA também são construídos empilhando uma camada sobre a outra
Resolva primeiro com código convencional e use IA especializada só onde for preciso
- Um ponto de partida importante na abordagem do Visual Copilot é não usar IA desde o início
- É preciso explorar o espaço do problema com programação convencional e identificar antes onde realmente há necessidade de um modelo especializado
- A abordagem de “supermodelo”, em que grandes volumes de dados do Figma são enviados ao modelo para receber código pronto de volta, é complexa demais
- há muitos frameworks para oferecer suporte
- existem muitas opções de estilo e customização
- é difícil retreinar continuamente para refletir novos dados
- tudo isso pode deixar o produto complexo, lento e caro demais até para ser lançado
- A Builder primeiro explorou até onde conseguiria chegar sem IA
- era necessário transformar cada nó do design em algo representável em código
- foi preciso entender em detalhe elementos como imagens, fundo e primeiro plano
- também foi necessário tratar com precisão como tornar qualquer entrada responsiva
- A equipe criou vários algoritmos sofisticados em lógica escrita manualmente, como tratar itens empilhados verticalmente como
flex columne itens lado a lado comoflex row - A IA só foi adicionada no ponto em que os limites do código padrão apareceram
- detectar automaticamente quais camadas devem ser combinadas em uma única imagem é algo fácil para a percepção humana, mas difícil de resolver com código imperativo em JavaScript
- Tipos de modelo bem estabelecidos, como detecção de objetos, podem ser treinados em produtos como o Google Vertex AI escolhendo opções via GUI, preparando os dados e fazendo upload
- A internet pode ser usada para gerar dados
- abrir sites no navegador com puppeteer e tirar screenshots
- percorrer o HTML em busca de tags
img - usar a posição das imagens como dado de saída e a screenshot da página como dado de entrada
- assim, é possível obter coordenadas de subimagens e a imagem original para usar como dados de treino de um modelo de detecção de objetos
- Ao combinar código com modelos de IA especializados, é possível selecionar um design, clicar em Generate code e, após cerca de 1 segundo de espera, ir para o Builder.io
- No Builder, é possível obter um site totalmente responsivo e código de alta qualidade customizável, com suporte a vários frameworks e opções
Vantagens de produto ao controlar seus próprios modelos
- Quando você tem seus próprios modelos, não fica apenas encapsulando modelos externos; você pode continuar melhorando o modelo ao longo do tempo
- Se depender apenas de modelos externos como os da OpenAI, não há garantia de quando eles ficarão mais inteligentes, rápidos ou baratos para o seu caso de uso específico
- O nível de controle possível só com prompt engineering e fine-tuning também é limitado
- O Visual Copilot ainda está em beta, então há designs que ele ainda não importa bem, mas melhorias são implantadas diariamente com base no feedback dos usuários
- Controlar sua própria tecnologia também ajuda a atender melhor exigências de privacidade
- grandes empresas com foco forte em privacidade frequentemente dizem que não podem usar a OpenAI nem produtos que dependem dela
- há exigências de que os dados não entrem em sistemas não autorizados
- como a Builder controla toda a tecnologia, pode aplicar padrões elevados de privacidade
- A etapa com LLM não é obrigatória; ela é mais opcional e pode ser desativada
- Empresas também podem conectar seu próprio LLM
- modelo totalmente interno
- fork de
llama2 - sua própria instância enterprise do OpenAI
- ou outros modelos
- A IA deve ser usada o mínimo possível, deixando o código convencional como base rápida, confiável, determinística e fácil de depurar, corrigir, manter e testar
- A mágica do produto não vem de substituir tudo por IA, e sim de usar modelos de IA em áreas pequenas, mas decisivas
1 comentários
Opiniões do Hacker News
Concordo com a ideia geral do texto, mas acho que não escolheria a forma de implementação proposta pelo autor
A conclusão que tirei é que não devemos depender demais de LLMs. Isso vale tanto para o escopo das tarefas delegadas quanto para evitar ficar preso a um único LLM específico
Por exemplo, mesmo usando OpenAI internamente, um produto que compete diretamente com o ChatGPT pode ficar em desvantagem no longo prazo. Se você criar um app para reservar hotéis e passagens aéreas por chatbot, há uma grande chance de que, um dia, o ChatGPT, a Microsoft ou o Google ofereçam algo parecido melhor e inviabilizem um pequeno negócio
Também acho perda de tempo depender demais de coisas como o SDK da OpenAI; chamar diretamente a REST API é mais flexível
Mas adicionar um compilador à toolchain é outra questão. Cada vez que você coloca um compilador, aumenta a complexidade desnecessária e a dependência de uma ferramenta específica. Se React ou Svelte já bastam, usar um cross-compiler de componentes parece apenas acrescentar mais uma coisa a aprender para criar uma aplicação web
Acho que a mensagem final do texto deveria ser “crie a toolchain mais eficiente para atingir o objetivo”. Valor não surge por anexar um monte de ferramentas, nem por seguir o modo como os outros fazem; isso vale não só para a integração de apps com LLMs, mas para a engenharia de software em geral
Não sei bem como a IA faria isso de maneira diferente, nem se no fim não esbarraria nas mesmas restrições
Seria algo único e não muito fácil de copiar, mas, considerando as linguagens suportadas, o custo de manutenção seria enorme
Essa camada extra de abstração passa um pouco a sensação de fábrica-de-fábrica-de-fábrica
Na verdade, a IA tem mais espaço para especialização do que a busca de passagens aéreas
Em chatbots para tarefas especializadas, agora que a interpretação básica de linguagem está boa o suficiente, a qualidade do modelo de linguagem de uso geral não é o fator mais importante. Um chatbot de reservas de viagem ajustado às minhas preferências e integrado a APIs de nicho relevantes não será facilmente superado por uma ferramenta genérica que parseia as perguntas um pouco melhor, mas tenta reservar tudo pela Expedia
Nesse tipo de mercado, uma boa ou má recomendação uma única vez também pode gerar fidelidade à marca ou rejeição, então é difícil dizer que será algo próximo de “o vencedor leva tudo”
Esse não era, na verdade, o ponto central do post
O produto deles é uma ferramenta que converte automaticamente arquivos de design do Figma em código React. A forma de resolver esse problema com código comum é justamente um compilador
Eles não estão dizendo que todo mundo deve usar compiladores
Nesse contexto, a crítica a compiladores em geral não se encaixa muito bem. A alternativa é usar o ChatGPT como se fosse um compilador, e o texto argumenta de modo bastante convincente que isso é pior. Ou fico curioso se a ideia é que o próprio produto de gerar código React seja ruim
É um texto que dá o que pensar, e concordo com a ideia de “não use IA pelo maior tempo possível”
A IA é mais bem usada em coisas que só são possíveis com IA. Se existe uma forma de criar uma funcionalidade ou resolver um problema sem IA, é melhor fazer assim
Agora que todo mundo tem acesso quase parecido aos modelos de ponta, bons produtos inevitavelmente serão definidos por coisas que não são IA: elementos à moda antiga como workflow, UI, experiência do usuário e desempenho
Mas não tenho certeza quanto ao conselho de “treine seu próprio modelo”. Pode ser um caminho para tornar o produto rapidamente obsoleto. Pode diferenciar por um tempo, mas se em 6 a 12 meses a OpenAI ou um concorrente com muito dinheiro lançar um modelo muito melhor, esse modelo diferenciado vira dívida técnica na hora
Para uma startup pequena, tentar competir com modelo parece uma grande distração. É parecido com criar o próprio banco de dados em vez de usar Postgres ou MySQL. Claro que é preciso ter um fosso competitivo e um produto difícil de copiar, mas precisa ser uma área em que, com os recursos disponíveis, seja realisticamente possível ser o melhor
Então o ChatGPT apareceu, o trabalho dos concorrentes ficou obsoleto de uma hora para outra, e ele conseguiu alcançar os recursos de IA em poucas semanas
Ele acertou o que deveria construir, mas errou o motivo; no fim, isso trouxe um benefício enorme para o negócio
Diferenciação é, de fato, um fator bem importante
É um bom texto e acho que vai ressoar com a maioria das novas startups de AI. Meu conselho é simplesmente não criar um produto de AI
O enquadramento de “produto X” raramente leva a algo que agregue valor ao cliente. Por exemplo: produto de web3, produto de observabilidade, produto de visão computacional, produto de AI, e assim por diante
Como em qualquer boa ideia de startup, o ponto central é partir de uma necessidade real do usuário, não tentar encaixar um problema em uma tecnologia emergente só porque você quer usá-la. Colocar uma UI em cima de uma tecnologia inflada por expectativas não atende a uma necessidade do usuário
Não digo isso por odiar LLMs, mas a maioria das pessoas que conheço offline odeia interagir com chatbots enquanto produto. Recentemente, durante uma mudança, tive que lidar com bots de suporte ao cliente de fornecedores de energia, água e internet, e todos foram horríveis
Partir de “GPT é incrível” para criar um chatbot personalizado dificilmente resolve uma necessidade real do usuário ou leva a um negócio sustentável
Até mesmo descobrir um problema real o suficiente para justificar o custo tecnológico fica fora da zona de conforto de muitos tecnólogos. Nós presumimos que o problema é real ou, pior, esperamos que seja real, e já pulamos direto para a solução. Porque construir é a área em que estamos confortáveis
Essa postura ou esse processo em si não é necessariamente errado. Em muitos casos em que tecnólogos resolveram problemas reais, o problema verdadeiro acabou surgindo por acaso no processo de construir, iterar e interromper
Portanto, para tecnólogos, a melhor forma de encontrar um problema real pode ser ter um ciclo melhor de lançar-iterar-interromper, em vez de ficar tempo demais na descoberta do problema. Um ciclo em que se observa o uso atual para estimar o futuro e se decide rapidamente o que construir ou não
Depois de ler biografias de vários líderes de tecnologia, passei a ver que a competência central que os diferencia é a capacidade de começar com um MVP muito básico e, em pouco tempo, refinar exponencialmente sua intuição sobre a demanda futura
Já havia chatbots alguns anos atrás, e praticamente todas as grandes empresas tinham uma estratégia para eles. A ideia era reduzir bastante o pessoal de call center e melhorar a experiência do cliente
O problema não era só a qualidade da conversa. Para muitos usuários, o importante não era apenas obter uma resposta para o problema, mas também sentir uma conexão humana, a sensação de que alguém estava ouvindo
O que eu quero é que a questão seja resolvida o mais rápido possível; se estou falando com uma pessoa de verdade ou não, não importa
O motivo pelo qual os chatbots não ajudaram até agora é que eles adicionavam tempo e irritação ao processo. O primeiro passo era fazer o chatbot cuspir um número de telefone ou, com sorte, transferir para um atendente
Obviamente, os chatbots antes da OpenAI eram péssimos. Mas, se os chatbots pós-OpenAI forem realmente excelentes, não vejo por que as pessoas não os usariam
Alguns anos atrás era blockchain. Não sei qual será a próxima, mas já dá para ver a rede de “tecnólogos” do LinkedIn migrando de startups de criptomoedas para startups de AI
Parece uma troca enorme contra a velocidade de lançamento
Quando você levar 6 a 12 meses para lançar, outras equipes talvez já tenham usado modelos hospedados diretamente, iterado duas vezes e construído uma base real de clientes. Nesse momento, você mostra o v0.1 ao primeiro cliente, e ele pode dizer que, na verdade, queria outra coisa
Aí não é só ajustar um pouco o prompt: você precisa recodificar o compilador e a toolchain, de cima a baixo na stack
Se você conhece muito bem os clientes e os requisitos, pode fazer sentido, mas, numa situação tão fácil quanto essa, fico mais cético em relação a por que não validar cedo o conceito com um modelo hospedado, mesmo que ele seja genérico e caro. É aquela questão de que otimização prematura é a raiz de todos os males
Houve muita conversa sobre tecnologia e pipeline, mas isso não significa nada se não houver um produto a construir e um problema a resolver
É parecido com discutir com o usuário se SOAP é melhor que REST. O usuário não se importa com como foi feito
Você está pensando demais do ponto de vista competitivo. Basta construir algo que não seja facilmente replicável
Há várias maneiras de fazer isso, mas, do ponto de vista competitivo, essa é a única regra necessária
Em praticamente todos os mercados verticais, algo próximo de 100% do mercado total ainda está em aberto
Diferenciação técnica é só um pedaço pequeno; primeiro, acho que o importante é alcance
É uma corrida para chegar a 1 bilhão de usuários e, para B2B como nós, talvez uma corrida para chegar a 1 milhão de usuários. Ao mesmo tempo, é uma corrida pelo maior valor — isto é, pelo problema resolvido e pela experiência do usuário —, não uma corrida pelas melhores especificações técnicas
Se o diferencial é algo que outra pessoa não consegue replicar usando OAI, então é seguro usar OAI
Se o único diferencial é usar OAI, então já era de qualquer forma
Em conclusão, concordo em geral com o estado proposto. Nosso produto também usa LLM dentro de um fluxo de controle como uma máquina de estados, e funciona bem
Mas não concordo com o sentimento do autor. Se você é um desenvolvedor que só usou a UI web do ChatGPT, precisa 100% mexer e construir tecnologia de “wrapper de AI”
Porque, antes de descobrir diretamente os limites dos modelos de ponta, fica difícil enxergar onde e como usar LLMs dentro de uma stack de software tradicional
A empresa do autor também parece ter trilhado esse caminho no fim das contas. No começo, criou um protótipo baseado em LLM que convertia do Figma para código e, depois que funcionou “até certo ponto”, encontrou as lacunas do processo
Então acho melhor criar algo como um “sistema de avaliação de cartas colecionáveis baseado em AI” com GPT-4-Vision, ou o que você quiser, e depois descobrir como transformar isso em um produto real que funcione, como a builder.io
Parece que em breve a IA será incorporada a vários softwares. Aí vai ficar realmente incrível — e assustador
Um exemplo simples é um cliente de e-mail. Quando alguém pede uma decisão ou confirmação, a IA pode extrair a pergunta e apresentar botões de opção
Ex.: aceitar um horário sugerido: [sexta-feira 10:00] [segunda-feira 11:30] [sugerir outro horário]
George está perguntando se pode apresentar o rascunho: [sim] [não]
Softwares de tickets de suporte ao cliente, como o Zendesk, aparentemente já têm IA. É bem provável que muitas solicitações de suporte já estejam sendo respondidas quase automaticamente
Departamentos de RH também poderiam usar IA para filtrar candidaturas, pesquisar na internet informações adicionais sobre os candidatos e então criar registros padronizados em um banco de dados. Claro, isso pode ter muitas falhas
O interessante são aplicações desse tipo, não mais uma extensão ou plugin do ChatGPT
A ideia é executar um pipeline para cada novo e-mail e fazê-lo sugerir algumas ações
Ainda estou avaliando várias abordagens mentalmente, mas já parece bastante viável
A introdução parece um pouco floreada e exagerada demais. Por exemplo, LLMs não são tão caros assim, a alegação do WSJ de que o Copilot dá prejuízo por usuário não me parece muito convincente, e também é difícil dizer que LLMs sejam sempre “dolorosamente lentos”
Ainda assim, as recomendações reais do texto são bem razoáveis
A ideia é tratar o máximo possível com código e usar IA especializada nas partes que não podem ser feitas com código
É razoável, mas não é algo especialmente novo
Eu esperava que o texto se aprofundasse mais em como criar produtos de IA realmente úteis e bons. Houve muitas tentativas recentes, como o lançamento da Humane, mas ainda não parece haver muitos sucessos
O texto é bem focado em como criar produtos de IA, mas, pessoalmente, acho que o sucesso ou fracasso de um “produto de IA” depende mais de ele ser realmente útil do que de diferenciação, custo, velocidade ou customização do modelo
Infelizmente, a maioria dos produtos que vi até agora parece uma solução em busca de um problema
Acho que o caminho que as empresas deveriam seguir agora é encontrar as partes mais tediosas e repetitivas do uso de seus produtos e descobrir uma forma de simplificá-las de maneira confiável com IA
Como em todo ciclo de hype, quando tudo o que você tem é um martelo, tudo parece prego
O martelo de pouco tempo atrás era o blockchain; agora é a IA
Se você foi ingênuo o bastante para cair nas promessas do blockchain, é natural se decepcionar ao descobrir que a IA não é um esquema de enriquecimento rápido em forma de pirâmide que permite ganhar milhões de dólares sem tempo, energia ou pensamento original
Se é só isso que você procura, vai continuar se decepcionando — e com razão
A IA tem muito mais a oferecer do que o blockchain. Comparar os dois no mesmo nível significa não entender direito nenhum dos dois