RAG: Retrieval Augmented Generation — die technische Referenz

Warum RAG existiert: drei Probleme, eine Architektur

Ein Sprachmodell ist ein statisches Artefakt. Sein Wissen stammt aus Trainingsdaten mit einem festen Stichtag, und interne Unternehmensdaten waren nie Teil dieses Trainings. Fragt jemand nach der aktuell gültigen Reisekostenrichtlinie, hat das Modell zwei Möglichkeiten: zugeben, dass es die Antwort nicht kennt, oder eine plausibel klingende Richtlinie formulieren. Ohne zusätzliche Architektur kommt es vor, dass Modelle sich für Letzteres entscheiden — wie häufig, hängt stark vom Modell und von der Systemanweisung ab.

Das zweite Problem ist das Kontextfenster. Moderne Modelle verarbeiten sehr lange Eingaben, aber ein Unternehmenswissensbestand aus Tausenden Dokumenten passt in kein Kontextfenster — und selbst wo er hineinpasst, muss jeder Aufruf den gesamten Kontext verarbeiten; Prompt-Caching senkt die Kosten für gleichbleibende Präfixe, hebt sie aber nicht auf. Hinzu kommt ein Effekt, den Liu et al. 2023 unter dem Namen "Lost in the Middle" beschrieben haben: Modelle nutzten in diesen Experimenten Informationen am Anfang und Ende eines langen Kontexts zuverlässiger als Informationen in der Mitte. Ob neuere Modelle dieses Verhalten verbessert haben, ist nicht abschließend geklärt. Mehr Kontext ist jedenfalls nicht automatisch besserer Kontext.

Das dritte Problem ist Nachvollziehbarkeit. Eine Antwort ohne Beleg ist in einem Unternehmenskontext oft wertlos, weil niemand sie verantworten kann. RAG verlagert die Wahrheitsquelle vom Modellgewicht in ein durchsuchbares Dokumentenkorpus und macht damit prüfbar, worauf eine Aussage beruht.

Wichtig ist die realistische Erwartung: RAG beseitigt Halluzinationen nicht. Es reduziert sie, indem das Modell die Antwort aus mitgeliefertem Material ableiten soll statt aus Erinnerung — und es macht Fehler erkennbar, weil die zitierte Quelle nachlesbar ist. Ein RAG-System, das den falschen Kontext liefert, produziert dagegen besonders überzeugende Falschaussagen.

Die RAG-Pipeline Schritt für Schritt

Eine produktive RAG-Pipeline zerfällt in zwei Phasen: eine Offline-Phase, in der Dokumente aufbereitet und indexiert werden, und eine Online-Phase, die bei jeder Anfrage durchlaufen wird. Beide Phasen lassen sich unabhängig voneinander optimieren, und genau diese Trennung hilft bei der Fehlersuche.

Offline — Ingestion: Dokumente werden aus Quellsystemen geholt (Dateiablage, Wiki, Ticketsystem, DMS, Datenbank), in Text konvertiert und normalisiert. Hier entstehen die ersten stillen Fehler: PDF-Parser, die Tabellen in unlesbare Zeichenfolgen verwandeln, Kopf- und Fußzeilen, die in jedem Chunk mitlaufen, oder gescannte Dokumente ohne OCR. Parallel werden Metadaten erfasst — Quelle, Titel, Abteilung, Gültigkeitsdatum, Berechtigungen, Version.

Offline — Chunking und Embedding: Der Text wird in Abschnitte zerlegt und jeder Abschnitt durch ein Embedding-Modell in einen Vektor übersetzt — eine Zahlenfolge mit typischerweise mehreren hundert bis wenigen tausend Dimensionen, die die Bedeutung des Textes kodiert. Ähnliche Bedeutung ergibt ähnliche Vektoren, gemessen meist über Kosinus-Ähnlichkeit. Vektor, Originaltext und Metadaten wandern gemeinsam in den Index.

Online — Retrieval und Re-Ranking: Die Nutzerfrage wird mit demselben Embedding-Modell vektorisiert; der Index liefert die ähnlichsten k Kandidaten, üblicherweise über einen Näherungsalgorithmus wie HNSW. Weil dieser erste Durchgang auf Geschwindigkeit optimiert ist, folgt in guten Systemen ein Re-Ranking: Ein Cross-Encoder bewertet jedes Kandidatenpaar aus Frage und Textabschnitt gemeinsam und sortiert neu. Das ist deutlich rechenintensiver, aber nur für wenige Kandidaten nötig — und es ist häufig der Schritt mit dem besten Verhältnis von Aufwand zu Qualitätsgewinn.

Online — Prompt-Konstruktion und Generierung: Die verbleibenden Abschnitte werden mit Quellenkennzeichnung in den Prompt eingesetzt, zusammen mit der Anweisung, ausschließlich aus diesem Material zu antworten und fehlende Information explizit zu benennen. Das Modell generiert die Antwort und referenziert die verwendeten Abschnitte. Ob diese Zitate stimmen, ist ein eigener Prüfschritt — Modelle können Belege auch falsch zuordnen.

• Ingestion: Quellsysteme anbinden, Text extrahieren, Metadaten und Berechtigungen mitführen
• Chunking: Dokumente in sinnvolle Abschnitte zerlegen, Struktur erhalten
• Embedding: Abschnitte in Vektoren übersetzen, konsistent mit dem Query-Modell
• Indexierung: Vektoren, Volltext und Metadaten gemeinsam speichern
• Query-Verarbeitung: Frage klären, ggf. umformulieren oder in Teilfragen zerlegen
• Retrieval: Kandidaten holen, Berechtigungsfilter direkt in der Suche anwenden
• Re-Ranking: Kandidaten mit Cross-Encoder neu bewerten und kürzen
• Generierung: Antwort mit Quellenangabe, Verweigerung bei fehlendem Beleg

RAG vs. Fine-Tuning vs. langes Kontextfenster vs. Tool-Aufrufe

Diese vier Ansätze werden oft als Konkurrenten diskutiert, lösen aber unterschiedliche Probleme. RAG bringt Wissen ins Modell. Fine-Tuning bringt Verhalten ins Modell — Tonalität, Format, Fachsprache, Aufgabenmuster. Ein langes Kontextfenster ersetzt Retrieval nur bei kleinen, klar abgegrenzten Beständen. Tool- und Funktionsaufrufe holen strukturierte, exakte Daten aus Systemen, in denen Ähnlichkeitssuche schlicht das falsche Werkzeug ist.

Die praktisch wichtigste Abgrenzung ist die zwischen RAG und Fine-Tuning, und sie lässt sich auf eine Frage reduzieren: Ändert sich die Information? Preise, Richtlinien, Projektstände, Ticketverläufe ändern sich — die gehören in ein Retrieval-System, weil ein Update dort das Neuschreiben eines Dokuments bedeutet und nicht einen Trainingslauf. Wie das Unternehmen formuliert, welche Struktur ein Angebot hat, welche Begriffe intern gelten: Das ändert sich selten und lässt sich per Fine-Tuning oder oft schon per Systemprompt festlegen.

Die zweite wichtige Abgrenzung betrifft exakte Daten. Für die Frage nach dem offenen Rechnungsbetrag eines Kunden ist Vektorsuche das falsche Verfahren — hier braucht es einen Funktionsaufruf gegen die Fachanwendung. Produktive Systeme kombinieren beides: unstrukturiertes Wissen per RAG, strukturierte Fakten per Tool-Aufruf. Genau diese Kombination beschreibt der Bauplan für KI-Agenten, und mit dem Model Context Protocol lässt sich der Retrieval-Schritt selbst als Tool bereitstellen, das mehrere Anwendungen nutzen können.

Chunking: die häufigste Fehlerursache in RAG-Systemen

Chunking entscheidet, welche Informationseinheit überhaupt gefunden werden kann. Zerschneidet die Pipeline einen Text mitten in einer Tabelle, an einer Aufzählung oder zwischen Bedingung und Rechtsfolge, dann existiert die vollständige Aussage im Index nicht mehr — kein Retrieval-Verfahren und kein Sprachmodell kann das reparieren. Genau deshalb ist Chunking in meiner Erfahrung die Stelle, an der sich RAG-Qualität am schnellsten verbessern lässt.

Zu große Abschnitte verwässern das Embedding: Ein Vektor, der viele verschiedene Themen gleichzeitig repräsentieren soll, liegt zu keinem davon besonders nah. Zu kleine Abschnitte verlieren Kontext — der Satz "Diese Frist beträgt 14 Tage" ist ohne den vorangehenden Absatz nicht verwertbar. Zwischen diesen beiden Fehlern liegt kein universeller Optimalwert, sondern eine Abhängigkeit vom Dokumenttyp: Ein Handbuch, ein Vertrag und ein Chatprotokoll brauchen verschiedene Strategien.

Zwei Techniken lösen viele Probleme unabhängig von der gewählten Größe. Erstens die Trennung von Suchtreffer und Antwortkontext: Gesucht wird auf kleinen, präzisen Abschnitten, an das Modell übergeben wird der umgebende größere Abschnitt oder das Elterndokument. Zweitens die kontextuelle Anreicherung: Vor dem Embedding bekommt jeder Abschnitt eine kurze, automatisch erzeugte Einordnung vorangestellt — welches Dokument, welches Kapitel, worum es geht. Das behebt genau den Fall, in dem ein Abschnitt sprachlich isoliert nicht mehr verständlich ist.

Praktisch bewährt hat sich, Chunking an der Dokumentstruktur auszurichten statt an Zeichenzahlen: Überschriftenebenen, Listen, Tabellen und Absätze als primäre Grenzen, Zeichenlimits nur als Obergrenze. Tabellen sollten möglichst am Stück bleiben und ihre Kopfzeile behalten, weil sie sonst als reine Zahlenkolonne im Index landen.

Embedding-Modelle — und was bei deutschsprachigen Inhalten zu beachten ist

Ein Embedding-Modell bildet Text auf einen Vektor ab, dessen Lage im Raum die Bedeutung kodiert. Für RAG zählen vier Eigenschaften: die unterstützten Sprachen, die maximale Eingabelänge, die Dimensionalität (mehr Dimensionen bedeuten vor allem mehr Speicherbedarf; innerhalb einer Modellfamilie oft etwas bessere Qualität, modellübergreifend ist die Dimensionszahl aber kein Qualitätsmaß) und die Frage, ob das Modell selbst gehostet werden kann. Der letzte Punkt ist in regulierten Umgebungen oft der entscheidende, weil beim Embedding der vollständige Dokumenttext an den Anbieter geht — nicht nur die Nutzerfrage.

Für deutschsprachige Inhalte gilt: Ein rein englisch trainiertes Modell funktioniert oberflächlich, verliert aber genau dort Trennschärfe, wo es darauf ankommt. Deutsche Komposita sind das bekannteste Problem — "Betriebsvereinbarung", "Rückstellungsbewertung", "Instandhaltungsintervall" zerfallen bei der Tokenisierung in Fragmente, die im Englischen nichts bedeuten. Hinzu kommen Flexion, Trennbarkeit von Verben und Fachsprache aus Verwaltung, Recht und Technik. Wählt daher ein explizit mehrsprachiges oder deutschsprachig evaluiertes Modell; das MTEB-Benchmark enthält deutschsprachige Aufgaben und ist ein brauchbarer Startpunkt für den Vergleich.

Ein Detail geht dabei leicht unter: Deutsche Texte erzeugen bei gängigen Tokenizern in der Regel mehr Tokens als der entsprechende englische Text. Wie groß der Aufschlag ausfällt, hängt vom Tokenizer ab und sollte am eigenen Korpus gemessen werden. Betroffen sind Embedding-Kosten, effektive Chunk-Größen und der Platzbedarf im Kontextfenster gleichermaßen — wer Chunk-Grenzen aus englischsprachiger Dokumentation übernimmt, arbeitet real mit kürzeren Inhalten. Zum Umgang mit Tokenverbrauch gibt es einen eigenen Praxisartikel zum Tokensparen.

Zwei harte Regeln zum Schluss. Erstens: Query und Dokument müssen mit demselben Modell und derselben Version eingebettet werden — ein Modellwechsel erfordert die vollständige Neuindexierung des Bestands. Zweitens: Manche Modelle erwarten unterschiedliche Präfixe für Suchanfrage und Dokument; wer das ignoriert, verliert Qualität, ohne dass ein Fehler sichtbar wird. Wer Embeddings lokal erzeugen will, findet die Grundlagen im Artikel zum lokalen Betrieb von Sprachmodellen.

Vektordatenbanken, Volltextsuche und warum Hybrid meist gewinnt

Eine Vektordatenbank speichert Embeddings und beantwortet Ähnlichkeitsanfragen näherungsweise (Approximate Nearest Neighbour), typischerweise über einen HNSW-Graphindex oder ein clusterbasiertes Verfahren. Der Unterschied zwischen den Produkten liegt selten in der reinen Suchqualität, sondern in Betriebsfragen: Filterung nach Metadaten während der Suche, Konsistenz bei Updates, Mandantentrennung, Speicherbedarf und Betriebsmodell.

Für viele Unternehmen ist die pragmatischste Wahl kein neues Spezialsystem, sondern eine Erweiterung des vorhandenen: Postgres mit pgvector, wenn ohnehin Postgres läuft, oder eine Suchmaschine wie OpenSearch beziehungsweise Elasticsearch, die Volltext- und Vektorsuche gemeinsam abdeckt. Ein zusätzlicher Datenspeicher bedeutet zusätzliche Backups, Berechtigungen und Ausfallpfade — dieser Aufwand sollte durch einen konkreten Bedarf begründet sein, nicht durch die Erwartung, dass RAG eine Vektordatenbank voraussetzt.

Der meistunterschätzte Punkt: Klassische Volltextsuche ist nicht überholt. BM25 findet exakte Begriffe zuverlässig — Artikelnummern, Fehlercodes, Paragraphen, Eigennamen, Abkürzungen. Voraussetzung ist eine passende Tokenisierung im Index: Zerlegt der Analyzer eine Artikelnummer, geht der Vorteil verloren. Genau dort versagt Vektorsuche regelmäßig, weil "Fehler E-4711" und "Fehler E-4712" semantisch nahezu identisch sind. Umgekehrt findet die Vektorsuche Umschreibungen, die kein Wort mit der Frage teilen.

Hybrid-Suche kombiniert beides und führt die zwei Trefferlisten zusammen, meist über Reciprocal Rank Fusion — ein Verfahren, das nur Rangpositionen verrechnet und deshalb ohne Kalibrierung unterschiedlicher Score-Skalen auskommt. In Kombination mit einem Re-Ranking-Schritt ist das für die meisten Unternehmensbestände die robusteste Ausgangskonfiguration. Wie sich das in eine Gesamtarchitektur einfügt, beschreibt die Übersicht zur KI-Infrastruktur.

Evaluation: woran man merkt, dass ein RAG-System schlecht ist

Der teuerste Fehler im RAG-Betrieb ist, Qualität nach Gefühl zu beurteilen. Ohne Messung lässt sich die zentrale Frage nicht beantworten: Lag die falsche Antwort daran, dass die richtige Passage nie gefunden wurde, oder daran, dass sie im Kontext stand und das Modell sie ignoriert hat? Beide Fälle sehen für Nutzende identisch aus und erfordern völlig unterschiedliche Gegenmaßnahmen.

Die Grundlage ist ein Evaluationsdatensatz: reale Fragen aus dem Fachbereich, dazu die Dokumentstellen, die die Antwort tatsächlich enthalten. Ein solcher Satz muss nicht groß sein, aber er muss echt sein — selbst ausgedachte Fragen treffen tendenziell genau die Formulierungen, die das System ohnehin beherrscht. Mit diesem Datensatz wird zuerst das Retrieval isoliert gemessen: Wie oft ist die richtige Stelle unter den ersten k Treffern (Recall@k), und auf welcher Position steht sie (MRR, nDCG)? Diese Zahlen sind die Obergrenze der Antwortqualität — was das Retrieval nicht liefert, kann kein Modell ausgleichen.

Erst danach wird die Generierung bewertet, entlang von drei Dimensionen: Ist jede Aussage durch den mitgelieferten Kontext gedeckt (Groundedness), beantwortet die Antwort die gestellte Frage (Relevanz), und verweigert das System zuverlässig, wenn keine Grundlage existiert? Der letzte Punkt ist im Unternehmenseinsatz der wichtigste und wird am seltensten getestet: Der Evaluationssatz braucht Fragen, auf die es bewusst keine Antwort im Bestand gibt.

Im laufenden Betrieb sind drei Signale aussagekräftig: Anfragen, bei denen das System verweigert, obwohl die Information existiert; Antworten, deren Zitate von Nutzenden aufgerufen und dann als unpassend markiert werden; und Suchanfragen ohne verwertbaren Treffer. Jede Änderung an Chunking, Embedding-Modell oder Prompt sollte gegen denselben Datensatz laufen, bevor sie produktiv geht — sonst ist jede Optimierung ein Tausch von einem Fehler gegen einen anderen.

• Retrieval getrennt von Generierung messen — sonst optimiert man an der falschen Stelle
• Recall@k und Rangposition als harte Kennzahlen für die Suchqualität
• Groundedness prüfen: Steht jede Aussage tatsächlich im mitgelieferten Kontext?
• Verweigerungsverhalten testen mit Fragen, die im Bestand bewusst nicht beantwortbar sind
• Regressionslauf vor jeder Änderung an Chunking, Modell oder Prompt

Typische Unternehmensarchitektur — inklusive Berechtigungsfilter

Eine belastbare RAG-Architektur im Unternehmen besteht aus fünf Schichten: den Quellsystemen, einer Ingestion-Strecke, dem Index, einem Retrieval-Dienst und der Anwendung, die das Sprachmodell aufruft. Entscheidend ist, dass der Retrieval-Dienst eine eigene, zentral betriebene Komponente ist und nicht in jeder Anwendung neu gebaut wird. Nur so lassen sich Berechtigungen, Protokollierung und Qualitätsmessung an einer Stelle durchsetzen.

Der kritischste Punkt ist die Berechtigungsprüfung, und dafür gibt es eine klare Regel: Sie gehört in die Suchanfrage, nicht in den Prompt. Ein Dokument, das im Kontext des Modells landet, gilt als offengelegt — die Anweisung "nutze dieses Dokument nur, wenn der Nutzer berechtigt ist" ist keine Zugriffskontrolle. Praktisch bedeutet das: Jeder Chunk trägt die Zugriffsmerkmale seines Quelldokuments als Metadaten, und die Suche wertet diesen Filter gemeinsam mit der Ähnlichkeitssuche aus, statt die Trefferliste erst nachträglich zu bereinigen (gefilterte Suche, oft als Pre-Filtering bezeichnet). Wie das intern umgesetzt ist, unterscheidet sich je nach System — sehr selektive Filter können in ANN-Indizes Recall und Latenz beeinflussen und gehören deshalb in die Lasttests. Wird stattdessen erst gesucht und danach gefiltert, schrumpft die Trefferliste unkontrolliert — Nutzende bekommen dann zwar keine unberechtigten Dokumente, aber auch zu wenige berechtigte.

Zwei Folgeprobleme sind in der Praxis unterschätzt. Erstens veralten Berechtigungen: Wird ein Dokument im Quellsystem umgestuft oder ein Mitarbeiter aus einer Gruppe entfernt, muss der Index das zeitnah nachvollziehen — sonst antwortet das System aus Rechten, die es nicht mehr gibt. Zweitens sind Löschungen bindend: Ein im Quellsystem gelöschtes Dokument muss aus Chunks, Vektoren und etwaigen Caches verschwinden. Beide Punkte sind organisatorisch und gehören in die KI-Governance, nicht in ein Ticket am Ende des Projekts.

Dazu kommt Protokollierung: Wer hat wann welche Frage gestellt, welche Dokumente wurden geliefert, welche Antwort erzeugt? Das ist keine Bürokratie, sondern die Voraussetzung, um Fehlverhalten zu rekonstruieren und Auskunftsersuchen überhaupt beantworten zu können. Welche Protokollierungs- und Auskunftspflichten im Einzelfall greifen, klärt ihr mit Rechtsabteilung oder Datenschutzbeauftragten. Wie sich ein RAG-System in eine breitere Wissensstrategie einordnet, beschreibt die Seite zum KI-Wissensmanagement; die organisatorische Gesamtsicht liefert Unternehmens-KI.

Betrieb: Aktualisierung, Latenz und Kostentreiber

Ein RAG-System ist kein Projekt mit Enddatum, sondern eine Datenstrecke, die laufend gepflegt wird. Die zentrale Betriebsfrage lautet: Wie kommen Änderungen aus den Quellsystemen in den Index? Vollständige Neuindexierung ist einfach, aber teuer und langsam; inkrementelle Aktualisierung über Änderungszeitstempel oder Webhooks ist deutlich effizienter, verlangt aber eine saubere Identität pro Chunk, damit Aktualisierungen und Löschungen zuverlässig durchschlagen. Versionierung gehört dazu — sonst stehen alte und neue Fassung derselben Richtlinie gleichzeitig im Index und konkurrieren um denselben Treffer.

Bei der Latenz summieren sich vier Beiträge: Embedding der Anfrage, Vektorsuche, Re-Ranking und Generierung. Die Generierung dominiert meist, aber Re-Ranking kann spürbar zu Buche schlagen, wenn zu viele Kandidaten bewertet werden. Ein pragmatischer Zuschnitt ist, breit zu suchen, aber nur eine kleine Zahl von Kandidaten neu zu sortieren und noch weniger an das Modell zu übergeben.

Die Kosten verteilen sich auf drei Posten: einmalige beziehungsweise laufende Embedding-Kosten bei der Indexierung, Infrastrukturkosten für Index und Retrieval-Dienst, und Inferenzkosten, die im Wesentlichen mit der Menge des übergebenen Kontexts skalieren. Der letzte Posten wird am häufigsten unterschätzt: Wer bei jeder Anfrage zwanzig Abschnitte mitschickt statt fünf, zahlt das dauerhaft bei jedem einzelnen Aufruf — und bekommt wegen der schlechteren Kontextdichte oft nicht einmal bessere Antworten.

Für Bestände mit hohen Vertraulichkeitsanforderungen lässt sich die gesamte Strecke lokal betreiben: Embedding-Modell, Index und Generierungsmodell im eigenen Netz. Das ist technisch machbar und deutlich weniger exotisch als noch vor wenigen Jahren; die Einordnung dazu steht in KI-Datenschutz und lokale KI.

Braucht ihr ein eigenes RAG-System — oder reicht etwas Einfacheres?

Häufige Fehler

1. Chunking nach Zeichenzahl statt nach Struktur Feste Blockgrößen zerschneiden Tabellen, Aufzählungen und Bedingungssätze. Die vollständige Aussage existiert dann im Index nicht mehr, und keine spätere Optimierung holt sie zurück. Dokumentstruktur als primäre Grenze verwenden, Zeichenlimits nur als Obergrenze.
2. Ausschließlich auf Vektorsuche setzen Reine Ähnlichkeitssuche findet Artikelnummern, Fehlercodes und Paragraphen unzuverlässig, weil sich benachbarte Codes semantisch kaum unterscheiden. Eine zusätzliche BM25-Volltextsuche mit anschließender Rangfusion bringt hier häufig einen großen Qualitätsgewinn bei überschaubarem Aufwand.
3. Berechtigungen im Prompt statt im Retrieval Wenn ein Dokument im Kontextfenster liegt, ist es offengelegt — unabhängig davon, was die Systemanweisung sagt. Zugriffsmerkmale gehören als Metadaten an jeden Chunk und müssen gemeinsam mit der Ähnlichkeitssuche ausgewertet werden, nicht erst hinterher auf der Trefferliste.
4. Kein Evaluationsdatensatz Ohne echte Fragen mit bekannten Fundstellen lässt sich nicht unterscheiden, ob das Retrieval oder die Generierung versagt hat. Jede Optimierung wird damit zum Ratespiel, und Verbesserungen an einer Stelle bleiben unbemerkte Verschlechterungen an anderer.
5. Ingestion als einmaliges Projekt behandeln Dokumente ändern sich, werden gelöscht und umklassifiziert. Ohne inkrementelle Aktualisierung, stabile Chunk-Identitäten und Versionierung liefert das System mit der Zeit Antworten aus veralteten Fassungen — und wirkt dabei genauso überzeugend wie vorher.
6. Zu viel Kontext übergeben Mehr Abschnitte im Prompt erhöhen Kosten und Latenz bei jeder Anfrage und verschlechtern häufig die Antwortqualität, weil relevante Stellen zwischen Füllmaterial untergehen. Besser breit suchen, hart nachsortieren und wenige, dichte Abschnitte übergeben.

Weiterlesen

Verwandte Themen

• KI-Wissensmanagement: verteiltes Unternehmenswissen nutzbar machen
• KI-Infrastruktur: die technische Basis für KI im Unternehmen
• Corporate LLM: Was es ist, welche Bauformen es gibt und wann sich welche lohnt