datos estructurados en un sistema RAG, los ingenieros a menudo incorporan JSON sin formato en una base de datos vectorial. La realidad, sin embargo, es que este enfoque intuitivo conduce a un rendimiento dramáticamente pobre. Las incorporaciones modernas se basan en la arquitectura BERT, que es esencialmente la parte codificadora de un Transformer, y están entrenadas en un enorme conjunto de datos de texto con el objetivo principal de capturar el significado semántico. Los modelos de incrustación modernos pueden proporcionar un rendimiento de recuperación increíble, pero están entrenados en un gran conjunto de texto no estructurado con un enfoque en el significado semántico. Como resultado, aunque la incrustación de JSON puede parecer una solución intuitivamente simple y elegante, el uso de un modelo de incrustación genérico para objetos JSON demostraría resultados que distan mucho del máximo rendimiento.
inmersión profunda
Tokenización
El primer paso es la tokenización, que toma el texto y lo divide en tokens, que generalmente son una parte genérica de la palabra. Los modelos de incrustación modernos utilizan codificación de par de bytes (BPE) o algoritmos de tokenización de WordPieza. Estos algoritmos están optimizados para el lenguaje natural y dividen las palabras en subcomponentes comunes. Cuando un tokenizador encuentra JSON sin formato, tiene problemas con la alta frecuencia de caracteres no alfanuméricos. Por ejemplo, “usd”: 10, no se considera un par clave-valor; en cambio, está fragmentado:
Las comillas (“), dos puntos (:) y la coma (,) Tokens usd y 10
Esto crea una baja relación señal-ruido. En el lenguaje natural, casi todas las palabras contribuyen a la “señal” semántica. Mientras que en JSON (y otros formatos estructurados), un porcentaje significativo de tokens se “desperdician” en una sintaxis estructural que no contiene valor semántico.
Cálculo de atención
El poder central de Transformers radica en el mecanismo de atención. Esto permite que el modelo sopese la importancia de los tokens entre sí.
En la frase El precio es 10 dólares estadounidenses o 9 euros, la atención puede vincular fácilmente el valor 10 con el precio del concepto porque estas relaciones están bien representadas en los datos previos al entrenamiento del modelo y el modelo ha visto este patrón lingüístico millones de veces. Por otro lado, en el JSON sin formato:
“precio”: { “usd”: 10, “eur”: 9, }
el modelo encuentra una sintaxis estructural que no fue optimizada principalmente para “leer”. Sin el conector lingüístico, el vector resultante no podrá capturar la verdadera intención de los datos, ya que las relaciones entre la clave y el valor quedan oscurecidas por el formato mismo.
Agrupación media
El último paso para generar una única representación incrustada del documento es Mean Pooling. Matemáticamente, la incrustación final (E) es el centroide de todos los vectores simbólicos (e1, e2, e3) en el documento:
Aquí es donde los tokens JSON se convierten en un problema matemático. Si el 25% de los tokens del documento son marcadores estructurales (llaves, comillas, dos puntos), el vector final está fuertemente influenciado por el “significado” de la puntuación. Como resultado, estas fichas de ruido “alejan” efectivamente el vector de su verdadero centro semántico en el espacio vectorial. Cuando un usuario envía una consulta en lenguaje natural, la distancia entre el vector de consulta “limpio” y el vector JSON “ruidoso” aumenta, lo que perjudica directamente las métricas de recuperación.
Aplanarlo
Ahora que conocemos las limitaciones de JSON, debemos descubrir cómo resolverlas. El enfoque general y más sencillo es aplanar el JSON y convertirlo a lenguaje natural.
Consideremos el objeto de producto típico:
{ “skuId”: “123”, “description”: “Este es un producto de prueba utilizado con fines de demostración”, “quantity”: 5, “price”: { “usd”: 10, “eur”: 9, }, “availableDiscounts”: [“1”, “2”, “3”]”giftCardAvailable”: “true”, “category”: “producto de demostración”… }
Este es un objeto simple con algunos atributos como descripción, etc. Apliquemos la tokenización y veamos cómo se ve:
Ahora, convirtámoslo en texto para facilitar el trabajo de las incrustaciones. Para hacer eso, podemos definir una plantilla y sustituir en ella los valores JSON. Por ejemplo, esta plantilla podría usarse para describir el producto:
El producto con SKU {skuId} pertenece a la categoría “{category}” Descripción: {description} Tiene una cantidad de {quantity} disponible El precio es {price.usd} dólares estadounidenses o {price.eur} euros Los identificadores de descuento disponibles incluyen {availableDiscounts as coma-separated list} Las tarjetas de regalo son {giftCardAvailable ? “disponible” : “no disponible”} para este producto
Entonces el resultado final se verá así:
El producto con SKU 123 pertenece a la categoría “producto de demostración” Descripción: Este es un producto de prueba utilizado con fines de demostración. Tiene una cantidad de 5 disponibles. El precio es de 10 dólares estadounidenses o 9 euros. Los identificadores de descuento disponibles incluyen 1, 2 y 3. Hay tarjetas de regalo disponibles para este producto.
Y aplíquele tokenizador:
No sólo tiene ahora un 14% menos de tokens, sino que también es una forma mucho más clara con el significado semántico y el contexto requerido.
midamos los resultados
Nota: El código completo y reproducible para este experimento está disponible en el cuaderno de Google Colab.
Ahora intentemos medir el rendimiento de recuperación para ambas opciones. Nos centraremos en las métricas de recuperación estándar como Recall@k, Precision@k y MRR para mantenerlo simple y utilizaremos un modelo de integración genérico (todo MiniLM-L6-v2) y el conjunto de datos de Amazon ESCI con 5000 consultas aleatorias y 3809 productos asociados.
El MiniLM-L6-v2 es una opción popular, que es pequeño (22,7 m de parámetros) pero proporciona resultados rápidos y precisos, lo que lo convierte en una buena opción para este experimento.
Para el conjunto de datos, se utiliza la versión de Amazon ESCI, específicamente milistu/amazon-esci-data (), que está disponible en Hugging Face y contiene una colección de productos de Amazon y datos de consultas de búsqueda.
La función de aplanamiento utilizada para la conversión de texto es:
def flatten_product(producto): return ( f”Producto {producto[‘product_title’]} de la marca {producto[‘product_brand’]}” f” e ID del producto {producto[‘product_id’]}” f” y descripción {producto[‘product_description’]}” )
Una muestra de los datos JSON sin procesar es:
{ “product_id”: “B07NKPWJMG”, “title”: “RoWood 3D Puzzles para adultos, kits de engranajes mecánicos de madera para adolescentes y niños mayores de 14 años”, “description”: “
Presupuesto
Número de modelo: Caja del tesoro Rowood LK502
Tiempo medio de construcción: 5 horas
Piezas Totales: 123
Peso del modelo: 0,69 kg
Peso de la caja: 0,74 KG
Tamaño ensamblado: 100*124*85mm
Tamaño de la caja: 320*235*39 mm
Certificados: EN71,-1,-2,-3,ASTMF963
Rango de edad recomendado: 14+
Contenido
Hojas de madera contrachapada
Resorte Metálico
Instrucciones ilustradas
Accesorios
HECHO PARA ENSAMBLAJE
-Siga las instrucciones proporcionadas en el folleto y monte un rompecabezas en 3D con una diversión emocionante y atractiva. Sienta el orgullo de la auto creación consiguiendo este exquisito trabajo en madera como un profesional.
GLORIFICA TU ESPACIO VITAL
-Revive el encanto enigmático y alegra tus fiestas y reuniones con una experiencia única e interesante.
“, “marca”: “RoWood”, “color”: “Caja del tesoro” }
Para la búsqueda vectorial se crean dos índices FAISS: uno para el texto aplanado y otro para el texto con formato JSON. Ambos índices son planos, lo que significa que compararán distancias para cada una de las entradas existentes en lugar de utilizar un índice aproximado del vecino más cercano (ANN). Esto es importante para garantizar que las métricas de recuperación no se vean afectadas por la ANN.
D = 384 index_json = faiss.IndexFlatIP(D) index_flatten = faiss.IndexFlatIP(D)
Para reducir el conjunto de datos, se seleccionó un número aleatorio de 5000 consultas y se incrustaron y agregaron todos los productos correspondientes a los índices. Como resultado, las métricas recopiladas son las siguientes:
Y el cambio de rendimiento de la versión aplanada es:
El análisis confirma que incorporar datos estructurados sin procesar en un espacio vectorial genérico es un enfoque subóptimo y agregar un simple paso de preprocesamiento para aplanar los datos estructurados ofrece consistentemente una mejora significativa para las métricas de recuperación (aumentando el recuerdo@k y la precisión@k en aproximadamente un 20%). La principal conclusión para los ingenieros que construyen sistemas RAG es que la preparación eficaz de los datos es extremadamente importante para lograr el máximo rendimiento del sistema de recuperación semántica/RAG.
Referencias
[1] Código de experimento completo https://colab.research.google.com/drive/1dTgt6xwmA6CeIKE38lf2cZVahaJNbQB1?usp=sharing
[2] Modelo https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2
[3] Conjunto de datos de Amazon ICES. Versión específica utilizada: https://huggingface.co/datasets/milistu/amazon-esci-data
El conjunto de datos original disponible en https://www.amazon.science/code-and-datasets/shopping-queries-dataset-a-large-scale-esci-benchmark-for-improving-product-search
[4] FAISS https://ai.meta.com/tools/faiss/