Tentando não ficar pobre antes de ficar rico criando uma Startup de serviços de inteligência artificial

Uaaauu! Que texto sensacional :D

Eu to criando uma aplicação usando a API do ChatGPT e percebi o mesmo problema que mencionasse de a API da OpenAI demorar muito para ser chamada enquanto o espaço em memória utilizado pela requisição é beeeem baixo.

Eu to usando o AWS Lambda, que permite ter uma bom limite de requisições gratuítas, mas nunca tinha parado pra pensar tanto sobre o custo de tempo de requisição. Eu não acho que tenha sido uma má escolha usar Serverless, porque permitiu eu de forma bem rápida construir o que precisava e integrar com a API da OpenAI.

E eu também havia reparado no problema de as atualizações e a documentação sobre a API da OpenAI parecem vir primeiro para ecossistema Python do que o Node.js. Tanto que a funcionalidade de Streaming, não está disponível na biblioteca oficial da OpenAI de Node.js, existindo apenas na de Python.

Me desse uma ideia interessante agora sobre a questão de dividir a API entre uma com Node e outra em Python, onde a que utilizaria Python, seria uma dedicada a integração com a OpenAI e a um servidor que os preços não cobrem por tempo de utilização ou que pelo menos cobrem mais barato. Enquanto uma outra para manter em Serverless, que realmente precise ser rápido.

Aliás, chegasse a dar uma olhada no Railway? Já havia ouvido falar do Render, mas não sei se em relação a custo-benefício acabasse percebendo que o Render era a melhor opção entre outras. Adoraria saber sobre isso =)

Além disso, to usando uma infraestrutura parecida com a sua, onde também uso o Firestore como DB, porém fiquei pensando se era uma decisão boa a longo prazo, se não seria melhor já colocar essas informações num MongoDB para que pudesse escalar de uma forma que não gastasse tanto dinheiro quanto deixando num Firestore da vida. Mas no meu caso eu pensei bastante em um estratégia de Offline-App, onde a maior parte das coisas ficaria salvo num banco de dados local ou cache do Aplicativo, e atualizaria com algum tipo de evento, como uma adição ao Banco de Dados remoto.

Post muito massa! É bom ver algo que fuja do padrão "IA vai roubar emprego" ou "IA é maligna".

Putz isso vai ser extremamente dificil kk

Exemplo: ‘Quanto custa 1kg do seu produto?’ ou ‘Quanto custa 1g do seu produto?’.

Já trabalhei com NLP, sem IA, a sugestão que eu vou dar é baseado no que eu já fiz no passado.

Basicamente tu pode fazer o mesmo que a gente faz com parsing de linguagem de programação (coisa que já fiz também), quebra o texto em tokens, por exemplo:

[str("Quanto"), str("custa"), number("1"), str("kg"), str("do"), str("seu"), str("produto"), str("?")]

Aqui tem várias decisões que você pode fazer também, você pode já no processo de criação de tokens determinar algumas keywords, como as linguagens fazem, e ai tua palavra kg já poderia vir com um tipo diferente:

[str("Quanto"), str("custa"), number("1"), mass_unit(KG, str("kg")), str("do"), str("seu"), str("produto"), str("?")]

ai você pode tirar também as stopwords para simplificar:

[str("Quanto"), str("custa"), number("1"), mass_unit(KG, str("kg")), str("produto"), str("?")]

Detalhe, na hora de armazenar os tokens, a gente não armazena as substrings, só os ranges, isso é crucial para qualquer lexer e parser feito na mão. Exemplo, a palavra custa fica armazenada como Token(range: [7..12], type: Str), e mass_unit ficaria: Token(range: [14..16], type: MassUnit), sem nenhuma string sendo armazenada.

Isso traz muitos ganhos de desempenho, por n ter q copiar string, e pouco custo de memória, pois você está armazenado ali por volta de 3 valores de 64-bit — pelo menos no exemplo que eu forneci com range tendo start e end, e o campo type (no total 3).

Caso queira armazenar um "ponteiro" para essa String (ou string slice), ai seriam 4 campos de 64-bit, mas vai depender se a linguagem copia a String ou apenas referencia ela, ou se suporta ponteiros. Mas isso é só uma conveniência, alguns lexers preferem ter um método get(str) e ai eles retornam a substring a partir daquela string que foi passada ao metodo, ou seja, eles esquecem completamente o input e só trabalham com ranges.

Depois tu meio que vai ter duas opções, você pode fazer um matching na mão com lookahead e lookbehind (era o que a gente fazia), ou já pode progredir para um sistema de regras e criar uma estrutura composta (ou uma Syntax Tree simplificada), um exemplo de regra seria (em pseudo-EBNF e bem simplificada mesmo):

texts    = text+ ;
text     = mass | massUnit | str ;
mass     = NUMBER, massUnit ;
massUnit = KG | G ;
str      = ALPHA

KG     = "kg" | "kilograma" | "quilograma";
G      = "g"  | "grama";
NUMBER = [0-9]+;
ALPHA  = [A-Za-z]+;

E ai no final você teria uma estrutura de dados tipo assim:

texts([text(str("Quanto")), text(str("custa")), mass(number(1), mass_unit(KG)), text(str("produto")), text(str("?"))])

Com isso você já pode fazer muita coisa, ai deixo para sua imaginação kkkk, não conheço o Pinecone e nem se seria possível fazer ele não comparar trechos do texto, outra opção seria fazer obfuscação com um hash dos trechos com unidades de medida, por exemplo:

Quanto custa LztgJ2EO8YcNEcjipENcYA do seu produto?

E ai qualquer pequena mudança nesse trecho já afetaria a distância de forma perceptível.

Só que o que eu acho que é mais dificil é na verdade outras coisas, até aritmética daria para fazer esse tricky que eu comentei, mas teriam muitos corner cases, você teria que fazer a mesma ideia com estados, tipo SP e SC são muito próximos, depois água e águia, e assim por diante. Seria possível minar todos os casos e classificar? Não, mas com o tempo conseguiria diminuir bastante os corner cases e deixa-los mais raros. E teria q ter uma forma de fazer isso com agilidade e de capturar quando isso ocorre também (Levenshtein distance caberia aqui para você logar os casos), e levaria muito tempo — os mais comuns seriam faceis, o resto teria que ser na base do uso e descoberta.

Eu ainda não li mas só o título ficou genial kkk

Finalmente o projeto saiu do papel e ganhou sua interface final https://guruduno.site/.

Ferramentas

• Ouça versões em áudio de perguntas e respostas fornecidas pelo público, disponíveis em um repositório compartilhado.
• Use sua voz para enviar suas perguntas
• Acesso às regras oficiais do jogo

Tecnologias usadas

• Firebase do Google:
  – Firestore: armazene as perguntas em tempo real
  – Host: Hospede os ativos do projeto
  – Functions: Após a inserção de uma nova pergunta no Firestore, há um gatilho para enviar os dados da pergunta para o app backend do Render.
• Render: Hospede o aplicativo Flask para solicitar respostas da API OpenAI.
• Ionic: versão Ionic React para criar a tela do app e consumir os dados do Firestore.
• Pinecone: armazene os dados de incorporação gerados pelo modelo ‘text-embedding-ada-002-v2’ da API OpenAI.
• API OpenAI (modelo 'gpt3.5-turbo'): responda às perguntas do usuário.

mano, essa tecnologia é alienígena? parabéns pela idéia e arquitetura, no meu conhecimento básico me pareceu genial! eu