Back to "Warum die meisten kommerziellen "KI"-Projekte Dumb sind"

This is a viewer only at the moment see the article on how this works.

To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk

# Warum die meisten kommerziellen "KI"-Projekte Dumb sind

<datetime class="hidden">2025-11-26T09:00</datetime>

> "Wir bauen einen KI-gestützten Wissensassistenten auf, der revolutionieren wird, wie unsere Mitarbeiter auf Informationen zugreifen..."
> — Jede Stellenanzeige, Pitch Deck und Beratungsvorschlag in 2024-2025

## Einleitung

Ich habe den letzten Monat oder so richtig verbracht, mich in den kommerziellen KI-Raum einzutauchen. Lesen Sie reichliche Mengen von Marketing-Bumf. Pored über Dutzende von Stellenanzeigen. Sat durch mehr Produkt-Demos als ich gerne zugeben. Und ich bin zu einem eher deprimierenden Schluss gekommen.

**Es ist fast alles dasselbe.**

"AI-powered Unternehmen Knowledge Base." "Intelligente Dokumentensuche." "Kunden-Chatbot mit Enterprise-Wissen." Entfernen Sie die atemlose Marketing-Kopie und Sie werden die gleiche Architektur, die gleichen Failure-Modi, und die gleichen enttäuschten Stakeholder etwa sechs Monate hinter der Linie zu finden.

Die Kunden-Chatbot-Varianten sind besonders unterhaltsam – sie können PR-Katastrophen bemerkenswert schnell werden, wenn Entwickler, die Geländer nicht verstehen, sie in der Öffentlichkeit loslassen. Nichts ganz wie Ihre Unterstützung Bot fröhlich bieten Rückerstattungen, die Sie nicht geben, Make-up-Produkt-Features, die nicht existieren, oder gehen auf eine philosophische Tangente über die Bedeutung der Existenz, wenn jemand fragt nach Lieferzeiten. Ohne ordnungsgemäße Einschränkungen, diese Bots werden glücklich versprechen, etwas, zu Verbrechen, die Ihr Unternehmen nicht begangen, oder entwickeln starke Meinungen über Konkurrenten. Das kanonische Beispiel bleibt Air Canada Chatbot zuversichtlich erfinden eine Trauerpolitik, die nicht existierte – und das Unternehmen gehalten, um es vor Gericht.

Hier ist das schmutzige Geheimnis, das niemand im Management hören will: **Die meisten kommerziellen KI-Projekte sind nicht innovativ.**

Bevor ich weiter gehe, ein Haftungsausschluss: Ich bin kein "KI-Visionär" oder was auch immer der hype-getriebene Titel des Augenblicks ist (meist ehemalige "Blockchain Visionäre", die bequem schwenkten). Ich bin ein Software-Ingenieur, der diese Art von Systemen – Suche, Wissensmanagement, natürliche Sprachverarbeitung, Entscheidungsunterstützung – für fast drei Jahrzehnte aufgebaut hat. Ich habe dieses Bild vorher mit Expertensystemen, mit semantischem Web, mit Big Data, mit Blockchain gesehen.

[TOC]

## Die beiden Arten von kommerziellen KI-Projekten

Entfernen Sie die Marketing-Blöcke und Sie werden feststellen, dass etwa 95% der kommerziellen "AI"-Projekte in eine von zwei Kategorien fallen:

### Typ 1: Die RAG-Pipeline

Dies ist bei weitem die häufigste. Jede "Unternehmens-KI-Lösung" folgt diesem Muster:

```mermaid
flowchart LR
    A[Documents] --> B[Document Ingestion Pipeline]
    B --> C[Vector Database / RAG]
    C --> D[Construct Prompts]
    D --> E[LLM API Call]
    E --> F[Hybrid Search]
    F --> G[Response to User]

style B stroke:#ff0000,stroke-width:4px
```

Das rote Kästchen ist da, wo alles kaputt geht, mehr dazu in einem Moment.

Die Tonhöhe klingt beeindruckend: "Wir haben eine KI gebaut, die die Dokumente Ihres Unternehmens versteht und Fragen intelligent beantworten kann!"

Die Realität: Sie haben eine Suchmaschine mit zusätzlichen Schritten und einem £ 10.000 / Monat OpenAI Rechnung gebaut.

### Typ 2: Das Modell mit Feinsteuerung

Das hier ist noch zierlicher. Der Pitch: "Wir haben unser eigenes KI-Modell speziell für Ihre Branche trainiert!"

Die Realität: Sie haben das Modell eines anderen genommen und es auf einen Datensatz fein abgestimmt, der wahrscheinlich zu klein, zu schmutzig und zu eng ist, um einen sinnvollen Unterschied zu machen, wenn Sie das Basismodell mit guten Eingaben verwenden.

```mermaid
flowchart TD
    A[Existing LLM] --> B[Collect Training Data]
    B --> C[Clean Data - Maybe]
    C --> D[Fine-tune Model]
    D --> E[Deploy Model]
    E --> F[Discover it's not much better than base model]
    F --> G[Keep paying for inference anyway]
    G --> H[Hope nobody notices]
```

Die meisten Feinabstimmungs-Projekte, die ich gesehen habe, wären besser gewesen, indem sie das gleiche Geld für die Verbesserung ihrer Aufforderungen und Retrieval-Systeme ausgegeben hätten.

## Warum die Dokumentaufnahme dahin geht, wo Träume sterben

Reden wir über das rote Kästchen im RAG-Diagramm. **Dokumentaufnahme ist der Teil, der am häufigsten versagt**, und es ist der Teil, der die geringste Aufmerksamkeit in den auffälligen Demos bekommt.

Hier ist, was die Verkaufsdemo zeigt:

- Schöne PDFs, die in das System fließen
- Clean Markdown perfekt extrahiert
- All Ihr Wissen, durchsuchbar mit KI!

Hier ist, was tatsächlich passiert:

### Das PDF-Problem

PDFs sind ein Alptraum. Sie wurden zum Drucken entwickelt, nicht zum Extrahieren strukturierter Daten. Jeder PDF-Parser, den ich benutzt habe, hat verschiedene Ausfallmodi:

- Spalten, die falsch zusammengeführt werden
- Tische, die zu Kauderwelsch werden
- Kopf- und Fußzeilen, die den Inhalt verschmutzen
- Gescannte Dokumente, die OCR benötigen (und OCR hat seine eigenen Fehlerraten)
- Sicherheitsgeschützte Dokumente, die überhaupt nicht verarbeitet werden können
- Font-Encoding-Probleme, die Text in Müll verwandeln

Und das sind nur PDFs. Warten Sie, bis Sie treffen:

- PowerPoint-Dateien mit Text in SmartArt
- Word-Dokumente mit Track-Änderungen
- Excel-Dateien mit zusammengeführten Zellen
- Gescannte Bilder mit Handschrift
- Legacy-Formate von Systemen, die in den 90er Jahren starben

### Die verheerende Katastrophe

Sobald Sie Text extrahiert haben (schlecht), müssen Sie es für Ihre Vektor-Datenbank broken. Dies ist, wo mehr magisches Denken geschieht.

"Wir werden semantische Brocken verwenden!" Großartig, dein 200-Seiten-Vertrag ist jetzt 500 Brocken, und die KI hat keine Ahnung, welche in welcher Reihenfolge sie verwandt sind.

"Wir werden feste Stücke mit Überlappung verwenden!" Perfekt, Sie haben gerade einen Satz in der Hälfte geteilt und die Einbettung stellt jetzt Unsinn dar.

```mermaid
flowchart TD
    A[Original Document] --> B[Chunk 1: This contract shall be governed by]
    A --> C[Chunk 2: the laws of the State of California]
    B --> D[Embedding: Legal stuff?]
    C --> E[Embedding: Geography?]
    D --> F[User asks about jurisdiction]
    E --> F
    F --> G[AI: Based on my knowledge, possibly California, or maybe legal governance, who knows]
```

### Die Metadaten-Messung

Gute RAG braucht gute Metadaten. Aber das Extrahieren von Metadaten aus Dokumenten ist schwierig:

- Was ist das Dokument Datum? Ist es das Erstellungsdatum, das Änderungsdatum oder das Datum, das im Inhalt erwähnt wird?
- Wer ist der Autor? Die Person, die die Akte erstellt hat, der Rechtsautor oder der Sachexperte?
- Zu welcher Kategorie gehört sie? Ihre Taxonomie stimmt wahrscheinlich nicht mit der Art überein, wie die Dokumente tatsächlich organisiert wurden.
- Ist dieses Dokument noch gültig? Oder wurde es durch etwas neueres ersetzt, von dem Ihr System nichts weiß?

Die meisten Organisationen haben jahrzehntelange Dokumente mit inkonsequenten Namenskonventionen, Ordnerstrukturen, die für jemanden Sinn machten, der 2003 ging, und Metadaten, die entweder fehlen oder falsch sind.

## Die Fantasie des Feintuning

Lassen Sie mich klar sagen: Feinabstimmung hat ihren Platz. Aber die Art und Weise, wie die meisten Unternehmen an sie herangehen, ist grundlegend gebrochen.

### Das Datenproblem

Feinabstimmung erfordert qualitativ hochwertige Trainingsdaten. Die meisten Unternehmen haben es nicht. Sie haben:

- Lärmige, inkonsistente Daten, die über Systeme verteilt sind
- Daten, die zeigen, wie die Dinge gemacht wurden, nicht wie sie gemacht werden sollten
- Daten, die voller Fehler sind, die niemand reparieren wollte
- Daten, die proprietär sind, aber nicht wirklich so wertvoll

"Wir werden auf unsere Support-Tickets abstimmen!" Ihre Support-Tickets sind voll von frustrierten Kunden, falschen Informationen von Junior-Mitarbeitern und Randfälle, die keine normale Nutzung darstellen.

"Wir werden Feinabstimmung auf unsere Verkaufsanrufe!" Sie meinen diejenigen, wo Verkäufer Versprechen machen, die das Produkt nicht halten kann?

### Das Bewertungsproblem

Woher wissen Sie, ob Ihr fein abgestimmtes Modell tatsächlich besser ist? Die meisten Unternehmen können das nicht beantworten, weil:

- Sie haben keinen guten Benchmark-Datensatz
- Sie haben keine klaren Bewertungsmetriken
- Sie haben keine rigorosen A/B-Tests gemacht.
- Sie vergleichen Vibes, keine Daten

Ich habe gesehen, Unternehmen verbringen sechs Monate Feinabstimmung ein Modell und dann haben keine Möglichkeit, zu beweisen, es ist besser als nur mit GPT-4 mit einem guten System-Prompt.

### Das Wartungsproblem

Feinabgestimmte Modelle müssen aktualisiert werden. Ihr Geschäft ändert sich. Ihre Produkte ändern sich. Ihre Prozesse ändern sich. Das Modell, das Sie im Januar feinabgestimmt haben, gibt jetzt Antworten auf veraltete Informationen.

Aktualisierung bedeutet jedoch:

- Neue Trainingsdaten sammeln
- Das Training wieder laufen lassen
- Validierung des neuen Modells
- Einsatz
- Ich hoffe, du hast keine Regressionen eingeführt.

Die meisten Unternehmen Feinabstimmung einmal und dann nur leben mit der Drift. Das Modell wird langsam weniger relevant, während jeder vorgibt, es ist immer noch Mehrwert.

## Welche "KI"-Projekte eigentlich gut sind

Versteh mich nicht falsch.

```mermaid
flowchart TD
    subgraph RAGWorks["✅ RAG Works When"]
        R1[Well-structured docs]
        R2[Clear metadata]
        R3[Search + synthesis use case]
        R4[Heavy ingestion investment]
        R5[Feedback loops exist]
    end

subgraph FTWorks["✅ Fine-Tuning Works When"]
        F1[Large high-quality dataset]
        F2[Base model truly struggles]
        F3[Ongoing maintenance budget]
        F4[Clear eval metrics]
        F5[Already tried prompting + RAG]
    end

style R4 stroke:#00aa00,stroke-width:2px
    style F5 stroke:#00aa00,stroke-width:2px
```

Die Green Boxen sind die Voraussetzungen, die die meisten Projekte überspringen. **"Wir haben bereits Prompting und RAG optimiert"** ist die Bar für Feinabstimmung. **"Schwere Ingestionsinvestitionen"** ist die Bar für RAG. Überspringen Sie diese und Sie bauen auf Sand.

## Die wirklichen Probleme, die niemand löst

Während jeder die gleiche RAG-Pipeline baut, werden die eigentlich interessanten Probleme in der kommerziellen KI ignoriert:

### Datenqualität

Die größte Einschränkung der KI-Wirksamkeit ist nicht das Modell. Es sind die Daten. Die meisten Organisationen haben:

- Daten verteilen sich auf Dutzende von Systemen, die nicht miteinander sprechen
- Keine einzige Quelle der Wahrheit für irgendetwas
- Daten-Governance, das ist mehr Aspiration als Realität
- Qualitätsfragen, die niemand mit Budget zu beheben hat

**Aber "Datenqualitätsinitiative" bekommt keinen Forbes-Artikel wie "AI Transformation".**

### Prozessintegration

Ein KI-Chatbot in einen bestehenden Prozess zu werfen, macht ihn nicht auf magische Weise besser. Der Prozess muss um die Fähigkeiten und Grenzen der KI neu gestaltet werden. Die meisten Unternehmen schrauben KI einfach auf gebrochene Prozesse und fragen sich, warum es nicht hilft.

### Mensch-AI-Zusammenarbeit

Die besten KI-Implementierungen erhöhen die menschlichen Fähigkeiten, anstatt sie zu ersetzen. Aber das ist schwieriger zu verkaufen als "KI, die X automatisch tut!"

Menschen + KI-Zusammenarbeit erfordert:

- Klare Übergabepunkte
- Transparente KI-Überlegung
- Einfache Überbrückungsmechanismen
- Feedback-Schleifen zur Verbesserung

Die meisten kommerziellen KI-Projekte behandeln den Menschen als Nachdenklichkeit.

### Echte Innovation

Die wirklich wertvollen KI-Anwendungen sind nicht "Chatbot auf Ihren Dokumenten." Sie sind Anwendungen, die:

- Dinge aktivieren, die bisher unmöglich waren
- Neue Wertekategorien erstellen
- Probleme auf grundlegend neue Weise lösen

Aber die sind hart. RAG-Pipelines sind einfach (gut, einfacher). Also das ist es, was jeder baut.

## Der beratende Industriekomplex

Ein wichtiger Treiber von dummen KI-Projekten ist das Beratungsökosystem:

```mermaid
flowchart TD
    A[Big Consultancy Tells C-Suite: You Need AI!] --> B[C-Suite Panics]
    B --> C[Consultancy Deploys Army of Juniors]
    C --> D[Recommendations: RAG + Fine-Tuning]
    D --> E[Build Same Thing as Last 20 Clients]
    E --> F[Demo Goes Well]
    F --> G[Reality: Real Data Breaks Everything]
    G --> H[Consultancy Moves On]
    H --> I[Internal Team Struggles]
    I --> J[Project Quietly Fails]
    J --> K[Nobody Admits It]
    K --> A

style G stroke:#ff0000,stroke-width:3px
    style J stroke:#ff0000,stroke-width:3px
```

<img src="https://media1.tenor.com/m/r53R8b0im3kAAAAd/hasbulla.gif" height="250"/>
Ich habe dieses Muster Dutzende Male gesehen. Die Beratung wird bezahlt. Die Führungskräfte bekommen zu sagen, sie "hatten KI." Die Ingenieure erhalten stecken bei etwas, das kaum funktioniert. Und das eigentliche Geschäft Problem bleibt ungelöst.

## Die VC-getriebene KI-Voraussetzung

Startups fallen in eine etwas andere Falle. Es sind keine Beratungsstellen, die die Dysfunktion treiben – es ist die Finanzierungsumgebung.

```mermaid
timeline
    title Technology Requirements for VC Funding
    2005 : Web 2.0 - "You need social features"
    2010 : Mobile - "You need an app"
    2015 : Cloud - "You need to be cloud-native"
    2018 : Blockchain - "You need a token"
    2023 : AI - "You need an AI strategy"
```

Klingt vertraut? Alle paar Jahre gibt es eine neue Technologie, die VCs entscheiden ist wichtig. Wenn Ihr Pitch Deck nicht erwähnt es prominent, Sie werden nicht finanziert. Die Technologie könnte irrelevant für Ihr tatsächliches Produkt sein - spielt keine Rolle. Sie brauchen das Schlagwort.

Ich habe gesehen, wie das mit Blockchain 2017-2018 passierte. Unternehmen, die kein Geschäft mit Blockchain hatten, waren Schuhhorn-Token in ihre Produkte, weil das die Finanzierung bekam. Die meisten dieser Blockchain-Features verschwanden ruhig, sobald das Geld gesichert war.

**Jetzt passiert es mit AI.**

Startups verschrauben LLM-Features auf Produkte, die sie nicht brauchen, weil:

- Investoren schauen nicht auf Decks ohne "AI" erwähnt
- Die Bewertungen sind 3-5x höher für "AI-Unternehmen"
- Die Presse berichtet nur über KI-Geschichten
- "KI-powered" ist Tischeinsatz für das Marketing

Das Ergebnis? Produkte mit unangenehmen KI-Features, die Benutzer ignorieren. Verbrannte Start- und Landebahn auf Feinsteuerungsexperimenten, die nirgendwohin gehen. Engineering-Zeit verschwendet auf RAG-Systemen, wenn eine einfache Datenbankabfrage besser funktionieren würde.

**Das Schlimmste:** Viele Gründer wissen, dass dies albern ist. Sie bauen KI-Features, an die sie nicht glauben, weil sie lange genug überleben müssen, um zu bauen, was ihnen eigentlich wichtig ist.

Wenn Sie ein Startup-Gründer sind, der KI hinzufügen soll, fragen Sie sich:

- Verbessert KI wirklich das Kernwertangebot meines Produktes?
- Oder checke ich nur ein Kästchen für Investoren?

Wenn es das letztere ist, bauen Sie die minimale lebensfähige KI-Funktion, die das Kästchen tickt, dann konzentrieren Sie sich auf das, was wirklich zählt. Lassen Sie sich nicht von der Finanzierungsumgebung ablenken, etwas Wertvolles zu bauen.

## Der Hype-Industriekomplex

Hier ist die unbequeme Wahrheit, die niemand in KI diskutieren will: **Fast jeder im Ökosystem hat einen finanziellen Anreiz, den Hype am Laufen zu halten.**

```mermaid
flowchart TD
    subgraph Researchers["🔬 Frontier Labs"]
        R1[Need billions for compute]
        R2[Must show progress to justify spend]
        R3[Hype generates investment]
    end

subgraph Companies["🏢 Tech Companies"]
        C1[Need AI angle for valuation]
        C2[Must justify AI team costs]
        C3[Hype drives stock price]
    end

subgraph Investors["💰 Financial Backers"]
        I1[Massive capital deployed]
        I2[Need exits and returns]
        I3[Hype maintains valuations]
    end

subgraph Media["📰 Tech Media"]
        M1[AI stories get clicks]
        M2[Access depends on positive coverage]
        M3[Hype drives engagement]
    end

R3 --> I1
    C3 --> I1
    I3 --> R1
    I3 --> C1
    M3 --> R3
    M3 --> C3
```

**Die Forscher** Das Geld kommt von Investoren und Big Tech. Um diese Ausgaben zu rechtfertigen, müssen sie Fortschritte demonstrieren – und "Fortschritt" wird in atemlose Ankündigungen über Fähigkeiten übersetzt, die in praktischen Anwendungen materialisieren können oder nicht. Wenn der Hype stirbt, trocknet die Finanzierung aus.

**Die Unternehmen** (sowohl die KI-Labore als auch alle, die KI nutzen) müssen die Erzählung fortsetzen. OpenAIs Bewertung hängt von der Überzeugung ab, dass AGI um die Ecke ist. Jedes "KI-powered"-Startup-Multiple hängt davon ab, dass KI den heißen Sektor bleibt.

**Die Investoren** Sie brauchen Ausstiege. Sie brauchen die Musik, um lange genug zu spielen, um Renditen zu realisieren. Eine realistische Bewertung der kurzfristigen KI-Fähigkeiten würde die Bewertungen im gesamten Sektor einkratzen.

**Die Medien** hat entdeckt, dass KI-Geschichten massives Engagement erzeugen. Nuanced Coverage bekommt keine Klicks. "KI wird Ihren Job annehmen" und "KI-Durchbruch löst X" tun. Zugang zu KI-Unternehmen hängt oft davon ab, positive Beziehungen aufrecht zu erhalten – was bedeutet, dass kritische Abdeckung Karriere-Limiting ist.

Das Ergebnis? Ein selbstverstärkender Hype-Zyklus, bei dem jeder Grund hat, die Erwartungen zu übertreffen, und nur sehr wenige Menschen davon profitieren, die Wahrheit zu sagen.

Dies bedeutet nicht, dass KI nicht wirklich nützlich ist – es ist absolut, wie ich in diesem Artikel diskutiert habe. Aber die Lücke zwischen dem, was versprochen wird und dem, was geliefert wird, ist groß, und die Anreize sind alle ausgerichtet, um diese Lücke versteckt zu halten.

Wenn Ihnen jemand sagt, dass KI Ihr Geschäft revolutionieren wird, fragen Sie sich: Was gewinnen sie davon, dass Sie daran glauben?

## Was sollte man eigentlich tun?

Wenn Sie ein KI-Projekt in Erwägung ziehen, hier ist mein ehrlicher Rat:

### 1. Beginnen Sie mit dem Problem, nicht mit der Technologie

Fragen Sie nicht "Wie können wir KI verwenden?" Fragen Sie "Welches Problem versuchen wir zu lösen?" Wenn KI die richtige Lösung ist, toll. Aber oft ist es nicht.

### 2. Fixieren Sie Ihre Daten zuerst

Bevor Sie eine RAG-Pipeline bauen, beheben Sie Ihr Dokument Chaos. Bevor Sie Feinabstimmung, reinigen Sie Ihre Trainingsdaten. Die KI wird Ihre Datenprobleme nicht beheben; es wird sie verstärken.

### 3. Starten Sie klein und iterate

Starten Sie keine massive "AI-Transformation." Bauen Sie einen kleinen Beweis des Konzepts. Testen Sie es mit echten Benutzern. Erfahren Sie, was tatsächlich funktioniert. Dann erweitern.

### 4. Investieren Sie in die langweiligen Bits

Die Dokumenteneinnahme-Pipeline ist nicht sexy. Die Datenreinigung ist nicht aufregend. Das Evaluierungs-Framework ist nicht etwas, das man dem Board vorführen kann. Aber diese sind es, die Erfolg oder Misserfolg bestimmen.

### 5. Seien Sie ehrlich über Einschränkungen

KI ist keine Magie. Aktuelle LLMs halluzinieren. RAG-Systeme vermissen relevante Dokumente. Feinabstimmung Modelle Drift. Setzen Sie realistische Erwartungen.

### 6. Wartungsplan

Der Aufbau des Systems ist vielleicht 30% des Aufwands. Aufrechterhaltung, Verbesserung, und halten es relevant ist die anderen 70%. Budget entsprechend.

### 7. Überlegen Sie, ob Sie eine benutzerdefinierte Lösung überhaupt benötigen

Vielleicht ist das, was Sie brauchen, nur eine bessere Verwendung von Off-the-Shelf-Tools. ChatGPT mit einigen benutzerdefinierten Anweisungen könnte genug sein.

## Aber sie müssen nicht dumm sein

Richtig, ich habe ein paar Worte damit verbracht, kommerzielle KI-Projekte abzufackeln. Jetzt zum hoffnungsvollen Teil: **Diese Projekte können tatsächlich funktionieren, wenn man sie vernünftig anspricht.**

Das Problem ist nicht RAG oder Feinabstimmung als Konzepte. Das Problem ist faule Umsetzung, unrealistische Erwartungen, und ignorieren die Grundlagen. Hier ist, wie es besser zu tun.

### KI in bestehende Workflows einbinden, sie nicht ersetzen

Der größte Fehler, den ich sehe, ist die Behandlung von KI als Ersatz für bestehende Prozesse und nicht als Verbesserung. Ihr Unternehmen hat bereits Workflows, die funktionieren (vor allem). Anstatt sie herauszureißen und sie durch eine "AI-powered"-Version zu ersetzen, haken Sie KI in die Lücken.

```mermaid
flowchart TD
    subgraph Traditional["Traditional Workflow"]
        A[Document Arrives] --> B[Human Reviews]
        B --> C[Decision Made]
        C --> D[Action Taken]
        D --> E[Results Logged]
    end

subgraph Enhanced["AI-Enhanced Workflow"]
        A2[Document Arrives] --> AI1[AI: Extract Key Info]
        AI1 --> B2[Human Reviews - With AI Summary]
        B2 --> AI2[AI: Suggest Decision Based on History]
        AI2 --> C2[Human Makes Final Decision]
        C2 --> D2[Action Taken]
        D2 --> AI3[AI: Auto-categorise & Log]
        AI3 --> E2[Results Available for Future AI Training]
    end
```

Beachten Sie, was anders ist:

- **Menschen sind immer noch in der Schleife** für Entscheidungen, die von Bedeutung sind
- **KI kümmert sich um die mühsamen Bits** - Extraktion, Zusammenfassung, Kategorisierung
- **Jeder AI-Schritt ist klein und nachprüfbar** - wenn die KI falsch absaugt, fängt der Mensch sie während der Überprüfung
- **Es existieren Rückkopplungsschleifen** - protokollierte Ergebnisse trainieren zukünftige KI-Verbesserungen

Das ist weitaus robuster als "AI behandelt alles und manchmal eine menschliche Kontrolle."

### Lokale LLMs für Kosten und Vertraulichkeit verwenden

Hier ist ein schmutziges Geheimnis: Sie brauchen wahrscheinlich nicht GPT-4 oder Claude für die meisten Aufgaben. Und Sie brauchen auf jeden Fall nicht Ihre vertraulichen Dokumente an OpenAI Server zu senden.

**Das Kostenproblem**

Auf Skala, API-Kosten addieren sich schnell. Ein beschäftigtes RAG-System könnte Tausende von LLM-Anrufe pro Tag machen. Bei $0,01-0.03 pro 1K-Token, das ist echtes Geld. Und während Sie skalieren, wird es schlimmer.

**Das Problem der Vertraulichkeit**

Viele Organisationen können (oder sollten) ihre Dokumente nicht an externe APIs senden:

- Rechtliche Dokumente mit Kundeninformationen
- Medizinische Unterlagen
- Finanzielle Daten
- Proprietäre Forschung
- Alles, was unter die DSGVO, HIPAA, etc.

**Die Lösung: Lokale Modelle**

Moderne Open-Source-Modelle sind verdammt gut. Laufen vor Ort bedeutet:

- **Null Grenzkosten pro Abfrage** - Sie haben für die Hardware bezahlt, Schlussfolgerung ist "frei"
- **Vollständiger Datenschutz** - nichts verlässt Ihre Infrastruktur
- **Keine Steuersätze** - skalieren so viel wie Ihre Hardware erlaubt
- **Anpassungsoptionen** - Feinabstimmung ohne Daten, die Ihre Kontrolle verlassen

```mermaid
flowchart LR
    subgraph Cloud["Cloud API Approach"]
        A1[Your Documents] --> B1[Internet]
        B1 --> C1[OpenAI/Anthropic]
        C1 --> D1[£££/month]
        C1 --> E1[Privacy Concerns]
    end

subgraph Local["Local LLM Approach"]
        A2[Your Documents] --> B2[Your Server]
        B2 --> C2[Local LLM]
        C2 --> D2[Fixed Hardware Cost]
        C2 --> E2[Data Never Leaves]
    end
```

#### Praktische lokale Modelloptionen

Für **Einbettung** (das RAG-Vektor-Suchbit):

- **Satztransformatoren** - Schnell, präzise, läuft auf bescheidener Hardware
- **mit einer Dicke von mehr als 2 mm, jedoch nicht mehr als 2 mm,** - Große Qualität, kleiner Fußabdruck
- **BGE-Modelle** - Konkurrenzfähig mit kommerziellen Optionen

Für **Erzeugung** (die tatsächlichen „AI"-Antworten):

- **Llama 3.1 8B/70B** - Ausgezeichnete allgemeine Zweck, große Anleitung folgen
- **Mistral/Mixtral** - Schnelle, effiziente, gute Argumentation
- **Phi-3** - Überraschend in der Lage für seine Größe
- **Qwen 2.5** - Starke mehrsprachige Unterstützung

Für **Kodierungsaufgaben**:

- **CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama** - Speziell für Code ausgebildet
- **Coder für DeepSeek** - Ausgezeichnetes Code-Verständnis
- **Sterncoder** - Gut für viele Sprachen

Diese lokal zu betreiben ist nicht so schwer, wie Sie denken würden. **Ollama**, **llama.cpp**, **vLLM**, oder **Text-Generation-Schlussfolgerung** Ich habe eine Reihe von Anwendungen gebaut (siehe unten im Artikel), die dies auf Consumer-Hardware demonstriert.

#### Der hybride Ansatz

Man muss nicht all-oder-nichts gehen. Eine sinnvolle Architektur verwendet:

1. **Lokale Modelle für großvolumige, weniger komplexe Aufgaben**
   
   - Klassifikation des Dokuments
   - Entitätsextraktion
   - Einfaches Q&A
   - Zusammenfassung

2. **Cloud-APIs für komplexe Überlegungen bei Bedarf**
   
   - Komplexe mehrstufige Analyse
   - Aufgaben, die die größten Kontextfenster erfordern
   - Rückfall, wenn das lokale Modell-Konfidenzniveau niedrig ist

Dieser hybride Ansatz gibt Ihnen die Kostenvorteile der lokalen Schlussfolgerung mit der Fähigkeit von Cloud-Modellen, wenn Sie es wirklich brauchen.

### Inkrementeller Wert schaffen, keine Urknall-Transformationen

```mermaid
flowchart LR
    subgraph Waterfall["❌ The Waterfall AI Project"]
        W1[Month 1-3: Requirements] --> W2[Month 4-6: Build Platform]
        W2 --> W3[Month 7-9: Integration]
        W3 --> W4[Month 10: Demo - Looks Great!]
        W4 --> W5[Month 11: Real Users Break It]
        W5 --> W6[Month 12: Project Shelved]
    end

subgraph Incremental["✅ The Incremental Approach"]
        I1[Week 1-2: One Small Problem] --> I2[Week 3-4: Refine + Measure]
        I2 --> I3[Week 5-6: Add Capability]
        I3 --> I4[Week 7-8: Refine + Measure]
        I4 --> I5[Repeat...]
        I5 --> I6[Continuous Value Delivery]
    end

style W5 stroke:#ff0000,stroke-width:3px
    style W6 stroke:#ff0000,stroke-width:3px
    style I6 stroke:#00aa00,stroke-width:3px
```

Jeder Schritt im inkrementellen Ansatz liefert messbaren Wert. Jeder Schritt lehrt Sie etwas. Wenn etwas fehlschlägt, haben Sie Wochen verloren, nicht Monate.

### Machen Sie die Aufnahme von Dokumenten zu einem Problem der ersten Klasse

Erinnern Sie sich an das rote Kästchen im Diagramm? Hier ist, wie man es tatsächlich beheben:

**Investieren Sie in Qualität über Quantität.** Es ist besser, 1.000 perfekt verarbeitete Dokumente als 100.000 schlecht verarbeitete zu haben. Beginnen Sie mit Ihren wichtigsten Dokumenten und erhalten Sie sie richtig.

**Verwenden Sie KI, um bei der Einnahme zu helfen.** Moderne visionssprachliche Modelle (GPT-4V, Claude, LLaVA lokal) können komplexe Dokumente - Tabellen, Diagramme, handschriftliche Notizen - auf eine Weise lesen, die traditionelle OCR nicht kann. Verwenden Sie sie für die harten Dokumente.

**Erstellen Sie Rückkopplungsschleifen.** Wenn Retrieval fehlschlägt, loggen Sie es. Wenn Benutzer sagen, "das ist nicht, was das Dokument sagt", erfassen Sie es. Verwenden Sie dieses Feedback, um Ihre Aufnahme Pipeline zu verbessern.

**Akzeptieren Sie, dass einige Dokumente nicht funktionieren.** Nicht jeder alte gescannte PDF ist es wert, mit zu kämpfen. Manchmal ist die Antwort "wir werden diesen Typ manuell handhaben" anstatt monatelang an Randfällen zu verbringen.

### Denken Sie an das vollständige System, nicht nur das KI-Bit

Eine funktionierende KI-Lösung braucht:

Was die meisten Projekte tun, was tatsächlich funktioniert
|-----------|----------------------|---------------------|
Datenaufnahme Nachdenklich Primärer Fokus
. Datenqualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basis-Vektorsuche: Hybride Suche + Neuranking:
Erzeugung, roher LLM-Ausgang, strukturierter Ausgang mit Validierung
Humane Bewertung Optional Integriert in den Workflow
Rückkopplung Keine Kontinuierliche Verbesserungsschleife
Beobachten: "Es funktioniert" Ausführliche Metriken & Alarmieren:
Pflege "Version 1 für immer" - Regelmäßige Updates & Umschulungen

Das KI-Modell ist vielleicht 20% eines funktionierenden Systems. Die anderen 80% sind die langweiligen Sachen, die es tatsächlich in der Produktion arbeiten lassen.

### Vom ersten Tag an in Beobachtbarkeit bauen

Sie können nicht verbessern, was Sie nicht messen können. Jedes KI-System sollte verfolgen:

- **Retrieval-Qualität**: Finden Sie relevante Dokumente? Verfolgen Sie Abrufgenauigkeit und Rückruf.
- **Erzeugungsqualität**: Sind die Antworten korrekt? Spur Halluzinationsraten (ja, das ist schwer).
- **Benutzerzufriedenheit**: Finden die Leute es tatsächlich nützlich? Verfolgen Sie Nutzung, Fertigstellungsraten, Daumen nach oben/unten.
- **Kosten pro Abfrage**: Was geben Sie eigentlich aus? Track Token-Nutzung, Latenz, Infrastrukturkosten.
- **Failure-Modi**: Wann bricht es? Verfolgen Sie Fehlerraten nach Dokumenttyp, Abfragetyp usw.

Diese Daten sagen Ihnen, wo Sie Aufwand investieren. Vielleicht ist Ihr Abrufen groß, aber Generation halluziniert. Vielleicht bestimmte Dokumenttypen immer scheitern. Sie können nicht beheben, was Sie nicht sehen können.

### Das Ende von "Big LLM Solves Everything"

Hier ist die wichtigste Veränderung, die gerade stattfindet: **die Ära von "wirf alles bei GPT-4 und hoffe auf das Beste" endet.**

Der 2023-2024 Ansatz war einfach: das größte Modell, das Sie sich leisten können, füllen Sie Ihr Kontextfenster voll von allem, und beten. Es funktionierte... irgendwie. Für Demos. Für Prototypen. Für Investitionen.

Aber es skaliert nicht. Es ist teuer. Es ist langsam. Und zunehmend wird es von intelligenteren Architekturen übertroffen.

#### Der Wechsel zu orchestrierten kleinen Modellen

Die Zukunft ist nicht ein riesiges Modell, das alles tut. **mehrere spezialisierte Modelle arbeiten zusammen**Jeder tut, was er kann.

```mermaid
flowchart TD
    subgraph OldWay["The 2023 Approach"]
        A1[Everything] --> B1[GPT-4]
        B1 --> C1[Hope It Works]
        B1 --> D1[£££££]
    end

subgraph NewWay["The 2025+ Approach"]
        A2[Input] --> B2[Router Model - Small/Fast]
        B2 --> C2[Specialist Model A - Extraction]
        B2 --> D2[Specialist Model B - Reasoning]
        B2 --> E2[Specialist Model C - Generation]
        C2 --> F2[Orchestrator]
        D2 --> F2
        E2 --> F2
        F2 --> G2[Output]
    end
```

Das habe ich in meinem [DiSE (Directed Synthetic Evolution)](/blog/disejustvoyager) Arbeit – die Idee, dass **Struktur schlägt Brillanz**. Eine sorgfältig orchestrierte Pipeline kleinerer, fokussierter Modelle übertrifft ein einziges massives Modell, das alles versucht.

Das gleiche Denken gilt für die [Synthetische Entscheidungsmaschine](/blog/semantidintelligence) Konzept: Mit mehreren LLM-Backends in Folge, wo jedes Modell bringt verschiedene Stärken. Schnelle Modelle für Triage, genaue Modelle für die Validierung, kreative Modelle für die Erzeugung. Jedes tun, was es am besten tut.

#### Warum dies für die RAG von Bedeutung ist

Wenn du es noch nicht getan hast, schau dir meine [RAG-Reihen](/blog/rag-primer) Das geht tief auf die Grundlagen. Aber hier ist die Schlüssel-Insight: **RAG selbst ist eine Form dieses orchestrierten Ansatzes**. Sie verwenden Embeddings (ein Modell), um relevante Inhalte zu finden, und dann ein LLM (ein anderes Modell), um eine Antwort zu synthetisieren.

Die nächste Entwicklung geht weiter:

- **Modell einbetten** → findet Kandidatendokumente
- **Reranking-Modell** → Bestellungen nach aktueller Relevanz
- **Klassifikationsmodell** → ermittelt Abfrage-Intention
- **Modell der kleinen Generation** → bearbeitet einfache sachliche Anfragen
- **Großes Argumentationsmodell** → behandelt komplexe Analysen (nur bei Bedarf)

Jedes Modell ist kleiner, schneller und billiger als die Verwendung von GPT-4 für alles. Zusammen aber übertreffen sie den monolithischen Ansatz.

#### Die agentische Zukunft

Der Begriff "Agentik" entlehnt sich aus der Psychologie – mein ursprüngliches Feld, bevor ich in Software fiel. In der Psychologie bezieht sich die Agentur auf die Fähigkeit, unabhängig zu handeln, Entscheidungen zu treffen und sie in der Welt auszuführen.

**Agenturische KI** wendet dieses Konzept auf Sprachmodelle an. Anstelle des traditionellen Musters – man stellt eine Frage, das Modell erzeugt Text – kann ein agentisches System tatsächlich *Dinge tun*. Es kann Werkzeuge verwenden, Code ausführen, Datenbanken abfragen, APIs aufrufen, Dateien schreiben und mehrstufige Workflows orchestrieren. Es ist der Unterschied zwischen jemand nach Richtungen fragen und jemanden einstellen, um Sie dort zu fahren.

Dies ist, was Anthropoc neueste Modelle (einschließlich [Claude Opus 4.5](https://www.anthropic.com/news/claude-opus-4-5) dass ich dies buchstäblich über Claude Code schreibe) so effektiv demonstrieren.

Hier ist die Sache, die das Feinabstimmungs Publikum unbequem macht: **Wenn Sie Werkzeuge gut genug beschreiben, brauchen Sie keine teure Feineinstellung, um sie zu verwenden.** Moderne Fundamentmodelle sind bemerkenswert gut im Werkzeugeinsatz aus dem Kasten heraus – man braucht einfach klare Funktionsschemata und eine gute Dokumentation im Kontext.

Dies ist ein massiver Wechsel vom Toolformer-Ansatz (Feinabstimmung eines Modells, um zu lernen, wann Werkzeuge durch Messung von Ergebnissen verwendet werden). Das ist teuer, erfordert spezielle Trainingsdaten und sperrt Sie in eine bestimmte Reihe von Werkzeugen ein. Die Alternative? Beschreiben Sie Ihre Werkzeuge klar, geben Sie dem Modell guten Kontext, und lassen Sie es herausfinden, wann sie verwendet werden.

Die Ergebnisse sind oft besser, weil:

- **Werkzeugbeschreibungen können sofort aktualisiert werden** - keine Umschulung erforderlich
- **Neue Tools können zur Laufzeit hinzugefügt werden** - einfach ein weiteres Schema hinzufügen
- **Das Modell profitiert von seiner allgemeinen Argumentation** - nicht nur auswendig gelernte Muster
- **Sie können jedes fähige Modell verwenden** - keine speziell fein abgestimmte

```mermaid
flowchart TD
    subgraph RAG["Traditional RAG Chatbot"]
        R1[User Question] --> R2[Search Documents]
        R2 --> R3[Construct Prompt]
        R3 --> R4[LLM Generates Answer]
        R4 --> R5[Return to User]
    end

subgraph Agentic["Agentic AI Pattern"]
        A1[User Task] --> A2[LLM Understands Task]
        A2 --> A3[Break Into Steps]
        A3 --> A4{Select Tool}
        A4 --> A5[Execute Tool]
        A5 --> A6{Evaluate Results}
        A6 -->|Need More| A4
        A6 -->|Done| A7[Return to User]
    end

style A6 stroke:#00aa00,stroke-width:3px
```

Dieses agentische Muster unterscheidet sich grundlegend von RAG Chatbots. Und es ist, wo der wahre Wert liegt.

**Frameworks wie LangChain, LlamaIndex und Semantic Kernel machen dies heute möglich.** Sie können Systeme bauen, bei denen:

- Ein kleines schnelles Modell verarbeitet Routing und Klassifizierung
- Spezialisierte Modelle bearbeiten domänenspezifische Aufgaben
- Werkzeugeinsatz erweitert Fähigkeiten über reine Sprache hinaus
- Rückkopplungsschleifen ermöglichen kontinuierliche Verbesserung

Die Unternehmen, die dies herausfinden, werden KI-Systeme bauen, die tatsächlich funktionieren. Diejenigen, die immer noch versuchen, ihren Weg zum Erfolg zu verfeinern oder einen weiteren RAG-Chatbot zu bauen, werden weiterhin enttäuscht sein.

#### Wo Sie mehr erfahren können

Ich habe ausführlich über diese Muster geschrieben:

Thema: Artikel Was Sie lernen werden
|-------|--------------------------------------------------------------------------|-----------------------------------------------------------------|
| **Architektur** | [DiSE gegen Voyager](/blog/disejustvoyager) Warum strukturierte Orchestrierung monolithische Modelle schlägt
| **Multi-Modell** | [Synthetische Entscheidungsmotoren](/blog/semantidintelligence) Bau von Pipelines von spezialisierten Modellen
| **RAG-Grundlagen** | [RAG-Reihe](/blog/rag-primer) Von Einbettungen bis hin zu Produktionssystemen
| **Lokale Einbettungen** | [Semantische Suche mit ONNX](/blog/semantic-search-with-onnx-and-qdrant) CPU-freundliche lokale Vektorsuche
| **Lokale LLMs** | [ENTWICKLUNG](/blog/semanticintelligence-part10) Ein selkf-evolvign-Workflow-System, das lokale Modelle verwendet, die miteinander verbunden sind
| **API-Simulation** | [LLMApi](/blog/llmapi) Verwenden von lokalen LLMs, um APIs zum Testen zu simulieren
| **Praktische RAG** | [Aufbau einer Rechtsanwältin GPT](/blog/building-a-lawyer-gpt-for-your-blog-part1) Vollständige RAG-Implementierung durchgehen

Die Technologie existiert. Die Muster entstehen. Die Frage ist, ob Ihre Organisation etwas Vernünftiges oder ein anderes dummes KI-Projekt aufbauen wird.

## Schlußfolgerung

Die aktuelle kommerzielle KI-Landschaft erinnert mich an die frühe Web-Ära. Jeder brauchte eine "Web-Strategie". Unternehmen bauten Websites, weil sie mussten, nicht, weil sie wussten, was mit ihnen zu tun. Die meisten dieser Websites waren nutzlos.

Schließlich waren die Unternehmen, die erfolgreich waren diejenigen, die herausgefunden, was das Web war eigentlich gut für und gebaut dafür. Das gleiche wird mit AI passieren.

Im Moment sind wir in der "Build it, weil wir müssen" Phase. Die meisten Projekte sind dumm. Die meisten werden scheitern oder unterliefern. Das ist normal für neue Technologie.

Aber wenn Sie einer der erfolgreichsten sein wollen, hören Sie auf, der Vorlage zu folgen. Beginnen Sie mit echten Problemen. Investieren Sie in die langweiligen Bits. Und aus Liebe zu Gott, beheben Sie Ihre Dokument-Ingestion-Pipeline, bevor Sie die Schuld der LLM.

Die KI ist nicht das Problem. Ihre Daten sind. Ihre Prozesse sind. Ihre unrealistischen Erwartungen sind.

Bringen Sie die zuerst in Ordnung, und vielleicht wird Ihr AI-Projekt nicht dumm sein.

This is a preview from the server running through my markdig pipeline

AI LLM Opinion Software Development

Warum die meisten kommerziellen "KI"-Projekte Dumb sind

Wednesday, 26 November 2025

"Wir bauen einen KI-gestützten Wissensassistenten auf, der revolutionieren wird, wie unsere Mitarbeiter auf Informationen zugreifen..." — Jede Stellenanzeige, Pitch Deck und Beratungsvorschlag in 2024-2025

Einleitung

Es ist fast alles dasselbe.

Hier ist das schmutzige Geheimnis, das niemand im Management hören will: Die meisten kommerziellen KI-Projekte sind nicht innovativ.

Die beiden Arten von kommerziellen KI-Projekten

Entfernen Sie die Marketing-Blöcke und Sie werden feststellen, dass etwa 95% der kommerziellen "AI"-Projekte in eine von zwei Kategorien fallen:

Typ 1: Die RAG-Pipeline

Dies ist bei weitem die häufigste. Jede "Unternehmens-KI-Lösung" folgt diesem Muster:

flowchart LR
    A[Documents] --> B[Document Ingestion Pipeline]
    B --> C[Vector Database / RAG]
    C --> D[Construct Prompts]
    D --> E[LLM API Call]
    E --> F[Hybrid Search]
    F --> G[Response to User]

    style B stroke:#ff0000,stroke-width:4px

Das rote Kästchen ist da, wo alles kaputt geht, mehr dazu in einem Moment.

Die Tonhöhe klingt beeindruckend: "Wir haben eine KI gebaut, die die Dokumente Ihres Unternehmens versteht und Fragen intelligent beantworten kann!"

Die Realität: Sie haben eine Suchmaschine mit zusätzlichen Schritten und einem £ 10.000 / Monat OpenAI Rechnung gebaut.

Typ 2: Das Modell mit Feinsteuerung

Das hier ist noch zierlicher. Der Pitch: "Wir haben unser eigenes KI-Modell speziell für Ihre Branche trainiert!"

flowchart TD
    A[Existing LLM] --> B[Collect Training Data]
    B --> C[Clean Data - Maybe]
    C --> D[Fine-tune Model]
    D --> E[Deploy Model]
    E --> F[Discover it's not much better than base model]
    F --> G[Keep paying for inference anyway]
    G --> H[Hope nobody notices]

Die meisten Feinabstimmungs-Projekte, die ich gesehen habe, wären besser gewesen, indem sie das gleiche Geld für die Verbesserung ihrer Aufforderungen und Retrieval-Systeme ausgegeben hätten.

Warum die Dokumentaufnahme dahin geht, wo Träume sterben

Reden wir über das rote Kästchen im RAG-Diagramm. Dokumentaufnahme ist der Teil, der am häufigsten versagt, und es ist der Teil, der die geringste Aufmerksamkeit in den auffälligen Demos bekommt.

Hier ist, was die Verkaufsdemo zeigt:

Schöne PDFs, die in das System fließen
Clean Markdown perfekt extrahiert
All Ihr Wissen, durchsuchbar mit KI!

Hier ist, was tatsächlich passiert:

Das PDF-Problem

PDFs sind ein Alptraum. Sie wurden zum Drucken entwickelt, nicht zum Extrahieren strukturierter Daten. Jeder PDF-Parser, den ich benutzt habe, hat verschiedene Ausfallmodi:

Spalten, die falsch zusammengeführt werden
Tische, die zu Kauderwelsch werden
Kopf- und Fußzeilen, die den Inhalt verschmutzen
Gescannte Dokumente, die OCR benötigen (und OCR hat seine eigenen Fehlerraten)
Sicherheitsgeschützte Dokumente, die überhaupt nicht verarbeitet werden können
Font-Encoding-Probleme, die Text in Müll verwandeln

Und das sind nur PDFs. Warten Sie, bis Sie treffen:

PowerPoint-Dateien mit Text in SmartArt
Word-Dokumente mit Track-Änderungen
Excel-Dateien mit zusammengeführten Zellen
Gescannte Bilder mit Handschrift
Legacy-Formate von Systemen, die in den 90er Jahren starben

Die verheerende Katastrophe

Sobald Sie Text extrahiert haben (schlecht), müssen Sie es für Ihre Vektor-Datenbank broken. Dies ist, wo mehr magisches Denken geschieht.

"Wir werden semantische Brocken verwenden!" Großartig, dein 200-Seiten-Vertrag ist jetzt 500 Brocken, und die KI hat keine Ahnung, welche in welcher Reihenfolge sie verwandt sind.

"Wir werden feste Stücke mit Überlappung verwenden!" Perfekt, Sie haben gerade einen Satz in der Hälfte geteilt und die Einbettung stellt jetzt Unsinn dar.

flowchart TD
    A[Original Document] --> B[Chunk 1: This contract shall be governed by]
    A --> C[Chunk 2: the laws of the State of California]
    B --> D[Embedding: Legal stuff?]
    C --> E[Embedding: Geography?]
    D --> F[User asks about jurisdiction]
    E --> F
    F --> G[AI: Based on my knowledge, possibly California, or maybe legal governance, who knows]

Die Metadaten-Messung

Gute RAG braucht gute Metadaten. Aber das Extrahieren von Metadaten aus Dokumenten ist schwierig:

Was ist das Dokument Datum? Ist es das Erstellungsdatum, das Änderungsdatum oder das Datum, das im Inhalt erwähnt wird?
Wer ist der Autor? Die Person, die die Akte erstellt hat, der Rechtsautor oder der Sachexperte?
Zu welcher Kategorie gehört sie? Ihre Taxonomie stimmt wahrscheinlich nicht mit der Art überein, wie die Dokumente tatsächlich organisiert wurden.
Ist dieses Dokument noch gültig? Oder wurde es durch etwas neueres ersetzt, von dem Ihr System nichts weiß?

Die Fantasie des Feintuning

Lassen Sie mich klar sagen: Feinabstimmung hat ihren Platz. Aber die Art und Weise, wie die meisten Unternehmen an sie herangehen, ist grundlegend gebrochen.

Das Datenproblem

Feinabstimmung erfordert qualitativ hochwertige Trainingsdaten. Die meisten Unternehmen haben es nicht. Sie haben:

Lärmige, inkonsistente Daten, die über Systeme verteilt sind
Daten, die zeigen, wie die Dinge gemacht wurden, nicht wie sie gemacht werden sollten
Daten, die voller Fehler sind, die niemand reparieren wollte
Daten, die proprietär sind, aber nicht wirklich so wertvoll

"Wir werden Feinabstimmung auf unsere Verkaufsanrufe!" Sie meinen diejenigen, wo Verkäufer Versprechen machen, die das Produkt nicht halten kann?

Das Bewertungsproblem

Woher wissen Sie, ob Ihr fein abgestimmtes Modell tatsächlich besser ist? Die meisten Unternehmen können das nicht beantworten, weil:

Sie haben keinen guten Benchmark-Datensatz
Sie haben keine klaren Bewertungsmetriken
Sie haben keine rigorosen A/B-Tests gemacht.
Sie vergleichen Vibes, keine Daten

Ich habe gesehen, Unternehmen verbringen sechs Monate Feinabstimmung ein Modell und dann haben keine Möglichkeit, zu beweisen, es ist besser als nur mit GPT-4 mit einem guten System-Prompt.

Das Wartungsproblem

Aktualisierung bedeutet jedoch:

Neue Trainingsdaten sammeln
Das Training wieder laufen lassen
Validierung des neuen Modells
Einsatz
Ich hoffe, du hast keine Regressionen eingeführt.

Die meisten Unternehmen Feinabstimmung einmal und dann nur leben mit der Drift. Das Modell wird langsam weniger relevant, während jeder vorgibt, es ist immer noch Mehrwert.

Welche "KI"-Projekte eigentlich gut sind

Versteh mich nicht falsch.

flowchart TD
    subgraph RAGWorks["✅ RAG Works When"]
        R1[Well-structured docs]
        R2[Clear metadata]
        R3[Search + synthesis use case]
        R4[Heavy ingestion investment]
        R5[Feedback loops exist]
    end

    subgraph FTWorks["✅ Fine-Tuning Works When"]
        F1[Large high-quality dataset]
        F2[Base model truly struggles]
        F3[Ongoing maintenance budget]
        F4[Clear eval metrics]
        F5[Already tried prompting + RAG]
    end

    style R4 stroke:#00aa00,stroke-width:2px
    style F5 stroke:#00aa00,stroke-width:2px

Die Green Boxen sind die Voraussetzungen, die die meisten Projekte überspringen. "Wir haben bereits Prompting und RAG optimiert" ist die Bar für Feinabstimmung. "Schwere Ingestionsinvestitionen" ist die Bar für RAG. Überspringen Sie diese und Sie bauen auf Sand.

Die wirklichen Probleme, die niemand löst

Während jeder die gleiche RAG-Pipeline baut, werden die eigentlich interessanten Probleme in der kommerziellen KI ignoriert:

Datenqualität

Die größte Einschränkung der KI-Wirksamkeit ist nicht das Modell. Es sind die Daten. Die meisten Organisationen haben:

Daten verteilen sich auf Dutzende von Systemen, die nicht miteinander sprechen
Keine einzige Quelle der Wahrheit für irgendetwas
Daten-Governance, das ist mehr Aspiration als Realität
Qualitätsfragen, die niemand mit Budget zu beheben hat

Aber "Datenqualitätsinitiative" bekommt keinen Forbes-Artikel wie "AI Transformation".

Prozessintegration

Mensch-AI-Zusammenarbeit

Die besten KI-Implementierungen erhöhen die menschlichen Fähigkeiten, anstatt sie zu ersetzen. Aber das ist schwieriger zu verkaufen als "KI, die X automatisch tut!"

Menschen + KI-Zusammenarbeit erfordert:

Klare Übergabepunkte
Transparente KI-Überlegung
Einfache Überbrückungsmechanismen
Feedback-Schleifen zur Verbesserung

Die meisten kommerziellen KI-Projekte behandeln den Menschen als Nachdenklichkeit.

Echte Innovation

Die wirklich wertvollen KI-Anwendungen sind nicht "Chatbot auf Ihren Dokumenten." Sie sind Anwendungen, die:

Dinge aktivieren, die bisher unmöglich waren
Neue Wertekategorien erstellen
Probleme auf grundlegend neue Weise lösen

Aber die sind hart. RAG-Pipelines sind einfach (gut, einfacher). Also das ist es, was jeder baut.

Der beratende Industriekomplex

Ein wichtiger Treiber von dummen KI-Projekten ist das Beratungsökosystem:

flowchart TD
    A[Big Consultancy Tells C-Suite: You Need AI!] --> B[C-Suite Panics]
    B --> C[Consultancy Deploys Army of Juniors]
    C --> D[Recommendations: RAG + Fine-Tuning]
    D --> E[Build Same Thing as Last 20 Clients]
    E --> F[Demo Goes Well]
    F --> G[Reality: Real Data Breaks Everything]
    G --> H[Consultancy Moves On]
    H --> I[Internal Team Struggles]
    I --> J[Project Quietly Fails]
    J --> K[Nobody Admits It]
    K --> A

    style G stroke:#ff0000,stroke-width:3px
    style J stroke:#ff0000,stroke-width:3px

Ich habe dieses Muster Dutzende Male gesehen. Die Beratung wird bezahlt. Die Führungskräfte bekommen zu sagen, sie "hatten KI." Die Ingenieure erhalten stecken bei etwas, das kaum funktioniert. Und das eigentliche Geschäft Problem bleibt ungelöst.

Die VC-getriebene KI-Voraussetzung

Startups fallen in eine etwas andere Falle. Es sind keine Beratungsstellen, die die Dysfunktion treiben – es ist die Finanzierungsumgebung.

timeline
    title Technology Requirements for VC Funding
    2005 : Web 2.0 - "You need social features"
    2010 : Mobile - "You need an app"
    2015 : Cloud - "You need to be cloud-native"
    2018 : Blockchain - "You need a token"
    2023 : AI - "You need an AI strategy"

Jetzt passiert es mit AI.

Startups verschrauben LLM-Features auf Produkte, die sie nicht brauchen, weil:

Investoren schauen nicht auf Decks ohne "AI" erwähnt
Die Bewertungen sind 3-5x höher für "AI-Unternehmen"
Die Presse berichtet nur über KI-Geschichten
"KI-powered" ist Tischeinsatz für das Marketing

Das Schlimmste: Viele Gründer wissen, dass dies albern ist. Sie bauen KI-Features, an die sie nicht glauben, weil sie lange genug überleben müssen, um zu bauen, was ihnen eigentlich wichtig ist.

Wenn Sie ein Startup-Gründer sind, der KI hinzufügen soll, fragen Sie sich:

Verbessert KI wirklich das Kernwertangebot meines Produktes?
Oder checke ich nur ein Kästchen für Investoren?

Der Hype-Industriekomplex

Hier ist die unbequeme Wahrheit, die niemand in KI diskutieren will: Fast jeder im Ökosystem hat einen finanziellen Anreiz, den Hype am Laufen zu halten.

flowchart TD
    subgraph Researchers["🔬 Frontier Labs"]
        R1[Need billions for compute]
        R2[Must show progress to justify spend]
        R3[Hype generates investment]
    end

    subgraph Companies["🏢 Tech Companies"]
        C1[Need AI angle for valuation]
        C2[Must justify AI team costs]
        C3[Hype drives stock price]
    end

    subgraph Investors["💰 Financial Backers"]
        I1[Massive capital deployed]
        I2[Need exits and returns]
        I3[Hype maintains valuations]
    end

    subgraph Media["📰 Tech Media"]
        M1[AI stories get clicks]
        M2[Access depends on positive coverage]
        M3[Hype drives engagement]
    end

    R3 --> I1
    C3 --> I1
    I3 --> R1
    I3 --> C1
    M3 --> R3
    M3 --> C3

Die Forscher Das Geld kommt von Investoren und Big Tech. Um diese Ausgaben zu rechtfertigen, müssen sie Fortschritte demonstrieren – und "Fortschritt" wird in atemlose Ankündigungen über Fähigkeiten übersetzt, die in praktischen Anwendungen materialisieren können oder nicht. Wenn der Hype stirbt, trocknet die Finanzierung aus.

Die Unternehmen (sowohl die KI-Labore als auch alle, die KI nutzen) müssen die Erzählung fortsetzen. OpenAIs Bewertung hängt von der Überzeugung ab, dass AGI um die Ecke ist. Jedes "KI-powered"-Startup-Multiple hängt davon ab, dass KI den heißen Sektor bleibt.

Die Investoren Sie brauchen Ausstiege. Sie brauchen die Musik, um lange genug zu spielen, um Renditen zu realisieren. Eine realistische Bewertung der kurzfristigen KI-Fähigkeiten würde die Bewertungen im gesamten Sektor einkratzen.

Die Medien hat entdeckt, dass KI-Geschichten massives Engagement erzeugen. Nuanced Coverage bekommt keine Klicks. "KI wird Ihren Job annehmen" und "KI-Durchbruch löst X" tun. Zugang zu KI-Unternehmen hängt oft davon ab, positive Beziehungen aufrecht zu erhalten – was bedeutet, dass kritische Abdeckung Karriere-Limiting ist.

Das Ergebnis? Ein selbstverstärkender Hype-Zyklus, bei dem jeder Grund hat, die Erwartungen zu übertreffen, und nur sehr wenige Menschen davon profitieren, die Wahrheit zu sagen.

Wenn Ihnen jemand sagt, dass KI Ihr Geschäft revolutionieren wird, fragen Sie sich: Was gewinnen sie davon, dass Sie daran glauben?

Was sollte man eigentlich tun?

Wenn Sie ein KI-Projekt in Erwägung ziehen, hier ist mein ehrlicher Rat:

1. Beginnen Sie mit dem Problem, nicht mit der Technologie

Fragen Sie nicht "Wie können wir KI verwenden?" Fragen Sie "Welches Problem versuchen wir zu lösen?" Wenn KI die richtige Lösung ist, toll. Aber oft ist es nicht.

2. Fixieren Sie Ihre Daten zuerst

Bevor Sie eine RAG-Pipeline bauen, beheben Sie Ihr Dokument Chaos. Bevor Sie Feinabstimmung, reinigen Sie Ihre Trainingsdaten. Die KI wird Ihre Datenprobleme nicht beheben; es wird sie verstärken.

3. Starten Sie klein und iterate

Starten Sie keine massive "AI-Transformation." Bauen Sie einen kleinen Beweis des Konzepts. Testen Sie es mit echten Benutzern. Erfahren Sie, was tatsächlich funktioniert. Dann erweitern.

4. Investieren Sie in die langweiligen Bits

5. Seien Sie ehrlich über Einschränkungen

KI ist keine Magie. Aktuelle LLMs halluzinieren. RAG-Systeme vermissen relevante Dokumente. Feinabstimmung Modelle Drift. Setzen Sie realistische Erwartungen.

6. Wartungsplan

Der Aufbau des Systems ist vielleicht 30% des Aufwands. Aufrechterhaltung, Verbesserung, und halten es relevant ist die anderen 70%. Budget entsprechend.

7. Überlegen Sie, ob Sie eine benutzerdefinierte Lösung überhaupt benötigen

Vielleicht ist das, was Sie brauchen, nur eine bessere Verwendung von Off-the-Shelf-Tools. ChatGPT mit einigen benutzerdefinierten Anweisungen könnte genug sein.

Aber sie müssen nicht dumm sein

Richtig, ich habe ein paar Worte damit verbracht, kommerzielle KI-Projekte abzufackeln. Jetzt zum hoffnungsvollen Teil: Diese Projekte können tatsächlich funktionieren, wenn man sie vernünftig anspricht.

Das Problem ist nicht RAG oder Feinabstimmung als Konzepte. Das Problem ist faule Umsetzung, unrealistische Erwartungen, und ignorieren die Grundlagen. Hier ist, wie es besser zu tun.

KI in bestehende Workflows einbinden, sie nicht ersetzen

flowchart TD
    subgraph Traditional["Traditional Workflow"]
        A[Document Arrives] --> B[Human Reviews]
        B --> C[Decision Made]
        C --> D[Action Taken]
        D --> E[Results Logged]
    end

    subgraph Enhanced["AI-Enhanced Workflow"]
        A2[Document Arrives] --> AI1[AI: Extract Key Info]
        AI1 --> B2[Human Reviews - With AI Summary]
        B2 --> AI2[AI: Suggest Decision Based on History]
        AI2 --> C2[Human Makes Final Decision]
        C2 --> D2[Action Taken]
        D2 --> AI3[AI: Auto-categorise & Log]
        AI3 --> E2[Results Available for Future AI Training]
    end

Beachten Sie, was anders ist:

Menschen sind immer noch in der Schleife für Entscheidungen, die von Bedeutung sind
KI kümmert sich um die mühsamen Bits - Extraktion, Zusammenfassung, Kategorisierung
Jeder AI-Schritt ist klein und nachprüfbar - wenn die KI falsch absaugt, fängt der Mensch sie während der Überprüfung
Es existieren Rückkopplungsschleifen - protokollierte Ergebnisse trainieren zukünftige KI-Verbesserungen

Das ist weitaus robuster als "AI behandelt alles und manchmal eine menschliche Kontrolle."

Lokale LLMs für Kosten und Vertraulichkeit verwenden

Das Kostenproblem

Das Problem der Vertraulichkeit

Viele Organisationen können (oder sollten) ihre Dokumente nicht an externe APIs senden:

Rechtliche Dokumente mit Kundeninformationen
Medizinische Unterlagen
Finanzielle Daten
Proprietäre Forschung
Alles, was unter die DSGVO, HIPAA, etc.

Die Lösung: Lokale Modelle

Moderne Open-Source-Modelle sind verdammt gut. Laufen vor Ort bedeutet:

Null Grenzkosten pro Abfrage - Sie haben für die Hardware bezahlt, Schlussfolgerung ist "frei"
Vollständiger Datenschutz - nichts verlässt Ihre Infrastruktur
Keine Steuersätze - skalieren so viel wie Ihre Hardware erlaubt
Anpassungsoptionen - Feinabstimmung ohne Daten, die Ihre Kontrolle verlassen

flowchart LR
    subgraph Cloud["Cloud API Approach"]
        A1[Your Documents] --> B1[Internet]
        B1 --> C1[OpenAI/Anthropic]
        C1 --> D1[£££/month]
        C1 --> E1[Privacy Concerns]
    end

    subgraph Local["Local LLM Approach"]
        A2[Your Documents] --> B2[Your Server]
        B2 --> C2[Local LLM]
        C2 --> D2[Fixed Hardware Cost]
        C2 --> E2[Data Never Leaves]
    end

Praktische lokale Modelloptionen

Für Einbettung (das RAG-Vektor-Suchbit):

Satztransformatoren - Schnell, präzise, läuft auf bescheidener Hardware
mit einer Dicke von mehr als 2 mm, jedoch nicht mehr als 2 mm, - Große Qualität, kleiner Fußabdruck
BGE-Modelle - Konkurrenzfähig mit kommerziellen Optionen

Für Erzeugung (die tatsächlichen „AI"-Antworten):

Llama 3.1 8B/70B - Ausgezeichnete allgemeine Zweck, große Anleitung folgen
Mistral/Mixtral - Schnelle, effiziente, gute Argumentation
Phi-3 - Überraschend in der Lage für seine Größe
Qwen 2.5 - Starke mehrsprachige Unterstützung

Für Kodierungsaufgaben:

CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama-CodeLlama - Speziell für Code ausgebildet
Coder für DeepSeek - Ausgezeichnetes Code-Verständnis
Sterncoder - Gut für viele Sprachen

Diese lokal zu betreiben ist nicht so schwer, wie Sie denken würden. Ollama, llama.cpp, vLLM, oder Text-Generation-Schlussfolgerung Ich habe eine Reihe von Anwendungen gebaut (siehe unten im Artikel), die dies auf Consumer-Hardware demonstriert.

Der hybride Ansatz

Man muss nicht all-oder-nichts gehen. Eine sinnvolle Architektur verwendet:

Lokale Modelle für großvolumige, weniger komplexe Aufgaben
- Klassifikation des Dokuments
- Entitätsextraktion
- Einfaches Q&A
- Zusammenfassung
Cloud-APIs für komplexe Überlegungen bei Bedarf
- Komplexe mehrstufige Analyse
- Aufgaben, die die größten Kontextfenster erfordern
- Rückfall, wenn das lokale Modell-Konfidenzniveau niedrig ist

Dieser hybride Ansatz gibt Ihnen die Kostenvorteile der lokalen Schlussfolgerung mit der Fähigkeit von Cloud-Modellen, wenn Sie es wirklich brauchen.

Inkrementeller Wert schaffen, keine Urknall-Transformationen

flowchart LR
    subgraph Waterfall["❌ The Waterfall AI Project"]
        W1[Month 1-3: Requirements] --> W2[Month 4-6: Build Platform]
        W2 --> W3[Month 7-9: Integration]
        W3 --> W4[Month 10: Demo - Looks Great!]
        W4 --> W5[Month 11: Real Users Break It]
        W5 --> W6[Month 12: Project Shelved]
    end

    subgraph Incremental["✅ The Incremental Approach"]
        I1[Week 1-2: One Small Problem] --> I2[Week 3-4: Refine + Measure]
        I2 --> I3[Week 5-6: Add Capability]
        I3 --> I4[Week 7-8: Refine + Measure]
        I4 --> I5[Repeat...]
        I5 --> I6[Continuous Value Delivery]
    end

    style W5 stroke:#ff0000,stroke-width:3px
    style W6 stroke:#ff0000,stroke-width:3px
    style I6 stroke:#00aa00,stroke-width:3px

Jeder Schritt im inkrementellen Ansatz liefert messbaren Wert. Jeder Schritt lehrt Sie etwas. Wenn etwas fehlschlägt, haben Sie Wochen verloren, nicht Monate.

Machen Sie die Aufnahme von Dokumenten zu einem Problem der ersten Klasse

Erinnern Sie sich an das rote Kästchen im Diagramm? Hier ist, wie man es tatsächlich beheben:

Investieren Sie in Qualität über Quantität. Es ist besser, 1.000 perfekt verarbeitete Dokumente als 100.000 schlecht verarbeitete zu haben. Beginnen Sie mit Ihren wichtigsten Dokumenten und erhalten Sie sie richtig.

Verwenden Sie KI, um bei der Einnahme zu helfen. Moderne visionssprachliche Modelle (GPT-4V, Claude, LLaVA lokal) können komplexe Dokumente - Tabellen, Diagramme, handschriftliche Notizen - auf eine Weise lesen, die traditionelle OCR nicht kann. Verwenden Sie sie für die harten Dokumente.

Erstellen Sie Rückkopplungsschleifen. Wenn Retrieval fehlschlägt, loggen Sie es. Wenn Benutzer sagen, "das ist nicht, was das Dokument sagt", erfassen Sie es. Verwenden Sie dieses Feedback, um Ihre Aufnahme Pipeline zu verbessern.

Akzeptieren Sie, dass einige Dokumente nicht funktionieren. Nicht jeder alte gescannte PDF ist es wert, mit zu kämpfen. Manchmal ist die Antwort "wir werden diesen Typ manuell handhaben" anstatt monatelang an Randfällen zu verbringen.

Denken Sie an das vollständige System, nicht nur das KI-Bit

Eine funktionierende KI-Lösung braucht:

Was die meisten Projekte tun, was tatsächlich funktioniert |-----------|----------------------|---------------------| Datenaufnahme Nachdenklich Primärer Fokus . Datenqualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basis-Vektorsuche: Hybride Suche + Neuranking: Erzeugung, roher LLM-Ausgang, strukturierter Ausgang mit Validierung Humane Bewertung Optional Integriert in den Workflow Rückkopplung Keine Kontinuierliche Verbesserungsschleife Beobachten: "Es funktioniert" Ausführliche Metriken & Alarmieren: Pflege "Version 1 für immer" - Regelmäßige Updates & Umschulungen

Das KI-Modell ist vielleicht 20% eines funktionierenden Systems. Die anderen 80% sind die langweiligen Sachen, die es tatsächlich in der Produktion arbeiten lassen.

Vom ersten Tag an in Beobachtbarkeit bauen

Sie können nicht verbessern, was Sie nicht messen können. Jedes KI-System sollte verfolgen:

Retrieval-Qualität: Finden Sie relevante Dokumente? Verfolgen Sie Abrufgenauigkeit und Rückruf.
Erzeugungsqualität: Sind die Antworten korrekt? Spur Halluzinationsraten (ja, das ist schwer).
Benutzerzufriedenheit: Finden die Leute es tatsächlich nützlich? Verfolgen Sie Nutzung, Fertigstellungsraten, Daumen nach oben/unten.
Kosten pro Abfrage: Was geben Sie eigentlich aus? Track Token-Nutzung, Latenz, Infrastrukturkosten.
Failure-Modi: Wann bricht es? Verfolgen Sie Fehlerraten nach Dokumenttyp, Abfragetyp usw.

Das Ende von "Big LLM Solves Everything"

Hier ist die wichtigste Veränderung, die gerade stattfindet: die Ära von "wirf alles bei GPT-4 und hoffe auf das Beste" endet.

Aber es skaliert nicht. Es ist teuer. Es ist langsam. Und zunehmend wird es von intelligenteren Architekturen übertroffen.

Der Wechsel zu orchestrierten kleinen Modellen

Die Zukunft ist nicht ein riesiges Modell, das alles tut. mehrere spezialisierte Modelle arbeiten zusammenJeder tut, was er kann.

flowchart TD
    subgraph OldWay["The 2023 Approach"]
        A1[Everything] --> B1[GPT-4]
        B1 --> C1[Hope It Works]
        B1 --> D1[£££££]
    end

    subgraph NewWay["The 2025+ Approach"]
        A2[Input] --> B2[Router Model - Small/Fast]
        B2 --> C2[Specialist Model A - Extraction]
        B2 --> D2[Specialist Model B - Reasoning]
        B2 --> E2[Specialist Model C - Generation]
        C2 --> F2[Orchestrator]
        D2 --> F2
        E2 --> F2
        F2 --> G2[Output]
    end

Das habe ich in meinem DiSE (Directed Synthetic Evolution) Arbeit – die Idee, dass Struktur schlägt Brillanz. Eine sorgfältig orchestrierte Pipeline kleinerer, fokussierter Modelle übertrifft ein einziges massives Modell, das alles versucht.

Das gleiche Denken gilt für die Synthetische Entscheidungsmaschine Konzept: Mit mehreren LLM-Backends in Folge, wo jedes Modell bringt verschiedene Stärken. Schnelle Modelle für Triage, genaue Modelle für die Validierung, kreative Modelle für die Erzeugung. Jedes tun, was es am besten tut.

Warum dies für die RAG von Bedeutung ist

Wenn du es noch nicht getan hast, schau dir meine RAG-Reihen Das geht tief auf die Grundlagen. Aber hier ist die Schlüssel-Insight: RAG selbst ist eine Form dieses orchestrierten Ansatzes. Sie verwenden Embeddings (ein Modell), um relevante Inhalte zu finden, und dann ein LLM (ein anderes Modell), um eine Antwort zu synthetisieren.

Die nächste Entwicklung geht weiter:

Modell einbetten → findet Kandidatendokumente
Reranking-Modell → Bestellungen nach aktueller Relevanz
Klassifikationsmodell → ermittelt Abfrage-Intention
Modell der kleinen Generation → bearbeitet einfache sachliche Anfragen
Großes Argumentationsmodell → behandelt komplexe Analysen (nur bei Bedarf)

Jedes Modell ist kleiner, schneller und billiger als die Verwendung von GPT-4 für alles. Zusammen aber übertreffen sie den monolithischen Ansatz.

Die agentische Zukunft

Agenturische KI wendet dieses Konzept auf Sprachmodelle an. Anstelle des traditionellen Musters – man stellt eine Frage, das Modell erzeugt Text – kann ein agentisches System tatsächlich Dinge tun. Es kann Werkzeuge verwenden, Code ausführen, Datenbanken abfragen, APIs aufrufen, Dateien schreiben und mehrstufige Workflows orchestrieren. Es ist der Unterschied zwischen jemand nach Richtungen fragen und jemanden einstellen, um Sie dort zu fahren.

Dies ist, was Anthropoc neueste Modelle (einschließlich Claude Opus 4.5 dass ich dies buchstäblich über Claude Code schreibe) so effektiv demonstrieren.

Hier ist die Sache, die das Feinabstimmungs Publikum unbequem macht: Wenn Sie Werkzeuge gut genug beschreiben, brauchen Sie keine teure Feineinstellung, um sie zu verwenden. Moderne Fundamentmodelle sind bemerkenswert gut im Werkzeugeinsatz aus dem Kasten heraus – man braucht einfach klare Funktionsschemata und eine gute Dokumentation im Kontext.

Die Ergebnisse sind oft besser, weil:

Werkzeugbeschreibungen können sofort aktualisiert werden - keine Umschulung erforderlich
Neue Tools können zur Laufzeit hinzugefügt werden - einfach ein weiteres Schema hinzufügen
Das Modell profitiert von seiner allgemeinen Argumentation - nicht nur auswendig gelernte Muster
Sie können jedes fähige Modell verwenden - keine speziell fein abgestimmte

flowchart TD
    subgraph RAG["Traditional RAG Chatbot"]
        R1[User Question] --> R2[Search Documents]
        R2 --> R3[Construct Prompt]
        R3 --> R4[LLM Generates Answer]
        R4 --> R5[Return to User]
    end

    subgraph Agentic["Agentic AI Pattern"]
        A1[User Task] --> A2[LLM Understands Task]
        A2 --> A3[Break Into Steps]
        A3 --> A4{Select Tool}
        A4 --> A5[Execute Tool]
        A5 --> A6{Evaluate Results}
        A6 -->|Need More| A4
        A6 -->|Done| A7[Return to User]
    end

    style A6 stroke:#00aa00,stroke-width:3px

Dieses agentische Muster unterscheidet sich grundlegend von RAG Chatbots. Und es ist, wo der wahre Wert liegt.

Frameworks wie LangChain, LlamaIndex und Semantic Kernel machen dies heute möglich. Sie können Systeme bauen, bei denen:

Ein kleines schnelles Modell verarbeitet Routing und Klassifizierung
Spezialisierte Modelle bearbeiten domänenspezifische Aufgaben
Werkzeugeinsatz erweitert Fähigkeiten über reine Sprache hinaus
Rückkopplungsschleifen ermöglichen kontinuierliche Verbesserung

Wo Sie mehr erfahren können

Ich habe ausführlich über diese Muster geschrieben:

Thema: Artikel Was Sie lernen werden |-------|--------------------------------------------------------------------------|-----------------------------------------------------------------| | Architektur | DiSE gegen Voyager Warum strukturierte Orchestrierung monolithische Modelle schlägt | Multi-Modell | Synthetische Entscheidungsmotoren Bau von Pipelines von spezialisierten Modellen | RAG-Grundlagen | RAG-Reihe Von Einbettungen bis hin zu Produktionssystemen | Lokale Einbettungen | Semantische Suche mit ONNX CPU-freundliche lokale Vektorsuche | Lokale LLMs | ENTWICKLUNG Ein selkf-evolvign-Workflow-System, das lokale Modelle verwendet, die miteinander verbunden sind | API-Simulation | LLMApi Verwenden von lokalen LLMs, um APIs zum Testen zu simulieren | Praktische RAG | Aufbau einer Rechtsanwältin GPT Vollständige RAG-Implementierung durchgehen

Die Technologie existiert. Die Muster entstehen. Die Frage ist, ob Ihre Organisation etwas Vernünftiges oder ein anderes dummes KI-Projekt aufbauen wird.

Schlußfolgerung

Schließlich waren die Unternehmen, die erfolgreich waren diejenigen, die herausgefunden, was das Web war eigentlich gut für und gebaut dafür. Das gleiche wird mit AI passieren.

Im Moment sind wir in der "Build it, weil wir müssen" Phase. Die meisten Projekte sind dumm. Die meisten werden scheitern oder unterliefern. Das ist normal für neue Technologie.

Die KI ist nicht das Problem. Ihre Daten sind. Ihre Prozesse sind. Ihre unrealistischen Erwartungen sind.

Bringen Sie die zuerst in Ordnung, und vielleicht wird Ihr AI-Projekt nicht dumm sein.