Das eigentliche Problem ist nicht das Modell
Wenn man heute „KI in unsere App einbauen" hört, denken die meisten an welches Modell?. Das ist die uninteressanteste Frage. Die wirklich harten Probleme bei LLM-Integration sind:
- Daten — wie kommt das Modell an firmenspezifischen Kontext, ohne ihn in jedem Prompt mitzuschleppen?
- Kosten — wie hält man den $/User-Wert vorhersagbar, wenn LLMs token-basiert abrechnen?
- Latenz — wie reagiert die UI binnen 100 ms, wenn das Modell 3 s zum Antworten braucht?
- Qualität — wie merkt man, dass das Modell halluziniert, bevor der Kunde es merkt?
Dieser Artikel zeigt die Architektur, die ich für produktionsreife LLM-Features nutze — mit konkreten Komponenten und Zahlen aus laufenden Projekten.
1. RAG statt Fine-Tuning (in 95 % der Fälle)
Fine-Tuning klingt verlockend, ist aber teuer und macht Updates schwer. Retrieval-Augmented Generation (RAG) löst das Problem „Modell kennt unsere Daten nicht" pragmatisch:
User-Query → Embedding → Vector-Search → relevante Chunks → LLM-Prompt → Antwort
Stack-Empfehlung für ein typisches RAG-Setup:
| Komponente | Empfehlung | Warum |
|---|---|---|
| Vector-DB | pgvector (Postgres-Extension) | Keine zusätzliche Infra, joins mit Business-Daten möglich |
| Embeddings | text-embedding-3-small (OpenAI) oder bge-m3 (lokal) | OpenAI 0.02 $/1M tokens, lokal kostenlos |
| Chunking | Semantic mit overlap (~400 tokens, 50 overlap) | Naive-Splitting zerstört Kontext-Grenzen |
| Re-Ranking | bge-reranker-v2-m3 oder Cohere Rerank | Verdoppelt die Treffer-Qualität bei minimaler Latenz |
Konkretes Beispiel — Knowledge-Base-Search über ~50.000 PDF-Seiten: Naive Vector-Suche allein traf in nur 60 % der Anfragen das richtige Dokument. Mit Reranking nach Top-20 → Top-5: 89 %. Mehrkosten: 30 ms Latenz, ~0.005 $/Query.
2. Multi-Provider-Routing
Single-Provider-Lockin ist der teuerste Fehler. Nicht weil OpenAI ausfällt, sondern weil Tasks unterschiedliche Modelle brauchen:
// Simplified routing logic
const ROUTES = {
classify: { model: 'claude-haiku-4-5', cost: 'low' }, // schnell + günstig
summarize: { model: 'gpt-4o-mini', cost: 'low' },
reason: { model: 'claude-opus-4-7', cost: 'high' }, // teuer aber besser
code_review: { model: 'claude-opus-4-7', cost: 'high' },
embeddings: { model: 'text-embedding-3-small', cost: 'minimal' },
} as const;
async function llm(task: keyof typeof ROUTES, prompt: string) {
const route = ROUTES[task];
return provider(route.model).complete(prompt);
}
Real-World-Kostenersparnis in einem AI-Customer-Support-Tool:
- 80 % der Anfragen werden mit Haiku/Mini beantwortet (0.001 $ pro Anfrage)
- 20 % eskalieren zu Opus/GPT-4o (0.05 $ pro Anfrage)
- Durchschnitt: ~0.011 $/Anfrage statt 0.05 $ mit „alles Opus" → 5x billiger
3. Semantisches Caching
LLM-Antworten lassen sich oft cachen — aber nicht 1:1 nach Prompt-Hash. Ähnliche Fragen sollen den gleichen Cache-Hit kriegen:
async function semanticCache(query: string): Promise<string | null> {
const queryEmbedding = await embed(query);
const hit = await db.query(
`SELECT response, 1 - (embedding <=> $1) AS similarity
FROM llm_cache
WHERE expires_at > now()
ORDER BY embedding <=> $1
LIMIT 1`,
[queryEmbedding]
);
if (hit && hit.similarity > 0.92) return hit.response;
return null;
}
Bei FAQ-artigen Workloads (Customer-Support, Docs-Bot):
- Cache-Hit-Rate typisch 30–50 %
- Median-Latenz fällt von 1.2 s auf 80 ms
- API-Kosten halbieren sich
Cache-Invalidierung ist trotzdem nicht trivial: wenn sich die zugrunde liegenden Daten ändern (neuer Helpdesk-Artikel), muss man semantisch verwandte Cache-Einträge invalidieren. Pragmatisch: TTL von 24h + manuelle Invalidierung nach Daten-Updates.
4. Streaming + Optimistic UI
User warten ungern 3 s auf eine Antwort. Server-Sent-Events + sofortige Anzeige des ersten Tokens ändert die wahrgenommene Performance dramatisch:
// Next.js Route Handler — Streaming-Antwort
export async function POST(req: Request) {
const stream = await openai.chat.completions.create({
model: 'gpt-4o',
messages: [...],
stream: true,
});
return new Response(
new ReadableStream({
async start(controller) {
for await (const chunk of stream) {
const text = chunk.choices[0]?.delta?.content || '';
controller.enqueue(new TextEncoder().encode(text));
}
controller.close();
},
}),
{ headers: { 'Content-Type': 'text/event-stream' } }
);
}
Time-to-first-token unter 400 ms fühlt sich "instant" an — auch wenn die volle Antwort 3 s dauert.
5. Qualitäts-Monitoring
LLMs halluzinieren. Das ist nicht behebbar — aber messbar:
- Evaluation-Suite — feste Frage-Antwort-Paare, regelmäßig durch das System schicken,
Antworten mit
LLM-as-Judgegegen Soll-Antworten vergleichen. - User-Feedback-Signal — Daumen-hoch/runter ins UI einbauen, in DB persistieren, schlechte Patterns clustern.
- Hallucination-Detection — bei RAG: Antwort + zugrunde liegende Chunks zu einem zweiten Modell schicken, das prüft, ob die Antwort durch die Chunks gedeckt ist.
Konkrete Zahl: Eval-Suite mit 200 Test-Queries läuft nightly, kostet ~2 $/Tag, fängt Regressionen nach Modell-Updates bevor sie der Nutzer merkt.
Anti-Patterns
- Alles in einen Mega-Prompt stopfen — System-Prompt + User-Prompt + alle Daten in einem 50 K-Token-Block. Teuer, langsam, schlechte Qualität. Lieber Chain-of-Thought mit gezielten Tool-Calls.
- Keine Kostenkontrolle — pro User-ID einen täglichen Token-Cap einbauen, sonst ruiniert ein einzelner Bot dein Budget.
- PII direkt an externe APIs schicken — DSGVO-Risiko. Vor dem Versand maskieren oder lokale Modelle für sensible Tasks nutzen.
Wann lokal, wann Cloud?
| Use Case | Empfehlung |
|---|---|
| FAQ-Bot, Klassifikation | Lokale Modelle (Llama 3.1 8B via Ollama) oder Haiku |
| Komplexes Reasoning | Claude Opus / GPT-4o |
| Embeddings | bge-m3 lokal (kostenlos) oder OpenAI für Bequemlichkeit |
| Vertrauliche Daten | Immer lokal oder EU-gehostete Anbieter |
| Code-Generierung | Claude Sonnet/Opus, Cursor |
Nächste Schritte
- Self-Hosted Supabase mit Docker — die DB-Basis für RAG-Pipelines
- Cost-Tracking für LLM-Apps — folgt
Bei Bedarf an einer LLM-Integration in dein bestehendes System — ob RAG-Pipeline, Customer-Support-Bot oder interner Coding-Assistant — hier entlang.
In Praxis
Verwandte Artikel
- KI / AI· 3 gemeinsame Tagspgvector als RAG-Backbone — wann es reicht und wann du eine dedizierte Vector-DB brauchst
- KI / AI· 2 gemeinsame TagsDSGVO-konforme KI-Integration: EU-Hosting, On-Premise-LLMs & Datenschutz-Best-Practices
- DevOpsCoolify als Heroku-Replacement — Self-Hosted PaaS in der Praxis
- FullstackNext.js 16 + Supabase Auth — der saubere SSR-Flow ohne flackernde Login-States