KI-Integration, Lokale Modelle & RAG-Systeme

Von der Cloud-API bis zum lokal laufenden Sprachmodell – KI wird dann produktiv, wenn sie sauber in bestehende Prozesse eingebunden ist. kommklick unterstützt Unternehmen im Raum Kiel und Schleswig-Holstein bei Architektur, Umsetzung und Betrieb. In Kombination mit Prompt Engineering und Browser-Automatisierung entsteht ein vollständiger Automatisierungsstack.

Cloud-KI-APIs professionell einbinden

OpenAI, Anthropic (Claude), Google (Gemini) und andere Anbieter stellen ihre Sprachmodelle über REST-APIs bereit. Was einfach klingt, hat in Produktionsumgebungen erhebliche Komplexität: Authentifizierung, Rate-Limiting, Token-Budgets, Fehlerbehandlung, Retry-Logik, Streaming-Responses, Kontext-Fenster-Management und Kosten-Monitoring sind Aspekte, die in einem stabilen System alle berücksichtigt werden müssen.

Die wichtigsten Modelle im Vergleich

  • GPT-4o (OpenAI): Stärkste allgemeine Sprachverarbeitung, hervorragend für Structured Output (JSON-Mode, Function Calling), sehr gute Code-Erzeugung
  • Claude 3.5 Sonnet / Opus (Anthropic): Lange Kontextfenster (200k Token), präzise Anweisungsfolge, stark in Dokumentenanalyse und strukturiertem Denken
  • Gemini 1.5 Pro (Google): Native Multimodalität, gut für Bild-Text-Kombinationen, tiefe Integration in Google-Ökosysteme
  • GPT-4o-mini / Claude Haiku: Günstige Modelle für einfache Klassifikations- und Extraktionsaufgaben – oft ausreichend bei einem Bruchteil der Kosten

Was eine produktionstaugliche API-Integration leisten muss

  • Anbieter-Abstraktion: Der Anwendungscode ist nicht hart an einen Anbieter gebunden – ein Adapter-Layer erlaubt den Wechsel zwischen Cloud und lokalem Modell ohne Änderung der Geschäftslogik
  • Fallback-Strategien: Wenn die primäre Cloud-API nicht verfügbar ist, greift das System automatisch auf ein Backup-Modell zurück
  • Kosten-Kontrolle: Token werden gezählt, Limits konfiguriert; teure Modelle nur für Aufgaben, die sie wirklich brauchen
  • Vollständiges Logging: Jede Anfrage und Antwort wird protokolliert – für Debugging, Compliance und Prompt-Optimierung
Praxisfall: Ein mittelständisches Unternehmen aus Schleswig-Holstein ließ täglich 80 Support-E-Mails manuell klassifizieren und priorisieren – zwei Vollzeit-Stunden täglich. Eine Node.js-Integration mit der OpenAI-API übernimmt Klassifikation, Priorisierung und Routing vollautomatisch. GPT-4o-mini für einfache Fälle (95%), GPT-4o für komplexe Eskalationen (5%). Gesamtkosten der KI: unter 15 Euro im Monat. Mehr zur Prompt-Architektur dahinter unter Prompt Engineering.

Lokale Modelle: Datenschutz, Kontrolle, keine Cloud-Kosten

Für viele Unternehmensanwendungen ist die Cloud keine Option – nicht wegen Leistung, sondern wegen Datenschutz. Personenbezogene Daten, Vertragsunterlagen, Gesundheitsinformationen, interne Strategiedokumente: All das darf nicht ohne Weiteres an US-amerikanische Cloud-Server gesendet werden. Lokale Sprachmodelle lösen dieses Problem.

Werkzeuge für lokalen Betrieb

  • Ollama: Einfachste Möglichkeit, Modelle lokal zu betreiben. OpenAI-kompatible API auf localhost – dieselben Client-Libraries, nur der Endpunkt ändert sich
  • LM Studio: GUI-basierter lokaler Modell-Server, gut für Einzelplatz-Tests und Entwicklung
  • llama.cpp mit GGUF-Modellen: Direkter Betrieb quantisierter Modelle, maximale Kontrolle, läuft auch auf CPU-Hardware
  • Verfügbare Modelle: Llama 3, Mistral, Phi-3, Qwen 2 – je nach Aufgabe und verfügbarer Hardware auswählbar

Hardware-Anforderungen realistisch einschätzen

Lokale Modelle laufen auf normaler Server- und Consumer-Hardware – aber die Leistung hängt stark von RAM und GPU ab. Für Unternehmenseinsatz empfehle ich eine realistische Evaluation: Ein 7B-Modell (z. B. Mistral 7B) läuft flüssig auf einem modernen Workstation-PC mit 16 GB RAM. Für anspruchsvollere Aufgaben und kürzere Antwortzeiten ist eine Nvidia-GPU mit mindestens 8 GB VRAM sinnvoll. Ich begleite diese Evaluierung und empfehle keine unnötige Hardware.

DSGVO-Hinweis: Lokale Modelle allein lösen noch kein Datenschutzproblem – entscheidend ist, wo die Daten verarbeitet werden und wie sie gespeichert werden. Ich analysiere den Verarbeitungsprozess vollständig: Welche Daten fließen in den Prompt? Werden Ergebnisse gespeichert? Ist ein Verarbeitungsverzeichniseintrag nötig?

RAG – Retrieval Augmented Generation: Ihre Dokumente, intelligent abrufbar

Das verbreitetste Missverständnis über Sprachmodelle: Man könne ihnen Unternehmensdokumente "beibringen". Sprachmodelle lernen nicht on-the-fly – ihr Wissen ist beim Training eingefroren. RAG (Retrieval Augmented Generation) ist die Lösung: Dokumente werden in einer Vektordatenbank indexiert. Bei jeder Frage sucht das System zuerst die relevantesten Textabschnitte und fügt sie als Kontext in den Prompt ein. Das Modell antwortet auf Basis dieses dynamisch zusammengestellten Kontexts – korrekt, quellengebunden, aktuell.

Die Architektur eines RAG-Systems

  • Dokumenten-Parsing: PDFs, Word-Dokumente, HTML, Datenbankinhalte, eingescannte Bilder (per OCR) werden in Rohtext umgewandelt
  • Chunking: Der Text wird in sinnvolle Abschnitte aufgeteilt – mit Überlappung, damit Kontext an Chunk-Grenzen nicht verloren geht
  • Embedding: Jeder Abschnitt wird durch ein Embedding-Modell in einen Vektor umgewandelt, der semantische Ähnlichkeit messbar macht
  • Vektordatenbank: Die Vektoren werden in ChromaDB, pgvector (PostgreSQL-Extension) oder Qdrant gespeichert und indiziert
  • Retrieval: Eine Nutzeranfrage wird ebenfalls eingebettet; die ähnlichsten Chunks werden per Nearest-Neighbor-Suche gefunden
  • Reranking: Optionaler zweiter Schritt: ein Cross-Encoder bewertet die Chunks neu und sortiert nach tatsächlicher Relevanz
  • Generierung: Das Sprachmodell erhält Frage + Kontext-Chunks und antwortet mit Quellenangabe
Praxisfall – Technisches Handbuch-System: 15.000 Seiten technische Dokumentation (Wartungshandbücher, Ersatzteilkataloge, Sicherheitsvorschriften) wurden in einem lokalen RAG-System indexiert. Techniker im Außendienst fragen auf Deutsch per Chat-Oberfläche; das System antwortet in Sekunden mit der korrekten Antwort, Seitenangabe und Handbuch als Quelle. Betrieb auf einem lokalen Server – funktioniert auch ohne Internetzugang per VPN. Kein Cloud-Dienst, keine laufenden API-Kosten.

Was ein gutes RAG-System von einem schlechten unterscheidet

Viele RAG-Implementierungen scheitern nicht an der Technologie, sondern an schlechtem Chunking, falscher Embedding-Modellwahl oder fehlender Halluzinationskontrolle. Ich baue RAG-Systeme mit: semantisch sinnvollem Chunking (keine willkürlichen Zeichengrenzen), mehrsprachigen Embedding-Modellen wo nötig, Metadaten-Filterung für Teilmengen-Suche, und Prompts, die das Modell zwingen, nur auf Basis der gefundenen Quellen zu antworten.

Wissensextraktion und Datenbankintegration

RAG ist eine Form der Wissensextraktion – aber nicht für alle Datenquellen die beste. Je nach Struktur der Daten kommen unterschiedliche Techniken zum Einsatz:

Text-to-SQL: Datenbankabfragen in natürlicher Sprache

Für strukturierte Daten in Datenbanken ist Text-to-SQL oft effektiver als RAG. Das Sprachmodell erhält das Datenbankschema als Kontext und übersetzt natürlichsprachliche Fragen in SQL-Abfragen. "Welche Maschinen hatten im letzten Quartal mehr als drei Stunden Stillstand pro Woche?" wird zu einem korrekten SELECT mit GROUP BY, HAVING und Datumsberechnung. Das Ergebnis wird als Tabelle ausgegeben oder weiterverarbeitet – ohne dass der Fragesteller SQL kennen muss. Ich bringe jahrzehntelange SQL-Erfahrung (MySQL/MariaDB, Oracle, PostgreSQL, MS SQL) mit, die für zuverlässige Text-to-SQL-Systeme entscheidend ist.

  • Datenbankschema-Dokumentation als Modell-Kontext aufbereiten
  • Schema-Filterung: Modell sieht nur relevante Tabellen für die jeweilige Anfrage
  • SQL-Validierung vor Ausführung: Syntaxprüfung und Sicherheitsfilter gegen Injection
  • Ergebnis-Nachbereitung: Zahlen in lesbare Texte übersetzen, Diagramme generieren

OCR und Dokumentenverarbeitung

Eingescannte Dokumente sind für Sprachmodelle zunächst unlesbar. OCR (Tesseract, PaddleOCR) macht sie maschinenlesbar; anschließend sorgen Layout-Analyse-Tools (LayoutParser, Unstructured.io) dafür, dass Tabellen, Kopfzeilen und Abschnitte korrekt erkannt und getrennt verarbeitet werden. Ich habe Erfahrung mit historischen Dokumenten, mehrsprachigen Texten und schlechter Scanqualität.

Praxisfall – Jahresbericht-Extraktion: Finanzkennzahlen (EBITDA, Umsatz, Eigenkapitalquote, Mitarbeiterzahl) aus PDFs verschiedener Unternehmen automatisch extrahieren. PDFs mit unterschiedlichen Layouts, teils eingescannt. Pipeline: PyMuPDF-Parsing → relevante Seiten per Keyword-Filterung vorauswählen → strukturierter Extraktions-Prompt mit JSON-Schema. Claude Haiku für einfache Kennzahlen, Sonnet für komplexe Interpretationen. Kosten pro Bericht: unter 0,05 Euro. Manuelle Bearbeitungszeit vorher: 2–3 Stunden.

Technischer Stack

  • Embedding-Modelle: sentence-transformers, OpenAI text-embedding-3, Nomic Embed (lokal)
  • Vektordatenbanken: ChromaDB (eingebettet/lokal), pgvector, Qdrant
  • Frameworks: LangChain, LlamaIndex – oder schlanke eigene Implementierungen ohne Overhead
  • Dokumenten-Parsing: PyMuPDF, python-docx, Unstructured.io, Tesseract OCR
  • Backend: Node.js/Express oder Python/FastAPI je nach Anforderung
Halluzinations-Kontrolle nicht vergessen: Ohne explizite Prompt-Instruktionen neigen Sprachmodelle dazu, bei unklaren Quellen zu raten statt "keine Information gefunden" zurückzugeben. Ich konfiguriere System-Prompts und Temperatur-Parameter so, dass Quellengebundenheit erzwungen wird. Wie das im Prompt funktioniert, beschreibt die Seite Prompt Engineering im Detail.

Weiterführende Themen