Wie die Engine mit jedem Modell spricht, das Sie mitbringen

Bringen Sie jedes Modell mit, das Sie wollen. Die KI-Schicht von RakuAI besteht aus Schnittstellen, nicht aus Imports – der Modellmarkt kann sich also vierteljährlich streiten, wer der Beste ist, und Ihre Engine muss sich nie darum kümmern.

Jemand stellte mir dieses Wochenende eine scharfe Frage. „Wenn KI ein Runtime-Grundbaustein in Ihrer Engine ist, dann ist die Engine an das Modell gebunden, das Sie eingebaut haben. Das nächste Mal, wenn der Modellanbieter sich bewegt, müssen Sie die Engine umschreiben.”

Berechtigte Sorge. Und falsch, aber berechtigt.

Der KI-Grundbaustein in der Runtime ist kein bestimmtes Modell. Es ist eine Schnittstelle. Fünf separate Subsysteme, jedes mit seiner eigenen C-API, jedes vom Rest der Engine aus ansprechbar, ohne dass irgendjemand wissen muss, welches Modell, welche Gewichte oder welcher Inferenzpfad die Antwort produziert. Modelle leben hinter der Schnittstelle. Aufrufer leben davor. Der Vertrag zwischen ihnen ist klein, stabil und absichtlich simpel gehalten.

Das ist der Beitrag darüber, wie diese Grenze gezogen ist, und warum ich immer mehr Wert daraus ziehe, sie gezogen zu haben.

Worauf „KI-Grundbaustein” tatsächlich zeigt

Die KI-Schicht in unserer Runtime ist nicht eine Sache. Sie sind fünf.

• Verhaltensbäume. Die deterministische Ausführungsschicht. Sagt einem Agenten, was zu tun ist, sobald die Absicht bekannt ist.
• Navigationsnetz und Pfadfindung. Die Schicht „wie bewege ich mich durch diesen Raum”.
• Crowd-Simulation. Die Schicht „wie weichen viele Agenten einander aus und verhalten sich kohärent zusammen”.
• Sensorische Systeme und Wahrnehmung. Die Schicht „was nimmt der Agent wahr”.
• Entscheidungsbäume und komplexe KI-Logik. Die Schicht „was will ich tun, gegeben alles, was ich weiß”.

Jede ist ihr eigenes Subsystem. Jede wird als eigene DLL ausgeliefert. Jede hat eine öffentliche C-API. Keine davon importiert ein bestimmtes Modell. Sie sprechen alle über ihre jeweiligen Schnittstellen mit dem Rest der Engine, und sie sprechen auf dieselbe Weise miteinander.

Wenn eine .raku-Erfahrungsdatei "ai_behavior": "strafe" sagt, benennt sie kein Modell. Sie benennt ein registriertes Verhalten. Die Runtime löst den String auf. Der String bildet auf eine Implementierung ab. Die Implementierung kann ein Verhaltensbaum sein, ein Entscheidungsbaum, eine gelernte Policy, oder eine handgeschriebene Heuristik. Der Aufrufer weiß es nicht. Die Datei weiß es nicht. Die Implementierung kann ausgetauscht werden, ohne dass eines von beidem angefasst wird.

Das ist der ganze Trick.

Die Modellverwaltungsschicht ist ihr eigenes Subsystem

Als wir echte Machine-Learning-Inferenz innerhalb der Runtime brauchten, haben wir sie nicht in eines der fünf oben genannten Subsysteme geflanscht. Wir haben ein sechstes Anliegen mit eigener API-Fläche hinzugefügt: Modellverwaltung.

// Roughly what the surface looks like, simplified for the post.
RakuModelHandle raku_ai_load_model(const char* model_id, RakuModelOptions opts);
RakuInferenceResult raku_ai_infer(RakuModelHandle h, const RakuTensor* input);
void raku_ai_unload_model(RakuModelHandle h);

Ein Behavior-Tree-Knoten, der ein Modell aufrufen möchte, geht über diese API. Nicht, indem er ein Vendor-SDK importiert. Nicht, indem er sich gegen eine bestimmte Runtime linkt. Indem er das Modellverwaltungs-Subsystem um ein Handle bittet und es benutzt.

Das bedeutet, das Modellverwaltungs-Subsystem ist die einzige Stelle in der Codebasis, die etwas über bestimmte Modellformate, Anbieter oder Inferenz-Frameworks weiß. Überall sonst in der Engine sieht man Handles und Tensoren. Ein Modell austauschen. Eine Runtime austauschen. Einen Anbieter austauschen. Nichts anderes muss sich ändern.

Das ist unglamouröse Infrastrukturarbeit. Sie ist auch das, was uns davor bewahrt, in Panik zu geraten, wenn das KI-Ökosystem seinen vierteljährlichen Wutanfall darüber hat, welches Modell das neue Beste ist.

Die Grenze schützt auch das Dateiformat

Werfen Sie einen Blick auf den ai-Block am Anfang einer beliebigen .raku-Erfahrungsdatei. Er hat Schlüssel wie:

"ai": {
  "dda_enabled": true,
  "target_flow_state": 0.7,
  "profiler_mode": "active"
}

Keiner davon benennt ein Modell. Sie benennen Fähigkeiten. „Dynamische Schwierigkeitsanpassung ist an. Die Runtime sollte auf einen Flow-Zustand von 0,7 abzielen. Der Profiler ist aktiv.” Die Runtime entscheidet, welche Subsysteme herangezogen werden, um diese Fähigkeiten zu liefern. Wenn die richtige Antwort dieses Quartal ein Verhaltensbaum ist, läuft das. Wenn es nächstes Quartal ein kleines On-Device-Modell wird, ändert sich die Datei nicht.

Jede Schnittstellengrenze, die Sie in einem System ziehen, ist eine Stelle, an der künftiger Wandel passieren kann, ohne Aufrufer zu brechen. Wir haben sie von Anfang an konsequent gezogen. Wir geben die Ersparnisse jetzt aus.

Warum das immer wichtiger wird, nicht weniger

Drei Gründe.

Erstens: Der Modellmarkt bewegt sich weiter. Das beste Modell des letzten Jahres ist das teure Modell dieses Jahres. Das Beste dieses Jahres ist im nächsten Jahr veraltet. Teams, die einen Modellanbieter fest in ihre Engine einprogrammiert haben, haben diese Integration inzwischen zwei- oder dreimal durchgeführt. Teams, die eine Modellverwaltungs-Schnittstelle dazwischengeschaltet haben, haben es einmal getan.

Zweitens: On-Device zählt mehr als früher. Die Schnittstelle erlaubt es uns, dasselbe ai_behavior: "strafe" gegen ein serverseitiges Modell in der Entwicklung und ein On-Device-Modell in der Produktion laufen zu lassen. Der Aufrufer weiß es nicht. Diese Flexibilität ist der einzige Grund, warum On-Device-Inferenz machbar ist, ohne die Erfahrungsschicht umzuschreiben.

Drittens: KI-Assistenten im Entwicklungskreislauf profitieren von sauberen Grenzen. Wenn ich einen Assistenten bitte, ein neues Verhalten hinzuzufügen, ist der Vertrag, den er einhalten muss, die Schnittstelle für registrierte Verhalten. Kein Knäuel aus Vendor-SDKs. Je sauberer die Schnittstelle, desto schneller produziert der Assistent korrekten Code, und desto kleiner sind die Review-Kosten auf meiner Seite.

Was daran schwer ist

Die ehrlichen Kosten.

Schnittstellendesign dauert länger als Implementierung. Es ist wirklich verlockend, den Schnittstellenschritt zu überspringen und einfach die funktionierende Version zu schreiben. Widerstehen Sie. Jede Abkürzung, die Sie hier nehmen, bezahlen Sie später, wenn Sie die Implementierung austauschen müssen.

Man muss diszipliniert sein, was in die Schnittstelle kommt. Jeder Parameter ist ein Vertrag, den man nicht leicht brechen kann. Fügen Sie weniger hinzu, als Sie zu brauchen glauben. Warten Sie auf den zweiten Anwendungsfall, der Ihnen zeigt, was tatsächlich allgemein ist. Die erste Version der KI-Schnittstelle hatte fünf Parameter, die sich als nicht dort hingehörig herausstellten. Sie später zu entfernen war schmerzhaft.

Registrierte Verhalten brauchen Versionierung. Wenn "strafe" in einem Build der Runtime eine Sache bedeutet und im nächsten eine leicht andere, erfahren Aufrufer das über Gameplay-Regressionen. Wir versionieren Verhalten und pinnen .raku-Dateien auf Runtime-Versionen. Es ist lästig. Es ist notwendig.

Manchmal will man die Abhängigkeit tatsächlich. Das ist der ketzerische Punkt. Es gibt Fälle, in denen ein bestimmtes Modell eine bestimmte Fähigkeit hat, die keine generische Schnittstelle ausdrücken kann. Der ehrliche Schritt ist, die Schnittstelle zu erweitern, damit die Fähigkeit generisch wird, statt das Modell in den Aufrufer durchsickern zu lassen. Wir haben uns schon mehr als einmal dabei ertappt, die Abkürzung nehmen zu wollen.

Das architektonische Argument ist einfach. KI ist ein Runtime-Grundbaustein. Das Dateiformat, das sie antreibt, benennt Fähigkeiten, keine Modelle. Die Runtime löst Fähigkeiten zu welchem Subsystem auch immer sie gerade liefert auf. Der Draht zwischen den drei Schichten ist die Schnittstelle. Die Schnittstelle ist klein, stabil und absichtlich simpel.

Das ist der ganze Beitrag.

Zurück zum Bauen.