HybridAI now supports the just released new family of GPT Models from OpenAI for the API. Especially GPT-4.1 nano is of interest because it opens a new category of small but fast and cheap models. It’s indeed a bit faster compared to GPT -4o-mini – the so far default model on our platform, yet similarly intelligent and capable.
We also move to Gemini 2.0 flash as you can see, a very impressing and super fast model by Google.
The new perplexity family is live since a few days already, too. Enjoy!
„Was mir Angst gemacht hat, gibt mir heute neue Möglichkeiten. KI ist kein Ersatz für uns. Sie ist ein Werkzeug, das wir lernen müssen zu nutzen.“
Als ich das erste Mal bewusst von den rasanten Entwicklungen im Bereich der Künstlichen Intelligenz gehört habe, war da vor allem eins: Unsicherheit. Und ja, auch Angst. KI war etwas völlig Neues und Unbekanntes. Etwas, das unser Leben, unsere Arbeitswelt und unsere Zukunft grundlegend verändern könnte. Ich wusste nicht, wie ich damit umgehen sollte oder welche Auswirkungen es auf mich persönlich und auf die Gesellschaft haben würde.
Ein Teil dieser Angst ist auch heute noch da. Aber sie ist viel kleiner geworden. Der Grund dafür ist, dass ich begonnen habe, mich mit dem Thema auseinanderzusetzen. Besonders durch meine Weiterbildung zur KI-Managerin habe ich nicht nur Fachwissen aufgebaut, sondern auch ein tieferes Verständnis dafür entwickelt, was KI kann und wo ihre Grenzen liegen.
In den letzten Jahren hat sich künstliche Intelligenz enorm weiterentwickelt. Sprachmodelle wie ChatGPT führen heute flüssige Gespräche, schreiben Texte, übersetzen Inhalte oder helfen beim Programmieren. KI kann Bilder analysieren oder sogar komplett neu generieren. In der Medizin unterstützt sie bei Diagnosen, in der Mobilität ermöglicht sie autonomes Fahren, und in der Kundenbetreuung verbessert sie den Service durch intelligente Chatbots. Selbst in alltäglichen Dingen wie Produktempfehlungen, Navigation oder Terminplanung ist KI längst angekommen.
Diese Entwicklungen sind nicht nur faszinierend, sondern auch unglaublich nützlich. Sie zeigen, wie sehr uns KI im Alltag unterstützen kann.
Sie ersetzt uns nicht, sie hilft uns. Sie nimmt uns wiederkehrende Aufgaben ab, sorgt für effizientere Prozesse und schafft Raum für Kreativität und Innovation. In vielen Berufen ist sie bereits ein wertvoller Begleiter.
Was ich dabei besonders wichtig finde: KI funktioniert nicht ohne den Menschen. Sie braucht unsere Anleitung, unsere Werte, unsere Entscheidungen. Wir gestalten, prüfen, kontrollieren und tragen Verantwortung. Die Technologie ist ein Werkzeug, aber die Richtung, in die wir es einsetzen, bestimmen wir.
Genau deshalb möchte ich anderen Mut machen. Wenn dir eine neue Entwicklung Angst macht, dann hilft es, dich damit zu beschäftigen. Je mehr du verstehst, desto klarer wird das Bild. Wissen gibt Sicherheit. Und das Gefühl, selbst mitgestalten zu können, nimmt die Ohnmacht.
Künstliche Intelligenz verändert unsere Welt. Aber sie tut es nicht gegen uns, sondern mit uns. Wir müssen nur bereit sein, uns darauf einzulassen.
Ja, die Aussage kommt in der aktuellen KI-Hype-Gesprächslage ja fast einem Selbstmord gleich, aber ich will kurz erklären, warum wir bei HybridAI zu dem Schluss gekommen sind, erstmal keinen MCP Server einzurichten oder anzusprechen.
MCP-Server sind ein (man muss vll. sagen derzeit noch „gewollter“) Standard der von Anthropic entwickelt und gepusht wird und derzeit extrem viel Wiederhall findet in der AI-Community.
Bei einem MCP-Server geht es darum die für aktuelle „agentic“ KI-Anwendungen so wichtigen Tool-Calls (oder „function-calls“) zu standardisieren, also genaugenommen die Schnittstelle vom LLM (tool-call) zur Schnittstelle des externen Service oder Tools, meist irgendeine Rest-API oder so.
Bei HybridAI haben wir ja schon lange auf eine starke Implementierung von function-calls gesetzt, insofern können wir auf ein paar dutzend implementierte und in Produktion befindlicher function-calls zurückschauen die von inzwischen mehr als 450 KI-Agents teilweise genutzt werden. Also schon ein bisschen Erfahrung in dem Thema. Wir nutzen auch N8N für bestimmte cases, das ist nochmal ein Layer auf dem Thema, der relevant ist im praktischen Alltag. Unsere Agents haben auch APIs nach aussen über die sie angesprochen werden, wir kennen das Problem also sogar in beide Richtungen (d.h. wir könnten sowohl einen MCP Server einrichten für unsere Agents als auch andere MCPs abfragen in unseren function-calls).
Also warum finde ich dann MCP-Server nicht total cool?
Ganz einfach: er löst ein Problem das es mE kaum gibt und lässt die zwei viel wichtigeren Probleme bei function-calls und damit agentischen Setups ungelöst.
Erstmal: warum gibt es das Problem der zu standardisierenden Fremd-Tool APIs eher nicht? Das hat zwei Gründe. (1) bestehende APIs und Tools haben meistens REST-APIs oder was ähnliches, also eine bereits standardisierte Schnittstelle. Diese ist zudem ziemlich stabil was man allein daran erkennt dass viele API-URLs noch ein „/v1/…“ im Aufruf haben oder vielleicht auch schonmal „/v2/…“. Aber die sind eigentlich sehr stabil und gut ansprechbar. Selbst wenn es neue Interfaces gibt, bleiben die alten Endpoints oft online für sehr lange Zeit. Und noch ein Punkt: gerade ältere APIs sind oft spannend, also z.B. die API der ISS oder die des europäischen Patent-Amtes oder die irgendeiner Open-Data API einer Stadt. Diese Services werden auch nicht so schnell MCP-Interfaces dafür anbieten – ergo muss man sich eh mit den alten APIs rumschlagen noch sehr lange. Dazu kommt Punkt (2), und bei dem wundert es mich ein bisschen mit dem MCP-Hype. Denn LLMs sind eigentlich ziemlich cool darin alte APIs abzufragen, viel cooler als andere Systeme die ich da schon kennengelernt habe – denn: man schmeisst ja den API-Output eigentlich nur in das LLM rein und lässt es antworten. Kein Parsing, kein Error-Handling, keine XML-Syntax durchdringen. Macht alles das LLM und das ziemlich reliable und fehlertolerant. Also wozu eigentlich der MCP-Server um das zu abstrahieren?
Also, MCP löst ein Problem (und fügt ja einen weiteren Tech-Layer hinzu), das eigentlich im realen tool-calling Alltag gar nicht so groß ist.
Größer sind dafür folgende zwei Probleme die wirklich nervig sind und andere Lösungen bräuchten in der nahen Zukunft:
–> Tool-Auswahl
–> Tool-Execution und Code-Security
Tool-Auswahl: Agentische Lösungen zeichnen sich ja dadurch aus, dass mehrere tools, ggf. sogar sequentiell verschaltet werden können und das LLM selbst entscheiden kann, welche es nimmt und in welcher Kombination. Wie das abläuft kann man mühevoll mit der Beschreibung des Tools beeinflussen, das ist quasi ein kleiner Mini-Prompt der die Funktion und Ihre Argumente beschreibt. Und da kann es sehr schnell ziemlich drunter und drüber gehen. Wir haben z.b. einen Tool-Call der Perplexity aufruft bei Anfragen mit aktuellem Bezug („wie ist das Wetter heute…“). Oft called das LLM den aber auch, wenn irgendwas anderes gefragt wird was ein bisschen komplizierter ist. Oder es wird der Tool-call für die WordPress-Search-API getriggered, obwohl wir eigentlich die Web-Search über GPT-4.1 mit Websearch haben wollten. Diese Baustelle empfinde ich als ziemlich messy aktuell und das soll ja noch viel autonomer und komplexer werden. Wie die LLMs mit verschiedenen tools umgehen unterscheidet sich auch noch signifikant, aber nicht sehr deterministisch und schlecht dokumentiert.
Tool-Execution: Ein richtig fettes Problem auch für Skalierung aber eben auch Security steckt in der eigentlichen Tool-Code Execution. Denn die – das wissen viele nicht – findet ja lokal auf Deinem eigenen System statt. D.h. eigentlich müssten wir bei HybridAI unseren Kunden anbieten uns Code anzuliefern, der dann als Tool-Call für sie hinterlegt und aktiviert und eben auch ausgeführt wird, wenn das LLM es will. Das ist aber hinsichtlich Code-Integrity, Plattform Stabilität und Sicherheit ein ziemlicher Albtraum (wer jemals ein WordPress-Plugin eingereicht hat weiß, wovon ich rede). Aber das ist ein sehr wichtiges Problem, das übrigens noch viel größer wird, wenn der „Operator“ oder das „computer use“ tool stärker verwendet werden – denn auch die laufen lokal ab und nicht bei OpenAI.
Für diese beiden Probleme hätte ich gerne Ideen, also vielleicht ein TOP (Tool-Orchestration-Protocol) oder ein TEE (Tool Execution Environment). Aber einen MCP brauchen wir erstmal nicht.
