Modelo da Phind supera o GPT-4 em programação com velocidade de GPT-3.5 e contexto de 16k

• Artigo intitulado 'Modelo da Phind supera o GPT-4 em programação com velocidade de GPT-3.5 e contexto de 16k'
• O modelo da Phind supera o GPT-4 em tarefas de programação, mantendo a velocidade do GPT-3.5 e um contexto de 16k
• Site www.phind.com, é necessária uma verificação de segurança antes de acessar
• O site informa que o navegador do usuário está desatualizado e precisa ser atualizado
• Mais informações sobre suporte a navegadores estão disponíveis na página para desenvolvedores da Cloudflare
• O desempenho e a segurança do site são fornecidos pela Cloudflare

[GN⁺]

Opiniões do Hacker News

• Comparei Phind e GPT-4 por alguns minutos com uma pergunta de design de alto nível, bastante vaga, sobre uma fila de tarefas distribuída. O Phind recomendou ativamente bibliotecas específicas relacionadas à implementação, que batiam bem com a minha pesquisa, e também deu código de exemplo usando as bibliotecas recomendadas.
  O Phind anexou várias fontes relevantes, como GitHub e Stack Overflow, o que foi bom como ponto de partida para uma investigação posterior, e as sugestões de perguntas de acompanhamento também foram bem boas.
  Ainda assim, o GPT-4 teve qualidade de resposta melhor e pareceu um candidato melhor para uma entrevista de design de sistemas. Ele abordou até contextos fora da pergunta, como logging e métricas, entendeu melhor a “pergunta por trás da pergunta” e, nas perguntas de acompanhamento, deu mais a sensação de ir estreitando a direção da conversa.
  Isso não foi um teste de capacidade de programação, como implementação de algoritmos, mas uma comparação como ferramenta de apoio ao raciocínio para design de alto nível e decisões de arquitetura.

  • O GPT-4 é realmente bom, em comparação com outros modelos, em captar a “pergunta por trás da pergunta”, e foi muito útil até para tarefas arbitrárias sobre as quais eu não sabia nada, como consertar uma parede em casa.
  • Fico curioso se as várias fontes fornecidas pelo Phind, como GitHub e Stack Overflow, eram de fato corretas.
  • Também seria preciso deixar claro se havia instruções personalizadas, para que a comparação não fique só no anedótico. O prompt também deveria ser publicado.
  • A parte de “dar contexto” tem muito a ver com escrever bem o prompt para o modelo. Para comparar de forma justa, seria preciso dar apenas o código e ver o que ele produz.
  • Seria bom se você compartilhasse parte do prompt usado para fazer a pergunta.

• Fiz uma pergunta-armadilha que costumo fazer a LLMs: “me dê 5 artigos e códigos recentes de machine learning que usem dados geoespaciais como GeoJSON como entrada e saída”.
  Pelo que entendo, esse campo de pesquisa recente não existe, dados geográficos são descontínuos e, portanto, inadequados para transformers, além de serem dependentes de contexto, o que também os torna difíceis para outras abordagens. Aceito uma explicação melhor de um especialista real em machine learning.
  Normalmente, LLMs inventam 5 artigos e códigos inexistentes, mas o Phind trouxe 5 links reais e explicou por que eles não eram artigos+código que usam dados GIS; foi a melhor resposta que recebi até agora.

  • Não sei o que isso tem a ver com um modelo de código. Modelos de código não são treinados para pesquisar artigos ou textos, e sim para completar código; procurar alucinações em uma tarefa não relacionada não é muito interessante.
  • ChatGPT 4 com navegação web: https://chat.openai.com/share/19a425b5-ed37-469e-860d-65ee70...
    ChatGPT 4 sem navegação web: https://chat.openai.com/share/7e11b4a6-52f2-441a-8614-7266c3...
  • Alguns trabalhos de GIS usam dados vetoriais de pontos, linhas e polígonos, como localização de estradas ou contornos de edifícios, que podem ser armazenados em formatos como GeoJSON ou WKT.
    Já dados de sensoriamento remoto ou imagens de satélite podem ser armazenados em formatos raster, como GeoTIFF, que na prática são imagens TIFF com informações de georreferenciamento.
    Machine learning em imagens de satélite em que tanto a entrada quanto a saída são dados geoespaciais é totalmente possível. Por exemplo, em classificação de uso do solo, a entrada pode ser uma imagem multiespectral e a saída uma imagem em que o valor de cada pixel representa o uso do solo identificado.
    Machine learning também pode ser usado para detectar footprints de edifícios e extrair contornos a partir de imagens de satélite, e os polígonos de saída podem ser armazenados em GeoJSON. Acho que esses casos se enquadram como exemplos de “machine learning que usa dados geoespaciais como entrada e saída”.
    [1]: https://azure.microsoft.com/en-us/blog/how-to-extract-buildi...
  • Também vale conferir o EarthPT: https://arxiv.org/abs/2309.07207

• É bom ver a concorrência aumentando, mas ainda acho que o GPT-4 é melhor. Quando pedi uma query para preencher teaser com aproximadamente as primeiras 200 palavras de full_text em uma tabela PostgreSQL, o Phind respondeu criando uma função PL/pgSQL separada que contava palavras com um loop, enquanto o GPT-4 sugeriu uma query que fazia o UPDATE diretamente com generate_series e STRING_AGG.

  • Ativar “Ignore Web Context” pode melhorar o desempenho nesse tipo de tarefa de design. Recebi uma resposta mais plausível, e a consistência é algo em andamento: https://www.phind.com/search?cache=f0fkv5mxscwvagxgkuwnwgtl
  • Um único exemplo não é suficiente para tirar uma conclusão de desempenho.
  • Perguntando de forma simples e clara, recebi uma resposta como UPDATE your_table SET teaser = substring(full_text from '(\S+\s*){1,200}').
  • Eu detesto teasers de artigos e botões “leia mais”, e agora sei que eles são resultado de cortar o texto de propósito.

• Fiquei me perguntando se a afirmação de que “é possível chegar a 100 tokens por segundo em um único stream, enquanto o GPT-4 faz, na melhor das hipóteses, cerca de 20 tokens por segundo” é resultado do uso de processamento em lote. Se for, é bem impressionante.
  A parte de que o Phind Model pode precisar de mais tentativas de geração do que o GPT-4 para chegar à resposta correta em perguntas difíceis parece, em parte, um problema de ajuste do sampler.
  Se ainda não estiverem usando, deveriam olhar para amostragem baseada em gramática (https://github.com/ggerganov/llama.cpp/pull/1773) e amostragem dinâmica como mirostat e dynatemp (https://github.com/LostRuins/koboldcpp/pull/464).
  Mesmo na implementação da Nvidia, parece que funcionaria se apenas a amostragem fosse trocada pela versão da Hugging Face, e poder implementar diretamente esse tipo de recurso experimental é uma grande vantagem de se afastar da OpenAI.

  • Para atingir 100 tokens por segundo no H100, eles usam o Flash Decoding do TensorRT-LLM: https://crfm.stanford.edu/2023/10/12/flashdecoding.html
  • Não sei se esse número é impressionante. Considerando que o LMDeploy afirma passar de 2000 tokens por segundo em A100 com tamanhos de lote grandes, 100 tokens por segundo em H100 parece bem lento.

• Uso bastante o GPT-4, e o Phind surpreendentemente ficou no mesmo nível do GPT-4 em várias tarefas de programação que testei de primeira. Considerando a janela de contexto longa do Phind, parece possível que ele supere o GPT-4 em algumas tarefas, e é um avanço considerável, bem impressionante.

  • Como referência, a janela de contexto padrão do GPT-4 via ChatGPT em breve deve mudar para 32k.

• Gosto do fato de o Phind citar as fontes do que recuperou. Acho que isso deveria ser obrigatório em todos os LLMs, e por isso costumo recomendar o uso do Phind em vez do ChatGPT.

  • O que ele cita não é o conteúdo que o LLM “raspou”, mas o conteúdo que o modelo de busca colocou no LLM. Não há garantia de que aquilo tenha sido usado na saída real, nem que represente todo o conhecimento necessário para gerar a resposta.
    O conhecimento está distribuído em milhões de exemplos que ensinaram linguagem e linguagem humana, e não fica preservado de uma forma compreensível para humanos.
  • Do ponto de vista do usuário, é melhor receber a resposta certa do que links. Não estou dizendo que o Phind seja ruim, mas, antes de impor restrições a LLMs que ainda estão em estágio inicial, é preciso focar primeiro em fazê-los acertar de fato.

• Há algum tempo comparei o Phind com o GPT-4 pedindo que eles usassem um programa que eu mesmo escrevi; o Phind não entendeu direito o que eu queria, enquanto o GPT-4 entendeu perfeitamente e estava pronto para continuar o prompt e concluir o trabalho.
  https://www.phind.com/agent?cache=cloeowfla000dl1084ermly3c
  vs
  https://chat.openai.com/share/4147da33-3669-4657-88fa-3a9dfc...
  Talvez isso não represente o todo, mas ele acabou indo para coisas estranhas que eu não pedi e para informações básicas que eu já sabia.

  • O modo Pair Programmer atualmente usa GPT-4 ou, se o limite tiver sido esgotado, GPT-3.5. Para usar o Phind Model, é preciso tentar de novo no modo de busca padrão.
    Usando o Phind Model na busca padrão, parece funcionar bem: https://www.phind.com/search?cache=ln6dpdtv5auwn4cq1ofg3gs9
  • O problema é que ele pesquisa um assunto relativamente de nicho e provavelmente traz resultados de baixa qualidade. O texto recuperado pela busca pesa mais do que no modelo-base; se esse contexto não ajuda muito, o desempenho acaba piorando.
    Dá para ver esse fenômeno também na busca Bing do ChatGPT, e já passei por isso no meu projeto.

• É surpreendente que o CodeLlama dê suporte a até 16k tokens. A janela de tokens é uma das limitações para criar uma IA que se lembre do usuário e dê continuidade a conversas anteriores.
  Em futuros apps de IA com conversas longas que se estendam por semanas, meses ou anos, uma grande janela de contexto será essencial. A tecnologia já é impressionante hoje, mas ficará ainda mais interessante quando ela conseguir lembrar tudo o que aprendeu e fez junto com você no passado, como um verdadeiro programador pareado.
  [0] https://huggingface.co/docs/transformers/main/model_doc/llam...

  • 640k deve ser suficiente para qualquer pessoa.
  • Com abordagens como o MemGPT, o tamanho da janela de tokens está sendo virtualizado, então esse impacto deve diminuir.
  • Estou esperando o dia em que uma memória de médio prazo, como o pooling médio de tokens dos sentence transformers, seja usada para esse fim. Parece estar óbvio diante de todas as empresas, mas ninguém parece disposto a implementar.

• Sei que não é popular, mas eu gostaria que houvesse uma forma de usar isso dentro do Emacs ou do Vim. Não quero mais usar o VS Code

  • A tendência dos últimos anos de tudo se padronizar em torno do VS Code é uma das mudanças que eu realmente lamento. É bom que o VS Code exista, mas estamos caminhando para um mundo em que, para usar as melhores ferramentas, é preciso usar o VS Code
    Foi assim com o IntelliJ no desenvolvimento Java, e acho que isso não foi nada saudável para o ecossistema. Fico muito feliz que o Copilot dê suporte ao Vim, mas me preocupo que em breve isso deixe de ser verdade
  • Eu gostaria que a profundidade do afeto pelo Emacs fosse mais valorizada pelo mercado
    Por exemplo, há o argumento de que música e arte acabam sendo niveladas por baixo porque é muito mais lucrativo fazer um álbum que vale 10 dólares para dezenas de milhões de pessoas do que um álbum que vale um milhão de dólares para algumas dezenas
    Afinal, o preço de um álbum acaba sendo definido em 10 dólares; só agora me dei conta de que o mesmo fenômeno também se aplica a ferramentas de desenvolvimento
  • No Vim, tentei chegar até :'<,'>y|call system('firefox ?q='.shellescape(@*).' &') para criar um atalho que envie o texto selecionado ao Phind ou a outro LLM
    O problema restante é que o texto não fica codificado em URL, e provavelmente há uma forma elegante de fazer isso, mas ainda não encontrei
  • Com base no exemplo de Copilot de outra pessoa, montei meio às pressas uma integração básica da API ollama no Emacs para autocompletar código de forma simples com um LLM local
    Em um Mac M1, normalmente leva cerca de 7 segundos por inferência, mais lento do que eu gostaria, e o contexto enviado também é bem simples, mas ainda assim é minimamente utilizável
    Eu dependia de uma façade em Python para trocar requisições e respostas no estilo Copilot com o ollama, então não pretendia publicar, mas, se houver interesse, posso lapidar e disponibilizar
  • Pelo que sei, o GitHub Copilot tem integração com Emacs/Vim

• Fiz uma comparação rápida e os resultados são excelentes; considerando ainda a vantagem de vir com busca na web e referências, ele é parecido com o GPT-4, só que mais rápido. Ainda assim, há duas pequenas ressalvas
  No modo escuro, a fonte do corpo das respostas é grossa e clara demais, o que dificulta ler parágrafos longos que não sejam código; no modo claro, tudo é claro demais. Para textos longos, eu preferiria um fundo escuro cinza como o da OpenAI ou um fundo claro sépia como o do HN
  Também fica confuso o que significa GPT-4 em “500+ usos por dia do melhor modelo (GPT-4)” na página de preços. Parece estranho a Phind anunciar que é concorrente do GPT-4 e, ao mesmo tempo, listar uso de GPT-4 no preço

  • O GPT-4 também é oferecido como modelo de resposta, para que o usuário possa escolher conforme o caso de uso. Ainda assim, para a maioria dos usuários, recomendamos o Phind Model