.NET wird KI-nativ: Wie IChatClient und IVectorStore den Anbieterwechsel überflüssig machen

Wer heute eine KI-Funktion in eine .NET-Anwendung einbaut, bindet sich in der Regel fest an einen Anbieter: Der SDK-Aufruf für OpenAI sieht anders aus als der für Azure AI, und ein lokales Modell über Ollama spricht wieder ein eigenes Protokoll. Wechselt das Unternehmen später den Anbieter – etwa aus Kosten-, Datenschutz- oder Compliance-Gründen – bedeutet das oft, große Teile der Integrationslogik neu zu schreiben.

Genau dieses Problem adressiert Microsoft mit Microsoft.Extensions.AI: einer einheitlichen Abstraktionsschicht für KI-Funktionen in .NET, die inzwischen fester Bestandteil des Ökosystems ist. Im Zentrum stehen zwei Schnittstellen, die den Unterschied machen: IChatClient und IVectorStore.

Das Problem: KI-Anbindung als Einbahnstraße

Ohne Abstraktionsschicht landet der SDK-Aufruf des jeweiligen Anbieters direkt im Anwendungscode – verteilt über Controller, Services und teils auch die Business-Logik. Jede Anfrage, jedes Antwortformat, jede Streaming-Logik ist anbieterspezifisch formuliert. Ein Wechsel von OpenAI zu Azure AI oder zu einem lokal gehosteten Modell zieht dann Änderungen an vielen Stellen im Code nach sich – von Tests einmal ganz abgesehen, denn ohne Abstraktion lässt sich ein KI-Aufruf kaum sauber mocken.

IChatClient: eine Schnittstelle für alle Chat-Modelle

IChatClient aus dem Paket Microsoft.Extensions.AI.Abstractions definiert eine gemeinsame Schnittstelle für Chat-Interaktionen mit einem Sprachmodell – unabhängig davon, ob es sich um ein Cloud-Modell oder ein lokal laufendes Modell handelt. Jede .NET-Bibliothek, die einen LLM-Client bereitstellt, kann diese Schnittstelle implementieren; die eigene Anwendung programmiert dann gegen die Abstraktion statt gegen ein konkretes SDK.

In der Praxis sieht die Registrierung über Dependency Injection typischerweise so aus:

csharp

builder.Services.AddChatClient(chatClientBuilder => chatClientBuilder
    .UseLogging()
    .UseFunctionInvocation()
    .UseDistributedCache()
    .UseOpenTelemetry()
    .Use(new OpenAIClient(apiKey).AsChatClient("gpt-4o-mini")));

Der eigene Anwendungscode kennt danach nur noch IChatClient und muss sich um Details wie Retry-Logik, Logging oder Tracing gar nicht mehr kümmern – diese Middleware-Bausteine lassen sich einfach in die Kette einhängen. Für einen Wechsel des Anbieters genügt es, an dieser einen Stelle die konkrete Client-Implementierung auszutauschen; der Rest der Anwendung bleibt unverändert.

IVectorStore: dieselbe Idee für Vektordatenbanken

Für Retrieval-Augmented-Generation-Szenarien (RAG), bei denen die eigenen Unternehmensdaten als Kontext für ein Sprachmodell aufbereitet werden, kommt eine zweite Abstraktion ins Spiel: IVectorStore aus Microsoft.Extensions.VectorData. Sie kapselt das Indizieren und Durchsuchen von Embeddings – unabhängig davon, ob im Hintergrund Azure AI Search, Qdrant, Milvus oder Pinecone läuft.

Der architektonische Vorteil liegt auf der Hand: Anwendungscode, der gegen IVectorStore programmiert, bleibt von der konkreten Datenbank entkoppelt. Ein Wechsel der Vektordatenbank – etwa weil sich Preis- oder Hosting-Anforderungen ändern – betrifft wieder nur die Registrierung, nicht die Fachlogik.

Warum das mehr ist als Komfort

Der eigentliche Wert dieser Abstraktionsschicht zeigt sich, sobald sich Rahmenbedingungen ändern – und genau das passiert bei KI-Projekten häufig:

• Datenschutz und Compliance: Ein Unternehmen startet mit einem Cloud-Modell, muss aber später aus regulatorischen Gründen auf ein On-Premises- oder EU-gehostetes Modell wechseln. Mit IChatClient bleibt das ein Konfigurationsdetail statt eines Rewrites.
• Kostenkontrolle: Steigen die Kosten eines Anbieters, lässt sich ein günstigeres Modell oder ein lokal betriebenes Open-Weight-Modell einsetzen, ohne die Anwendung neu zu architektieren.
• Testbarkeit: Da IChatClient und IVectorStore Interfaces sind, lassen sie sich in Unit-Tests problemlos durch Mocks ersetzen – ein KI-Aufruf muss für einen Test nicht mehr tatsächlich ein Modell erreichen.
• Middleware statt Boilerplate: Logging, Caching, Function-Calling und Telemetrie lassen sich einmal zentral konfigurieren und gelten dann für jeden angeschlossenen Provider gleichermaßen.

Einordnung: Teil eines größeren Bilds

IChatClient und IVectorStore sind kein isoliertes Feature, sondern Teil eines größeren Trends: .NET positioniert sich zunehmend als Plattform, auf der sich klassische Geschäftslogik und KI-Funktionen im selben Projekt, mit denselben Werkzeugen für Dependency Injection, Logging und Tests entwickeln lassen. Wer bereits mit ASP.NET Core und Entity Framework Core arbeitet, muss für den Einstieg in KI-Funktionen kein komplett neues Ökosystem lernen – die Abstraktionen fügen sich in vertraute Muster ein.

Unsere Einschätzung

Für Unternehmen, die KI-Funktionen nicht nur ausprobieren, sondern langfristig produktiv betreiben wollen, ist diese Abstraktionsschicht ein handfestes Argument für .NET als Plattform. Die Bindung an einen einzelnen KI-Anbieter war in den letzten Jahren eines der größten Risiken bei KI-Projekten – technisch wie vertraglich. Mit IChatClient und IVectorStore lässt sich dieses Risiko von Anfang an in der Architektur entschärfen, statt es nachträglich mit hohem Aufwand zu beheben.

Wenn Sie überlegen, KI-Funktionen in eine bestehende .NET-Anwendung zu integrieren oder ein neues Projekt von vornherein anbieteroffen aufzubauen – sprechen Sie uns gerne an. Wir unterstützen Sie von der Architekturentscheidung bis zur konkreten Umsetzung.