Bei der Integration strukturierter Daten in ein RAG-System binden Ingenieure häufig standardmäßig rohes JSON in eine Vektordatenbank ein. Die Realität ist jedoch, dass dieser intuitive Ansatz zu einer dramatisch schlechten Leistung führt. Moderne Einbettungen basieren auf der BERT-Architektur, die im Wesentlichen der Encoder-Teil von a ist Transformatorund werden anhand eines riesigen Textdatensatzes trainiert, mit dem Hauptziel, die semantische Bedeutung zu erfassen. Moderne Einbettungsmodelle können eine unglaubliche Abrufleistung bieten, sie werden jedoch auf eine große Menge unstrukturierter Texte trainiert, wobei der Schwerpunkt auf der semantischen Bedeutung liegt. Auch wenn die Einbettung von JSON wie eine intuitiv einfache und elegante Lösung erscheint, würde die Verwendung eines generischen Einbettungsmodells für JSON-Objekte Ergebnisse liefern, die weit von der Spitzenleistung entfernt sind.
Tiefer Tauchgang
Tokenisierung
Der erste Schritt ist die Tokenisierung, bei der der Textual content in Token aufgeteilt wird, die im Allgemeinen einen generischen Teil des Wortes darstellen. Die modernen Einbettungsmodelle nutzen Byte-Pair-Encoding (BPE) oder WordPiece-Tokenisierungsalgorithmen. Diese Algorithmen sind für natürliche Sprache optimiert und zerlegen Wörter in gemeinsame Unterkomponenten. Wenn ein Tokenizer auf rohes JSON stößt, hat er Probleme mit der hohen Häufigkeit nicht-alphanumerischer Zeichen. Zum Beispiel, "usd": 10, wird nicht als Schlüssel-Wert-Paar betrachtet; Stattdessen ist es fragmentiert:
- Die Zitate (
"), Doppelpunkt (:) und Komma (,) - Token
usdUnd10
Dadurch entsteht ein Tief Sign-Rausch-Verhältnis. In der natürlichen Sprache tragen quick alle Wörter zum semantischen „Sign“ bei. Während in JSON (und anderen strukturierten Formaten) ein erheblicher Prozentsatz der Token für strukturelle Syntax „verschwendet“ wird, die keinen semantischen Wert enthält.
Aufmerksamkeitsberechnung
Die Kernkraft von Transformatoren liegt im Aufmerksamkeitsmechanismus. Dadurch kann das Modell die Bedeutung der Token relativ zueinander gewichten.
Im Satz The value is 10 US {dollars} or 9 eurosAufmerksamkeit kann den Wert leicht verknüpfen 10 zum Konzept worth weil diese Beziehungen in den Pre-Coaching-Daten des Modells intestine dargestellt sind und das Modell dieses sprachliche Muster millionenfach gesehen hat. Andererseits im rohen JSON:
"worth": {
"usd": 10,
"eur": 9,
}
Das Modell stößt auf eine strukturelle Syntax, die nicht primär für das „Lesen“ optimiert wurde. Ohne den linguistischen Konnektor kann der resultierende Vektor die wahre Absicht der Daten nicht erfassen, da die Beziehungen zwischen dem Schlüssel und dem Wert durch das Format selbst verdeckt werden.
Mittleres Pooling
Der letzte Schritt beim Generieren einer einzelnen Einbettungsdarstellung des Dokuments ist Imply Pooling. Mathematisch gesehen ist die endgültige Einbettung (E) ist der Schwerpunkt aller Token-Vektoren (e1, e2, e3) im Dokument:

Hier werden die JSON-Tokens zu einer mathematischen Belastung. Wenn 25 % der Token im Dokument strukturelle Markierungen (geschweifte Klammern, Anführungszeichen, Doppelpunkte) sind, wird der endgültige Vektor stark von der „Bedeutung“ der Interpunktion beeinflusst. Dadurch wird der Vektor durch diese Rauschtoken effektiv von seinem wahren semantischen Zentrum im Vektorraum „herausgezogen“. Wenn ein Benutzer eine Abfrage in natürlicher Sprache sendet, vergrößert sich der Abstand zwischen dem „sauberen“ Abfragevektor und dem „verrauschten“ JSON-Vektor, was sich direkt negativ auf die Abrufmetriken auswirkt.
Machen Sie es flach
Nachdem wir nun die JSON-Einschränkungen kennen, müssen wir herausfinden, wie wir sie beheben können. Der allgemeine und einfachste Ansatz besteht darin, JSON zu reduzieren und in natürliche Sprache umzuwandeln.
Betrachten wir das typische Produktobjekt:
{
"skuId": "123",
"description": "It is a check product used for demonstration functions",
"amount": 5,
"worth": {
"usd": 10,
"eur": 9,
},
"availableDiscounts": ("1", "2", "3"),
"giftCardAvailable": "true",
"class": "demo product"
...
}
Dies ist ein einfaches Objekt mit einigen Attributen wie Beschreibung usw. Wenden wir die Tokenisierung darauf an und sehen, wie es aussieht:

Nun wandeln wir es in Textual content um, um die Arbeit der Einbettungen zu erleichtern. Dazu können wir eine Vorlage definieren und die JSON-Werte darin ersetzen. Diese Vorlage könnte beispielsweise zur Beschreibung des Produkts verwendet werden:
Product with SKU {skuId} belongs to the class "{class}"
Description: {description}
It has a amount of {amount} accessible
The value is {worth.usd} US {dollars} or {worth.eur} euros
Obtainable low cost ids embrace {availableDiscounts as comma-separated listing}
Present playing cards are {giftCardAvailable ? "accessible" : "not accessible"} for this product
Das Endergebnis wird additionally so aussehen:
Product with SKU 123 belongs to the class "demo product"
Description: It is a check product used for demonstration functions
It has a amount of 5 accessible
The value is 10 US {dollars} or 9 euros
Obtainable low cost ids embrace 1, 2, and three
Present playing cards can be found for this product
Und wenden Sie den Tokenizer darauf an:

Es verfügt jetzt nicht nur über 14 % weniger Token, sondern ist auch eine viel klarere Type mit der semantischen Bedeutung und dem erforderlichen Kontext.
Lassen Sie uns die Ergebnisse messen
Hinweis: Der vollständige, reproduzierbare Code für dieses Experiment ist im verfügbar Google Colab-Notizbuch
Versuchen wir nun, die Abrufleistung für beide Optionen zu messen. Wir werden uns auf die Customary-Abrufmetriken wie Recall@okay, Precision@okay und MRR konzentrieren, um es einfach zu halten, und werden ein generisches Einbettungsmodell verwenden (All-MiniLM-L6-v2) und die Amazon ESCI Datensatz mit zufälligen 5.000 Abfragen und 3.809 zugehörigen Produkten.
Der All-MiniLM-L6-v2 ist eine beliebte Wahl, da sie klein ist (22,7 m Parameter), aber schnelle und genaue Ergebnisse liefert, was sie zu einer guten Wahl für dieses Experiment macht.
Für den Datensatz die Model von Amazon ESCI wird speziell verwendet milistu/amazon-esci-data (), das auf Hugging Face verfügbar ist und eine Sammlung von Amazon-Produkten und Suchanfragendaten enthält.
Die für die Textkonvertierung verwendete Reduzierungsfunktion ist:
def flatten_product(product):
return (
f"Product {product('product_title')} from model {product('product_brand')}"
f" and product id {product('product_id')}"
f" and outline {product('product_description')}"
)
Ein Beispiel der JSON-Rohdaten ist:
{
"product_id": "B07NKPWJMG",
"title": "RoWood 3D Puzzles for Adults, Wood Mechanical Gear Kits for Teenagers Children Age 14+",
"description": "<p> <sturdy>Specs</sturdy><br /> Mannequin Quantity: Rowood Treasure field LK502<br /> Common construct time: 5 hours<br /> Complete Items: 123<br /> Mannequin weight: 0.69 kg<br /> Field weight: 0.74 KG<br /> Assembled measurement: 100*124*85 mm<br /> Field measurement: 320*235*39 mm<br /> Certificates: EN71,-1,-2,-3,ASTMF963<br /> Beneficial Age Vary: 14+<br /> <br /> <sturdy>Contents</sturdy><br /> Plywood sheets<br /> Metallic Spring<br /> Illustrated directions<br /> Equipment<br /> <br /> <sturdy>MADE FOR ASSEMBLY</sturdy><br /> -Observe the directions offered within the booklet and meeting 3d puzzle with some thrilling and interesting enjoyable. Fell the pleasure of self creation getting this beautiful picket work like a professional.<br /> <sturdy>GLORIFY YOUR LIVING SPACE</sturdy><br /> -Revive the enigmatic attraction and cheer your events and get-togethers with an expertise that's distinctive and attention-grabbing .<br /> <br />",
"model": "RoWood",
"coloration": "Treasure Field"
}
Für die Vektorsuche zwei FAISS Es werden Indizes erstellt: einer für den reduzierten Textual content und einer für den JSON-formatierten Textual content. Beide Indizes sind flach, was bedeutet, dass sie die Entfernungen für jeden der vorhandenen Einträge vergleichen, anstatt einen zu verwenden Ungefährer nächster Nachbar (ANN) Index. Dies ist wichtig, um sicherzustellen, dass die Abrufmetriken nicht durch das ANN beeinflusst werden.
D = 384
index_json = faiss.IndexFlatIP(D)
index_flatten = faiss.IndexFlatIP(D)
Um den Datensatz zu reduzieren, wurde eine zufällige Anzahl von 5.000 Abfragen ausgewählt und alle entsprechenden Produkte eingebettet und den Indizes hinzugefügt. Infolgedessen lauten die gesammelten Metriken wie folgt:

all-MiniLM-L6-v2 Einbettungsmodell in den Amazon ESCI-Datensatz. Der abgeflachte Ansatz führt durchweg zu höheren Ergebnissen bei allen wichtigen Abrufmetriken (Precision@10, Recall@10 und MRR). Bild vom AutorUnd die Leistungsänderung der abgeflachten Model ist:

Die Analyse bestätigt, dass die Einbettung strukturierter Rohdaten in den generischen Vektorraum ein suboptimaler Ansatz ist und dass das Hinzufügen eines einfachen Vorverarbeitungsschritts zur Glättung strukturierter Daten durchweg eine erhebliche Verbesserung der Abrufmetriken liefert (Erhöhung von Recall@okay und Precision@okay um etwa 20 %). Die wichtigste Erkenntnis für Ingenieure, die RAG-Systeme entwickeln, besteht darin, dass eine effektive Datenaufbereitung äußerst wichtig ist, um die Spitzenleistung des semantischen Retrieval-/RAG-Programs zu erreichen.
Referenzen
(1) Vollständiger Experimentcode https://colab.analysis.google.com/drive/1dTgt6xwmA6CeIKE38lf2cZVahaJNbQB1?usp=sharing
(2) Modell https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2
(3) Amazon ESCI-Datensatz. Spezifische verwendete Model: https://huggingface.co/datasets/milistu/amazon-esci-data
Der Originaldatensatz ist verfügbar unter 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/instruments/faiss/
