Dieses Problem existiert bereits seit vielen Jahren:
Unternehmen sitzen auf einem riesigen Berg wertvoller interner Dokumente in unterschiedlichsten Formaten. Wissen, Regeln, Anweisungen, Tipps und Erfahrungen wurden über Jahre hinweg dokumentiert, gesammelt und an den verschiedensten Orten abgelegt.

Es ist ein enormer Schatz an Wissen – doch sobald man darauf zugreifen möchte, scheint er unauffindbar zu sein. Man weiß, dass die Information irgendwo existiert, doch niemand weiß mehr genau, wo sie abgelegt wurde.

Viele Unternehmen kennen dieses Problem nur zu gut. Immer wieder wird versucht, Ordnung in dieses Dokumentenchaos zu bringen und eine sinnvolle Struktur zu etablieren. Doch das ist in der Praxis oft schwieriger als gedacht. Selbst wenn man sich auf eine einheitliche Struktur geeinigt hat, bleiben Herausforderungen bestehen: Inhalte sind doppelt vorhanden, wurden mehrfach aktualisiert oder widersprechen sich an einzelnen Stellen.

Häufig versucht man, dem Ganzen mit strikten Ordnerhierarchien, Namenskonventionen und Volltextsuche Herr zu werden. Trotzdem kostet die Suche nach den passenden Dokumenten viel Zeit – ganz abgesehen davon, dass die gefundenen Dateien erst mühsam gesichtet werden müssen, um die tatsächlich relevante Information zu finden.

Wie praktisch wäre es, stattdessen einfach Fragen stellen zu können – und ein hilfreicher Assistent beantwortet sie direkt auf Basis der unternehmenseigenen Dokumente?
Welche Richtlinie gilt in diesem Fall?
Was muss ich hier beachten?

Große Sprachmodelle als Game Changer

Bis vor Kurzem war dies leider noch Wunschdenken. Doch dank aktueller Fortschritte in der KI – insbesondere durch große Sprachmodelle wie ChatGPT, Gemini oder Mistral – ist genau das inzwischen realistisch umsetzbar.

Diese Sprachmodelle sind in der Lage, Texte semantisch zu verarbeiten und Fragen auf Basis vorgegebener Texte zu beantworten. Dabei geht es nicht um reines Stichwortsuchen, sondern um das Verstehen von Zusammenhängen und Bedeutungen im Text.

Wir nutzen LLMs wie ChatGPT und ähnliche Modelle heute praktisch täglich, und viele können sich ein Leben ohne sie kaum noch vorstellen. Die Handhabung ist dabei erstaunlich einfach:
Wir geben dem LLM etwas Kontext in Form eines Prompts, und das Modell vervollständigt diesen.

Stellen wir eine Frage, erhalten wir – im Idealfall – eine passende Antwort. Dieses Wissen bezieht das LLM aus seinem Weltwissen, also aus den Daten, mit denen es trainiert wurde.

Fortschrittliche Modelle nutzen darüber hinaus Function Calling oder ähnliche Mechanismen, um sich zusätzliche Informationen aus externen Quellen, etwa aus dem Internet, zu beschaffen.

Wie bringen wir nun unsere eigenen Dokumente ins Spiel?

Für allgemeines Wissen funktioniert das bereits sehr gut. Doch wie stellen wir Fragen zu eigenen Dokumenten – etwa zu einer PDF-Datei?

Im Prinzip scheint auch das ganz einfach zu sein:
Wir extrahieren den Text (und gegebenenfalls auch Bilder und Tabellen) aus dem Dokument, kopieren ihn in das Chatfenster und stellen anschließend unsere Frage. Als Antwort erhalten wir – idealerweise – Informationen, die direkt aus dem Dokument stammen.

flowchart TD
subgraph A[ PDF-Verarbeitung]
A0[ PDF] --> A1[ Text extrahieren]
end

subgraph B[ Anfrage]
B0[ Nutzerfrage] --> B1[ Prompt]
A1 --> B1
end

subgraph C[ Generierung]
B1 --> C0[ LLM]
C0 --> C1[ Antwort]
end

So unkompliziert das zunächst klingt, verbergen sich dahinter jedoch einige grundlegende Probleme:

1. Das Herauskopieren relevanter Informationen aus Dokumenten kann bereits beim Copy-and-Paste mühsam und fehleranfällig sein.
2. Wir müssen dem Modell sehr genau vorgeben, wie es sich verhalten soll, damit es kein eigenes Weltwissen beimischt oder halluziniert.
3. Bei großen Dokumenten stoßen wir schnell an die Grenzen des Kontextfensters – also an die maximale Textmenge, die ein LLM gleichzeitig verarbeiten kann.
4. Der Kontext bleibt nur erhalten, weil das Dokument Teil des Chatverlaufs ist. Wird es nicht erneut mitgeschickt oder fällt aus dem Kontextfenster, ist es für das LLM nicht mehr verfügbar.
5. Durch die hohe Anzahl an Tokens kann dieser Ansatz sehr schnell teuer werden.
6. Zudem können wir auf diese Weise immer nur einzelne Dokumente mitgeben – in der Praxis ist relevantes Wissen jedoch häufig auf Hunderte oder Tausende von Dokumenten verteilt.

Retrieval-Augmented Generation (RAG)

Die grundlegende Idee ist einfach:
Zu einer Frage werden relevante Abschnitte aus den vorhandenen Dokumenten herausgesucht und dem Prompt als zusätzlicher Kontext mitgegeben. Das LLM verfügt dadurch über genau die Informationen, die es benötigt, um die Frage dokumentengetreu zu beantworten.

flowchart TD
subgraph D[ Dokumente vorbereiten]
D0[ Dokumente] --> D1[ Inhalte extrahieren]
end

D1 --> K[ Wissensbasis]

Q[ Nutzerfrage] --> R[ Relevante Inhalte finden]
K --> R
R --> P[ Prompt mit Kontext]
P --> L[ LLM]
L --> A[ Antwort]

Wichtig ist dabei: Die Dokumente werden nicht vollständig, sondern nur selektiv eingebunden – also genau die Textstellen, die für die jeweilige Frage relevant sind.

Auf diese Weise lassen sich mehrere der zuvor beschriebenen Kernprobleme direkt lösen:
Durch die gezielte Auswahl relevanter Ausschnitte können Inhalte aus vielen Dokumenten gleichzeitig berücksichtigt werden, ohne das Kontextfenster zu sprengen oder die Tokenkosten explodieren zu lassen.

Gute Vorbereitung ist alles

Damit das LLM schnell und gezielt auf relevante Inhalte zugreifen kann, müssen die Dokumente vorab aufbereitet werden.
Zunächst gilt es, die Dokumente in eine für Maschinen lesbare Form zu überführen. Anschließend werden die Inhalte in kleinere Einheiten aufgeteilt und indexiert, sodass ein schneller Zugriff möglich ist – vergleichbar mit einer Datenbank.

Dokumente in eine lesbare Form bringen

Dieser erste Schritt ist deutlich anspruchsvoller, als es auf den ersten Blick scheint. Dokumente liegen in der Praxis in den unterschiedlichsten Formaten vor: einfache Textdateien, Word-Dokumente, E-Mails, PDFs, Webseiten und vieles mehr.

Bei einfachen Texten, Word-Dateien oder E-Mails ist die Extraktion meist unproblematisch. Anders sieht es bei PDFs oder Webseiten aus. Diese enthalten oft komplexe Formatierungen, Tabellen, Bilder, Layouts oder sogar interaktive Elemente.

Im Idealfall werden alle relevanten Inhalte vollständig extrahiert, die inhaltliche Hierarchie beibehalten und Bilder sowie Tabellen dem jeweils passenden Text zugeordnet. Gerade bei Webseiten, E-Mails oder PDFs stellt das jedoch häufig eine große Herausforderung dar.

Für diese Konvertierung kommen unterschiedliche Ansätze zum Einsatz: von selbstgebauten Extraktionspipelines über Dokumentenkonvertierungslösungen bis hin zu spezialisierten Parsern wie Docling. Je nach Aufbau und Qualität der Quelldokumente kann dieser Schritt relativ einfach – oder nahezu ein unlösbares Problem sein.

Das Ziel ist im optimalen Fall eine strukturierte, hierarchische Repräsentation der Inhalte, die als Grundlage für alle weiteren Verarbeitungsschritte dient.

Dokumente in kleinere Happen aufteilen

Nachdem wir die Daten in eine einheitliche, lesbare Form gebracht haben, werden die Dokumente in kleinere Einheiten zerlegt – sogenannte Chunks.
Diese Aufgabe übernimmt ein Splitter.

Je nach Art und Struktur des Dokuments kommen dabei unterschiedliche Strategien zum Einsatz:
vom einfachen Längenschnitt, über rekursive Splitter, bis hin zu Verfahren, die Inhalte hierarchisch entlang von Überschriften, Absätzen oder Abschnitten aufteilen.

Damit die einzelnen Chunks ihren inhaltlichen Zusammenhang nicht verlieren, wird in der Praxis meist ein Overlap verwendet. Dabei wird ein Teil des vorherigen und nachfolgenden Inhalts in jeden Chunk übernommen, um Kontext zu erhalten.

Dieser Schritt ist ein essenzieller Bestandteil der RAG-Pipeline, denn die Chunk-Größe hat einen maßgeblichen Einfluss auf die Qualität der Ergebnisse:

• Zu kleine Chunks trennen Informationen, die eigentlich zusammengehören.
• Zu große Chunks packen zu viel auf einmal hinein, sodass das Wichtige untergeht.

Auch der Overlap spielt dabei eine entscheidende Rolle. Häufig werden Faustregeln wie 200–800 Tokens Chunk-Größe bei etwa 10–20 % Overlap genannt. Diese Werte sind jedoch keine festen Vorgaben, sondern hängen stark vom Dokumenttyp und dem konkreten Anwendungsfall ab.

Bewährt haben sich Stichproben, um zu prüfen, ob einzelne Chunks für sich verständlich und sinnvoll in den Gesamtkontext einzuordnen sind. Diese Prüfung kann manuell erfolgen, lässt sich in vielen Fällen aber auch automatisiert unterstützen.

Bedeutung statt Wörter speichern

Nun haben wir unsere lesbaren Häppchen – diese möchten wir so abspeichern, dass wir sie später schnell und gezielt wiederfinden können.
Das Ziel ist, zu einem großen Dokumentenpool Fragen zu stellen und dabei genau die relevanten Chunks zu erhalten.

Früher hätte man diese Chunks einfach in einer klassischen Datenbank gespeichert und über eine Volltextsuche abgefragt – mit, wie wir wissen, oft mäßigen Ergebnissen. Die Suche bleibt dabei stark wortbasiert und berücksichtigt dabei kaum Bedeutung oder inhaltliche Nähe.

Embedding – die Bedeutung eines Worts

Dank moderner Transformer-Modelle können wir heute einen deutlich effektiveren Ansatz verfolgen:
Statt nur den Text zu speichern, speichern wir dessen Bedeutung. Dieser Vorgang wird als Embedding bezeichnet.

In den Grundlagen auf dieser Webseite beschreibe ich die Technologie hinter Embeddings ausführlicher. An dieser Stelle fasse ich das Prinzip bewusst vereinfacht noch einmal zusammen.

Wem das Thema Embeddings geläufig ist, kann diesen Absatz überspringen.

Einzelne Wörter – genauer gesagt Tokens – werden anhand einer Vielzahl von Merkmalen (man könnte auch von Eigenschaften sprechen) beschrieben und als Punkte in einem mehrdimensionalen Raum abgelegt.

Nehmen wir als vereinfachtes Beispiel eine Katze. Mit drei Eigenschaften – etwa flauschige Ohren, Fellnase und große Augen – ließe sich eine Katze in einem dreidimensionalen Raum darstellen: eine Dimension pro Eigenschaft.

Erhöhen wir die Anzahl der Dimensionen, können entsprechend mehr Eigenschaften gleichzeitig berücksichtigt werden. Mit acht Dimensionen wären es acht Eigenschaften, mit sechzehn entsprechend sechzehn. Moderne Embedding-Modelle arbeiten jedoch mit sehr viel höheren Dimensionalitäten, zum Beispiel 1.536 Dimensionen, und können damit eine entsprechend feingranulare Beschreibung der Bedeutung eines Tokens abbilden.

Wichtig dabei: Die Eigenschaften einzelner Wörter oder Begriffe werden nicht manuell festgelegt oder beschriftet. Stattdessen lernt das Modell diese Merkmale automatisch während des Trainings auf großen Textmengen. Man spricht hierbei von latenten Merkmalen, da sie zwar wirksam sind, für uns Menschen jedoch nicht direkt interpretierbar.

Das Ziel ist es, Begriffe mit ähnlicher Bedeutung im Raum nahe beieinander abzubilden.
Der Abstand zwischen ihnen drückt dabei die semantische Nähe aus.

Worte mit ähnlichen Merkmalen – etwa Katze, Hund oder Haustier – gruppieren sich in einer Region des Merkmalsraums, während Begriffe wie Auto, Fahrrad oder Lkw sich in einer anderen Region konzentrieren.

Alle Wörter (Tokens) eines Chunks werden nun embedded – das heißt, sie werden in eine Position in einem mehrdimensionalen Vektorraum überführt.
Das Ergebnis ist ein numerischer Vektor, zum Beispiel (0.1, 0.23, …), mit einem Zahlenwert pro Dimension.

Verschiedene Anbieter stellen heute unterschiedliche Embedding-Modelle zur Verfügung, darunter zum Beispiel E5, OpenAI oder Cohere.

Betrachten wir einen Chunk mit beispielsweise 500 Tokens. Würde man jedes Token einzeln als Vektor mit 1.536 Dimensionen darstellen, ergäbe das pro Chunk 768.000 Zahlenwerte. Das ist unhandlich und lässt sich später nur schwer effizient vergleichen.

Deshalb verfolgen wir einen anderen Ansatz:
Jeder Chunk wird als Ganzes durch einen einzigen Vektor beschrieben. Dieser Vektor dient als eine Art kompakter Fingerabdruck für den gesamten Inhalt des Chunks.

Pooling

Das Verfahren, aus vielen Token-Vektoren einen einzigen Fingerabdruck für den gesamten Chunk zu berechnen, nennt man Pooling.
Dabei gibt es verschiedene Pooling-Strategien, zum Beispiel Mean Pooling, Max Pooling, CLS-Token oder Weighted Pooling.

Für RAG-Anwendungen wird in der Praxis häufig Mean Pooling eingesetzt. Dabei wird für jede Dimension der arithmetische Mittelwert über alle Token-Vektoren eines Chunks berechnet. Konkret bedeutet das:
Jede einzelne Dimension aller Token wird aufsummiert und anschließend durch die Anzahl der Tokens geteilt – eine klassische Mittelwertberechnung.

Durch dieses Verfahren werden die semantischen Merkmale aller Tokens eines Chunks zusammengeführt.
Erstaunlicherweise liefert diese einfache Methode in vielen Anwendungsfällen stabile und gut vergleichbare Ergebnisse.

Je nach Embedding-Modell ist dieser Pooling-Schritt intern umgesetzt oder explizit auswählbar.

Speichern in der Datenbank

Nun können wir den Chunk-Vektor gemeinsam mit dem zugehörigen Text in einer Vektordatenbank speichern.
Dadurch lassen sich die Inhalte später schnell, zuverlässig und semantisch wiederfinden.

Zur Auswahl stehen verschiedene Vektordatenbanken, die jeweils ihre eigenen Vor- und Nachteile haben. Dazu zählen zum Beispiel Pinecone, Weaviate, Qdrant, Milvus oder ChromaDB.

Für Tests und Prototypen (MVPs) eignet sich ChromaDB besonders gut, da es leichtgewichtig, einfach aufzusetzen und lokal nutzbar ist.
Für den produktiven Einsatz greifen Unternehmen hingegen häufiger zu Pinecone, Weaviate oder Qdrant, da diese Lösungen besser auf Skalierbarkeit, Stabilität und Betrieb in Produktionsumgebungen ausgelegt sind.

Frage deine KI

RAG-Systeme sind in Unternehmen oft der erste Berührungspunkt mit KI. Sie lassen sich vergleichsweise einfach implementieren und liefern schnell einen konkreten, messbaren Mehrwert.

Für Mitarbeitende ist das besonders praktisch, um Fragen zu internen Richtlinien, Prozessen oder dem unternehmensweiten Wissenspool zu stellen. Gleichzeitig profitieren auch Kundinnen und Kunden, etwa bei Fragen zu Öffnungszeiten, Produkten oder Services.

In der Praxis erfolgt die Interaktion häufig über eine Chatoberfläche, die an bekannte KI-Systeme erinnert. Alternativ wird das System direkt in eine bestehende Infrastruktur integriert, zum Beispiel in Microsoft Teams oder ähnliche Kollaborationstools.

Dabei gilt: Je unauffälliger und natürlicher die Integration, desto besser wird KI von den Menschen angenommen.

Wie findet RAG die relevanten Chunks?

In der Praxis stellt ein Nutzer eine Frage, zum Beispiel: „Wie sind die Öffnungszeiten?“
Nun ist es Aufgabe des RAG-Systems, auf Basis dieser Anfrage die relevanten Chunks zu finden und daraus eine möglichst passende Antwort zu generieren.

Der Ablauf ist dabei sehr ähnlich zu dem Prozess, den wir bereits beim Embedding der Dokumente kennengelernt haben:

1. Die Frage des Nutzers wird zunächst in Tokens zerlegt.
2. Anschließend wird die gesamte Frage embedded und – je nach Modell – gepoolt. Dadurch erhält sie eine Position im Embedding Space, also im mehrdimensionalen latenten Vektorraum.
3. Die Chunks, die im Vektorraum am nächsten zu dieser Frage liegen, sind diejenigen, die uns interessieren.

Ganz wichtig dabei ist, dass für das Embedding der Chunks und für das Embedding der Nutzerfrage dasselbe Embedding-Modell und dieselben Parameter verwendet werden.

Andernfalls liegen Frage und Dokumente in unterschiedlichen Vektorräumen – sie „sprechen“ dann nicht dieselbe Sprache und lassen sich nicht sinnvoll miteinander vergleichen.

Wie finden wir heraus, welche Chunks am nächsten zu unserer Frage sind?

Dazu messen wir die räumliche Distanz zwischen dem Vektor der Nutzerfrage und den Vektoren der gespeicherten Chunks.
Chunks mit dem geringsten Abstand gelten als semantisch am ähnlichsten und werden für die Beantwortung der Frage herangezogen.

Wie man den geometrischen Abstand zwischen Vektoren misst, habe ich in den Grundlagen auf dieser Webseite bereits ausführlich erklärt.
Ich greife den Punkt hier noch einmal kurz auf, um den Zusammenhang klarzumachen.

Geometrische Nähe im Embedding-Raum

Grundlegend gibt es drei Möglichkeiten, die räumliche Nähe zu messen:

1) Euklidische Distanz
Dabei wird der geometrische Abstand zwischen zwei Vektoren über alle Dimensionen berechnet.
Anschaulich entspricht das der „geraden Linie“ zwischen zwei Punkten im Vektorraum.

d(\mathbf{x}, \mathbf{y}) = \sqrt{(x_1 - y_1)^2 + (x_2 - y_2)^2 + (x_3 - y_3)^2}

d(\mathbf{x}, \mathbf{y}) = \sqrt{\sum_{i=1}^{n} (x_i - y_i)^2}

2) Skalares Produkt (Dot-Produkt)
Die Ähnlichkeit von Wörtern lässt sich auch über den Winkel und die Länge der Vektoren ihrer Embeddings verstehen.
Man kann sich das so vorstellen: Je kleiner der Winkel zwischen den Vektoren zweier Wörter ist, desto ähnlicher sind ihre Bedeutungen.

\mathbf{x} \cdot \mathbf{y} = \sum_{i=1}^{n} x_i , y_i

3) Kosinus-Ähnlichkeit

Die Kosinus-Ähnlichkeit geht noch einen Schritt weiter und ist ein normalisiertes Skalarprodukt.
Das bedeutet: Es wird nur der Winkel zwischen den Vektoren betrachtet, unabhängig von ihrer Länge.
Das Ergebnis liegt immer zwischen –1 und 1.
Wie auch bei den anderen Verfahren fließen alle Dimensionen der Embeddings in die Berechnung ein.

cos(\theta) = \frac{ \vec{A} \cdot \vec{B} }{ | \vec{A} | \cdot | \vec{B} | }

In vielen RAG-Systemen lässt sich eines dieser Distanz- bzw. Ähnlichkeitsverfahren konfigurieren.

In der Praxis werden Embedding-Vektoren oft normalisiert, sodass ihre Länge keine Rolle mehr spielt und beim Vergleich nur noch die inhaltliche Richtung zählt.

Nur die besten kommen in die Auswahl

In der Praxis übergeben wir der Vektordatenbank die Nutzerfrage (als Embedding) sowie die gewünschte Anzahl an Treffern (k).

Die Vektordatenbank berechnet daraufhin, welche Chunks der Anfrage semantisch am nächsten liegen, sortiert sie nach Ähnlichkeit und liefert die Top-k relevantesten Chunks zurück.

Anfrage an das LLM

Die Anfrage an das LLM erfolgt in Form eines Prompts. Dabei werden die System-Anweisung, die relevanten Chunks sowie die Nutzeranfrage zu einem gemeinsamen Kontext zusammengeführt und in einer Anfrage an das LLM gesendet.

In der Praxis wird die System-Anweisung häufig auf Englisch formuliert – selbst dann, wenn der eigentliche Kontext und die Nutzerfrage deutsch sind. Der Grund dafür ist, dass die Stabilität und Zuverlässigkeit von Instruktionen bei den meisten LLMs in englischer Sprache höher ist.

{
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful assistant. Answer only based on the provided context. If the answer is not contained in the context, say that you do not know."
    },
    {
      "role": "user",
      "content": "Context:\n---\n[Chunk 1]\n[Chunk 2]\n[Chunk N]\n---\n\nQuestion:\nWie sind die Öffnungszeiten?"
    }
  ]
}

Mit dieser Anweisung vervollständigt das LLM die Nutzeranfrage gemeinsam mit dem bereitgestellten Kontext zu einer sinnvollen, zusammenhängenden Antwort.

{
  "role": "assistant",
  "content": "Unsere Öffnungszeiten sind Montag bis Freitag von 08:00 bis 17:00 Uhr."
}

In vielen Systemen werden zusätzlich die verwendeten Textstellen referenziert oder mitgeliefert, um Antworten nachvollziehbar zu machen.

Am Ende dieses Prozesses steht ein funktionsfähiges RAG-System, das Antworten auf Grundlage der hochgeladenen Dokumente generiert.

Die RAG-Pipeline im Überblick

flowchart TD

%% INDEXING
subgraph A[ Indexing]
A0[ Dokumente] --> A1[ Chunking]
A1 --> A2[ Tokenisierung]
A2 --> A3[ Transformer Encoder]
A3 --> A4[ Token Vektoren]
A4 --> A5[ Pooling z.B.: Mean]
A5 --> A6[ Chunk Vektor]
A6 --> A7[( VectorDB)]
end

%% QUERY
subgraph B[ Query]
B0[ User Query] --> B1[ Tokenisierung]
B1 --> B2[ Transformer Encoder]
B2 --> B3[ Token Vektoren]
B3 --> B4[ Pooling z.B.: Mean]
B4 --> B5[ Query Vektor]
end

%% RETRIEVAL
subgraph C[ Retrieval]
B5 --> C1[ Similarity Search]
A7 --> C1
C1 --> C2[ Top-k Chunks]
end

%% GENERATION
subgraph D[ Generation]
D0[ Prompt + Kontext + Frage] --> D1[ LLM]
D1 --> D2[ Antwort]
end

C2 --> D0

Unsere RAG-Pipeline ist bereits voll funktionsfähig – dennoch lässt sie sich weiter verbessern.

Die Antworten basieren primär auf semantischer Ähnlichkeit. Das ist der große Fortschritt – und in den meisten Fällen genau richtig. Manchmal möchte man jedoch ganz gezielt exakte Details finden, zum Beispiel Nummern, IDs oder konkrete Fehlermeldungen. In solchen Fällen ist ein rein semantischer Ansatz nicht immer die beste Wahl.

Gespür für Details – BM25

Hier kann ein klassisches Retrieval-Verfahren helfen: BM25 (Best Matching 25).
BM25 basiert auf Wortstatistiken und kommt ohne KI aus. Die Grundidee ist einfach: Seltene Wörter sind oft besonders aussagekräftig – vor allem dann, wenn sie in wenigen, aber relevanten Textstellen auftauchen (z. B. eine eindeutige Fehlermeldung oder ein spezieller Fachbegriff).

BM25 nutzt dabei unter anderem folgende Größen:

• Term Frequency (TF): Wie oft kommt ein Wort in einem Chunk vor?
• Document Frequency (DF): In wie vielen Chunks kommt dieses Wort insgesamt vor?
• Dokumentlänge: Wie lang ist der Chunk im Vergleich zu anderen?

In Kombination mit Embeddings entsteht so ein robustes Hybrid-Retrieval:
Embeddings liefern Textverständnis und finden auch ähnliche Formulierungen, während BM25 besonders gut bei exakten Begriffen, Fehlercodes und Fachtermini ist.

Beim Chunking der Dokumente werden die Chunks sowohl in einen BM25-Textindex aufgenommen als auch parallel als Embeddings in der Vektordatenbank gespeichert.

Hybrid RAG

Beim hybriden RAG werden für eine Nutzeranfrage zwei Suchen parallel ausgeführt: eine semantische Vektorsuche auf Basis von Embeddings und eine statistische, wortbasierte Suche mit BM25.
Beide Verfahren liefern jeweils ihre Top-k Chunks, die anschließend zusammengeführt und weiterverarbeitet werden.

flowchart TD

%% INDEXING
subgraph A[ Indexing]
A0[ Dokumente] --> A1[ Chunking]
A1 --> A2[ Embedding Model]
A2 --> A3[ Chunk Embeddings]
A3 --> A4[( Vector Database)]
A1 --> A5[ Tokenization]
A5 --> A6[( BM25 Text Index)]
end

%% QUERY
subgraph B[ Query]
B0[ User Query] --> B1[ Embedding Model]
B1 --> B2[ Query Embedding]
B0 --> B3[ Tokenization]
end

%% RETRIEVAL
subgraph C[ Retrieval]
B2 --> C1[ Vector Search]
A4 --> C1
C1 --> C2[ Top-k Vector]

B3 --> C3[ BM25 Retrieval]
A6 --> C3
C3 --> C4[ Top-k BM25]

C2 --> C5[ Merge / Re-ranking]
C4 --> C5
C5 --> C6[ Final Top-k Chunks]

end

%% GENERATION
subgraph D[ Generation]
C6 --> D0[ Prompt: Context + Question]
D0 --> D1[ LLM]
D1 --> D2[ Answer]
end

Hier kommt im Retriever eine zusätzliche Komponente ins Spiel: Merge / Re-Ranking.
Denn wir erhalten zwei getrennte Ergebnislisten – einmal aus der Vektorsuche und einmal aus BM25. Diese Kandidaten müssen wir zusammenführen, nach Relevanz sortieren und anschließend auf ein finales Top-k begrenzen.

Dafür gibt es unterschiedliche Strategien, zum Beispiel:

• score-basiert (Scores werden normalisiert und kombiniert)
• ranking-basiert (Ränge werden zusammengeführt, z. B. über Rank-Fusion)

Besonders gute Ergebnisse liefern Transformer-Modelle als Re-Ranker. In der Praxis sind zwei Ansätze verbreitet:

1. Cross-Encoder Re-Ranker
   Ein Modell, das Query und Chunk gemeinsam bewertet und daraus einen Relevanzscore ableitet. Solche Modelle sind typischerweise für Relevanzbewertung (Ranking) optimiert.
2. LLM Re-Ranking (z. B. per GPT)
   Ein klassisches LLM, das per Prompt dazu angeleitet wird, die Kandidaten-Chunks nach Passgenauigkeit zur Frage zu sortieren oder die besten k auszuwählen.

Anschließend gehen die Nutzeranfrage und die passendsten Chunks in die Generation-Pipeline, wo das LLM daraus eine möglichst passende und informative Antwort auf die Frage des Nutzers erzeugt.

Millionen von Vektoren? – Hierarchical Navigable Small World (HNSW)

Spätestens bei großen RAG-Systemen stellt sich die Frage, wie sich Millionen multidimensionaler Vektoren in akzeptabler Zeit durchsuchen lassen. Ein exakter Vergleich aller Vektoren wäre hier zu langsam.

In der Praxis kommen daher approximative Ähnlichkeitssuchen zum Einsatz – Verfahren, die sich schrittweise an die relevantesten Vektoren annähern.
Ein häufig verwendeter Ansatz ist HNSW (Hierarchical Navigable Small World), der von vielen Vektordatenbanken eingesetzt wird.

Das Prinzip lässt sich gut mit einem Straßennetz vergleichen:
Vektoren werden in mehreren Hierarchieebenen organisiert. Die obersten Ebenen sind sehr dünn besetzt und entsprechen gewissermaßen Autobahnen, über die man schnell große Distanzen zurücklegt. Die darunterliegenden Ebenen werden zunehmend dichter und bilden feinere lokale Verbindungen ab – vergleichbar mit Landstraßen und Nebenstraßen.

Die Suche beginnt immer in der obersten Ebene. Dort wird der Vektor gesucht, der der Anfrage am ähnlichsten erscheint. Von diesem Punkt aus wechselt der Algorithmus in die nächsttiefere, dichter vernetzte Ebene und setzt die Suche fort. Dieser Vorgang wiederholt sich Ebene für Ebene, bis die unterste und detaillierteste Ebene erreicht ist.

Auf diese Weise nähert sich die Suche gezielt dem Zielvektor, ohne alle Vektoren vergleichen zu müssen.
Das ermöglicht eine sehr schnelle Ähnlichkeitssuche, insbesondere bei großen Vektormengen, bei gleichzeitig hoher Trefferqualität.

Grenzen von RAG

Moderne LLMs machen es erstmals möglich, intelligente Frage-Antwort-Systeme auf Basis bestehender Dokumente zu realisieren. Dennoch sollten bei RAG-Systemen einige grundlegende Einschränkungen berücksichtigt werden.

1. Datenqualität ist entscheidend
   RAG kann nur mit den Informationen arbeiten, die tatsächlich extrahiert wurden. Gerade bei komplexen Formaten wie PDFs, Webseiten oder E-Mails ist die zuverlässige Extraktion von Text, Struktur und Kontext häufig eine große Herausforderung.
2. Verlust von Kontext durch Chunking
   Durch die Aufteilung von Dokumenten in einzelne Chunks können Zusammenhänge verloren gehen. Aufgaben, die ein globales Verständnis erfordern – etwa vollständige Zusammenfassungen oder Querverweise über mehrere Abschnitte hinweg – sind dadurch nur eingeschränkt möglich.
3. Halluzinationen sind nicht vollständig ausgeschlossen
   RAG reduziert Halluzinationen deutlich, verhindert sie jedoch nicht vollständig. Findet das System keine passenden Inhalte zur Anfrage oder sind die bereitgestellten Chunks unklar, kann das LLM weiterhin plausibel klingende, aber falsche Antworten erzeugen.
4. Begrenzte Nachvollziehbarkeit
   Ohne zusätzliche Maßnahmen ist oft nicht transparent, auf welchen Textstellen eine Antwort basiert. In der Praxis ist es daher sinnvoll, Quellen, Textausschnitte oder Positionsangaben mitzuliefern, um Ergebnisse überprüfbar zu machen.

Alle reden über Künstliche Intelligenz – ein Hype, der in aller Munde ist. Täglich hört man von den erstaunlichen Fähigkeiten moderner Sprachmodelle wie ChatGPT, Gemini, Granite und vielen anderen.

Obwohl es Künstliche Intelligenz (KI) und Neuronale Netze schon seit Jahrzehnten gibt – etwa für

• Filmempfehlungen
• Produktvorschläge
• Werbeoptimierung
• Bonitätsprüfungen

löste ChatGPT Ende 2022 einen weltweiten Hype aus.

Warum war das so?

KI war zuvor meist unsichtbar im Hintergrund aktiv: Sie unterstützte Geschäftsprozesse, half bei Analysen oder steuerte Personalisierungen, ohne dass Endnutzer sie direkt wahrnahmen.

Erst mit der Veröffentlichung des großen Sprachmodells (LLM) ChatGPT durch OpenAI konnten plötzlich Millionen Menschen selbst erleben, wie leistungsfähig moderne KI-Systeme sind:

• Texte schreiben
• Erklären
• Zusammenfassen
• Ideen liefern
• Programmieren

Und das alles in natürlicher Sprache – scheinbar mühelos. Damit rückt die KI in Bereiche vor, die lange als kreative Domäne des Menschen galten: Sprache verstehen, Wissen verknüpfen, neue Ideen hervorbringen.

Innerhalb von nur 2 Monaten erreichte ChatGPT bereits über 100 Millionen Nutzer – ein Rekord, der es zum am schnellsten wachsenden digitalen Produkt der Geschichte machte.

Damit wurde KI zum ersten Mal unmittelbar erfahrbar für jedermann, nicht nur für Experten oder Unternehmen. Dieser direkte Zugang erklärt den enormen Hype – und markiert einen Wendepunkt in der öffentlichen Wahrnehmung von Künstlicher Intelligenz.

KI – sicher mehr als nur ein Hype

Ist das alles nur heiße Luft? Meiner Meinung nach nicht. Vielmehr stehen wir wahrscheinlich mitten in einer der größten technologischen Revolutionen unserer Zeit – mit Auswirkungen, die weit über einzelne Branchen hinausgehen werden.

Heute gibt es nicht nur ChatGPT, sondern viele weitere Mitbewerber wie Gemini (Google), Granite (IBM), LLaMA (Meta), Mistral, DeepSeek und zahlreiche andere.
Die rasanten Entwicklungen und Erfolge sind inzwischen kaum mehr vollständig zu überblicken.

Doch gerade deshalb stellt sich die spannende Frage:
Warum überhaupt eine KI auf der eigenen Hardware betreiben, wenn es so viele leistungsstarke Modelle in der Cloud gibt?

Warum eine eigene KI betreiben?

Stellen wir uns vor, wir könnten Sprachmodelle lokal installieren – welche Vorteile würde das mit sich bringen?

• Spezialisierung – Lokale Modelle können gezielt auf eigene Daten oder Fachgebiete zugeschnitten werden.
• Kosten – Nach der Einrichtung entstehen keine laufenden API- oder Abo-Kosten, nur Strom- und Hardwareaufwand.
• Performance – Für viele Anwendungen reicht die Geschwindigkeit lokaler Modelle aus, besonders mit optimierten Versionen.
• Latenz – Abfragen laufen direkt auf der eigenen Hardware, ohne Umweg über die Cloud.
• Sicherheit & Datenschutz – Alle Daten bleiben lokal, nichts verlässt den eigenen Rechner oder das Unternehmensnetzwerk.
• Flexibilität – Nutzer entscheiden selbst, welche Modelle und Tools sie einsetzen.
• Finetuning – Modelle lassen sich mit eigenen Daten nachtrainieren und damit optimal anpassen.
• Vielfalt der Modelle – Es gibt viele offene Modelle (z. B. LLaMA, Mistral, Falcon, DeepSeek), die je nach Bedarf eingesetzt werden können.
• Offline-Nutzung – Auch ohne Internetzugang bleibt die KI einsatzfähig.
• Keine externen Beschränkungen – Keine Limits bei Abfragen oder Abhängigkeit von Nutzungsbedingungen Dritter.
• Individuelle Sicherheitseinstellungen – Man kann selbst entscheiden, welche „Guardrails“ oder Sicherheitsfilter aktiv sein sollen – oder eben nicht.

Die nächste spannende Frage lautet: Ist es überhaupt möglich, so große Sprachmodelle lokal zu betreiben?

Die ganz großen Modelle – etwa GPT-5 (OpenAI), Gemini 2.5 Pro (Google) oder Claude Opus 4 (Anthropic) – werden weder Privatnutzer noch die meisten Unternehmen lokal installieren können. Sie laufen in riesigen Rechenzentren mit Millionen spezialisierter Recheneinheiten (GPUs/TPUs/NPUs) und erfordern eine Infrastruktur, die außerhalb von Hyperscalern (Google, Microsoft, Meta, Amazon usw.) nicht realistisch ist.

Ja, es gibt sie wirklich: große Sprachmodelle für den lokalen Einsatz

Aber: Es ist durchaus möglich, leistungsstarke offene Sprachmodelle lokal auf der eigenen Hardware zu betreiben. Projekte wie LLaMA (Meta), Mistral, Falcon, DeepSeek oder Mixtral sind so optimiert, dass sie auch auf normaler Consumer-Hardware (starke CPU, moderne GPU, ausreichend RAM) lauffähig sind.

Und das Erstaunliche: Manche dieser lokalen Modelle kommen in einzelnen Disziplinen – etwa beim Textverständnis, Programmieren oder in Benchmarks – den großen Cloud-Modellen beeindruckend nahe. Damit eröffnen sich für Forschung, Unternehmen und Privatpersonen völlig neue Möglichkeiten: von Datenschutz und Kostenkontrolle bis hin zu individuellen Anpassungen.

Wir sprechen hier meist von Sprachmodellen, doch aktuelle Systeme können längst viel mehr.
Sie verstehen nicht nur Text, sondern sind in der Lage, auch Bilder, Audio und sogar Video zu verarbeiten und zu erzeugen.

Deshalb spricht man heute nicht mehr ausschließlich von Sprachmodellen, sondern von multimodalen Foundation Modellen (kurz MFM).
Diese Modelle verknüpfen verschiedene Eingabe- und Ausgabeformen und eröffnen dadurch völlig neue Anwendungsmöglichkeiten – etwa Bildbeschreibung, Spracherkennung, Code-Generierung oder Videoanalyse.

Auch wenn einige Vorteile vielleicht dafürsprechen, es lokal zu versuchen – welche Nachteile gibt es?
Klar ist: Man benötigt auf jeden Fall leistungsstarke Hardware und ein gewisses Maß an technischem Know-how.

Neuronale Netze

Sprachmodelle – oder allgemeiner Multimodale Foundation Models (MFM) – basieren auf künstlichen neuronalen Netzen.
Diese sind von der Funktionsweise des Gehirns inspiriert und bestehen aus Millionen künstlicher Neuronen sowie Milliarden von Parametern.
Parameter sind die Gewichte und Bias-Werte, mit denen das Netzwerk während des Trainings Muster erkennt und z.B. Vorhersagen trifft.

Dass hierfür enorme Rechenleistung nötig ist, liegt auf der Hand.
Ein einzelner Prozessor (CPU) stößt hier ganz schnell an seine Grenzen – moderne Grafikkarten (GPUs) sind dagegen bestens geeignet.

Grafikkarten treiben lokale KI an

Warum? Neuronale Netze benötigen vor allem extrem viele Matrix-Multiplikationen.
Genau diese Art von Berechnungen sind seit jeher das Herzstück der 3D-Grafik:
Schon seit Jahrzehnten nutzen Computerspiele GPUs, um komplexe 3D-Spielwelten in Echtzeit zu berechnen.
Mit dem steigenden Anspruch an Grafikqualität haben sich Grafikkarten zu wahren Rechenmonstern entwickelt.

Heute profitiert die KI davon: Dieselbe Hardware, die für 3D-Spiele gedacht war, eignet sich auch hervorragend für das Training und den Betrieb neuronaler Netze.
(Zudem gibt es heute auch spezialisierte Chips wie TPUs von Google oder die Tensor Cores in NVIDIA-GPUs sowie andere dedizierte AI-Chips, die speziell für KI-Berechnungen entwickelt wurden.)

Wichtiger Faktor: Geschwindigkeit

Um möglichst viele Matrizen berechnen zu können, braucht es vor allem eine hohe Parallelität.
Das bedeutet: Viele Recheneinheiten („Shaderkerne“) und eine solide Taktfrequenz.

Was sind Shaderkerne?
Shaderkerne sind kleine Recheneinheiten innerhalb der GPU, die ursprünglich für die Berechnung von 3D-Grafik gedacht waren,

• Geometrie zu berechnen (Vertex-Shader)
• Farben und Pixel zu berechnen (Fragment-Shader)

Mit dem Aufkommen von KI kam eine weitere Nutzung hinzu: Compute-Shader.
Dabei handelt es sich um Programme, die auf Shaderkernen laufen und speziell für mathematische Operationen (z. B. Matrixmultiplikationen) entwickelt wurden.
(NVIDIA nennt sie daher CUDA-Kerne)

Im KI-Bereich spricht man deshalb oft von Kernels – hochoptimierten Routinen, die die eigentlichen Berechnungen übernehmen.

Warum ist das wichtig?

• Shaderkerne / CUDA-Kerne sind extrem zahlreich – bei aktuellen Karten wie der RTX 4090 über 16.000 Stück.
• Sie können gleichzeitig (parallel) rechnen, wodurch enorme Geschwindigkeiten erreicht werden.
• Für die Leistung sind daher sowohl die Taktfrequenz als auch vor allem die Anzahl der Kerne entscheidend.

Ausschlaggebend: Speicher

Noch wichtiger als die reine Rechengeschwindigkeit ist der Speicher – und zwar nicht der Hauptspeicher (RAM), sondern das VRAM (Video RAM) direkt auf der Grafikkarte.
Die Recheneinheiten der GPU (CUDA-/Shaderkerne) können ausschließlich auf diesen Grafikspeicher zugreifen.

Foundation Models sind riesig: Sie enthalten Milliarden von Parametern und benötigen daher enorme Mengen an Speicherplatz. Zusätzlich fällt während der Berechnung weiterer Speicherbedarf für Zwischenergebnisse (z.B. KV-Cache) an.
Das macht den Grafikspeicher zum eigentlichen Flaschenhals.

• Mit 8 GB VRAM lassen sich nur kleine Modelle (z. B. 7B-Modelle in starker Quantisierung) nutzen.
• 16 GB ermöglichen schon komfortableres Arbeiten und den Einsatz mittelgroßer Modelle.
• Ab 24 GB VRAM lassen sich auch größere Sprachmodelle lokal laden und sinnvoll betreiben.

Zwar ist es technisch möglich, den Hauptspeicher (RAM) einzubinden, wenn der VRAM nicht ausreicht – doch dann müssen Daten ständig zwischen Hauptspeicher und VRAM hin- und her kopiert werden.
Das verlangsamt die Berechnungen drastisch und macht eine sinnvolle Nutzung praktisch unmöglich.

Das Modell

Wir haben nun schon einige Male den Begriff Modell verwendet – aber was genau bedeutet das eigentlich?

Ein Modell ist das Ergebnis des Trainings eines neuronalen Netzes.
Es umfasst:

• die Parameter des Netzes (vor allem Gewichte und Bias-Werte),
• die Architektur des Netzwerks, also die Beschreibung der Schichten und ihrer Verbindungen (oft als Rechengraph dargestellt).

All diese Informationen werden in einer oder mehreren Dateien gespeichert und können später wieder geladen werden.
So wird aus dem trainierten Modell ein Werkzeug, das für die Inferenz – also die praktische Anwendung – genutzt werden kann.

Das sind letztlich die Rohdaten des Modells, die von einer passenden Runtime oder einem Framework geladen und ausgeführt werden können.
Ähnlich wie bei Bildern – die je nach Format (z. B. JPG, PNG, TIFF) unterschiedliche Eigenschaften haben – gibt es auch für Modelle verschiedene Speicherformate.
Nur wenn das richtige Format verwendet wird, kann ein Modell korrekt geladen und für die Inferenz ausgeführt werden.

Sprach- und Foundation-Modelle – wahre Giganten

Wir haben bereits erwähnt, dass Foundation Models extrem groß sein können. Aber wie groß ist „groß“?
Bei aktuellen Modellen geben die Betreiber – vermutlich aus Konkurrenzgründen – kaum noch Details wie Architektur oder genaue Parameterzahlen preis.
Es gibt jedoch Leaks und fundierte Schätzungen.

Demnach arbeiten diese Netzwerke mit bis zu Billionen von Parametern.
Allerdings werden je nach Architektur (z. B. Mixture of Experts, kurz MoE) nicht alle Parameter gleichzeitig genutzt.
Um Rechenzeit und Speicher zu sparen, werden pro Anfrage („Prompt“) nur bestimmte Experten-Teile des Netzes aktiviert.
Bei GPT-4 bedeutet das nach Schätzungen trotzdem immer noch rund 300 Milliarden aktive Parameter pro Inferenz.

Die Parameter liegen in der Regel als Fließkommazahlen im FP16-Format vor, also 2 Byte pro Parameter (seltener auch als BF16).
Allein das Modell würde damit schon 300 Milliarden × 2 Byte ≈ 600 GB VRAM belegen –
und das ohne zusätzliche Zwischenspeicherungen wie den KV-Cache, der bei langen Kontexten nochmals hunderte Gigabyte beanspruchen kann.

Alles in allem also: riesig und viel zu groß für den lokalen Einsatz.
Deshalb werden für den Betrieb auf normaler Hardware kleinere Modelle entwickelt und optimiert – die aber trotzdem eine erstaunliche Leistung erreichen.

Aktuelle Open-Weight-Modelle für lokale Nutzung

Die Größe der Modelle wird meist mit B angegeben – das steht im Englischen für „Billion“ (US-Zählweise) und entspricht Milliarden Parametern auf Deutsch.
Beispiel: LLaMA-3 8B bedeutet, dass das Modell etwa 8 Milliarden Parameter hat.

Rechnen wir kurz: Das kleinste Modell der Reihe, LLaMA-3 8B, hat rund 8 Milliarden Parameter.

Bei FP16/BF16 (16 Bit) entspricht das 2 Byte pro Parameter → 8B × 2 Byte ≈ 16 GB VRAM nur für die Modellgewichte.

Dazu kommt der KV-Cache für die Attention, dessen Größe linear mit der Kontextlänge wächst.
Als „sehr grobe“ Faustregel (bei 16 Bit):

• kleine Modelle bis ~10B Parameter → ca. 0,5 MB pro Token
• mittlere Modelle (~10–30B Parameter) → ca. 1 MB pro Token
• große Modelle (70B+) → ca. 3–4 MB pro Token

Praxisbeispiel (8k Kontext):

• 16 GB (Gewichte) + ~4 GB (KV-Cache) + Overhead ⇒ > 20 GB Gesamtbedarf

Selbst eine hochwertige Grafikkarte mit 16 GB VRAM reicht für LLaMA-3 8B in FP16 nicht mehr aus.

Trotzdem zu groß – Speicher weiter reduzieren

Drücken wir den Speicherbedarf einmal gedanklich herunter:

Modelle werden meist im Format FP16 ausgeliefert.

In FP16 besteht eine Zahl aus:

V EEEEE MMMMMMMMMM

• v = 1 Bit Vorzeichen
• e = 5 Bit Exponent (legt den Wertebereich fest)
• m = 10 Bit Mantisse (legt die Genauigkeit fest)

Damit lässt sich ein Bereich von rund −65.504 bis +65.504 abdecken.

Für viele KI-Modelle sind die Gewichte jedoch bereits auf den Bereich −1 bis +1 normalisiert.
Der große Exponentenbereich wird also kaum genutzt – die 5 Exponenten-Bits sind in diesem Fall überflüssig.

Theoretisch würden also 11 Bit (1+10) genügen, um Modellgewichte in diesem Bereich ohne Präzisionsverlust darzustellen.
Das entspräche einer Ersparnis von rund 31 % Speicher – allerdings nur als Gedankenmodell, da es kein echtes 11-Bit-Format gibt.

Wie kann man diese Modelle doch noch in den Griff bekommen?

Quantisierung – das Wunder der (fast) verlustfreien Komprimierung

Genau hier setzt Quantisierung an:
Sie reduziert die Bitbreite noch weiter – typischerweise auf 8 Bit oder sogar 4 Bit –
und erzielt dadurch enorme Einsparungen bei Speicher und Rechenaufwand, bei meist nur geringem Qualitätsverlust.

In unseren einfachen Rechnungen konnten wir bereits 5 Bit einsparen, ohne Genauigkeitsverluste.
In der Praxis lässt sich der Wertebereich jedoch nicht immer exakt auf –1 bis +1 begrenzen. Manchmal reicht er weiter, manchmal liegt er nur zwischen –0.2 und +0.2.
Daher arbeitet man nicht mit fixen Grenzen, sondern bestimmt den tatsächlichen Minimal- und Maximalwert der Parameter.
Die so entstehende Range zwischen Min und Max wird anschließend quantisiert, indem man sie in gleichmäßige (lineare) Abstände aufteilt.

Die Quantisierung wird in Bit angegeben, z. B. 8 Bit, 4 Bit oder sogar nur 2 Bit.

• 8 Bit = 256 Stufen
• 4 Bit = 16 Stufen
• Ganzzahlen: 8 Bit = 1 Byte

Beispiel:
Bei einem Range von –1 bis +1 (Breite = 2.0) und 8 Bit teilen wir diesen Bereich in 256 Stufen auf = 1 Byte

Teilen wir den Wertebereich 2.0 durch 256 Stufen, ergibt sich ein Skalierungswert von 0.0078125.
Das ist der Abstand von einer Stufe zur nächsten und bestimmt die Genauigkeit:

• Weniger Bits → größere Abstände → geringere Genauigkeit.

In der Praxis:

• Für jeden Parameter wird eine Stufe gespeichert (als Byte).
• Zusätzlich gibt es den Skalierungsfaktor.
• Diese Quantisierung passiert nach dem Training, aber vor der Nutzung des Modells.

Symmetrische Quantisierung

• Range ist um 0 symmetrisch (z. B. –1 bis +1).
• Nur ein Skalierungsfaktor wird gespeichert.
• Einfach, aber bei asymmetrischen Daten geht Präzision verloren.

Asymmetrische Quantisierung

• Range ist verschoben (z. B. –1 bis +0.2).
• Zusätzlich zum Skalierungsfaktor wird ein Nullpunkt (Zero Point) gespeichert.
• Der Zero Point legt fest, welche Ganzzahl genau den Wert 0 repräsentiert.
• Vorteil: Der verfügbare Wertebereich wird optimal genutzt.

Dequantisierung

Bei der Inferenz (Anwendung des Modells) liegen die Parameter nicht mehr als FP16-Werte vor, sondern z. B. nur noch als Ganzzahlenwerte (z. B. 1 Byte pro Gewicht).

Für die Berechnung müssen diese Ganzzahlen wieder in FP16 konvertiert werden:
Dies geschieht, indem man die Ganzzahl mit dem Skalierungsfaktor multipliziert.
Bei asymmetrischer Quantisierung wird zusätzlich der Nullpunkt (Zero Point) berücksichtigt.

Parameter_fp = (Stufe × Skalierungsfaktor) [+ Nullpunkt bei asymmetrisch]

Durch die Quantisierung können Fehler entstehen, wenn der rekonstruierte Wert vom ursprünglichen Wert abweicht.
Je weniger Bits verwendet werden, desto höher die mögliche Abweichung.

• Mit 8 Bit spart man bereits rund 50 % Speicherplatz, in der Praxis meist mit kaum messbaren Verlusten.
• Mit 4 Bit lassen sich sogar 75 % einsparen, allerdings steigt die Wahrscheinlichkeit von Genauigkeitsverlusten.

Faustregel:

• FP16: Originalpräzision → hohe Qualität, viel Speicherbedarf
• INT8: Standard für Inferenz → kaum Qualitätsverlust, große Ersparnis
• INT4: weitere starke Ersparnis → meist noch gute Qualität (mit spezieller Quantisierung)
• INT2: extreme Kompression → Qualität stark eingeschränkt, oft kaum brauchbar

Bedeutet das nicht großen Rechenaufwand?

Ja, für jeden Parameter ist eine Multiplikation und ggf. eine Addition (bei asymmetrischer Quantisierung) nötig.
Der VRAM-Gewinn gleicht diesen Mehraufwand aber meist aus.
Außerdem unterstützen moderne GPUs, TPUs und NPUs bereits spezielle Quantisierungs-Operatoren, die diese Schritte sehr effizient ausführen.

Bekommt das ganze Netzwerk die gleiche Skalierung?

Nicht unbedingt …
In der Praxis teilt man die Parameter oft in Spalten (Channels) oder Gruppen auf und vergibt dafür getrennte Skalierungsfaktoren.
Das verbessert die Genauigkeit deutlich gegenüber einer einzigen globalen Skalierung.

Werden alle Parameter des Modells quantisiert?

Grundsätzlich ja – aber die größten Einsparungen erzielt man bei den Hauptblöcken:

1. Attention (Q, K, V, O Projektionen):
   Belegen je nach Architektur rund 20–30 % der Parameter.
2. Feed Forward Network (FFN / MLP):
   Macht rund 60–70 % der Parameter aus.

Kleinere Teile wie Embeddings oder LayerNorms sind vergleichsweise unbedeutend. Die meisten Einsparungen durch Quantisierung entstehen also im FFN und im Attention-Block.

GPTQ (Gradient Post-Training Quantization)

GPTQ ist ein Verfahren, das nach dem Training angewendet wird und die Qualität der Quantisierung deutlich verbessert.

Dabei werden die Parameter nicht alle gleich behandelt, sondern nach ihrer Wichtigkeit unterschieden.
Mit Hilfe der Hessian-Matrix (eine Ableitungsmatrix, die Sensitivität und Krümmung beschreibt) wird abgeschätzt, wie stark sich ein Quantisierungsfehler bei einem bestimmten Parameter auf die Modellqualität auswirkt.

So erhalten wichtige Parameter feinere Skalierungen, während weniger wichtige Parameter gröber quantisiert werden können.
Das ermöglicht eine effizientere Kompression, bei gleichzeitig geringerem Qualitätsverlust.

Vorteil: GPTQ erlaubt oft Quantisierungen bis 4 Bit mit nur minimalen Genauigkeitseinbußen, wodurch große Modelle auf deutlich kleineren Geräten lauffähig werden.

Der Player für dein KI-Modell: die Runtime

Jetzt haben wir den etwas trockenen Teil hinter uns und wissen, worauf es ankommt und worauf wir achten müssen.
Einen passenden Computer mit starker Grafikkarte und ausreichend VRAM haben wir uns bereits besorgt.

Nun geht es in die Praxis: Wie lassen sich multimodale Foundation Models auf Consumer-Hardware nutzen?

Bei Modellen ist es ähnlich wie bei Videos: Mit der Datei allein kann der Computer wenig anfangen – er braucht einen Player, damit etwas passiert.
Was bei Videos der Videoplayer ist, ist bei Foundation Models die LLM-Runtime.
Sie lädt das Modell und bietet uns die Schnittstelle, um damit zu interagieren – zum Beispiel in Form eines Chats.

Wie KI-Software auf die Grafikkarte zugreift

Der Zugriff einer Runtime – oder allgemein von KI-Software – auf die GPU erfolgt in mehreren Ebenen.

• Unterste Ebene: die eigentliche Hardware (GPU).
  Dafür stellt der jeweilige Hersteller passende Treiber bereit.
  Diese Treiber sind nötig, damit das Betriebssystem und die Software überhaupt mit der GPU kommunizieren können.
• Darüber: der Zugriff auf die Hardware geschieht über eine Programmierschnittstelle (API).
  Diese kann entweder
  • herstellerspezifisch sein (z. B. CUDA von NVIDIA)
  • oder auf einem offenen Standard basieren (z. B. DirectML)

Diese Schnittstellen bilden die Grundlage, auf der KI-Frameworks wie PyTorch, TensorFlow oder KI Applikationen arbeiten.

Herstellerspezifische Schnittstellen

Diese Schnittstellen sind speziell für eine bestimmte Hardware-Familie optimiert (z. B. nur für NVIDIA).
Sie funktionieren ausschließlich auf den GPUs dieses Herstellers.

• Vorteil:
  Die besonderen Fähigkeiten und Funktionen der Hardware können gezielt und sehr performant genutzt werden.
• Nachteil:
  Für jede andere Hardware-Familie muss separat programmiert werden – ein Wechsel des Herstellers ist damit schwierig.

Beispiele:

• NVIDIA: CUDA
• AMD: ROCm
• Intel: oneAPI
• Apple: Metal (MPS)

Universelle Schnittstellen

Hier stellen Konsortien oder Standardisierungsorganisationen eine gemeinsame Schnittstelle bereit, die auf Hardware vieler Hersteller lauffähig ist.

• Vorteil:
  Eine Schnittstelle funktioniert mit GPUs verschiedener Anbieter – weniger Abhängigkeit vom Hersteller.
• Nachteil:
  Spezielle Funktionen einzelner GPUs können nicht ausgereizt werden, außerdem ist der Zugriff in der Regel etwas langsamer.

Beispiele:

• OpenCL: – Khronos Group
• Vulkan Compute: – Khronos Group
• DirectML: – Microsoft

Runtimes für lokale und skalierte Nutzung

Für die verschiedenen Betriebssysteme – Linux, Windows und macOS – stehen unterschiedliche Runtimes zur Verfügung.
Aktuell sind Linux-Nutzer etwas im Vorteil, da viele Tools zuerst für Linux entwickelt und optimiert werden.
Unter Windows lassen sich viele davon jedoch ebenfalls nutzen, z. B. über das Windows Subsystem for Linux (WSL).
Auch macOS wird inzwischen gut unterstützt, insbesondere seit es Apple Silicon (M1/M2/M3) mit eigener GPU-Beschleunigung gibt.

Wichtig ist die Unterscheidung nach dem Einsatzzweck:

• Lokale Runtimes für Einzelrechner (z. B. llama.cpp)
• Server- oder Cluster-Runtimes für skalierte Nutzung (z. B. vLLM)

Lokale Runtimes

Eine lokale Runtime ist in der Regel schnell installiert und eingerichtet.
Sie ist für den Betrieb auf einem einzelnen Rechner gedacht und eignet sich besonders für kleinere Workflows, die direkt auf dieser Maschine laufen oder sich gezielt mit genau diesem Rechner verbinden.

Typische Vertreter:

• llama.cpp – leichtgewichtig, sehr portabel, läuft auf fast allen Plattformen
• Ollama – CLI-/API-orientiert, einfach in eigene Anwendungen integrierbar
• LM Studio – benutzerfreundliche Desktop-App mit GUI und Modellverwaltung

Server- oder Cluster-Runtimes (Inference Engines)

Diese Runtimes sind deutlich komplexer in der Installation und richten sich an professionelle Anwendungen mit vielen gleichzeitigen Anfragen.
Sie sind für den Einsatz auf leistungsstarker Server-Hardware gedacht, oft mit mehreren GPUs, und lassen sich sehr gut skalieren – von einzelnen Servern bis hin zu großen Clustern.
Typischerweise werden dafür Datacenter-GPUs wie die NVIDIA A100 oder H100 genutzt.

Typische Vertreter:

• vLLM (UC Berkeley) – hochoptimierte Inference Engine, u. a. mit PagedAttention
• Text Generation Inference (TGI, Hugging Face) – Serving-Framework für Produktionsumgebungen
• TensorRT-LLM (NVIDIA) – maximal optimierte Inferenz auf NVIDIA-GPUs mit Tensor Cores

Für kleinere Anwendungen bieten sich lokale Runtimes an

Grundsätzlich brauchen wir einen Motor unter der Haube, der Modelle laden und ausführen kann.
Bei den lokalen Runtimes kommt sehr häufig llama.cpp zum Einsatz.

llama.cpp

llama.cpp ist eine extrem schnelle, hardwarenahe Bibliothek, die in C/C++ mit teils Assembler-Optimierungen entwickelt wurde.
Sie ermöglicht es, große Sprachmodelle effizient auch auf Consumer-Hardware laufen zu lassen.

• Bietet Bindings für viele Programmiersprachen (z. B. Python, Go, Rust), sodass andere KI-Programme unter verschiedenen Betriebssystemen die Funktionen der Bibliothek nutzen können.
• Dieser Zugriff erfolgt über eine API (Application Programming Interface).
• Zusätzlich gibt es ein Command Line Interface (CLI), über das man direkt mit der Bibliothek arbeiten kann.

llama.cpp kann GGUF-Modelle (Generalized GGML Unified Format) laden und ausführen – auch in quantisierter Form, um Speicher und Rechenleistung zu sparen.

llama.cpp auf GitHub

Da die direkte Nutzung von llama.cpp eher technisch und für Entwickler gedacht ist, greifen viele Nutzer auf eine höhere Abstraktionsebene zurück – also auf Runtimes oder Tools, die auf llama.cpp aufbauen und eine benutzerfreundlichere Oberfläche bieten.

LM Studio

LM Studio ist eine komfortable Runtime mit klarer GUI-Ausrichtung und richtet sich vor allem an Endanwender.
Es bietet eine integrierte Modell-Liste („Model Catalog“), über die man Modelle direkt auswählen und herunterladen kann.

Inzwischen legt das Projekt auch mehr Fokus auf Entwickler:

• Es gibt ein eigenes Command Line Tool (lms), mit dem sich Modelle laden, verwalten und der API-Server steuern lassen.
• Zusätzlich stellt LM Studio eine OpenAI-kompatible REST-Schnittstelle bereit, sodass es problemlos von anderen Programmen angesteuert werden kann.

Unterstützte Formate:

• GGUF (Standard für llama.cpp-basierte Runtimes)
• MLX (speziell für Apple über die MLX-Schnittstelle)

Basis: LM Studio baut intern auf llama.cpp auf, erweitert dies aber um GUI, API und Komfortfunktionen.

LM Studio Website
LM Studio Model Catalog

Ollama

Ollama ist stärker auf Developer ausgerichtet und bietet umfangreiche Steuerungsmöglichkeiten:

• Command Line Interface (CLI) für direkte Kontrolle
• OpenAI-kompatible REST-API für die Integration in eigene Anwendungen
• SDKs (z. B. für Python, JavaScript), um Ollama von außen programmatisch zu steuern

Inzwischen richtet sich Ollama aber auch zunehmend an Endanwender – dafür gibt es z. B. einen integrierten UI-Chat-Client.

Basis: Auch Ollama nutzt unter der Haube llama.cpp als Runtime.

Unterstützte Formate:

• Eigenes Ollama-Format (Modelfile), vergleichbar mit einem Dockerfile für Modelle.
• GGUF (Standard für llama.cpp-basierte Runtimes) – kann in ein Ollama-Format „importiert“ werden.
• PyTorch (.pt / .pth) – nach Konvertierung.
• Safetensors (.safetensors) – nach Konvertierung.

Modellbibliothek:
Ollama stellt eine eigene offizielle Modellbibliothek bereit, aus der Modelle direkt per CLI heruntergeladen und gestartet werden können:

Ollama Model Library

Ollama Website
Ollama GitHub

Gängige Formate für Foundation Models

Welche Runtime passt am besten?

Die drei Runtimes unterscheiden sich zunehmend weniger in ihrem Funktionsumfang.
Am Ende ist es vor allem eine Frage der persönlichen Vorlieben:

• Wie schnell möchte ich starten?
• Wie viel Zeit und Energie will ich in Konfiguration und Feinschliff investieren?

Im nächsten Abschnitt werfen wir einen praktischen Blick auf die Ollama Runtime.

Ollama in der Praxis

In diesem Tutorial zeige ich dir die Installation und Nutzung von Ollama unter Windows.

Ollama herunterladen

Rufe die offizielle Download-Seite auf:

https://ollama.com/download

Dort wählst du dein Betriebssystem aus.

Installation

Nachdem der Download abgeschlossen ist, startest du die Installation.

• Standardinstallation (Ollama wird in den Standardordner installiert): OllamaSetup.exe
• Eigener Installationspfad (Beispiel): OllamaSetup.exe /DIR="D:DeinPfad"

Ollama starten

Die Installation ist abgeschlossen – jetzt können wir Ollama starten.
Da Ollama Command-Line-first ist, öffnen wir eine Eingabeaufforderung oder PowerShell und starten es dort:

Architektur von Ollama

Ollama hat einen hierarchischen Aufbau:

• Es basiert auf llama.cpp
• Beim Start öffnet es einen Port unter
  http://localhost:11434
• Darüber stellt es eine OpenAPI-kompatible REST-API bereit

Auf dieser Grundlage können verschiedene Clients mit Ollama kommunizieren – zum Beispiel:

• die Kommandozeile
• die Chat-Oberfläche
• externe AI-Programme oder Skripte

Ollama Modell laden

Nachdem Ollama läuft, wollen wir natürlich ein Modell starten, mit dem wir chatten können.

Modelle finden

Eine Übersicht verfügbarer Modelle findest du in der Ollama Library:
https://ollama.com/library

Modell herunterladen

Hast du ein Modell gefunden, kannst du es mit ollama pull in dein lokales Modellverzeichnis laden.
Beispiel:

ollama pull llama3.2-vision:11b-instruct-q4_K_M

Modell starten

Um mit dem Modell zu chatten, starten wir es mit ollama run:

ollama run llama3.2-vision:11b-instruct-q4_K_M

In diesem Beispiel verwende ich ein multimodales Vision-/Text-Modell (4-Bit quantisiert).
Das bedeutet: es kann sowohl Texteingaben als auch Bilder verarbeiten. Und obwohl es sich um ein sehr kleines, hochquantisiertes Modell handelt – und als Text-Vision-Modell im reinen Textverständnis nicht ganz so stark ist – liefert es bereits in deutscher Sprache beeindruckend gute Antworten.

Laufzeit-Parameter

Beim Start lassen sich zusätzliche Optionen setzen, um das Verhalten des Modells zu steuern.
Beispiel:

ollama run granite3.2-vision:latest -o temperature=0.2 -o num_ctx=4096

Hiermit werden die Parameter temperature und Kontextlänge (num_ctx) überschrieben.

Nützliche Befehle zur Modellverwaltung

• ollama list → installierte Modelle auflisten
• ollama show <modell> → Infos & Fähigkeiten eines Modells anzeigen
• ollama pull <modell> → Modell herunterladen
• ollama push <modell> → Modell hochladen
• ollama create <modell> → neues Modell anlegen
• ollama cp <quelle> <ziel> → Modell kopieren
• ollama rm <modell> → Modell löschen

Runtime-Befehle von Ollama

Neben den Modell-Management-Befehlen gibt es auch Runtime-Befehle, mit denen laufende Modelle gesteuert werden können:

• ollama stop <modell> → laufendes Modell stoppen
• ollama ps → aktuell laufende Modelle auflisten
• ollama serve → Ollama-Server ohne Modell starten

Modellquellen & Vertrauenswürdigkeit

Alle registrierten Modelle findest du hier:
https://ollama.com/library

Wichtig: Eine „echte“ zentrale Qualitätskontrolle gibt es nicht. Ollama ist eher ein Community-getriebenes Projekt.
Daher solltest du beim Download darauf achten, dass die Modelle von seriösen Uploadern stammen (z. B. direkt von Ollama selbst) und ein Modell validieren, bevor du es produktiv einsetzt.

Herkunft der Modelle

Viele Modelle werden von den Anbietern (Vendors) zunächst auf Hugging Face veröffentlicht:
https://huggingface.co/

Erst danach werden sie von der Community in die Ollama-Bibliothek übernommen.
Daher kann es manchmal etwas dauern, bis neue Modelle auch über Ollama verfügbar sind.

Modelle anpassen (Customizing)

Ollama erlaubt es, ein Modell zu customizen, sodass bestimmte Parameter oder Systemeinstellungen direkt ins Modell „eingebrannt“ werden.
Beispiel:

PARAMETER temperature 0.2
SYSTEM "Du bist ein hilfsbereiter Assistent"

Damit kannst du z. B. die Temperatur dauerhaft setzen oder ein globales System-Prompt definieren.

OpenAI-kompatible REST-API

Ollama bietet eine OpenAI-kompatible REST-API, über die sich Anfragen senden lassen – z. B. mit curl oder in einem Python-Skript.

Diese API hat sich inzwischen faktisch als Standard-Schnittstelle etabliert, um verschiedenste Sprach- und Foundation-Modelle anzusprechen.
Das bedeutet: Viele vorhandene Tools und Bibliotheken, die eigentlich für die OpenAI-API gedacht sind, lassen sich direkt mit Ollama nutzen.

API-Nutzung mit curl

Über die REST-API von Ollama lassen sich Modelle direkt ansprechen – zum Beispiel mit curl:

curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" -H "Authorization: Bearer ollama" -d "{"model":"llama3.2-vision:11b-instruct-q4_K_M","messages":[{"role":"user","content":"Welche Stadt ist die Landeshauptstadt von Vorarlberg?"}]}"

API-Nutzung mit python

#pip install openai

from openai import OpenAI

client = OpenAI(
    api_key="dummy",
    base_url="http://localhost:11434/v1"
)

resp = client.chat.completions.create(
    model="llama3.2-vision:11b-instruct-q4_K_M",
    messages=[{"role": "user", "content": "Welche Stadt ist die Landeshauptstadt von Vorarlberg?"}]
)

print(resp.choices[0].message.content)

... und wir erhalten jeweils das richige Ergebnis als json reponse: Bregenz

Environment-Variablen in Ollama

Ollama unterstützt verschiedene Environment-Variablen, mit denen sich Verhalten und Speicherorte anpassen lassen.
Hier eine kleine Auswahl (die vollständige Liste findest du in der offiziellen Dokumentation):

• OLLAMA_HOST → Server-Adresse & Port festlegen (z. B. 127.0.0.1:0815)
• OLLAMA_MODELS → Speicherort für Modell-Dateien überschreiben
• OLLAMA_DEBUG → auf 1 setzen, um zusätzliche Debug-Ausgaben zu aktivieren

Damit kannst du Ollama an deine lokale Umgebung und Workflows anpassen.

Dokumentation

Ollama ist gut dokumentiert – mit vielen Beispielen und Code-Snippets.
https://ollama.readthedocs.io/en/

Ollama GUI

Obwohl Ollama ursprünglich Command-Line-first entwickelt wurde, gibt es mittlerweile auch eine grafische Benutzeroberfläche (GUI).

Du kannst das GUI mit folgendem Befehl starten:

"ollama app.exe"

Frage im GUI: „Welche Stadt ist die Landeshauptstadt von Vorarlberg?“

Wenn du ein multimodales Modell (z. B. llama3.2-vision) verwendest, kannst du im GUI nicht nur Texteingaben machen, sondern auch Bilder hochladen.

So kannst du direkt Fragen zu einem Bild stellen – das Modell kombiniert dann Text- und Bildinformationen in seiner Antwort.

Nachdem wir ein Bild hochgeladen und eine Frage gestellt haben, liefert uns das multimodale Modell die passende Antwort.

Ollama im System-Tray

Neben der Kommandozeile und dem GUI ist Ollama nach der Installation auch im System-Tray verfügbar (Taskleiste unten rechts in Windows).

Einstellungen in Ollama

Über die Einstellungen in der Ollama-App lassen sich verschiedene Optionen anpassen.
Besonders interessant sind dabei:

• Model Location → legt fest, in welchem Verzeichnis die Modelle gespeichert werden.
• Context Length → bestimmt die Länge des Kontextfensters.
  • Je größer das Kontextfenster, desto mehr Text (oder Bildinformationen) kann das Modell gleichzeitig berücksichtigen.
  • Achtung: Ein größeres Kontextfenster benötigt auch mehr Grafikspeicher (VRAM).

Fazit

Lokale Foundation-Modelle sind längst kein Spielzeug mehr. Mit der richtigen Hardware und Runtime lassen sie sich heute effizient einsetzen – privat wie auch im Unternehmen. Sie bringen Datenschutz, Kontrolle und Kostenersparnis, erfordern aber auch technisches Know-how und klare Verantwortung.