La revolución de memoria de GPT-4o: una aguja en un pajar de agujas

• needle-in-a-needlestack es una página pública que reúne en un solo lugar artículos y código experimental relacionados con GPT-4o, Llama, Jamba, Sonnet y Gemini
• También se ofrece el repositorio de código del proyecto, por lo que se puede revisar directamente el material experimental de Needle in a Needlestack
• Los artículos de cada modelo comparan resultados como Llama 3.1 8B y Jamba 1.5, centrándose en las diferencias de manejo de contexto largo y escalabilidad
• GPT-4o-mini se presenta como un caso similar a GPT-4 Turbo pero con un precio 98.5% menor, y Sonnet 3.5 como un caso mejor que Sonnet 3.0 en NIAN
• La página en sí es open source, por lo que se puede participar en la edición de la documentación mediante el enlace “Improve this page” en GitHub

---

Enlaces relacionados con Needle in a Needlestack

• Needle in a Needlestack Code: repositorio de código de Needle in a Needlestack
• GPT-4o’s Memory Breakthrough!: artículo sobre la revolución de memoria de GPT-4o
• GPT4o-mini comparable to GPT-4 Turbo, for 98.5% lower price: artículo que dice que GPT-4o-mini es comparable a GPT-4 Turbo con un precio 98.5% menor

Artículos comparativos por modelo

• Llama 3.1 8B: Excels in 8K Contexts, Challenged by Expansion: Llama 3.1 8B destaca en contextos de 8K, pero tiene dificultades al escalar
• Jamba 1.5: New model with new architecture crushes Needle-in-a-Needlestack: Jamba 1.5 supera ampliamente a Needle-in-a-Needlestack con una nueva arquitectura
• Sonnet 3.5 Does Much Better at NIAN Than 3.0: Sonnet 3.5 rinde mucho mejor que Sonnet 3.0 en NIAN
• Gemini 1.5 Flash Outperforms Much More Expensive Models: Gemini 1.5 Flash supera a modelos mucho más caros

Documentación open source

• Este sitio es open source
• Se puede editar la página en GitHub mediante el enlace Improve this page

[wedding]

El avance tecnológico es realmente impresionante.. T_T

[GN⁺]

Opiniones de Hacker News

• Esta prueba se basa en el dataset de limericks publicado en 2021: https://zenodo.org/records/5722527
  Creo que es muy probable que GPT-4o haya sido entrenado con estos datos. No habría una razón particular para no incluirlos. Me pregunto por qué el equipo de NIAN no genera limericks con varios modelos y verifica que los resultados no estén en el dataset. Eso permitiría descartar la posibilidad de que los modelos hayan sido entrenados con esos limericks

  • Probaron si los LLM podían responder las preguntas sin proporcionarles los limericks. Salvo 4o, el rendimiento en este benchmark es muy malo, así que no creo que la inclusión en los datos de entrenamiento invalide la prueba
  • ¿No podrían simplemente crear texto completamente aleatorio y hacer que lo busque ahí?
  • NIAN es una idea muy buena, pero ¿no bastaría con traducir a N idiomas distintos y hacer las preguntas así? También podrían mezclar DeepL, Google Translate, traducciones del propio LLM, etc.

• Comparé dos documentos legales pequeños y alucinó por completo diciendo que había una cláusula en uno que no estaba en el otro. Lo hizo en tres secciones distintas del contrato
  Al verificarlo con ctrl-f, estaba incluida de forma idéntica en ambos. Es solo una muestra, pero una cifra de 90% no me parece plausible. En total eran unas 80 mil tokens aproximadamente

  • Me pasó algo parecido. Le pedí que encontrara duplicados en una lista de 6 mil elementos y prácticamente alucinó la respuesta completa varias veces. A veces encontraba algunos duplicados, pero entre medio metía elementos inventados
    No esperaba la respuesta correcta porque creo que es una tarea difícil con una cantidad fija de attention heads, pero me pareció mucho peor que Claude Opus o GPT-4
  • Eso no es encontrar una aguja en un pajar
    Los LLM hacen mejor esta tarea si se dividen los dos documentos en secciones más pequeñas y se procesan iterativamente por sección. No tienen capacidad de inferencia ni memoria para analizar estructuralmente dos bloques de texto más allá de fragmentos relativamente pequeños. En cambio, si se recorren progresivamente fragmentos pequeños que sean semánticamente independientes y relevantes, funcionan bastante bien
    Es un error asumir que son máquinas mágicas. Tienen límites y capacidades y, como con cualquier otra herramienta, hay que entender qué pueden y qué no pueden hacer, y conviene saber por qué. Para el 99.9% de los desarrolladores sigue siendo un avance bastante nuevo, así que no entiendo por qué las expectativas son prácticamente infinitas. Con tecnologías anteriores, el estándar era más razonable: “bueno, veamos cómo usar esto correctamente”. Tal vez sea porque hablan como personas y eso hace que parezca que tienen capacidades que no tienen, o porque suenan demasiado humanas y se les reprocha no ser humanas. Hay exageración, pero también subestimación al mismo tiempo. Incluso XML pasó por un ciclo de entusiasmo similar en el que parecía que iba a terminar con el hambre en el mundo
  • Esa es una prueba distinta de needle-in-a-needlestack, pero muestra bien lo frágiles que son los modelos. En algunos ámbitos son competentes, pero en otros son terriblemente malos
    needle-in-a-needlestack es, a diferencia de needle-in-a-haystack, que consiste en encontrar algo entre cosas distintas, el problema de encontrar un dato específico entre datos similares. Por ejemplo, encontrar uno entre miles de limericks
  • Hice el mismo experimento con normativa local y descubrí que GPT alucinaba multas y cargos. Es un problema real
  • Interesante; al menos oficialmente, la ventana de contexto de GPT-4o es de 128k

• La prueba needle-in-a-haystack muestra de manera muy limitada la capacidad real de un modelo para manejar contexto largo. Se usa principalmente porque los primeros modelos hacían esta tarea pésimamente y era fácil de probar
  De hecho, la mayoría de los modelos modernos son bastante buenos en esta única tarea, pero en la práctica su capacidad para hacer cosas complejas por encima de 32K tokens cae mucho. RULER es una prueba mucho mejor: https://github.com/hsiehjackson/RULER

  Aunque logran un rendimiento casi perfecto en la prueba básica needle-in-a-haystack (NIAH), todos los modelos (excepto Gemini-1.5-pro) muestran una gran degradación de rendimiento en las tareas de RULER a medida que aumenta la longitud de la secuencia
  Aunque todos los modelos afirman tener tamaños de contexto superiores a 32k tokens (excepto Llama3), solo la mitad puede manejar eficazmente secuencias de 32K superando el criterio cualitativo, el rendimiento de Llama2-7b con 4K (85.6%). El rendimiento que supera el criterio está subrayado

  • Puede ser, pero primero, este artículo no trata sobre NIHS sino sobre una prueba propia modificada, así que podría ser más relevante. Segundo, la afirmación principal del artículo es que GPT-4o lo hace mejor, y la prueba que mencionas no benchmarkeó GPT-4o
  • Los modelos benchmarkeados por RULER salen peor en needle-in-a-needlestack. Me da curiosidad cómo le iría a 4o en RULER

• También me gustaría ver esto con Gemini Pro 1.5. La semana pasada probé metiendo Moby Dick completo y, en otra ocasión, todos los libros publicados por Byung-Chul Han; en ambos casos encontró literalmente, cada vez, partes de las frases que mencionaban o respondían mi pregunta, y no hubo alucinaciones.

  • Varias personas del laboratorio están investigando la evaluación de contexto largo de los LLM en obras de ficción. Es muy probable que Moby Dick esté en los datos de entrenamiento. Por eso, la gente del laboratorio ha estado explorando libros publicados recientemente para evitar ese problema.
    Se pueden consultar BooookScore (https://openreview.net/forum?id=7Ttk3RzDeu), presentado la semana pasada en ICLR, y el preprint reciente FABLES (https://arxiv.org/abs/2404.01261).
  • ¿Eso no está probablemente en el conjunto de entrenamiento? Sería interesante hacer la misma tarea con una colección de libros publicados después de la última versión del modelo.
  • Metí los 2500 ejemplos enlazados en el artículo en Gemini 1.5 Flash y acertó la respuesta correcta, “The tree has diseased leaves and its bark is peeling.”: https://aistudio.google.com/
  • Tengo acceso a ese modelo y también he visto una extracción de contexto impresionante. Le metí una base de código grande completa y también la resumió muy bien.
    También vi a alguien analizar un archivo de logs enorme, pero para identificar el punto en el que el modelo empieza a omitir cosas, realmente hace falta algo como este needle-in-a-needlestack. Como mínimo, puede servirles a los desarrolladores de modelos para analizar sus modelos propuestos.
  • Ahora parece que en unos 2 a 5 años podremos meter un ePub y obtener en minutos una versión de novela gráfica precisa. Estoy listo para ver 4000 dibujos de árboles al estilo Tolkien.

• Alguien debería crear una prueba de “síntesis en el haystack” que evalúe no solo la búsqueda, sino la profundidad de comprensión, las conexiones y la abstracción entre distintos datos.
  Cuando una persona lee un libro, desarrolla una “intuición general” sobre él. Necesitamos una forma de cuantificar eso. Siento que la prueba needle-in-haystack es demasiado simple y no llega lo suficientemente lejos.

  • Podría ser posible hacer un whodunit sofisticado al estilo Agatha Christie. La idea sería incluir varios giros y coartadas, y cortar el final de la obra de modo que el sospechoso más probable cambie.
  • También podría hacerse que las agujas formen un grafo y que el prompt pregunte por tareas basadas en ese grafo.
  • Hay una idea de comprar una novela o guion inédito con un mundo detallado e internamente coherente y personajes con motivaciones bien diseñadas, y pedirle que siga escribiendo una nueva trama que vincule a dos personajes que aún no se han encontrado, desde un punto arbitrario después de la mitad.
    Si entiende el contexto, debería poder escribir una nueva parte de la historia y usar las motivaciones de los personajes que el lector percibe intuitivamente para desarrollar sus arcos. Pero, para que sea útil, habría que mantener todo estrictamente privado, así que solo serviría casi como benchmark privado. O bien podría convertirse en una especie de premio prestigioso, evaluado por la credibilidad de sus conclusiones, en vez de publicar la metodología para mejorar el campo.
  • Pensé algo parecido. Una parte de la pregunta debería dar información suficiente para que el LLM encuentre el limerick, y la segunda parte debería preguntar algo que requiera una comprensión más profunda de ese limerick o de otro texto.
  • Como la comprensión no existe, no se puede hacer eso.
    GPT-4o todavía no puede manejar la intersección de dos ideas distintas que no estén en el conjunto de entrenamiento. Ni siquiera puede crear variaciones aleatorias sobre la intersección de dos ideas distintas. Más aún, no deberíamos esperar que el modelo haga eso. No es justo con el modelo, con su utilidad real ni con las cosas sorprendentes que logra sin comprensión. Creer que el modelo entiende es engañarse a uno mismo.

• Ahora se puede usar GPT para convertir datos dinámicos sin procesar en layouts HTML atractivos al vuelo. En páginas de bajo tráfico, como registros de cambios o logs de auditoría, puede reducir mucho el tiempo de desarrollo y mantener el HTML actualizado aunque cambie la estructura de los datos.
  Los intentos anteriores no funcionaban de forma consistente porque GPT-4-Turbo a veces ignoraba casi por completo el contexto y las instrucciones.

• Este artículo muestra cuánto mejoró la capacidad de GPT-4o para prestar atención a toda la ventana de entrada frente a GPT-4 Turbo y Claude-3 Sonnet.
  Hacía falta desde hace tiempo una mejora de needle-in-a-haystack, y este “Needle In A Needlestack” es un buen siguiente paso. NIAN crea un prompt con miles de limericks y hace preguntas sobre el limerick ubicado en una posición específica.

  • De acuerdo. Pagué por Claude durante un tiempo. Afirman con mucha fuerza que soporta contextos grandes, y cuando usas contextos grandes consume una cantidad enorme de tokens, pero si había código fuente de apenas unas páginas antes en el contexto, era casi inútil.
    Era más frustrante porque en todo lo demás estaba bien y me gustaba su tono. Anoche probé 4o y todavía reconocía perfectamente una clase de C++ que había pegado 20 preguntas antes. No me importa si es inteligente; me importa si es útil, y esto aporta muchísimo a la utilidad.

• Cada vez estoy más convencido de que en el internet público parece no haber nadie que sepa hacer una evaluación decente de LLMs.

  • Aun así, al menos ya dejamos atrás las evaluaciones de LLM que todos hacían en 2022-2023, tipo “quién fue el 29.º presidente de EE. UU.” o “dibújalo al estilo de Van Gogh”.

• Para que esta prueba tenga sentido, habría que saber que los datos del conjunto de prueba no estaban incluidos en los datos de entrenamiento.

  • Si preguntas sin proporcionar primero los limericks, nunca acierta la respuesta correcta. Cuando el LLM se equivoca, normalmente vuelve a los datos de entrenamiento y da una respuesta genérica que no coincide con el limerick.
  • No necesariamente. Basta con comparar el rendimiento del modelo antes y después de subir el material.
  • Pensé que los limericks de prueba habían sido generados automáticamente.

• Suena bien. El mayor problema de GPT-4.0 era que la calidad caía a medida que la conversación se alargaba, y eso era especialmente importante en proyectos de programación.
  Me pregunto si ahora habrá mejorado. Lo voy a probar hoy.

  • Hasta ahora, esa también ha sido mi experiencia. Mis conversaciones actuales se han vuelto absurdamente más largas que las conversaciones antiguas con GPT-4. Antes tenía que copiar el contexto con frecuencia y empezar de nuevo en un chat nuevo.
  • Tuve la misma experiencia. Con prompts de 16k, Turbo era casi perfecto, pero con 32k ya no era tan bueno, y con más de 100k era inutilizable. Para obtener buenos resultados con prompts largos, hay que repetir la información dentro del prompt.