vorheriger Artikel
Azure AI Search, Microsofts serverloses Angebot für das R in RAG, hat seine eigene Skalierungslogik. Sie verbirgt viel von der Komplexität serverbasierter Lösungen, erfordert aber spezifische Kenntnisse.
Grundbegriffe: Replikate, Partitionen, Indizes, Sucheinheiten und Dienstebenen
Zum Einstieg ein Überblick über die Grundbegriffe der Konfiguration von Azure AI Search:
Indizes: Indizes speichern die Dokumente analog zu einer Tabelle in einer relationalen Datenbank. Je nach Dienstebene (siehe unten) sind bis zu 200 Indizes möglich, in der speziell für eine hohe Anzahl von Indizes ausgelegten Dienstebene Standard S3 High Density sogar bis zu 3.000.
- Partitionen: Indizes sind der logische Speicherort, Partitionen das physische Pendant. Es lässt sich nur die Anzahl Partitionen konfigurieren. Jeder Index wird auf alle Partitionen verteilt, außer in der Dienstebene Standard S3 High Density, wo jeder Index eindeutig einer Partition zugeordnet ist.
- Replikate: Replikate sind identische Kopien Ihres Dienstes, die für das Load Balancing verwendet werden.
- Dienstebene: Azure AI Search ist in acht verschiedenen Dienstebenen verfügbar, die sich in der maximalen Anzahl von Indizes, Partitionen und Replikaten unterscheiden. Sie unterscheiden sich zudem in der Partitionsgröße (die für jede Stufe einen festen Wert hat) und im verfügbaren Gesamtspeicher. Höheren Dienstebenen wird leistungsfähigere Hardware zugewiesen (die Spezifikationen sind nicht dokumentiert).
- Sucheinheiten (manchmal auch Skalierungseinheiten genannt): Die Anzahl der Sucheinheiten ist das Produkt aus der Anzahl Replikate und der Anzahl Partitionen. Multipliziert man die Anzahl Sucheinheiten mit der Gebühr, die der Dienstebene zugeordnet ist, erhält man den Rechnungsbetrag.
Zwei besondere Dienstebenen: die kostenlose Ebene und Standard S3 High Density
Es gibt zwei besondere Ebenen. Die kostenlose Ebene sollte nur für Demos und Ausbildungszwecke verwendet werden. Ihre Ressourcen werden mit anderen Diensten geteilt, was die Leistung etwas unvorhersehbar macht, und die Limitierungen sind sehr eng. Selbst bei einem Proof of Concept möchte man Einblicke in den Abfragedurchsatz und andere Leistungskennzahlen spezifisch für die eigenen Daten gewinnen. Das ist mit der kostenlosen Ebene nicht zuverlässig möglich. Daher sollte man selbst bei einem Proof of Concept zumindest die Ebene Basic verwenden.
Die Ebene Standard S3 High Density unterstützt bis zu 3.000 Indizes, im Vergleich zu maximal 200 in anderen Tiers. Sie ist für mandantenfähige Anwendungen konzipiert, ein Szenario, das sich von typischen Anwendungsfällen unterscheidet. Im weiteren Verlauf dieses Textes gehen wir davon aus, dass wir höchstens 200 Indizes benötigen. Mandantenfähige Anwendungen und die Ebene Standard S3 High Density werden nicht behandelt.
Dimensionierung und Skalierung für einen Proof of Concept: Speicherbedarf im Mittelpunkt
Die Dimensionierung von Azure AI Search für einen Proof of Concept ist normalerweise einfacher als in einer Produktionsumgebung. Zwei Dinge helfen uns in einer typischen Proof-of-Concept-Situation:
- Die Anzahl der Benutzer und Abfragen ist gering und wächst langsam, wenn überhaupt.
- Wir müssen uns nicht an SLAs halten.
In der Regel reicht daher ein Replikat. Stattdessen konzentrieren wir uns auf den insgesamt benötigten Speicherplatz. Diese Zahl lässt sich nicht genau abschätzen. In der Azure-Dokumentation heißt es, dass es nur eine Möglichkeit gibt, die Größe eines Indexes zu ermitteln: ihn zu erstellen. Da es jedoch große Unterschiede zwischen den verfügbaren Speicherkapazitäten der einzelnen Dienstebenen gibt, wirst du wahrscheinlich eine Vorstellung davon haben, welche Ebene du benötigst. In Zweifelsfällen ist die höhere Ebene die bessere Wahl. Ein Wechsel der Dienstebene bedeutet, dass der Suchdienst komplett neu aufgebaut werden muss. Dafür ist in einer typischen Proof-of-Concept-Situation keine Zeit. Eine andere Möglichkeit besteht darin, eine Ebene zu wählen, die möglicherweise nicht ausreicht, um alle Daten aufzunehmen, und mit dem Risiko zu leben, nicht alle Dokumente berücksichtigen zu können. Schließlich kann auch die Anzahl der benötigten Indizes die Wahl der Dienstebene beeinflussen.
Dimensionierung und Skalierung in Produktion: das Design von vornherein darauf auslegen
Es gibt zwei wichtige Dinge, die man nur durch Tests herausfinden kann:
- Die Größe eines Indexes
- Die Query Performance auf einer anderen Dienstebene, mit einer anderen Anzahl von Replikaten oder Änderungen an Indizes. Die Erhöhung der Anzahl der Replikate verbessert die Abfrageleistung, aber die Beschleunigung ist nicht proportional zur Anzahl der Replikate und kann bei verschiedenen Abfragen unterschiedlich sein.
Für eine Produktionsumgebung bedeutet dies, dass alle Größen- und Skalierungsentscheidungen ausgiebig getestet werden müssen. Man kann die Skalierung nicht mit einer Skalierungsstrategie vorbereiten, die einem sagt, wie man die Parameter in einer bestimmten Situation wählen soll. Stattdessen muss man die Architektur so gestalten, dass häufige, realistische und effiziente Tests möglich sind. Testen braucht Zeit: Nicht nur die Migration auf eine andere Ebene erfordert Zeit und Aufwand für den kompletten Neuaufbau. Auch die Änderung der Anzahl der Replikate oder Partitionen in der Konfiguration kann aufgrund der potenziell großen Datenmengen, die dabei verschoben werden, mehrere Stunden in Anspruch nehmen.
Architektur und Ihre DevOps-Prozesse müssen auf die Herausforderungen des Testens angelegt sein:
Architektur: Plane einen Traffic-Split/eine Traffic-Kopie ein, die für Tests einen Teil des Traffics an einen separaten Azure-AI-Suchdienst weiterleitet.
DevOps: Der Build-Prozess des Testdienstes muss vollständig automatisiert ablaufen. Infrastructure as Code ist ein Teil der Lösung.
Hast du Fragen zur Größenbestimmung und Skalierung?
Die Dimensionierung und Skalierung der Azure-KI-Suche ist keine triviale Aufgabe, selbst auf dieser etwas oberflächlichen Überblicksebene. Wenn du Fragen hast oder andere RAG-bezogene Themen diskutieren möchtest, sprich mich gerne auf LinkedIn an oder über Michael.Allgoewer@btelligent.com.
Wenn du dich auch für andere Aspekte von RAG, LLMs und DevOps/MLOps interessierst, findest du weitere Anregungen in unseren anderen Blogeinträgen.
