Hör zu! https://leebutterman.com/wikipedia-search-by-vibes/
Dies ist eine browserbasierte Suchmaschine für Wikipedia, in der Sie nach „die rötlichen hohen Bäume an der Küste von San Francisco“ suchen und Ergebnisse wie „Sequoia sempervirens“ (ein Name eines Mammutbaums) finden können. Der Browser lädt die Datenbank herunter und die Suche erfolgt offline. Das Herunterladen von zwei Millionen Wikipedia-Seiten mit ihren Titeln dauert etwa 100 MB und es dauert weniger als 50 Millisekunden, bis die Endergebnisse angezeigt werden. Dies nutzt Satztransformatoren zum Einbetten von Dokumenten, Produktquantisierung zum Komprimieren von Einbettungen, pq.js um die Entfernungsberechnung im Browser auszuführen, und transformers.js um Satztransformatoren im Browser für Abfragen auszuführen.
Ja.
Die Echtzeitsuche in Millionen von Dokumenten erfolgt in Echtzeit und völlig offline. Die Ergebnisse werden alle 10 ms auf ein Mobilgerät zurückgestreamt und die Suchergebnisse werden nach und nach aktualisiert, während die Datenbank nacheinander gescannt wird.
Timing: erste Ergebnisse in 21 ms, 70 % der endgültigen Ergebnisse in 116 ms, Facettensuche in 23 ms
Die Distanzberechnung über 2 Millionen Einbettungen dauert insgesamt 250 ms, über 20 Iterationen, und wir können Zwischenergebnisse mit einer facettierten Top-10-Berechnung anzeigen, die 8 ms dauert. Um Zwischenergebnisse anzuzeigen, führen wir Stapel von 100.000 Distanzberechnungen gleichzeitig durch, berechnen den Top-k und zeichnen neu, nachdem ein Timer (30 ms) abgelaufen ist.
Wir ordnen Einbettungen nach komprimierter Seitengröße: Seiten mit mehr Informationen werden zuerst analysiert und in einem Top-10-Ranking zurückgegeben und könnten in einem Suchergebnis nützlicher sein. Beachten Sie, dass die Suchergebnisse weiterhin einströmen und die Top-Ergebnisse aktualisieren, die meisten Seiten mit geringerer Seitengröße jedoch nicht in den Top 10 ranken, sodass die Suche schneller angezeigt wird, als wenn wir die Benutzeroberfläche nicht aktualisiert hätten, bis alles zurückgegeben wurde.
70 % der endgültigen Suchergebnisse befanden sich in den ersten 670.000 Einbettungen, die insgesamt in 116 Millisekunden gerendert wurden (beachten Sie das Topk-Timing unten links, das Entfernungsberechnungen als positive Zeiten und Topk-Berechnungen als negative Zeiten zählt):
Beachten Sie, dass durch das Ändern der Facette für die Onomatopoeia-Suche (Änderung des ersten Buchstabens der zurückzugebenden Seite) die Ausführung einer neuen Einbettung vermieden wurde und die Rückgabe in weniger als 25 ms erfolgte. Die Änderung der Anzahl der Ergebnisse von den Top 10 zu den Top 20 oder Top 100 erfolgt ebenfalls augenblicklich.
200.000 Einbettungen und Seitentitel werden in Arrow auf 10 MB komprimiert
Die Datenbank ist klein genug, um gelegentliche Anwendungsfälle mit bis zu einer Million Einbettungen ohne Sonderbehandlung zu unterstützen.
Beachten Sie, dass wir für eine hohe Leistung Arrow anstelle von JSON verwenden. Arrow kann unsere 8-Bit-Ganzzahlprodukt-Quantisierungs-Arrays kompakt speichern, und Arrow kann ein Array von Strings als Array von Indizes in einem Puffer speichern, was eine erhebliche Einsparung im Vergleich zu einer Million Javascript-String-Objekten darstellt.
Diese ONNX-Modelle laufen derzeit in WASM
Bisher gibt es keine GPU-Beschleunigung, sondern nur WebAssembly. ONNX ist ein praktisches Kompilierungsziel. WebGPU ist noch sehr neu und eine mit Spannung erwartete zukünftige Richtung.
Es stehen viele Satztransformatoren zur Auswahl! Es gibt eine Rangliste der Satzeinbettungen: https://huggingface.co/blog/mteb
Der all-minilm-l6-v2 Das Modell hat eine angemessene Leistung https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2 und ist klein und in ONNX-Gewichten verfügbar https://huggingface.co/Xenova/all-MiniLM-L6-v2/ für Transformers.js https://github.com/xenova/transformers.js .
6 Millionen Seiten * 384-dimensionale Einbettungen * 32-Bit-Floats sind über 9 GB. Selbst eine Million Einbettungen in float16-Präzision sind 800 MB groß. Für den gelegentlichen Gebrauch ist es zu groß.
Um die oberste Million auszuwählen, besteht eine erste Annäherungsweise darin, die Seiten mit den meisten Informationen auszuwählen: Komprimieren Sie jede Seite und sehen Sie sich die Anzahl der ausgegebenen Bytes an. Listen wären überrepräsentiert (Listen sind weniger komprimierbar als allgemeiner Text), die Linkstruktur von Webseiten wird nicht erkannt, ist aber kostengünstig zu berechnen und einfach zu starten.
FAISS (https://faiss.ai) ist eine sehr beliebte serverseitige eingebettete Suchmaschine mit vielen Einstellknöpfen zum Erstellen verschiedener Suchindizes-Stile. Autofaiss (https://github.com/criteo/autofaiss) empfiehlt normalerweise die Verwendung der Produktquantisierung nach der Erstellung von IVF-Indizes oder HNSW-Indizes (Pinecone bietet eine großartige Einführung in die Vektorindizierung https://www.pinecone.io/learn/vector -indizes/).
Die Produktquantisierung ist außerordentlich einfach zu implementieren: Das Erstellen einer „Abstandstabelle“ dauert weniger als 5 Zeilen Numpy und die Verwendung dieser zum Ermitteln von Abständen ist ein Einzeiler.
Häufig möchten Sie in bestimmten Produktunterkategorien suchen, z. B. wenn Sie bei einer Websuche nur PDFs oder Ergebnisse in altem Latein finden. Indem wir die Distanzberechnung von der Berechnung einer Top-10-Rangliste trennen, können wir die Flugdistanzen vor der Rangliste manipulieren. Für die Suche im Millionenmaßstab ist dies durchaus machbar. Bei dieser Wikipedia-Suche gibt es eine Suchfacette: das erste Zeichen der Seite. Da das Top-K-Ranking von der Distanzberechnung getrennt ist, können wir die Neuberechnung von Abfrageeinbettungen und Distanzen vermeiden, um verschiedene Facettenwerte in Echtzeit zu untersuchen.
ONNX verfügt über einen speziellen Opcode, der genau den Produktquantisierungsschritt ausführt! Dieser Opcode ist GatherElements. Leider verwendet der PyTorch ONNX-Export diesen speziellen Opcode für das Modell nicht wie geschrieben. Glücklicherweise gibt es reichlich Unterstützung für das Lesen und Schreiben von ONNX außerhalb eines PyTorch-Kompilierungsschritts.
Ein nützliches grafisches Bearbeitungstool für ONNX ist ONNX-modifier unter https://github.com/ZhangGe6/onnx-modifier, das eine benutzerfreundliche Schnittstelle zum Hinzufügen von Elementen zum Datenflussdiagramm jedes exportierten ONNX-Modells bietet.
Durch die Durchführung mehrerer Schritte im PyTorch-Modell, das in ONNX kompiliert wird, und durch das Ersetzen aller Schritte durch einen ONNX-Opcode ist die Entfernungsberechnung etwa viermal schneller.
Wie bereits erwähnt, ist das Arrow-Format viel kompakter im Speicher und viel kompakter auf der Festplatte, um die Einbettungen und Metadaten (Seitentitel) zu speichern.
Da das Arrow-Array-Format nur eindimensionale Daten speichert, wir über 48 Dimensionen von Einbettungsdaten verfügen und keine Einbettungsdaten in einem anderen Datenformat speichern möchten, benötigen wir zwei separate Schemata, eines für die Metadaten (mit jeweils einhunderttausend Zeilen) und eine für die Einbettungen (mit jeweils hunderttausend * 48 Zeilen), und wir formen die Einbettungen beim Laden um.
Die Speicherung des Produktquantisierungscodebuchs in JSON beträgt weniger als 1,0 MB, daher ist es weniger wichtig, diesen Teil zu optimieren.
Viele der Bibliotheksfunktionen in der vollständigen Wikipedia-Such-App sollten in wiederverwendbare pq.js-Komponenten migriert werden. Viele der ONNX-Formen sind vorgebacken, daher wäre es sinnvoll, unterschiedliche Quantisierungsstufen und unterschiedliche Einbettungsdimensionen zu unterstützen. Rufen Sie!
