Zum Inhalt springen
Web & Search
Zurück zum Blog

RAG für Unternehmen: Eigenes Wissen KI-durchsuchbar machen

Mit Retrieval Augmented Generation wird dein Firmenwissen zum LLM. So baust du ein System, das nicht halluziniert.

J
Jörg
Web & Search
10. November 2025
4 min Lesezeit
Teilen

Das Problem mit generischen LLMs im Unternehmenseinsatz

Claude und GPT sind brillant — aber sie wissen nicht, wie dein Kundensupport-Prozess aussieht, welche Klauseln in euren Verträgen stehen, wie eure Produktspezifikationen sind oder was euer Onboarding-Handbuch sagt. Wenn du sie danach fragst, halluzinieren sie plausibel klingende Antworten, die schlicht falsch sind. Das ist für produktiven Einsatz im Mittelstand ein No-Go — eine falsche Antwort auf eine Kundenanfrage kann echten Schaden anrichten.

Die Lösung heißt RAG: Retrieval Augmented Generation. Statt das Modell raten zu lassen, holt es die Antwort aus deinen eigenen Dokumenten. Das Modell bekommt die relevanten Passagen zur Frage mitgeliefert und muss seine Antwort daraus formulieren. Wenn es in den Dokumenten nichts findet, soll es das ehrlich sagen — kein Halluzinieren, kein Erfinden.

RAG ist 2026 der mit Abstand wichtigste KI-Use-Case im Mittelstand. Und er ist technisch nicht schwer, wenn man weiß, wie die Teile zusammenspielen. Dieser Artikel zeigt dir die komplette Architektur, den Tech-Stack und den realistischen Umsetzungsweg.

Warum RAG ein Game-Changer ist

  • Keine Halluzinationen — der Agent antwortet nur mit dem, was wirklich im Wissensbestand steht
  • Aktualität — du updatest die Wissensbasis, nicht das Modell. Änderungen sind in Sekunden live.
  • DSGVO-konform — die Daten bleiben bei dir, auf deinem Storage, in deiner EU-Region
  • Quellenangabe — der Agent zeigt, aus welchem Dokument die Antwort kommt
  • Kontrollierbar — du kannst prüfen, welche Dokumente im Kontext landen
  • Wartbar — neue Dokumente dazufügen ist ein Einzeiler

Die Architektur Schritt für Schritt

Schritt 1: Dokumente einlesen und chunken

Deine Dokumente (PDFs, Markdown, Confluence-Exports, Webseiten, E-Mails) werden in kleine Abschnitte (Chunks) geteilt. Typisch 500–1500 Zeichen pro Chunk mit etwas Überlappung. Zu große Chunks verschlechtern die Suchqualität, zu kleine verlieren Kontext.

Schritt 2: Embeddings erzeugen

Jeder Chunk wird durch ein Embedding-Modell geschickt, das ihn in einen mehrdimensionalen Vektor (meist 1024 oder 1536 Dimensionen) umwandelt. Dieser Vektor repräsentiert die semantische Bedeutung des Textes.

import OpenAI from "openai";
 
const openai = new OpenAI();
 
const { data } = await openai.embeddings.create({
  model: "text-embedding-3-small",
  input: chunk.text,
});
 
const embedding = data[0].embedding;

Schritt 3: In einer Vektor-Datenbank speichern

Die Embeddings landen in einer Vektor-DB. Für die meisten Projekte empfehle ich Supabase mit pgvector — du hast Postgres für alle anderen Daten und bekommst die Vektor-Suche gratis dazu. Alternative: Pinecone, Weaviate, Qdrant.

create table documents (
  id uuid primary key default gen_random_uuid(),
  content text,
  metadata jsonb,
  embedding vector(1536)
);
 
create index on documents
  using ivfflat (embedding vector_cosine_ops)
  with (lists = 100);

Schritt 4: Suche bei einer Anfrage

Wenn ein Nutzer eine Frage stellt, wird die Frage ebenfalls in ein Embedding umgewandelt. Dann sucht die DB die semantisch ähnlichsten Chunks aus dem Wissensbestand — meist die Top 5 bis Top 10.

create function match_documents (
  query_embedding vector(1536),
  match_count int
)
returns table (id uuid, content text, similarity float)
as $$
  select
    id,
    content,
    1 - (embedding <=> query_embedding) as similarity
  from documents
  order by embedding <=> query_embedding
  limit match_count;
$$ language sql stable;

Schritt 5: Antwort mit dem LLM generieren

Die gefundenen Chunks gehen zusammen mit der Frage an Claude oder GPT. Der System-Prompt ist entscheidend — er muss das Modell zwingen, nur aus dem gegebenen Kontext zu antworten und nichts zu erfinden.

const systemPrompt = `Du bist ein Support-Assistent. Beantworte die Frage
ausschließlich basierend auf dem folgenden Kontext. Wenn die Antwort nicht
im Kontext steht, sage ehrlich: "Das kann ich aus den mir verfügbaren
Dokumenten nicht beantworten." Erfinde nichts.
 
Kontext:
${relevantChunks.map(c => c.content).join("\n---\n")}
`;
 
const response = await anthropic.messages.create({
  model: "claude-sonnet-4-5",
  system: systemPrompt,
  messages: [{ role: "user", content: userQuestion }],
});

Schritt 6: Quelle mit ausgeben

Die gefundenen Chunks enthalten in den Metadaten den Verweis auf das Originaldokument. Die finale Antwort kann also zeigen: "Quelle: Handbuch XY, Kapitel 3.2". Das schafft Vertrauen und macht das System auditierbar.

Mein Standard-Tech-Stack für RAG-Projekte

  • Supabase + pgvector für die Vektor-DB
  • OpenAI text-embedding-3-small für Embeddings (günstig und stark)
  • Claude Sonnet 4.6 für die Antwortgenerierung (beste Instruction-Following)
  • Next.js Edge Functions als API-Schicht
  • Unstructured.io oder llama-parse für saubere PDF-Extraktion
  • Langchain oder LlamaIndex als Orchestrierung (optional)

Für Self-Hosting ohne OpenAI: bge-m3 als Embedding-Modell via Ollama, Llama 3.1 70B oder Qwen 2.5 als Generator.

Typische Use Cases im Mittelstand

  • Kundensupport-Bot, der Produktwissen durchsucht
  • Internes Wiki als Chat — Mitarbeiter finden Antworten, ohne zu suchen
  • Onboarding-Assistent für neue Mitarbeiter
  • Vertragsdurchsuche — "Welche unserer Verträge enthalten Klausel X?"
  • Compliance-Check — "Was sagt unsere Richtlinie zu Fall Y?"
  • Produkthandbuch-Chat für Endkunden
  • Legal-Review von eingehenden Verträgen

Die wichtigsten Fallstricke

  1. Chunk-Größe falsch gewählt → Qualität miserabel
  2. Kein Metadaten-Filter → Suche findet irrelevante Dokumente
  3. System-Prompt zu weich → Modell halluziniert trotzdem
  4. Re-Ranking vergessen → Top-5 hat nicht die besten Treffer
  5. Keine Aktualisierungs-Strategie → Wissen veraltet
  6. Keine Evaluation → niemand weiß, ob es wirklich funktioniert

Realistischer Aufwand

Ein produktives RAG-System für kleine Wissensbestände (bis 500 Dokumente) ist in 2–3 Wochen umsetzbar:

  • Woche 1: Architektur, Dokumenten-Pipeline, Embeddings, Datenbank
  • Woche 2: Retrieval-Tuning, System-Prompt, Chat-Interface
  • Woche 3: Evaluation, Fine-Tuning, Produktiv-Rollout

Budget: typisch 6–15k € für ein erstes produktives System, inklusive Integration in eure bestehenden Tools (Slack, Teams, Interne Chat-UIs).

Mein Angebot

Wenn du einen konkreten RAG-Use-Case hast, aber nicht weißt, wo du anfangen sollst: Ich baue gerne einen 2-Wochen-Proof-of-Concept, mit dem du bei echten Fragen die Qualität testen kannst. So siehst du sofort, ob RAG für euch funktioniert, bevor du in die Vollversion investierst.

J

Über den Autor

Jörg · Web & Search

Seit 1998 in IT, Web & SEO — in Emlichheim, für die Grafschaft Bentheim.

1