KI-Tools nach Maß, gebaut für dein Problem

Wann ein individuelles KI-Tool sinnvoll ist

Nicht jeder Workflow erfordert KI. Ein n8n-Flow oder ein einfaches Skript löst die meisten wiederkehrenden Aufgaben ohne den Overhead eines Sprachmodells. Aber es gibt Situationen, in denen das nicht funktioniert. Drei Signale, dass ein individuelles KI-Tool der richtige Ansatz ist:

• Die Aufgabe erfordert Kontext: die korrekte Ausgabe hängt von Informationen ab, die über das Dokument oder den Datensatz verteilt sind, nicht von einer festen Regel, die in ein if-Statement passt.
• Die Eingabe variiert zu stark für eine Regex oder ein Template: Freitext, PDF-Formulare, E-Mails in wechselnden Formaten, Bilder von Belegen. Manuelle Strukturierung ist im Massstab nicht möglich.
• Die Entscheidungen sind zu kleinteilig für manuelle Regeln: Support-Tickets gleichzeitig nach Inhalt, Ton und Dringlichkeit an die richtige Abteilung weiterleiten, ohne dass eine Entscheidungsmatrix realisierbar ist.
• Das Volumen ist gross, aber die Arbeit ist zu repetitiv für einen Spezialisten: 200 Angebote pro Woche auf fehlende Klauseln prüfen ist Arbeit für eine KI, nicht für einen Juristen.

Wenn eines dieser Kriterien zutrifft, lohnt es sich, ein individuelles Tool zu erkunden. Nicht um KI einzubeziehen, sondern weil es der einzige Ansatz ist, der das Problem tatsächlich löst.

Wann ein individuelles KI-Tool keinen Sinn ergibt

KI ist keine Antwort auf jedes Problem. Ich baue keine Tools, wenn:

• Das Problem mit einer normalen Abfrage, einer Tabellenkalkulationsformel oder einer API-Integration ohne Reasoning-Ebene gelöst werden kann.
• Kein Business Case vorhanden ist: 'Wir wollen KI nutzen' ohne ein konkretes, messbares Problem dahinter.
• Das Ziel die Generierung von Marketinginhalten ohne spezifisches Domainwissen oder interne Daten als Eingabe ist. Das kann jeder selbst mit ChatGPT.
• Die Datenqualität nicht ausreicht, um ein Modell darauf zu betreiben: Garbage in, garbage out gilt auch für die fortgeschrittensten Modelle.

Mein Discovery-Ansatz: Audit vor Code

Bevor ich eine einzige Zeile Code schreibe, erfasse ich die manuelle Aufgabe. Das kostet nicht viel Zeit, verhindert aber, dass ich das falsche Tool baue. Die Schritte:

• Intake: Beschreibe den Prozess Schritt für Schritt. Was ist die Eingabe, was ist die gewünschte Ausgabe, welche Entscheidungen werden dazwischen getroffen?
• Fehleranalyse: Wo läuft es manuell schief? Wo treten Fehler auf, werden Schritte übersprungen oder dauert es länger als es sollte?
• POC in 1 bis 3 Iterationen: Ich baue einen funktionierenden Prototyp mit echten Daten deiner Organisation. Keine Demo-Daten, keine Idealsituationen.
• Validierung: Du oder ein Mitarbeiter bewertet die Ausgabe des Prototyps. Erst dann entscheide ich, ob das Modell geeignet ist oder angepasst werden muss.
• Iteration: Nach der Validierung passe ich die Prompts, die Pipeline oder die Architektur basierend auf dem an, was nicht stimmte. Keine große Veröffentlichung nach Monaten, sondern kleine Schritte, die nachweislich funktionieren.

Dieser Prozess ist bewusst kurz und konkret. Wenn der Prototyp in der ersten Iteration nutzlos ist, höre ich dort auf. Das ist ehrlicher als monatelang auf einem fehlerhaften Fundament weiterzuentwickeln.

Welche Modelle ich nutze und warum

Die Modellwahl hängt vom Problem ab, nicht davon, was gerade am meisten diskutiert wird. Meine Standardabwägung:

• Claudes neueste Modelle (Anthropic): für Aufgaben, bei denen das Reasoning über längeren Kontext wichtig ist, wie das Durchsuchen eines Dokuments auf Inkonsistenzen oder das Generieren strukturierter Ausgaben mit mehreren abhängigen Feldern.
• OpenAIs neuestes Modell (OpenAI): für Anwendungen, bei denen die Kosten pro Token stärker ins Gewicht fallen und die Aufgabe keine komplexen Reasoning-Ketten erfordert. Weit verbreitet für Klassifikationsaufgaben mit hohem Volumen.
• Lokale Llama-Varianten (Ollama oder vLLM): für Situationen, in denen Daten das System nicht verlassen duerfen. On-Premise, keine API-Calls an externe Server, vollständig innerhalb des Netzwerks oder Servers.
• Embeddings und Vector Store: für RAG-Anwendungen, bei denen das Modell Kontext aus einer eigenen Dokumentenbasis bezieht statt aus seinen Trainingsdaten.

Ich binde mich nicht an einen einzigen Anbieter. Das Modell, das das Problem am besten zu den niedrigsten laufenden Kosten löst, gewinnt.

Architektur, die ich typischerweise verwende

Je nach Tool kann der Stack variieren, aber die meisten individuellen KI-Tools, die ich baue, basieren auf einer ähnlichen Grundlage:

• Frontend: Next.js für Webinterfaces oder kein UI, wenn das Tool headless per API oder Cron läuft.
• Backend: FastAPI (Python) für Pipelines mit vielen KI-Aufrufen, Node.js für Integrationen mit bestehenden Systemen.
• Zustand und Speicher: PostgreSQL für strukturierte Daten und Entscheidungshistorie, S3-kompatibler Speicher für Dateien.
• Vector Store: pgvector in Postgres für einfache RAG-Setups oder Qdrant für größere Sammlungen mit mehr Suchoptionen.
• Orchestrierung: LangChain oder direkte API-Aufrufe, je nachdem, ob die Komplexität ein Framework rechtfertigt.
• Logging: Jede KI-Entscheidung wird mit Eingabe, Ausgabe und Begründung protokolliert. Das ist keine Option, das ist Standard.

Was ich nicht tue

Es gibt Dinge, die ich bewusst außerhalb des Umfangs halte:

• Out-of-the-box ChatGPT-API-Integrationen, bei denen das einzige Ziel darin besteht, dass auf der Website 'KI' steht. Das löst kein einziges Problem.
• KI-Features als Demo oder Pilot ohne Plan für den Produktionseinsatz. Ein Prototyp, der in der Schublade landet, ist verschwendetes Geld.
• Training eigener Modelle auf kleinen Datensätzen. Fine-Tuning macht erst bei tausenden von Beispielen und einem spezifischen Grund Sinn, warum ein Foundational Model nicht ausreicht.
• Systeme, bei denen die Ausgabe nicht überprüft werden kann. Jede KI-Entscheidung in der Produktion benötigt einen Audit-Trail. Ohne das gehe ich nicht live.

Weiterlesen