Publicado originalmente en https://blog.developer.bazaarvoice.com el 28 de octubre de 2024.
Los modelos de lenguaje grandes son herramientas fantásticas para texto no estructurado, pero ¿qué pasa si su texto no cabe en la ventana contextual? Bazaarvoice enfrentó exactamente este desafío al crear nuestra función de resúmenes de reseñas de IA: millones de reseñas de usuarios simplemente no encajarán en la ventana contextual de LLM aún más nuevos e, incluso si lo hicieran, sería prohibitivamente costoso.
En esta publicación, comparto cómo Bazaarvoice abordó este problema comprimiendo el texto de entrada sin pérdida de semántica. Específicamente, utilizamos un enfoque de agrupamiento jerárquico de múltiples pasos que nos permite ajustar explícitamente el nivel de detalle que queremos perder a cambio de la compresión, independientemente del modelo de incorporación elegido. La técnica final hizo que nuestra función de resúmenes de revisión fuera financieramente factible y nos preparó para continuar escalando nuestro negocio en el futuro.
Bazaarvoice ha estado recopilando reseñas de productos generadas por usuarios durante casi 20 años, por lo que tenemos mucho de datos. Estas reseñas de productos no están estructuradas en absoluto y varían en extensión y contenido. Los modelos de lenguaje grandes son excelentes herramientas para texto no estructurado: pueden manejar datos no estructurados e identificar piezas de información relevantes entre los distractores.
Sin embargo, los LLM tienen sus limitaciones, y una de ellas es la ventana de contexto: cuántos tokens (aproximadamente la cantidad de palabras) se pueden colocar en la red a la vez. Los modelos de lenguajes grandes de última generación, como la versión 3 de Claude de Athropic, tienen ventanas de contexto extremadamente grandes de hasta 200.000 tokens. Esto significa que puedes incluir pequeñas novelas en ellos, pero Internet sigue siendo una colección de datos enorme y en constante crecimiento, y nuestras reseñas de productos generadas por los usuarios no son diferentes.
Alcanzamos el límite de la ventana de contexto mientras construíamos nuestra función Resúmenes de reseñas que resume todas las reseñas de un producto específico en el sitio web de nuestros clientes. Sin embargo, durante los últimos 20 años, muchos productos han obtenido miles de reseñas que rápidamente sobrecargaron la ventana de contexto de LLM. De hecho, incluso tenemos productos con millones de revisiones que requerirían una inmensa reingeniería de los LLM para poder procesarlos de una sola vez.
Incluso si fuera técnicamente viable, los costes serían bastante prohibitivos. Todos los proveedores de LLM cobran según la cantidad de tokens de entrada y salida. A medida que nos acercamos a los límites de la ventana de contexto para cada producto, de los cuales tenemos millones, podemos acumular rápidamente facturas de alojamiento en la nube de más de seis cifras.
Para enviar resúmenes de reseñas a pesar de estas limitaciones técnicas y financieras, nos centramos en una visión bastante simple de nuestros datos: muchas reseñas dicen lo mismo. De hecho, toda la idea de un resumen se basa en esto: los resúmenes de reseñas capturan las ideas, los temas y los sentimientos recurrentes de los revisores. Nos dimos cuenta de que podemos aprovechar esta duplicación de datos para reducir la cantidad de texto que necesitamos enviar al LLM, evitando que alcancemos el límite de la ventana de contexto. y reduciendo el costo operativo de nuestro sistema.
Para lograrlo, necesitábamos identificar segmentos de texto que dijeran lo mismo. Esta tarea es más fácil de decir que de hacer: a menudo las personas usan diferentes palabras o frases para expresar la misma cosa.
Afortunadamente, la tarea de identificar si un texto es semánticamente similar ha sido un área activa de investigación en el campo del procesamiento del lenguaje natural. El trabajo de Agirre et. Alabama. 2013 (Tarea compartida SEM 2013: Similitud textual semántica. En Segunda Conferencia Conjunta sobre Semántica Léxica y Computacional) incluso publicó datos etiquetados por humanos de oraciones semánticamente similares conocidos como STS Benchmark. En él, piden a los humanos que indiquen si las oraciones textuales son semánticamente similares o diferentes en una escala del 1 al 5, como se ilustra en la siguiente tabla (de Cer et. al., SemEval-2017 Tarea 1: Evaluación enfocada multilingüe y translingüe de similitud textual semántica):
El conjunto de datos STSBenchmark se utiliza a menudo para evaluar qué tan bien un modelo de incrustación de texto puede asociar oraciones semánticamente similares en su espacio de alta dimensión. Específicamente, la correlación de Pearson se utiliza para medir qué tan bien el modelo de integración representa los juicios humanos.
Por lo tanto, podemos utilizar dicho modelo de incorporación para identificar frases semánticamente similares de reseñas de productos y luego eliminar frases repetidas antes de enviarlas al LLM.
Nuestro enfoque es el siguiente:
- Primero, las reseñas de productos se segmentan en oraciones.
- Se calcula un vector de incrustación para cada oración utilizando una red que funciona bien en el punto de referencia STS.
- La agrupación aglomerativa se utiliza en todos los vectores de incrustación para cada producto.
- Se retiene una oración de ejemplo, la más cercana al centroide del grupo, de cada grupo para enviarla al LLM, y se eliminan otras oraciones dentro de cada grupo.
- Cualquier grupo pequeño se considera atípico y se toma una muestra aleatoria para su inclusión en el LLM.
- La cantidad de oraciones que representa cada grupo se incluye en el mensaje LLM para garantizar que se considere el peso de cada sentimiento.
Esto puede parecer sencillo cuando se escribe en una lista con viñetas, pero había algunos problemas en los detalles que teníamos que resolver antes de poder confiar en este enfoque.
Primero, teníamos que asegurarnos de que el modelo utilizaba texto efectivamente incrustado en un espacio donde las oraciones semánticamente similares están cerca y las semánticamente diferentes están lejos. Para hacer esto, simplemente utilizamos el conjunto de datos de referencia STS y calculamos la correlación de Pearson para los modelos que deseábamos considerar. Utilizamos AWS como proveedor de nube, por lo que, naturalmente, queríamos evaluar su Incrustación de texto titán modelos.
A continuación se muestra una tabla que muestra la correlación de Pearson en el STS Benchmark para diferentes modelos de Titan Embedding:
(El estado del arte es visible aquí)
Por lo tanto, los modelos de incorporación de AWS son bastante buenos para incorporar oraciones semánticamente similares. Esta fue una gran noticia para nosotros: podemos usar estos modelos disponibles en el mercado y su costo es extremadamente bajo.
El siguiente desafío al que nos enfrentamos fue: ¿cómo podemos imponer la similitud semántica durante la agrupación? Idealmente, ningún grupo tendría dos oraciones cuya similitud semántica sea menor de lo que los humanos pueden aceptar: una puntuación de 4 en la tabla anterior. Sin embargo, esas puntuaciones no se traducen directamente en las distancias de incrustación, que es lo que se necesita para los umbrales de agrupación aglomerativa.
Para solucionar este problema, volvimos a recurrir al conjunto de datos de referencia de STS. Calculamos las distancias para todos los pares en el conjunto de datos de entrenamiento y ajustamos un polinomio de las puntuaciones a los umbrales de distancia.
Este polinomio nos permite calcular el umbral de distancia necesario para alcanzar cualquier objetivo de similitud semántica. Para los resúmenes de revisión, seleccionamos una puntuación de 3,5, por lo que casi todos los grupos contienen oraciones que son equivalentes “aproximadamente” a “mayormente” o más.
Vale la pena señalar que esto se puede hacer en cualquier red integrada. Esto nos permite experimentar con diferentes redes de integración a medida que estén disponibles y cambiarlas rápidamente si lo deseamos sin preocuparnos de que los grupos tengan oraciones semánticamente diferentes.
Hasta este punto, sabíamos que podíamos confiar en nuestra compresión semántica, pero no estaba claro cuánta compresión podíamos obtener de nuestros datos. Como era de esperar, la cantidad de compresión varió según los diferentes productos, clientes e industrias.
Sin pérdida de información semántica, es decir, un umbral estricto de 4, sólo logramos una relación de compresión de 1,18 (es decir, un ahorro de espacio del 15%).
Claramente, la compresión sin pérdidas no sería suficiente para que esta característica fuera financieramente viable.
Sin embargo, nuestro enfoque de selección de distancia discutido anteriormente proporcionó una posibilidad interesante aquí: podemos aumentar lentamente la cantidad de pérdida de información ejecutando repetidamente la agrupación en umbrales más bajos para los datos restantes.
El enfoque es el siguiente:
- Ejecute la agrupación con un umbral seleccionado de puntuación = 4. Esto se considera sin pérdidas.
- Seleccione cualquier grupo periférico, es decir, aquellos con sólo unos pocos vectores. Estos se consideran «no comprimidos» y se utilizan para la siguiente fase. Elegimos volver a ejecutar la agrupación en clústeres con un tamaño inferior a 10.
- Ejecute la agrupación nuevamente con un umbral seleccionado de puntaje = 3. Esto no es sin pérdidas, pero no es tan malo.
- Seleccione cualquier grupo con un tamaño inferior a 10.
- Repita como desee, disminuyendo continuamente el umbral de puntuación.
Entonces, en cada paso de la agrupación, sacrificamos más pérdida de información, pero obtenemos más compresión y no enturbiamos las frases representativas sin pérdidas que seleccionamos durante el primer paso.
Además, este enfoque es extremadamente útil no sólo para resúmenes de revisión, donde queremos un alto nivel de similitud semántica a costa de una menor compresión, sino también para otros casos de uso en los que puede que nos importe menos la pérdida de información semántica pero deseamos gastar menos. en entradas rápidas.
En la práctica, todavía hay una cantidad significativamente grande de grupos con un solo vector, incluso después de bajar el umbral de puntuación varias veces. Estos se consideran valores atípicos y se toman muestras al azar para incluirlos en la pregunta final. Seleccionamos el tamaño de la muestra para asegurarnos de que el mensaje final tenga 25.000 tokens, pero no más.
La agrupación de múltiples pasos y el muestreo aleatorio de valores atípicos permiten la pérdida de información semántica a cambio de una ventana de contexto más pequeña para enviar al LLM. Esto plantea la pregunta: ¿qué tan buenos son nuestros resúmenes?
En Bazaarvoice, sabemos que la autenticidad es un requisito para la confianza del consumidor y nuestros resúmenes de reseñas deben seguir siendo auténticos para representar verdaderamente todas las voces capturadas en las reseñas. Cualquier enfoque de compresión con pérdidas corre el riesgo de tergiversar o excluir a los consumidores que se tomaron el tiempo para escribir una reseña.
Para garantizar que nuestra técnica de compresión fuera válida, la medimos directamente. Específicamente, para cada producto, probamos una serie de reseñas y luego utilizamos Evaluaciones LLM para identificar si el resumen era representativo y relevante para cada revisión. Esto nos da una métrica difícil de evaluar y equilibrar nuestra compresión.
Durante los últimos 20 años, hemos recopilado casi mil millones de reseñas generadas por usuarios y necesitábamos generar resúmenes de decenas de millones de productos. Muchos de estos productos tienen miles de reseñas, y algunas hasta millones, lo que agotaría las ventanas de contexto de los LLM y aumentaría considerablemente el precio.
Sin embargo, utilizando nuestro enfoque anterior, redujimos el tamaño del texto de entrada en 97,7% (una relación de compresión de 42), permitiéndonos escalar esta solución para todos los productos y cualquier cantidad de volumen de reseñas en el futuro.
Además, se redujo el costo de generar resúmenes para todo nuestro conjunto de datos a escala de miles de millones. 82,4%. Esto incluye el costo de incorporar los datos de la oración y almacenarlos en una base de datos.