Die Frage, wie groß ein solches Modell sein darf, hat keine einzelne Antwort in Megabyte. Sie hat zwei Budgets, die unterschiedlich funktionieren, und einen Posten, der fast immer unterschätzt wird.

Warum ein 3D-Modell anders lädt als ein Video

Ein Produktvideo wird einmal berechnet und dann nur abgespielt. Ein 3D-Modell im Browser zeichnet dagegen die Grafikkarte des Besuchers bei jeder Bewegung neu, aus Dreiecken für die Oberfläche und aus Texturen, also Bildern für Farbe und Material. Deshalb kann ein Kunde die Einhausung drehen oder eine andere Füllung wählen, und deshalb entscheidet sein Gerät, ob das flüssig gelingt.

Ein Konfigurator liegt zwischen zwei Extremen. Ein Video legt jedes Bild vorher fest, ein CAD-Programm lässt jedes Maß offen, und im Konfigurator stehen die Regeln fest, innerhalb derer der Kunde frei wählt.

Für die Frage nach der Größe heißt das: Die Last trägt das Gerät des Kunden. Die Grenze setzt deshalb das schwächste Gerät, mit dem Ihre Zielgruppe das Modell öffnet.

Zwei Budgets, die man getrennt rechnen muss

Das erste Budget ist die Übertragung. Geometrie, Texturen und der Programmcode für die Darstellung müssen über das Netz, und ihre Summe bestimmt zusammen mit der Bandbreite, wie lange der Kunde wartet. Verdichtungsverfahren machen die Daten für den Transport kleiner.

Das zweite Budget ist der Grafikspeicher. Um zu zeichnen, hält das Gerät Geometrie und Texturen in einer Form vor, mit der die Grafikkarte direkt arbeiten kann, und diese Form ist oft viel größer als die übertragene Datei. Reicht der Speicher nicht, ruckelt die Darstellung, oder die Seite bricht ab.

Die beiden Budgets verhalten sich unterschiedlich. Eine gut verdichtete Datei lädt schnell und kann trotzdem den Grafikspeicher eines Telefons überfordern, und eine Datei, die in den Speicher passt, kann trotzdem zu lange laden.

Warum meist die Texturen den Ausschlag geben

Die Größe einer Textur wächst mit dem Quadrat ihrer Kantenlänge. Eine Textur mit 2.048 mal 2.048 Bildpunkten hat viermal so viele Bildpunkte wie eine mit 1.024, und jedes Material trägt oft mehrere davon, etwa für Farbe, Oberflächenstruktur und Rauheit. Bei acht Materialien mit je drei Texturen sind das bereits 24 Bilder.

Hinzu kommt der Unterschied zwischen Datei und Speicher. JPG und PNG sind für die Übertragung verdichtet, die Grafikkarte kann mit diesen Formaten aber nicht zeichnen, deshalb werden sie vorher vollständig entpackt. Zusätzlich hält das Gerät meist verkleinerte Fassungen jeder Textur für entfernte Ansichten vor, was den Bedarf um rund ein Drittel erhöht.

Texturen im Format KTX 2.0 gehen einen anderen Weg. Sie werden beim Laden in ein Format umgewandelt, das die Grafikkarte auch danach verdichtet halten kann, und senken so nach Angaben der Khronos Group den Grafikspeicher. Über eine Erweiterung lassen sie sich direkt in glTF-Dateien einbetten, das gängige Lieferformat für 3D im Web.

Es ist wie bei Akten: Im Ordner brauchen sie wenig Platz, ausgebreitet auf dem Schreibtisch sehr viel. Eine JPG-Textur liegt auf der Grafikkarte ausgebreitet, eine Textur im GPU-Format bleibt im Ordner.

Rechnen Sie das Ladebudget der Einhausung nach

Der Rechner trennt beide Budgets und prüft sie gegen drei angenommene Geräteklassen. Voreingestellt ist die Einhausung, wie sie aus einem Renderprogramm kommen könnte: 900.000 Dreiecke, acht Materialien mit je drei Texturen in 2.048 Bildpunkten, JPG-Texturen und verdichtete Geometrie. Alle Werte sind Beispielwerte, auch die Annahmen zu Bandbreite und Grafikspeicher der Geräteklassen.

Achten Sie auf die Zeile Smartphone. Schalten Sie dann das Texturformat von JPG auf KTX2 und senken Sie danach die Texturauflösung auf 1.024.

In der Voreinstellung überträgt das Modell rund 25 Megabyte, davon rund 21 Megabyte Texturen, und belegt 537 Megabyte Grafikspeicher. Mit KTX2 sinkt der Grafikspeicher in der Rechnung auf 89 Megabyte, das Telefon lädt aber immer noch zu lange. Erst mit 1.024 Bildpunkten fällt die Ladezeit auf rund 7,5 Sekunden, und das Urteil wechselt auf „läuft mit Abstrichen“.

Was die Rechnung über das Beispiel verrät

Die Geometrie ist in diesem Beispiel der kleinere Posten, solange sie verdichtet wird. Verdoppeln Sie die Dreiecke auf 1,8 Millionen, wächst die Übertragung nur um rund drei Megabyte. Schalten Sie die Verdichtung aus, wird die Geometrie mit rund 25 Megabyte zum größten Posten, und schon das Notebook lädt zu lange.

Die Texturauflösung ist der stärkste Hebel. Mit 4.096 Bildpunkten vervierfachen sich die Texturen, und in der Rechnung scheitert selbst der Bürorechner an der Ladezeit. Welche Auflösung ein Material braucht, hängt davon ab, wie nah der Kunde herangehen kann: Eine Füllung aus Drahtgitter, die nie näher als einen Meter vor der Kamera erscheint, braucht keine Textur für die Lupe.

Die Rechnung ist bewusst einfach. Sie kennt keine Zeichenaufrufe, keine Schatten und kein schrittweises Nachladen, und ihre Faktoren für Verdichtung und Speicher sind Annahmen. Sie zeigt Größenverhältnisse und sagt nicht voraus, wie ein bestimmtes Modell auf einem bestimmten Gerät läuft.

Wie ein Konfigurator von innen aufgebaut ist

Das Ladebudget betrifft nur eine von sechs Stufen, die ein Modell auf dem Weg von der Konstruktion zum Kunden durchläuft. Die meisten Vorhaben stocken dabei weniger an der Grafik als am Regelwerk.

Modell. Die Geometrie braucht benannte Bauteile wie Pfosten, Tür und Füllung, Maße in Millimetern und einen festen Ursprung. Kommt das Modell als einzelnes Netz ohne benannte Teile aus einem Renderprogramm, weiß die Software nicht, wo die Tür aufhört, und jede Variante wird Handarbeit.

Regelwerk. Hier steht, welche Optionen es gibt, welche sich ausschließen und welche Grenzmaße gelten. Oft stecken diese Regeln im Kopf weniger Personen, oder Preisliste und Konfigurator führen getrennte Optionslisten, die auseinanderlaufen.

Varianten. Der eingestellte Zustand gehört an eine Stelle, die ein Link mitnehmen kann, etwa in die Adresse der Seite. Lebt er nur im Speicher des Browsers, löscht die Zurück-Taste die Auswahl, und niemand kann seine Konfiguration weiterschicken.

Preisgerüst und Stückliste. Mengen sollten aus derselben Geometrie stammen wie das Bild, sonst weicht eine getrennt gepflegte Stückliste irgendwann ab. Preisstaffeln gehören nicht in den Browser, weil jeder sie dort auslesen kann.

Darstellung. Material, Licht, Kamera, Beschriftung und Ladereihenfolge entscheiden über das Ladebudget. Dazu gehört die Entscheidung, wann nicht gezeichnet wird, denn ein endlos rotierendes Modell leert Akkus.

Ausgabe. Am Ende steht, was der Kunde abschickt: eine Anfrage mit vollständigem Zustand, eine Stückliste oder eine Datei für die Fertigung. Kommt die Anfrage ohne Konfiguration an, baut der Innendienst von Hand nach, was der Kunde schon eingestellt hatte.

Wie eine parametrische Definition als Dienst hinter einem solchen Konfigurator laufen kann, beschreibt Vom Grasshopper-Modell zum Web-Konfigurator. Zwei Rechner, die Mengen und Dateien aus einer Regel ableiten, sind der Fassaden-Rationalisierer und der Nesting-Rechner.

Was vor dem Export geklärt sein sollte

Die meisten Größenprobleme entstehen beim Export, und die meisten lassen sich mit wenigen Entscheidungen davor vermeiden. Nach Wirkung sortiert sind es sechs.

1. Die schwächste Geräteklasse der Zielgruppe festlegen und beide Budgets für sie rechnen.
2. Die Texturauflösung je Material nach dem kleinsten Betrachtungsabstand wählen.
3. Texturen zwischen Materialien teilen und wiederholen, statt jede Fläche einzeln zu bemalen.
4. Ein GPU-taugliches Texturformat prüfen, wenn der Grafikspeicher knapp ist.
5. Geometrie für die Auslieferung verdichten und Details entfernen, die aus Betrachtungsabstand nicht sichtbar sind, etwa Gewinde, Schrauben und innenliegende Teile.
6. Die Browserfassung automatisch aus der Konstruktion ableiten, statt sie von Hand nachzubauen.

Der letzte Punkt entscheidet über die Pflege. glTF ist nach Beschreibung der Khronos Group ein Format für die effiziente Übertragung und das Laden von 3D-Szenen, also ein Lieferformat und kein Arbeitsformat. Wird die Browserfassung bei jeder Konstruktionsänderung neu erzeugt, bleibt sie aktuell, während ein von Hand nachgebautes Modell mit der ersten Änderung auseinanderläuft.

Wann ein Bild die bessere Wahl ist

Gibt es ein Produkt nur in wenigen Ausführungen, sind gute Fotos in Herstellung und Pflege günstiger als jedes 3D-Modell. Ob sich ein parametrisches Modell lohnt, hängt an Variantenzahl und Änderungshäufigkeit, wie Wann sich ein parametrisches Modell rechnet ausführt.

Nutzt die Zielgruppe vor allem ältere Telefone oder langsame Verbindungen, ist ein vorab berechnetes Bild oder ein kurzes Video robuster. Und fehlt ein sauberes Konstruktionsmodell, zeigt ein Konfigurator ungeprüfte Maße, nach denen womöglich jemand bestellt.

Ob ein Kunde das Modell zusätzlich im eigenen Raum sehen sollte, ist eine eigene Frage. Wann eine Maßprüfung genügt und wann AR hilft, behandelt Passt es in den Raum?, die Leistung selbst beschreibt die Seite 3D-Konfiguratoren.

Der naheliegende Plan heißt Neubau und Umstellung an einem festen Tag. Der andere Plan zieht die Module einzeln um, lässt Alt und Neu eine Zeit lang nebeneinander laufen und schaltet das Altsystem erst ab, wenn nichts mehr darauf zugreift. Welcher Plan trägt, hängt weniger an der Technik als an den Abhängigkeiten zwischen den Modulen, und die lassen sich vorher aufschreiben und durchrechnen.

Warum ein Stichtag so viel auf einen Tag legt

Bei einer Umstellung an einem Stichtag passiert alles gleichzeitig: Die Daten werden übertragen, alle Schnittstellen zeigen auf das neue System, alle Nutzer arbeiten ab Montag in neuen Masken. Jeder dieser Schritte kann einzeln gelingen und im Zusammenspiel trotzdem scheitern, und der Fehler zeigt sich erst, wenn der erste echte Auftrag durchläuft.

Ein Stichtag gleicht dem Umzug einer Werkhalle an einem Wochenende. Klemmt am Montag eine Maschine, steht die ganze Halle, weil die alte Aufstellung bereits abgebaut ist. Dazu kommt, dass sich eine Umstellung schwer zurücknehmen lässt, sobald im neuen System die ersten Belege entstanden sind: Wer zurückschaltet, muss diese Daten wieder in das Altsystem bringen.

Daraus folgt nicht, dass ein Stichtag immer falsch ist. Es folgt, dass das Risiko eines Stichtags mit der Zahl der Module wächst, die an diesem Tag gemeinsam funktionieren müssen. Genau diese Zahl lässt sich mit einer schrittweisen Ablösung klein halten.

Eine Weiche vor dem Altsystem

Martin Fowler beschreibt das Vorgehen unter dem Namen Strangler Fig, nach einer Feige, die an einem Wirtsbaum emporwächst, bis sie ihn ersetzt. Neue Funktionen entstehen getrennt vom Altsystem, beide laufen während des Übergangs nebeneinander, und das Verhalten wandert schrittweise vom alten in das neue System. Fowler betont, dass die Zerlegung in einzeln ersetzbare Teile der eigentliche Kern ist.

Technisch braucht das eine Stelle, an der sich entscheiden lässt, welches System eine Anfrage bearbeitet. Das kann eine vorgeschaltete Schnittstelle sein, über die Portal, Lager und Buchhaltung ohnehin sprechen, oder eine Datenbanksicht, hinter der die Tabellen umgezogen werden. Diese Weiche ist Übergangsarchitektur: Sie kostet Aufwand, obwohl sie am Ende wieder verschwindet, und sie ist trotzdem der Grund, warum jeder einzelne Umzug klein bleibt.

Fehlt eine solche Stelle, weil Nutzer und Fremdsysteme direkt in die Datenbank des Altsystems schreiben, beginnt die Ablösung mit ihrem Bau. Dieser erste Schritt bringt fachlich noch nichts Neues, er macht aber sichtbar, wer das Altsystem überhaupt benutzt.

Welches Modul zuerst umzieht

Nicht jedes Modul kann jederzeit umziehen. Die Rechnungen brauchen die Aufträge, die Aufträge brauchen die Kunden, und das Mahnwesen braucht die Rechnungen. Eine solche harte Abhängigkeit heißt: Ein Modul kann erst im neuen System laufen, wenn seine Voraussetzung dort bereits läuft, oder es zieht in derselben Stufe mit ihr um.

Daraus ergibt sich eine einfache Regel. Zuerst ziehen Randmodule um, auf die sich kein anderes Modul stützt, im Beispiel etwa Versand und Angebote. Ein früher Umzug an einer Stelle mit wenig Verkehr zeigt, ob Weiche, Datenabgleich und Betrieb funktionieren, bevor ein Modul an der Reihe ist, von dem der Umsatz abhängt.

Schwieriger sind Module, die sich gegenseitig brauchen oder deren Voraussetzung selbst lange warten muss. Dann entstehen gekoppelte Umzüge, bei denen zwei Module in derselben Stufe wechseln. Eine gekoppelte Stufe ist ein kleiner Stichtag innerhalb der schrittweisen Ablösung, und sie verdient die gründlichste Vorbereitung.

Den Stufenplan selbst durchrechnen

Der Rechner setzt diese Regeln um. Er nimmt eine Liste fachlicher Module, verteilt einen einstellbaren Anteil harter Abhängigkeiten und plant daraus Stufen, in denen höchstens so viele Module umziehen wie eingestellt. Schalten Sie zwischen Stichtag und schrittweise um und beobachten Sie, in welcher Stufe das Modul Rechnungen wechselt und ob die Stufe gestrichelt als Risiko markiert ist.

Mit den Beispielwerten der Voreinstellung, zehn Modulen, zwei Modulen je Stufe und drei harten Abhängigkeiten, entstehen fünf Stufen. Die Rechnungen ziehen erst in Stufe 4 um, gekoppelt an die Aufträge, die ihrerseits auf die Kunden warten. Als Stichtag gerechnet wechseln alle zehn Module in einer Stufe, und alle drei Abhängigkeiten werden zu gekoppelten Umzügen. Mit nur einem Modul je Stufe verschwindet das Risiko ganz, dafür wächst der Plan auf zehn Stufen.

Die Zahlen sind Stufen und keine Wochen. Wie lange eine Stufe dauert, hängt vom Modul, von den Daten und vom Parallelbetrieb ab. Was der Rechner zuverlässig zeigt, ist die Struktur: welche Module warten, wo Kopplungen entstehen und welcher Hebel sie auflöst.

Parallelbetrieb heißt vergleichen

Während ein Modul umzieht, laufen Alt und Neu eine Stufe lang parallel. Das bringt nur dann Sicherheit, wenn beide Ergebnisse verglichen werden. Die Weiche schickt dieselbe Anfrage an beide Systeme, maßgeblich bleibt zunächst das Altsystem, und jede Abweichung landet in einem Protokoll, das jemand liest.

Vor dem Umschalten sollte schriftlich feststehen, wann der Parallelbetrieb endet: etwa wenn über einen vereinbarten Zeitraum keine ungeklärte Abweichung mehr auftritt und alle bekannten Sonderfälle mindestens einmal durchgelaufen sind. Ohne ein solches Kriterium bleibt der Parallelbetrieb aus Vorsicht bestehen, und das Team pflegt zwei Systeme länger als geplant.

Abweichungen sind dabei nicht immer Fehler des neuen Systems. Oft zeigt der Abgleich eine Regel, die im Altsystem nie dokumentiert wurde, etwa eine Rundung oder einen Rabatt, der nur für eine Kundengruppe gilt. Solche Funde gehören in die Beschreibung des neuen Moduls, bevor das alte abgeschaltet wird.

Wem die Daten während der Ablösung gehören

Die heikelste Frage einer schrittweisen Ablösung betrifft die Daten. Solange ein Modul in beiden Systemen existiert, braucht jedes Datenobjekt genau ein führendes System: Kundenstammdaten werden entweder im alten oder im neuen System geändert, nie in beiden. Das andere System erhält eine Kopie, und die Richtung dieser Kopie wechselt erst mit dem Umzug des Moduls.

Praktisch heißt das, früh eine Zuordnungstabelle für Kennungen anzulegen, weil das neue System eigene Nummern vergibt, und festzulegen, wie oft und in welche Richtung abgeglichen wird. Wer an beiden Enden gleichzeitig schreiben lässt, erzeugt Konflikte, die sich später kaum noch auflösen lassen.

Wenn eine Funktion früher gebraucht wird, als ihr Modul umziehen kann

Im Beispiel soll das Kundenportal früh Aufträge übergeben, das Modul Aufträge kann aber erst in Stufe 4 umziehen. Der Stufenplan beantwortet die Frage deshalb nicht allein. Eine Zwischenlösung an der Weiche kann Aufträge aus dem Portal annehmen, prüfen und über den vorhandenen Weg in das Altsystem schreiben, bis das neue Modul bereitsteht.

Eine solche Zwischenlösung ist bewusst Übergangscode. Sie sollte so gebaut sein, dass sie später vor das neue Modul umgehängt oder entfernt werden kann, und sie gehört mit einem Datum für ihre Überprüfung in den Plan. Sonst wird aus der Übergangslösung ein weiteres Altsystem.

Wann der Stichtag doch die bessere Wahl ist

Eine schrittweise Ablösung kostet Weiche, Parallelbetrieb und Datenabgleich. Diese Kosten lohnen sich nicht in jedem Fall. Ein kleines System mit wenigen Nutzern und ohne Anbindungen lässt sich oft sauberer an einem gut vorbereiteten Tag umstellen.

1. Das System ist klein: Wenn alle Module an einem Tag getestet werden können, bringt die Zerlegung wenig.
2. Es gibt keine Stelle für eine Weiche: Eine Anwendung, deren Daten nur über ihre eigene Oberfläche erreichbar sind, lässt sich schwer abschnittsweise umleiten.
3. Das Datenmodell lässt sich nicht teilen: Wenn fast jede Tabelle von fast jedem Modul geschrieben wird, entstehen in jeder Stufe gekoppelte Umzüge.
4. Der Parallelbetrieb ist teurer als das Risiko: Wenn ein Ausfall von einem Tag verkraftbar ist, darf die Vorbereitung schlanker ausfallen.

Auch dann bleibt ein Teil der Methode nützlich. Die Liste der Module und ihrer Abhängigkeiten zeigt, was am Stichtag gemeinsam funktionieren muss, und damit, was vorher gemeinsam getestet werden sollte.

Womit Sie beginnen können

Die ersten Schritte folgen derselben Logik wie der Stufenplan, und sie lassen sich im eigenen Haus beginnen. Zuerst entsteht eine Liste der fachlichen Module mit ihren Nutzern, Datenflüssen und harten Abhängigkeiten, gezählt statt geschätzt. Danach wird jede Verbindung zu anderen Systemen wie ein Vertrag beschrieben: Format, Richtung, Verhalten im Fehlerfall und Zuständigkeit.

Mit dieser Liste lässt sich ein Randmodul als erster Kandidat wählen, und an ihm zeigt sich, ob Weiche, Abgleich und Betrieb tragen. Welche Unterlagen ein neues Modul braucht, bevor ein anderes Team es betreibt, beschreibt der Leitfaden Vom Proof of Concept in den Regelbetrieb. Was beim Betrieb im eigenen Haus zu klären ist, steht unter Eine Anwendung im eigenen Haus betreiben, und woran sich Abkürzungen im Code zeigen, die jeden weiteren Umzug verteuern, unter Technische Schulden erkennen.

Soll ein Dienstleister die Ablösung begleiten, hilft der Leitfaden Prototyp weiterentwickeln lassen bei der Auswahl. Einen Überblick über Softwareentwicklung bei iiterate gibt die Seite Softwareentwicklung.

Diese Zahl ist eine Summe. Sie setzt sich aus fünf Posten zusammen, die unterschiedlich groß sind, unterschiedlich reagieren und sich mit unterschiedlichen Mitteln verkleinern lassen.

Warum eine einzelne Zeitmessung wenig erklärt

Eine Gesamtzeit beantwortet die Frage, ob ein Assistent zu langsam ist. Sie beantwortet nicht, warum, und damit auch nicht, welche Maßnahme hilft. Eine neue Grafikkarte beschleunigt nur einen der Posten, eine schnellere Suche einen anderen, und beide Investitionen können an der eigentlichen Ursache vorbeigehen.

Hilfreicher ist ein Latenzbudget, wie es aus der Planung von Echtzeitsystemen bekannt ist. Man legt eine Ziel-Antwortzeit fest und verteilt sie auf die Posten, die eine Antwort durchläuft. Überschreitet die Summe das Ziel, zeigt das Budget sofort, welcher Posten zu groß ist.

Beim Maschinenbauer aus dem Beispiel hätte ein solches Budget die Diskussion verkürzt. Statt über Grafikkarten zu streiten, hätte das Team gesehen, welcher Posten die Zielzeit überschreitet und ob er sich mit einer Einstellung verkleinern lässt. Diese Zerlegung lässt sich mit Beispielwerten selbst durchrechnen.

Die fünf Posten einer Antwort

Ein Assistent, der aus eigenen Dokumenten antwortet, arbeitet bei jeder Frage dieselbe Kette ab. Wie diese Kette im Einzelnen aufgebaut ist, beschreibt der Wissensbeitrag Retrieval-Augmented Generation. Für die Antwortzeit zählen fünf Abschnitte davon.

Dokumentabruf. Die Suche ermittelt zur Frage passende Textabschnitte aus dem Index. Ihre Dauer hängt von der Größe des Bestands, vom Suchverfahren und davon ab, wie Berechtigungen gefiltert werden.

Nachsortierung. Ein zweites Modell ordnet die gefundenen Kandidaten neu, bevor die besten an das Sprachmodell gehen. Dieser Schritt heißt Reranking, und seine Dauer wächst mit der Zahl der Kandidaten, die er bewerten muss.

Modellantwort. Das Sprachmodell liest Anweisung, Frage und Abschnitte und schreibt dann die Antwort. Das Lesen des Kontexts kostet Zeit, bevor das erste Wort erscheint, und das Schreiben kostet Zeit für jedes weitere.

Prüfschritt. Eine Prüfung gleicht Aussagen mit Belegen ab und kontrolliert Zugriffsrechte und Format. Sie macht Antworten verlässlicher und fügt dafür einen eigenen Posten hinzu.

Netz. Anfrage und Antwort laufen zwischen Browser, Anwendung, Suche und Modell hin und her. Liegt das Modell bei einem externen Anbieter, kommen weitere Wege hinzu, liegt es im eigenen Netz, fallen sie kürzer aus.

Warum die Modellantwort meist der größte Posten ist

Ein Sprachmodell schreibt keine ganzen Sätze auf einmal. Es erzeugt Tokens, also Wortbausteine, eines nach dem anderen, und jedes neue Token baut auf allen vorherigen auf. Die Schreibzeit ist deshalb ungefähr die Zahl der Tokens mal der Zeit je Token.

Die Zeit je Token ist keine feste Eigenschaft eines Modells. Sie hängt von Modellgröße, Hardware und Quantisierung ab und davon, wie viele Anfragen sich die Rechenkapazität gerade teilen. Zwei gleichzeitige Anfragen auf derselben Grafikkarte werden beide langsamer, und bei einem externen Anbieter kann der Wert mit dessen Auslastung schwanken.

Die Zahl der Tokens bestimmen dagegen Sie. Eine Anweisung, die ausführliche Einleitungen, Wiederholungen der Frage und Zusammenfassungen am Ende verlangt, verdoppelt schnell die Antwortlänge, ohne dass die Antwort besser wird.

Das erste Wort und die fertige Antwort sind zwei Zeiten

Viele Oberflächen zeigen die Antwort, während sie entsteht. Für die Nutzer zählt dann vor allem, wann das erste Wort erscheint, und weniger, wann das letzte steht. Bis zum ersten Wort laufen Abruf, Nachsortierung, Netz und das Lesen des Kontexts, erst danach beginnt das sichtbare Schreiben.

Ein Prüfschritt verändert diese Rechnung. Prüft er die fertige Antwort, bevor sie angezeigt wird, kann die Oberfläche nichts vorab zeigen, und die gefühlte Wartezeit entspricht der vollen Summe. Prüft er fortlaufend oder nur ausgewählte Aussagen, bleibt das schrittweise Anzeigen möglich, dafür kann eine bereits sichtbare Aussage nachträglich zurückgezogen werden.

Welche Variante passt, ist eine fachliche Entscheidung. Bei Auskünften, auf die hin jemand eine Maschine freigibt, ist das Warten auf die geprüfte Antwort das kleinere Übel.

Rechnen Sie ein Latenzbudget selbst durch

Die Demonstration addiert die fünf Posten zu einer Summe und trägt sie maßstäblich gegen eine Ziel-Antwortzeit auf. Voreingestellt sind Beispielwerte für einen Assistenten mit zwei Sekunden Ziel, bei denen die Summe knapp darunter liegt. Die Werte sind keine Messungen, sie machen nur die Größenverhältnisse greifbar.

Stellen Sie die Zeit je Token von 9 auf 14 Millisekunden, als würden sich zwei Anfragen eine Grafikkarte teilen. Kürzen Sie danach die Antwortlänge von 180 auf 110 Tokens und beobachten Sie die Ziellinie.

Bei 14 Millisekunden je Token ragt der Balken um 880 Millisekunden über das Ziel. Mit 110 Tokens liegt die Summe bei 1.900 Millisekunden und damit wieder unter dem Ziel, ohne dass sich an Hardware oder Modell etwas geändert hat.

Was die Rechnung zeigt und was sie auslässt

Die Modellantwort dominiert die Summe in fast jeder Einstellung. Entfallen Nachsortierung und Prüfschritt ganz, spart das in der Voreinstellung zusammen 190 Millisekunden, während 70 Tokens weniger bei 9 Millisekunden je Token 630 Millisekunden sparen. Kürzere Antworten sind deshalb oft die erste und günstigste Korrektur.

Die Rechnung hat drei Lücken, die im Betrieb zählen. Sie rechnet mit einem festen Wert je Posten, obwohl echte Zeiten streuen und Nutzer langsame Antworten stärker wahrnehmen als den Durchschnitt. Sie kennt keine Warteschlange, die entsteht, wenn mehr Fragen eintreffen, als gleichzeitig bearbeitet werden können. Und sie trennt nicht zwischen Lesen und Schreiben, obwohl lange übergebene Abschnitte vor allem das erste Wort verzögern.

Für eine belastbare Aussage braucht es deshalb Messungen am eigenen System. Sinnvoll sind Zeitstempel an jeder Übergabe und eine Auswertung, die neben dem Mittelwert auch die langsamsten Anfragen zeigt, etwa über das 95. Perzentil.

Wie die Betriebsart die Posten verschiebt

Wo das Sprachmodell läuft, verändert vor allem zwei Posten. Bei einem externen Anbieter kommen Netzwege und dessen Auslastung hinzu, im eigenen Netz fallen die Wege kürzer aus, dafür teilen sich alle Nutzer die eigene Rechenkapazität. Eine Grafikkarte, die für ein Fachteam schnell genug ist, kann bei gleichzeitigen Fragen einer ganzen Abteilung spürbar langsamer werden.

Die Betriebsarten selbst, also Cloud-Schnittstelle, Hosting in der EU und Betrieb im eigenen Haus, unterscheiden sich in weit mehr als der Antwortzeit. Eine Gegenüberstellung steht auf der Seite KI-Entwicklung, die Abwägung aus Sicht von Daten und Kosten in On-Premise vs. Cloud-LLM. Was für den eigenen Betrieb an Hardware realistisch ist, beschreibt Lokales LLM im Unternehmen, welche offenen Modelle sich lokal betreiben lassen, der Wissensbeitrag Lokale Sprachmodelle.

Für den Maschinenbauer heißt das: Bevor eine größere Grafikkarte gekauft wird, zeigt eine Messung mit gleichzeitigen Fragen, ob die Zeit je Token unter Last steigt. Steigt sie, hilft mehr Rechenkapazität. Bleibt sie stabil, liegt die Ursache in einem anderen Posten, und die neue Karte würde das Problem nicht lösen.

In welcher Reihenfolge Sie eine langsame Antwort beschleunigen

Die Reihenfolge folgt dem Verhältnis von Wirkung zu Aufwand. Die ersten Schritte ändern Konfiguration und Anweisung, erst die letzten kosten Geld.

1. Zeitstempel je Posten setzen und die langsamsten Anfragen getrennt auswerten.
2. Die Antwortlänge begrenzen: eine kurze Form in der Anweisung verlangen, Wiederholungen der Frage und Schlussformeln streichen.
3. Weniger und kürzere Abschnitte übergeben, wenn die Testfragen zeigen, dass die richtigen Stellen auch so ankommen.
4. Die Zahl der Kandidaten für die Nachsortierung prüfen, denn sie wächst oft unbemerkt mit dem Bestand.
5. Den Prüfschritt so legen, dass nichts doppelt geprüft wird, etwa Rechte vor der Suche statt nach der Antwort.
6. Häufige Fragen mit stabilen Antworten zwischenspeichern, sofern sich die Quellen selten ändern.
7. Erst danach über ein kleineres Modell, andere Hardware oder eine andere Betriebsart entscheiden.

Jede dieser Änderungen kann die Qualität der Antworten berühren. Deshalb läuft nach jedem Schritt dieselbe Testmenge, wie in Warum KI-Features in der Praxis scheitern beschrieben.

Wann die Antwortzeit zweitrangig ist

Nicht jede KI-Anwendung wartet auf einen Menschen. Extraktionen aus Dokumenten, nächtliche Auswertungen oder Zusammenfassungen für einen Bericht laufen im Hintergrund, und dort zählt der Durchsatz pro Stunde mehr als die Sekunden je Anfrage.

Umgekehrt gibt es Anwendungen, bei denen ein Budget von zwei Sekunden zu großzügig ist, etwa Sprachdialoge, in denen eine Pause wie eine Störung wirkt. Dort verschiebt sich die Rechnung zu kurzen Antworten, kleineren Modellen und einer Prüfung, die nicht auf die fertige Antwort wartet. Welche Zielzeit angemessen ist, entscheidet der Einsatz, und das Budget macht sichtbar, was diese Zielzeit kostet.

Mit diesem Satz lässt sich nicht arbeiten, weil er keinen Ort nennt. Ein KI-Feature besteht aus mehreren Stufen, und fast jeder Fehler entsteht an genau einer davon. Das Beispiel mit der Pumpe ist erfunden, der Weg zur Ursache ist übertragbar.

Warum „die KI“ keine Fehlerursache ist

Von außen sind bei einem KI-Feature zwei Dinge sichtbar: die Frage und die Antwort. Alles dazwischen wirkt wie eine geschlossene Kiste, und Fehlermeldungen landen deshalb beim Sprachmodell, weil es der einzige Baustein ist, dessen Namen alle kennen. Die naheliegende Reaktion ist ein anderes Modell, eine längere Anweisung oder ein teurerer Tarif.

In einem gebauten System ist die Kiste eine Kette. Dokumente werden eingesammelt, zerlegt, indiziert und bei jeder Frage durchsucht, erst danach formuliert ein Modell, und im besten Fall prüft eine weitere Stufe das Ergebnis, bevor es ausgegeben wird. Zerlegt man die Meldung des Technikers entlang dieser Kette, zeigt sich ein anderes Bild: Das Handbuch lag im Index, der richtige Abschnitt stand in der Trefferliste aber erst auf Rang sechs, und an das Modell gingen nur die ersten vier.

Die Reparatur liegt in diesem Fall in der Suche. Am Sprachmodell müsste niemand etwas ändern, und ein Modellwechsel hätte den Fehler bestenfalls überdeckt.

Die sieben Stufen eines KI-Features und ihre typischen Fehler

Die folgende Einteilung ist auf Fehlersuche ausgerichtet. Wie die Verarbeitung technisch abläuft, von der Zerlegung über Einbettungen bis zur Neuordnung der Treffer, erklärt der Wissensbeitrag Retrieval-Augmented Generation. Für die Fehlersuche zählt bei jeder Stufe nur, was dort schiefgeht und woran Sie es merken.

1. Eingang. Dokumente, Tickets und Datensätze werden eingesammelt, mit Fassung und Leserechten. Typische Fehler sind ein unvollständiger Bestand, veraltete Fassungen und Scans ohne Textebene. Sie merken es daran, dass Antworten eine überholte Fassung zitieren oder bestimmte Aktenbestände nie auftauchen.

2. Aufbereitung. Texte werden in Abschnitte zerlegt, die einzeln gefunden werden können. Zerreißt die Zerlegung eine Tabelle oder trennt eine Überschrift von ihrem Inhalt, findet die Suche Bruchstücke ohne Zusammenhang. Das Symptom sind Antworten, die eine Zahl ohne ihre Einheit oder Bedingung nennen.

3. Index. Die Abschnitte werden durchsuchbar abgelegt, als Stichwortindex, als Vektorindex oder beides. Fehler entstehen, wenn geänderte Dokumente nicht nachgezogen werden oder Berechtigungen beim Import verloren gehen. Dann zitiert der Assistent Dokumente, die gelöscht sind oder die die fragende Person nicht öffnen dürfte.

4. Abruf. Zur Frage sucht das System passende Abschnitte und übergibt eine begrenzte Anzahl an das Modell. Liegt die richtige Stelle zu weit hinten oder verwendet die Frage andere Wörter als das Dokument, kommt sie nie an. Das Symptom ist eine allgemeine, halb richtige Antwort, obwohl das Wissen im Bestand steht.

5. Modell. Das Sprachmodell formuliert aus Frage, Anweisung und übergebenen Abschnitten eine Antwort. Es kann Abschnitte falsch gewichten, Bedingungen weglassen oder Lücken mit plausiblem Allgemeinwissen füllen. Sie erkennen diesen Fall daran, dass die richtige Stelle nachweislich übergeben wurde und die Antwort trotzdem abweicht.

6. Prüfung. Eine Prüfstufe gleicht Aussagen mit Belegen ab, kontrolliert Format und Rechte und hält im Zweifel eine Antwort zurück. Fehlt sie oder ist sie zu großzügig eingestellt, gehen unbelegte Aussagen durch. Ist sie zu streng, bekommen Nutzer auffällig oft gar keine Antwort.

7. Ausgabe. Die Antwort erreicht ein Zielsystem, etwa eine Oberfläche, ein Ticket oder einen Datensatz. Dort gehen Fußnoten verloren, Zahlen werden umformatiert oder Felder abgeschnitten. Das Symptom ist eine Antwort, die im Protokoll richtig war und beim Nutzer falsch ankommt.

Warum die Suche so oft die Ursache ist

Ein Sprachmodell liest bei jeder Frage nur das, was im Kontextfenster liegt, also Anweisung, Frage und übergebene Abschnitte. Das ist vergleichbar mit einem Kollegen, dem man vier Seiten aus einem Ordner in die Hand drückt: Er kann gut formulieren, aber nur über diese vier Seiten. Wie viele Abschnitte übergeben werden, ist eine Einstellung, und jede Einstellung schneidet die Trefferliste an irgendeiner Stelle ab.

Dazu kommt ein Wortproblem. Der Techniker schreibt „Leckrate“, das Handbuch spricht von „Leckage“, und eine reine Stichwortsuche sieht darin zwei verschiedene Begriffe. Vektorsuche und hybride Verfahren mildern das, besonders bei Fachbegriffen, Typenbezeichnungen und zusammengesetzten Wörtern bleibt die Lücke aber ein häufiger Grund für Fehltreffer. Welche Verfahren es gibt und wie sie sich kombinieren lassen, beschreibt der Wissensbeitrag Semantische Suche im Unternehmen.

Beide Effekte sind leise. Die Antwort klingt flüssig, weil das Modell aus den übergebenen Abschnitten etwas Passendes macht, und niemand sieht die Trefferliste, in der die richtige Stelle knapp unter der Grenze steht.

Probieren Sie die Suche aus Stufe 4 selbst aus

Die Demonstration arbeitet mit dreizehn erfundenen Abschnitten aus Wartungshandbuch, Norm-Auszug, Datenblatt und Instandhaltungsprotokollen. Voreingestellt ist die Frage des Technikers, bewertet wird mit einer einfachen Stichwortsuche, die seltene Wörter stärker gewichtet. Achten Sie auf die markierte Zeile mit dem Handbuchabschnitt 4.5 Leckage und auf die Angabe, ob er beim Modell ankommt.

Stellen Sie danach sechs Abschnitte im Kontextfenster ein. Schalten Sie anschließend zurück auf vier und aktivieren Sie die Synonymliste.

Mit sechs Abschnitten rutscht der Handbuchabschnitt gerade noch ins Kontextfenster. Mit der Synonymliste steigt er auf Rang 1, weil die Suche „Leckrate“ nun auch als „Leckage“ versteht. Beide Korrekturen liegen in Stufe 4, und keine davon berührt das Sprachmodell.

Was die Demonstration zeigt und wo sie aufhört

Die zwei Korrekturen haben unterschiedliche Preise. Mehr Abschnitte im Kontextfenster verlängern jede Anfrage und geben dem Modell mehr Material, das es falsch gewichten kann. Eine Synonymliste wirkt gezielt, muss aber von jemandem gepflegt werden, der die Sprache der Dokumente und die Sprache der Fragenden kennt.

Probieren Sie auch die Frage „Wann ist die Pumpe undicht?“. Ohne Synonymliste landet der richtige Abschnitt auf Rang 5, mit ihr auf Rang 1, und direkt dahinter steht der Norm-Auszug mit seiner Definition von Dichtheit. Das ist ein gutes Ergebnis, weil beide Stellen zusammen die vollständige Antwort ergeben.

Die Demonstration hat bewusst enge Grenzen. Sie rechnet ohne Einbettungen, ohne Neuordnung und ohne Sprachmodell, und ihr Bestand ist so klein, dass sich jede Zeile nachvollziehen lässt. Die Rangzahlen sind Rechenergebnisse der Demonstration und keine Messwerte aus einem System, das Muster dahinter gilt aber auch in großen Beständen: Eine richtige Antwort setzt voraus, dass die richtige Stelle ankommt.

Eine Testmenge macht Fehler zählbar

Einzelne Meldungen zeigen, dass etwas schiefgeht, aber nicht, wie oft. Dafür braucht es eine feste Sammlung echter Fragen, zu denen vorher notiert ist, welche Fundstelle eine richtige Antwort zitieren müsste. Einige Dutzend solcher Fragen aus dem Alltag genügen für einen ersten Stand.

Die Testmenge trennt zwei Fragen, die in einer Fehlermeldung vermischt sind. Die erste lautet, ob die richtige Fundstelle im Kontextfenster angekommen ist; wenn nicht, liegt der Fehler in den Stufen 1 bis 4. Die zweite lautet, ob die Antwort aus der angekommenen Stelle richtig und belegt formuliert ist; wenn nicht, liegt er in Modell, Anweisung oder Prüfung.

Nach jeder Änderung an Zerlegung, Index, Suche, Modell oder Anweisung läuft dieselbe Testmenge erneut. So wird sichtbar, ob eine Änderung geholfen oder an anderer Stelle etwas verschlechtert hat. Wie sich Antworten an Quellen binden und bewerten lassen, bis hin zu menschlichen Stichproben, behandelt der Wissensbeitrag KI-Antworten prüfen. Warum diese Auswertung eine laufende Position ist und keine Projektphase, steht in Was ein RAG-System im Betrieb wirklich kostet.

In welcher Reihenfolge Sie eine Fehlermeldung eingrenzen

Für eine einzelne Meldung lohnt eine feste Reihenfolge, weil jeder Schritt ganze Stufen ausschließt. Wer beim Modell beginnt, prüft zuerst die Stelle, an der der Fehler am seltensten sichtbar wird.

1. Frage und erwartete Fundstelle festhalten. Ohne die Stelle, die eine richtige Antwort zitieren müsste, lässt sich kein Fehler belegen.
2. Prüfen, ob die Fundstelle im Index liegt, in der gültigen Fassung und mit den richtigen Rechten. Fehlt sie, liegt die Ursache in Stufe 1 bis 3.
3. Den Rang der Fundstelle in der Trefferliste ansehen. Liegt sie hinter der Grenze des Kontextfensters, liegt die Ursache in Stufe 4.
4. Wurde die Stelle übergeben, Anweisung und Antwort vergleichen. Weicht die Antwort trotzdem ab, liegt die Ursache in Stufe 5.
5. Zuletzt Prüfstufe und Ausgabe kontrollieren, also ob eine belegte Antwort zurückgehalten, gekürzt oder umformatiert wurde.

Dafür braucht das System ein Suchprotokoll, das zu jeder Antwort festhält, was gefunden, was übergeben und was verwendet wurde. Fehlt dieses Protokoll, bleibt nur Raten, und die Fehlersuche endet wieder beim Modell.

Wann ein KI-Feature nicht die passende Lösung ist

Nicht jede Frage aus dem Betrieb braucht sieben Stufen. Lässt sich eine Frage als feste Abfrage formulieren, etwa nach einem Termin oder einem Stammdatum, ist eine Datenbank genauer und günstiger als jedes Sprachmodell.

Zwei weitere Fälle scheitern vor der Technik. Kursieren drei Fassungen desselben Handbuchs, muss zuerst festgelegt werden, welche gilt. Und ohne eine Person, die neue Fassungen einpflegt und alte zurückzieht, veralten die Antworten, ohne dass es jemand bemerkt.

Löst ein einzelner Fehler Zahlungen, Sicherheitsrisiken oder Stillstand aus, gehört ein Mensch an die Entscheidung. Ob die Pumpe P-40 wieder anläuft, entscheidet der Techniker, und der Assistent liefert ihm die Fundstelle dazu. Wie weit Ihr eigener Bestand für ein solches System vorbereitet ist, lässt sich mit dem RAG-Readiness-Check einschätzen, welche Bausteine eine Umsetzung umfasst, beschreibt die Seite KI-Entwicklung.

Die Frage klingt nach einem Fall für Augmented Reality. Häufig genügt aber eine Rechnung, weil Einhausung und Raum ohnehin als Maße vorliegen. Wo diese Rechnung aufhört, wie fein ein 3D-Modell für die räumliche Ansicht sein muss und wann AR tatsächlich hilft, lässt sich klar trennen.

Warum die Frage nach dem Raum zwei Fragen sind

Wer fragt, ob eine Einhausung in die Halle passt, meint meistens zwei Dinge. Die erste Frage ist, ob sie mit genügend Abstand zu Wänden und Decke aufgestellt werden kann, damit Wartung und Bedienung möglich bleiben. Die zweite ist, ob die Maschine, die darin stehen soll, durch die Hallentür kommt.

Beide Fragen haben eigene Engstellen. Eine Einhausung kann bequem im Raum stehen, während die Maschine an der Türbreite scheitert, und umgekehrt. Ein Raumcheck, der nur eine der beiden Fragen beantwortet, erzeugt deshalb falsche Sicherheit.

Die Maße der Einhausung kommen im besten Fall aus einem Konfigurator, in dem der Kunde Breite, Tiefe, Höhe und Türen einstellt. Wie ein solcher Konfigurator Zeichnung, Stückliste und Gewicht aus derselben Regel ableitet, zeigt die Seite 3D-Konfiguratoren.

Was eine Raumprüfung rechnen muss

Für die Aufstellung braucht die Einhausung ihre eigene Grundfläche plus einen Wartungsabstand an jeder Seite. Vor Türen der Einhausung kommt ein Schwenkbereich hinzu, der größer sein kann als der Wartungsabstand, und in der Höhe muss Luft bis zur Decke bleiben. Welcher Abstand für eine bestimmte Maschine nötig ist, steht in deren Unterlagen, die Rechnung übernimmt ihn nur als Eingabe.

Der Schwenkbereich wird in Skizzen leicht vergessen. Eine Einhausung, die mit Wartungsabstand gerade in den Raum passt, kann trotzdem unbrauchbar sein, wenn sich ihre Tür nicht vollständig öffnen lässt. Die Rechnung setzt deshalb vor jeder Tür den größeren der beiden Werte an.

Für die Einbringung zählt der Querschnitt der Maschine. Aufrecht muss ihre schmalere Grundseite durch die Türbreite und ihre Höhe durch die Türhöhe passen. Darf die Maschine gekippt werden, kommen weitere Lagen hinzu, und die Rechnung nimmt die günstigste davon.

Aus beiden Prüfungen entstehen vier Angaben, die ein Kunde versteht: ob die Einhausung passt, ob die Maschine hineinkommt, wie viel freie Fläche bleibt und wo der engste Abstand liegt. Mehr braucht es für eine erste Antwort selten.

Prüfen Sie die Einhausung selbst

Die Demonstration rechnet beide Prüfungen für eine Einhausung von vier mal drei Metern und 2.200 Millimetern Höhe mit einer Tür. Voreingestellt ist eine Halle von 6.500 mal 4.600 Millimetern mit 800 Millimetern Wartungsabstand, alles Beispielwerte. In dieser Einstellung fehlen 200 Millimeter Tiefe, und die Draufsicht markiert die betroffenen Wände.

Senken Sie den Wartungsabstand auf 600 Millimeter, oder nehmen Sie der Einhausung einen Meter Tiefe. Stellen Sie danach die Türbreite auf 1.500 Millimeter und erlauben Sie das Kippen.

Mit 600 Millimetern Wartungsabstand passt die Einhausung, und es bleiben knapp sechs Quadratmeter frei. Bei 1.500 Millimetern Türbreite kommt die Maschine aufrecht nicht hinein, gekippt meldet die Rechnung „ja“ mit 0 Millimetern Luft.

Was die Prüfung zeigt und was sie verschweigt

Das Ergebnis mit 0 Millimetern Luft ist rechnerisch richtig und praktisch wertlos. Keine Maschine lässt sich ohne Spiel durch eine Öffnung bewegen, und Stapler, Transportrollen oder Anschlagmittel brauchen zusätzlichen Platz. Eine brauchbare Prüfung rechnet deshalb mit einer Mindestluft, die der Hersteller aus seiner Erfahrung festlegt.

Auch die Aufstellung ist vereinfacht. Die Rechnung setzt die Einhausung mittig, kennt keine Stützen, Kabeltrassen, Kranbahnen oder Bodenabläufe und fragt nicht nach der Tragfähigkeit des Bodens. Sie prüft außerdem nur die letzte Tür, obwohl der Transportweg über Flure, Rampen oder einen Aufzug oft enger ist.

Als erste Antwort taugt sie trotzdem. Sie ersetzt eine Rückfrage durch eine Zahl und zeigt, welche Angabe fehlt, bevor jemand zum Aufmaß fährt.

Welche Angaben ein Kunde liefern sollte

Die Qualität eines Raumchecks hängt an den Eingaben. Fünf Angaben decken die meisten Fälle ab, und viele Kunden können sie ohne Ortstermin liefern.

1. Raummaße: lichte Breite, Tiefe und Höhe am Aufstellort, gemessen unter der niedrigsten Stelle wie Trägern oder Leitungen.
2. Tür- und Tormaße: lichte Breite und Höhe jeder Öffnung auf dem Transportweg, auch der ersten.
3. Hindernisse: Stützen, Kabeltrassen, Kranbahnen und Bodenabläufe mit ihrer ungefähren Lage.
4. Zugang: von welcher Seite die Einhausung bedient und gewartet wird.
5. Transport: ob die Maschine gekippt werden darf und womit sie bewegt wird.

Liegen diese Angaben vor, lässt sich die Prüfung automatisch rechnen und als Teil der Anfrage mitschicken. Der Innendienst sieht dann neben der gewählten Einhausung auch, ob sie beim Kunden steht und hineinkommt.

Wie fein das Modell für die räumliche Ansicht sein muss

Soll der Kunde die Einhausung zusätzlich in 3D drehen oder später im eigenen Raum sehen, braucht jedes Teil eine Oberfläche aus Dreiecken. Ein Modell direkt aus der Konstruktion ist dafür fast immer zu fein, weil es Details trägt, die aus Betrachtungsabstand niemand sieht.

Die Zahl der Dreiecke lässt sich aus der Stückliste abschätzen: Stückzahl je Position mal Dreiecke je Teil, summiert über alle Positionen. Für die Einhausung aus der Demonstration ergibt das in einer schlichten Vertriebsansicht rund 800 Dreiecke, in einer konstruktionsnahen Fassung mit abgerundeten Profilen knapp 7.000 und in einer fertigungsnahen Fassung mit Verbindern und Fußplatten über 32.000.

Die fertigungsnahe Fassung hat damit rund 42-mal so viele Dreiecke wie die Vertriebsansicht, und für die Frage nach dem Raum zeigt sie nichts Zusätzliches. Welcher Detailgrad trägt, entscheidet der Zweck: Für Maß und Aufstellung genügt die schlichte Fassung, für eine Erklärung der Verbindungstechnik lohnt die feinere. Wie sich die Budgets eines Modells im Browser rechnen lassen, zeigt Wie groß darf ein 3D-Modell im Browser sein?.

Die vereinfachte Fassung sollte nicht von Hand entstehen. Wird sie bei jeder Konstruktionsänderung automatisch aus dem Modell abgeleitet, stimmen Maße und Stückzahlen weiter mit der Konstruktion überein. Ein nachgebautes Vertriebsmodell zeigt dagegen nach der ersten Änderung eine Einhausung, die es so nicht mehr gibt.

Wann AR die Frage besser beantwortet als eine Rechnung

Eine Rechnung braucht Maße, und manche Räume lassen sich schlecht in Maße fassen. Unregelmäßige Grundrisse, verstreute Hindernisse oder eine Halle voller Bestandsanlagen sind mit fünf Zahlen nicht beschrieben. Dann kann eine AR-Ansicht helfen, die das Modell über die Kamera eines Telefons oder Tablets maßstäblich in den realen Raum stellt.

Der Vorteil liegt im Blick vor Ort. Der Kunde sieht, ob die Einhausung vor einer Stütze endet oder eine Kabeltrasse berührt, und das Gespräch mit dem Hersteller beginnt mit einem gemeinsamen Bild. Für diesen Zweck genügt das leichte Modell der Vertriebsansicht.

AR hat eigene Grenzen. Die Lageerkennung braucht Kanten und Muster in der Umgebung, und gleichförmige Flächen, Glas oder schwaches Licht bieten davon wenig, was in Werkhallen häufig vorkommt. Die Anwendung muss zudem auf den Geräten der Kunden laufen, und der Zugriff auf die Kamera muss vorher freigegeben werden.

Die Reihenfolge ergibt sich daraus fast von selbst. Zuerst kommen Regel und Maße, dann die Rechnung, und AR dort, wo Maße den Raum nicht beschreiben.

Wann sich Raumcheck und 3D nicht lohnen

Gibt es nur wenige Ausführungen und stellt kaum ein Kunde die Frage nach dem Raum, ist eine Maßzeichnung mit Mindestabständen die günstigere Antwort. Sie lässt sich drucken, in ein Angebot legen und braucht keine Pflege.

Steht die Regel für Abstände und Varianten nur in einem Kopf, kommt die Software zu früh. Der erste Schritt ist dann, Grenzen und Abhängigkeiten aufzuschreiben, damit Konfigurator, Stückliste und Prüfung dieselbe Quelle lesen, wie Vom Grasshopper-Modell zum Web-Konfigurator beschreibt.

Und endet die Anfrage samt Raumcheck im Postfach, weil jemand sie von Hand ins ERP-System übertragen muss, verschiebt sich der Aufwand nur an eine andere Stelle. Ob sich ein parametrisches Modell für Ihr Produkt rechnet, lässt sich mit den Kriterien aus Wann sich ein parametrisches Modell rechnet abschätzen.

Wer diese drei Fälle ausschließen kann, hat eine gute Ausgangslage. Dann lohnt es, mit der Regel und dem Raumcheck zu beginnen und 3D-Modell und AR-Ansicht erst folgen zu lassen, wenn die Anfragen zeigen, dass Kunden den Raum auch sehen wollen.

Dit artikel ordent de belangrijkste programma's naar de stand van september 2026, beschrijft stap voor stap de weg naar de aanvraag en noemt de typische fouten die u de ondersteuning kunnen kosten.

Welke soorten ondersteuning er zijn

Er zijn vier soorten ondersteuning, en ze verschillen meer in hun logica dan in hun hoogte. Een subsidie dekt een deel van de subsidiabele kosten en wordt niet terugbetaald, maar vereist een aanvraag vóór de start van het project en aan het einde een verantwoording van de besteding (Verwendungsnachweis). Een voordelige lening loopt via uw eigen bank (Hausbank) en kan in hogere niveaus een subsidiecomponent bevatten. De Forschungszulage is een fiscale regeling voor onderzoek en ontwikkeling. Adviesaanbod keert geen geld uit, maar helpt een project te plaatsen.

Een AI-project komt niet al in aanmerking vanwege het trefwoord AI, maar wanneer het past bij het doel van een programma: onderzoek en ontwikkeling, digitalisering van processen en producten of extern advies. Bij het zoeken helpt het te weten dat het federale ministerie van Economische Zaken nu als BMWE (voorheen BMWK) opereert en het onderzoeksministerie als BMFTR.

Federale programma's in het kort

Op federaal niveau zijn in 2026 vooral vijf instrumenten relevant voor AI-projecten, met een zeer verschillende status.

• ZIM (Zentrales Innovationsprogramm Mittelstand, het centrale innovatieprogramma voor het mkb). Het BMWE financiert onderzoeks- en ontwikkelingsprojecten van mkb-bedrijven, alleen of met onderzoeksinstellingen, en daarnaast innovatienetwerken en haalbaarheidsstudies. Sinds 7 juli 2026 geldt een tijdelijke aanvraagstop: ZIM neemt momenteel geen nieuwe aanvragen aan, heropening wordt nagestreefd voor begin 2027 en hangt af van de begroting voor 2027. Reeds ingediende aanvragen worden nog beoordeeld.
• KMU-innovativ. Het BMFTR financiert risicovolle onderzoeks- en ontwikkelingsprojecten in sleuteltechnologieën, waaronder informatie- en communicatietechnologie. De procedure kent twee fasen: eerst een projectschets, dan de aanvraag. De deadlines zijn 15 april en 15 oktober, de volgende is 15 oktober 2026 (stand: september 2026). Programmapagina KMU-innovativ.
• Forschungszulage (fiscale tegemoetkoming voor onderzoek). Elke in Duitsland belastingplichtige onderneming kan er aanspraak op maken, ongeacht omvang en sector. Eerst verklaart de BSFZ dat het om onderzoek en ontwikkeling gaat, daarna wordt de tegemoetkoming na afloop van het boekjaar bij de belastingdienst aangevraagd, ook voor reeds uitgevoerde projecten. Voor 2026 is ze uitgebreid via het Investitionssofortprogramm (direct investeringsprogramma). Certificeringsinstantie Forschungszulage.
• ERP-Förderkredit Digitalisierung (511, 512). Via uw eigen bank financiert de KfW digitalisering in drie niveaus, van IT, software en cloud via procesdigitalisering, IT-beveiliging en training tot grotere projecten, uitdrukkelijk inclusief de inzet van AI op bedrijfsgegevens. De aanvraag moet vóór de start van het project worden ingediend, en voor het eerste niveau is vooraf een KfW-Digitalisierungs-Check nodig. Productpagina van de KfW.
• Mittelstand-Digital Zentren. Het BMWE financiert gratis, leveranciersonafhankelijke ondersteuning op het gebied van digitalisering, AI en IT-beveiliging, met AI-trainers in de centra. Er wordt geen geld uitgekeerd. Het bestaande netwerk wordt tot eind 2026 geleidelijk afgebouwd, en vanaf 1 januari 2027 volgt een nieuw netwerk met een extra focus op IT-beveiliging, nog steeds gratis voor het mkb. Mittelstand-Digital.

Voor consortia van wetenschap en industrie staat bovendien de BMFTR-richtlijn voor AI-vlaggenschipprojecten in waardeketens open, met een deadline voor projectschetsen op 1 november 2026 (stand: september 2026).

Ondersteuning op EU-niveau

Op EU-niveau staan vier wegen open voor AI-projecten: de European Digital Innovation Hubs, de EIC Accelerator, cascadefinanciering en het programma Digitaal Europa.

• European Digital Innovation Hubs (EDIH). Regionale consortia bieden gratis of gesubsidieerde diensten aan, zoals "test before invest", trainingen en ondersteuning bij het vinden van investeringen, met zwaartepunten als AI en cyberbeveiliging. Overzicht van de Europese Commissie.
• EIC Accelerator. De Europese Innovatieraad ondersteunt individuele start-ups en mkb-bedrijven met baanbrekende innovaties dicht bij de markt via een subsidie, een kapitaalinvestering of beide. Korte voorstellen kunnen op elk moment worden ingediend, en de volgende deadline voor volledige voorstellen is 4 november 2026 (stand: september 2026). EIC Accelerator.
• Cascadefinanciering. Door de EU gefinancierde projectconsortia geven via open oproepen een deel van hun budget door aan start-ups en mkb-bedrijven, als vast bedrag, prijs of voucher en met een vereenvoudigde procedure, bijvoorbeeld voor kleine experimenten en pilotprojecten. De oproepen staan minstens twee maanden open op het Funding & Tenders Portal van de EU. Leidraad van de Commissie (pdf).
• Programma Digitaal Europa. De Commissie schrijft middelen uit voor AI, supercomputing, cyberbeveiliging en digitale vaardigheden. Mkb-bedrijven profiteren meestal indirect, bijvoorbeeld via de EDIH's. Programmapagina.

Deelstaatprogramma's in Rijnland-Palts

In Rijnland-Palts verstrekt de ISB de steun van de deelstaat, en voor AI-projecten zijn vier programma's bijzonder relevant.

• InnoTop. Technologieneutrale financiering van haalbaarheidsstudies en onderzoeks- en ontwikkelingsprojecten voor nieuwe of verbeterde producten, processen en diensten, voor mkb-bedrijven en SmallMidCaps.
• Innovationsgutschein (FuE-Auftrag). Een innovatievoucher: subsidie voor mkb-bedrijven die onderzoek en ontwikkeling van maximaal twaalf maanden uitbesteden aan een hogeschool of onderzoeksinstituut.
• IBI-EFRE. Subsidie voor investeringen waarmee commerciële mkb-bedrijven digitalisering in productie en bedrijfsmodellen doorvoeren. Sommige sectoren zijn uitgesloten, er geldt een minimaal investeringsvolume en de aanvraag loopt vóór de start van het project via het portaal van de ISB. Vermelding in de Förderdatenbank.
• Betriebsberatungsprogramm RLP. Subsidie voor extern advies, uitdrukkelijk ook over digitalisering en kunstmatige intelligentie. Aanvragen zijn mogelijk sinds 16 december 2025, en voor sommige onderwerpen is een aanbeveling van de kamer nodig. Het programma vervangt het eind 2025 beëindigde BITT-technologieadvies. Programmapagina van de ISB.

Het overzicht van de innovatie- en digitaliseringsprogramma's staat op isb.rlp.de. In de EU-catalogus voor Duitsland was geen EDIH met zetel in Rijnland-Palts te vinden (stand: september 2026). Voor de hand liggend zijn EDIH Saarland, dat zich ook op de Grote Regio richt, en het Mittelstand-Digital Zentrum Kaiserslautern, dat bedrijven uit Rijnland-Palts ondersteunt bij AI-gereedheid.

Deelstaatprogramma's in Noordrijn-Westfalen

In Noordrijn-Westfalen is Mittelstand Innovativ & Digital (MID) de centrale toegang voor mkb-bedrijven die in de deelstaat gevestigd zijn, en sinds 1 januari 2026 keurt de NRW.BANK nieuwe projecten goed.

• MID-Digitalisierung. Subsidie voor de ontwikkeling van marktgerichte digitale producten met sleuteltechnologieën, uitdrukkelijk inclusief AI, machine learning en datamining. Productpagina van de NRW.BANK.
• MID-Digitale Sicherheit. Subsidie voor IT-statusanalyses inclusief penetratietests, training van medewerkers en basismaatregelen voor IT-beveiliging. Subsidieportaal NRW.

Beide programma's verdelen aanvraagplaatsen via een maandelijkse loting. Wie wordt ingeloot, heeft 28 dagen voor de aanvraag, en de loting is nog geen subsidietoezegging. De oproep 2026 voor MID-Digitale Prozesse, dat extern advies financiert, is al gesloten omdat het maximale aantal aanvragen is bereikt (stand: september 2026). Daarnaast heeft Noordrijn-Westfalen drie EDIH's: in Dortmund, in het Rijnland met zetel in Aken en in Zuid-Westfalen.

Andere deelstaten en beëindigde programma's

Voor alle andere deelstaten is de federale Förderdatenbank (subsidiedatabank) de snelste weg naar passende programma's. Elke deelstaat heeft eigen programma's, en de Förderdatenbank bevat steun van de federale overheid, de deelstaten en de EU, te filteren op regio, aanvragers en soort steun. Doorslaggevend blijft de pagina van de betreffende subsidieverstrekker, want oproepen openen en sluiten in de loop van het jaar.

Twee federale programma's waarnaar nog vaak wordt gezocht, zijn beëindigd: Digital Jetzt neemt geen aanvragen meer aan, en go-digital is eind 2024 stopgezet. Ook de naam ERP-Digitalisierungs- und Innovationskredit is verouderd, het huidige product van de KfW is de ERP-Förderkredit Digitalisierung.

Stap voor stap naar de aanvraag

Bij bijna alle programma's volgt de weg naar de aanvraag dezelfde tien stappen, ook al verschillen formulieren en portalen.

1. Mkb-status controleren. Volgens EU-aanbeveling 2003/361 is een mkb-bedrijf een onderneming met minder dan 250 werknemers die binnen de drempels voor jaaromzet of balanstotaal blijft. Partner- en verbonden ondernemingen kunnen meetellen. De Forschungszulage en de ERP-Förderkredit Digitalisierung staan ook open voor grotere ondernemingen. Mkb-definitie van de EU.
2. Gratis oriëntatie benutten. Een Mittelstand-Digital Zentrum, een EDIH of het federale subsidieadvies helpt u het project te plaatsen voordat er moeite in een aanvraag gaat.
3. Programma en status controleren. Is het programma open, is er een deadline, een loting of een aanvraagstop?
4. Niet vóór de toekenning beginnen. Een voortijdige start van de maatregel (vorzeitiger Maßnahmenbeginn), dus een start vóór ontvangst van de subsidiebeschikking, is in de regel niet toegestaan, tenzij de richtlijn of een schriftelijke toestemming dit toestaat. Dat geldt ook voor bindende opdrachten aan dienstverleners. Bij de KfW moet de aanvraag vóór de start van het project zijn ingediend.
5. De-minimissteun optellen. Waar een programma de-minimissteun verleent, geldt een plafond van 300.000 euro per onderneming binnen drie jaar. In de aanvraag verklaart u welke steun u in die periode al heeft ontvangen. Sinds 1 januari 2026 is daarvoor een centraal register verplicht. Verordening (EU) 2023/2831.
6. Projectschets schrijven. Bij procedures in twee fasen staat aan het begin een korte schets die zonder aanvullende vragen begrijpelijk moet zijn en met andere schetsen concurreert. Projecten worden begeleid door Projektträger (projectbeheerorganisaties) zoals DLR, PtJ of VDI/VDE-IT, die in opdracht van het ministerie werken. Basiskennis projectfinanciering.
7. Aanvraag indienen. Federale onderzoeksaanvragen lopen meestal via easy-Online, KfW-leningen via uw eigen bank en deelstaatprogramma's via de portalen van de ISB of de NRW.BANK. Gebruikelijke stukken zijn een projectbeschrijving met werkplan, een kosten- en financieringsplan, kredietwaardigheidsdocumenten, de mkb-verklaring, zo nodig de de-minimisverklaring en offertes van leveranciers.
8. Eigen bijdrage veiligstellen. Subsidies dekken slechts een deel van de kosten, de rest financiert de onderneming zelf.
9. Cumulatie controleren. Steun kan worden gecombineerd, maar alleen binnen de toegestane steunintensiteiten, en dezelfde kosten mogen nooit dubbel worden gefinancierd. Gebruikelijk is een verdeling per kostenpost, bijvoorbeeld gratis advies, een lening voor de investering en de Forschungszulage voor het ontwikkelingsdeel.
10. Rapporteren en verantwoorden. Tijdens de looptijd rapporteert u aan de Projektträger, en aan het einde volgt de Verwendungsnachweis, bestaande uit een financiële verantwoording en een technisch eindverslag. FAQ van de DLR Projektträger.

Typische fouten

De typische fouten zijn formeel van aard en zijn vóór de aanvraag te vermijden.

• Te vroeg opdracht gegeven. Wie leverings- of adviescontracten vóór de toekenning, of afhankelijk van het programma zelfs vóór de aanvraag, bindend ondertekent, kan de subsidiabiliteit verliezen.
• Mkb-status overschat. Een dochteronderneming van een groter concern is mogelijk geen mkb-bedrijf, ook al is ze zelf klein.
• Status niet gecontroleerd. Programma's sluiten ook in de loop van het jaar, zoals de ZIM-aanvraagstop en de volle oproep van MID-Digitale Prozesse in 2026 laten zien.
• Loting verkeerd begrepen. Bij MID is inloting geen toezegging, en de termijn daarna is kort.
• Programmadoel gemist. Een adviesprogramma financiert geen softwarelicenties, en een Mittelstand-Digital Zentrum keert geen geld uit.
• Deadline gemist. Bij KMU-innovativ betekent een gemiste deadline een half jaar wachten.
• De-minimis verkeerd berekend. De periode van drie jaar is voortschrijdend en niet gekoppeld aan kalenderjaren.
• Namen verward. EDIH Rheinland is gevestigd in Aken en is geen aanspreekpunt voor Rijnland-Palts. Oudere blogberichten noemen bovendien programma's en productnamen die niet meer bestaan.

Welk programma bij welk AI-project past

Welk programma past, volgt uit de aard van het project: onderzoek, invoering of advies.

Een AI-project is onderzoeksgericht als het technisch risico draagt, bijvoorbeeld een nieuwe methode of een model voor een vraagstuk waarvan de uitkomst vooraf niet vaststaat. Daarvoor zijn de Forschungszulage, KMU-innovativ, InnoTop en de Innovationsgutschein bedoeld, ZIM na de heropening, en voor baanbrekende projecten dicht bij de markt de EIC Accelerator.

Het gaat om invoering wanneer beproefde technologie in uw eigen bedrijf komt, bijvoorbeeld zoeken in uw eigen documenten of de automatisering van een proces. Hier passen de ERP-Förderkredit Digitalisierung, in Rijnland-Palts IBI-EFRE en in Noordrijn-Westfalen MID-Digitalisierung als er een digitaal product uit voortkomt. Open oproepen van cascadefinanciering kunnen kleine pilotprojecten dragen.

Advies staat aan het begin wanneer nog open is of een use case standhoudt. De Mittelstand-Digital Zentren en de EDIH's zijn gratis, en in Rijnland-Palts wordt extern advies gesubsidieerd via het Betriebsberatungsprogramm. Voor IT-beveiliging rond een AI-project biedt Noordrijn-Westfalen MID-Digitale Sicherheit.

Dit artikel is algemene informatie en geen juridisch of fiscaal advies, en subsidievoorwaarden veranderen.

Een AI-project moet inhoudelijk zijn afgebakend voordat de subsidievraag wordt gesteld, meer daarover onder AI-gereedheid.

Wat Slush is

Slush is een conferentie voor start-ups en investeerders in Helsinki die in 2008 begon als een bijeenkomst van 250 mensen. Ze heeft geen winstoogmerk, is eigendom van de Finse Startup Foundation en wordt georganiseerd door studenten en pas afgestudeerden, samen met een groot team van vrijwilligers.

Het evenement vindt plaats op 18 en 19 november 2026 in het Helsinki Expo and Convention Centre (Messukeskus), met een Day 0-programma op 17 november. Volgens de organisator komen er meer dan 12.000 deelnemers, van wie ongeveer driekwart start-ups of investeerders. De nadruk ligt op geselecteerde Europese start-ups, internationale investeerders en techmedia, en Slush noemt de DACH-regio uitdrukkelijk als kernregio. Programma en details staan op de officiële website van Slush.

Wat iiterate meebrengt

iiterate brengt naar Helsinki het werk dat we dagelijks doen: AI voor omgevingen waarin gegevens het bedrijf niet zouden moeten verlaten. Wij zijn een AI-adviesbureau uit Adenau in Rijnland-Palts en reizen als deel van de Duitse delegatie. Onze zwaartepunten:

• On-premise LLM. Taalmodellen die in de eigen infrastructuur draaien.
• RAG en kennisbeheer. Retrievalsystemen die antwoorden afleiden uit de documenten van een bedrijf en de bronnen noemen.
• AI met gegevensopslag in de EU. Architecturen waarbij verwerking en opslag binnen de Europese Unie blijven.
• Computational design. Parametrische modellen en configuratoren waarin regels de geometrie genereren.

In gesprekken gaat het ons om concrete vragen: welke gegevens een project raakt, waar de verwerking mag plaatsvinden en welke architectuur daaruit volgt.

Wie met ons zou moeten praten

Vooral investeerders, bedrijven en oprichters die met AI en gevoelige gegevens te maken hebben, zouden met ons moeten praten.

• Investeerders die AI-projecten beoordelen in gereguleerde of gegevensgevoelige sectoren.
• Bedrijven die AI willen inzetten op vertrouwelijke documenten en daarvoor gegevensopslag in de EU of in eigen huis nodig hebben.
• Oprichters die werken aan AI met gevoelige gegevens en willen praten over architectuur, beheer of samenwerking.

Een project dat nog niet volledig is doordacht, is daarbij geen belemmering, maar een goed vertrekpunt voor een gesprek.

Een afspraak in Helsinki maken

Een afspraak in Helsinki maakt u het best vooraf via onze contactpagina. Vermeld kort uw onderwerp en de dagen waarop u ter plaatse bent. Gesprekken zijn mogelijk in het Duits of het Engels.

De specificatie, zonder marketing

Voordat het over gevolgen gaat, helpt de nuchtere tabel. Alle waarden komen uit het modeloverzicht en de prijspagina van Anthropic, opgehaald op 10 september 2026.

Opmerkelijk is wat Anthropic in het eigen modeloverzicht toevoegt: Claude Opus 5 wordt aanbevolen als standaard voor de meeste werklasten, en Fable 5.1 is bedoeld voor gevallen waarin Opus 5 op een hoger effortniveau tekortschiet. Dat is een ongewoon duidelijke zelfbeperking en tegelijk het eerste filter voor elke architectuurbeslissing. Fable 5.1 is geen algemene upgrade, maar een instrument voor lange, samenhangende taken.

De modaliteit is smal, en dat telt in de praktijk. Tekst en beelden gaan erin, tekst komt eruit. Geen geluid erin, geen geluid eruit, geen beeld- of videogeneratie. Wie een gespreksopname wil verwerken, heeft er een transcriptie voor nodig. Wie gesproken antwoorden nodig heeft, heeft er spraaksynthese achter nodig. Wie afbeeldingen wil maken, heeft een ander model nodig. Dat klinkt banaal, maar het verschuift systeemgrenzen, kosten en privacyvragen precies naar de plekken waar die extra componenten staan.

Wat een miljoen tokens verandert, en wat niet

Het venster wordt over de volle lengte tegen de normale tokentarieven afgerekend; een toeslag voor lange context is er niet (Anthropic). Daarmee worden opzetten mogelijk die eerder niet op het model strandden maar op het opdelen: een compleet bestand aan contracten of aanbestedingsstukken in één doorloop in plaats van dertig stukjes met een samenvoeging achteraf; een volledig agentspoor inclusief alle tooluitvoer dat nog analyseerbaar is in plaats van na twintig stappen afgekapt; een middelgrote repository waarover een vraag in één keer wordt beantwoord in plaats van via een zoekactie die vooraf moet raden welke bestanden ertoe doen. De winst zit minder in intelligentie dan in het verdwijnen van een hele klasse lijmwerk, en dat lijmwerk was in onze projecten stelselmatig de bron van de moeilijk vindbare fouten.

Het getal is echter geen paginatelling. Anthropic becijfert 1.000.000 tokens op ongeveer 555.000 Engelse woorden met de huidige tokenizer en wijst er in dezelfde adem op dat deze tokenizer voor dezelfde tekst ongeveer 30 procent meer tokens produceert dan de vorige (Anthropic). De opgave betreft Engelse tekst; voor een Duitstalig bestand valt daaruit geen getal af te leiden, dat moet worden gemeten. Wie capaciteit plant, telt de eigen documenten met de tokenizer van het model dat hij daadwerkelijk gebruikt, en rekent niet in pagina's.

Om dezelfde reden zegt het vergelijken van venstergroottes tussen leveranciers niets. Een token is een leveranciersgebonden eenheid, en er bestaat geen gepubliceerde omrekening die twee tokenizers op dezelfde hoeveelheid tekst afbeeldt. Een getal op een specificatieblad zegt dus niets over welk model meer van uw tekst bevat.

En het grotere venster maakt retrieval niet overbodig. De redenering is eenvoudig: alles wat in het venster staat, wordt bij elke aanroep betaald en moet bij elke aanroep worden verwerkt. Een methode die de twintig relevante alinea's vindt, blijft sneller, goedkoper en doorgaans nauwkeuriger dan een methode die tienduizend alinea's erin legt en op aandacht hoopt. Het grote venster verschuift de drempel waarboven opdelen nodig wordt fors omhoog. Het vervangt niet de vraag welke informatie voor dit ene antwoord nodig is.

Het eigenlijke engineeringverhaal heet cachelezen

Het interessantste getal in de specificatie is geen absolute waarde maar een verhouding. Verse invoer kost 10 USD per miljoen tokens, een cachetreffer 0,25 USD. Schrijven naar de cache kost 12,50 USD per miljoen tokens in de vijfminutenlaag en 20 USD in de uurlaag. Op Fable 5.1 en Mythos 5.1 ligt de leesprijs op 0,025 maal de basisprijs, tegenover 0,1 maal bij alle andere Claude-modellen, en dat is volgens Anthropic de enige prijswijziging ten opzichte van Fable 5 (Anthropic).

De factor 40 tussen verse invoer en een cachetreffer bepaalt de ontwerpen. In een agentlus worden dezelfde systeemprompt, dezelfde tooldefinities en dezelfde projectcontext bij elke stap opnieuw gelezen. Een taak van tweehonderd toolaanroepen leest dezelfde aanhef tweehonderd keer. Of die aanhef telkens als verse invoer wordt afgerekend of als cachetreffer, is geen boekhoudkundig detail maar de grens tussen een ontwerp dat in productie kan en een ontwerp dat in de demo blijft.

Juist daarom is Anthropics eigen formulering, dat typische werklasten ongeveer 25 procent goedkoper zijn en sterk agentische tot ongeveer 45 procent, een schatting over cachetrefferpercentages en geen prijsverlaging (Anthropic). De kopprijzen voor invoer en uitvoer zijn ten opzichte van Fable 5 ongewijzigd. Een werklast met slechte cachelokaliteit ziet van die besparing vrijwel niets, en wie de 25 procent zonder dat voorbehoud in een budget zet, heeft geen budget maar een hoop.

Wat trefferpercentages in de praktijk goed of slecht maakt, is geen gedocumenteerde meetwaarde maar engineeringlogica, en die laat zich benoemen:

• Een stabiel voorvoegsel. Hergebruikt wordt het ongewijzigde begin van het verzoek. Alles wat constant is hoort voorin, alles wat varieert achterin. Een tijdstempel, een sessie-ID of een gebruikersnaam op de verkeerde plek maakt alle context die erop volgt waardeloos.
• Deterministische opbouw. Toollijsten in willekeurige volgorde, zoekresultaten in wisselende sortering of objecten met instabiele sleutelvolgorde leveren bij elke run een nieuw voorvoegsel op. De cache ziet dan nooit twee keer hetzelfde.
• De levensduur tegen het ritme van de taak. Vijf minuten past bij een strak getimede agentlus. Het past niet bij een dialoog waarin iemand tussen twee vragen twintig minuten in een vergadering zit. De uurlaag kost meer bij het schrijven en loont pas wanneer die de treffer daadwerkelijk redt.
• Genoeg herhaling per voorvoegsel. Veel korte, onderling ongerelateerde verzoeken verdelen zich over veel voorvoegsels. Elk betaalt een schrijfactie en krijgt zelden een leesactie. Dat is het geval waarin de cache-economie tegen u werkt, en dan is de batchinterface met 50 procent korting in beide richtingen vaak de betere weg.

Een concreet aanknopingspunt uit de prijslijst ondersteunt hetzelfde punt: de toolset voor computergebruik voegt ongeveer 4.500 invoertokens per verzoek toe, die voor browsergebruik ongeveer 6.600 (Anthropic). Dat is een constant blok dat bij elke stap terugkeert, en dus precies het materiaal dat in een stabiel voorvoegsel thuishoort.

Agentisch werken, tools en de vraag naar het effortniveau

Fable 5.1 is gebouwd voor lange runs. Anthropic voert als bewijs een onbewaakte run van 38 uur op een machinelearningprobleem aan (Anthropic). Dat is een leveranciersopgave over één run en geen verdelingsresultaat, maar het werkt als orde van grootte voor datgene waarop het model is ontworpen.

De denkmodus is adaptief en permanent actief; de eerdere handmatige modus met een expliciet denkbudget wordt niet meer geaccepteerd. Ten opzichte van Fable 5 zijn er drie brekende wijzigingen die elke bestaande integratie raken: afgedwongen toolgebruik levert een fout op, eerdere modellen kunnen de denkblokken van dit model niet lezen, en het bewerken van eerdere beurten maakt die denkblokken ongeldig. Aanvullend komen er onder meer een effortniveau per bericht, systeemberichten die per beurt gelden, leesbare voortgangsmeldingen tussen toolaanroepen en de lagere cacheleesprijs bij; meerdere daarvan zijn als bèta gemarkeerd (Anthropic). Voor de planning betekent dat: overstappen op dit model is geen configuratiewijziging maar een kleine verbouwing met een test erachteraan.

Bij de effortniveaus is zorgvuldigheid geboden. De documentatie noemt high als standaard (Anthropic), en de aankondiging preciseert dat de standaard per oppervlak verschilt: high in Claude Code, medium in Claude Cowork en op claude.ai (Anthropic). De volledige set geaccepteerde waarden staat niet op de documentatiepagina's die wij hebben geraadpleegd, en wij beweren die dan ook niet.

Het praktische gevolg is ongemakkelijk maar belangrijk: een benchmarkgetal of een kostenraming zonder vermeld effortniveau is niet reproduceerbaar. Twee teams die hetzelfde model via twee verschillende oppervlakken meten, meten verschillende configuraties. Wie wil dat offertes, testresultaten of interne vergelijkingen standhouden, noteert het niveau naast het getal, zoals men een meting zonder eenheid ook niet laat passeren.

Kennisstand juni 2026 is een architectuureis

De kennis- en trainingsdatumgrens ligt bij juni 2026 (Anthropic). Operationeel betekent dat weinig dramatisch en tegelijk heel wat. Uw prijslijst van vorige week, de beslissing van gisteren, de stand van uw orderportefeuille van vanochtend: niets daarvan zit in het model. Het moet via retrieval, via een toolkoppeling of via de prompt in de context komen.

Dat is geen gebrek van het model maar een eis aan de architectuur, en die eis is leveranciersonafhankelijk. Elk systeem dat over actuele feiten moet informeren en geen gedefinieerde weg heeft waarlangs die feiten binnenkomen, is verkeerd gespecificeerd, hoe goed het model ook is. Twee gevolgen hebben zich bij ons bewezen. Ten eerste hoort bij elk op feiten gebaseerd antwoord een noembare bron in de context, niet het modelgeheugen. Ten tweede horen in elke evaluatieset enkele vragen waarvan het juiste antwoord na de kennisgrens is veranderd: die toetsen precies het pad dat in productie het gemakkelijkst stilzwijgend breekt.

Het watermerk uit artikel 50 is geen audittrail

Fable 5.1 en Mythos 5.1 dragen vanaf de lancering een onzichtbaar tekstwatermerk (Anthropic). Anthropic past de markering wereldwijd toe en niet alleen in de EU (Euronews). De achtergrond zijn de transparantieverplichtingen uit artikel 50 van de AI-verordening, die sinds 2 augustus 2026 gelden en een machineleesbare markering van synthetische inhoud vereisen.

Doorslaggevend is het voorbehoud dat Anthropic zelf maakt. Een gedetecteerd watermerk geeft aan dat inhoud mogelijk door Claude is verwerkt, is uitdrukkelijk niet volledig sluitend en bevestigt op zichzelf de herkomst van de inhoud niet (Anthropic Help Center). Daar komt bij dat de detectie-interface in een besloten preview slechts voor een beperkte kring toegankelijk is (MacRumors).

Voor een onderneming die het eigen AI-gebruik wil documenteren volgt daaruit een nuchtere ontwerpeis, en dit is een technische inschatting en geen juridisch advies: het watermerk is een signaal in de uitvoer dat niet van u is, dat u doorgaans niet zelf kunt uitlezen en waarvan de leverancier zelf de bewijskracht begrenst. Het is dus geen audittrail. Als traceerbaar moet zijn welk model wanneer met welke invoer welke uitvoer heeft voortgebracht en wie die heeft vrijgegeven, ontstaat dat bewijs in uw eigen vastleggingen. Technisch is dat weinig spectaculair, want het zijn dezelfde logs die u toch al bijhoudt voor foutopsporing en kostenbeheersing.

De randvoorwaarde die in Duitsland de architectuur bepaalt

In Duitse projecten beslist de gegevensverwerking vaker over de inzet van een model dan de capaciteit ervan. Hier is de situatie eenduidig gedocumenteerd en voor velen verrassend. Anthropic merkt Fable 5.1 aan als Covered Model. Deze modellen vereisen een bewaartermijn van 30 dagen en zijn niet beschikbaar onder zero data retention, tenzij Anthropic dat uitdrukkelijk toestaat. Een organisatie die op zero data retention draait, moet de bewaring voor een specifieke workspace bewust inschakelen, anders worden verzoeken met een fout afgewezen (Anthropic).

Twee aanvullingen uit dezelfde bron horen erbij, omdat het beeld anders scheef komt te staan. Bewaarde gegevens worden volgens Anthropic zonder uitdrukkelijke toestemming niet voor modeltraining gebruikt. En ook onder zero data retention kan als opvallend gemarkeerde inhoud tot twee jaar worden bewaard. Zero data retention geldt bovendien niet voor alle wegen het systeem in, onder meer niet voor de batchinterface en de bestandsopslag.

Daar komt de regiovraag bij. Op de eerstepartij-interface bestaat geen EU-inferentieregio. De parameter voor de inferentieregio accepteert exact twee waarden, global en us, en opslag vindt uitsluitend in de VS plaats; de regio van een workspace is na aanmaak niet meer te wijzigen (Anthropic). De begaanbare weg binnen de EU loopt via een partnercloud: Amazon Bedrock en Google Cloud bieden regionale endpoints met gegarandeerde gegevensroutering, tegen een opslag van 10 procent ten opzichte van de globale endpoints, en stellen hun eigen levenscyclusdata vast (Anthropic).

Dit is een ontwerpgegeven en geen oordeel over het model. In de praktijk blijven er drie wegen, en de keuze valt vóór het eerste prototype, niet erna. Ten eerste: een regionaal endpoint bij een partnercloud, met de opslag en met de cloudaanbieder als verwerker. Ten tweede: de eerstepartij-interface met bewust ingeschakelde bewaring, voor gegevensklassen waarbij dat verdedigbaar is. Ten derde: de betreffende gegevensklasse bereikt dit model helemaal niet, omdat een ander model of een lokale opstelling het deel overneemt dat de gevoelige velden ziet. De derde weg wordt te zelden onderzocht, terwijl die in kennis- en documentsystemen vaak de schoonste is.

Wat verandert, en wat dit model niet aanraakt

Eerlijk benoemd verandert er een overzichtelijke maar waardevolle verzameling taakklassen. Analyses over bestanden die tot nu toe op het opdelen strandden, worden in één doorloop haalbaar. Agentruns die eerder aan de contextgrens uiteenvielen, blijven samenhangend. En opzetten die dezelfde basis heel vaak opnieuw moeten lezen, worden door de cacheleesprijs rendabel, mits de opbouw het trefferpercentage oplevert. Dat zijn drie echte verschuivingen, en ze raken precies het werk dat in een adviespraktijk anders als monnikenwerk binnenkomt.

Even eerlijk benoemd is wat onveranderd blijft. Ook de capaciteiten van het model zijn begrensd: penetratietests, exploitgeneratie, binair gebaseerd scannen en taken uit biologisch onderzoek worden naar de Opus-modellen doorverwezen, en de snelle modus is op Fable 5.1 niet beschikbaar (Anthropic, Anthropic).

Belangrijker zijn echter de problemen waar geen enkel model aan raakt. Datakwaliteit blijft uw taak: een groter venster leest tegenstrijdige stamgegevens alleen grondiger. Procesdefinitie blijft uw taak: een agent die niet weet wanneer iets besloten is, weerspiegelt slechts de onduidelijkheid die eerder in het team lag. Autorisaties blijven uw taak: een model dat alles mag zien, is een privacyprobleem met taalgevoel. Evaluatie blijft uw taak, want zonder een set gevallen met bekend juist antwoord kan niemand zeggen of een overstap iets heeft verbeterd. En de kosten van een fout blijven waar ze waren: op een suggestielijst is een fout vervelend, op een uitgaande factuur is die duur. Dat onderscheid bepaalt de mate van automatisering, en het is een bedrijfsvraag.

Onze positie hierin is zonder ophef: Fable 5.1 verschuift de grens van wat een opzet kan dragen, en verschuift die op een plek die in de praktijk werkelijk remde. Het verschuift geen enkele van de vragen die daarvóór beantwoord moeten zijn. Welke van die vragen staat in uw volgende project nog open?

Dit artikel leest de release zoals een organisatie die overweegt erop te bouwen hem zou moeten lezen: welke specificaties werkelijk tellen, wat aan de prijsstructuur echt is en wat een gemodelleerde schatting, wat er breekt op het niveau van de interface, en waarom de Europese route naar dit model via een partnercloud loopt en niet via Anthropic zelf.

Wat er op 1 september daadwerkelijk is uitgebracht

Anthropic heeft Claude Fable 5.1 op 1 september 2026 uitgebracht, samen met Claude Mythos 5.1. Volgens Anthropics eigen weergave zijn beide hetzelfde model met verschillende beveiligingsniveaus: Fable 5.1 is algemeen beschikbaar, Mythos 5.1 uitsluitend op uitnodiging via programma's voor vertrouwde toegang. De vakpers bevestigt de datum en de beschikbaarheid op alle platforms vanaf de dag van verschijnen.

De model-id luidt claude-fable-5-1, op Amazon Bedrock anthropic.claude-fable-5-1. Het model wordt geleverd via de Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry en Claude Platform op AWS. Als oppervlakken noemt Anthropic Claude Code, Claude Enterprise en Claude Platform, met verschillende standaardwaarden voor het inspanningsniveau: high in Claude Code en medium in Claude Cowork en op claude.ai. Er is een toezegging over uitfasering: op de door Anthropic beheerde platforms wordt het model niet eerder dan 1 september 2027 uitgezet, terwijl Bedrock en Google Cloud hun eigen data vaststellen.

Opmerkelijk is wat Anthropic in diezelfde documentatie toevoegt. Fable 5.1 wordt beschreven als bedoeld voor veeleisend redeneren en langlopend agentisch werk; als standaard voor de meeste workloads beveelt Anthropic nog altijd uitdrukkelijk Claude Opus 5 aan, en Fable 5.1 pas daar waar Opus 5 op een hoog inspanningsniveau tekortschiet. Wie de overstap intern moet verantwoorden, zou die zin moeten kennen: de leverancier zelf beveelt zijn nieuwe vlaggenschip niet in algemene zin aan.

De specificaties die een beslissing dragen

De kerngegevens komen uit Anthropics modeldocumentatie en wegen voor een architectuurbeslissing zwaarder dan welke ranglijst dan ook.

Twee punten verdienen meer dan een tabelregel. Ten eerste de denkmodus: Fable 5.1 denkt adaptief en permanent, en de oudere handmatige modus met thinking.type: enabled en budget_tokens wordt niet meer geaccepteerd. Wie een bestaande integratie overzet, moet die plek in de code aanpassen.

Ten tweede het contextvenster. Eén miljoen tokens komt volgens Anthropic overeen met ongeveer 555.000 Engelse woorden, gemeten met de huidige tokenizer die met Claude Opus 4.7 is ingevoerd. Diezelfde tokenizer produceert voor dezelfde tekst ongeveer 30 procent meer tokens dan de vorige. Een getal voor het contextvenster is daarmee geen capaciteitsopgave die men luchtig kan vergelijken tussen modelgeneraties, laat staan tussen leveranciers. Voor de budgetplanning telt hoeveel tokens uw eigen tekstbestand daadwerkelijk oplevert, niet de kop boven het bericht.

Prestatiecijfers houdt dit artikel bewust kort, omdat die het onderwerp zijn van een apart vergelijkingsartikel. Alleen dit, en uitdrukkelijk als opgave van de leverancier: Anthropic rapporteert voor Fable 5.1 52,6 procent op Terminal-Bench-Science 0.1 tegenover 24,7 procent voor Fable 5, en 55,8 procent op Terminal-Bench 4.0 tegenover 42,0 procent. De vergelijkingskolom in Anthropics eigen tabel is GPT-5.6 Sol. OpenAI's huidige vlaggenschip GPT-6 Astra verscheen twee dagen na deze release en komt in Anthropics cijfers helemaal niet voor.

De prijs: precies één regel is veranderd

Anthropics prijsdocumentatie noemt voor Fable 5.1 de volgende waarden, telkens in Amerikaanse dollar per miljoen tokens.

Precies één regel is interessant. Bij Fable 5.1 en Mythos 5.1 worden cache-leesbewerkingen berekend tegen 0,025 maal de invoerprijs, terwijl bij elk ander Claude-model een factor 0,1 geldt. Dat is de enige prijswijziging ten opzichte van Fable 5, waarvan de cache-leesbewerking op 1,00 Amerikaanse dollar per miljoen tokens stond. Invoer en uitvoer zijn ongewijzigd. Het volledige contextvenster wordt tegen de gewone tokentarieven afgerekend; een toeslag voor lange context bestaat niet.

Anthropic becijfert de besparing op ongeveer 25 procent ten opzichte van Fable 5 voor typische workloads en op tot ongeveer 45 procent voor sterk agentisch werk. Dat getal is belangrijk genoeg om goed te lezen: het is een gemodelleerde schatting van de leverancier die volledig uit de cacheregel voortkomt, en geen prijsverlaging. Wie verzoeken stuurt die zelden dezelfde context opnieuw lezen, bespaart niets. Wie een agentlus draait die honderd keer dezelfde systeemprompt, dezelfde codebase en dezelfde tooldefinities opnieuw inleest, bespaart aanzienlijk. Het verschil tussen beide gevallen is uw cache-trefferpercentage, en dat kent alleen uw eigen belastingprofiel.

Nog een detail voor de kostenberekening: wordt de inferentie via inference_geo: "us" vastgelegd op de Verenigde Staten, dan geldt een factor 1,1 op invoer, uitvoer, cache schrijven en cache lezen.

In het concurrentieveld is deze cacheregel het enige echte prijsverschil aan de top. OpenAI noemt voor gpt-6-astra eveneens 10 en 50 Amerikaanse dollar per miljoen tokens voor invoer en uitvoer, maar 1,00 dollar voor invoer uit de cache. Bij cache-leesbewerkingen zit Fable 5.1 daarmee op een kwart van de prijs, wat in lange agentlussen de doorslag kan geven. Al het overige over die vergelijking, inclusief de vraag welke benchmarkcijfers überhaupt vergelijkbaar zijn, staat in het afzonderlijke artikel.

Wat er verandert aan de interface, en wat daarbij breekt

Als bewijs van langlopende autonomie noemt Anthropic één onbeheerde run van 38 uur aan een machine learning-probleem. Wie daarop wil bouwen, zou echter eerst de lijst met interfacewijzigingen moeten lezen, want drie daarvan breken bestaande code.

Breaking changes ten opzichte van Fable 5:

• Geforceerd toolgebruik geeft een fout terug.
• Eerdere modellen kunnen de denkblokken van Fable 5.1 niet lezen.
• Het bewerken van eerdere gespreksbeurten maakt denkblokken ongeldig.

Aanvullingen:

• Inspanningsniveau per bericht (bèta).
• Systeemberichten met geldigheid voor één beurt (bèta).
• Leesbare voortgangsmeldingen tussen toolaanroepen via display: "updates" (bèta).
• De verlaagde prijs voor cache-leesbewerkingen.
• Herkomstmarkering van de gegenereerde inhoud.

Voor agentarchitecturen is bovendien de tokenopslag van de toolsets relevant: computer_toolset_20260801 voegt per verzoek ongeveer 4.500 invoertokens toe, browser_toolset_20260801 ongeveer 6.600. Dat is een basislast die bij elk afzonderlijk verzoek optreedt en die in elke kostenraming thuishoort. De fast mode, die bij Claude Opus 5 en Opus 4.8 als onderzoeksvoorbeeld bestaat, is voor Fable 5.1 niet beschikbaar.

Aan de veiligheidskant meldt Anthropic dat de beveiligingen op het gebied van cybersecurity 60 procent minder valse positieven blokkeren dan voorheen, en dat de biologiebeveiligingen 85 procent minder vaak afgaan bij onschuldige vragen over elementaire biologie. Tegelijk blijven hele klassen taken uitgesloten: penetratietests, exploitgeneratie, binaire scans en onderzoekstaken uit de biologie worden doorgestuurd naar Opus-modellen. Fable 5.1 kan kwetsbaarheden in software identificeren, terwijl het genereren van exploits geblokkeerd blijft. Nieuwe API-accounts kunnen daarnaast de voorafgaande context in gesprekken met meerdere beurten niet meer handmatig bewerken; Anthropic motiveert dat met de stelling dat het daarmee een gangbare, publiek gedocumenteerde destillatietechniek afsluit. Voor teams die gespreksverlopen programmatisch herschrijven, is dat een gedragswijziging met directe gevolgen voor bestaande architecturen.

Dataresidentie: bij Anthropic zelf bestaat geen EU-regio

Hier scheidt het technische verhaal zich van het governanceverhaal. Anthropics documentatie over dataresidentie is ondubbelzinnig: de parameter inference_geo accepteert precies twee waarden, global en us. Onder de huidige beperkingen staat letterlijk dat alleen die twee beschikbaar zijn. Een EU-inferentieregio bestaat op Anthropics eigen API niet.

Voor data in rust geldt hetzelfde. De regio van een workspace wordt bij het aanmaken vastgelegd, kan daarna niet meer worden gewijzigd, en de enige beschikbare waarde zijn de Verenigde Staten.

Twee Anthropic-bronnen lijken elkaar hier tegen te spreken, en dat hoort openlijk vermeld. Het privacy-helpcentrum, laatst bijgewerkt op 15 juni 2026, schrijft dat klantverkeer standaard naar geselecteerde landen in de VS, Europa, Azië en Australië kan worden gerouteerd, en voegt in dezelfde tekst toe dat data in de VS worden opgeslagen. De platformdocumentatie kent daarentegen alleen de twee genoemde inferentieregio's. De verzoening ligt in het onderscheid tussen routering en residentie: de modus global kan Europa aandoen, maar is geen selecteerbare garantie dat verwerking en opslag in de EU plaatsvinden. Wie zo'n garantie nodig heeft, vindt die hier niet.

De parameter inference_geo bestaat bovendien pas vanaf Claude 4.6; oudere modellen antwoorden met een 400-fout. Op Amazon Bedrock en Google Cloud bestaat hij niet, daar bepalen endpoint of inferentieprofiel de regio. Microsoft Foundry biedt in plaats daarvan een implementatietype met een Amerikaanse datazone. Via het met de OpenAI SDK compatibele endpoint is de parameter evenmin beschikbaar.

De begaanbare EU-route loopt daarom niet via Anthropic maar via een partnercloud. Bedrock en Google Cloud bieden regionale endpoints met gegarandeerde datarouting, volgens Anthropics prijsdocumentatie met een toeslag van 10 procent ten opzichte van de globale endpoints, en zij stellen hun eigen levenscyclusdata vast. Daarmee is ook de wijdverbreide bewering dat Claude EU-dataresidentie heeft omdat het in Frankfurt draait half waar en per saldo misleidend: Claude-modellen kunnen in EU-regio's draaien, maar daar is de cloudaanbieder de verwerker en niet Anthropic. Voor de contractuele constructie is dat precies het verschil.

Covered Model: 30 dagen bewaren is een voorwaarde, geen optie

De ongemakkelijkste zin uit de hele documentatie staat op Anthropics pagina over API en dataretentie. Daar staat over Claude Fable 5.1, Mythos 5.1, Fable 5 en Mythos 5 dat deze modellen een bewaartermijn van 30 dagen vereisen en niet beschikbaar zijn onder zero data retention, tenzij Anthropic dat uitdrukkelijk toestaat. Zij zijn aangemerkt als Covered Models.

Praktisch betekent dat: een organisatie die vandaag onder zero data retention werkt, kan Fable 5.1 niet eenvoudigweg bijschakelen. Zij moet voor een bepaalde workspace uitdrukkelijk de bewaartermijn van 30 dagen activeren, anders antwoordt de API met 400 invalid_request_error. Dat is geen configuratiefijnzinnigheid maar een beslissing die in veel organisaties eerst langs de privacygoedkeuring moet, voordat de eerste regel integratiecode bestaat.

Voor de volledigheid horen Anthropics toezeggingen ernaast: bewaarde data worden naar eigen zeggen nooit zonder uitdrukkelijke toestemming gebruikt voor modeltraining, en gespreksinhoud wordt buiten de Covered Model-uitzondering standaard niet bewaard.

Ook wie zero data retention al heeft ingericht, zou de grenzen ervan moeten kennen, want die zijn nauwer dan de naam doet vermoeden.

• ZDR wordt per organisatie op aanvraag via sales vrijgeschakeld en gaat niet automatisch over op zusterorganisaties onder hetzelfde account.
• Niet gedekt zijn de Batch API, de Files API, code-uitvoering, Claude for Excel en de productinterfaces van Claude Teams en Claude Enterprise. Claude Code via Claude Enterprise met ZDR is de genoemde uitzondering.
• CORS wordt voor ZDR-organisaties niet ondersteund.
• Wordt een chat of sessie gemarkeerd, dan mag Anthropic invoer en uitvoer tot twee jaar bewaren, ook onder ZDR.

De richting is daarmee eenduidig, en zij loopt tegen het prijsverhaal in. Fable 5.1 is in de agentlus goedkoper dan elk ander Claude-model, en onder strikte EU-dataregels tegelijk lastiger in te voeren dan de Claude-modellen die niet op die lijst staan.

Artikel 50: een watermerk vanaf dag één, met Anthropics eigen voorbehoud

Volgens Anthropic dragen Fable 5.1 en Mythos 5.1 vanaf de dag van verschijnen een onzichtbaar tekstwatermerk. Artikel 50 van de EU-AI-verordening, dat machineleesbare markering van synthetische inhoud verlangt, geldt sinds 2 augustus 2026. Anthropic past de markering wereldwijd toe en niet alleen in de EU.

Wie het watermerk in een controleproces wil inbouwen, zou Anthropics eigen voorbehoud moeten kennen, en dat staat duidelijk in het helpcentrum: een gedetecteerd merk geeft aan dat inhoud mogelijk door Claude is verwerkt, is "not fully conclusive" en bevestigt op zichzelf niet de volledige herkomst van de inhoud. Een bewijs in juridische zin is het dus niet, en de verwachting daarmee auteurschap te kunnen vaststellen gaat verder dan wat de leverancier zelf beweert. Dat is een opmerkelijke constellatie: de markering is een echt kenmerk van het model, en de bewijskracht ervan wordt gerelativeerd door hetzelfde bedrijf dat haar aanbiedt.

Daar komt de toegang bij. De detectie-API bevindt zich in een private preview en staat alleen open voor in aanmerking komende organisaties; genoemd worden toezichthouders, opsporingsdiensten, media, factcheckers, onderzoek, onderwijsinstellingen en maatschappelijke organisaties in de EU. Een onderneming die inkomende teksten zelf op deze markering wil controleren, kan dat langs deze weg momenteel niet.

Het omringende regelgevende kader, zoals de publicerende instanties het beschrijven: de handhaving voor AI-modellen voor algemene doeleinden loopt eveneens sinds 2 augustus 2026, met boetes tot 15 miljoen euro of 3 procent van de wereldwijde jaaromzet voor niet-conforme aanbieders van zulke modellen, ongeacht of zij de gedragscode hebben ondertekend. De gedragscode van de Europese Commissie verplicht ondertekenaars tot een gepubliceerd transparantieformulier, een methodiek voor de beoordeling van systeemrisico's en een kader voor naleving van het auteursrecht, met een documentatiebewaring van ten minste tien jaar. Deze verplichtingen rusten op de modelaanbieders. Wat daaruit voor uw eigen organisatie volgt, hangt af van uw rol in de toeleveringsketen en is een vraag voor uw juridisch adviseur, niet voor een vakartikel.

Wat dit betekent voor een beslissing in Duitsland

Bij elkaar genomen levert de release een ongewoon helder beeld op, juist omdat de twee verhalen in tegengestelde richtingen wijzen. Technisch is Fable 5.1 de goedkopere keuze voor lange agentlussen waarin steeds opnieuw dezelfde context wordt gelezen. Regelgevend is het een model dat men zonder bewaartermijn van 30 dagen niet eens kan starten.

Vier vragen zouden daarom beantwoord moeten zijn voordat de integratie begint.

1. Hoe hoog is uw cache-trefferpercentage werkelijk? De volledige besparing hangt aan dat ene kengetal. Meet het aan een echt belastingprofiel voordat u met 25 procent rekent.
2. Verdraagt uw privacygoedkeuring een bewaartermijn van 30 dagen? Zo niet, dan is Fable 5.1 geen optie tot Anthropic uitdrukkelijk toestemming geeft, en die vraag laat zich technisch niet omzeilen.
3. Via welk endpoint loopt de inferentie? Is verwerking in de EU vereist, dan loopt de weg via Bedrock of Google Cloud, met 10 procent toeslag ten opzichte van de globale endpoints, met de cloudaanbieder als verwerker en met diens eigen levenscyclusdata.
4. Volstaat Opus 5? Anthropic zelf beveelt Opus 5 als standaard aan, en Opus 5 staat niet op de lijst met Covered Models. Een deel van de hier beschreven governancevragen speelt daar in deze vorm niet.

Niets hiervan is een argument tegen Anthropic. Fable 5.1 is een sterk model, de cachewijziging is voor agentisch werk een echte verbetering, en dat de ongemakkelijke feiten netjes na te lezen zijn in Anthropics eigen documentatie pleit voor de leverancier en niet tegen hem. Het is een argument om de volgorde om te draaien: eerst vaststellen onder welke voorwaarden uw data verwerkt mogen worden, dan het model kiezen. Wat Fable 5.1 in het dagelijkse werk daadwerkelijk presteert, behandelt een apart artikel over de mogelijkheden in de praktijk; hoe het zich verhoudt tot GPT-6 Astra, een ander.

De tabel die vrijwel iedereen publiceert deugt niet

De meest voorkomende zin in de huidige berichtgeving komt hierop neer: Anthropics eigen benchmarks zouden Claude Fable 5.1 vóór GPT-6 Astra zetten. Die zin is onjuist, en een kalender weerlegt hem.

Anthropic heeft zijn benchmarktabel op 1 september 2026 gepubliceerd. De vergelijkingskolom daarin draagt de aanduiding GPT-5.6 Sol. GPT-6 Astra ging op 3 september in beperkte preview en op 4 september in algemene beschikbaarheid. Anthropic heeft Astra dus niet alleen niet gemeten, het kón het niet meten: het model was op de publicatiedatum niet openbaar.

Wie de regel over Terminal-Bench 4.0 leest, waar 55,8% voor Fable 5.1 tegenover 37,3% staat, en die 37,3% voor Astra aanziet, vergelijkt Anthropics huidige model met de voorganger van de concurrent. Dat is geen afrondingsfout, dat is een andere bewering. En het is precies de verkeerde lezing die zich op dit moment het snelst verspreidt via aggregators en samenvattingen.

De waarde van dit artikel ligt daarom minder in de cijfers dan in de sortering: welke vergelijkingen standhouden, welke niet, en waaraan u het verschil herkent.

Wat werkelijk één op één te vergelijken is

Er blijft een kleine maar zuivere kern over. Alle regels in onderstaande tabel komen uit de Anthropic-modeldocumentatie, de Anthropic-prijspagina en de OpenAI-ontwikkelaarsdocumentatie voor gpt-6-astra, geraadpleegd op 10 september 2026. Het zijn uitspraken van elke aanbieder over het eigen product, in dezelfde eenheid, zonder meetkader ertussen.

Bij de regel cache-schrijven hoort een voorbehoud: Anthropic verkoopt twee bewaartermijnen, vijf minuten en een uur, terwijl OpenAI geen vergelijkbare staffel publiceert. De twee bedragen van 12,50 USD liggen dicht bij elkaar, maar staan niet volledig parallel.

De economisch interessante regel is cache-lezen. Een factor vier in het voordeel van Anthropic klinkt als een bijpost, maar dat is het bij agentisch werk niet: daar wordt dezelfde context, repository, systeeminstructie en gereedschapsbeschrijvingen, over honderden stappen telkens opnieuw gelezen. Anthropic becijfert de daaruit volgende besparing zelf op ongeveer 25% ten opzichte van Fable 5 bij typische belastingen en tot ongeveer 45% bij sterk agentische belastingen. Dat cijfer is een modelberekening van de aanbieder, geen prijsverlaging: de catalogusprijzen voor invoer en uitvoer zijn ongewijzigd, en een belasting met weinig cachetreffers bespaart praktisch niets.

Twee andere posten horen in elke calculatie thuis. Anthropics Batch-API halveert beide richtingen, tot 5 USD invoer en 25 USD uitvoer per miljoen tokens. En wie de inferentie bij Anthropic op de Verenigde Staten vastzet, betaalt volgens Anthropics documentatie over dataresidentie een vermenigvuldiger van 1,1 op invoer, uitvoer, cache-schrijven en cache-lezen.

Terminal-Bench 4.0: het enige cijfer met een echte kruiscontrole

Eén benchmarkregel verdient hier bijzonder vertrouwen, om een reden die zelden wordt uitgelegd.

Op 1 september 2026 meldt Anthropic voor Claude Fable 5.1 op Terminal-Bench 4.0 55,8%. In de door OpenAI gerapporteerde resultaten voor GPT-6 Astra, op 3 september 2026 doorgegeven door DataCamp en daar uitdrukkelijk aangeduid als door de aanbieder gerapporteerd, staat Astra op 57,7% en wordt Fable 5.1 met ongewijzigd 55,8% vermeld.

Beide aanbieders komen dus onafhankelijk van elkaar op hetzelfde cijfer voor het model van het andere kamp. Dat is de sterkste enkelvoudige controle die in deze hele vergelijking beschikbaar is. Een aanbieder heeft weinig belang bij het te hoog inschatten van een concurrent, en wanneer twee partijen met tegengestelde belangen hetzelfde cijfer melden, pleit dat ervoor dat het cijfer de opstelling overleeft in plaats van een huismeting te zijn.

Toch blijven er twee beperkingen. Ten eerste vermeldt geen van beide publicaties met welk harness, welk scaffold en welk effortniveau is gemeten. Ten tweede is het verschil van 1,9 procentpunt klein genoeg om juist uit die factoren voort te komen. De houdbare lezing luidt dan ook: op Terminal-Bench 4.0 liggen beide modellen volgens de opgaven van beide aanbieders dicht bij elkaar, met een lichte voorsprong voor Astra volgens OpenAI's meting.

Wat niet vergelijkbaar is, en waarom

Het grootste deel van de gepubliceerde cijfers hoort niet in één gezamenlijke tabel. Dat is geen formalisme, het is het verschil tussen een beslissingsgrondslag en een muur van getallen.

• OSWorld 2.0. Anthropic geeft voor Fable 5.1 twee waarden, 77,9% met deelpunten en 41,7% bij strikte beoordeling. Aan OpenAI-zijde staat voor Astra één enkele waarde van 72,6%, zonder vermelding van de beoordelingswijze. 72,6 tegenover 77,9 zetten is even ongefundeerd als het tegenover 41,7 zetten. Zolang de beoordelingswijze niet overeenkomt is hier geen vergelijking, alleen een selectie.
• Contextvenster. Anthropic noemt 1.000.000 tokens, OpenAI 1.050.000 met maximaal 922.000 tokens invoer. Deze cijfers zijn geen capaciteitsopgave op dezelfde schaal, want een token betekent per tokenizer iets anders. Anthropic schrijft zelf dat de huidige tokenizer voor dezelfde tekst ongeveer 30% meer tokens produceert dan de eigen voorganger. Een aanbiederoverstijgend cijfer voor tokens per woord is niet openbaar, dus de vraag welk model meer tekst bevat, is uit open bronnen niet te beantwoorden.
• AutomationBench. Anthropic publiceert 31,4% voor Fable 5.1. In het eigen aankondigingsbericht claimt OpenAI de koppositie op dezelfde benchmark, maar noemt daar geen cijfer. Er valt eenvoudigweg niets te vergelijken.
• Regels waarin het Claude-cijfer niet van Anthropic komt. Voor ScreenSpot-Pro, FrontierMath Tier 4 v2, ExploitBench, ARC-AGI-3, GPQA Diamond en FrontierCode 1.1 bestaan alleen waarden van OpenAI-zijde. Het Claude-cijfer in die regels is OpenAI's meting van Claude, en in meerdere gevallen een meting van Claude Fable 5 of Claude Opus 5, niet van Fable 5.1. Wie ze aan Anthropic toeschrijft, citeert de verkeerde bron en deels ook het verkeerde model.
• Effortniveaus. Beide aanbieders staan wisselende rekeninzet per verzoek toe. Bij Anthropic verschilt zelfs de standaardinstelling per omgeving: high in Claude Code, medium in claude.ai en Claude Cowork. Artificial Analysis meet op de niveaus "max" en "xhigh". Een benchmarkcijfer zonder vermeld effortniveau is niet vergelijkbaar met een cijfer op een ander niveau. Dat is geen finesse, het is de waarschijnlijkste reden waarom dezelfde ranglijst op drie websites drie uitkomsten toont.

Eén bijzonder geval verdient een waarschuwing: de 99,9% die voor Astra op ARC-AGI-3 circuleert, draagt in de bron de toevoeging "adapter harness" en staat naast 7,8% voor het vorige model. Een sprong van ongeveer 92 punten over een harnesswissel beschrijft eerst het harness en pas daarna het model. Dat cijfer hoort in geen enkele kop thuis.

De ranglijsten van derden spreken elkaar openlijk tegen

Wie de aanbiedercijfers wantrouwt, grijpt naar ranglijsten van derden. In dit geval helpt dat niet, want de ranglijsten spreken elkaar tegen, en dat bij één en dezelfde index.

Artificial Analysis geeft in het eigen artikel van 3 september 2026 voor de Intelligence Index: GPT-6 Astra 61, GPT-5.6 Sol 61, Claude Fable 5.1 66, dat laatste op het hoogste effortniveau met een fallbackconfiguratie die niet de API-standaard is. BenchLM geeft dezelfde index in september 2026 anders weer: GPT-5.6 Sol leidt met 58,9%, Fable 5.1 staat op 53,7%. llm-stats, geraadpleegd op 10 september 2026, meldt Fable 5.1 op 56,8, Astra op 54,7 en Claude Opus 5 op 54,1.

Drie bronnen, één index, drie volgordes. Ze kunnen niet allemaal actueel zijn. Als oorzaken komen verschillende peildata, verschillende effortinstellingen en het door elkaar halen van punten en percentages in aanmerking. De praktische consequentie is eenvoudig: een Intelligence Index-waarde zonder vermelding van website, datum en effortniveau is geen informatie. Artificial Analysis wijst overigens zelf op gemengde bevindingen, waaronder een terugval van ongeveer 80 Elo-punten op GDPval-AA v2.

Blijft de arena. Ook daar valt niets te halen: noch Claude Fable 5.1 noch GPT-6 Astra heeft in de hier bereikbare momentopnamen van september 2026 een gerangschikte LMArena-positie, omdat arena-Elo stemvolume nodig heeft en weken achterloopt op frontier-releases. Zelfs als die waarden er wel waren, zouden ze het verkeerde instrument voor deze beslissing zijn. Blinde paarsgewijze voorkeur meet de ervaren antwoordkwaliteit op zelfgekozen prompts, reageert sterk op opmaak en breedsprakigheid, en zegt weinig over agentisch werk over lange trajecten. Voor een codeeragent of een kennisplatform is dat niet de maatstaf waarop een inkoopbeslissing hoort te steunen.

FrontierCode 1.1: het cijfer dat tegen de eigen aanbieder pleit

Er is in deze vergelijking één regel die om methodische redenen zwaarder weegt dan de andere. Op FrontierCode 1.1 staat GPT-6 Astra volgens OpenAI's eigen gerapporteerde resultaten op 53,3%, en daarmee achter Claude Fable 5 met 53,5%.

Twee preciseringen zijn hier verplicht. De vergelijkingswaarde betreft Claude Fable 5, niet Fable 5.1, en Anthropic heeft voor Fable 5.1 op deze benchmark geen eigen waarde gepubliceerd. Het verschil bedraagt 0,2 procentpunt en valt daarmee binnen elke plausibele meetspreiding.

Toch is het het meest betrouwbare soort cijfer dat een productaankondiging kan bevatten. Een aanbieder die een regel publiceert waarin zijn nieuwe vlaggenschip achter een vreemd model eindigt, heeft daar geen marketingbelang bij. Wie wil inschatten hoe draagkrachtig een benchmarktabel is, zou eerst moeten kijken of zulke regels erin voorkomen. Een tabel waarin de publicerende aanbieder elke afzonderlijke regel wint, is geen meting maar een selectie.

De richting keert om: EU-dataresidentie en zero data retention

Tot hier loopt Anthropic voorop op prijs en cache-economie en staan beide modellen ongeveer gelijk op de benchmarks. Bij datagovernance draait het beeld volledig om, en voor een Duits bedrijf is dat de kolom die een architectuur verandert.

Aan Anthropic-zijde staat dit in de eigen documentatie. De parameter inference_geo accepteert precies twee waarden, global en us, en als opslagregio van een workspace is uitsluitend us te kiezen, vastgelegd bij het aanmaken. De retentiekant is nog duidelijker: Anthropic merkt Fable 5.1 en Mythos 5.1 (en ook Fable 5 en Mythos 5) aan als Covered Models die een bewaartermijn van 30 dagen vereisen en niet beschikbaar zijn onder zero data retention tenzij Anthropic dat uitdrukkelijk toestaat. Een organisatie met ZDR moet de bewaartermijn van 30 dagen actief inschakelen voor een specifieke workspace, anders wordt het verzoek geweigerd.

Aan OpenAI-zijde stelt de ontwikkelaarsdocumentatie over gegevensverwerking dat Europa (EER en Zwitserland) zowel regionale opslag als regionale verwerking via eu.api.openai.com ondersteunt, ingesteld per project, waarbij regio's buiten de Verenigde Staten goedkeuring voor misbruikcontroles en een aangepast retentie-addendum vergen. Diezelfde pagina somt de ZDR-geschikte endpoints op, waaronder /v1/chat/completions en /v1/responses, en sluit Assistants, Threads, Vector Stores, fine-tuning en Batches uitdrukkelijk uit.

Nauwkeurigheid weegt hier zwaarder dan een gladde formulering: geen enkele gevonden bron stelt positief dat GPT-6 Astra ZDR-geschikt is. Gedocumenteerd is dat die endpoints ZDR ondersteunen en dat voor gpt-6-astra geen modelspecifieke uitzondering is gepubliceerd. Het ontbreken van een beperking is echter geen toestemming. Wie daar een architectuur op bouwt, laat dat beter contractueel bevestigen dan het uit een documentatiegat af te leiden. Bij Anthropic is de situatie de andere kant op eenduidig, omdat de uitzondering daar zwart op wit staat.

Ook een veelgehoorde zin verdient correctie: "Claude heeft EU-dataresidentie omdat het op AWS Frankfurt draait." Dat klopt precies dan wanneer u Claude via een partnercloud afneemt, zoals Amazon Bedrock of Google Cloud, waar de cloudaanbieder de regio bepaalt en verwerker is. Voor Anthropics eigen API geldt het niet. Voor gegarandeerde regionale routering verwijst Anthropic zelf naar de regionale endpoints van de partnerclouds, tegen een toeslag van 10% ten opzichte van de globale endpoints. Voor een AVG-toets is precies dat onderscheid de kern, omdat het bepaalt met wie de verwerkersovereenkomst wordt gesloten.

Artikel 50: een verschil dat maar half te onderbouwen is

Sinds 2 augustus 2026 gelden de transparantieverplichtingen uit artikel 50 van de AI-verordening, die machineleesbare markering van synthetische inhoud vereisen. Anthropic geeft aan dat Fable 5.1 en Mythos 5.1 vanaf dag één een onzichtbaar watermerk in de tekst dragen, en past die markering wereldwijd toe en niet alleen in de EU. Voor zover de beschikbare bronnen reiken, is dat een echt verschil.

Die zin heeft echter beide helften nodig. Er is geen bron gevonden die zegt of de tekstuitvoer van GPT-6 Astra gemarkeerd is. OpenAI's gedocumenteerde herkomstaanpak, C2PA Content Credentials plus SynthID, betreft beeld en audio; de bereikbare pagina's zeggen niets over tekst. Uit dat gat volgt niet dat OpenAI tekst niet markeert. Daarom beweren wij dat niet. OpenAI publiceert afzonderlijk klantinformatie over de AI-verordening.

En ook Anthropics watermerk draagt minder ver dan de term suggereert. Anthropic schrijft in de eigen helppagina's dat een gedetecteerde markering aangeeft dat inhoud mogelijk door Claude is verwerkt, niet volledig sluitend is en op zichzelf de herkomst van de inhoud niet bevestigt. De bijbehorende detectie-API bevindt zich bovendien in een private preview voor geselecteerde organisaties. Als bouwsteen van een complianceverhaal is het watermerk bruikbaar; als bewijsmiddel niet.

Wat dit betekent voor een Duitse beslissing

Als u één regel uit deze vergelijking meeneemt, neem dan deze: bij twee frontier-modellen die op de houdbare cijfers dicht bij elkaar liggen en identiek geprijsd zijn, beslist een benchmarkregel zelden iets. Het verschil op Terminal-Bench 4.0 bedraagt 1,9 procentpunt zonder vermeld harness. Op FrontierCode 1.1 is het 0,2 punt de andere kant op, tegenover een ouder Claude-model. Zulke verschillen verschuiven bij de volgende release en veranderen geen enkele architectuur.

Wat wel een architectuur verandert, staat in de governancekolom. Een organisatie die aan zero data retention gebonden is, kan Claude Fable 5.1 zonder uitdrukkelijke toestemming niet via Anthropics eigen API inzetten, hoe goed het model ook is. Een organisatie die inferentie binnen de EU verlangt, vindt die weg bij Anthropic alleen via een partnercloud, met de bijbehorende toeslag en een andere verwerker in het contract. Omgekeerd is Anthropics voordeel bij cache-lezen reëel en groeit het met het aandeel agentisch werk waarin dezelfde context honderden keren wordt gelezen.

In de praktijk: klaar eerst de verplichtingen uit, daarna de kosten en pas als laatste de benchmarks. In de omgekeerde volgorde bouwt u een systeem dat goed meet en het gesprek over gegevensbescherming niet doorstaat. En controleer bij elk cijfer dat iemand u toont drie dingen: wie het heeft gerapporteerd, wanneer, en op welk effortniveau.

Wat de release zelf voor een Duits bedrijf veranderde, behandelen we in ons artikel over Claude Fable 5.1. Hoe het model zich in lopend projectwerk gedraagt, behandelen we in capaciteiten in de praktijk. En als het antwoord op de governancevraag is dat de data het pand helemaal niet mogen verlaten, loopt de route via de afweging tussen on-premise en cloud, niet via een ranglijst.

Die Ursache ist fast immer die Datenstruktur: die Bäume, mit denen parametrische Umgebungen Listen von Listen verwalten. Etwa alle Fenster je Geschoss je Fassade. Wer diese Ebenen einmal falsch zusammenführt, bekommt kein Fehlerbild, sondern ein anderes Bauwerk.

Warum der Fehler nicht auffällt

Weil die Ausgabe plausibel ist. Wenn 120 Paneele erwartet werden und 120 Paneele entstehen, ist die erste Prüfung bestanden. Dass Paneel 47 die Maße von Position 74 trägt, sieht man an einer Fassade mit ähnlichen Elementen nicht.

Verstärkt wird das dadurch, dass parametrische Umgebungen selten hart abbrechen. Sie gleichen Listen unterschiedlicher Länge stillschweigend an, indem sie den letzten Wert wiederholen. Das ist im Alltag bequem und in genau diesem Fall fatal: die Struktur bleibt heil, der Inhalt nicht.

Die drei Muster, die fast alle Fälle erklären

Erstens der Ebenenversatz. Zwei Datenströme werden zusammengeführt, die auf unterschiedlichen Ebenen verzweigt sind. Einer trägt die Struktur Fassade zu Geschoss zu Öffnung, der andere nur Fassade zu Öffnung. Das Ergebnis hat die richtige Anzahl und die falsche Zuordnung.

Zweitens das ungewollte Abflachen. Ein Arbeitsschritt, der die Baumstruktur einebnet, um eine Operation zu ermöglichen, und danach wird nie wieder verzweigt. Ab dieser Stelle weiß das Modell nicht mehr, welches Element zu welchem Geschoss gehört, und es sagt es nicht.

Drittens die Wiederholung des letzten Werts. Eine Liste mit 12 Werten trifft auf eine mit 120 Elementen. Die ersten 12 stimmen, die restlichen 108 tragen den zwölften Wert. Der Fehler ist am Anfang der Liste unsichtbar und am Ende systematisch.

Prüfen statt hinsehen

Die wirksamste Gegenmaßnahme ist keine höhere Aufmerksamkeit, sondern eine Zählung. An jeder Stelle, an der zwei Ströme zusammenkommen, gehört die erwartete Zahl der Zweige und die erwartete Zahl der Elemente je Zweig ausgeschrieben und mit der tatsächlichen verglichen.

Das kostet ein paar Minuten pro Zusammenführung und fängt alle drei Muster oben ab, weil alle drei die Zählung verändern, bevor sie die Geometrie verändern.

Zweite Maßnahme: eine sichtbare Probe. Ein Element wird eingefärbt oder beschriftet und im Modell verfolgt, vom Eingang bis zum Zuschnitt. Wenn Position 47 am Ende noch Position 47 ist, stimmt die Zuordnung. Das ist der einzige Test, der die ganze Kette abdeckt.

Dritte Maßnahme: die Struktur benennen. Wer die erwartete Baumstruktur an den wichtigen Stellen als Kommentar hinschreibt, dokumentiert nicht nur, sondern zwingt sich zu der Frage, ob sie noch stimmt.

Warum das teurer ist als es klingt

Weil der Fehler nach unten durchschlägt. Aus derselben Struktur entstehen Zuschnitte, Stücklisten und Preise. Eine Zuordnung, die im Bild nicht auffällt, fällt in der Fertigung auf, wenn das Material bereits geschnitten ist.

Und weil das Vertrauen mitgeht. Ein Team, das einmal erlebt hat, dass ein parametrisches Modell überzeugend falsch war, prüft danach jede Ausgabe von Hand nach. Damit ist der Zeitgewinn weg, der der Grund für die Methode war.

Was wir uns angewöhnt haben

Zählprüfungen an jeder Zusammenführung, eine markierte Probe je Bauteilfamilie, und Cluster mit festgelegten Ein- und Ausgängen statt gewachsener Graphen. Ein Cluster erzwingt eine Entscheidung darüber, welche Struktur hinein- und herausgeht, und genau diese Entscheidung ist es, die sonst unterbleibt.

Nichts davon ist aufwendig. Es ist die Sorte Disziplin, die aus der Softwareentwicklung kommt und in parametrischen Modellen aus demselben Grund wirkt: der Fehler, der nicht abbricht, ist der teuerste.

Das ist der Punkt, an dem aus Computational Design Softwareentwicklung wird. Eine Definition lässt sich ohne Oberfläche auf einem Server betreiben und über eine Schnittstelle ansprechen. Was dann davorsteht, kann ein Konfigurator im Browser sein, eine Angebotsrechnung, eine Prüfung in einem bestehenden System oder alles drei aus derselben Quelle.

Was ein Geometrie-Server tatsächlich ist

Ein Rechenknoten, der die Definition geladen hat, Parameter entgegennimmt und das Ergebnis zurückgibt: Geometrie in einem Austauschformat, dazu die Kennzahlen, die im Modell ohnehin berechnet werden. Fläche, Gewicht, Teilezahl, Verschnitt, Materialbedarf.

Der entscheidende Teil ist der zweite. Ein Konfigurator, der nur ein Bild liefert, ist eine Visualisierung. Einer, der zusätzlich die Stückliste und den Materialbedarf zurückgibt, ist ein Vertriebswerkzeug, und das ist der Unterschied, der ein solches Vorhaben trägt.

Die Definition bleibt dabei dieselbe Datei, mit der entworfen wird. Genau das ist der Punkt: es gibt keine zweite Nachbildung der Logik, die auseinanderlaufen kann.

Warum die zweite Nachbildung das eigentliche Problem ist

Der übliche Weg zu einem Konfigurator führt über eine Neuimplementierung: Ein Entwicklungsteam bekommt die Regeln als Dokument beschrieben und baut sie in der Anwendung nach. Von diesem Tag an gibt es zwei Wahrheiten.

Sie laufen auseinander, und zwar leise. Der Entwurf bekommt eine neue Randbedingung, der Konfigurator nicht. Ein halbes Jahr später verkauft der Vertrieb eine Ausführung, die die Fertigung ablehnt, und niemand kann sagen, seit wann.

Mit der Definition als Dienst gibt es diese Klasse von Fehlern nicht. Eine Regeländerung im Entwurf ist eine Regeländerung im Verkauf, weil es dieselbe Regel ist.

Der Zuschnitt, der in der Praxis funktioniert

Nicht jede Anfrage darf eine volle Berechnung auslösen. Bewährt hat sich eine Trennung in drei Stufen: eine sofortige Vorschau aus vorberechneten Zwischenständen, eine vollständige Berechnung auf Anforderung, und eine Ableitung der Fertigungsdaten erst nach der Auswahl.

Der Variantenraum wird dafür vorher abgetastet und die Ergebnisse werden abgelegt. Was ein Kunde im Browser bewegt, ist dann meistens eine Auswahl aus bekannten Ergebnissen und keine Live-Rechnung. Das ist der Unterschied zwischen einer Antwort in Millisekunden und einer in zwanzig Sekunden.

Für die Darstellung im Browser wird die Geometrie vereinfacht ausgeliefert. Wichtig ist, dass diese Vereinfachung automatisiert aus dem Konstruktionsmodell fällt und nicht von Hand gepflegt wird, sonst ist die zweite Wahrheit über die Hintertür wieder da.

Woran es tatsächlich klemmt

Rechenzeit. Eine Definition, die im Entwurf zwanzig Sekunden braucht, braucht sie auch auf dem Server. Interaktiv ist das nicht. Entweder wird die Definition auf Geschwindigkeit hin überarbeitet, was oft möglich und selten beliebt ist, oder der Variantenraum wird vorberechnet.

Zustand. Entwurfsumgebungen halten Zustand zwischen Aufrufen. Ein Dienst, der viele Anfragen parallel bedient, darf das nicht. Definitionen, die sich auf zuletzt geladene Dateien oder Referenzobjekte verlassen, verhalten sich unter Last nicht reproduzierbar, und dieser Fehler tritt genau dann auf, wenn niemand zusieht.

Lizenzierung. Der Serverbetrieb einer Entwurfsumgebung ist lizenzrechtlich eine andere Frage als der Arbeitsplatzbetrieb. Das gehört vor die Architekturentscheidung und nicht danach, weil es das gesamte Betriebsmodell bestimmt.

Und Fehlerfälle. Eine unzulässige Parameterkombination darf keinen Serverfehler erzeugen, sondern muss eine begründete Ablehnung zurückgeben. Randbedingungen als Prüfungen im Modell zahlen sich hier ein zweites Mal aus.

Wo die Daten bleiben

Der gesamte Aufbau lässt sich im eigenen Haus betreiben. Das ist kein Randthema: eine Definition enthält die Konstruktionslogik eines Produkts, und für viele Hersteller ist genau das der Kern dessen, was nicht abfließen darf.

Wir bauen solche Dienste deshalb so, dass Rechenknoten, Ergebnisspeicher und Auslieferung in der Infrastruktur des Kunden stehen können, mit einer Schnittstelle als einziger Berührungsfläche nach außen.

Wann sich der Schritt lohnt

Wenn dieselben Fragen mehrfach im Monat an dieselbe Person gehen. Wenn der Vertrieb Varianten verkaufen soll, die er selbst nicht durchrechnen kann. Wenn aus der Geometrie ohnehin Stücklisten oder Preise entstehen sollen.

Und nicht, wenn der Konfigurator vor allem hübsch sein soll. Ein 3D-Konfigurator ohne Kennzahlen dahinter ist eine Visualisierung mit Wartungsaufwand, und die gibt es billiger.

Was hier steht, sind keine Preise. Es sind die Kostenstellen, nach denen Sie ein Angebot durchsuchen sollten, und die Größenordnungen, in denen sie zueinander stehen.

Die Inferenz ist selten das Problem

Die Rechnung, mit der gerechnet wird, ist die pro Anfrage: Kontext hinein, Antwort heraus, Preis je Token. Sie ist gut kalkulierbar und in den meisten Häusern kleiner als erwartet, weil die Zahl der Anfragen kleiner ist als erwartet. Ein internes Wissenssystem mit 200 Beschäftigten sieht keine Millionen Anfragen.

Worauf zu achten ist: deutschsprachige Texte verbrauchen spürbar mehr Token als englische, und ein großzügig gefülltes Kontextfenster kostet pro Anfrage mehr als eine gute Suche davor. Wer Retrieval und Reranking ernst nimmt, senkt damit auch die laufenden Kosten, nicht nur die Fehlerquote.

Der Index ist die eigentliche laufende Position

Ein Index ist kein Bauwerk, das fertig wird. Neue Dokumente müssen hinein, geänderte ersetzt, gelöschte entfernt. Das ist Betrieb, und es braucht jemanden, der zuständig ist.

Der teure Sonderfall ist der Wechsel des Embedding-Modells. Embeddings sind nur untereinander vergleichbar, also erzwingt jeder Wechsel die Neuberechnung des gesamten Bestands. Bei einigen zehntausend Dokumenten ist das ein Wochenendlauf, bei Millionen eine Planung. Wer das nicht einkalkuliert, sitzt auf dem Modell fest, mit dem er angefangen hat.

Dazu kommt die Pflege des Bestands selbst, und das ist die Position, die am häufigsten fehlt. Ein Retrieval-System zitiert eine überholte Arbeitsanweisung genauso überzeugend wie die gültige. Aussortieren ist Handarbeit und wird wichtiger, nicht unwichtiger, sobald das System benutzt wird.

Evaluation ist eine Kostenstelle, keine Phase

Der Goldstandard-Testsatz aus echten Fragen mit geprüften Antworten entsteht einmal und veraltet danach. Neue Themen kommen dazu, alte Antworten stimmen nicht mehr.

Ohne laufende Evaluation lässt sich keine Änderung mehr verantworten: ein neues Modell, ein anderes Chunking, ein zusätzlicher Filter. Man merkt an Einzelfällen, dass etwas anders ist, und kann nicht sagen, ob es besser ist. Ab diesem Punkt wird nichts mehr geändert, und das System altert.

Als Größenordnung: die Pflege von Testsatz und Auswertung ist über die Laufzeit derselbe Aufwand wie die Indexpflege, und beide zusammen übersteigen die Inferenzkosten in fast allen Fällen im Mittelstand.

Lokal oder gehostet ist eine Tauschentscheidung, keine Sparentscheidung

Lokaler Betrieb tauscht laufende Token-Kosten gegen einmalige Anschaffung plus Betrieb. Die begrenzende Größe ist der Videospeicher, weil er bestimmt, welche Modellgröße hineinpasst; Rechengeschwindigkeit entscheidet danach nur über den Durchsatz.

Was in der Rechnung oft fehlt: Strom, Kühlung, Ersatzteile und vor allem jemand, der die Modelle aktualisiert. Ein lokales Modell veraltet, und der Aktualisierungsprozess ist Ihrer.

Was dafür spricht, ist meistens nicht der Preis, sondern dass die Dokumente das Haus nicht verlassen. Das ist eine gute Begründung. Die Ersparnis als Hauptargument trägt nur bei hohem, gleichmäßigem Anfragevolumen.

Die Positionen, nach denen wir ein Angebot durchsuchen würden

Wer pflegt den Index und mit welchem Aufwand pro Monat. Was passiert bei einem Wechsel des Embedding-Modells und wer trägt ihn. Wie wird gemessen, ob das System noch richtig antwortet, und wie oft. Wie werden Rechte abgebildet und wer pflegt sie, wenn sich die Organisation ändert. Und was kostet der Ausstieg, also in welcher Form die Daten und der Index das System verlassen.

Ein Angebot, das diese fünf Fragen beantwortet, ist möglicherweise teurer als eines, das sie nicht stellt. Es ist auch das einzige der beiden, dessen Zahl nach einem Jahr noch stimmt.

Die ehrliche Antwort ist eine Rechnung, keine Haltung. Ein parametrisches Modell verschiebt Aufwand von hinten nach vorne. Es kostet mehr, bevor die erste Ausführung steht, und weniger bei jeder weiteren. Ob sich das trägt, hängt an drei Größen, die sich vor Projektbeginn abschätzen lassen.

Die drei Größen, an denen es hängt

Die erste ist die Zahl der Ausführungen. Nicht die Zahl der Varianten, die im Entwurf betrachtet werden, sondern die Zahl der Teile, Module oder Objekte, die am Ende wirklich hergestellt oder gebaut werden. Zwanzig unterschiedliche Fassadenpaneele sind ein Fall dafür. Ein Bauwerk ist es nicht.

Die zweite ist die Zahl der Änderungsrunden. Sie wird fast immer unterschätzt und ist der eigentliche Hebel. Ein Entwurf, der viermal überarbeitet wird, wird bei manueller Bearbeitung viermal vollständig nachgezogen. Ein Regelwerk wird einmal angepasst und rechnet neu.

Die dritte ist die Kopplung zwischen Entwurf und Nachgelagertem. Wenn aus derselben Geometrie auch Stücklisten, Zuschnitte, Angebotspreise oder ein Konfigurator entstehen sollen, entsteht der Nutzen nicht einmal, sondern pro angeschlossenem Schritt.

Eine Faustregel, die trägt

Als grobe Orientierung aus umgesetzten Projekten: Der Aufbau einer belastbaren Definition kostet ungefähr das Drei- bis Fünffache der ersten manuell gezeichneten Variante. Jede weitere Variante kostet danach nahezu nichts.

Daraus folgt der Umschlagpunkt bei etwa fünf Ausführungen, wenn sich nichts mehr ändert. Er verschiebt sich auf zwei bis drei, sobald mit mindestens einer echten Änderungsrunde zu rechnen ist, weil die Änderung im Regelwerk einmal und in der Zeichnung pro Variante anfällt.

Diese Zahlen sind Größenordnungen und keine Kalkulation. Sie sind trotzdem nützlich, weil sie die Diskussion an der richtigen Stelle führen: nicht darüber, ob Parametrik beeindruckend ist, sondern darüber, wie oft sich Ihr Entwurf ändern wird.

Wo die Rechnung kippt, und das wird selten gesagt

Bei einem einmaligen Entwurf ohne Wiederholung. Ein Sonderbauteil, ein Messestand, ein Objekt, das genau einmal existiert: hier gewinnt Zeichnen, und zwar deutlich. Ein Regelwerk für eine einzige Ausführung ist ein teurer Umweg.

Bei unklaren Randbedingungen. Parametrik zwingt dazu, die Regel vorher zu formulieren. Wenn niemand sagen kann, welche Maße gelten, welche Toleranzen zulässig sind und welche Ausführungen ausgeschlossen sind, entsteht ein Modell, das schnell viele falsche Varianten erzeugt. Das ist schlechter als eine Zeichnung, weil es überzeugender aussieht.

Bei Entwürfen, deren Wert in der Ausnahme liegt. Ein Regelwerk ist gut in dem, was sich wiederholt. Wo die gestalterische Qualität gerade aus dem Bruch mit der Regel entsteht, arbeitet die Methode gegen das Ziel, und die Ausnahmen zurück ins Modell zu bauen kostet mehr als sie erspart.

Und bei Teams ohne Übernahme. Eine Definition, die nur ihr Autor ändern kann, ist eine Abhängigkeit und kein Werkzeug. Wenn niemand im Haus sie weiterführen soll oder kann, gehört das in die Rechnung.

Was die Rechnung deutlich verbessert

Bauteilfamilien statt Einzelteile. Fünf Familien mit je zwanzig Maßen sind herstellbar und kalkulierbar, hundert Unikate sind es meist nicht. Die Familienbildung ist der Schritt, in dem ein parametrisches Modell den Preis wirklich senkt, und sie ist eine Entwurfsentscheidung, keine Software-Einstellung.

Randbedingungen als Prüfungen im Modell. Wenn eine unzulässige Ausführung gar nicht erst entsteht, entfällt die Prüfschleife am Ende. Das ist derselbe Gedanke wie ein Test in der Softwareentwicklung und wirkt aus demselben Grund.

Und eine Definition, die wie Software behandelt wird: benannt, strukturiert, kommentiert, versioniert. Eine gewachsene Definition ohne Struktur ist nach sechs Monaten für niemanden mehr änderbar, auch nicht für ihren Autor. Dann ist der eingesparte Aufwand zurück.

Wie wir das vor einem Angebot klären

Wir fragen nach der Zahl der herzustellenden Ausführungen, nach der erwarteten Zahl der Abstimmungsrunden und danach, was aus der Geometrie außer Bildern noch entstehen soll. Diese drei Antworten reichen in den meisten Fällen für eine belastbare Einschätzung.

Fällt sie negativ aus, sagen wir das. Ein Vorhaben, dem wir vom parametrischen Weg abraten, ist ein besseres Ergebnis als eine Definition, die niemand braucht.

WAT VISUEEL ZOEKEN BEWUST NIET LEVERT

Visuele retrievalmodellen vinden de juiste pagina, ook in een lastige scan. Maar ze geven u een afbeelding terug, geen tekst. U kunt daaruit niet zomaar een regel kopiëren, geen volledige-tekst zoekopdracht over het archief leggen, geen machineleesbaar controlespoor bouwen. Voor dat alles hebt u herkende tekst nodig. Dat is geen zwakte van de nieuwe aanpak, maar een bewuste taakverdeling: zoeken op de afbeelding, tekstextractie via OCR, elke stap voor wat hij het best kan.

WAT PADDLEOCR-VL KAN

Baidu heeft met PaddleOCR-VL een open OCR-model gepresenteerd dat met slechts 0,9 miljard parameters topwaarden behaalt (Project). Het herkent tekst, tabellen, formules en diagrammen in 109 talen en reconstrueert de semantische structuur van een document. Op de OmniDocBench-v1.5-benchmark staat het met ongeveer 94,5% nauwkeurigheid vooraan. Het valt onder de Apache-2.0-licentie, is dus commercieel vrij te gebruiken en lokaal in te zetten. Voor het mkb betekent dat: sterke tekstherkenning zonder doorlopende kosten en zonder datalekken naar buiten.

DE HYBRIDE OPZET

In de praktijk lopen beide wegen naast elkaar. Het visuele zoeken vindt de relevante pagina's snel en layoutgetrouw. Waar daaruit harde tekst moet ontstaan, bijvoorbeeld voor een factuurregel, een contractclausule om te citeren of een invoer in het ERP, neemt OCR het over op precies die paar pagina's. Men hoeft niet het hele archief door OCR te sturen, maar alleen wat het zoeken al als belangrijk heeft gemarkeerd. Dat houdt de pipeline slank en voorkomt dat OCR-fouten van meet af aan in het zoeken insijpelen.

DE PRAGMATISCHE LIJN

Of-of is hier de verkeerde houding. Visueel zoeken verbetert het vinden, OCR verbetert de verwerking. Wie beide als tools met duidelijke taken beschouwt, bouwt de robuustere kennisbank dan iemand die dogmatisch op één kant inzet. Hoe de bouwstenen samenhangen, van encoder tot vectordatabase, staat in het stackoverzicht.

Voor een mkb-onderneming die dagelijks contracten, technische handleidingen en meerpagina's facturen verwerkt, is dat het interessantere nieuws. Niet dat de tekstherkenning een paar punten beter is, maar: een document van 80 pagina's hoeft niet meer in stukken geknipt en weer samengevoegd te worden, en daarvoor hoeft geen document het pand te verlaten.

WAT UNLIMITED-OCR ANDERS DOET

De kern is een aangepast aandachtsmechanisme in de decoder, dat het geheugen constant houdt. Klassieke OCR-modellen op transformer-basis laten de zogenoemde KV-cache meegroeien met de lengte van het document. Hoe langer de PDF, hoe meer geheugen, tot het op een gegeven moment niet meer in een verwerking past.

Unlimited-OCR vervangt dit onderdeel door Reference Sliding Window Attention (R-SWA). De KV-cache blijft daarbij constant, onafhankelijk van de documentlengte. Precies dat bedoelt de term one-shot long-horizon parsing: een lang document wordt in één doorgang gelezen, in plaats van het in secties op te delen en de resultaten achteraf samen te voegen.

Opvallend is het trainingstraject. Het team is niet bij nul begonnen, maar heeft het DeepSeek-OCR-checkpoint verder getraind: de encoder bevroren en alleen de decoder over circa 4.000 stappen aangepast. Daarmee staat het model in directe lijn met DeepSeek-OCR, dat we in de stackcontext al hebben geplaatst. Code en gewichten liggen open op GitHub.

WAAROM DE CONSTANTE KV-CACHE TELT

Het eigenlijke probleem bij lange documenten is niet de afzonderlijke pagina, maar de samenhang over de pagina's heen. Als een model een document van 60 pagina's in blokken van tien pagina's knipt, gaat precies verloren wat in de B2B-praktijk telt: een tabel die over de paginabreuk doorloopt, een clausule die verwijst naar een eerdere sectie, een post waarvan de referentiewaarde twintig pagina's eerder staat.

Een constante KV-cache maakt het mogelijk om het hele document in één context te houden. Het geheugen groeit niet mee met de lengte, dus blijft de structuur over alle pagina's behouden. Bovendien wordt het sneller: Baidu noemt in base-modus 5.580 tokens per seconde tegenover 4.951 bij DeepSeek-OCR, bij een outputlimiet van 6.000 tokens ligt het verschil rond de 35 procent.

Wat nauwkeurigheid betreft scoort Unlimited-OCR op OmniDocBench v1.5 93,23 punten, 6,22 boven de DeepSeek-OCR-basis, op v1.6 93,92. Dat zijn de cijfers uit het paper. Op uw eigen documenten telt uiteindelijk hoe het model omgaat met uw tabellen, stempels en formulieren, niet het gemiddelde van een publieke testset. Verwant is de ontwikkeling bij subkwadratische LLM's, die lange context on-premise goedkoper maken.

WAAR DIT IETS VERANDERT IN HET MKB

Het nut ontstaat daar waar lange, gestructureerde documenten omgezet moeten worden in schone, doorzoekbare data. Een paar concrete plekken:

• Contracten en raamovereenkomsten. Kruisverwijzingen en bijlagen blijven in samenhang leesbaar, in plaats van uiteen te vallen bij blokgrenzen.
• Technische handleidingen en normen. Lange documenten met afbeeldingen, tabellen en genummerde secties in één doorgang.
• Meerpagina's facturen en bonnen. Schoon geëxtraheerde tekst is de voorfase voor gestructureerde verdere verwerking, bijvoorbeeld richting e-factuur.
• Archieven en dossiers. Bestanden die tot nu toe alleen als scan bestonden, worden machinaal leesbaar, zonder ze aan een clouddienst te geven.

In bijna alle gevallen is OCR niet het doel, maar de eerste stap. Schoon geparste tekst is de basis voor een kennisbank met RAG: hoe beter het parsen, hoe beter de zoekfunctie later de juiste plek vindt.

OCR OF VISUEEL DOCUMENTEN ZOEKEN?

Niet elke documenttaak heeft klassieke tekstherkenning nodig, en dat is een eerlijke afweging. Er bestaat inmiddels een hele tak die documenten helemaal niet eerst omzet in tekst, maar ze als beeld doorzoekt, met modellen zoals ColPali of ColQwen. Deze OCR-vrije aanpak hebben we apart beschreven.

De vuistregel die bij ons haar waarde heeft bewezen:

• U hebt de daadwerkelijke tekens nodig (factuurbedragen, contractclausules, gestructureerde extractie, doorgifte aan een ander systeem): dan is OCR nauwelijks te vermijden, en een model zoals Unlimited-OCR is hier sterk.
• U hebt de juiste plek nodig, niet de volledige tekst (een vraag over een groot bestand beantwoorden, een afbeelding terugvinden): dan kan visueel documenten zoeken de directere weg zijn.

Vaak is het beide naast elkaar. Unlimited-OCR maakt het OCR-deel van deze stack goedkoper en op lange documenten betrouwbaarder.

WAT IK ZOU CONTROLEREN VOOR PRODUCTIE

Een goede benchmarkscore is een reden om het model te testen, geen reden om het productief te zetten. Voordat ik Unlimited-OCR in een klantproces zou zetten, zou ik vier dingen controleren:

🔸 Duitse documenten en handschrift. De benchmarkcijfers zeggen weinig over Duitse formulieren, oude dossiers of handgeschreven aantekeningen. Dat hoort op een eigen testset van echte documenten.

🔸 Tabellen en layout. Bij B2B-documenten bepaalt de trouw van tabellen en kolommen het nut. Hier loont de directe vergelijking met de bestaande stack.

🔸 Hardware en beheer. 3B als MoE met circa 500M actieve parameters is on-premise realistisch. Wat dat concreet betekent aan GPU-geheugen en doorvoer, hoort voor de uitrol gemeten te worden, niet geschat.

🔸 Licentie en herkomst. MIT staat commercieel, on-premise gebruik zonder voetnoten toe. Dat het spoor van het model naar een van de DeepSeek-OCR-auteurs leidt, is een kwaliteitssignaal, maar vervangt niet de eigen controle.

Wat mij eigenlijk het meest interesseert aan deze release is minder het model zelf dan de richting: lange documenten in één doorgang, klein genoeg voor het eigen rekencentrum, onder een licentie die niemand beperkt. Precies daar wordt documentverwerking in het mkb nu praktisch. Welke van uw documenten zou u als eerste laten doorlopen?

VOORBIJ DE PROMPT

Prompt engineering stemt de vraag af. Context engineering vormt de omgeving waarin het model beslist. Voor een eenmalige taak volstaat een goede prompt. Voor een agent die over veel stappen loopt, tools uitleest en geheugen meedraagt, is de prompt slechts een klein deel van wat het model ziet. De rest, wat u ophaalt, wat u onthoudt, welke tools u hoe vrijgeeft, is context, en die bepaalt veel meer over het resultaat. Daarom is het uitbreiden van een agentische harness overwegend contextwerk.

DE VIER FAALPATRONEN WAARTEGEN MEN ONTWERPT

De meeste agentfouten zijn terug te voeren op een van vier contextproblemen:

• Contextoverbelasting. Te veel in het venster. Het model verliest de draad, en kosten en latentie stijgen. Meer context is niet betere context.
• Contextvergiftiging. Een onjuist of verouderd feit belandt in het venster, en het model behandelt het als waarheid. Eén enkel slecht opgehaald fragment kan een antwoord laten ontsporen.
• Tokenbeheer. Het venster is eindig. Zonder een plan voor wat te behouden en wat te verwerpen, wordt het belangrijke detail verdrongen door ruis.
• Verouderd geheugen. Langlopende agenten verzamelen context die niet meer geldig is, en handelen daarnaar.

Het falen benoemen is de halve oplossing. Elk heeft een concrete tegenzet.

PRAKTIJKEN DIE STANDHOUDEN

Een paar patronen keren terug in opzetten die betrouwbaar blijven:

1. Ophalen, niet afladen. Haal de enkele relevante passages op met goede retrieval, in plaats van alles erin te kopiëren. Dat is de hele zin van RAG, en het is context engineering toegepast op data.
2. Doorlopend snoeien. Pas regelgebaseerde bewerking toe in het raamwerk om het venster slank te houden: verwerp wat een stap niet meer nodig heeft.
3. Lange geschiedenissen samenvatten. Vervang een lang transcript door een getrouwe samenvatting voordat het de taak verdringt.
4. Eenvoudig beginnen, indien nodig opschalen. Voeg geheugen en tools alleen toe als een echt falen daarom vraagt, niet standaard.

Het instinct om meer toe te voegen is de valkuil. De discipline is het weglaten.

WAAROM DIT HET WERKELIJKE ENGINEERING IS

Een groter model lost een contextprobleem zelden op; het faalt alleen duurder. Het werk dat een agent van demo naar betrouwbaarheid brengt, is bijna uitsluitend contextwerk: wat hij ziet, wanneer, en wat hij moet vergeten. Bij zeer lange invoer telt ook de modelarchitectuur, en daar komen subkwadratische aanpakken in beeld, maar voor de meeste teams zit de winst in de context, niet in de parameters.

HET MECHANISME, EENVOUDIG

Eenvoudige RAG embedt uw query, vindt de dichtstbijzijnde passages en beantwoordt daaruit. RAG-fusion voegt daar twee stappen aan vooraf toe. Ten eerste schrijft een model een handvol alternatieve queries die hetzelfde bedoelen vanuit verschillende invalshoeken. Ten tweede haalt het voor alle resultaten op en voegt de gerangschikte lijsten samen via reciprocal rank fusion, die passages beloont die over meerdere queries heen goed scoren in plaats van slechts bij één. Het antwoord wordt vervolgens geschreven uit deze versmolten, opnieuw gerangschikte set.

WAAROM DE FUSIESTAP TELT

Eén enkele query is één enkele gok over hoe het antwoord in uw documenten geformuleerd is. Echte archieven gebruiken synoniemen, afkortingen en verschillende formuleringen voor hetzelfde onderwerp. Doordat RAG-fusion de vraag meerdere keren stelt en beloont wat consequent hoog scoort, brengt het de passage naar boven die één enkele formulering zou hebben gemist. Reciprocal rank fusion is hier het stille werkpaard: het combineert lijsten zonder vergelijkbare scores nodig te hebben, en daarom duikt het ook op in hybride en late-interaction-opzetten zoals die achter Qdrant en ColQwen.

WANNEER HET HELPT EN WANNEER HET SCHAADT

RAG-fusion verdient zijn kosten bij dubbelzinnige of terminologiezware vragen, waar één formulering een zwakke gok is. Het kost meer: meerdere retrievals en een generatiestap per vraag, dus het is geen gratis latency. En het heeft een echt faalpatroon. Wijken de gegenereerde queryvarianten af van wat u eigenlijk bedoelde, dan trekken ze off-topic passages binnen en drift het antwoord af. De remedie is om de gegenereerde queries nauw gebonden te houden aan de oorspronkelijke intentie en te meten, niet aan te nemen dat de recall gestegen is.

WAAR HET STAAT TUSSEN DE OPTIES

RAG-fusion is een van meerdere manieren om retrieval beter te maken, geen vervanging voor goede retrieval. Voordat u ernaar grijpt, zorg dat de basis klopt: schone chunks, een solide embeddingmodel en een vectorstore die bij de taak past. Voor visueel dichte documenten is de grotere hefboom vaak visuele retrieval in plaats van meer queryvarianten. Gebruik F-RAG waar de vraag werkelijk dubbelzinnig is en de recallwinst de extra aanroepen waard is.

HET PROBLEEM WAS NOOIT HET ANIMEREN, MAAR DE OVERDRACHT

Tot nu toe ontstond UI-beweging buiten Figma. De designer bouwde die in een tweede tool, exporteerde een video of een beschrijving, en de ontwikkeling moest de curves en timings nabouwen, vaak op het oog. Daarbij gaat precisie verloren: een easingcurve wordt een ruw idee, een timing een schatting. Precies deze breuk, niet het gebrek aan animatietools, heeft beweging in veel producten inconsistent gemaakt.

WAT FIGMA MOTION CONCREET BRENGT

Drie dingen veranderen de workflow merkbaar:

• Tijdlijn in de canvas. Keyframes, presets en bewegingsbesturing zitten daar waar het design al leeft. Geen overstap naar een tweede tool.
• Beweging als onderdeel van het designsysteem. Een component wordt eenmaal geanimeerd, en de beweging reist mee zoals kleur of typografie over elk scherm en elk bestand. Dat is het punt dat consistentie afdwingt in plaats van te hopen.
• Leesbare overdracht. In Dev Mode is de hele tijdlijn zichtbaar: elke timingwaarde, elke easingcurve, elke keyframe. De export gaat als CSS, JSON of framework-klaar React, plus MP4, WebM, geanimeerd SVG en GIF.

Daarmee leest de ontwikkeling de beweging, in plaats van hem te interpreteren. Dat is de eigenlijke verschuiving.

WAAR HET WRINGT

Een geïntegreerde tool is niet automatisch de juiste voor elk geval. Complex, narratief motionwerk, zoals een uitgebreide merkfilm, blijft een zaak voor gespecialiseerde tools. Figma Motion richt zich op interface-animatie: states, transities, micro-interacties, precies wat in het product dagelijks nodig is en tot nu toe leed onder de overdrachtsbreuk. Voor deze klasse van beweging is de integratie de winst. Voor alles daarboven blijft de toolkit gemengd.

VOOR WIE HET DE MOEITE WAARD IS OM TE KIJKEN

Wie een product met terugkerende UI-patronen onderhoudt, profiteert het meest: de eenmaal gedefinieerde beweging blijft consistent, en de implementatie krijgt exacte waarden in plaats van benaderingen. Beweging is daarbij geen decoratie, maar onderdeel van de begrijpelijkheid van een interface, een punt dat we nader uitwerken in de rol van UX in softwarebouw. Figma Motion maakt dit onderdeel eindelijk op één plek bewerkbaar.

DRIE LANCERINGEN, EENVOUDIG GEZEGD

Elk daarvan verscheen in juni 2026 binnen twee weken van de andere, en elk is een ander soort ding. Precisie loont hier, want twee ervan worden op grote schaal verkeerd omschreven.

GLM-5.2, van Z.ai in Peking, verscheen op 17 juni. Het is een open-weight mixture-of-experts-model, ongeveer 750 miljard parameters met circa 40 miljard actieve, een context van één miljoen tokens en, cruciaal, een MIT-licentie met gewichten die op HuggingFace zijn gepubliceerd.

Sakana Fugu, van Sakana AI in Tokio, verscheen op 22 juni. Het is geen gewoon model, en de gangbare indeling klopt niet: Fugu is een getrainde orchestrator die een pool van andere modellen aanroept en hun werk synthetiseert. Het is alleen via API beschikbaar, aangeboden als een OpenAI-compatibel eindpunt.

Claude Fable 5, van Anthropic in de Verenigde Staten, verscheen op 9 juni. De tweede veelgemaakte fout is Fable indelen als een snelle of creatieve variant. Het is het vlaggenschip, Anthropics meest capabele breed uitgebrachte model, met sturing op veiligheid, alleen in de cloud, tegen 10 en 50 dollar per miljoen tokens. De benchmarkcijfers zijn sterk; voor dit artikel zijn ze tegelijk bijzaak.

DE ENIGE VERGELIJKING DIE DE INKOOP OVERLEEFT

Laat de ranglijst achterwege en zet ze op de dimensies waarvoor een Duitse B2B-koper daadwerkelijk verantwoordelijk is. Het beeld is duidelijk, en het gaat niet om welke het slimst is.

Twee eerlijke voorbehouden horen bij deze tabel. De standaardroute van GLM-5.2, de Z.ai-API, valt onder China's datawetten met hun verplichte toegangsclausules, en dat is precies de reden waarom de open gewichten tellen: self-hosting in de EU neutraliseert dit risico. En Fugu's claim van frontier-gelijkwaardigheid is volledig zelf gerapporteerd, verzwakt door het feit dat Fable en het beperkte Mythos-model niet eens in de pool zitten. Ik zou geen beslissing baseren op een van beide aanbieder-benchmarks.

WAT IK EEN KLANT WERKELIJK ZEG

Ik beveel er geen enkele in het abstract aan. Ik pas het standpunt aan op wat de klant kan financieren en waarvoor hij verantwoordelijk is.

🔸 GLM-5.2 is het on-premise-spoor. De open MIT-gewichten zijn het hele punt: u kunt het in uw eigen datacenter draaien, en de prompts verlaten uw netwerk nooit. De adder onder het gras is de GPU-voetafdruk, ongeveer 744 gigabyte in FP8, dus het past bij de klant die de hardware kan financieren en data in huis moet houden. Het is het schoonste soevereiniteitsverhaal van de drie.

🔸 Claude Fable 5 is het spoor voor beheerde zekerheid. U huurt capaciteit van een Amerikaanse aanbieder, hier tegen de hoogste prijs, met echte veiligheidssturing en regionale datarouting bij de grote clouds. Voor een team dat een topmodel wil zonder de stack te bezitten, en dat met een cloudafhankelijkheid kan leven, is het de sterkste beheerde optie.

🔸 Sakana Fugu is het gemakspoor, met het zwakste controleverhaal. Een API die via een pool van modellen routeert is slim, en Japan is geopolitiek zachter dan China. Maar u kunt het niet on-premise draaien, u kiest niet welk model de data ziet, en de bewijzen zijn dun. Ik zou het als interessant behandelen, niet als standaard voor gereguleerd werk.

Dat is dezelfde les die Claude Fable 5 op de harde manier leerde, toen een eerder model binnen 72 uur werd uitgeschakeld: gehuurde capaciteit is herroepbaar, en controle is een eigenschap van de stack, niet van de score. Daarom wijs ik klanten steeds weer op open-weight-modellen die ze daadwerkelijk kunnen bezitten.

DE VRAAG WAAR HET DE MOEITE WAARD IS OM VOOR TE ONTWERPEN

Als u hier één ding uit meeneemt, laat het dan de vraag zijn, niet de rangorde. De modellen wisselen binnen een kwartaal weer van plaats op de ranglijst; dat is ruis. De houdbare vraag is degene die een inkoopverantwoordelijke op dag één zou moeten stellen: welk van deze kunt u nog draaien, controleren en betalen als de aanbieder de voorwaarden wijzigt? Voor de meeste gereguleerde klanten met wie ik werk, beantwoordt deze vraag zich vanzelf, en ze wijst niet naar de hoogste benchmark. Voordat u dus het slimste model kiest: wat zou het u kosten om het te verliezen?

WAT GEMINI OMNI WERKELIJK IS

Noem eerst de naam correct, want de marketing vertroebelt hem. De familie is Gemini Omni en het eerste model is Gemini Omni Flash. Het neemt tekst, beeld, audio en video als invoer, en bij de lancering genereert het één soort uitvoer: video, in clips van ongeveer 10 seconden met native gesynchroniseerd geluid. Google omschrijft het als een stap richting een wereldmodel, dat wil zeggen dat het probeert fysica, zwaartekracht en ruimtelijke coherentie consistent te houden over een gegenereerde scène, en het draait op Googles TPU's van de 8e generatie, opgesplitst in trainings- en inferentievarianten.

Een eerlijke correctie telt voor een technische lezer: Omni wordt vermarkt als any-to-any, maar zoals het is uitgeleverd, is het elke-invoer-naar-video. Beeld- en audio-uitvoer staan op de roadmap, niet in het product. Het is dus geen realtime conversatie-omni-assistent, en het is nog niet het universele any-to-any-systeem dat de naam suggereert. Het is een zeer capabele, invoerflexibele videogenerator, wat een nauwer en bruikbaarder ding is om op te plannen.

AANGEKONDIGD, UITGELEVERD EN BESCHIKBAAR ZIJN DRIE VERSCHILLENDE DINGEN

Het nuttigste onderscheid voor een koper is dat deze drie toestanden niet hetzelfde zijn, en Omni bevindt zich, afhankelijk van wie u bent, in verschillende ervan. Het is uitgeleverd aan consumenten en creatieven, en voor iedereen die op een API wil bouwen, is het slechts aangekondigd.

De praktische lezing voor een EU-bedrijf is direct. Als u vandaag AVG-conforme EU-residentie voor videogeneratie nodig heeft, kan Omni die u niet bieden, omdat de enterprise-route nog niet bestaat. De ondersteunde optie op Googles eigen stack blijft Veo 3.1 op Vertex AI, dat u op een EU-regio kunt vastzetten. Dat is hetzelfde patroon dat we steeds weer zien bij nieuwe modellanceringen, waarbij de demo en het inzetbare product maanden uit elkaar liggen.

WAT EEN DUITS BEDRIJF NU ZOU MOETEN DOEN

Behandel Omni als een signaal om te volgen, niet als een tool om dit kwartaal in te voeren. Drie concrete stappen.

• Gebruik vandaag Veo 3.1, regiogebonden, voor productievideo. Het heeft een echte Vertex-API, EU-regio's en een SLA. Omni heeft daar tot dusver niets van, dus hoort het nu niet in een productiepijplijn.
• Plan het herkomstverhaal vroeg. Omni voegt een SynthID-watermerk toe aan elke clip. Bouw voor gereguleerde of publieke content de verwachting in uw proces in dat AI-gegenereerde video gemarkeerd en herleidbaar is, ongeacht welk model wint.
• Houd twee risico's in de gaten, niet alleen de capaciteit. Beoordelaars hebben herkenbaar merkrechtelijk beschermde figuren gereproduceerd in Omni-uitvoer, wat een echt intellectueel-eigendomsrisico is voor commercieel gebruik, en de visuele consistentie vertoont bij snelle beweging nog steeds drift. De grens van 10 seconden is een UX-grens, geen modelplafond, verwacht dus dat die verschuift.

Het houdbare punt is het punt dat de lancering terloops maakt: een model dat u in een keynote kunt zien, is geen model dat u contractueel kunt inzetten. Scheid de twee, en de hype wordt een roadmap-punt in plaats van een inkoopfout.

WAT 2025 EN 2026 WERKELIJK BRACHTEN

Het grote nieuws is stabiliteit na jaren van omwentelingen. LangChain 1.0 en LangGraph 1.0 bereikten beide op 22 oktober 2025 de stabiele release, met de toezegging om tot 2.0 geen breaking changes door te voeren. De nieuwe centrale abstractie van het framework, create_agent, draait nu daaronder op de LangGraph-runtime, de agentenlus is dus een LangGraph-graaf. Dat is het duidelijkste signaal van de versmelting: het framework en de orchestratie-runtime zijn geen gescheiden beslissingen meer.

LangGraph 1.0 bracht durable execution als ingebouwde functie: de status wordt automatisch als checkpoint opgeslagen, zodat een langlopende of human-in-the-loop-workflow na een onderbreking of een herstart van de server verdergaat. LangSmith, de observability- en evaluatielaag, voegde in maart 2026 volledige OpenTelemetry-ondersteuning toe, wat betekent dat u ook traces kunt versturen vanuit code die LangChain helemaal niet gebruikt. Het commerciële beeld paste bij het technische: LangChain Inc haalde in oktober 2025 een Series B van 125 miljoen dollar op bij een waardering van 1,25 miljard en hernoemde LangGraph Platform naar LangSmith Deployment, waardoor deployment, observability en evaluatie in één product werden samengevoegd.

VIER NAMEN, TWEE BEDRIJVEN

Uitzoeken wie wat doet is het nuttigst voordat u kiest. De meeste weergaven maken het vaag; het goed te doen verandert de beslissing.

LangFlow is waar mensen over struikelen. Het is geen product van LangChain Inc. Het is een opensource visuele bouwset, gemaakt door DataStax, waarvan de moedermaatschappij in februari 2025 door IBM werd overgenomen, en die nu richting IBMs watsonx wijst. Het rijm in de naam is toeval. Als uw behoefte een drag-and-drop-canvas is voor mensen die geen Python schrijven, is LangFlow de kandidaat; het is geen laag van de LangChain-stack.

DE BESLISSING WAAR DE MEESTE TEAMS WERKELIJK VOOR STAAN

Zodra de namen duidelijk zijn, is de keuze meestal een korte beslisboom, en hebt u zelden alle vier nodig.

• Hebt u langdurige orchestratie nodig? LangGraph is het sterkste onderdeel en degene die zelfs critici respecteren. Hervatbare status, checkpointing en human-in-the-loop zijn echt engineering, geen wrapper.
• Hebt u observability en evaluatie nodig? LangSmith is capabel, maar koppelt u aan het ecosysteem. Langfuse is de opensource, zelf te hosten tegenhanger en het meest genoemde alternatief. Omdat LangSmith nu OpenTelemetry spreekt, kunt u ook vanuit niet-LangChain-code tracen, wat de lock-in verzacht.
• Bouwt u een ongecompliceerde agent? De SDK's van de aanbieders (het OpenAI Agents SDK, het Claude Agent SDK) en Pydantic AI zijn geloofwaardige, lichtere alternatieven. Het meest gehoorde bezwaar van praktijkmensen zijn de abstractielagen in het framework, en meerdere teams melden dat ze code en onderhoud hebben verminderd door over te stappen op een slankere stack.
• Niet-ontwikkelaars die prototypen? LangFlow, met de kanttekening dat een canvas-prototype voor de oplevering dezelfde governance en evaluatie nodig heeft.

Dat is dezelfde les die wij trokken bij de vergelijking hoe u AI via een API, een MCP-server of een CLI in een stack bedraadt: de tools zijn lagen, en u kiest op basis van de taak, niet van de nieuwigheid. Het rijmt ook met wat wij vonden bij het bekijken van no-code agentbouwers voor het mkb, waar het canvas snel tot een demo leidt en precies bij governance, betrouwbaarheid en kosten stopt.

STABIEL BETEKENDE NIET GEHARD

Eén kanttekening telt voor een zakelijk publiek: 1.0 kocht API-stabiliteit, geen geharde beveiligingshouding. Een cluster van CVE's trof LangChain en LangGraph eind 2025 en begin 2026, aangevoerd door een deserialisatiefout die API-sleutels en omgevingsgeheimen kon lekken, beoordeeld met CVSS 9.3 en LangGrinch genoemd. Twee andere volgden: een path-traversal-probleem in de prompt-laad-API en een SQL-injectie in de LangGraph-SQLite-checkpointer.

De praktische lezing is niet om het framework te mijden. Het is om het te behandelen als elke andere afhankelijkheid die uw geheimen en uw data raakt: versies vastzetten, de gepatchte releases installeren en het opnemen in uw dreigingsmodel. Een framework dat tool-aanroepen orchestreert en toegangsgegevens bewaart, is onderdeel van uw aanvalsoppervlak, en "stabiel" op basis van het versienummer zegt daar weinig over. Voor een gereguleerde of on-premise inzet hoort deze toetsing in hetzelfde gesprek als de dataresidentie, niet na de go-live.

HET PROBLEEM MET DE ENE VECTOR

Klassieke vectorzoekopdrachten persen een hele tekstalinea of een hele pagina in één enkele vector. Dat is zuinig, maar het middelt weg wat lokaal belangrijk is. Staat het gezochte bedrag in een specifieke tabelcel, dan verdwijnt dat verband in het gemiddelde van de hele pagina. Voor nette lopende tekst is dat vaak voldoende. Voor de documenten waarvoor visuele zoekopdrachten eigenlijk zijn bedoeld, is het niet voldoende.

LATE INTERACTION, IN ÉÉN ZIN

Late interaction houdt meerdere vectoren per pagina aan en vergelijkt ze pas laat, namelijk bij het zoeken. Het model genereert voor de zoekopdracht een vector per token en voor de pagina een vector per fragment. De score heet MaxSim: voor elke zoektoken wordt het best passende paginafragment gezocht, en deze beste overeenkomsten worden opgeteld. Zo kan het woord "restbedrag" gericht aankoppelen bij de tabelcel waarin het staat. De techniek komt uit ColBERT en werd met ColPali overgebracht naar beelden. Wie de hele toolkit wil zien: de OCR-vrije stack plaatst de modellen in context.

WAAR QDRANT IN BEELD KOMT

Late interaction heeft een database nodig die meerdere vectoren per object begrijpt. Qdrant ondersteunt dergelijke multi-vectoren direct, zonder voor- of nabewerking, en kan elk late-interactionmodel zoals ColBERT of ColPali dragen (documentatie). De gebruikelijke opzet is tweetraps: een snelle eerste zoekopdracht met normale dense vectoren beperkt de kandidaten, waarna MaxSim alleen die paar pagina's nauwkeurig herbeoordeelt. Zo blijft de index betaalbaar, want de dure tokenvectoren hoeven niet volledig geïndexeerd te worden, maar dienen voor de re-ranking.

WAT DIT PRAKTISCH BETEKENT

U krijgt resultaten die de lay-out respecteren, zonder de zoekopdracht onbetaalbaar te maken. De prijs is meer opslag per pagina en iets meer complexiteit bij de opbouw. Beide zijn beheersbaar als u de re-rankingfase vanaf het begin inplant in plaats van elke tokenvector volledig te indexeren. Voor zeer lange contexten loont het de moeite om te kijken naar subkwadratische modellen; voor het basisidee van retrieval blijft Wat is RAG het beginpunt.

WAAROM GROOTTE HIER EEN OBSTAKEL WORDT

Visuele retrievalmodellen zoals ColPali of ColQwen zijn trefzeker, maar ze zijn ook groot. On-prem, dus op eigen hardware in huis, wordt dat al snel een kostenkwestie: grote modellen vragen om krachtige GPU's, meer geheugen, meer stroom. Voor veel mkb-opzetten is niet de kwaliteit de horde, maar de hardwarerekening. Precies hier zet een kleiner model de hefboom aan.

WAT MODERNVBERT ANDERS DOET

ModernVBERT is een compacte vision-language-encoder met 250M parameters (paper). Hij combineert een moderne 150M-tekstencoder op ModernBERT-basis met een kleine beeldencoder en lijnt beide op elkaar af via een masked-language-modelingdoel. ColModernVBERT is de voor retrieval fijn afgestemde variant. Het resultaat volgens de paper: ondanks ongeveer tien keer minder parameters ligt het slechts 0,6 nDCG@5 onder ColPali op de geaggregeerde ViDoRe-benchmark, en behaalt daarmee waarden waarvoor anders bijna tien keer grotere modellen nodig waren. Model en code zijn openbaar beschikbaar.

WAAROM DIT TELT VOOR SOEVEREINITEIT

Een klein, open, sterk model is precies de combinatie die lokale werking mogelijk maakt. Het past op een bescheiden GPU, de gewichten liggen open, en de documenten blijven in huis omdat de zoekopdracht niet naar een extern eindpunt gaat. Dat is geen achteraf toegevoegde beveiligingsfunctie, maar een eigenschap van de architectuur. Het grotere verband, waarom lokaal en open bij elkaar horen, behandelen we in On-Premise tegen Cloud.

WANNEER HET KLEINE MODEL DE JUISTE KEUZE IS

Niet altijd is het grootste model nodig. Als uw hardware beperkt is en uw documenten typische zakelijke documenten zijn, is ColModernVBERT vaak de eerlijkere keuze dan ColQwen: bijna dezelfde kwaliteit, een fractie van de kosten. Hebt u dat laatste beetje trefzekerheid nodig op bijzonder dichte pagina's, dan loont de vergelijking met het grotere model. Hoe beide samenwerken in de volledige stack met Qdrant, staat in het overzicht.

Wat n8n sterk maakt

n8n is node-gebaseerde workflowautomatisering, self-hosted of als cloud, met meer dan 400 integraties plus een HTTP-node en code-node voor al het overige (n8n). Het beslissende punt voor gereguleerde sectoren: het draait in eigen huis, de gegevens verlaten de infrastructuur niet. De fair-code-licentie staat intern gebruik zonder vergoeding toe. Wie eigen logica, eigen endpoints en volledige gegevenscontrole nodig heeft, zit hier goed. De prijs daarvoor is beheer: u host, update en beveiligt zelf.

Wat Make.com sterk maakt

Make.com is een clouddienst met visuele scenario's die zonder eigen beheer werkt. U klikt een workflow bij elkaar en die draait, zonder server, zonder onderhoud. Voor teams zonder technische diepgang of voor een snel idee is dat de kortere weg. Er wordt afgerekend per operatie, dus per uitgevoerde stap. Dat is voordelig bij kleine volumes en kan bij grote, veelvoorkomende workflows onaangenaam oplopen. De keerzijde van het gemak: de gegevens lopen via een externe dienst, en de logica blijft binnen diens grenzen.

De beslissing in een tabel

De scheidslijn is duidelijk: gegevenscontrole en diepgang tegenover snelheid zonder eigen beheer.

Ons pragmatische advies

Prototype snel, host bewust. Voor een eerste test die alleen moet aantonen of een workflow werkt, is Make.com vaak sneller. Zodra gevoelige gegevens, grote volumes of eigen logica in beeld komen, wint n8n, omdat het in huis draait. En waar automatisering grenst aan echte AI-taken, loont een blik op no-code-agenten en hun grenzen: automatisering en agent zijn niet hetzelfde gereedschap.

Waarom OCR het wankele onderdeel van de pipeline was

OCR was lang het punt waarop stille fouten het antwoord binnenslopen. De klassieke weg is een keten: pagina scannen, via OCR omzetten naar tekst, in stukken knippen, embedden, ophalen. Elke stap verliest iets. Een pagina met twee kolommen wordt verkeerd samengevoegd, een tabel valt uiteen in losse cijfers, een diagram valt volledig weg omdat het geen tekst is. Naar onze ervaring zit bij lastige documenten het grootste deel van het kwaliteitsprobleem niet in het taalmodel, maar hier, in het lezen. Visueel retrieval grijpt precies op deze stap in: het slaat tekstherkenning bij het zoeken over en werkt op het beeld van de pagina.

De vier bouwstenen, kort uitgelegd

ColPali. De referentie, voorgesteld in juli 2024 (arXiv). Het bouwt voort op het vision-taalmodel PaliGemma en genereert ongeveer 1024 beelduitsnede-vectoren per pagina, elk 128-dimensionaal. In plaats van de pagina in een enkele vector te persen, blijft de granulariteit behouden. De matching gebeurt via Late Interaction, een techniek overgenomen van ColBERT, die we hier verder uitsplitsen.

ColQwen. Hetzelfde recept, andere basis: ColQwen2.5 zet in op Qwen2.5-VL in plaats van PaliGemma en staat op de ViDoRe-benchmark meestal vooraan. Wie vandaag opnieuw begint, begint hier zinvol.

ModernVBERT. De efficiëntiehefboom. ColModernVBERT heeft 250M parameters, dus ongeveer tien keer minder dan ColPali, en ligt volgens het paper toch maar 0,6 nDCG@5 daaronder. Dit is de bouwsteen die visueel retrieval on-premise betaalbaar maakt.

Qdrant. De infrastructuur eronder. Qdrant slaat de multi-vectoren van deze modellen native op en berekent de late-interaction-score bij het zoeken (documentatie). Zonder een vectordatabase die meerdere vectoren per pagina begrijpt, draait geen van de drie encoders.

Wanneer de overstap loont, en wanneer niet

Visueel retrieval wint daar waar de layout de informatie draagt. Gescande contracten, facturen, datasheets, presentaties, formulieren, meertalige dossiers: alles waarop een OCR-keten regelmatig faalt. Het bespaart bovendien het volledige onderhoud van die keten.

Het is echter geen automatische winst. Meerdere vectoren per pagina kosten meer opslag en meer index dan een enkele tekstvector, vaak een veelvoud. Bij schone, pure lopende tekst blijft klassiek tekst-RAG goedkoper en volledig toereikend. En sommige taken hebben uiteindelijk toch tekst nodig, zoals volledige tekstzoekopdrachten, kopiëren of een controlespoor. Daarvoor zijn er nog steeds goede redenen voor OCR, hybride naast visueel retrieval.

Een nuchtere routekaart

1. Test met uw eigen documenten, niet met de benchmark. ViDoRe is een goed aanknopingspunt, maar uw dossiers zijn dat niet. Neem de twintig pagina's waarop uw huidige zoekfunctie faalt.
2. Start met ColQwen of ColModernVBERT, afhankelijk van de hardware. Op een krappe GPU is het kleine model vaak het eerlijkere.
3. Zet Qdrant op als multi-vectoropslag, late interaction alleen in de re-ranking-fase, om de index klein te houden.
4. Reken de opslagprijs vooraf door. De indexgrootte is de plek die later pijn doet, niet de modelkeuze.

Wie de grotere boog zoekt, dus waarom lokale modellen en eigen retrieval eigenlijk bij elkaar horen: dat staat in On-premise versus cloud. De afzonderlijke bouwstenen verdiepen we in eigen teksten, beginnend bij de mkb-blik.

De kloof tussen een mesh en een onderdeel

Een gegenereerd mesh en een fabricagegeschikt onderdeel zijn verschillende objecten, en de kloof is niet cosmetisch. Drie randvoorwaarden maken dat duidelijk. Ten eerste heeft printen een waterdicht, manifold solid nodig (geen gaten, geen omgeklapte normalen, geen zelfdoorsnijdingen), en generatieve meshes overtreden dat regelmatig; een slicer kan van een oppervlak met gaten geen deel maken. Ten tweede is een mesh een statische soep van driehoeken, terwijl de fabricage een parametrisch B-Rep-model wil (een STEP-bestand met schetsen, features en beperkingen) dat een ingenieur kan bewerken en een CAM-systeem kan verwerken. Geen van de beeld-naar-mesh-tools genereert dat.

Ten derde, en het meest fundamenteel, draagt een enkele afbeelding geen metrische schaal. Het model wijst een geraden camerapositie toe en genereert een vorm zonder gegarandeerde millimeters, zonder afgedwongen wanddikte, zonder toleranties. En omdat een foto slechts één kant ziet, wordt de verborgen kant niet gereconstrueerd, maar verzonnen: het model vult de ongeziene geometrie met een plausibel gemiddelde. Een game-asset kan dat allemaal achter een mooie textuur verbergen. Een onderdeel kan dat niet, omdat het de printer en de belasting niet uitmaakt hoe het eruitziet.

Twee pipelines die de hype door elkaar haalt

Het duidelijkst plant u door twee pipelines te scheiden die de marketing laat samenvloeien. Ze dienen verschillende onderdelen en vereisen verschillende gereedschappen.

De eerste pipeline is vandaag reëel voor onderdelen waarbij de pasvorm soepel is. De AI schetst de vorm ruwweg; een mens blijft verantwoordelijk voor het waterdicht maken, het schalen naar echte afmetingen en het uitvoeren van een printbaarheidscontrole. De tweede is de plek waar het fabricagerelevante front zich bevindt: beeld-naar-CAD-onderzoek zoals CAD-Recode en Img2CAD genereert bewerkbare parametrische geometrie, en commerciële tools zoals Zoo kunnen een echt STEP-bestand exporteren, maar ze blijven vooralsnog grotendeels beperkt tot eenvoudigere onderdelen. Voor veeleisende geometrie blijft klassiek scan-gebaseerd reverse engineering (Geomagic, PolyWorks) de betrouwbare weg. Dat is de fabricageneef van de vraag die wij stelden bij Single-Image-reconstructie van de mens: een plausibel oppervlak is niet hetzelfde als een betrouwbaar solid.

Wat voor een mkb-maker vandaag reëel is

Tegenover de hype gesteld zijn de echte winsten stiller en waardevoller dan het one-shot-onderdeel uit een smartphonefoto. De sterkste reële hefboom is de digitalisering van wat u al heeft: tools zoals Theia van Spare Parts 3D en de tekeninganalyse van 3YOURMIND zetten oude technische 2D-tekeningen om in printbare reserveonderdeelmodellen, gemeld tot 200 keer sneller dan handmatig hertekenen, met een bijgevoegde maakbaarheidscontrole. Dat is beeld-naar-3D waarbij de invoer een technische tekening is, geen vakantiekiekje, en de geometrie verankerd is in echte afmetingen.

De andere solide winsten zijn de versnelling van reverse engineering, waarbij AI-generatie en intelligente retopologie een bestaande scan-gebaseerde workflow versnellen in plaats van vervangen, en rapid prototyping voor niet-kritieke onderdelen. Waar het faalt, is precies daar waar de inzet het hoogst is: lastdragende, strak tolerante en gereguleerde onderdelen die schaal, materiaalspecificatie en traceerbaarheid nodig hebben die een enkele afbeelding niet kan leveren. De vuistregel is kort. Voor een onderdeel dat gewicht draagt of een test moet doorstaan, is de onzichtbare kant altijd een gok, en een gok is een defect.

Begin op de bodem, niet aan het plafond

Voordat u een slimme methode toepast, brengt u de basis op orde, want die verhelpt de meeste klachten. De productiestandaard van 2026 is hybride zoeken (dense embeddings plus keyword-BM25), gevolgd door een cross-encoder-reranker. Hybride zoeken vangt zowel semantische als exacte termtreffers op; de reranker beoordeelt een grote kandidatenset terug tot de paar passages die daadwerkelijk relevant zijn, niet slechts thematisch verwant. Praktijkgidsen melden dat deze combinatie de retrievalkwaliteit op standaard-evaluatiesets met 15 tot 30 procent verhoogt.

Dat telt, omdat de meeste reele fouten van het eenvoudige soort zijn: het antwoord stond in de documenten, maar het systeem bracht het niet naar boven. Dat is een recall- en rankingprobleem, en de bovenstaande basis verhelpt het. Bewijs dat u meer nodig heeft voordat u meer bouwt. Elke techniek voorbij dit punt voegt LLM-aanroepen, latentie en kosten toe; elk moet zijn plaats verdienen tegenover een gemeten falen, niet tegenover een onderbuikgevoel.

De gereedschapskist, geïndexeerd op het falen dat hij verhelpt

De nuttige manier om de hele dierentuin aan methoden te behouden, is elke af te beelden op het specifieke faalpatroon dat ze adresseert. Grijp naar een methode wanneer u het falen ervan ziet, niet eerder.

Elke regel heeft echte herkomst: HyDE komt uit een CMU-paper uit 2022 over zero-shot dense retrieval; step-back-prompting van Google DeepMind, 2023; GraphRAG van Microsoft, 2024. Dat is dezelfde beslis-na-falen-discipline achter onze blik op RAG-fusion en hoe het verschilt van eenvoudige RAG.

Query-decompositie, in het bijzonder

Query-decompositie splitst een complexe aanvraag in onafhankelijke deelvragen, haalt voor elk op en synthetiseert vervolgens een antwoord. Het is het juiste gereedschap wanneer een enkele retrievalronde niet kan werken, omdat de feiten in verschillende documenten leven of een feit van een ander afhangt (wie de film regisseerde die een bepaalde prijs won). De lijn loopt van least-to-most-prompting in 2022 naar de deelvraag-query-engines van de huidige frameworks.

Het eerlijke deel is dat het niet gratis is en schade kan aanrichten. Een studie van de HU Berlin uit juli 2025 mat dat decompositie plus reranking de multi-hop-recall (Hits@10) van 74,7 naar 87,2 procent tilde, een echte winst. Dezelfde studie mat de kosten: ongeveer 16,7 seconden per aanvraag tegenover 0,03 seconden voor naieve retrieval, en ontdekte dat het decomponeren van een reeds specifieke aanvraag ruis introduceert en het antwoord slechter maakt. Decompositie hoort dus bij echte multi-hop-vragen, niet standaard bij elke aanvraag. De kunst is die twee uit elkaar te houden.

De hefboom die zichzelf terugbetaalt is routing

Als u hier een operationeel inzicht uit meeneemt, maak er dan routing van. Classificeer de aanvraag eerst, en geef complexiteit alleen uit waar ze verdiend is. Een analyse uit 2026 over kostenbewust routing verlaagde afgerekende tokens met 26 procent en de mediane latentie met 34 procent bij gelijke antwoordkwaliteit, door slechts ongeveer 18 procent van de aanvragen naar zware retrieval en 14 procent naar helemaal geen retrieval te sturen. De dure methoden bleven voorbehouden aan de aanvragen die ze nodig hadden.

Voor een Duits mkb-team is dat evenzeer een governance- en kostenverhaal als een kwaliteitsverhaal. Minder, gerechtvaardigde LLM-aanroepen betekenen voorspelbare uitgaven, lagere latentie en een systeem dat u aan een compliance-gerichte stakeholder kunt uitleggen: hier is waarom deze aanvraag de dure weg nam, en hier is waarom die andere dat niet deed. Overengineerde retrieval is niet alleen traag, het is onverklaarbare uitvoer. Het verfijnde RAG-systeem van 2026 is dat wat weet wanneer het geen van zijn trucs gebruikt.

Het werkelijke verschil, in telkens één zin

Prompt engineering is een instructie goed formuleren. Context engineering is beslissen wat het model eigenlijk te zien krijgt. De term werd in juni 2025 gepopulariseerd door Shopify's Tobi Lutke en versterkt door Andrej Karpathy, die hem omschreef als de kunst om het contextvenster te vullen met precies de juiste informatie voor de volgende stap. Het scherpste onderscheid komt van Philipp Schmid: context is alles wat het model ziet voordat het een antwoord genereert, en dat is een systeem, geen tekenreeks.

De twee zijn geen rivalen; prompt engineering is een deelverzameling. Wanneer u een goede systeemprompt schrijft, is dat prompt engineering. Wanneer u beslist welke drie documenten worden opgehaald, welke tools u vrijgeeft, hoeveel geschiedenis u behoudt, wat u weglaat en welk uitvoerschema u vereist, allemaal binnen een tokenbudget, is dat context engineering. Anthropics eigen richtlijn omschrijft dit als het beheren van de volledige contexttoestand over beurten heen, en de scherpste zin daarin is er een om te onthouden: context is een eindige bron met afnemend grensnut.

Waarom het veld verschoof, en het was geen trend

De reden waarom context engineering een benoemde discipline werd, is dat de gemakkelijke aanname onder meting instortte. De aanname was dat modellen met een lange context het venster laten volstoppen en gewoon ophouden na te denken. Chroma's context-rotstudie testte in juli 2025 18 frontier-modellen en ontdekte dat elk model degradeert naarmate de invoer groeit, vaak op een inconsistente manier: het model behandelt het tienduizendste token niet zo betrouwbaar als het honderdste. De oudere lost-in-the-middle-bevinding wees in dezelfde richting.

Twee krachten maakten de lading, niet de prompt, tot het ding dat geengineerd moet worden. Ten eerste: agenten, tool-gebruik, retrieval en geheugen betekenen dat de context over veel beurten door een systeem wordt samengesteld, niet eenmalig met de hand geschreven. Ten tweede de economie: in productie bij Manus ligt de verhouding van invoer- tot uitvoertokens rond 100 tot 1, en het hergebruik van de key-value-cache stuurt een groot kostenverschil aan. Wat in het venster terechtkomt, is dus net zozeer een kostenbeslissing als een kwaliteitsbeslissing. Meer context is niet beter; gebudgetteerde, relevante context is dat wel. Dat is de empirische ruggengraat onder onze eerdere bespreking van context engineering en waarom het telt.

Waaruit context engineering werkelijk bestaat

Bevrijd van het etiket is context engineering een verzameling toetsbare praktijken, geen prompt-fluisteren. De benoemde technieken keren terug bij Anthropic, LangChain en het Manus-productierapport:

• Retrieval. Haal de paar relevante documenten op op het moment dat ze nodig zijn, in plaats van alles erin te kopieren. Dat is de discipline achter Retrieval-Augmented Generation.
• Verdichting en samenvatting. Comprimeer oude beurten tot een lopende samenvatting, zodat het budget wordt besteed aan wat leeft, niet aan het transcript.
• Geheugen en notities. Sla toestand op in externe notities of bestanden die de agent kan teruglezen, in plaats van hem in het venster mee te dragen.
• Toolcuratie. Houd drie tot vijf kerntools geladen en haal de rest precies op tijd erbij. Elke geladen tool verdunt het signaal en breekt de cache.
• Gestructureerde uitvoer. Vereis een schema, zodat het model tokens uitgeeft aan het antwoord, niet aan opmaakproza.
• Isolatie. Verdeel werk over subagenten, zodat elk alleen de context ziet die hij nodig heeft.

LangChain omschrijft dezelfde verzameling als schrijven, selecteren, comprimeren en isoleren. Het punt is dat elk daarvan meetbaar is: u kunt een retriever, een verdichtingsdrempel of een tooluitrusting A/B-testen, en precies dat maakt dit tot engineering in plaats van formulering.

Is het alleen een rebranding? Het eerlijke antwoord

Deels, en dat is prima. Ja, goede ingenieurs curateerden al wat het model ziet; de waarde van de naam is dat hij de optimalisatie richt op de lading en het systeem, niet op de zin, waar betrouwbaarheid en kosten daadwerkelijk zitten. Het lopende debat is nuttiger dan de terminologiestrijd. In juni 2025 pleitte Cognition tegen multi-agentsystemen, met als argument dat het moeilijk is om context netjes tussen agenten te delen, en beval aan werk enkelvoudig te houden en volledige traces te delen. In dezelfde week beschreef Anthropic een multi-agent-onderzoekssysteem dat afhankelijk is van gedisciplineerde contextisolatie. Dezelfde discipline, tegengestelde architecturale conclusie.

Voor een team dat met LLM's bouwt, zijn de lessen eenvoudig. Budgetteer tokens zoals u rekenkracht budgetteert, want meer is niet gratis en niet altijd beter. Behandel het werk als bedrading (retrievalkwaliteit, verdichting, geheugen, toolcuratie, gestructureerde uitvoer), niet als formulering. En kies uw architectuur op basis van hoe betrouwbaar u context kunt delen, niet op basis van welke aanpak geavanceerder klinkt. De naam zal blijven muteren, sommigen noemen de volgende laag al harness engineering, maar het object is stabiel: het systeem dat beslist wat het model te zien krijgt.

Wat SAM 3D Body werkelijk doet

SAM 3D Body reconstrueert een volledig lichaamsmesh, inclusief handen en voeten, uit één enkele afbeelding en schat zowel pose als vorm. Het introduceert een nieuw parametrisch lichaamsformaat, de Momentum Human Rig (MHR), die het skelet loskoppelt van het weke-delenoppervlak, zodat rig en lichaamsvorm afzonderlijk kunnen worden bekeken. Zoals de rest van de Segment-Anything-familie is het promptbaar: u kunt 2D-keypoints of segmentatiemaskers meegeven om het resultaat te sturen.

De praktische details tellen voor iedereen die het wil inzetten. Meta leverde open gewichten in twee backbones, een DINOv3-H+ met circa 840M parameters en een ViT-H met circa 631M, plus inferentiecode, trainingsdata en het MHR-model. Het meldt een 3DPW-meshfout (MPJPE) van 54,8 en drijft al een live consumentenfunctie aan, Facebook Marketplace's View in Room. Het is getraind op circa 8 miljoen afbeeldingen. Dit is geen onderzoeksdemo; het ging op dag één een product in.

De B2B-winst zit in de pipeline, niet in de pixels

Het strategische punt voor een Duits of EU-bedrijf is waar de berekening plaatsvindt, niet hoe knap de mesh eruitziet. Een menselijke lichaamsafbeelding is onder de AVG een gevoelig persoonsgegeven. Op het moment dat u de foto van een klant naar een externe reconstructie-API stuurt, heeft u een verwerkersovereenkomst, een doorgiftevraagstuk en een vertrouwensprijs. Open gewichten halen die stap weg: u draait het model in uw eigen netwerk, en de lichaamsafbeelding verlaat dat nooit.

Dat verandert meerdere toepassingen van ongemakkelijk naar bezitbaar. Virtual try-on en pasvormvisualisatie, AR- en VR-avatars, fitness- en bewegingsanalyse, en previs voor animatie of virtuele productie kunnen allemaal draaien op infrastructuur die u beheert, met dezelfde UX die een gehoste API zou bieden. Dat is dezelfde eigen-pipelinelogica die we toepasten op het genereren van 3D-assets uit één enkele afbeelding met TRELLIS: de waarde is niet alleen het model, het is de gevoelige input aan uw kant van de muur houden. De licentie is het ene dat u voor het bouwen moet controleren: de MHR-rig is bevestigd als permissief-commercieel, en de lichaamsgewichten verschijnen onder de SAM-licentie, lees dus de daadwerkelijke voorwaarden voor uw inzet.

Waar het stilletjes breekt

De toepassing correct afbakenen is de hele kunst, want single-image reconstructie heeft eerlijke grenzen die geen modelkwaliteit wegneemt. Onafhankelijke analyse vond dat SAM 3D Body een plausibele pose voorrang geeft boven metrische nauwkeurigheid en atypische lichamen (scoliose, leeftijdsgebonden veranderingen, zwangerschap) naar een gezond gemiddelde duwt. Dat is prima voor een avatar die er goed uit moet zien; het is fout voor medische, ergonomische of juridische opmeting, waar de afwijking juist het punt is.

Drie andere grenzen om rekening mee te houden. Eén enkele afbeelding kan diepte of ware schaal niet oplossen, globale positie en werkelijke afmetingen zijn dus onderbepaalde schattingen. Sterke occlusie, waarbij het grootste deel van het lichaam verborgen is, verslechtert het scherp. En het is per afbeelding, niet real-time: de community wedijvert al om dit op te lossen met snellere varianten en C++-runtimes, en video vereist extra machinerie voor temporele stabiliteit. De regel die u veilig houdt, is simpel. Snijd de toepassing toe op plausibel (visualisatie, try-on, avatars), niet op precies (opmeting, diagnose, veiligheid). Binnen die lijn is een zelf te draaien, privacyvriendelijk menselijk 3D-model een echte nieuwe optie in 2026.

Waar klassieke RAG in het mkb vastloopt

RAG maakt van uw documenten doorzoekbare kennis. Het zwakke punt is de eerste fase: de tekstherkenning. Een leveranciersfactuur met positietabel, een tweekoloms contract, een ingescand datasheet met maattekening: OCR zet dat soort dingen geregeld verkeerd in elkaar. De tabel wordt een cijferbrij, de kolommen lopen door elkaar, de tekening verdwijnt. Het model krijgt dan al kapotte tekst en antwoordt dienovereenkomstig. In onze ervaring zit bij echte dossiers het grootste deel van de fouten hier, lang voordat een taalmodel überhaupt aan het woord komt.

Hoe visueel zoeken dit omzeilt

Visuele retrievalmodellen slaan de tekstherkenning bij het zoeken over. Ze splitsen de afbeelding van de pagina op in veel kleine fragmenten, embedden elk fragment en vergelijken de zoekvraag daar direct mee. Zo blijft behouden dat een getal in een tabelcel staat en niet in de lopende tekst. Drie namen leiden het veld: ColPali als referentie, ColQwen als meestal sterkere variant op Qwen-basis, en ModernVBERT als klein, on-premise-geschikt model. De hele toolkit inclusief vectordatabase brengen we onder in het stackoverzicht. Voor het praktische beeld volstaat: de pagina wordt gezien, niet geraden.

Eerlijk over de kosten

De winst is niet gratis. Meerdere vectoren per pagina vereisen aanzienlijk meer indexopslag dan een enkele tekstvector. Bij een archief van pure, schone lopende tekst blijft klassieke tekst-RAG goedkoper en volstaat het. Visueel zoeken loont waar de layout de informatie draagt, en dat is in het mkb eerder de regel dan de uitzondering. En voor gevallen waarin u uiteindelijk toch doorzoekbare tekst nodig heeft, bijvoorbeeld om te kopiëren of voor een audittrail, blijft OCR zinvol, als aanvulling in plaats van vervanging.

De eerste stap is klein

Daarvoor hoeft u niets groots te verbouwen. Neem de twintig documenten waar uw huidige zoekfunctie op vastloopt, en stel precies de vragen die vandaag misgaan. Als visueel zoeken de tabelrij vindt die OCR kwijtraakte, heeft u uw antwoord, op uw eigen dossiers, niet op een benchmark. Het mooie eraan: de hele opzet draait lokaal, de data blijft in huis. Waarom dat telt voor gevoelige documenten, staat in On-premise versus cloud.

Waarom het samenvoegen het eigenlijke probleem was

Een lange sequentie genereren door korte clips aan elkaar te plakken, introduceert precies de artefacten die materiaal onbruikbaar maken: zichtbare naden tussen segmenten, gezichten van personages die tussen shots verschuiven, licht dat springt. Voor een merk- of productvideo is die drift het verschil tussen een bruikbaar asset en een overduidelijke vervalsing. Lengte in één enkele pass verwijdert de naad, en daarom zijn 30 native seconden een echte stap, geen ijdelheidscijfer.

Wat 2.5 werkelijk verandert

Drie dingen springen eruit voor een team dat het daadwerkelijk zou gebruiken:

• Native clips van 30 seconden. Eén pass, geen samenvoegen, zodat de consistentie over de hele duur standhoudt.
• Tot 50 multimodale referenties. Beelden, audio en video gecombineerd in één generatie, ongeveer vier keer de twaalf van Seedance 2.0, gericht op het stabiel houden van een personage, een product en een stijl.
• Gezamenlijke audio-videogeneratie. Beeld en geluid worden samen verwerkt in één latente ruimte in plaats van apart gegenereerd en daarna gesynchroniseerd, wat beweging en geluid uitgelijnd houdt.

Samen mikken deze op hetzelfde doel: consistentie over tijd, wat zakelijke video nodig heeft en korte clips niet konden bieden.

Het eerlijke voorbehoud

Kwaliteit is nu het makkelijke deel. Voor zakelijk gebruik beslissen de zware vragen: mag u het materiaal commercieel gebruiken, van wie is de gelijkenis erin, waar gaan de data heen, en is de output consistent genoeg om er een merk op te zetten. Seedance 2.5 zit in enterprise-bèta met een publieke lancering die begin juli wordt beoogd, de licentie- en herkomstdetails zijn dus precies waar u vóór de vastlegging naar moet kijken. Het bredere veld en hoe u tussen de modellen kiest, staat in ons overzicht van AI-video in 2026.

Waar het past

Voor storyboarding, conceptfilms en korte social-assets verandert een schone native clip van 30 seconden wat één persoon kan produceren. Voor gereguleerd of merkkritisch werk behandelt u het als een ontwerp-engine, tot de rechten en de consistentie uw lat halen. De capaciteit is echt; governance is het onderdeel dat u eerst goed moet regelen.

Waar RPA echt goed in is

RPA is regelgebaseerd en deterministisch. U beschrijft een vast proces, en het verloopt elke keer hetzelfde: dezelfde invoer, dezelfde weg, hetzelfde resultaat. Voor een gestructureerd, stabiel proces, bijvoorbeeld gegevens uit een vast formulier naar een ERP overzetten, is dat precies goed. Het is controleerbaar, herhaalbaar en goedkoop in gebruik. De zwakte toont zich pas wanneer er iets verandert: een nieuwe veldindeling, een onverwachte invoer, en de starre regel breekt.

Waar AI-agenten beter in zijn

Een AI-agent komt in beeld waar het proces niet star is: dubbelzinnige invoer, vrije taal, beslissingen die context nodig hebben. Hij kan een ongestructureerde e-mail lezen en het juiste doen, waar een RPA-regel zou capituleren. De prijs is dat hij niet deterministisch is: dezelfde invoer kan twee resultaten opleveren, en hij heeft sturing, vangrails en controle nodig. Hoever no-code-agenten reiken en waar ze ophouden, behandelen we elders.

De beslissingslijn

Een eenvoudige heuristiek scheidt de gevallen:

• Stabiel en gestructureerd (vast formulier, duidelijke regel, hoge herhaling): RPA. Betrouwbaarheid verslaat flexibiliteit.
• Dubbelzinnig en talig (vrije teksten, wisselende invoer, oordeelsvragen): Agent. Flexibiliteit verslaat starheid.
• Gemengd: vaak het beste antwoord. RPA doet het vaste deel, de agent neemt alleen het punt over dat echt oordeel vereist.

De marktcijfers manen tot nuchterheid: Gartner verwacht dat meer dan 40 procent van de agentische AI-projecten eind 2027 wordt stopgezet. Veel daarvan, omdat een agent werd ingezet waar een regel had volstaan.

De nuchtere middenweg

Niet AI of RPA, maar de juiste laag voor het juiste deel. De duurste fout is een betrouwbaar, regelbaar proces over te laten aan een niet-deterministische agent, alleen omdat AI moderner klinkt. Begin met de vraag naar de taak, niet naar het gereedschap. Waar AI werkelijk in de stack hoort en via welke interface, brengt API tegen MCP tegen CLI in kaart.

Waar het helpt

Vibe coding blinkt overal uit waar snelheid telt en de code daarna mag verdwijnen. Het prototype op een middag, het interne gereedschap voor een klein team, de klik-dummy voor een klantpresentatie, de eerste 70 procent van een idee: hier levert het echte waarde. Karpathy's oorspronkelijke voorbeeld was precies dat, wegwerpsoftware voor een weekendproject.

De vraag bevestigt dat. Gereedschappen zoals Cursor, Claude Code, Lovable en Bolt zijn in recordtijd gegroeid, Lovable naar circa 200 miljoen dollar jaaromzet eind 2025. Ook in mijn werk is het nut concreet: een vakspecialist zonder programmeerachtergrond kan een idee zelf aan de praat krijgen, in plaats van het eerst te beschrijven en dan twee weken te wachten. Zolang het resultaat een experiment blijft en niemand er zijn bedrijf op bouwt, is dat een tempowinst die u niet moet onderschatten.

Waar het bijt

Zodra de code wordt uitgeleverd, draait het beeld om, en het bewijs is ongemakkelijk concreet. Veracode onderzocht in 2025 meer dan 80 taken en meer dan 100 modellen: 45 procent van de gegenereerde code bevatte een beveiligingslek, en nieuwere of grotere modellen scoorden niet beter. Een studie van METR vond dat ervaren ontwikkelaars met AI-gereedschappen 19 procent trager waren, maar zichzelf sneller inschatten.

Daar komen de incidenten bij die blijven hangen. Een Replit-agent verwijderde in juli 2025 een productiedatabase, negeerde de uitdrukkelijke instructie om niets te wijzigen, en beweerde daarna dat herstel onmogelijk was (dat was het niet). Ongeveer een op de vijf door AI voorgestelde pakketten bestaat helemaal niet, en 43 procent van die verzonnen namen duikt herhaaldelijk op, wat aanvallers een nieuw gat in de toeleveringsketen opent. Addy Osmani noemt het het 70-procentprobleem: de AI brengt u snel naar 70 procent, de laatste 30 procent uit uitzonderingsgevallen, beveiliging en integratie blijft klassiek ingenieurswerk. En juridisch is de zaak duidelijk: de aansprakelijkheid voor uitgeleverde software blijft bij het bedrijf dat haar bouwt en verkoopt, niet bij de AI-aanbieder.

De grens: wegwerp tegenover uitgeleverd

Het nuttigste onderscheid gaat niet over gereedschappen, maar over het doel. Een script dat één persoon eenmalig gebruikt, is iets anders dan software die uw klanten, uw auditors en de EU Cyber Resilience Act vanaf december 2027 beoordelen. Zelfs Gartner, dat tegen 2028 rekent op 40 procent vibe-coding-aandeel in bedrijfssoftware, noemt de ruwe output uitdrukkelijk wegwerpcode, niet productierijp.

Voor het mkb betekent dat: de vraag is niet of uw team vibe coding mag gebruiken, maar waarvoor. Wegwerp en experiment: graag, snel, zonder omhaal. Alles wat klantgegevens raakt, wordt uitgeleverd of een toetsing moet doorstaan: nooit ongelezen. Deze ene sortering bespaart de meeste latere pijn.

De volwassen weg: gecontroleerd vibe coding

Het goede nieuws is dat het professionele antwoord in 2025 en 2026 al bestaat, en het heet geen verbod. Het heet gecontroleerd vibe coding, of AI-ondersteunde ontwikkeling: de AI als een zeer snelle junior, met een verantwoordelijke senior ernaast. Zo pakken wij het aan.

🔸 Specificatie voor de prompt. De tegenbeweging heet spec-driven development, met gereedschappen zoals GitHub Spec Kit: eerst specificatie, plan en taken, dan code. Dat maakt het resultaat toetsbaar in plaats van willekeurig.

🔸 Review en tests voor de productie. Geen AI-code gaat ongelezen live. Codereview, geautomatiseerde tests en een beveiligingsscan zijn de voorwaarde, niet de kers op de taart, zeker bij alles wat data of geld raakt.

🔸 Licentie en toeleveringsketen in het oog. Ongecontroleerde AI-code kan GPL-gelicentieerde fragmenten of verzonnen pakketten binnensmokkelen. Beide horen thuis in het controleproces, voordat het een compliance-probleem wordt.

Vibe coding is een briljant gereedschap voor de juiste taak en een risico voor de verkeerde. Het verschil zit erin om voor de eerste prompt te weten aan welke kant van de grens u staat. Aan welke kant staat uw volgende project?

Wat YOLO26 werkelijk veranderde

YOLO26 verwijdert de twee nabewerkingsstappen die eerdere detectoren omslachtig maakten in gebruik. Het voert standaard een one-to-one-detectiekop uit, er is dus geen Non-Maximum Suppression (NMS) bij inferentie, en het netwerk geeft definitieve detecties direct uit. Het laat ook de Distribution Focal Loss (DFL) vallen, wat de kop lichter maakt voor edge- en laagenergie-apparaten. Ook het trainingsrecept is nieuw: een MuSGD-optimizer, progressive loss en kleindoel-labeltoewijzing.

Waarom NMS-vrij het deel is dat telt: NMS is een aparte, datagevoelige stap die na het netwerk draait, en de duur ervan varieert met hoeveel objecten er in het beeld zijn. Het verwijderen ervan geeft u deterministische latentie en een schonere export, precies wat u wilt als het doel ONNX, TensorRT, OpenVINO of CoreML op vaste hardware is. Minder nabewerkingsknoppen betekenen minder manieren waarop het productiepad afwijkt van het lab.

De cijfers zijn incrementeel, niet dramatisch. Op COCO behaalt YOLO26n 40,9 mAP bij 2,4M parameters, en Ultralytics meldt tot 43 procent snellere CPU-ONNX-inferentie dan YOLO11n. Dit CPU-cijfer, niet de nauwkeurigheid, is de kop voor een koper die detectie draait op courante edge-silicium zonder GPU.

De versienummers betekenen niet meer wat u denkt

Het enige nuttigste dat u in 2026 moet begrijpen, is dat "YOLO" niet langer één project is en de versienummers van verschillende teams komen. Ultralytics onderhoudt YOLO26, YOLO11 en de oudere v8 en v5. YOLOv12 en YOLOv13 zijn aparte academische lijnen, en beide steunen nog steeds op NMS en DFL, precies de dingen die YOLO26 verwijderde.

De les is dat een hoger versienummer geen nieuwer product van dezelfde leverancier is. Het is soms een compleet andere onderzoeksgroep. YOLOv13 kreeg openlijke kritiek omdat het een AP van ongeveer 54,8 meldde tegenover YOLOv12s 55,2, terwijl het zwaarder draaide, een regressie die als upgrade werd gepresenteerd. En YOLO zelf is niet automatisch de nauwkeurigheidsleider: transformer-gebaseerde detectoren uit de RF-DETR-familie concurreren nu rechtstreeks mee aan de bovenkant. Lees de benchmark en de beheerder, niet het label.

De licentievraag die een Duitse koper als eerste stelt

Controleer voor de architectuur de licentie, want de standaardlicentie beperkt hoe u uitlevert. Ultralytics YOLO is gelicentieerd onder AGPL-3.0. AGPL is een sterke copyleft-licentie: als u de software verspreidt of als dienst via een netwerk aanbiedt, bent u doorgaans verplicht de volledige bijbehorende broncode van uw afgeleide werk vrij te geven, en de gangbare interpretatie breidt deze verplichting uit naar de gewichten en de omringende applicatiecode.

Het punt dat de meeste teams over het hoofd zien, is dat on-premise u niet vrijstelt. De netwerkclausule van AGPL wordt geactiveerd doordat de functionaliteit als dienst wordt aangeboden, in sommige interpretaties zelfs intern gericht, niet alleen doordat een binary aan een klant wordt geleverd. Voor een closed-source product of een inzet die u liever niet open source maakt, verkoopt Ultralytics een commerciële enterprise-licentie. Deze wordt individueel berekend, zonder openbare prijs, en hoort dus vroeg in het inkoopgesprek thuis, niet nadat het prototype werkt.

Het inkooprelevante inzicht is eenvoudig: reken de enterprise-licentie in of kies vanaf het begin een detector onder een permissieve licentie (Apache of MIT). Dit is dezelfde controlevraag waar wij bij open-weightmodellen steeds weer op terugkomen, waar de licentie en de stack, niet de benchmark, bepalen wat u mag doen.

Hoe u kiest zonder het nummer achterna te jagen

Behandel de releases van 2026 als een korte, saaie checklist in plaats van een ranglijst.

• Leg een onderhouden versie vast. Voor productie is de Ultralytics-lijn (YOLO26 of YOLO11) de ondersteunde weg. De academische lijnen v12 en v13 zijn onderzoek, nuttig om te lezen, niet de standaard om te leveren.
• Lees de benchmark, niet het label. Vergelijk mAP en latentie op hardware die dicht bij de uwe ligt, en wees eerlijk dat RF-DETR of een kleiner ouder model voor uw scenario kan winnen.
• Test het exportpad vroegtijdig. De waarde van NMS-vrij wordt gerealiseerd in de ONNX- of TensorRT-export op uw doelapparaat. Bevestig dit daar voordat u zich vastlegt.
• Verhelder de licentie voor de pilot. AGPL of enterprise-licentie of een permissief alternatief. Beslis dit terwijl het nog goedkoop is om te wijzigen.

Niets daarvan heeft het nieuwste nummer nodig. Het heeft een detector nodig die bij uw latentie, op uw hardware, onder een licentie draait waarmee u kunt leven.

Het eerlijke deel komt daarna. n8n neemt u de bekabeling van bedrijfsprocessen uit handen, en met de AI-nodes komt er echte taalverwerking bij. Zodra er echter een taalmodel in het spel is, wordt het proces niet meer deterministisch, en precies daar wordt bepaald of een automatisering in de praktijk standhoudt. Dit artikel laat beide zien: wat n8n goed kan, en waar de grens naar echte engineering ligt.

Wat n8n eigenlijk is

n8n is een op nodes gebaseerd platform voor workflow-automatisering. U bouwt een proces visueel op uit nodes en kunt op elk punt eigen code in JavaScript of Python toevoegen.

🔸 Self-hosted of cloud. Het doorslaggevende punt voor het mkb: n8n draait als Docker-container op uw eigen infrastructuur. Verwerking en data blijven in uw eigen netwerk, het bedrijf blijft alleen verantwoordelijke.

🔸 Meer dan 400 integraties plus een HTTP-node voor elke gewenste REST-interface. Wat er niet als kant-en-klare node is, koppelt u zelf aan.

🔸 Fair-code, niet klassiek open source. De Sustainable Use License staat intern zakelijk gebruik gratis toe. Verboden is n8n als gehost product aan derden door te verkopen. Voor klassiek eigen gebruik is dat niet kritiek, maar voor een technisch publiek is het belangrijk dit correct te benoemen.

Wie nog moet beslissen of AI überhaupt lokaal moet draaien, vindt de afweging in On-premise versus cloud-LLM.

Hoe n8n bedrijfsprocessen automatiseert

Het opzet is altijd hetzelfde: een trigger start het proces, daarna lopen de nodes stap voor stap.

🔸 Trigger: webhook, tijdschema, een app-gebeurtenis zoals een nieuwe e-mail of een nieuwe CRM-invoer, een verzonden formulier.
🔸 Nodes: app-integraties, HTTP-aanroepen, database-query's, logica zoals IF en Switch, datatransformatie.

In de praktijk zien we in het mkb steeds weer dezelfde patronen:

Dat is dezelfde logica waarmee wij onze eigen Event Scout-microapp hebben gebouwd, voordat we besloten wat echte engineering verdiende.

Waar AI in beeld komt

n8n heeft AI niet aangeplakt, maar geïntegreerd als een eigen node-familie op basis van LangChain.

🔸 AI Agent Node. Een volwaardige agent met tool-aanroepen, geheugen en een iteratieve reasoning-lus, niet alleen een promptveld. De agent krijgt andere nodes of workflows als tools.

🔸 RAG over eigen documenten. Sinds versie 1.74.0 in januari 2025 kunt u vectorstores zoals Qdrant, Weaviate of pgvector rechtstreeks als tool voor de agent koppelen. Zo antwoordt het systeem op basis van uw eigen documenten, niet vanuit de algemene modelkennis. Wat RAG precies is, hebben we uitgelegd in Wat is RAG.

🔸 Lokale modellen. Via de Ollama-koppeling draait de inferentie op uw eigen hardware. Self-hosted n8n plus een lokaal model levert een volledig private AI-stack op zonder doorgifte naar een derde land. Welke hardware dat realistisch kost, staat in Lokaal LLM in het bedrijf.

Wat goed werkt: classificatie, extractie, routing, RAG, eenvoudige agenten. Fragiel wordt het bij lange, meerstaps agentenketens en bij de reproduceerbaarheid van modeluitvoer.

Grenzen, en wanneer het richting engineering kantelt

Een paar punten die wij klanten vooraf meegeven:

🔸 Determinisme en foutopsporing. Een AI-stap levert bij dezelfde invoer niet per se dezelfde uitvoer. Het debuggen van lange agent-workflows is bewerkelijk.
🔸 Versiebeheer. Workflows leven in de database. Nette, Git-gebaseerde review is niet de native standaard, maar eerder iets voor de enterprise-functies.
🔸 Schaling. De single-server-modus loopt bij veel parallelle webhooks tegen zijn grenzen aan. Voor productie is de queue-modus met aparte workers nodig.
🔸 Onderhoud. Self-hosted betekent: updates, beveiligingspatches, back-ups en monitoring liggen bij u.

Richting echte engineering kantelt het zodra bedrijfskritische, deterministische logica, hoge transactievolumes, strikte service levels of multi-agent-gebruik in continu bedrijf nodig zijn. Dan zijn tests, CI/CD en observability nodig, niet alleen kliks in de editor. De hardening-release n8n 2.0 van januari 2026 heeft hierop ingespeeld, met geïsoleerde code-uitvoering en stabieler gedrag onder belasting.

Hoe wij n8n bij iiterate inschatten

Wij zetten n8n graag in voor precies waar het sterk in is: interne processen snel automatiseren, AI daar aankoppelen waar het een stap echt beter maakt, en dat geheel AVG-conform in eigen huis draaien.

De fout die we het vaakst zien, is een werkend proces verwarren met een productierijp systeem. Voor interne, goed te tolereren processen is n8n vaak het volledige antwoord. Zodra het proces bedrijfskritisch wordt, is n8n de snelste manier om het juiste proces te vinden, en het punt waarop wij het beproefde pad omzetten naar eigen engineering. Waar AI in het mkb over de hele linie zinvol is, hebben we samengevat in AI-oplossingen voor het mkb.

De keuze gaat dus niet over welk model abstract beter is. Ze gaat over de taak die voor u ligt en de stack die u al gebruikt.

Eerst de afkomst goed op orde

De helft van de verwarring in deze vergelijking zit in de naamgeving, dus het loont om die eerst helder te krijgen.

🔸 GPT Image 2 is OpenAIs huidige beeldmodel, de opvolger in de gpt-image-reeks, uitgebracht in 2026. De oudere API-ID gpt-image-1 is de eerste generatie, niet dit model.
🔸 Nano Banana Pro is Googles marketingnaam voor Gemini 3 Pro Image, aangekondigd in november 2025 en gebouwd op Gemini 3 Pro.
🔸 Nano Banana zonder de Pro is het eerdere Gemini 2.5 Flash Image, nu gepositioneerd als de snelle en goedkope variant. Verwar de twee niet, want hun uitvoerkwaliteit en prijs verschillen.

Dit goed op orde hebben is belangrijk om dezelfde reden waarom de modelafkomst in de Fable-5-les over soevereiniteit belangrijk was: over een tool die u verkeerd hebt geïdentificeerd, kunt u niet goed nadenken.

De vergelijking die echt werk beslist

De assen die de uiteindelijke output echt veranderen:

Kort samengevat: Nano Banana Pro wint op tekst, resolutie en consistentie. GPT Image 2 wint op algemene look en op integratie in een bestaande OpenAI-workflow.

Waar elk wint

🔸 Marketingcreatie met veel tekst in beeld of infographics. Nano Banana Pro. Beste tekstweergave, 2K- en 4K-uitvoer en Search Grounding voor correcte feiten en logo's. GPT Image 2 is een solide terugvaloptie als u toch al op OpenAI bouwt.
🔸 Product- of karakterconsistentie over een reeks. Nano Banana Pro. Het is het model met een genoemde specificatie, 14 referentiebeelden en 5 consistente personen, wat een coherente campagne of een terugkerende productopname nodig heeft.
🔸 Algemene hero- of redactionele beelden. Nipt. GPT Image 2 leidt momenteel de algemene tekst-naar-beeld-ranglijsten, kies dus op basis van look-voorkeur. Kies Nano Banana Pro als u 4K rechtstreeks uit het model nodig hebt.
🔸 Nauwe stackintegratie. Gebruik wat u al draait. Een OpenAI-omgeving krijgt een API en batchkortingen met GPT Image 2. Een Google- of Vertex-omgeving krijgt native generatie met Nano Banana Pro.

Dat is dezelfde selectiediscipline die wij toepassen bij AI-videomodellen en bij beeld-naar-3D met TRELLIS. Kies op basis van de taak, niet van het logo.

Eerlijke grenzen aan beide kanten

Geen enkel model is vrij van compromissen, en de compromissen zijn wat in productie bijt.

🔸 GPT Image 2 stopt bij ongeveer 1536px aan de lange zijde en biedt slechts drie beeldverhoudingen, het verliest dus bij grote formaten en ongewone vormen. De tokenprijs maakt edit-zwaar werk duur, omdat edits ook beeld-invoertokens berekenen. Het watermerk bestaat uit C2PA-metadata in plaats van een ingebedde onzichtbare markering, wat u moet toetsen aan uw compliance-eisen.
🔸 Nano Banana Pro draagt het onzichtbare SynthID-watermerk op de uitvoer, dat onder de hoogste enterprise-laag niet verwijderbaar is. Sommige klanten willen het weg, controleer dit dus vroeg. Het draait bovendien met hogere kosten en latency dan de basis-Nano Banana, en Google publiceert geen duidelijke prijs per beeld, plan de kosten dus via de Vertex-rekenmodule.

Niets daarvan is een uitsluitingscriterium. Het is het soort detail dat bepaalt welk model past bij een specifieke klanteis.

Hoe wij bij iiterate kiezen

Onze standaardkeuze is geen trouw aan één model, maar een korte checklist. Bevat het beeld tekst of is 4K nodig? Moet het consistent blijven over een reeks heen? Welke cloud gebruikt de klant al? Zijn er watermerk- of residentievereisten?

Meestal beantwoorden deze vier vragen zichzelf. Tekstzwaar, hoogresolutie- of consistentiekritisch werk gaat naar Nano Banana Pro. Algemeen redactioneel werk en OpenAI-native pipelines gaan naar GPT Image 2. Wij houden beide in de gereedschapskist, juist omdat het juiste antwoord per briefing verandert.

De modellen zullen elkaar blijven inhalen, controleer dus ranglijsten en prijzen opnieuw op het moment van beslissen. Wat stabiel blijft, is de gewoonte: het model laten aansluiten bij de taak, en bij de stack waarin de klant al leeft.

Deze bijdrage behandelt wat TRELLIS is, hoe het werkt, waar het past in een echte asset-pipeline en op welke punten het ophoudt een antwoord met één klik te zijn.

Wat TRELLIS is

TRELLIS is een generatief 3D-model dat een beeld, meerdere beelden of een tekstprompt aanneemt en een 3D-asset genereert.

🔸 Gestructureerde latents (SLAT). Het kernidee is een uniforme latent die een dunbezet 3D-voxelrooster voor de structuur verbindt met dichte visuele kenmerken voor het uiterlijk. Vorm loskoppelen van uiterlijk is wat dezelfde latent tot verschillende outputs laat worden.
🔸 Drie outputs uit een latent. Radiance fields, 3D-gaussians of een als GLB geëxporteerde mesh. GLB is het praktische doel, omdat het materialen draagt in web- en AR-viewers.
🔸 Open en MIT-gelicentieerd. Het werkpaard voor beelden, TRELLIS-image-large, heeft 1,2 miljard parameters. Het model en het merendeel van de code zijn MIT, wat telt voor commercieel gebruik. Een nieuwere 4B-reeks voegt volledig fysiek gebaseerde materialen toe, de moeite waard om te volgen terwijl ze rijpt.
🔸 Getraind op grote schaal. Rond 500.000 gecureerde objecten, met het paper als CVPR 2025 Spotlight.

Dat staat naast het parametrische, stuurbare uiteinde van 3D-werk, dat we behandelen in Grasshopper voor computerondersteund ontwerp. Generatieve 3D en parametrische 3D lossen verschillende problemen op.

Hoe het werkt

De pipeline is kort te beschrijven en nuttig om te begrijpen voordat u er een GPU aan wijdt.

1. Input. Een enkel beeld, meerdere aanzichten of een tekstprompt.
2. Gestructureerde latent. Een tweetraps rectified-flow-transformer genereert eerst de dunbezette structuur en vult vervolgens de SLAT-kenmerken.
3. Decoderen. De latent decodeert naar uw gekozen formaat: mesh, gaussians of radiance field.

In de praktijk plant u met ongeveer 16 GB VRAM als ondergrens, met 24 GB comfortabel. De generatie loopt in minder dan twee minuten op een RTX 4090. Community-builds drukken de geheugenbehoefte verder omlaag, wat TRELLIS realistisch zelf-hostbaar maakt in plaats van gehuurd. Voor teams die al lokale tegenover gehoste inferentie afwegen, geldt dezelfde afweging die we beschreven in On-premise tegenover cloud-LLM, ook voor generatieve media.

Waar het past in een asset-pipeline

De sterkste match is het begin van de pipeline, waar tempo boven finish gaat.

🔸 Een productfoto of prompt naar een GLB. Plaats het in een three.js-viewer of een model-viewer op het web, converteer naar USDZ voor AR of zet het in een visualisatiescène. Snel concepting en previews zijn waar TRELLIS uitblinkt.
🔸 Lokaal bewerken. TRELLIS kan een regio van het model opnieuw genereren of verfijnen, wat zeldzaam is onder generatoren die van één beeld uitgaan.
🔸 Eerlijk over topologie. De output is generatieve geometrie, geen kunstenaarschone mesh. Verwacht ongelijkmatige driehoeken, geen schone edge-flow en automatisch gegenereerde UV's. Voor games of film gaat u retopologiseren, opnieuw UV-mappen en texturen opnieuw bakken. De nieuwere materiaalbewuste reeks verkleint deze kloof, zonder haar te sluiten.

De waardetest voor een gegeven asset is dus eenvoudig: moet het volgende week correct uitzien in een viewer, of moet het een riggbaar, geoptimaliseerd game-asset zijn? TRELLIS is uitstekend in het eerste en een startpunt voor het tweede.

TRELLIS tegenover de alternatieven

Het open en gehoste 3D-veld bewoog snel. Een korte oriëntatie:

Waar TRELLIS staat: de sterkste werkelijk MIT-gelicentieerde optie met output in meerdere formaten en lokaal bewerken. Gehoste tools zoals Tripo en Rodin verslaan het op meteen schone topologie, en Hunyuan wint vaak op textuur, maar met een restrictievere licentie. Als uw vereiste is het model en de juridische voorwaarden te bezitten, is TRELLIS het voor de hand liggende startpunt.

De eerlijke grenzen, en hoe wij het gebruiken

Een paar kanttekeningen die we op tafel leggen voordat iemand TRELLIS in productie inzet:

🔸 Topologie en UV's zijn niet productieklaar voor games of CAD. Plan budget in voor retopo.
🔸 CAD valt buiten het bereik. Generatieve meshes zijn geen parametrische solids, dus geen engineering-geometrie.
🔸 Het inputrisico ligt bij u. Het model is MIT, maar de juridische blootstelling van uw inputbeeld of prompt is de uwe. Voer geen productfoto's in die u niet kunt licentiëren.

Wij behandelen TRELLIS als een concepting- en previz-engine: een manier om in een middag een geloofwaardig 3D-asset voor een klant neer te zetten en dan te beslissen wat een handgemaakte pipeline verdient. Dat is hetzelfde instinct achter waar de huidige golf van AI-videomodellen nuttig is, en dezelfde selectiediscipline die we toepassen bij het kiezen van een beeldmodel. Het gereedschap is niet de levering. Het oordeel over waar het past, is dat wel.

Dit artikel brengt beide kanten in kaart: waar deze platforms in 2026 echt goed in zijn, en de concrete punten waarop u een muur kunt verwachten.

Wat een no-code agent-builder eigenlijk is

Het helpt om twee zaken te scheiden die onder dezelfde noemer worden verkocht.

Workflowautomatisering is deterministisch. Een trigger gaat af, vaste stappen lopen, dezelfde invoer levert dezelfde uitvoer op. Klassieke Make- of Zapier-scenario's spelen zich hier af, en ook een hoop nuttig werk.

Een no-code agent-builder laat een taalmodel het pad bepalen. U beschrijft een resultaat, en het model kiest tools, roept API's aan, leest uw documenten en blijft net zolang doorlussen totdat het denkt klaar te zijn. Het verloop wordt niet vooraf door u vastgelegd.

De grens vervaagt omdat de automatiseringsplatforms agents op hun canvassen hebben geschroefd, terwijl de agent-native tools integraties toevoegden. Voor een mkb-team is de praktische vraag niet 'agent of workflow'. Het is hoeveel non-determinisme u in een bedrijfsproces toelaat, en wie de data beheert terwijl het draait. Datzelfde onderscheid maakten we toen we schreven over het verschil tussen een API, een MCP-server en een CLI.

Waar ze vandaag goed in zijn

Voor de juiste taak ingezet, verdienen deze tools snel hun plaats:

🔸 Triggers en integraties. Webhooks, app-gebeurtenissen en schema's via duizenden connectors. De bekabeling is opgelost.

🔸 Tool-aanroepen. De agent chat niet alleen, hij handelt: hij bevraagt een database, plaatst iets in een systeem, maakt een ticket aan.

🔸 Retrieval over uw eigen documenten. Antwoorden verankeren in interne kennis is nu een kwestie van een paar klikken, hetzelfde patroon dat we behandelen in ons artikel over RAG.

🔸 Meerstaps-workflows met een mens in de lus. Een goedkeuringspoort voordat er iets onomkeerbaars gebeurt.

De winst is tempo. U kunt in dagen aantonen dat een idee het waard is, en precies daarvoor dient een prototype. Wij hebben onze eigen Event Scout micro-app in die geest gebouwd, voordat we besloten wat echt engineering verdiende.

Waar ze ophouden

Dat is het deel dat de meeste demo's overslaan, en de reden waarom Gartner verwacht dat meer dan 40 procent van de agentische projecten eind 2027 wordt afgebroken. De faalmodus is zelden een crash. Hij is stiller dan dat.

🔸 Betrouwbaarheid en non-determinisme. Dezelfde aanvraag levert niet twee keer hetzelfde resultaat op. Agents crashen niet, ze driften: ze lussen, kiezen de verkeerde tool of handelen op verouderde context. De kosten uiten zich in kwaliteit en latentie, zonder rood lampje op het dashboard.

🔸 Evaluatie en observeerbaarheid. No-code-consoles geven u dunne tracing. Meten of een agent werkelijk beter wordt, over een hele meerstaps-run heen en niet alleen het eindantwoord, is een uitbreiding die u zelf moet bouwen.

🔸 Datagovernance en hosting. De meeste van deze platforms zijn Amerikaanse SaaS. Voor Duitse data betekent dat AVG- en Schrems-II-vraagstukken die u niet kunt wegwuiven. De zelf hostbare opties die data op uw eigen EU-servers houden, vormen een korte lijst: n8n, Flowise, Langflow, Dify. Wij gaan dieper op deze afweging in in On-premise versus cloud-LLM en in wat de AVG daadwerkelijk toestaat.

🔸 Kosten bij schaalvergroting. Facturering per uitvoering en per credit bestraft volume. Bij een creditmodel kan dezelfde agent een paar euro of meerdere honderden kosten, puur afhankelijk van hoe hij gebouwd is. Pilots ogen goedkoop. De productie is dat vaak niet.

🔸 Lock-in en overdracht. Propriëtaire canvassen exporteren niet naar echt engineering. Wanneer u een no-code tool ontgroeit, bouwt u meestal opnieuw, in plaats van te migreren.

De beslissingslens

Ik gebruik vijf vragen om te bepalen of iets no-code blijft of opklimt naar een gebouwd systeem. Beoordeel elke vraag met laag of hoog.

1. Datagevoeligheid. Raakt het aan persoons- of gereguleerde data?
2. Volume- en kostencurve. Schaalt het gebruik naar een punt waarop facturering per credit pijn doet?
3. Betrouwbaarheidseis. Is het intern en vergevingsgezind, of klantgericht met een SLA?
4. Logica-complexiteit. Lichte vertakking of diepe voorwaardelijke en toestandsgebonden logica?
5. Audit en evaluatie. Heeft u evals op trajectniveau en een audit spoor nodig?

Twee of meer 'hoog'-antwoorden, en u wilt een maatwerk of hybride bouw. Anders is no-code het juiste gereedschap, vooral om waarde aan te tonen.

Het patroon dat in de praktijk werkt, is geen kwestie van of-of. Prototype op iets als n8n of Flowise, vind het pad dat echt levert, en verhard vervolgens precies dat ene pad tot eigen engineering. Het prototype was niet verspild. Het heeft u precies verteld wat u moet bouwen.

Hoe wij ze bij iiterate behandelen

Wij grijpen vroeg en vaak naar no-code agent-builders, en zijn ons vervolgens bewust van wanneer we ze verlaten. Een no-code agent is een snelle, eerlijke manier om uit te zoeken of een resultaat het engineering waard is dat nodig zou zijn om het betrouwbaar te maken. Dat is echte waarde, en voor veel interne taken is het het hele antwoord.

De fout die ik in het mkb het vaakst zie, is een werkende demo behandelen als een af systeem. Dat is niet hetzelfde, en de kloof daartussen is de lijst hierboven. Als u weet waar de grens ligt voordat u begint, krijgt u het tempo zonder het afgebroken project. Wilt u een gefundeerde blik op waar AI in een mkb-onderneming eigenlijk past, dat hebben we opgeschreven in AI-oplossingen voor het mkb.

Twee voorbehouden vooraf voor een Duitse koper. De prijzen van alle drie veranderen vaak, behandel elk getal hier dus als verouderd en controlewaardig. En dataresidentie is een echte randvoorwaarde: geen van de drie host standaard in de EU, wat telt voordat persoonsgegevens een gesprek raken.

Wat elk platform eigenlijk is

🔸 ElevenLabs Agents. Gebouwd op de spraakkwaliteit waar ElevenLabs bekend om staat, nu omhuld door een gehoste agentlaag met telefonie via SIP. De keuze als de meest natuurlijk klinkende stem en ontwikkelaarscontrole de doorslaggevende factoren zijn.

🔸 Retell AI. Telefonie-eerst-infrastructuur voor voice-agents. Het positioneert zich via lage latentie en betrouwbare gespreksafhandeling, inkomend en uitgaand, en laat u uw eigen carrier meebrengen. De keuze voor productieve belactiviteit.

🔸 Voiceflow. Een visueel, collaboratief platform voor het ontwerpen van chat- en voice-agents, met ingebouwde kennisbank. Ontwerpgestuurd en no-code-eerst. De keuze voor een CX- of ontwerpteam dat aan stromen itereert. Let op: de live telefoonstem is hier de zwakste van de drie, omdat ze leunt op een aparte telefonieaanbieder.

Als uw taak dichter bij een tekst- of tool-gebruikende agent ligt dan bij een telefoonlijn, geldt dezelfde bouwen-versus-kopen-logica als bij no-code-agentbouwers.

De vergelijking die telt

De dimensies die een voice-agentproject echt bepalen, naast elkaar:

Lees de tabel als kaart van afwegingen, niet als scorebord. Geen kolom is bij alles het beste, dat is precies het punt.

Waar elk platform past

🔸 Een Duitse supportlijn die telefonie en een natuurlijke Duitse stem nodig heeft. Begin met Retell voor betrouwbare gespreksafhandeling en carriercontrole, of ElevenLabs, als de natuurlijkheid van de Duitse stem de doorslaggevende factor is. Voor strikte datasoevereiniteit host geen van beide standaard in de EU, plan dus zelf gehost Retell of een EU-native alternatief.

🔸 Een ontwerpgestuurd team dat een CX-stroom bouwt. Voiceflow. De visuele builder, de samenwerking met meerdere editors en de kennisbank laten een team zonder ontwikkelaars itereren. Voeg telefonie apart toe als u spraak nodig heeft.

🔸 Een ontwikkelaar die maximale spraakkwaliteit en eigen controle wil. ElevenLabs. Beste TTS, SDK-controle, modelagnostisch, SIP voor telefonie.

Het patroon is hetzelfde dat wij op de meeste gereedschapskeuzes toepassen: eerst de taak benoemen, dan het gereedschap kiezen dat die taak bezit.

De Duitse vraag naar dataresidentie

Dit is het deel dat beslist of een voice-agent überhaupt is toegestaan, voordat spraakkwaliteit al telt.

AVG-conformiteit is niet hetzelfde als EU-hosting. Een aanbieder kan AVG-conform zijn en gesprekken toch op Amerikaanse infrastructuur verwerken en opslaan, wat de Schrems-II-vragen weer opent. Over deze drie heen: ElevenLabs biedt EU-dataresidentie alleen in het enterprise-niveau, Retell bereikt dit via self-hosting, en Voiceflow is pure cloud zonder soevereine residentie-optie.

Voor een Duitse supportlijn die klantgegevens verwerkt, maakt dat van de shortlist net zozeer een hostingbeslissing als een featurebeslissing. Het is dezelfde logica die wij uiteenzetten in wat de AVG daadwerkelijk toestaat en in on-premise tegenover cloud-LLM: bepaal waar de data mogen staan, kies dan het gereedschap dat dat respecteert.

Hoe wij zouden kiezen

Wij zouden niet uitgaan van het merk. Wij zouden uitgaan van drie vragen: loopt dit via de telefoon, wie onderhoudt het, en waar mogen de data staan.

Is het een telefoonlijn, dan verdient Retell de eerste blik. Draagt de spraakkwaliteit de ervaring en bezit een ontwikkelaar het, dan ElevenLabs. Moet een niet-technisch team de stroom ontwerpen en bezitten, dan Voiceflow. En als de data de EU niet mogen verlaten, verschuift het gesprek naar de hosting voordat het bij de features komt, wat de shortlist vaak opnieuw vormt.

De prijzen zullen zich blijven bewegen, controleer ze dus opnieuw op het moment van evaluatie, in plaats van te vertrouwen op één enkel getal. Het blijvende deel is de fit, en de fit volgt de taak.