Deja de hacer chunking como si estuviéramos en 2022 — Yuval Belfer, AI21 Labs
AAI Engineer
컴퓨터/소프트웨어AI/미래기술
스크립트
00:00:00Hola a todos. Gracias por venir hoy. Bienvenidos a una charla sobre nada. Perdón, una charla sobre
00:00:21recuperación. Mi nombre es Yuval. Trabajo en AI21, que básicamente es un laboratorio de investigación de IA. Y hoy,
00:00:29quiero hablarles de algo de lo que la mayoría de la gente no quiere hablar, que es la fragmentación.
00:00:37Y espero convencerlos al final de que la fragmentación no está muerta y que hay algo que hacer al respecto.
00:00:45Y de verdad, si están en X, LinkedIn, donde sea, probablemente hayan visto que RAG está muerto, ¿verdad?
00:00:53Creo que últimamente la gente también mató a MCP. Y RAG está muerto otra vez. Larga vida a la recuperación orgánica,
00:01:00a la búsqueda orgánica. Y llega un momento en el que uno tiene que preguntarse, ¿cuántas veces puede morir RAG?
00:01:07¿Verdad? Y aun cuando alguien dice, bueno, RAG no ha muerto, como Jerry, el director ejecutivo de Llama Index,
00:01:14todavía tienen que matar algo. Y al parecer, ese algo es la fragmentación. O sea, no inviertan en ella.
00:01:23No lo hagan. Y esta es la razón por la que la gente dice que la fragmentación está muerta, porque todo el mundo usa
00:01:30búsqueda agéntica ahora, ¿verdad? Tienen grep, tienen ls, tienen find. Todo esto es genial,
00:01:36pero todavía no es suficiente si tienes una gran cantidad de datos y una variedad de consultas.
00:01:46Un segundo. De acuerdo. Y creo que la razón principal por la que a mucha gente no le gusta hablar
00:01:51de la fragmentación es porque no es la parte divertida, ¿verdad? En cualquier RAG o sistema de archivos,
00:02:00tenemos dos etapas. La primera etapa es la aburrida, por decirlo así. La que haces al principio,
00:02:07tienes muchos datos. Tienes que preprocesarlos. Tienes que decidir el tamaño de los fragmentos. Y luego
00:02:13tienes que almacenar todo en una base de datos vectorial. La otra parte es la parte de recuperación, esencialmente la que
00:02:20ocurre por consulta. Esto es algo mucho más fácil de hacer, ¿verdad? Es mucho más fácil
00:02:25de optimizar. Puedes usar todas tus consultas y luego puedes jugar con el K máximo, top K, perdón, puedes jugar
00:02:32con la búsqueda híbrida tal vez, ese tipo de cosas. ¡Es mucho más divertido hacer ajustes de recuperación, verdad?
00:02:40Así que yo afirmaría que si tenemos que matar algo, si algo tiene que morir, entonces probablemente sea
00:02:47el ajuste de recuperación. Y sí, la búsqueda agéntica probablemente mató eso. Pero aún así, la búsqueda agéntica, incluso si
00:02:55podemos aceptar el hecho de que mató el ajuste de recuperación, sigue sin ser suficiente cuando tienes una gran cantidad
00:03:02de datos. Cuesta mucho dinero. Creo que ya no tengo que mencionar eso. El uso máximo de tokens
00:03:09es algo de lo que todo el mundo habla. Y lo que hay debajo, que es que si los datos en sí
00:03:17no está ordenada correctamente en tus carpetas, en tus directorios, sigues obteniendo algo que es
00:03:25ineficiente. Así que pensemos en un ejemplo oportuno, ¿verdad? La Copa Mundial de la FIFA es ahora. E imaginemos
00:03:33que tenemos un conjunto de datos que contiene toda la Copa Mundial de la FIFA. Entonces cada directorio es, digamos,
00:03:40el del 98, el del 2002, etcétera. Pero si tu consulta pregunta qué equipo ganó más Copas del
00:03:50Mundo, no puedes simplemente ir a una carpeta y acceder a eso. Tienes que ir a cada carpeta, ver quién ganó, y
00:03:57luego agregar todo eso, lo cual es muy ineficiente. La respuesta inmediata es Brasil, eso espero, al menos
00:04:03según el momento en que ocurre esta conversación. Así que la recuperación en realidad no murió. No estamos
00:04:13matando nada en esta conferencia. Se ha convertido en fontanería. Y creo que cualquiera que haya trabajado en
00:04:21cualquier sistema RAG conoce esa sensación. El día uno, o la semana uno, o tal vez incluso el mes uno, si eres muy minucioso,
00:04:29eliges algún tipo de tamaño de fragmento. Digamos 512. Y tal vez pongas algo de solapamiento,
00:04:36¿verdad? 10%, 20%, etcétera, indexando todo, y te olvidas por completo. Y puedes hacerlo, ¿verdad?
00:04:43Hablamos mucho sobre las estrategias de fragmentación fija, donde si tu fragmento es demasiado grande,
00:04:49obtienes la imagen completa, lo cual está bien, pero pierdes muchos matices. Y todos los
00:04:54fragmentos no obtendrán incrustaciones significativas. Mientras que si eliges que tus fragmentos sean demasiado pequeños,
00:05:00pierdes la imagen general. Y la verdad es que no será tan eficiente. Así que lo que esto nos indica es
00:05:07que la fragmentación es esencialmente una compresión con pérdidas. No importa lo que hagamos, siempre perdemos algo.
00:05:15Y yo afirmaría que no hay un tamaño de fragmento correcto. Y muchos de ustedes que han trabajado con datos dirán:
00:05:23no, pero tenemos este corpus, tenemos este conjunto de datos, y realmente lo usamos y optimizamos nuestro sistema para
00:05:29que funcione muy, muy bien con estos datos. Y nosotros también lo pensábamos. Teníamos mucha experiencia con eso,
00:05:35con muchos tipos diferentes de agentes, sistemas y flujos de trabajo que realmente puedes,
00:05:40y, ¿verdad?, piensas en los puntos de referencia, lo fácil que es sobreajustar tu modelo a un punto de referencia.
00:05:48Pero no con RAG. Ahí no pasa eso. Y realmente no se puede optimizar por conjunto de datos. Y les
00:05:54mostraré cómo asegurarse de que dependa de la consulta. ¿Y cómo puedo estar tan seguro? ¿Cómo puedo afirmar algo
00:06:00así? Porque realizamos experimentos, lo probamos y ahora voy a presentárselo. Así que lo que
00:06:06hicimos, en lugar de decir cuál es el mejor tamaño de fragmento por dato, es averiguarlo. Tomemos
00:06:14conjunto de datos y dupliquémoslo varias veces. En este caso, seis veces. En cada duplicación,
00:06:23en cada instancia, el tamaño del fragmento es diferente. Así que tenemos una base de datos con un tamaño de fragmento de 2000,
00:06:28una base de datos con un tamaño de fragmento de 1000, etcétera. Y lo hicimos con varios conjuntos de datos,
00:06:36como QMSUM, que es un conjunto de datos de transcripciones de reuniones. Narrative QA, que es la respuesta a preguntas sobre
00:06:41novelas. Y el conjunto de datos de Seinfeld, que trata sobre trivialidades acerca de nada. Bueno, no realmente. Son preguntas de trivia
00:06:49sobre las transcripciones de Seinfeld. Es una especie de conjunto de datos de troleo que construimos internamente. También
00:06:56lo publicamos por si alguien quiere el enlace al final. Y lo probamos en todos ellos para ver qué sucede.
00:07:03Y ante todo, solo queríamos ver, para cada conjunto de datos, qué tamaño de fragmento es el mejor. Y lo que
00:07:10vemos aquí es un ejemplo del conjunto de datos de Seinfeld, donde esencialmente dos consultas, que son
00:07:16diferentes por naturaleza, obtienen resultados distintos según el tamaño del fragmento. Así que la primera pregunta, ¿cuál es el
00:07:24nombre de la camisa favorita de Jerry? Pueden ver que es una pregunta muy enfocada, muy específica.
00:07:28La respuesta probablemente esté muy acotada. Y esto es algo en lo que un tamaño de fragmento más pequeño
00:07:33funcionará mejor. Y pueden ver el rango uno frente a un rango inferior a 50. Entre 100 tokens de tamaño de fragmento
00:07:43fijo a 100. Mientras que una pregunta como, ¿a quién describe Jerry como su némesis y la maldad pura,
00:07:50de la cual ni siquiera soy tan fan de Seinfeld, y sé que es Newman. Pero si miras la
00:07:56transcripción, no es algo que se pueda encontrar tan fácilmente. Y como puedes ver, realmente cambia, ¿verdad? Si usas
00:08:02un tamaño de fragmento pequeño, no obtendrás la respuesta. Y lo que hicimos realmente, después de ejecutar
00:08:10todas estas cosas y todas estas cosas, notamos que dijimos, ¿qué pasaría si tuviéramos un oráculo, o un genio,
00:08:19si prefieren, que pudiera decirnos, para cada consulta, cuál es el mejor tamaño de fragmento para realizar la recuperación? Esto esencialmente es el
00:08:25experimento del oráculo. Esto es lo que queríamos saber para ver el potencial. Esto no es -- ya tenemos la
00:08:33capacidad de construir un sistema aquí. Solo queremos ver cuál es el potencial que tenemos aquí. Y lo que pueden
00:08:38ver aquí, okay, en este gráfico, todo el azul -- primero, el eje y es la recuperación. Cuanto más alto, mejor. El
00:08:46eje x es el número de fragmentos recuperados. Así que es la recuperación en k frente a k. Pueden ver todas las líneas azules,
00:08:52indistinguibles, pero cada una de ellas muestra el rendimiento para un tamaño de fragmento fijo. Mientras que la naranja es la
00:09:01línea oráculo. Es decir, para cada consulta, elegimos la mejor opción entre todas. Y como se puede ver, ocurre
00:09:09en varios conjuntos de datos. En muchos de ellos, realmente se puede ver que las líneas azules se cruzan entre
00:09:16sí, lo que significa que, en efecto, para muchos conjuntos de datos, ningún tamaño de fragmento domina realmente. Y lo que
00:09:24es más interesante es que hay mucho potencial. La brecha que se puede ver entre la línea naranja
00:09:30y todas las líneas azules es grande. Y cuando digo grande, es algo así como del 20 al 40 por ciento solo por
00:09:38hacer estrategia en la fragmentación. Y una estrategia muy simple, si se me permite añadir. Y esto es -- esta brecha, esto es lo que
00:09:47la elección de 512 o 1000 o lo que sea, ¿verdad? Este número es simplemente arbitrario. Esto es lo que te cuesta. Y
00:09:56pienso que el problema aquí es que es un poco complicado porque es como un problema de información donde no tenemos la
00:10:07información que necesitamos en cada etapa. ¿Y a qué me refiero con eso? Si observo la parte de indexación,
00:10:12donde sí tengo control sobre el tamaño del fragmento, no sé cuáles serán las consultas.
00:10:18Puedo adivinar. Quizás pueda estimar. Puedo intentarlo. Pero no sé cuáles serán las consultas, así que no puedo
00:10:25ajustar mi tamaño de fragmento en consecuencia. Y en la parte de recuperación, donde sí tengo mis consultas,
00:10:31no puedo controlar el tamaño del fragmento, ¿verdad? Ya está fijo. Y obviamente no voy a hacer todo el
00:10:37proceso por consulta desde el principio. Así que analizamos trabajos anteriores, como notablemente la recuperación entrópica,
00:10:47la recuperación contextual, donde enriquecen cada fragmento, y otros que esencialmente intentan mejorar el espacio
00:10:54espacio latente de cada fragmento. Pero esta no es la dirección que tomamos. Todos ellos se mantuvieron en el modelo
00:11:01de trabajemos con un tamaño de fragmento fijo, mientras que nosotros adoptamos un enfoque diferente. Y dijimos, ¿por qué comprometernos con
00:11:08uno cuando podemos comprometernos con varios? Y lo llamamos indexación multiescala. Básicamente, solo estamos
00:11:16haciendo lo que vimos antes. Así que revisamos la base de datos. La duplicamos y la fragmentamos con varios
00:11:26tamaños de fragmento o tamaños de ventana. Y luego, esto es lo que ocurre en la indexación. Y luego, en el momento de la recuperación,
00:11:34consultamos todas ellas. Así que si teníamos n duplicados de la base de datos y tamaños de ventana, ahora tenemos que ejecutar
00:11:43seis llamadas de recuperación diferentes por consulta. Perdón, seis como n. ¿Y cómo los combinamos? Obviamente no podemos
00:11:52usar el oráculo, ¿verdad? El oráculo es algo que tenemos solo para el potencial. En la vida real,
00:11:57no sabemos la respuesta. Pero lo que podemos hacer es encontrar algún tipo de algoritmo de fusión. Ahora bien, dirías,
00:12:06cuando lo miramos así, ¿cuál puede ser el problema? El hecho de que tenemos n clasificaciones,
00:12:13pero las clasificaciones son para fragmentos. Y los fragmentos con diferentes tamaños no son realmente comparables,
00:12:19¿verdad? Así que en su lugar, optamos por hacer algo que es bastante popular hoy en día. Y muchos de los
00:12:25los sistemas RAG funcionan en realidad así, que en lugar de recuperar solo el fragmento, al obtener un
00:12:30fragmento, recuperamos el documento entero, ¿verdad? Cuando la ventana de contexto crece, queremos ofrecer cada vez
00:12:35más contexto. Y ahora, en este caso, tenemos n clasificaciones de los mismos documentos, porque ya no son
00:12:44fragmentos. Y esto sí lo podemos comparar. Y en este caso, se puede pensar en la recuperación esencialmente
00:12:50como una votación, ¿de acuerdo? Así que no es puramente una clasificación. No tenemos una clasificación y luego
00:12:56hacemos una re-clasificación. Tenemos n clasificaciones diferentes de los documentos relevantes y queremos agruparlas
00:13:03todas en una sola. Por eso usamos algo llamado RRF, Reciprocal Rank Fusion, que es prácticamente
00:13:11una fórmula sencilla. Probamos varias cosas. Esta funcionó mejor. Y como pueden ver, no es un
00:13:17modelo. No es algo que debas hacer de forma específica. Es decir, en especial, esto es solo un
00:13:23script sencillo que no toma prácticamente nada de tiempo. Y así es como se ve el sistema completo. Así que tenemos la
00:13:32indexación n veces, luego consultamos cada consulta en cada base de datos y usamos RRF para combinarlas
00:13:40todas. Y los resultados, pueden adivinar que son buenos. De lo contrario, no estaría aquí parado
00:13:48teniendo tanta confianza. ¿De acuerdo? Pero como pueden ver, lo probamos en varios conjuntos de datos, QMSum,
00:13:56Narrative QA, Seinfeld y también Finance Bench. Los tomamos todos, y supera a nuestros tamaños fijos de la mejor
00:14:05manera. Veamos esto en un gráfico. Cuesta un poco verlo aquí, así que lo repasaré lentamente. Cada fila
00:14:12aquí es el tamaño del fragmento. Así que pueden ver 50, 100 y así sucesivamente. La fila inferior es nuestro método. Este,
00:14:21el que se hace con todos ellos y luego se combina. Y cada columna es el recuerdo (recall) de algo. Así que recuerdo en 1,
00:14:312, 3, hasta 10. Lo que pueden ver aquí son dos cosas, ¿verdad? En primer lugar, que en cuanto
00:14:39al recuerdo o lo que sea, nuestro método sigue ganando, lo cual podría parecer muy fácil, pero el hecho de que
00:14:46tengas que combinar todos ellos no es algo precisamente trivial. Y también pueden ver que la calidad
00:14:53en realidad aumenta. El mapa de calor donde se ve que se vuelve mucho más verde. Y de nuevo, esto era solo
00:14:58algo que quería mostrar en grande. Aquí pueden ver los cuatro conjuntos de datos donde logramos
00:15:06mejores resultados. La verdad, un 20, 30, 40 por ciento de mejora incluso en muchas cosas. Además, hay resultados
00:15:14que no les mostré aquí y que están en MTab. Como pueden ver en nuestro blog, pondré el enlace más tarde, estamos obteniendo
00:15:22allí también muchas mejoras, entre un 10 y un 40 por ciento dependiendo del conjunto de datos.
00:15:30Ahora bien, no soy ingenuo. No voy a afirmar aquí que esto no cuesta nada. Obviamente hay un costo,
00:15:36¿verdad? No hay almuerzos gratis. Todo tiene que venir con algo. Y sí, esto cuesta memoria adicional.
00:15:43Cuesta algo así como entre 2 y 5 veces O(1), ¿verdad? Una constante de memoria adicional donde tienes que mantener
00:15:51todas esas copias de la base de datos. Sin embargo, si lo piensan, en cuanto a latencia, no afecta
00:15:59demasiado porque toda la parte de recuperación se puede hacer en paralelo. Y además, la parte del RRF no toma mucho tiempo.
00:16:10Diré que este fue un proyecto de investigación muy bonito que hicimos y obtuvimos resultados muy, muy geniales.
00:16:16Hay cosas por hacer, ¿verdad? Hay áreas que mejorar. Hay trabajo futuro por realizar. Más precisamente,
00:16:23queremos entender cuántos tamaños de fragmento queremos y cuáles, ¿verdad? El hecho de haber trabajado con 50, 100,
00:16:32200 y demás fue bastante arbitrario, para ser sinceros. Así que necesitamos averiguar cómo calcular esto y
00:16:40cómo saber exactamente cuántas copias se necesitan. Además, ir más allá de RRF, ¿verdad? El hecho de usar
00:16:46RRF se debe a que funcionó mejor entre los métodos que usamos, pero eso no significa que no exista
00:16:52un método mejor. Y si tengo que dejarles con algo, diría que los agentes no mataron
00:16:59a la recuperación. Nada ha muerto. Venga ya. Es solo infraestructura. Y lo malo es que es
00:17:07infraestructura de 2022. Y con métodos realmente sencillos, puedes tomar tu sistema RAG o cualquier cosa que tenga
00:17:17que ver con almacenar datos y luego recuperarlos mejorando un 20 o 40 por ciento, de nuevo, sin necesidad de algo
00:17:26demasiado sofisticado. Así que si quieren leer más al respecto, pueden leer el blog. También hay código de ejemplo
00:17:34ahí y el conjunto de datos de Seinfeld. Y eso es todo. Soy Yuval. Muchas gracias por estar aquí.
00:17:47Nos vemos la próxima vez.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기