aeternum

KI-Entwicklung, die als Software ausgeliefert wird und nicht als Demo.

Retrieval, Agents und Modell-Integration, gebaut mit denselben Tests, Schnittstellen und der Fehlerbehandlung wie der Rest deines Produkts.

Ein Modell ist eine Komponente, kein Produkt. Wir testen es auch so.

  • RAG & Retrieval
  • Agents & Automation
  • LLM-Integration
  • Evaluation

Was KI-Entwicklung hier bedeutet

Ein KI-Feature ist gewöhnliche Software mit einer probabilistischen Komponente in der Mitte. Es braucht ein Schema, Fehlerbehandlung, Retries und einen Weg festzustellen, ob es letzten Dienstag schlechter geworden ist. Am Letzten scheitern die meisten LLM-Projekte, deshalb bauen wir die Evaluation, bevor wir das Feature bauen.

Aeternum behandelt ein Modell wie einen Zahlungsanbieter: eine Abhängigkeit mit Vertrag, mit einem Fehlerfall und mit einer Testsuite davor.

Was wir bauen

  • Retrieval (RAG). Dokumenten-Ingestion, Chunking, Embeddings und eine Retrieval-Schicht, in die du hineinschauen kannst. Eine falsche Antwort lässt sich auf die Textstelle zurückführen, die sie verursacht hat.
  • Agents und Automation. Tool-Calling-Workflows mit klaren Grenzen: was das Modell allein tun darf, was einen Menschen braucht, und was passiert, wenn ein Tool-Aufruf scheitert.
  • LLM-Integration. Modellaufrufe hinter einer einzigen Schnittstelle, mit Prompt, Ausgabeschema und Retry-Regeln in der Versionskontrolle neben allem anderen.
  • Evaluation. Ein bewertetes Testset, das in der CI läuft. Qualität wird damit zu einer Zahl, die du beobachten kannst, statt zu einem Eindruck.

Warum die Evaluation zuerst kommt

Ein Modell-Upgrade verbessert neun deiner Prompts und macht den zehnten still kaputt. Ohne bewertetes Testset gibt es keinen Weg herauszufinden, welcher es war, und keine Grundlage, mit einem Kunden darüber zu reden.

Wir sammeln das Set aus echten Eingaben, bevor der erste Prompt geschrieben wird. Es ist der Unterschied zwischen einem Feature, das du ändern kannst, und einem, das niemand mehr anfassen will.

Wovon wir dir abraten

Chat-Oberflächen, die auf Produkte geschraubt werden, die keine brauchen. Ist die eigentliche Aufgabe ein Formular mit sechs Feldern, dann ist ein Formular mit sechs Feldern für die Nutzerinnen und Nutzer schneller und für dich günstiger. Wir bauen lieber die kleine Sache, die funktioniert.

Wie ein Build abläuft

  1. Die Aufgabe finden, nicht das Modell

    Wir starten bei der Arbeit, die heute jemand von Hand macht, und dabei, wie lange sie dauert. Hat diese Arbeit kein messbares Resultat, kann ein LLM sie nicht verbessern, und wir sagen es dir, bevor du etwas ausgibst.

  2. Zuerst das Evaluationsset

    Ein fester Satz echter Eingaben mit bewerteten Sollausgaben, geschrieben vor dem ersten Prompt. Jede Prompt- und Modelländerung wird ab da dagegen gemessen.

  3. Das Feature um den Aufruf herum bauen

    Typisierte Schnittstellen, Retries, Timeouts, Fallbacks und ein protokollierter Trace pro Anfrage. Der Modellaufruf ist eine Komponente inmitten ganz normaler Software.

  4. Mit der Evaluation in der CI ausliefern

    Das Testset läuft bei jedem Pull Request. Eine Regression lässt einen Build scheitern, statt drei Wochen später in einer Kundendemo aufzutauchen.

Fragen zu AI Engineering.

Was ist RAG, in einem Satz?

Retrieval-augmented Generation ist das Muster, bei dem ein System zuerst in deinen eigenen Dokumenten nach passenden Stellen sucht und diese dem Sprachmodell als Kontext mitgibt, damit die Antwort auf deinen Inhalten beruht und nicht auf den Trainingsdaten des Modells.

Mit welchen Modellen arbeitet ihr?

Das entscheiden wir pro Projekt und prüfen es neu, denn die Rangfolge ändert sich alle paar Monate, und eine einmal getroffene Wahl ist eine veraltende Wahl. Jeder Modellaufruf liegt hinter einer einzigen Schnittstelle, mit Prompt und Ausgabeschema daneben. Ein Anbieterwechsel ist damit Konfiguration und kein Rewrite.

Wie verhindert ihr, dass das Modell Dinge erfindet?

Drei Massnahmen, nach Wirkung geordnet. Jede Antwort auf gefundenen Textstellen abstützen und diese zitieren, die Ausgabe auf ein Schema zwingen, das der Code prüft, und die gesamte Pipeline gegen ein festes Testset bewerten, damit eine Verschlechterung sichtbar wird. Halluzination ist eine messbare Rate und kein Ja oder Nein.

Wo liegen die Daten des Kunden?

Dort, wo du es erlaubst, und das klären wir, bevor die erste Zeile Code entsteht. Wir halten fest, welche Daten deine Systeme verlassen würden, was die Anbieterbedingungen zur Speicherung sagen, und ob die Aufgabe stattdessen ein Modell in einer Infrastruktur erledigen kann, die du bereits kontrollierst. Ändert die Antwort den Entwurf, willst du das in Woche eins wissen.

Beiträge dazu

  1. Die KI-Verordnung wurde verschoben. Drei Teile davon nicht.KI4 Min. Lesezeit
  2. Warum ein eigenes Modell in der Schweiz Sinn ergeben kannKI5 Min. Lesezeit
Alle Beiträge

Erzähl uns, was du bauen möchtest.

Schick uns das Briefing. Scope und Rahmen bekommst du innerhalb von zwei Arbeitstagen.