Modelo de Phind supera a GPT-4 en programación con la velocidad de GPT-3.5 y contexto de 16k

• Artículo titulado 'El modelo de Phind supera a GPT-4 en programación con la velocidad de GPT-3.5 y contexto de 16k'
• El modelo de Phind supera a GPT-4 en tareas de programación, manteniendo la velocidad de GPT-3.5 y un contexto de 16k
• El sitio web www.phind.com requiere una revisión de seguridad antes de acceder
• El sitio web informa que el navegador del usuario es una versión antigua y necesita actualizarse
• Se puede consultar más información sobre compatibilidad de navegadores en la página para desarrolladores de Cloudflare
• El rendimiento y la seguridad del sitio web son proporcionados por Cloudflare

[GN⁺]

Opiniones de Hacker News

• Comparé durante unos minutos Phind y GPT-4 con una pregunta de diseño de alto nivel bastante vaga sobre una cola de trabajos distribuida, y Phind recomendó activamente bibliotecas concretas relacionadas con la implementación, que encajaban bien con mi investigación, y también dio código de ejemplo usando las bibliotecas que recomendó.
  Phind agregó muchas fuentes relevantes, como GitHub y Stack Overflow, lo que lo hacía útil como punto de partida para investigar después, y sus sugerencias de preguntas de seguimiento también fueron bastante buenas.
  Aun así, GPT-4 tuvo mejor calidad de respuesta y, si fuera una entrevista de diseño de sistemas, habría parecido un mejor candidato. Cubrió contexto fuera de la pregunta, como logging y métricas, captó mejor “la pregunta detrás de la pregunta” y en las preguntas de seguimiento dio más la sensación de ir acotando la dirección de la conversación.
  Esto no fue una prueba de capacidad de programación como implementar algoritmos, sino una comparación como herramienta de apoyo al razonamiento para decisiones de diseño y arquitectura de alto nivel.

  • GPT-4 realmente detecta muy bien “la pregunta detrás de la pregunta” en comparación con otros modelos, y fue muy útil incluso para tareas arbitrarias de las que no sabía nada, como reparar una pared de la casa.
  • Me da curiosidad si las abundantes fuentes que proporcionó Phind, como GitHub y Stack Overflow, eran en realidad correctas.
  • También habría que aclarar si había instrucciones personalizadas para que la comparación no quede solo en una anécdota. También deberían publicar el prompt.
  • La parte de “dar contexto” tiene mucho que ver con la forma de escribir buenos prompts según el modelo. Para comparar de forma justa, habría que darle solo el código y ver qué produce.
  • Sería bueno que compartieras parte del prompt con el que hiciste la pregunta.

• Le hice una de las preguntas trampa que suelo hacer a los LLM: “dame 5 papers y código recientes de machine learning que usen datos geoespaciales como GeoJSON tanto de entrada como de salida”.
  Tengo entendido que no existe un campo de investigación reciente así, y considero que los datos geográficos son discontinuos, por lo que no son adecuados para transformers, y además dependen mucho del contexto, así que también son difíciles para otros enfoques. Seguiré una mejor explicación de un experto real en machine learning.
  Normalmente, los LLM inventan 5 papers y repositorios de código inexistentes, pero Phind dio 5 enlaces reales y además explicó por qué esos no eran papers + código que usaran datos GIS, y fue la mejor respuesta que he recibido hasta ahora.

  • No veo qué tiene que ver esto con un modelo de código. Un modelo de código no está entrenado para buscar papers o textos, sino para completar código, y encontrar alucinaciones en una tarea no relacionada no es muy interesante.
  • ChatGPT 4 con navegación web: https://chat.openai.com/share/19a425b5-ed37-469e-860d-65ee70...
    ChatGPT 4 sin navegación web: https://chat.openai.com/share/7e11b4a6-52f2-441a-8614-7266c3...
  • Algunas tareas de GIS usan datos vectoriales de puntos, líneas y polígonos, como ubicaciones de caminos o contornos de edificios, y pueden almacenarse en formatos como GeoJSON o WKT.
    En cambio, los datos de teledetección o las imágenes satelitales pueden almacenarse en formatos ráster como GeoTIFF, que en la práctica son imágenes TIFF con información de georreferenciación adjunta.
    El machine learning con imágenes satelitales, donde tanto la entrada como la salida son datos geoespaciales, es totalmente posible. Por ejemplo, en la clasificación de uso del suelo, la entrada puede ser una imagen multiespectral y la salida una imagen en la que el valor de cada píxel representa el uso del suelo identificado.
    También se puede usar machine learning para la detección de footprints de edificios y extracción de contornos a partir de imágenes satelitales, y los polígonos de salida pueden almacenarse como GeoJSON. Creo que estos son ejemplos de “machine learning que usa datos geoespaciales como entrada y salida”.
    [1]: https://azure.microsoft.com/en-us/blog/how-to-extract-buildi...
  • También vale la pena revisar EarthPT: https://arxiv.org/abs/2309.07207

• Me alegra que haya más competencia, pero todavía creo que GPT-4 es mejor. Cuando pedí una consulta para llenar teaser con aproximadamente las primeras 200 palabras de full_text en una tabla de PostgreSQL, Phind respondió creando una función PL/pgSQL separada que cuenta palabras con un bucle, mientras que GPT-4 propuso una consulta que hace directamente el UPDATE con generate_series y STRING_AGG.

  • Si lo ejecutas con “Ignore Web Context” activado, puede mejorar el rendimiento en este tipo de tareas de diseño. Recibí una respuesta más convincente, y la consistencia es algo en lo que se está trabajando: https://www.phind.com/search?cache=f0fkv5mxscwvagxgkuwnwgtl
  • Un solo ejemplo no alcanza para sacar una conclusión sobre el rendimiento.
  • Al preguntarlo de forma simple y clara, recibí una respuesta como UPDATE your_table SET teaser = substring(full_text from '(\S+\s*){1,200}').
  • De verdad odio los teasers de artículos y los botones de “read more”, y ahora sé que son el resultado de recortar deliberadamente ese texto.

• Me da curiosidad si eso de que “con un solo stream puede llegar a 100 tokens por segundo, mientras que GPT-4, en el mejor de los casos, ronda los 20 tokens por segundo” es resultado de usar procesamiento por lotes. Si es así, es bastante impresionante.
  La parte de que Phind Model podría necesitar más intentos de generación que GPT-4 para llegar a la respuesta correcta en preguntas difíciles parece, en parte, un problema de ajuste del sampler.
  Si todavía no lo están usando, deberían mirar el muestreo basado en gramática (https://github.com/ggerganov/llama.cpp/pull/1773) y el muestreo dinámico como mirostat y dynatemp (https://github.com/LostRuins/koboldcpp/pull/464).
  Incluso en la implementación de Nvidia, parece que funcionaría con solo cambiar el muestreo por la versión de Hugging Face, y poder implementar directamente este tipo de funciones experimentales es una gran ventaja de alejarse de OpenAI.

  • Para lograr 100 tokens por segundo en H100, aprovechan Flash Decoding de TensorRT-LLM: https://crfm.stanford.edu/2023/10/12/flashdecoding.html
  • No sé si esa cifra sea impresionante. Si pensamos que LMDeploy afirma superar los 2000 tokens por segundo con A100 y tamaños de lote grandes, 100 tokens por segundo en H100 se siente bastante lento.

• Uso mucho GPT-4 y, en varias tareas de programación que le lancé de entrada, Phind sorprendentemente estuvo a la par de GPT-4. Considerando la ventana de contexto larga de Phind, parece posible que en algunas tareas incluso supere a GPT-4, y me parece un logro considerable e impresionante.

  • Como referencia, la ventana de contexto predeterminada de GPT-4 a través de ChatGPT pronto cambiará a 32k.

• Me gusta que Phind cite las fuentes de lo que recupera. Creo que debería ser obligatorio para todos los LLM, y por eso suelo recomendar usar Phind en vez de ChatGPT.

  • Lo que cita no es contenido que el LLM “recuperó”, sino contenido que el modelo de búsqueda le pasó al LLM. No hay garantía de que realmente lo haya usado en la salida, ni representa todo el conocimiento necesario para generar la respuesta.
    El conocimiento está distribuido entre millones de ejemplos con los que aprendió el lenguaje y el lenguaje humano, y ni siquiera queda almacenado de una forma comprensible para las personas.
  • Desde el punto de vista del usuario, es mejor recibir la respuesta correcta que recibir enlaces. No digo que Phind sea malo, pero antes de imponer restricciones a los LLM, que todavía están en una etapa temprana, habría que enfocarse primero en que acierten correctamente.

• Hace tiempo lo comparé con GPT-4 haciéndole probar un programa que escribí yo mismo, y Phind no entendió bien lo que quería, mientras que GPT-4 lo entendió perfectamente y estaba listo para seguir iterando con más prompts hasta completarlo.
  https://www.phind.com/agent?cache=cloeowfla000dl1084ermly3c
  vs
  https://chat.openai.com/share/4147da33-3669-4657-88fa-3a9dfc...
  Puede que no sea representativo de todo, pero se desvió hacia cosas raras que no pedí e información básica que ya sabía.

  • El modo Pair Programmer actualmente usa GPT-4 o, si se agota el límite, GPT-3.5. Para usar Phind Model, hay que volver a intentarlo en el modo de búsqueda predeterminado.
    Usando Phind Model en la búsqueda predeterminada parece funcionar bien: https://www.phind.com/search?cache=ln6dpdtv5auwn4cq1ofg3gs9
  • El problema está en que busca un tema relativamente de nicho y probablemente trae resultados de baja calidad. El texto de búsqueda tiene más peso que en el modelo base, y si ese contexto no ayuda mucho, termina empeorando el rendimiento.
    También se puede ver este fenómeno en la búsqueda con Bing de ChatGPT, y lo he experimentado en mi propio proyecto.

• Me sorprende que CodeLlama soporte hasta 16k tokens. La ventana de tokens es una de las limitaciones para crear una IA que recuerde al usuario y continúe conversaciones pasadas.
  Para futuras apps de IA donde conversaciones largas continúen durante semanas, meses o años, una ventana de contexto grande será clave. La tecnología ya es impresionante, pero se volverá aún más interesante cuando pueda recordar todo lo que aprendió y trabajó contigo en el pasado, como un verdadero programador en pareja.
  [0] https://huggingface.co/docs/transformers/main/model_doc/llam...

  • 640k debería ser suficiente para cualquiera.
  • Con enfoques como MemGPT, el tamaño de la ventana de tokens se está virtualizando, así que su impacto disminuirá.
  • Estoy esperando el día en que se use memoria de mediano plazo para este fin, como el pooling promedio de tokens de sentence transformers. Parece algo obvio para todas las empresas, pero da la impresión de que nadie quiere implementarlo.

• Sé que no es popular, pero me gustaría que hubiera una forma de usar esto dentro de Emacs o Vim. Ya no quiero usar VS Code.

  • La tendencia de los últimos años a estandarizarse en VS Code es uno de los cambios que más lamento. Está bien que VS Code exista, pero estamos yendo hacia un mundo en el que, para usar las mejores herramientas, tienes que usar VS Code.
    En el desarrollo Java pasó eso con IntelliJ, y creo que fue muy poco saludable para el ecosistema. Me alegra mucho que Copilot soporte Vim, pero me preocupa que pronto deje de ser así.
  • Ojalá la profundidad del cariño por Emacs se valorara más en el mercado.
    Por ejemplo, existe el argumento de que la música y el arte se nivelan hacia abajo porque es mucho más rentable hacer un álbum que vale 10 dólares para decenas de millones de personas que hacer un álbum que vale un millón de dólares para unas decenas.
    Esto se debe a que, al final, el precio de un álbum se fija en 10 dólares; recién ahora se me ocurre que el mismo fenómeno también aplica a las herramientas de desarrollo.
  • Intenté llegar hasta :'<,'>y|call system('firefox ?q='.shellescape(@*).' &') para crear un atajo en Vim que envíe el texto seleccionado a Phind u otro LLM.
    El problema restante es que el texto no queda codificado en URL, y probablemente haya una forma elegante de hacerlo, pero todavía no la encontré.
  • Basándome en el ejemplo de Copilot de otra persona, armé a grandes rasgos una integración básica de Emacs con la API de ollama para autocompletado simple de código con un LLM local.
    En una Mac M1 suele tardar unos 7 segundos por inferencia, más lento de lo que quisiera, y el contexto que se envía también es muy simple, pero aun así apenas alcanza para ser usable.
    No pensaba publicarlo porque depende de una fachada en Python para intercambiar solicitudes y respuestas estilo Copilot con ollama, pero si hay interés podría pulirlo y sacarlo.
  • Tengo entendido que GitHub Copilot tiene integración con Emacs/Vim.

• Hice una comparación rápida y los resultados son excelentes; si además se considera la ventaja de incluir búsqueda web y referencias, es parecido a GPT-4 pero más rápido. Sin embargo, hay dos detalles menores que me molestan.
  En modo oscuro, la fuente del cuerpo de las respuestas es demasiado gruesa y brillante, lo que dificulta leer párrafos largos que no son código; y el modo claro es demasiado brillante en general. Para textos largos, preferiría un fondo oscuro gris como el de OpenAI o un fondo claro sepia como el de HN.
  También me confunde qué significa GPT-4 en “500+ best model uses (GPT-4) por día” en la página de precios. Se siente raro que Phind se anuncie como competidor de GPT-4 y, al mismo tiempo, incluya el uso de GPT-4 en los precios.

  • También soporta GPT-4 como modelo de respuesta, para que los usuarios puedan elegir según el caso de uso. Aun así, para la mayoría de los usuarios recomendamos Phind Model.