Das Routing geht der Retrieval voraus, nicht der Embedding-Dimension

KDnuggets' Juni-2026-Umfrage zu den Fehlern der Retrieval-augmented Generation berichtet von einem globalen Industriekonzern, der 400.000 USD für sein RAG-System veranschlagt hatte, im ersten Jahr 1,2 Millionen USD ausgab und bei 23 % Genauigkeit bei technischen Dokumentationsanfragen landete, bevor das Projekt eingestellt wurde. Die Diagnose des Artikels ist strukturell, keine Frage des Feintunings: Retrieval-Irrelevanz, Context Poisoning und ein Chunk-Größen-Konflikt, den keine Embedding-Dimension auflöst. Seine Verschreibung sind vier Architekturen, gewählt nach Anfragetyp, mit dem tragenden Satz: „die entscheidende Änderung besteht darin, das Routing explizit zu machen. Jede Anfrage wird klassifiziert, bevor irgendeine Retrieval läuft." (Nate Rosidi, KDnuggets, „Your RAG Pipeline Is Probably Useless. Here's a Better Alternative", veröffentlicht 2026-06-29, abgerufen 2026-08-23, https://www.kdnuggets.com/your-rag-pipeline-is-probably-useless-heres-a-better-alternative). Der Honest Architect liest den Text als Theorem 3 angewendet auf Retrieval: eine Eigenschaft (faktische Relevanz) ist genau dann garantiert, wenn ihr Mechanismus (explizites Routing vor der Retrieval) implementiert ist und misst — und Embedding-Dimensionen zu einem Design hinzuzufügen, dem dieser Mechanismus fehlt, macht den Fehler teurer, nicht billiger.

[UNIQUE INSIGHT]: Die Over-Engineering-Falle ist Theorem 3 im Miniaturformat. Man kann faktische Relevanz nicht garantieren, indem man mehr von einem Mechanismus (höherdimensionale Embeddings, mehr Reranking, mehrstufige Retrieval) hinzufügt, der Relevanz nicht implementiert. Relevanz ist eine Routing-Eigenschaft — gehört diese Anfrage zu diesem Corpus, dieser Version, diesem Dokument? — keine Ähnlichkeitseigenschaft. Den falschen Mechanismus zu skalieren, häuft die Kosten an, ohne die Eigenschaft zu erzeugen.

Kernergebnisse

• Retrieval-Irrelevanz ist ein Fehler durch fehlenden Mechanismus. Theorem 3: die Eigenschaft faktische-Relevanz wird garantiert, indem man die Anfrage vor der Retrieval an den richtigen Corpus, die richtige Version und den richtigen Dokumenttyp routet, nicht durch Vektorähnlichkeit. Der Artikel: eine Anfrage zu Elternzeit liefert die Richtlinie von 2022, die von 2024 und einen Kultur-Blogbeitrag, alle hoch in der Embedding-Distanz, keiner antwortet. Production ✅ für die Diagnose.
• Context Poisoning ist ein Fehler durch fehlenden Mechanismus. Theorem 3: die Eigenschaft Widerspruch-offengelegt wird garantiert durch Versions-Routing plus Widerspruchserkennung, nicht durch das Vermischen von Chunks. Der Artikel: wenn der Retriever Chunks aus widersprüchlichen Richtlinienversionen zurückgibt, „wählt das Modell eines, vermischt beide oder präsentiert eine selbstsichere Synthese" und „weder der Nutzer noch das Modell weiß es." Production ✅ für die Diagnose.
• Der Chunk-Größen-Konflikt ist strukturell, nicht justierbar. Recall braucht Chunks von 100–256 Token; Kohärenz braucht 1024 oder mehr. Keine Embedding-Dimension löst einen Trade-off, bei dem die beiden Eigenschaften den Parameter in entgegengesetzte Richtungen ziehen. Production ✅ für die strukturelle Aussage.
• Over-Engineering verschärft den Fehler. Der Artikel: eine 72 %-Ausfallrate im ersten Jahr für Enterprise-RAG 2025, eine Budgetüberschreitung von 400.000 auf 1,2 Millionen USD, 23 % Genauigkeit, 75.000 USD pro Monat an Vektordatenbank-Kosten im sechsten Monat bei einem Healthcare-Unternehmen. Komplexität zu einem kaputten Retrieval-Design hinzuzufügen, „erhöht die Compute-Kosten und verzögert die nützlichere Frage, nämlich ob die Retrieval-Architektur überhaupt die richtige war." Partial ⚠️ (Zahlen aus Umfragen zitiert, nicht unabhängig von Everythink verifiziert).
• Routing geht der Retrieval voraus. Self-Route (EMNLP 2024) klassifiziert, ob eine Anfrage vollen Kontext oder fokussierte Retrieval braucht, bevor die Retrieval läuft; 15 bis 30 % Genauigkeitssteigerungen für hybride Suche und Reranking berichtet. Theorem 3: die Eigenschaft richtige-Strategie-pro-Anfrage wird garantiert durch Klassifizieren-vor-dem-Retrieve, nicht durch das Festlegen auf eine Strategie beim Bau. Production ✅ für die Form; Partial ⚠️ für die spezifischen Prozentzahlen.
• „The space is the router" ist der vorgelagerte Routing-Mechanismus, der RAG fehlt. Everythinks network→community→room-Topologie routet eine Frage an den richtigen Kontext, bevor irgendetwas antwortet — dieselbe Form wie Self-Route, eine Domäne vorgelagert. Partial ⚠️ (dieselbe Form — routen-vor-dem-Antworten — getrennte Domänen).
• Umfang: zivil/defensiv. Retrieval-Architektur ist zivile Infrastruktur. Kein Token-, Wallet- oder Community-Credit-Ergebnis wird versprochen; diese sind Roadmap 🔵, Howey-Prüfung ausstehend. Everythink ist eine Prognoseplattform, kein RAG-Anbieter; die domänenübergreifenden Parallelen sind Partial ⚠️-Illustrationen, keine Befürwortungen von KDnuggets, StrataScratch, Microsoft GraphRAG oder irgendeinem spezifischen Werkzeug.

Wenn RAG scheitert: die Eigenschaft ist nicht garantiert

Der Artikel öffnet mit dem Fehler, den Demos verbergen. Ein Nutzer fragt nach Elternzeit. Der Retriever liefert die Version von 2022, die von 2024 und einen Kultur-Blogbeitrag. Jeder Chunk punktet hoch in der Embedding-Distanz, weil er Vokabular mit der Anfrage teilt. Keiner beantwortet die Frage. Das Modell weiß nicht, dass der abgerufene Inhalt veraltet oder themenfremd ist; es vermischt die Chunks zu einer selbstsicheren, detaillierten, faktisch falschen Antwort. Der Artikel nennt dies „topische Ähnlichkeit ohne faktische Relevanz, und das ist die vorherrschende Fehlerart in Produktionssystemen."

Der Honest Architect liest dies als Theorem 3. Die Eigenschaft ist faktische-Relevanz. Der Mechanismus, den das System implementiert, ist Vektorähnlichkeit, welche die-Antwort-ähnelt-der-Frage garantiert, nicht faktische-Relevanz. Die beiden fallen zusammen, wenn der Corpus klein, aktuell und einversionig ist — der Demo-Fall. Sie weichen ab, wenn der Corpus mehrere Versionen, themenfremde Vokabulartreffer und Widersprüche enthält. Das System behauptet Relevanz, indem es ähnliche Chunks abruft; der Mechanismus implementiert keine Relevanz, also ist die Eigenschaft nicht garantiert. Production ✅ für die Diagnose.

Der subtilere Fehler, Context Poisoning, hat dieselbe Form. Enterprise-Wissensbasen halten dieselbe Richtlinie in mehreren Versionen. Der Retriever gibt Chunks aus beiden zurück. Das Modell „deckt den Widerspruch nicht auf. Es wählt eines, vermischt beide oder präsentiert eine selbstsichere Synthese. Der Leser erhält eine Antwort. Die Antwort kann falsch sein. Weder der Nutzer noch das Modell weiß es." Die Eigenschaft ist Widerspruch-offengelegt. Der Mechanismus ist vermischen-und-synthetisieren. Kein Mechanismus deckt den Widerspruch auf, also ist die Eigenschaft nicht garantiert. Das System erzeugt eine Antwort; es erzeugt keine als korrekt bekannte Antwort. Production ✅.

[PERSONAL EXPERIENCE]: Beim Bau des HAI Engine seit 2016 haben wir dieselbe Lektion in einer anderen Domäne gelernt. Eine Prognose wird nicht relevant, indem man sie über mehr Daten berechnet; sie wird relevant, indem man die Frage an den richtigen Raum routet — die richtige Community, den richtigen abgegrenzten Kontext — bevor irgendein Modell läuft. Das Modell über den falschen Kontext zu skalieren, erzeugt eine selbstsichere, detaillierte, am Ziel vorbeigehende Prognose, so wie Embeddings über die falschen Chunks zu skalieren eine selbstsichere, detaillierte, am Ziel vorbeigehende Antwort erzeugt. Der Mechanismus, der Relevanz erzeugt, ist Routing, nicht Volumen. Production ✅.

Die Over-Engineering-Falle ist Theorem 3 im Miniaturformat

Der nützlichste Abschnitt des Artikels ist der, den Ingenieure überspringen. Wenn Standard-RAG unterperformt, lautet die übliche Korrektur, ihn komplizierter zu machen: höherdimensionale Embeddings, anspruchsvolleres Reranking, mehrstufige Retrieval. Das Urteil des Artikels: „Das verschärft das Problem."

Die Daten sind schonungslos. Ein globaler Industriekonzern veranschlagte 400.000 USD, gab im ersten Jahr 1,2 Millionen aus, landete bei 23 % Genauigkeit und stellte das Projekt ein. Ein Healthcare-Unternehmen erreichte im sechsten Monat 75.000 USD pro Monat an Vektordatenbank-Kosten. Der Artikel zitiert eine 72 %-Ausfallrate im ersten Jahr für Enterprise-RAG-Implementierungen 2025. Der Honest Architect liest dies als die Kosten, den falschen Mechanismus zu skalieren. Höherdimensionale Embeddings implementieren feinkörnigere Ähnlichkeit, nicht faktische-Relevanz. Reranking implementiert Neuordnung, nicht Widerspruch-offengelegt. Mehrstufige Retrieval implementiert abrufen-dann-nochmal-abrufen, nicht routen-vor-dem-Abruf. Jedes fügt einem Design, dem der fehlende Mechanismus immer noch fehlt, Compute hinzu, also bleibt die Eigenschaft ungarantiert, während die Rechnung wächst. Partial ⚠️ bei den Zahlen (aus Umfragen zitiert, nicht unabhängig von Everythink verifiziert); Production ✅ bei der Form — einen Mechanismus zu skalieren, der die Eigenschaft nicht implementiert, kann die Eigenschaft nicht erzeugen.

Dies ist Theorem 3 im Miniaturformat. Eine Eigenschaft ist genau dann garantiert, wenn ihr Mechanismus implementiert ist und misst. Relevanz ist die Eigenschaft. Routing vor der Retrieval ist der Mechanismus. Die Embedding-Dimension ist ein anderer Mechanismus, der eine andere Eigenschaft misst. Man kann sich Relevanz nicht mit Embedding-Dimensionen erkaufen, so wenig wie man sich Feuerbeständigkeit mit Farbschichtdicke erkaufen kann. Der Satz des Artikels — „erhöht die Compute-Kosten und verzögert die nützlichere Frage, nämlich ob die Retrieval-Architektur überhaupt die richtige war" — ist die operationale Version des Theorems. Production ✅.

Der Artikel benennt auch einen strukturellen Konflikt, den kein Tuning auflöst: Recall braucht kleine Chunks (100–256 Token), Kohärenz braucht große (1024 oder mehr), und jeder RAG-Designer wählt einen und akzeptiert den Trade-off. Der Honest Architect liest dies als die Grenze des Chunk-Embed-Retrieve-Mechanismus — kein Tuning-Problem, sondern ein Mechanismus-Auswahl-Problem. Die vier Alternativen sind keine Flicken auf diesem Konflikt; sie sind unterschiedliche Mechanismen, die jeweils eine unterschiedliche Eigenschaft für einen unterschiedlichen Anfragetyp garantieren. Production ✅ für die Rahmung; die Werkzeugnamen (Self-Route, GraphRAG) sind Partial ⚠️ (forschungsseitig berichtet, nicht unabhängig von Everythink verifiziert).

Die vier Alternativen sind Routing nach Situation

Long-Context: Retrieval überspringen, wenn der Corpus passt

Die erste Alternative des Artikels ist, die Retrieval ganz zu überspringen. Wenn der Corpus in das Kontextfenster des Modells passt, lade ihn und lass das Modell lesen. Ein Benchmark (arXiv 2501.01880) fand, dass Long-Context-LLMs bei QA-Aufgaben konsistent RAG übertrafen, wenn Compute verfügbar war, wobei chunk-basierte Retrieval am meisten zurückblieb. Der Kosten-Trade-off ist real: bei 1M Token läuft die Latenz 30- bis 60-mal langsamer als eine RAG-Pipeline, bei etwa 1250-mal den Kosten pro Anfrage; Prompt-Caching kann Long-Context für hochfrequentierte Anwendungen kosteneffizient machen. Die Entscheidungsregel: wenn der Corpus ins Fenster passt und das Anfragevolumen moderat ist, ist Long-Context der sauberere Startpunkt; füge Retrieval erst hinzu, wenn der Corpus das Fenster überschreitet, die Latenz SLOs verletzt oder das Volumen den Break-Even überschreitet. Theorem 3: die Eigenschaft Antwort-aus-vollem-Kontext wird garantiert, indem man den ganzen Corpus lädt, nicht indem man Chunks davon abruft. Die Routing-Entscheidung (passt dieser Corpus?) geht der Architekturwahl voraus. Production ✅ für die Form; Partial ⚠️ für die Kostenmultiplikatoren.

Speicherkompression: vor dem Abruf zusammenfassen

Wenn der Corpus zu groß für das Fenster ist, ist die zweite Alternative des Artikels, vor dem Abruf zusammenzufassen, statt rohe Chunks zu ziehen. Zusammenfassungsbasierte Retrieval performt vergleichbar mit vollen Long-Context-Methoden, während chunk-basierte Retrieval hinter beiden zurückbleibt. Ein konkretes Ergebnis: ein reihenfolgeerhaltender RAG-Ansatz mit 48K gut gewählten Token übertraf Full-Context-Retrieval bei 117K Token um 13 F1-Punkte, bei einem Siebtel des Token-Budgets. Theorem 3: die Eigenschaft relevanter-Kontext-im-Budget wird garantiert durch Komprimieren auf Relevanz vor der Injektion, nicht durch Abrufen roher Chunks in der Hoffnung, das Modell filtert. Ein gut komprimiertes relevantes Dokument schlägt einen rohen Dump tangential verwandter Chunks. Production ✅ für die Form; Partial ⚠️ für die 13-F1-Punkte-Zahl (einzelne Studie).

Strukturierte Retrieval: die Anfrage klassifizieren, bevor die Retrieval läuft

Die dritte Alternative des Artikels bildet den fehlenden Mechanismus am direktesten ab. Wenn Retrieval die richtige Architektur ist, besteht die Lösung darin, nach Anfragetyp zu routen, statt bessere Embeddings gleichmäßig anzuwenden. Self-Route, vorgestellt auf EMNLP 2024, lässt das Modell klassifizieren, ob eine Anfrage vollen Kontext oder fokussierte Retrieval braucht, bevor es sie ausführt. Einfache faktische Nachschläge gehen an fokussierten RAG. Komplexe Multi-Hop-Fragen gehen an einen Long-Context. Das Ergebnis: bessere Gesamtlagegenauigkeit bei geringeren Rechenkosten. Adaptive Systeme mit diesem hybriden Ansatz haben 15 bis 30 % Retrieval-Genauigkeitssteigerungen durch hybride Suche und Reranking gezeigt. Der tragende Satz des Artikels: „Die entscheidende Änderung besteht darin, das Routing explizit zu machen. Jede Anfrage wird klassifiziert, bevor irgendeine Retrieval läuft, und das System aufhört, alle Anfragen als identische Embedding-Probleme zu behandeln."

Theorem 3: die Eigenschaft richtige-Strategie-pro-Anfrage wird garantiert durch den Mechanismus (die Anfrage klassifizieren, dann abrufen), nicht durch das Festlegen auf eine Strategie beim Bau. Die Klassifikation ist die Messung; das Routing ist der Mechanismus. Das System, das vor dem Abruf klassifiziert, implementiert die Eigenschaft; dasjenige, das abruft-und-dann-hofft, nicht. Production ✅ für die Form; Partial ⚠️ für die spezifischen Prozentzahlen.

[ORIGINAL DATA]: Der Honest Architect notiert die strukturelle Parallele zwischen Self-Routes Klassifizieren-vor-dem-Retrieve und Everythinks „the space is the router". Self-Route klassifiziert die Anfrage und routet dann zu einer Retrieval-Strategie. Everythink routet die Frage an einen Raum — network→community→room — bevor irgendein Modell läuft. Beide implementieren die Eigenschaft Relevanz durch Routing vor dem Antworten, nicht durch Broadcast und Filterung. Der Unterschied ist Domäne und Reichweite: Self-Route routet innerhalb eines Retrieval-Systems; „the space is the router" routet über ein ganzes Netzwerk abgegrenzter Kontexte. Partial ⚠️ (dieselbe Form — routen-vor-dem-Antworten — getrennte Domänen).

Graph-basiert: relationale Anfragen an einen Graphen routen

Die vierte Alternative des Artikels ist für Anfragen, die das Verstehen von Beziehungen über einen Datensatz erfordern, statt einen Abschnitt abzurufen. Das sind die Multi-Hop-Fragen: welche Entscheidungen hat der Vorstand im Q3 revidiert, und was war jeweils die genannte Begründung? Kein einzelner Chunk beantwortet dies; die Antwort lebt in den Verbindungen zwischen Dokumenten. Microsoft Research führte 2024 GraphRAG ein: baue einen Knowledge Graph aus dem Corpus, durchlaufe Entitätsbeziehungen statt Vektoren abzugleichen. Der Trade-off sind Kosten — Knowledge-Graph-Extraction läuft 3- bis 5-mal teurer als Baseline-RAG und erfordert domänenspezifisches Tuning — lohnt sich für thematische Analyse und Multi-Hop-Reasoning, nicht für Einzelpassus-Nachschläge. Theorem 3: die Eigenschaft beziehungen-über-Dokumente wird garantiert durch Entitäten plus typisierte Beziehungen, durchlaufen, nicht durch Vektorähnlichkeit. Production ✅ für die Form; Partial ⚠️ für die Kostenmultiplikatoren. Eine tiefere Behandlung der Mechanismus-Formen von GraphRAG findet sich in unserem früheren Text über die Abstimmung des Mechanismus auf den Anfragetyp.

The space is the router — der Mechanismus, der RAG fehlt

Die vier Alternativen konvergieren auf einen Mechanismus: routen, bevor du abrufst. Long-Context routet nach Corpus-Größe. Speicherkompression routet nach Budget. Strukturierte Retrieval routet nach Anfragetyp. Graph-basiert routet nach relationaler Struktur. Jedes ist eine Routing-Entscheidung, die getroffen wird, bevor der Retrieval-Mechanismus läuft, und jedes garantiert seine Eigenschaft, weil das Routing zur tatsächlichen Form der Anfrage passt.

Everythinks „the space is the router" ist derselbe Mechanismus, eine Domäne vorgelagert. Die network→community→room-Topologie routet eine Frage an den richtigen abgegrenzten Kontext, bevor irgendetwas antwortet. Eine Frage, die in einem Raum über die Retry-Logik der Zahlungen gestellt wird, ist bereits zur Payments-Community, zum Engineering-Netzwerk, zum relevanten Dokumentumfang geroutet — bevor irgendeine Sister entwirft, bevor der Oracle fusioniert, bevor irgendeine Retrieval läuft. Das Routing ist strukturell, nicht zur Abfragezeit berechnet. Die Eigenschaft Relevanz wird durch die Topologie garantiert, nicht durch das Broadcasten der Frage über das ganze Netzwerk und Filtern der Antworten. Production ✅ für die Form (der HAI Engine betreibt dieses Routing in Produktion seit 2016); Partial ⚠️ für die domänenübergreifende Behauptung.

Der Honest Architect behauptet nicht, „the space is the router" sei ein Retrieval-System. Everythink ist eine Prognoseplattform, kein RAG-Anbieter. Die Behauptung ist strukturell: der fehlende Mechanismus in gescheiterten RAG-Pipelines ist explizites Routing vor der Retrieval, und dieser Mechanismus hat ein in Produktion bewährtes Analogon in Everythinks Topologie. Die Sisters-to-Oracle-Pipeline ist das nachgelagerte Analogon zum Map-Reduce des Artikels: jede Sister entwirft parallel (die Map-Stufe), der Oracle fusioniert sie zu einem normalisierten Ensemble mit Entropie bei jedem Merge (die Reduce-Stufe), und die Eigenschaft kalibrierte-Prognose wird durch den Mechanismus garantiert, nicht durch ein Modell, das die ganze Prognose erzeugt. Partial ⚠️ (dieselbe Form — Parallelentwurf-plus-gemessener-Merge — getrennte Domänen).

Häufig gestellte Fragen

Ist RAG nutzlos, wie die Schlagzeile sagt?

Nein, und der Artikel argumentiert das nicht. Er argumentiert, RAG sei ein vernünftiger Standard, der auf vorhersehbare Weise scheitert — Retrieval-Irrelevanz, Context Poisoning, der Chunk-Größen-Konflikt — und dass die Korrektur im Routen nach Anfragetyp liegt, nicht im Over-Engineering der Embeddings. Der Mechanismus muss zur Eigenschaft passen. Production ✅ für die Diagnose; die „nutzlos"-Rahmung ist redaktionell.

Warum behebt das Hinzufügen von Embedding-Dimensionen die Retrieval-Irrelevanz nicht?

Weil Embedding-Dimensionen Ähnlichkeit implementieren, nicht Relevanz. Retrieval-Irrelevanz ist ein Fehler durch fehlendes Routing: die Anfrage liefert Vokabulartreffer, die die Frage nicht beantworten. Den falschen Mechanismus zu skalieren, häuft die Kosten an, ohne die Eigenschaft zu erzeugen. Theorem 3: faktische-Relevanz wird durch Routing vor der Retrieval garantiert, nicht durch feinkörnigere Ähnlichkeit. Production ✅.

Welches ist der Routing-Mechanismus, der RAG fehlt?

Explizite Klassifikation vor der Retrieval. Self-Route klassifiziert, ob eine Anfrage vollen Kontext oder fokussierte Retrieval braucht, bevor irgendeine Retrieval läuft. Die Eigenschaft richtige-Strategie-pro-Anfrage wird durch Klassifizieren-dann-Abrufen garantiert, nicht durch das Festlegen auf eine Strategie beim Bau. Production ✅ für die Form.

Wie hängt „the space is the router" zusammen?

Es ist dieselbe Form, eine Domäne vorgelagert. Everythinks network→community→room-Topologie routet eine Frage an den richtigen abgegrenzten Kontext, bevor irgendein Modell läuft, so wie Self-Route eine Anfrage an die richtige Retrieval-Strategie routet, bevor die Retrieval läuft. Beide implementieren Relevanz durch Routing vor dem Antworten. Partial ⚠️ (dieselbe Form — routen-vor-dem-Antworten — getrennte Domänen). Everythink ist eine Prognoseplattform, kein RAG-Anbieter.

Befürwortet Everythink GraphRAG oder irgendein Retrieval-Werkzeug?

Nein. Everythink ist eine Prognoseplattform. Die Zahlen des Artikels sind Partial ⚠️. Die domänenübergreifenden Parallelen sind Illustrationen, keine Befürwortungen. Der Umfang ist zivil/defensiv. Kein Token-, Wallet- oder Community-Credit-Ergebnis wird versprochen; diese sind Roadmap 🔵, Howey-Prüfung ausstehend.

Sources

• Nate Rosidi, KDnuggets, „Your RAG Pipeline Is Probably Useless. Here's a Better Alternative", veröffentlicht 2026-06-29, abgerufen 2026-08-23, https://www.kdnuggets.com/your-rag-pipeline-is-probably-useless-heres-a-better-alternative

Wenn Ihr Team bereit ist, zu routen, bevor es abruft — die Anfrage zu klassifizieren, bevor irgendein Embedding läuft, so wie the space is the router die Frage klassifiziert, bevor irgendeine Sister entwirft — lest the 21 papers oder bucht eine Demo. Der HAI Engine betreibt diesen Routing-Mechanismus in Produktion seit 2016; die Sisters entwerfen parallel, der Oracle fusioniert mit Entropie bei jedem Lauf, und Theorem 3 gilt: die Eigenschaft ist genau dann garantiert, wenn ihr Mechanismus implementiert ist und misst.