Dieser Beitrag sammelt die Anwendungsfälle, bei denen Latenz nicht Komfort ist, sondern Bedingung, und beschreibt, woran sie bisher gescheitert sind.

Warum Doom das bessere Argument ist als der Benchmark

Ein Spiel liefert die Bedingungen, die ein Benchmark verschweigt. Der Aktionsraum ist fest und klein. Der Zustand ist vollständig beschreibbar. Und es gibt ein hartes Zeitfenster, in dem geantwortet sein muss, sonst ist die Antwort wertlos, egal wie gut sie ist.

Genau an dieser Stelle scheitert ein Token-für-Token-Modell nicht an Intelligenz, sondern an Verfahren. Der Nachweis ist deshalb keine Spielerei: Wer zeigt, dass eine Entscheidung in ein Frame-Budget passt, hat gezeigt, dass sie auch in ein Zahlungsvorgang-Budget passt.

Die Spiele-Projekte als Belastungstest

Die Community hat das schnell durchdekliniert. typesafe-snake lässt den Code die legalen Züge erzeugen und das Modell einen davon je Tick wählen. jev-plays-pokemon-red läuft auf einem Emulator und ruft das Modell nur an Verzweigungen auf, mit Brier-Scores auf den eigenen Vorhersagen als Qualitätsmaß. Dazu kommen Mario-, Drohnen- und Fahr-Demos, mehrere davon in unter einer Stunde gebaut.

Der Blitzschach-Test ist die klarste Zahl aus dieser Gruppe. Jev antwortete in rund 2,6 Sekunden je Zug, während Vergleichsmodelle 6 bis 15 Sekunden brauchten und aus gewonnener Stellung auf Zeit verloren. Die Zugqualität war nicht der entscheidende Faktor, die Einhaltung des Budgets war es.

Handel, Sprachagenten und Browser-Automatisierung

Dieselbe Eigenschaft trägt Anwendungen ohne Spielcharakter. jev-trader baut eine Marktentscheidungsschleife im Sub-Sekunden-Bereich und dokumentiert Trocken- und Echtbetrieb getrennt. QuantDinger setzt das Modell als Vorprüfung vor einen Einstieg und blockiert abgelehnte Aufträge, mit protokolliertem Rückfallpfad.

Bei Sprachagenten geht es um die Entscheidung, ob unterbrochen werden darf und wann eine Antwort beginnt. Das muss im Rhythmus eines Gesprächs passieren, also deutlich unter einer Sekunde. Browser-Automatisierung hat dasselbe Profil: Welches Element ist gemeint, aus einer sichtbaren Menge, sofort. Für gesprochene Navigation werden rund 0,0002 US-Dollar je Entscheidung bei etwa 300 Millisekunden berichtet.

Was das für gewöhnliche Systeme bedeutet

Die meisten B2B-Systeme haben kein Frame-Budget, aber sie haben Budgets, die niemand aufgeschrieben hat. Ein Zahlungsvorgang darf nicht auf eine Betrugsbewertung warten. Eine Suchanfrage darf nicht auf die Neusortierung ihrer Treffer warten. Ein Assistent, der drei Sekunden braucht, wird nicht benutzt, egal wie gut die Antwort ist.

Diese Budgets waren bisher der Grund, warum Prüfungen weggelassen wurden. Fällt die Begründung weg, fällt auch der Grund weg. Wie sich ein Antwortzeitbudget für einen KI-Assistenten überhaupt aufteilt, haben wir in Antwortzeit eines KI-Assistenten beschrieben.

Die harten Grenzen im Echtzeitbetrieb

Ein Auswahlaufruf trägt bis zu 255 Optionen, eine Skala 2 bis 10 Stufen. Die Ratengrenzen liegen bei rund 250.000 Tokens je Sekunde und 1.200 Anfragen je Minute und sind laut Anbieter dynamisch. Für eine Schleife, die zehnmal je Sekunde entscheidet, ist die Anfragegrenze und nicht die Latenz der bindende Faktor.

Und es bleibt bei Text. Kein Bild, kein Audio, kein Video. Wer einen Spielzustand oder eine Kameraszene bewerten lassen will, muss sie vorher in eine Zustandsbeschreibung übersetzen. Diese Übersetzung ist die eigentliche Ingenieursarbeit, nicht der Modellaufruf.

Dieser Beitrag beschreibt sechs davon und benennt jeweils die Fragen, aus denen die Entscheidungsschicht besteht. Es sind Muster, keine fertigen Systeme.

Rechnungsabgleich und Eingangsprüfung

Eine eingehende Rechnung wird gegen Bestellung, Vertrag, Lieferantenstammdaten und Liefernachweis gehalten. Die Fragen sind unabhängig voneinander: Stimmt die Position mit der Bestellung überein, liegt der Preis im vertraglich vereinbarten Rahmen, ist der Lieferant bekannt, existiert ein Liefernachweis. Jede Frage bekommt eine eigene Wahrscheinlichkeit, und erst der Code verrechnet sie zu einer Freigabe.

Das ist der Unterschied zu einem einzigen Modellaufruf, der "prüfe diese Rechnung" fragt. Vier getrennte Urteile lassen sich einzeln nachvollziehen und einzeln nachjustieren. Ein zusammengefasstes Urteil nicht.

Reisekosten und Spesenfreigabe

Ein Spesenbeleg wird zunächst auf Lesbarkeit geprüft, dann klassifiziert, dann gegen die Reisekostenrichtlinie gehalten. Bewirtungsbelege sind der Fall, an dem die meisten Automatisierungen scheitern, weil die Regel selten eindeutig ist und der Betrag allein nicht reicht.

Als Fragensatz funktioniert das gut: Ist der Beleg lesbar, welche Kategorie, überschreitet der Betrag die Grenze für diese Kategorie, fehlt eine erforderliche Angabe. Was unterhalb der Konfidenzschwelle liegt, geht an einen Menschen, und zwar mit der Angabe, welche der vier Fragen unsicher war.

Schadensmeldungen und Erstbewertung

In der Erstbewertung einer Schadensmeldung existiert meist bereits eine Prüfliste. Sie wird heute entweder von Hand abgearbeitet oder in ein Formular gepresst. Als Satz unabhängiger Ja-Nein-Fragen auf demselben Vorgang bleibt jede Einzelwahrscheinlichkeit erhalten, statt zu einer Ampel zusammenzufallen.

Der operative Gewinn liegt nicht in der Automatisierung der Entscheidung, sondern in der Reihenfolge. Fälle, bei denen alle Fragen eindeutig sind, kommen zuerst durch. Fälle mit einer unsicheren Antwort landen vorne in der menschlichen Warteschlange statt hinten.

Prüfberichte und regulatorische Durchsicht

Ein Dokument gegen einen Anforderungskatalog zu halten ist ein Stapel unabhängiger Fragen auf einem Zustand. Vertragsklauseln gegen eine Vorgabenliste, ein Prüfbericht gegen eine Norm, eine Dokumentation gegen eine Checkliste. Das Modell beantwortet jede Anforderung einzeln, der Bericht entsteht im Code.

Wichtig ist die Grenze: Das Ergebnis ist eine Vorsortierung, keine Bewertung. Wer eine Begründung braucht, braucht einen Menschen oder ein generierendes Modell, und warum das nicht dasselbe ist, steht in Eine Zahl ohne Begründung.

Sicherheitsmeldungen und Alarmkontext

Eine Sicherheitsmeldung wird mit dem Kontext zusammengeführt, in dem sie entstanden ist, und dann auf drei Dinge geprüft: War die Handlung autorisiert, gibt es eine harmlose Erklärung, wie stark ist die Beweislage. Die dritte Frage ist die wichtigste, weil sie darüber entscheidet, ob überhaupt jemand geweckt wird.

Dasselbe Muster trägt die Durchsicht abgeschlossener Agentenläufe, wenn ein Unternehmen KI-Agenten auf eigene Systeme lässt. Rechteüberschreitung, Aufgabenerfüllung, Auffälligkeit, je als eigene Frage.

Extraktion mit Kontrolle statt Extraktion allein

Das wirksamste Muster für Dokumenten-Pipelines ist eine Kaskade. Ein kleines, günstiges Modell extrahiert die Felder. Eine typisierte Entscheidungsschicht prüft jeden Wert einzeln gegen den Quelltext. Nur was durchfällt, geht an ein größeres Modell oder an einen Menschen.

Damit verschiebt sich die Qualitätsfrage von "wie gut extrahiert das Modell" zu "wie zuverlässig erkennen wir einen falschen Wert". Die zweite Frage ist messbar, die erste war es nie. Welche Fehlerbilder in Dokumentenstrecken typisch sind, behandelt Wo ein KI-Feature schiefgeht.

Dieser Beitrag geht durch die öffentlichen Projekte, die seit dem 15. September entstanden sind, und benennt das wiederkehrende Muster dahinter. Die Sammlungen liegen offen, unter anderem als awesome-jev und awesome-jev-by-typesafe.

Triage ist der erste Reflex

Die naheliegendste Anwendung ist ein Posteingang, der sortiert werden muss. TypeSafe selbst zeigt das an einem Triage-Dashboard für GitHub-Repositories: Zu jedem Issue beantwortet das Modell denselben festen Fragensatz, also Art, Schwere, Dringlichkeit, Duplikat und nächster Schritt. Unsichere Fälle und Stellen, an denen Menschen widersprochen haben, bekommen eigene Aufmerksamkeit, und jede menschliche Korrektur wird aufbewahrt und bei späteren Läufen wieder mitgegeben.

Dasselbe Muster trägt den Support-Posteingang. Der Code sammelt Vorgang und Geschäftsregeln ein, das Modell beantwortet Kategorie, Dringlichkeit und Frustrationsgrad, und die Zuweisung an eine Warteschlange bleibt gewöhnlicher Code. Die Reihenfolge ist wichtig: erst die Warteschlangen verbessern, dann automatisieren.

Retrieval, Suche und die Prüfung von Behauptungen

Die zweite große Gruppe sitzt vor oder hinter einer Suche. jev-reranker ist eine Rust-Kommandozeile, die Treffer mit Ja-Nein-Fragen neu ordnet, filtert und kürzt. nlgrep sucht in Dateien nach einer in natürlicher Sprache formulierten Bedingung und gibt gerankte Dateien mit Fundstellen zurück. jevql schiebt dieselben Fragen als Filter und Sortierung in eine Postgres-Abfrage.

Aufschlussreicher als die Werkzeuge ist die Fragenliste, die sich eingebürgert hat. Ein abgerufener Abschnitt wird nicht nur auf Relevanz geprüft, sondern auch darauf, ob er die Antwort stützt, ob er ihr widerspricht und ob er eine eingeschleuste Anweisung enthält. Vier unabhängige Urteile auf demselben Zustand, in einem Aufruf.

Code, Commits und CI als Entscheidungsproblem

Eine überraschend dichte Gruppe sitzt in der Entwicklungskette selbst. jev-git prüft gestagte Diffs vor dem Commit auf Geheimnisse und zerstörerische Kommandos. is-malicious bewertet Quell-, Konfigurations- und CI-Dateien, wobei Schwellenwerte und Schweregrade im Code bleiben. jev-pref liest Projektkonventionen aus einer AGENTS.md und prüft Diffs dagegen, also semantisches Linting statt Formatprüfung.

Der gemeinsame Nenner: Regeln, die bisher als Regex oder als Kommentar im Pull Request existierten, werden zu Ja-Nein-Fragen, die auf jedem Commit laufen können, weil sie nichts kosten.

Agenten, die ihre eigenen Schritte bewerten

Die interessanteste Gruppe steuert andere KI-Systeme. JevRouter wählt aus einer Menge von Fähigkeiten aus, während Verfügbarkeit, Rechte und Fallback im Code bleiben. jev-guard bewertet geplante Werkzeugaufrufe nach Risiko und gibt sie frei, fragt nach oder verweigert. wakegate entscheidet vor dem Fortsetzen eines schlafenden Agenten, ob ein Ereignis überhaupt zu ihm gehört.

Beobachtbarkeit gehört in dieselbe Gruppe. jevlogs annotiert OpenTelemetry-Datensätze und überspringt teure Analyse für Spuren ohne Aussagewert. Ein abgeschlossener Agentenlauf lässt sich im Nachhinein auf Rechteüberschreitungen, Aufgabenerfüllung und Zufriedenheit prüfen, ohne dass ein Mensch ihn liest.

Zahlen, die aus echten Läufen stammen

Ein paar Projekte veröffentlichen ihre eigenen Messungen, und die sind belastbarer als jeder Anbieter-Benchmark. jev-skip, eine Browser-Erweiterung, die Sponsoren-Abschnitte in YouTube-Videos anhand der Untertitel erkennt, meldet eine Trefferquote von 77 Prozent der Sponsoren-Sekunden über 23 Videos bei 0,0008 US-Dollar je Video. Eine Audit-Studie mit 1.204 gecrawlten Seiten kam auf 4.816 typisierte Urteile je Lauf und 0,0048 US-Dollar je Triage-Stapel aus zwölf Fragen.

Die Zahl, die im Alltag zählt, ist nicht der Faktor gegenüber einem Sprachmodell, sondern die Absolutkosten je Entscheidung. Bei diesen Größenordnungen verschwindet die Frage, ob eine Prüfung sich lohnt.

Das Muster hinter allen Projekten

Fast jedes dieser Projekte trennt gleich. Das Modell beantwortet eine enge Frage über einen übergebenen Zustand. Der Code besitzt die Optionsmenge, den Schwellenwert, die Rechte, die Reihenfolge und den Fallback. Wo ein Projekt diese Trennung aufgibt und das Modell entscheiden lässt, was es tun darf, taucht im Repository kurz darauf eine Ausnahmebehandlung auf.

Die zweite Wiederkehr ist die Bündelung. Statt fünf Aufrufe nacheinander zu machen, werden alle plausibel benötigten Fragen in einem Aufruf gestellt, auch die, deren Antwort vielleicht gar nicht gebraucht wird. Bei kostenlosen Ausgabe-Tokens ist das billiger als die zweite Netzwerkrunde. Was das für den Entwurf einer Pipeline bedeutet, steht in Wo ein Entscheidungsmodell tatsächlich hingehört.

Für alles, was den Antrag, den Anspruch, die Rechnung oder das Arbeitsverhältnis eines Menschen berührt, wirkt die fehlende Begründung zunächst wie das eigentliche Problem. Sie ist es nicht. Sie ist eine Aussage darüber, wo der Nachweis liegen muss.

Die generierte Begründung war nie ein Nachweis

Ein Sprachmodell, das einen Fall klassifiziert, kann um eine Begründung gebeten werden, und die liest sich gut. Genau darin liegt die Falle. Der Text entsteht im Nachhinein und ist kein Protokoll der Berechnung, die zur Entscheidung geführt hat. Er ist eine plausible Geschichte über eine Entscheidung, nicht die Entscheidung. Abgelegt wurde er trotzdem als Prüfspur.

Ein Entscheidungsmodell nimmt diese Illusion weg. Es liefert eine typisierte Ausgabe und eine kalibrierte Wahrscheinlichkeit, und nichts, was einer Begründung ähnelt. Der Nachweis muss also um das Modell herum gebaut werden statt von ihm angefordert.

Wie der Nachweis aussieht

In der Praxis protokolliert die Entscheidungsschicht den übergebenen Zustand, die exakt gestellte Frage, die typisierte Antwort, die Wahrscheinlichkeit, den zu diesem Zeitpunkt geltenden Schwellenwert und die Version des Fragensatzes. Das ist reproduzierbar. Bei gleichem Zustand lässt sich zeigen, was das System gefragt wurde und was es zurückgegeben hat. Ein generierter Absatz kann das nicht leisten.

Der Fragensatz selbst wird damit zum versionierten Artefakt. Ändert sich eine Frage, ändert sich die Grundlage aller späteren Entscheidungen, und das muss sichtbar sein. In Systemen, die wir bauen, liegt dieser Satz im Repository und nicht in einer Konfigurationsoberfläche.

Kalibrierung verdient einen präzisen Satz

Kalibrierung ist eine Eigenschaft einer Verteilung. Gibt das Modell über viele Fälle hinweg 0,8 an, sind davon etwa acht von zehn korrekt. Über den konkret vorliegenden Fall sagt das nichts.

Der Schwellenwert ist damit eine Richtungsentscheidung über akzeptierten Fehler und gehört in ein Dokument, das ein Mensch unterzeichnet hat, nicht in eine Konstante im Quellcode. Teams, die das ernst nehmen, messen die Kalibrierung auf einem zurückgehaltenen Teil der eigenen Daten nach, statt sie vorauszusetzen.

Aufsicht braucht Grenzen, keinen Fließtext

Die Anforderungen des EU AI Act an menschliche Aufsicht bei höherem Risiko zeigen in dieselbe Richtung. Aufsicht ist dann wirksam, wenn die prüfende Person sieht, was das System bekommen hat, was es entschieden hat und wo die Grenze liegt. Ein selbstbewusster Satz, erzeugt von genau dem System, das die Entscheidung getroffen hat, leistet das nicht. Ein protokollierter Zustand mit Frage, Score und Schwellenwert leistet es.

Es gibt eine Variante, die schlechter ist als beide Optionen. Ein Entscheidungsmodell liefert eine Zahl, und ein Sprachmodell wird anschließend gebeten, diese Zahl zu erklären. Das wirkt gründlich und ist es nicht. Die Erklärung wird aus der Ausgabe rekonstruiert, nie aus der Berechnung.

Die Form, auf die wir hinbauen

Typisierte Entscheidungen dort, wo die Antwort eine Klasse, ein Score oder ein Boolescher Wert ist. Generierung nur dort, wo ein Mensch tatsächlich Fließtext braucht. Ein Entscheidungsnachweis, der außerhalb von beidem liegt und nicht davon abhängt, dass eines von beidem einsehbar ist. Menschliche Prüfung ausgelöst durch das Wahrscheinlichkeitsband statt durch das Thema, damit die Fälle nahe der Grenze Aufmerksamkeit bekommen und nicht die Fälle, die jemand für heikel gehalten hat.

Als Prinzip ist daran nichts neu. Neu ist, dass die Entscheidungsschicht günstig genug geworden ist, damit sich die Architektur auch in gewöhnlichen B2B-Workloads lohnt und nicht nur in Systemen, an denen ohnehin eine Aufsichtsbehörde hängt.

Ein Entscheidungsmodell ersetzt nicht das Sprachmodell im Stack. Es ersetzt die Sprachmodell-Aufrufe, die nie wirklich Sprachaufgaben waren. Dieser Beitrag benennt fünf solche Stellen und beschreibt einen Test, der ohne Business Case auskommt.

Klassifikation beim Eingang

Jede Dokumenten-Pipeline beginnt mit der Entscheidung, was überhaupt eingegangen ist. Rechnung, Lieferschein, Vertragsnachtrag oder etwas Unlesbares, das einen Menschen braucht. Die meisten Teams lösen das mit einem kleinen Modellaufruf plus JSON-Schema und härten anschließend wochenlang den Parser.

Eine typisierte Auswahl mit Konfidenzwert eliminiert das Parsing-Problem vollständig, weil die Ausgabe nie Text war. Der Schwellenwert, ab dem ein Fall an einen Menschen geht, wird damit zu einer eingestellten Größe statt zu einer Heuristik im Code.

Filterung im Retrieval

Bei Retrieval Augmented Generation ist nicht der fehlende Textabschnitt der teure Fehler, sondern der irrelevante, der zu einer selbstbewusst falschen Antwort synthetisiert wird. Jeden Kandidaten vor der Synthese auf tatsächliche Relevanz zu bewerten ist der wirksamste Guardrail der Pipeline und wird am häufigsten weggelassen, weil ein Sprachmodell dafür einen zusätzlichen Aufruf pro Abschnitt bedeutet.

Im Sub-Cent-Bereich bewertet man alle, und zwar nicht nur auf Relevanz: ob der Abschnitt die Antwort überhaupt stützt, ob er der Frage widerspricht, ob er eine eingeschleuste Anweisung enthält. Das sind vier Nouls auf demselben Zustand. Wie dieselbe Schicht in der Praxis eingesetzt wird, zeigt Was Entwickler mit Jev tatsächlich bauen.

Tool- und Routing-Auswahl

Agentische Systeme verbringen einen überraschend großen Teil ihres Latenzbudgets mit der Entscheidung, welches Werkzeug als Nächstes aufgerufen wird. Diese Entscheidung ist eine Auswahl aus einer festen Menge. Sie braucht keine Begründung, sie muss richtig und schnell sein.

Der belastbare Teil des Musters liegt in der Trennung der Achsen: Die Antwort sagt, was gewählt wurde, die Konfidenz sagt, wie sicher. Eine umkehrbare Aktion darf bei geringer Konfidenz laufen, eine unumkehrbare nicht. Damit wird aus einem Modellaufruf eine Freigabelogik, die im Code liegt und dort auch geprüft werden kann.

Prüfung der Extraktion und Guardrails

Nach der Extraktion eines Feldes muss etwas beurteilen, ob es vollständig und plausibel wirkt. Teams überspringen das, prüfen stichprobenartig oder leiten alles an einen Menschen weiter. Ein kalibrierter Score pro Feld macht daraus einen Schwellenwert, den man gegen ein reales Fehlerbudget einstellen kann statt gegen ein Bauchgefühl.

Policy-Prüfungen sind ebenfalls Klassifikationen. Üblicherweise laufen sie nur auf Anfragen, die jemand als riskant markiert hat, weil sie überall zu langsam und zu teuer waren. Diese Einschränkung entfällt weitgehend.

Wie man es ohne Business Case testet

Einen Monat produktiver Klassifikationsaufrufe nehmen und erneut abspielen. Genauigkeit und p95-Latenz gegen den heutigen Stand vergleichen. Dann nicht den Gesamtscore ansehen, sondern die Abweichungen, denn die Abweichungen zeigen, ob die Aufgabe jemals eine Sprachaufgabe war. Der Test kostet weniger als das Meeting darüber, ob man ihn durchführt. Die Schnittstelle dafür liegt bereits in gängigen Werkzeugketten, etwa als evaluate-Aufruf im AI SDK.

Der größere operative Gewinn steckt nicht in der Inferenzersparnis. Die meisten B2B-KI-Pipelines haben dünne Observability, weil die Bewertung jedes Schritts einen weiteren Modellaufruf kostet und dafür niemand Budget einplant. Sinkt die Bewertung auf einen Rundungsfehler, lässt sich jeder Schritt jedes Laufs bewerten, die Verteilung festhalten und Drift erkennen, bevor ein Nutzer sie meldet.

Nicht geeignet ist das Muster für alles, was eine Begründung liefern, an einen Menschen schreiben oder über den übergebenen Zustand hinausgreifen muss. Ein Entscheidungsmodell hat kein Weltwissen und keine Begründung. Arbeit dieser Art dorthin zu geben ist der Weg, auf dem ein erster Pilot scheitert.

Dieser Beitrag ordnet die These ein, benennt die belastbaren Zahlen und die Grenzen, und beschreibt, was daraus für die Architektur von B2B-Pipelines folgt.

Die Benennung ist die These

"System One" übernimmt die Trennung von Daniel Kahneman zwischen schnellem, intuitivem Urteil und langsamem, bewusstem Schlussfolgern. Das Modell selbst ist nach William Stanley Jevons benannt, dem Ökonomen hinter dem Jevons-Paradoxon: Wird eine Ressource billiger, steigt der Gesamtverbrauch, statt zu sinken. TypeSafe sagt damit offen, was passieren soll, sobald eine Entscheidung einen Bruchteil eines Cents kostet.

Die architektonische These trifft etwas, das in fast jeder B2B-Pipeline sichtbar ist. Die meisten Entscheidungen innerhalb eines Produktivsystems sind keine System-2-Probleme. Ist dieses Dokument eine Rechnung oder ein Lieferschein. Braucht dieses Ticket einen Menschen. Ist dieser abgerufene Textabschnitt für die gestellte Frage überhaupt relevant. Wirkt dieses extrahierte Feld vollständig. Das sind Klassifikationen, gelöst mit Modellen, die für Konversation gebaut sind, zu Konversationslatenz und Konversationspreisen.

Drei Fragetypen, mehr gibt es nicht

Die gesamte Schnittstelle besteht aus drei Primitiven. Noul beantwortet eine Ja-Nein-Frage mit einer Wahrscheinlichkeit zwischen 0 und 1. Choice wählt eine Option aus einer festen Menge von bis zu 255 Einträgen und liefert die vollständige Verteilung mit. Score ordnet auf einer Skala von zwei bis zehn Stufen ein und gibt einen wahrscheinlichkeitsgewichteten Mittelwert zurück.

Zustand und Fragen teilen sich ein Budget von rund 64.000 Tokens, wobei Zustand plus längste Einzelfrage bei etwa 32.000 Tokens liegen müssen. Nur Text, keine Bilder, kein Audio, kein Video. Die Enge dieser Schnittstelle ist kein Mangel, sondern der Punkt: Was zurückkommt, muss nicht geparst werden, weil es nie Text war.

Herstellerzahlen bleiben Herstellerzahlen

TypeSafe nennt bis zu 193-fach schneller und 444-fach günstiger als Frontier-Modelle bei eng gefassten Entscheidungsaufgaben. Das sind Benchmarks des Anbieters auf Aufgaben, die der Anbieter ausgewählt hat. Eine unabhängige Bestätigung der Größenordnung wird Monate dauern, und eng gefasste Benchmark-Aufgaben sind der freundlichste denkbare Fall für ein Entscheidungsmodell.

Die Richtung steht trotzdem kaum infrage, und der Markt hat das schnell deutlich gemacht. Vercel hat Jev ins AI Gateway aufgenommen und binnen weniger Tage als am schnellsten adaptierten Modell-Launch der Plattformgeschichte bezeichnet. Netlify zog nach. Ein Open-Source-CRM hat einen Pull Request gemerged, der eine völlig neue Modellkategorie einführt, "evaluation", samt darauf aufsetzendem Klassifikations-Node. Infrastruktur bewegt sich für eine marginale Verbesserung nicht so schnell.

Der eigentliche Effekt ist der zweiter Ordnung

Die meisten KI-Systeme behandeln heute jeden Schritt als Generierungsproblem, weil Generierung das einzige verfügbare Werkzeug war. Ein großes Modell übernimmt Routing, Extraktion, Bewertung und Formulierung, und die gesamte Pipeline erbt die Eigenschaften ihrer langsamsten und teuersten Komponente.

Trennt man die schnellen typisierten Entscheidungen von der langsamen generativen Arbeit, ändert sich die Form des Systems. Kostet eine Klassifikation fast nichts, hört man auf zu rationieren. Retrieval wird gefiltert statt Kontext vollgestopft. Jedes extrahierte Feld wird bewertet statt stichprobenartig geprüft. Die Policy-Prüfung läuft auf jeder Anfrage, nicht nur auf den als riskant markierten. Jevons, wie angekündigt.

Die Grenzen sind strukturell, nicht vorübergehend

Jev liefert eine Zahl ohne Begründung. Das wird relevant in dem Moment, in dem jemand fragt, warum ein Fall so geroutet wurde. Das Modell hat kein Weltwissen, es kennt ausschließlich den übergebenen Zustand. Kalibrierung ist eine Eigenschaft der Verteilung über viele Vorhersagen, keine Garantie für die einzelne Antwort. Was daraus für Nachweis und Aufsicht folgt, steht in Eine Zahl ohne Begründung.

Auch die schärfste Kritik in der Diskussion auf Hacker News verdient Beachtung. Ein großer Teil der Geschwindigkeit könnte aus eingeschränktem Single-Token-Decoding gegen eine feste Auswahlmenge stammen statt aus einer neuen Architektur. Träfe das zu, wäre der Vorteil reproduzierbar und der Burggraben schmal.

An der Lehre ändert das nichts. Entscheidungsarbeit und Spracharbeit haben unterschiedliche Kostenkurven, unterschiedliche Latenzbudgets und unterschiedliche Fehlermodi. Sie als eine Schicht zu bauen war eine Bequemlichkeit des Werkzeugs, keine Eigenschaft des Problems. Wo die Trennung in einer laufenden Pipeline konkret verläuft, beschreibt Wo ein Entscheidungsmodell tatsächlich hingehört.

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.

Ten artykuł porządkuje najważniejsze programy według stanu na wrzesień 2026 roku, opisuje krok po kroku drogę do wniosku i wskazuje typowe błędy, które mogą kosztować utratę wsparcia.

Jakie są rodzaje wsparcia

Istnieją cztery rodzaje wsparcia i różnią się bardziej logiką niż wysokością. Dotacja pokrywa część kosztów kwalifikowalnych i nie podlega zwrotowi, ale wymaga złożenia wniosku przed rozpoczęciem projektu, a na końcu rozliczenia wykorzystania środków (Verwendungsnachweis). Kredyt preferencyjny jest udzielany za pośrednictwem Państwa banku (Hausbank) i na wyższych poziomach może zawierać element dotacyjny. Forschungszulage to podatkowa forma wsparcia badań i rozwoju. Oferty doradcze nie wypłacają pieniędzy, ale pomagają umiejscowić przedsięwzięcie.

Projekt AI nie kwalifikuje się do wsparcia tylko ze względu na hasło AI, lecz wtedy, gdy odpowiada celowi programu: badaniom i rozwojowi, cyfryzacji procesów i produktów lub doradztwu zewnętrznemu. Przy poszukiwaniach warto wiedzieć, że federalne ministerstwo gospodarki działa obecnie jako BMWE (wcześniej BMWK), a ministerstwo badań jako BMFTR.

Programy federalne w skrócie

Na poziomie federalnym w 2026 roku szczególnie istotnych dla projektów AI jest pięć instrumentów o bardzo różnym statusie.

• ZIM (Zentrales Innovationsprogramm Mittelstand, centralny program innowacji dla MŚP). BMWE finansuje projekty badawczo-rozwojowe MŚP, realizowane samodzielnie lub z jednostkami badawczymi, a także sieci innowacji i studia wykonalności. Od 7 lipca 2026 roku obowiązuje czasowe wstrzymanie naboru wniosków: ZIM obecnie nie przyjmuje nowych wniosków, ponowne otwarcie planowane jest na początek 2027 roku i zależy od budżetu na 2027 rok. Wnioski już złożone są nadal rozpatrywane.
• KMU-innovativ. BMFTR finansuje obarczone ryzykiem projekty badawczo-rozwojowe w kluczowych technologiach, w tym w technologiach informacyjno-komunikacyjnych. Procedura jest dwuetapowa: najpierw zarys projektu, potem wniosek. Terminy to 15 kwietnia i 15 października, najbliższy przypada 15 października 2026 roku (stan na wrzesień 2026). Strona programu KMU-innovativ.
• Forschungszulage (ulga podatkowa na badania). Może z niej skorzystać każde przedsiębiorstwo podlegające opodatkowaniu w Niemczech, niezależnie od wielkości i branży. Najpierw BSFZ poświadcza, że chodzi o badania i rozwój, a następnie o ulgę wnioskuje się w urzędzie skarbowym po zakończeniu roku obrotowego, także w odniesieniu do projektów już zrealizowanych. Na 2026 rok została rozszerzona w ramach Investitionssofortprogramm (natychmiastowego programu inwestycyjnego). Instytucja certyfikująca Forschungszulage.
• ERP-Förderkredit Digitalisierung (511, 512). Za pośrednictwem Państwa banku KfW finansuje cyfryzację na trzech poziomach, od IT, oprogramowania i chmury, przez cyfryzację procesów, bezpieczeństwo IT i szkolenia, po większe przedsięwzięcia, wyraźnie obejmując wykorzystanie AI na danych przedsiębiorstwa. Wniosek należy złożyć przed rozpoczęciem projektu, a w przypadku pierwszego poziomu wcześniej wymagany jest KfW-Digitalisierungs-Check. Strona produktu KfW.
• Mittelstand-Digital Zentren. BMWE finansuje bezpłatne, niezależne od dostawców wsparcie w zakresie cyfryzacji, AI i bezpieczeństwa IT, z trenerami AI w centrach. Pieniądze nie są wypłacane. Obecna sieć jest stopniowo wygaszana do końca 2026 roku, a od 1 stycznia 2027 roku zastąpi ją nowa sieć z dodatkowym naciskiem na bezpieczeństwo IT, nadal bezpłatna dla MŚP. Mittelstand-Digital.

Dla konsorcjów nauki i przemysłu otwarta jest ponadto wytyczna BMFTR dotycząca flagowych projektów AI w łańcuchach wartości, z terminem na zarysy projektów 1 listopada 2026 roku (stan na wrzesień 2026).

Wsparcie na poziomie UE

Na poziomie UE dla projektów AI dostępne są cztery ścieżki: European Digital Innovation Hubs, EIC Accelerator, finansowanie kaskadowe i program Cyfrowa Europa.

• European Digital Innovation Hubs (EDIH). Regionalne konsorcja oferują bezpłatne lub dofinansowane usługi, takie jak „test before invest”, szkolenia i wsparcie w pozyskiwaniu inwestorów, z priorytetami takimi jak AI i cyberbezpieczeństwo. Przegląd Komisji Europejskiej.
• EIC Accelerator. Europejska Rada ds. Innowacji wspiera pojedyncze start-upy i MŚP z przełomowymi innowacjami bliskimi rynku w formie dotacji, inwestycji kapitałowej lub obu. Krótkie wnioski można składać w dowolnym momencie, a najbliższy termin na pełne wnioski to 4 listopada 2026 roku (stan na wrzesień 2026). EIC Accelerator.
• Finansowanie kaskadowe. Konsorcja projektów finansowanych przez UE przekazują część budżetu start-upom i MŚP w otwartych naborach, w formie kwot ryczałtowych, nagród lub bonów i w uproszczonej procedurze, na przykład na małe eksperymenty i projekty pilotażowe. Nabory są otwarte co najmniej dwa miesiące w portalu Funding & Tenders UE. Wytyczne Komisji (PDF).
• Program Cyfrowa Europa. Komisja ogłasza nabory w obszarach AI, superkomputerów, cyberbezpieczeństwa i kompetencji cyfrowych. MŚP korzystają z niego najczęściej pośrednio, na przykład za pośrednictwem EDIH. Strona programu.

Programy regionalne w Nadrenii-Palatynacie

W Nadrenii-Palatynacie wsparcie kraju związkowego przyznaje ISB, a dla projektów AI szczególnie istotne są cztery programy.

• InnoTop. Neutralne technologicznie finansowanie studiów wykonalności oraz projektów badawczo-rozwojowych dotyczących nowych lub ulepszonych produktów, procesów i usług, dla MŚP i SmallMidCaps.
• Innovationsgutschein (FuE-Auftrag). Bon na innowacje: dotacja dla MŚP, które zlecają uczelni lub instytutowi badawczemu prace badawczo-rozwojowe trwające do dwunastu miesięcy.
• IBI-EFRE. Dotacja na inwestycje, dzięki którym komercyjne MŚP wdrażają cyfryzację w produkcji i modelach biznesowych. Niektóre branże są wyłączone, obowiązuje minimalna wartość inwestycji, a wniosek składa się przez portal ISB przed rozpoczęciem projektu. Wpis w Förderdatenbank.
• Betriebsberatungsprogramm RLP. Dotacja do doradztwa zewnętrznego, wyraźnie także w zakresie cyfryzacji i sztucznej inteligencji. Wnioski można składać od 16 grudnia 2025 roku, a przy niektórych tematach potrzebna jest rekomendacja izby. Program zastępuje doradztwo technologiczne BITT, zakończone pod koniec 2025 roku. Strona programu ISB.

Przegląd programów w zakresie innowacji i cyfryzacji znajduje się na isb.rlp.de. W katalogu UE dla Niemiec nie udało się znaleźć EDIH z siedzibą w Nadrenii-Palatynacie (stan na wrzesień 2026). Najbliższe możliwości to EDIH Saarland, który kieruje ofertę także do Wielkiego Regionu, oraz Mittelstand-Digital Zentrum Kaiserslautern, które wspiera przedsiębiorstwa z Nadrenii-Palatynatu w zakresie gotowości na AI.

Programy regionalne w Nadrenii Północnej-Westfalii

W Nadrenii Północnej-Westfalii centralną ścieżką dla MŚP z siedzibą w tym kraju związkowym jest Mittelstand Innovativ & Digital (MID), a od 1 stycznia 2026 roku nowe projekty zatwierdza NRW.BANK.

• MID-Digitalisierung. Dotacja na rozwój rynkowych produktów cyfrowych z wykorzystaniem kluczowych technologii, wyraźnie obejmujących AI, uczenie maszynowe i eksplorację danych. Strona produktu NRW.BANK.
• MID-Digitale Sicherheit. Dotacja na analizy stanu IT, w tym testy penetracyjne, szkolenia pracowników i podstawowe środki ochrony IT. Portal wsparcia NRW.

Oba programy przydzielają możliwość złożenia wniosku w comiesięcznym losowaniu. Wylosowane firmy mają 28 dni na złożenie wniosku, a samo wylosowanie nie jest jeszcze przyrzeczeniem wsparcia. Nabór 2026 w programie MID-Digitale Prozesse, który finansuje doradztwo zewnętrzne, jest już zamknięty, ponieważ osiągnięto maksymalną liczbę wniosków (stan na wrzesień 2026). W Nadrenii Północnej-Westfalii działają ponadto trzy EDIH: w Dortmundzie, w Nadrenii z siedzibą w Akwizgranie oraz w Południowej Westfalii.

Pozostałe kraje związkowe i zakończone programy

W przypadku wszystkich pozostałych krajów związkowych najszybszą drogą do odpowiednich programów jest federalna Förderdatenbank (baza danych programów wsparcia). Każdy kraj związkowy ma własne programy, a Förderdatenbank obejmuje wsparcie federalne, krajowe i unijne z filtrami według regionu, uprawnionych wnioskodawców i rodzaju wsparcia. Rozstrzygająca pozostaje strona danej instytucji udzielającej wsparcia, ponieważ nabory otwierają się i zamykają w ciągu roku.

Zakończyły się dwa programy federalne, których wciąż często się szuka: Digital Jetzt nie przyjmuje już wniosków, a go-digital zakończono pod koniec 2024 roku. Nieaktualna jest także nazwa ERP-Digitalisierungs- und Innovationskredit, obecnym produktem KfW jest ERP-Förderkredit Digitalisierung.

Krok po kroku do wniosku

W niemal wszystkich programach droga do wniosku składa się z tych samych dziesięciu kroków, nawet jeśli formularze i portale się różnią.

1. Sprawdzić status MŚP. Zgodnie z zaleceniem UE 2003/361 za MŚP uznaje się przedsiębiorstwo, które zatrudnia mniej niż 250 osób i mieści się w progach rocznego obrotu lub sumy bilansowej. Przedsiębiorstwa partnerskie i powiązane mogą być wliczane. Forschungszulage i ERP-Förderkredit Digitalisierung są dostępne także dla większych przedsiębiorstw. Definicja MŚP w UE.
2. Skorzystać z bezpłatnej orientacji. Mittelstand-Digital Zentrum, EDIH lub federalne doradztwo w zakresie wsparcia pomogą Państwu umiejscowić przedsięwzięcie, zanim wysiłek trafi do wniosku.
3. Sprawdzić program i jego status. Czy program jest otwarty, czy obowiązuje termin, losowanie lub wstrzymanie naboru?
4. Nie zaczynać przed zatwierdzeniem. Wcześniejsze rozpoczęcie działania (vorzeitiger Maßnahmenbeginn), czyli start przed otrzymaniem decyzji o przyznaniu wsparcia, co do zasady jest niedopuszczalne, chyba że wytyczne lub pisemna zgoda na to pozwalają. Dotyczy to również wiążących zleceń dla usługodawców. W KfW wniosek musi zostać złożony przed rozpoczęciem projektu.
5. Zsumować pomoc de minimis. Jeżeli program przyznaje pomoc de minimis, obowiązuje limit 300 000 euro na przedsiębiorstwo w ciągu trzech lat. We wniosku deklarują Państwo pomoc otrzymaną już w tym okresie. Od 1 stycznia 2026 roku obowiązkowy jest w tym celu centralny rejestr. Rozporządzenie (UE) 2023/2831.
6. Napisać zarys projektu. W procedurach dwuetapowych na początku stoi krótki zarys, który musi być zrozumiały bez dodatkowych pytań i konkuruje z innymi zarysami. Projekty obsługują Projektträger (instytucje zarządzające projektami), takie jak DLR, PtJ czy VDI/VDE-IT, działające w imieniu ministerstwa. Podstawy finansowania projektów.
7. Złożyć wniosek. Federalne wnioski badawcze składa się zwykle przez easy-Online, kredyty KfW przez Państwa bank, a programy regionalne przez portale ISB lub NRW.BANK. Typowe dokumenty to opis projektu z planem prac, plan kosztów i finansowania, dokumenty dotyczące zdolności kredytowej, oświadczenie o statusie MŚP, w razie potrzeby oświadczenie de minimis oraz oferty dostawców.
8. Zabezpieczyć wkład własny. Dotacje pokrywają tylko część kosztów, a resztę przedsiębiorstwo finansuje samo.
9. Sprawdzić kumulację. Wsparcie można łączyć, ale tylko w granicach dopuszczalnej intensywności pomocy, a te same koszty nigdy nie mogą być finansowane podwójnie. Zwykle dzieli się je według pozycji kosztowych, na przykład bezpłatne doradztwo, kredyt na inwestycję i Forschungszulage na część rozwojową.
10. Raportować i złożyć rozliczenie. W trakcie projektu składają Państwo sprawozdania do Projektträger, a na końcu następuje Verwendungsnachweis, składający się z rozliczenia liczbowego i technicznego raportu końcowego. FAQ DLR Projektträger.

Typowe błędy

Typowe błędy mają charakter formalny i można ich uniknąć przed złożeniem wniosku.

• Zbyt wczesne zlecenie. Wiążące podpisanie umów dostawy lub doradztwa przed zatwierdzeniem, a w zależności od programu nawet przed złożeniem wniosku, może skutkować utratą prawa do wsparcia.
• Przecenienie statusu MŚP. Spółka zależna większej grupy może nie być MŚP, nawet jeśli sama jest mała.
• Niesprawdzony status programu. Programy zamykają się także w ciągu roku, co pokazują wstrzymanie naboru w ZIM i wyczerpany nabór MID-Digitale Prozesse w 2026 roku.
• Błędne rozumienie losowania. W MID wylosowanie nie jest przyrzeczeniem, a późniejszy termin jest krótki.
• Chybiony cel programu. Program doradczy nie finansuje licencji na oprogramowanie, a Mittelstand-Digital Zentrum nie wypłaca pieniędzy.
• Przegapiony termin. W KMU-innovativ przegapiony termin oznacza pół roku oczekiwania.
• Błędnie policzone de minimis. Okres trzech lat jest kroczący i nie jest powiązany z latami kalendarzowymi.
• Pomylone nazwy. EDIH Rheinland ma siedzibę w Akwizgranie i nie jest punktem kontaktowym dla Nadrenii-Palatynatu. Starsze wpisy na blogach wymieniają ponadto programy i nazwy produktów, które już nie istnieją.

Który program pasuje do jakiego projektu AI

Właściwy program wynika z charakteru przedsięwzięcia: badania, wdrożenie lub doradztwo.

Projekt AI jest bliski badaniom, gdy wiąże się z ryzykiem technicznym, na przykład z nową metodą lub modelem dla zagadnienia, którego wynik nie jest z góry znany. Do tego służą Forschungszulage, KMU-innovativ, InnoTop i Innovationsgutschein, ZIM po ponownym otwarciu, a w przypadku przełomowych przedsięwzięć bliskich rynku EIC Accelerator.

O wdrożenie chodzi wtedy, gdy sprawdzona technologia trafia do Państwa własnej firmy, na przykład wyszukiwanie we własnych dokumentach lub automatyzacja procesu. Pasują tu ERP-Förderkredit Digitalisierung, w Nadrenii-Palatynacie IBI-EFRE, a w Nadrenii Północnej-Westfalii MID-Digitalisierung, jeśli powstaje z tego produkt cyfrowy. Otwarte nabory finansowania kaskadowego mogą udźwignąć małe projekty pilotażowe.

Doradztwo jest na początku, gdy wciąż nie wiadomo, czy dany przypadek użycia się obroni. Mittelstand-Digital Zentren i EDIH są bezpłatne, a w Nadrenii-Palatynacie doradztwo zewnętrzne jest dofinansowywane z Betriebsberatungsprogramm. W zakresie bezpieczeństwa IT wokół projektu AI Nadrenia Północna-Westfalia oferuje MID-Digitale Sicherheit.

Ten artykuł stanowi ogólną informację, a nie poradę prawną ani podatkową, a warunki wsparcia się zmieniają.

Projekt AI powinien zostać merytorycznie zawężony, zanim padnie pytanie o dofinansowanie, więcej na stronie Gotowość na AI.

Czym jest Slush

Slush to konferencja dla start-upów i inwestorów w Helsinkach, która zaczęła się w 2008 roku jako spotkanie 250 osób. Działa non-profit, należy do fińskiej Startup Foundation i jest organizowana przez studentów i absolwentów wraz z dużym zespołem wolontariuszy.

Wydarzenie odbędzie się 18 i 19 listopada 2026 roku w Helsinki Expo and Convention Centre (Messukeskus), a 17 listopada zaplanowano program Day 0. Według organizatora w wydarzeniu uczestniczy ponad 12 000 osób, z czego około trzech czwartych to start-upy lub inwestorzy. W centrum uwagi są wyselekcjonowane europejskie start-upy, międzynarodowi inwestorzy i media technologiczne, a region DACH Slush wymienia wprost jako region kluczowy. Program i szczegóły są dostępne na oficjalnej stronie Slush.

Co wnosi iiterate

iiterate przywozi do Helsinek pracę, którą wykonujemy na co dzień: AI dla środowisk, w których dane nie powinny opuszczać firmy. Jesteśmy firmą doradczą w zakresie AI z Adenau w Nadrenii-Palatynacie i jedziemy jako część niemieckiej delegacji. Nasze obszary:

• LLM on-premise. Modele językowe działające we własnej infrastrukturze.
• RAG i zarządzanie wiedzą. Systemy retrievalu, które wyprowadzają odpowiedzi z dokumentów firmy i wskazują źródła.
• AI z przechowywaniem danych w UE. Architektury, w których przetwarzanie i przechowywanie pozostają w Unii Europejskiej.
• Computational design. Modele parametryczne i konfiguratory, w których reguły generują geometrię.

W rozmowach wychodzimy od konkretnych pytań: jakich danych dotyczy przedsięwzięcie, gdzie może odbywać się przetwarzanie i jaka architektura z tego wynika.

Kto powinien z nami porozmawiać

Porozmawiać z nami powinni przede wszystkim inwestorzy, firmy oraz założycielki i założyciele, którzy mają do czynienia z AI i wrażliwymi danymi.

• Inwestorki i inwestorzy, którzy oceniają przedsięwzięcia AI w branżach regulowanych lub wrażliwych pod względem danych.
• Firmy, które chcą wykorzystywać AI na poufnych dokumentach i potrzebują do tego przechowywania danych w UE lub we własnej infrastrukturze.
• Założycielki i założyciele, którzy pracują nad AI z wrażliwymi danymi i chcą porozmawiać o architekturze, eksploatacji lub współpracy.

Przedsięwzięcie, które nie jest jeszcze w pełni przemyślane, nie stanowi przeszkody, lecz dobry punkt wyjścia do rozmowy.

Umówienie spotkania w Helsinkach

Spotkanie w Helsinkach najlepiej umówić z wyprzedzeniem przez naszą stronę kontaktową. Prosimy krótko podać temat i dni, w których będą Państwo na miejscu. Rozmowy mogą odbywać się po niemiecku lub po angielsku.

Specyfikacja bez marketingu

Zanim przejdziemy do konsekwencji, pomaga rzeczowa tabela. Wszystkie wartości pochodzą z przeglądu modeli i ze strony cennika Anthropic, pobranych 10 września 2026 roku.

Warto zwrócić uwagę na to, co Anthropic dopisuje we własnym przeglądzie modeli: Claude Opus 5 jest zalecany jako domyślny wybór dla większości obciążeń, a Fable 5.1 przewidziano dla przypadków, w których Opus 5 na wyższym poziomie wysiłku nie wystarcza. To niezwykle jasne samoograniczenie, a zarazem pierwszy filtr dla każdej decyzji architektonicznej. Fable 5.1 nie jest ogólną modernizacją, lecz narzędziem do długich, spójnych zadań.

Modalność jest wąska i ma to znaczenie praktyczne. Wchodzą tekst i obrazy, wychodzi tekst. Żadnego dźwięku na wejściu ani na wyjściu, żadnego generowania obrazu ani wideo. Kto chce przetworzyć nagranie rozmowy, potrzebuje wcześniej transkrypcji. Kto potrzebuje odpowiedzi mówionych, potrzebuje dalej syntezy mowy. Kto chce tworzyć grafiki, potrzebuje innego modelu. Brzmi to banalnie, ale przesuwa granice systemu, koszty i kwestie ochrony danych dokładnie tam, gdzie stoją te dodatkowe komponenty.

Co zmienia milion tokenów, a czego nie

Okno rozliczane jest na całej długości według normalnych stawek za token, bez dopłaty za długi kontekst (Anthropic). Umożliwia to konstrukcje, które wcześniej rozbijały się nie o model, lecz o dzielenie materiału: kompletny zbiór umów albo dokumentacji przetargowej w jednym przebiegu zamiast trzydziestu kawałków i późniejszego scalania; cały ślad pracy agenta wraz z wynikami narzędzi, który nadal daje się analizować, zamiast urwanego po dwudziestu krokach; średniej wielkości repozytorium, w którym odpowiedź powstaje za jednym razem, zamiast wyszukiwania zgadującego z góry, które pliki są istotne. Zysk leży mniej w inteligencji, a bardziej w zniknięciu całej klasy pracy spajającej, a to właśnie ta praca spajająca była w naszych projektach regularnym źródłem trudnych do wykrycia błędów.

Liczba ta nie jest jednak liczbą stron. Anthropic szacuje 1 000 000 tokenów na około 555 000 angielskich słów przy obecnym tokenizatorze i jednocześnie zaznacza, że ten tokenizator wytwarza dla tego samego tekstu około 30 procent więcej tokenów niż poprzedni (Anthropic). Dane dotyczą tekstu angielskiego; dla zbioru niemieckojęzycznego nie da się z nich wyprowadzić żadnej liczby, trzeba ją zmierzyć. Kto planuje pojemność, liczy własne dokumenty tokenizatorem modelu, którego faktycznie używa, a nie przelicza na strony.

Z tego samego powodu porównywanie wielkości okien między dostawcami nic nie mówi. Token jest jednostką właściwą dla dostawcy i nie istnieje opublikowane przeliczenie sprowadzające dwa tokenizatory do tej samej ilości tekstu. Liczba w specyfikacji nie mówi więc, który model pomieści więcej Państwa tekstu.

Większe okno nie czyni też wyszukiwania zbędnym. Rozumowanie jest proste: wszystko, co znajduje się w oknie, jest opłacane przy każdym wywołaniu i przy każdym wywołaniu musi zostać przetworzone. Metoda, która znajduje dwadzieścia właściwych akapitów, pozostaje szybsza, tańsza i zwykle dokładniejsza niż taka, która wrzuca dziesięć tysięcy akapitów i liczy na uwagę modelu. Duże okno wyraźnie podnosi próg, od którego dzielenie staje się konieczne. Nie zastępuje pytania, jaka informacja jest potrzebna do tej konkretnej odpowiedzi.

Właściwa historia inżynierska nazywa się odczyt z pamięci podręcznej

Najciekawszą liczbą w specyfikacji nie jest wartość bezwzględna, lecz stosunek. Świeże wejście kosztuje 10 USD za milion tokenów, trafienie w pamięć podręczną 0,25 USD. Zapis do pamięci podręcznej kosztuje 12,50 USD za milion tokenów w wariancie pięciominutowym i 20 USD w wariancie godzinnym. W Fable 5.1 i Mythos 5.1 cena odczytu wynosi 0,025 ceny bazowej wobec 0,1 we wszystkich innych modelach Claude i jest to, według Anthropic, jedyna zmiana cenowa względem Fable 5 (Anthropic).

Czterdziestokrotna różnica między świeżym wejściem a trafieniem w pamięć podręczną przesądza o konstrukcjach. W pętli agenta ten sam prompt systemowy, te same definicje narzędzi i ten sam kontekst projektu są odczytywane na nowo w każdym kroku. Zadanie obejmujące dwieście wywołań narzędzi odczytuje ten sam wstęp dwieście razy. To, czy ten wstęp jest za każdym razem rozliczany jako świeże wejście, czy jako trafienie w pamięć podręczną, nie jest szczegółem rozliczeniowym, lecz granicą między konstrukcją, którą można wdrożyć na produkcję, a taką, która zostaje w demonstracji.

Właśnie dlatego sformułowanie Anthropic, że typowe obciążenia są około 25 procent tańsze, a silnie agentowe nawet około 45 procent, jest szacunkiem dotyczącym współczynnika trafień, a nie obniżką cen (Anthropic). Główne ceny wejścia i wyjścia pozostają takie same jak w Fable 5. Obciążenie o słabej lokalności pamięci podręcznej niemal nic z tej oszczędności nie zobaczy, a kto wpisze te 25 procent do budżetu bez zastrzeżenia, ma nie budżet, lecz nadzieję.

To, co w praktyce czyni współczynnik trafień dobrym lub złym, nie jest miarą z dokumentacji, lecz logiką inżynierską, i da się to nazwać:

• Stabilny prefiks. Ponownie wykorzystywany jest niezmieniony początek zapytania. Wszystko, co stałe, należy umieścić z przodu, wszystko zmienne z tyłu. Znacznik czasu, identyfikator sesji albo nazwa użytkownika w niewłaściwym miejscu unieważnia cały następujący po nim kontekst.
• Deterministyczny montaż. Listy narzędzi w losowej kolejności, wyniki wyszukiwania w zmiennym sortowaniu albo obiekty o niestabilnej kolejności kluczy tworzą przy każdym uruchomieniu nowy prefiks. Pamięć podręczna nigdy nie widzi wtedy dwa razy tego samego.
• Czas życia wobec rytmu zadania. Pięć minut pasuje do gęsto taktowanej pętli agenta. Nie pasuje do dialogu, w którym ktoś spędza między dwoma pytaniami dwadzieścia minut na spotkaniu. Wariant godzinny kosztuje więcej przy zapisie i opłaca się dopiero wtedy, gdy faktycznie ratuje trafienie.
• Dostateczna powtarzalność na prefiks. Wiele krótkich, wzajemnie niepowiązanych zapytań rozkłada się na wiele prefiksów. Każde płaci za zapis i rzadko doczekuje się odczytu. To przypadek, w którym ekonomia pamięci podręcznej działa przeciwko Państwu, a wtedy interfejs wsadowy z 50 procent rabatu w obie strony jest często lepszą drogą.

Konkretna wskazówka z cennika potwierdza ten sam punkt: zestaw narzędzi do obsługi komputera dokłada około 4 500 tokenów wejściowych na zapytanie, a zestaw do obsługi przeglądarki około 6 600 (Anthropic). To stały blok, który powraca w każdym kroku, a więc dokładnie ten materiał, który należy do stabilnego prefiksu.

Praca agentowa, narzędzia i pytanie o poziom wysiłku

Fable 5.1 zaprojektowano pod długie przebiegi. Anthropic przywołuje jako dowód nienadzorowany przebieg trwający 38 godzin nad problemem uczenia maszynowego (Anthropic). To deklaracja dostawcy o pojedynczym przebiegu, a nie wynik rozkładu, ale nadaje się jako rząd wielkości tego, pod co model zaprojektowano.

Tryb rozumowania jest adaptacyjny i stale włączony; wcześniejszy tryb ręczny z jawnym budżetem rozumowania nie jest już przyjmowany. Wobec Fable 5 są trzy zmiany łamiące zgodność, dotyczące każdej istniejącej integracji: wymuszone użycie narzędzia zwraca błąd, wcześniejsze modele nie odczytają bloków rozumowania tego modelu, a edycja wcześniejszych tur unieważnia te bloki. Dochodzą między innymi poziom wysiłku ustawiany na wiadomość, wiadomości systemowe obowiązujące w obrębie tury, czytelne komunikaty o postępie między wywołaniami narzędzi oraz niższa cena odczytu z pamięci podręcznej; kilka z nich oznaczono jako beta (Anthropic). Dla planowania oznacza to, że przejście na ten model nie jest zmianą konfiguracji, lecz niewielką przebudową z następującym po niej testem.

Przy poziomach wysiłku potrzebna jest staranność. Dokumentacja podaje high jako wartość domyślną (Anthropic), a ogłoszenie precyzuje, że ustawienie różni się zależnie od powierzchni: high w Claude Code, medium w Claude Cowork i na claude.ai (Anthropic). Pełnego zbioru akceptowanych wartości nie ma na stronach dokumentacji, które przejrzeliśmy, więc go nie twierdzimy.

Praktyczny wniosek jest niewygodny, ale ważny: liczba z benchmarku albo szacunek kosztów bez podanego poziomu wysiłku nie są odtwarzalne. Dwa zespoły mierzące ten sam model przez dwie różne powierzchnie mierzą różne konfiguracje. Kto chce, by oferty, wyniki testów i porównania wewnętrzne były wiarygodne, zapisuje poziom obok liczby, tak jak nie przepuszcza się pomiaru bez jednostki.

Stan wiedzy z czerwca 2026 to wymóg architektoniczny

Stan wiedzy i danych treningowych sięga czerwca 2026 roku (Anthropic). Operacyjnie oznacza to jednocześnie niewiele dramatycznego i całkiem sporo. Państwa cennik sprzed tygodnia, wczorajsza decyzja, stan portfela zamówień z dzisiejszego poranka: nic z tego nie znajduje się w modelu. Musi trafić do kontekstu przez wyszukiwanie, przez podłączone narzędzie albo przez prompt.

To nie wada modelu, lecz wymóg wobec architektury, i jest on niezależny od dostawcy. Każdy system, który ma udzielać informacji o bieżących faktach i nie ma zdefiniowanej drogi, którą te fakty wpływają, jest źle wyspecyfikowany, niezależnie od jakości modelu. Dwa wnioski sprawdziły się u nas. Po pierwsze, każda odpowiedź oparta na faktach potrzebuje w kontekście dającego się wskazać źródła, a nie pamięci modelu. Po drugie, każdy zestaw ewaluacyjny potrzebuje kilku pytań, których poprawna odpowiedź zmieniła się po dacie odcięcia: sprawdzają dokładnie tę ścieżkę, która na produkcji najchętniej pęka po cichu.

Znak wodny z artykułu 50 nie jest ścieżką audytu

Fable 5.1 i Mythos 5.1 od premiery noszą niewidoczny znak wodny w tekście (Anthropic). Anthropic stosuje to oznaczenie na całym świecie, a nie tylko w UE (Euronews). Tłem są obowiązki przejrzystości z artykułu 50 rozporządzenia o AI, obowiązujące od 2 sierpnia 2026 roku i wymagające maszynowo czytelnego oznaczania treści syntetycznych.

Rozstrzygające jest zastrzeżenie, które formułuje sama Anthropic. Wykryty znak wskazuje, że treść mogła zostać przetworzona przez Claude, wyraźnie nie jest w pełni rozstrzygający i sam z siebie nie potwierdza pochodzenia treści (Anthropic Help Center). Do tego interfejs wykrywania jest w zamkniętej wersji zapoznawczej dostępny tylko ograniczonemu kręgowi (MacRumors).

Dla firmy, która chce udokumentować własne wykorzystanie AI, wynika z tego trzeźwa wytyczna projektowa, i jest to ocena techniczna, a nie porada prawna: znak wodny to sygnał w wyjściu, który nie należy do Państwa, którego zwykle nie mogą Państwo sami odczytać i którego moc dowodową ogranicza sam dostawca. Nie jest więc ścieżką audytu. Jeśli ma być możliwe prześledzenie, który model, kiedy i z jakiego wejścia wytworzył jakie wyjście oraz kto je zatwierdził, dowód ten powstaje we własnych zapisach. Technicznie jest to mało spektakularne, bo chodzi o te same dzienniki, które i tak prowadzi się dla diagnostyki i kontroli kosztów.

Warunek, który w Niemczech przesądza o architekturze

W niemieckich projektach o użyciu modelu częściej decyduje sposób przetwarzania danych niż jego możliwości. Tutaj sytuacja jest jednoznacznie udokumentowana i dla wielu zaskakująca. Anthropic klasyfikuje Fable 5.1 jako Covered Model. Modele te wymagają 30-dniowego przechowywania danych i nie są dostępne w trybie zerowego przechowywania danych, o ile Anthropic wyraźnie tego nie dopuści. Organizacja działająca w trybie zerowego przechowywania musi świadomie włączyć przechowywanie dla konkretnej przestrzeni roboczej, w przeciwnym razie zapytania są odrzucane błędem (Anthropic).

Dwa uzupełnienia z tego samego źródła są konieczne, bo bez nich obraz się przekrzywia. Przechowywane dane, jak podaje Anthropic, nie są wykorzystywane do trenowania modeli bez wyraźnej zgody. A także w trybie zerowego przechowywania treści oznaczone jako podejrzane mogą być przechowywane do dwóch lat. Zerowe przechowywanie nie obejmuje ponadto wszystkich dróg do systemu, między innymi ani interfejsu wsadowego, ani składnicy plików.

Dochodzi kwestia regionu. W interfejsie pierwszej strony nie ma unijnego regionu inferencji. Parametr regionu inferencji przyjmuje dokładnie dwie wartości, global i us, a przechowywanie odbywa się wyłącznie w USA; regionu przestrzeni roboczej nie da się zmienić po jej utworzeniu (Anthropic). Praktyczna droga wewnątrz UE prowadzi przez chmurę partnerską: Amazon Bedrock i Google Cloud oferują regionalne punkty końcowe z gwarantowanym kierowaniem danych, z dopłatą 10 procent wobec punktów globalnych, i ustalają własne daty cyklu życia (Anthropic).

To dana projektowa, a nie wyrok o modelu. W praktyce pozostają trzy drogi, a wybór zapada przed pierwszym prototypem, nie po nim. Po pierwsze: regionalny punkt końcowy w chmurze partnerskiej, z dopłatą i z dostawcą chmury jako podmiotem przetwarzającym. Po drugie: interfejs pierwszej strony ze świadomie włączonym przechowywaniem, dla klas danych, przy których jest to do obrony. Po trzecie: dana klasa danych w ogóle nie dociera do tego modelu, ponieważ inny model albo instalacja lokalna przejmuje część widzącą wrażliwe pola. Trzecia droga jest badana zbyt rzadko, choć w systemach wiedzy i dokumentów bywa najczystsza.

Co się zmienia, a czego ten model nie dotyka

Uczciwie nazwane, zmienia się ograniczony, lecz cenny zbiór klas zadań. Analizy zbiorów, które dotąd rozbijały się o dzielenie materiału, stają się wykonalne w jednym przebiegu. Przebiegi agentów, które wcześniej rozpadały się na granicy kontekstu, pozostają spójne. A konstrukcje, które muszą bardzo często odczytywać tę samą podstawę, stają się ekonomiczne dzięki cenie odczytu z pamięci podręcznej, o ile montaż zapewnia współczynnik trafień. To trzy realne przesunięcia i dotyczą dokładnie tej pracy, która w doradztwie pojawia się inaczej jako mozół.

Równie uczciwie nazwane jest to, co pozostaje bez zmian. Możliwości modelu również mają granice: testy penetracyjne, generowanie exploitów, skanowanie oparte na plikach binarnych oraz zadania z badań biologicznych są kierowane do modeli Opus, a tryb szybki nie jest dostępny w Fable 5.1 (Anthropic, Anthropic).

Ważniejsze są jednak problemy, których nie tyka żaden model. Jakość danych pozostaje Państwa zadaniem: większe okno tylko dokładniej odczyta sprzeczne dane podstawowe. Definicja procesów pozostaje Państwa zadaniem: agent, który nie wie, kiedy sprawa jest rozstrzygnięta, odwzorowuje tylko niejasność, która wcześniej panowała w zespole. Uprawnienia pozostają Państwa zadaniem: model, który może widzieć wszystko, jest problemem ochrony danych z talentem językowym. Ewaluacja pozostaje Państwa zadaniem, bo bez zestawu przypadków ze znaną poprawną odpowiedzią nikt nie powie, czy zmiana cokolwiek poprawiła. A koszt pomyłki zostaje tam, gdzie był: na liście propozycji błąd jest irytujący, na wystawionej fakturze jest kosztowny. To rozróżnienie decyduje o stopniu automatyzacji i jest pytaniem biznesowym.

Nasze stanowisko jest bez emfazy: Fable 5.1 przesuwa granicę tego, co dana konstrukcja udźwignie, i przesuwa ją w miejscu, które w praktyce naprawdę hamowało. Nie przesuwa ani jednego z pytań, które trzeba rozstrzygnąć wcześniej. Które z tych pytań pozostaje otwarte w Państwa najbliższym przedsięwzięciu?

Ten tekst czyta premierę tak, jak powinna ją czytać firma, która właśnie decyduje, czy na niej budować: które specyfikacje naprawdę się liczą, co w strukturze cen jest faktem, a co modelowanym szacunkiem, co psuje się na poziomie interfejsu i dlaczego europejska droga do tego modelu prowadzi przez chmurę partnerską, a nie przez Anthropic.

Co faktycznie opublikowano 1 września

Anthropic opublikował Claude Fable 5.1 w dniu 1 września 2026 roku, razem z Claude Mythos 5.1. Zgodnie z własnym opisem Anthropic oba są tym samym modelem o różnych poziomach zabezpieczeń: Fable 5.1 jest ogólnie dostępny, Mythos 5.1 wyłącznie na zaproszenie, poprzez programy zaufanego dostępu. Prasa branżowa potwierdza datę oraz dostępność na wszystkich platformach od dnia premiery.

Identyfikator modelu to claude-fable-5-1, a na Amazon Bedrock anthropic.claude-fable-5-1. Model dostarczany jest przez Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry oraz Claude Platform na AWS. Jako powierzchnie Anthropic wymienia Claude Code, Claude Enterprise i Claude Platform, z różnymi ustawieniami domyślnymi poziomu wysiłku: high w Claude Code oraz medium w Claude Cowork i na claude.ai. Istnieje zobowiązanie dotyczące wycofania: na platformach prowadzonych przez Anthropic model nie zostanie wyłączony wcześniej niż 1 września 2027 roku, natomiast Bedrock i Google Cloud wyznaczają własne terminy.

Na uwagę zasługuje to, co Anthropic dopisuje w tej samej dokumentacji. Fable 5.1 opisywany jest jako model do wymagającego wnioskowania i długodystansowej pracy agentowej; jako domyślny wybór dla większości obciążeń Anthropic nadal wyraźnie zaleca Claude Opus 5, a Fable 5.1 rezerwuje na przypadki, w których Opus 5 przy wysokim poziomie wysiłku nie wystarcza. Kto musi uzasadnić zmianę wewnątrz organizacji, powinien znać to zdanie: sam producent nie zaleca swojego nowego modelu flagowego w sposób ogólny.

Specyfikacje, na których opiera się decyzja

Dane podstawowe pochodzą z dokumentacji modeli Anthropic i dla decyzji architektonicznej ważą więcej niż jakikolwiek ranking.

Dwie pozycje zasługują na więcej niż wiersz tabeli. Po pierwsze tryb myślenia: Fable 5.1 myśli adaptacyjnie i nieprzerwanie, a starszy tryb ręczny z thinking.type: enabled i budget_tokens nie jest już przyjmowany. Kto przenosi istniejącą integrację, musi ruszyć to miejsce w kodzie.

Po drugie okno kontekstu. Milion tokenów odpowiada według Anthropic około 555 000 angielskich słów, mierzonych obecnym tokenizerem wprowadzonym wraz z Claude Opus 4.7. Ten sam tokenizer wytwarza dla tego samego tekstu około 30 procent więcej tokenów niż poprzedni. Liczba opisująca okno kontekstu nie jest zatem informacją o pojemności, którą można lekko porównywać między generacjami modeli, a tym bardziej między dostawcami. Dla planowania budżetu liczy się to, ile tokenów faktycznie generuje Państwa własny zasób tekstów, a nie nagłówek.

Wyniki wydajnościowe ten tekst świadomie traktuje skrótowo, ponieważ są przedmiotem osobnego artykułu porównawczego. Tylko tyle, i wyraźnie jako dane producenta: Anthropic podaje dla Fable 5.1 wynik 52,6 procent w Terminal-Bench-Science 0.1 wobec 24,7 procent dla Fable 5 oraz 55,8 procent w Terminal-Bench 4.0 wobec 42,0 procent. Kolumną porównawczą we własnej tabeli Anthropic jest GPT-5.6 Sol. Obecny model flagowy OpenAI, GPT-6 Astra, ukazał się dwa dni po tej premierze i w liczbach Anthropic w ogóle nie występuje.

Cena: zmienił się dokładnie jeden wiersz

Dokumentacja cenowa Anthropic podaje dla Fable 5.1 następujące wartości, w dolarach amerykańskich za milion tokenów.

Interesujący jest dokładnie jeden wiersz. W Fable 5.1 i Mythos 5.1 odczyty z pamięci podręcznej wyceniane są na 0,025-krotność ceny wejścia, podczas gdy w każdym innym modelu Claude obowiązuje mnożnik 0,1. To jedyna zmiana cenowa wobec Fable 5, którego odczyt z pamięci podręcznej kosztował 1,00 dolara amerykańskiego za milion tokenów. Wejście i wyjście pozostają bez zmian. Pełne okno kontekstu rozliczane jest według zwykłych stawek za token; dopłaty za długi kontekst nie ma.

Anthropic określa oszczędność na około 25 procent wobec Fable 5 dla typowych obciążeń i do około 45 procent dla pracy silnie agentowej. Ta liczba jest na tyle ważna, by przeczytać ją właściwie: to modelowany szacunek producenta, wynikający w całości z wiersza dotyczącego pamięci podręcznej, a nie obniżka cen. Kto wysyła zapytania rzadko odczytujące ponownie ten sam kontekst, nie oszczędza nic. Kto prowadzi pętlę agentową, która sto razy wczytuje ten sam prompt systemowy, tę samą bazę kodu i te same definicje narzędzi, oszczędza znacząco. Różnicą między tymi przypadkami jest współczynnik trafień pamięci podręcznej, a zna go wyłącznie Państwa własny profil obciążenia.

Jeszcze jeden szczegół do rachunku kosztów: jeśli inferencja zostanie przypisana do Stanów Zjednoczonych przez inference_geo: "us", obowiązuje mnożnik 1,1 dla wejścia, wyjścia, zapisu i odczytu pamięci podręcznej.

W otoczeniu konkurencyjnym ten wiersz jest jedyną realną różnicą cenową na szczycie. OpenAI również podaje dla gpt-6-astra 10 i 50 dolarów amerykańskich za milion tokenów wejścia i wyjścia, ale 1,00 dolara za wejście z pamięci podręcznej. Przy odczytach z pamięci podręcznej Fable 5.1 kosztuje więc jedną czwartą tego, co konkurent, co w długich pętlach agentowych może przesądzić o wyborze. Wszystko pozostałe w tym porównaniu, wraz z pytaniem, które liczby benchmarkowe są w ogóle porównywalne, znajduje się w osobnym tekście.

Co zmienia się w interfejsie i co przy tym pęka

Jako dowód długodystansowej autonomii Anthropic przywołuje jeden nienadzorowany przebieg trwający 38 godzin nad problemem uczenia maszynowego. Kto chce na tym budować, powinien jednak najpierw przeczytać listę zmian w interfejsie, ponieważ trzy z nich psują istniejący kod.

Zmiany łamiące zgodność wobec Fable 5:

• Wymuszone użycie narzędzi zwraca błąd.
• Wcześniejsze modele nie potrafią odczytać bloków myślenia Fable 5.1.
• Edycja wcześniejszych tur rozmowy unieważnia bloki myślenia.

Uzupełnienia:

• Poziom wysiłku ustawiany dla pojedynczej wiadomości (beta).
• Wiadomości systemowe obowiązujące w zakresie jednej tury (beta).
• Czytelne komunikaty o postępie między wywołaniami narzędzi przez display: "updates" (beta).
• Obniżona cena odczytów z pamięci podręcznej.
• Oznaczanie pochodzenia treści.

Dla architektur agentowych istotny jest też narzut tokenów zestawów narzędzi: computer_toolset_20260801 dokłada na zapytanie około 4500 tokenów wejściowych, a browser_toolset_20260801 około 6600. To obciążenie podstawowe występujące przy każdym pojedynczym zapytaniu i należy je uwzględnić w każdej kalkulacji kosztów. Tryb szybki, istniejący jako podgląd badawczy w Claude Opus 5 i Opus 4.8, dla Fable 5.1 nie jest dostępny.

Po stronie bezpieczeństwa Anthropic podaje, że zabezpieczenia w obszarze cyberbezpieczeństwa blokują o 60 procent mniej fałszywych alarmów niż wcześniej, a zabezpieczenia biologiczne uruchamiają się o 85 procent rzadziej przy nieszkodliwych pytaniach z zakresu biologii elementarnej. Jednocześnie całe klasy zadań pozostają wyłączone: testy penetracyjne, generowanie exploitów, skanowanie oparte na plikach binarnych oraz zadania badawcze z biologii są przekierowywane do modeli Opus. Fable 5.1 potrafi identyfikować podatności w oprogramowaniu, natomiast generowanie exploitów pozostaje zablokowane. Nowe konta API nie mogą ponadto ręcznie edytować wcześniejszego kontekstu w rozmowach wieloturowych; Anthropic uzasadnia to tym, że zamyka w ten sposób powszechną i publicznie udokumentowaną technikę destylacji. Dla zespołów, które programowo przepisują historie rozmów, jest to zmiana zachowania o bezpośrednich skutkach dla istniejących architektur.

Rezydencja danych: u samego Anthropic nie ma regionu UE

W tym miejscu historia inżynierska rozchodzi się z historią zarządczą. Dokumentacja Anthropic dotycząca rezydencji danych jest jednoznaczna: parametr inference_geo przyjmuje dokładnie dwie wartości, global i us. Wśród aktualnych ograniczeń napisano wprost, że dostępne są wyłącznie te dwie. Regionu inferencji w UE na własnym API Anthropic nie ma.

To samo dotyczy danych w spoczynku. Region workspace ustalany jest przy jego tworzeniu, później nie da się go zmienić, a jedyną dostępną wartością są Stany Zjednoczone.

Dwa źródła Anthropic zdają się tu sobie przeczyć i należy to powiedzieć otwarcie. Centrum pomocy dotyczące prywatności, ostatnio zaktualizowane 15 czerwca 2026 roku, podaje, że ruch klientów może być domyślnie kierowany do wybranych krajów w USA, Europie, Azji i Australii, i w tym samym tekście dodaje, że dane przechowywane są w USA. Dokumentacja platformy zna natomiast tylko dwa wymienione regiony inferencji. Pogodzenie tych zapisów leży w rozróżnieniu między trasowaniem a rezydencją: tryb global może przechodzić przez Europę, ale nie jest wybieralną gwarancją, że przetwarzanie i przechowywanie odbywają się w UE. Kto potrzebuje takiej gwarancji, tutaj jej nie znajdzie.

Sam parametr inference_geo istnieje dopiero od Claude 4.6; wcześniejsze modele odpowiadają błędem 400. Na Amazon Bedrock i Google Cloud go nie ma, tam region wyznacza punkt końcowy lub profil inferencji. Microsoft Foundry oferuje zamiast tego typ wdrożenia z amerykańską strefą danych. Parametr nie jest też dostępny przez punkt końcowy zgodny z SDK OpenAI.

Wykonalna droga europejska nie prowadzi zatem przez Anthropic, lecz przez chmurę partnerską. Bedrock i Google Cloud oferują regionalne punkty końcowe z gwarantowanym trasowaniem danych, według dokumentacji cenowej Anthropic z dopłatą 10 procent wobec punktów globalnych, i wyznaczają własne terminy cyklu życia. Czyni to również rozpowszechnione zdanie, że Claude ma rezydencję danych w UE, bo działa we Frankfurcie, w połowie prawdziwym i w efekcie mylącym: modele Claude mogą działać w regionach UE, ale podmiotem przetwarzającym jest tam dostawca chmury, a nie Anthropic. Dla konstrukcji umownej to właśnie jest cała różnica.

Covered Model: 30 dni przechowywania to warunek, nie opcja

Najbardziej niewygodne zdanie całej dokumentacji znajduje się na stronie Anthropic poświęconej API i przechowywaniu danych. Napisano tam o Claude Fable 5.1, Mythos 5.1, Fable 5 i Mythos 5, że modele te wymagają 30-dniowego przechowywania danych i nie są dostępne w trybie zero data retention, o ile Anthropic wyraźnie na to nie zezwoli. Zostały sklasyfikowane jako Covered Models.

W praktyce oznacza to, że organizacja pracująca dziś w trybie zero data retention nie może po prostu włączyć Fable 5.1. Musi wyraźnie aktywować 30-dniowe przechowywanie dla konkretnego workspace, w przeciwnym razie API odpowiada komunikatem 400 invalid_request_error. To nie subtelność konfiguracyjna, lecz decyzja, która w wielu firmach musi przejść przez zgodę działu ochrony danych, zanim powstanie pierwsza linia kodu integracyjnego.

Dla pełności obrazu obok tego stoją zobowiązania Anthropic: przechowywane dane, według własnych słów firmy, nigdy nie są wykorzystywane do trenowania modeli bez wyraźnej zgody, a treść rozmów nie jest domyślnie przechowywana poza wyjątkiem dotyczącym Covered Models.

Także ten, kto już wdrożył zero data retention, powinien znać granice tego trybu, węższe, niż sugeruje nazwa.

• ZDR aktywowany jest dla pojedynczej organizacji na wniosek złożony przez dział sprzedaży i nie przenosi się automatycznie na organizacje siostrzane w ramach tego samego konta.
• Nie obejmuje Batch API, Files API, wykonywania kodu, Claude for Excel ani interfejsów produktowych Claude Teams i Claude Enterprise. Claude Code przez Claude Enterprise z ZDR jest wskazanym wyjątkiem.
• CORS nie jest wspierany dla organizacji z ZDR.
• Jeśli czat lub sesja zostaną oznaczone, Anthropic może przechowywać dane wejściowe i wyjściowe do dwóch lat, również w trybie ZDR.

Kierunek jest zatem jednoznaczny i biegnie wbrew historii cenowej. Fable 5.1 jest w pętli agentowej tańszy niż każdy inny model Claude, a przy surowych regułach danych w UE jednocześnie trudniejszy do wdrożenia niż modele Claude, których na tej liście nie ma.

Artykuł 50: znak wodny od pierwszego dnia, z zastrzeżeniem samego Anthropic

Według Anthropic Fable 5.1 i Mythos 5.1 niosą niewidoczny znak wodny w tekście od dnia premiery. Artykuł 50 unijnego aktu o sztucznej inteligencji, który wymaga maszynowo czytelnego oznaczania treści syntetycznych, obowiązuje od 2 sierpnia 2026 roku. Anthropic stosuje oznaczenie na całym świecie, a nie tylko w UE.

Kto chce wbudować znak wodny w proces kontroli, powinien znać zastrzeżenie samego Anthropic, wyrażone wprost w centrum pomocy: wykryty znak wskazuje, że treść mogła zostać przetworzona przez Claude, jest "not fully conclusive" i sam w sobie nie potwierdza pełnego pochodzenia treści. Nie jest to zatem dowód w sensie prawnym, a oczekiwanie, że da się w ten sposób ustalić autorstwo, wykracza poza to, co twierdzi sam producent. Układ jest godny uwagi: oznaczanie jest realną cechą modelu, a jego moc dowodową relatywizuje ta sama firma, która je oferuje.

Dochodzi do tego kwestia dostępu. Interfejs wykrywania znajduje się w prywatnym podglądzie i jest otwarty wyłącznie dla uprawnionych organizacji; wymieniane są organy regulacyjne, organy ścigania, media, weryfikatorzy faktów, badacze, instytucje edukacyjne oraz organizacje społeczeństwa obywatelskiego w UE. Firma, która chciałaby sama sprawdzać napływające teksty, tą drogą obecnie tego nie zrobi.

Otaczające ramy regulacyjne, tak jak opisują je publikujące je instytucje: egzekwowanie wobec modeli AI ogólnego przeznaczenia trwa również od 2 sierpnia 2026 roku, z karami do 15 milionów euro lub 3 procent światowego rocznego obrotu dla niezgodnych dostawców takich modeli, niezależnie od tego, czy podpisali kodeks postępowania. Kodeks postępowania Komisji Europejskiej zobowiązuje sygnatariuszy do opublikowanego formularza przejrzystości, metodyki oceny ryzyk systemowych oraz ram zgodności z prawem autorskim, z przechowywaniem dokumentacji przez co najmniej dziesięć lat. Obowiązki te spoczywają na dostawcach modeli. To, co z nich wynika dla Państwa własnej organizacji, zależy od Państwa roli w łańcuchu dostaw i jest pytaniem do doradców prawnych, a nie do artykułu branżowego.

Co to oznacza dla decyzji podejmowanej w Niemczech

Razem wzięta premiera daje wyjątkowo klarowny obraz właśnie dlatego, że obie historie prowadzą w przeciwne strony. Technicznie Fable 5.1 jest tańszym wyborem do długich pętli agentowych, w których wciąż na nowo odczytywany jest ten sam kontekst. Regulacyjnie jest to model, którego bez 30-dniowego przechowywania w ogóle nie da się uruchomić.

Dlatego przed rozpoczęciem integracji powinny zostać rozstrzygnięte cztery pytania.

1. Jaki naprawdę jest Państwa współczynnik trafień pamięci podręcznej? Cała oszczędność zależy od tego jednego wskaźnika. Proszę zmierzyć go na realnym profilu obciążenia, zanim wpiszą Państwo do budżetu 25 procent.
2. Czy Państwa zgoda w zakresie ochrony danych zniesie 30-dniowe przechowywanie? Jeśli nie, Fable 5.1 nie jest opcją do czasu wyraźnej zgody Anthropic, a pytania tego nie da się obejść technicznie.
3. Przez który punkt końcowy przebiega inferencja? Jeśli wymagane jest przetwarzanie w UE, droga prowadzi przez Bedrock lub Google Cloud, z dopłatą 10 procent wobec punktów globalnych, z dostawcą chmury jako podmiotem przetwarzającym i z jego własnymi terminami cyklu życia.
4. Czy wystarczy Opus 5? Sam Anthropic zaleca Opus 5 jako wybór domyślny, a Opus 5 nie figuruje na liście Covered Models. Część opisanych tu pytań zarządczych w tej formie tam nie powstaje.

Nic z tego nie jest argumentem przeciwko Anthropic. Fable 5.1 to mocny model, zmiana w pamięci podręcznej jest realną poprawą dla pracy agentowej, a to, że niewygodne fakty da się czysto odczytać we własnej dokumentacji Anthropic, przemawia raczej za dostawcą niż przeciw niemu. To argument za odwróceniem kolejności: najpierw ustalić, na jakich warunkach wolno przetwarzać Państwa dane, a dopiero potem wybrać model. Czym Fable 5.1 wykazuje się w codziennej pracy, opisuje osobny tekst o możliwościach w praktyce; jak wypada w bezpośrednim zestawieniu z GPT-6 Astra, kolejny.

Tabela, którą publikują niemal wszyscy, jest wadliwa

Najczęstsze zdanie w bieżących doniesieniach brzmi mniej więcej tak: własne benchmarki Anthropic miałyby stawiać Claude Fable 5.1 przed GPT-6 Astra. To zdanie jest fałszywe i obala je zwykły kalendarz.

Anthropic opublikował swoją tabelę benchmarków 1 września 2026 roku. Kolumna porównawcza nosi w niej oznaczenie GPT-5.6 Sol. GPT-6 Astra trafił 3 września do ograniczonej wersji zapoznawczej, a 4 września do ogólnej dostępności. Anthropic nie tylko więc nie zmierzył Astry, ale nie mógł jej zmierzyć: model nie był publiczny w dniu publikacji.

Kto czyta wiersz Terminal-Bench 4.0, w którym 55,8% dla Fable 5.1 stoi naprzeciw 37,3%, i bierze te 37,3% za Astrę, porównuje aktualny model Anthropic z poprzednikiem konkurenta. To nie błąd zaokrąglenia, lecz zupełnie inne twierdzenie. I właśnie ta błędna interpretacja rozprzestrzenia się dziś najszybciej w agregatorach i streszczeniach.

Wartość tego tekstu tkwi zatem mniej w liczbach, a bardziej w segregacji: które porównania się bronią, które nie i po czym rozpoznać różnicę.

Co naprawdę porównuje się jeden do jednego

Zostaje niewielki, ale czysty rdzeń. Wszystkie wiersze poniższej tabeli pochodzą z dokumentacji modelu Anthropic, ze strony cenowej Anthropic oraz z dokumentacji deweloperskiej OpenAI dla gpt-6-astra, pobranych 10 września 2026 roku. To oświadczenia każdego dostawcy o własnym produkcie, w tej samej jednostce, bez ram pomiarowych pośrodku.

Do wiersza o zapisie pamięci podręcznej należy zastrzeżenie: Anthropic sprzedaje dwa czasy przechowywania, pięć minut i godzinę, natomiast OpenAI nie publikuje odpowiadającego progu. Obie kwoty 12,50 USD są sobie bliskie, ale nie w pełni równoległe.

Ekonomicznie interesujący jest wiersz odczytu pamięci podręcznej. Czterokrotna różnica na korzyść Anthropic brzmi jak pozycja poboczna, lecz w pracy agentowej nią nie jest: ten sam kontekst, repozytorium, instrukcja systemowa i opisy narzędzi są tam odczytywane raz za razem przez setki kroków. Anthropic sam wycenia wynikającą z tego oszczędność na około 25% wobec Fable 5 przy typowych obciążeniach i do około 45% przy obciążeniach silnie agentowych. Ta liczba to wyliczenie modelowe dostawcy, a nie obniżka cen: ceny katalogowe wejścia i wyjścia są niezmienione, a obciążenie z niewielką liczbą trafień w pamięć podręczną nie oszczędza praktycznie nic.

Do każdej kalkulacji należą jeszcze dwie pozycje. Batch API Anthropic zmniejsza o połowę oba kierunki, do 5 USD za wejście i 25 USD za wyjście na milion tokenów. A przypięcie wnioskowania do Stanów Zjednoczonych po stronie Anthropic oznacza, zgodnie z dokumentacją Anthropic dotyczącą lokalizacji danych, mnożnik 1,1 dla wejścia, wyjścia, zapisów i odczytów pamięci podręcznej.

Terminal-Bench 4.0: jedyna liczba z prawdziwą kontrolą krzyżową

Jeden wiersz benchmarku zasługuje tu na szczególne zaufanie, z powodu, który rzadko bywa wyjaśniany.

1 września 2026 roku Anthropic podaje dla Claude Fable 5.1 na Terminal-Bench 4.0 wynik 55,8%. W wynikach raportowanych przez OpenAI dla GPT-6 Astra, przekazanych 3 września 2026 roku przez DataCamp i tam wyraźnie oznaczonych jako dane dostawcy, Astra osiąga 57,7%, a Fable 5.1 figuruje z niezmienionym wynikiem 55,8%.

Obaj dostawcy dochodzą zatem niezależnie do tej samej liczby dla modelu drugiej strony. To najmocniejsza pojedyncza kontrola dostępna w całym tym porównaniu. Dostawca ma niewielki interes w zawyżaniu konkurenta, a gdy dwie strony o przeciwnych interesach podają tę samą liczbę, przemawia to za tym, że liczba przeżywa konfigurację, zamiast być pomiarem domowym.

Mimo to pozostają dwa ograniczenia. Po pierwsze, żadna z publikacji nie podaje, jakiego harnessu, jakiego scaffoldu i jakiego poziomu wysiłku użyto. Po drugie, różnica 1,9 punktu procentowego jest na tyle mała, że mogłaby pochodzić dokładnie z tych czynników. Broniąca się interpretacja brzmi więc: na Terminal-Bench 4.0 oba modele leżą blisko siebie według danych obu dostawców, z niewielką przewagą Astry wedle pomiaru OpenAI.

Co nie jest porównywalne i dlaczego

Większa część opublikowanych liczb nie należy do wspólnej tabeli. To nie formalizm, lecz różnica między podstawą decyzji a ścianą cyfr.

• OSWorld 2.0. Anthropic podaje dla Fable 5.1 dwie wartości, 77,9% z punktami częściowymi i 41,7% przy ocenie ścisłej. Po stronie OpenAI figuruje dla Astry pojedyncza wartość 72,6%, bez wskazania trybu oceny. Zestawienie 72,6 z 77,9 jest tak samo bezpodstawne jak zestawienie z 41,7. Dopóki tryb oceny się nie zgadza, nie ma tu porównania, jest tylko wybór.
• Okno kontekstu. Anthropic podaje 1 000 000 tokenów, OpenAI 1 050 000 przy maksymalnym wejściu 922 000 tokenów. Te liczby nie są miarą pojemności w tej samej skali, bo token znaczy co innego w zależności od tokenizatora. Anthropic sam pisze, że jego obecny tokenizator wytwarza dla tego samego tekstu około 30% więcej tokenów niż jego własny poprzedni. Publicznie nie istnieje żadna międzydostawcza dana o liczbie tokenów na słowo, więc pytanie, który model mieści więcej tekstu, nie da się rozstrzygnąć na podstawie źródeł otwartych.
• AutomationBench. Anthropic publikuje 31,4% dla Fable 5.1. We własnym wpisie ogłoszeniowym OpenAI rości sobie pierwsze miejsce na tym samym benchmarku, ale nie podaje tam żadnej liczby. Po prostu nie ma czego porównywać.
• Wiersze, w których liczba dla Claude nie pochodzi od Anthropic. Dla ScreenSpot-Pro, FrontierMath Tier 4 v2, ExploitBench, ARC-AGI-3, GPQA Diamond i FrontierCode 1.1 istnieją wyłącznie wartości ze strony OpenAI. Liczba dla Claude w tych wierszach to pomiar Claude wykonany przez OpenAI, a w kilku przypadkach pomiar Claude Fable 5 lub Claude Opus 5, nie Fable 5.1. Przypisanie ich Anthropic oznacza cytowanie niewłaściwego źródła, a częściowo także niewłaściwego modelu.
• Poziomy wysiłku. Obaj dostawcy dopuszczają różną moc obliczeniową na zapytanie. U Anthropic już domyślne ustawienie różni się zależnie od powierzchni: high w Claude Code, medium w claude.ai i Claude Cowork. Artificial Analysis mierzy na poziomach „max” i „xhigh”. Liczba benchmarkowa bez podanego poziomu wysiłku nie jest porównywalna z liczbą uzyskaną na innym poziomie. To nie subtelność, lecz najbardziej prawdopodobna przyczyna tego, że ten sam ranking pokazuje trzy wyniki na trzech stronach.

Jeden przypadek szczególny wymaga ostrzeżenia: 99,9%, które krąży dla Astry na ARC-AGI-3, nosi w źródle dopisek „harness adaptera” i sąsiaduje z 7,8% dla poprzedniego modelu. Skok o około 92 punkty przy zmianie harnessu opisuje najpierw harness, a dopiero potem model. Ta liczba nie należy do żadnego nagłówka.

Rankingi zewnętrzne otwarcie sobie przeczą

Kto nie ufa liczbom dostawców, sięga po rankingi niezależne. W tym przypadku to nie pomaga, bo rankingi przeczą sobie nawzajem, i to przy jednym i tym samym indeksie.

Artificial Analysis we własnym artykule z 3 września 2026 roku podaje dla Intelligence Index: GPT-6 Astra 61, GPT-5.6 Sol 61, Claude Fable 5.1 66, przy czym ten ostatni na maksymalnym poziomie wysiłku z konfiguracją zapasową, która nie jest domyślnym ustawieniem API. BenchLM przedstawia ten sam indeks inaczej we wrześniu 2026 roku: GPT-5.6 Sol prowadzi z wynikiem 58,9%, a Fable 5.1 ma 53,7%. llm-stats, pobrane 10 września 2026 roku, podaje Fable 5.1 na 56,8, Astrę na 54,7 i Claude Opus 5 na 54,1.

Trzy źródła, jeden indeks, trzy kolejności. Nie mogą być wszystkie aktualne. Jako przyczyny wchodzą w grę różne daty pomiaru, różne ustawienia wysiłku oraz mieszanie punktów z procentami. Praktyczna konsekwencja jest prosta: wartość Intelligence Index bez podania serwisu, daty i poziomu wysiłku nie jest informacją. Artificial Analysis zresztą sam wskazuje na mieszane wyniki, w tym spadek o około 80 punktów Elo na GDPval-AA v2.

Pozostaje arena. Tam również nie ma czego szukać: ani Claude Fable 5.1, ani GPT-6 Astra nie ma sklasyfikowanej pozycji w LMArena w dostępnych tu migawkach z września 2026 roku, ponieważ Elo areny potrzebuje wolumenu głosów i opóźnia się o tygodnie wobec premier klasy frontier. Nawet gdyby te wartości istniały, byłyby niewłaściwym narzędziem dla tej decyzji. Ślepe porównanie parami mierzy postrzeganą jakość odpowiedzi na samodzielnie dobranych zapytaniach, silnie reaguje na formatowanie i rozwlekłość oraz mało mówi o pracy agentowej w długim horyzoncie. Dla agenta programistycznego albo platformy pracy wiedzy nie jest to miara, według której należy układać zakup.

FrontierCode 1.1: liczba, która działa przeciwko własnemu dostawcy

W tym porównaniu jest jeden wiersz, który waży więcej niż pozostałe, z powodu metodologicznego. Na FrontierCode 1.1 GPT-6 Astra stoi według własnych raportowanych wyników OpenAI na poziomie 53,3%, a więc za Claude Fable 5 z wynikiem 53,5%.

Dwa doprecyzowania są tu obowiązkowe. Wartość porównawcza dotyczy Claude Fable 5, a nie Fable 5.1, a Anthropic nie opublikował dla Fable 5.1 własnego wyniku na tym benchmarku. Różnica wynosi 0,2 punktu procentowego i mieści się w każdym prawdopodobnym rozrzucie pomiarowym.

Mimo to jest to najbardziej godny zaufania rodzaj liczby, jaki może zawierać ogłoszenie produktowe. Dostawca, który publikuje wiersz, gdzie jego nowy okręt flagowy przegrywa z cudzym modelem, nie ma w tym żadnego interesu marketingowego. Kto chce ocenić nośność tabeli benchmarków, powinien najpierw sprawdzić, czy takie wiersze w ogóle w niej występują. Tabela, w której publikujący ją dostawca wygrywa każdy pojedynczy wiersz, nie jest pomiarem, lecz wyborem.

Kierunek się odwraca: lokalizacja danych w UE i zero retencji

Do tego miejsca Anthropic prowadzi w cenie i ekonomii pamięci podręcznej, a w benchmarkach jest mniej więcej na równi. W zarządzaniu danymi obraz odwraca się całkowicie, a dla niemieckiej firmy to właśnie ta kolumna zmienia architekturę.

Po stronie Anthropic wynika to z własnej dokumentacji. Parametr inference_geo przyjmuje dokładnie dwie wartości, global i us, a jako region przechowywania obszaru roboczego można wybrać wyłącznie us, ustalony w chwili utworzenia. Strona retencji jest jeszcze wyraźniejsza: Anthropic oznacza Fable 5.1 i Mythos 5.1 (a także Fable 5 i Mythos 5) jako Covered Models, które wymagają 30-dniowego przechowywania danych i nie są dostępne w trybie zero retencji bez wyraźnego zezwolenia Anthropic. Organizacja objęta ZDR musi aktywnie włączyć 30-dniowe przechowywanie dla konkretnego obszaru roboczego, inaczej zapytanie zostaje odrzucone.

Po stronie OpenAI dokumentacja deweloperska dotycząca przetwarzania danych stwierdza, że Europa (EOG i Szwajcaria) obsługuje zarówno przechowywanie regionalne, jak i przetwarzanie regionalne przez eu.api.openai.com, konfigurowane na poziomie projektu, przy czym regiony poza Stanami Zjednoczonymi wymagają zgody na mechanizmy kontroli nadużyć oraz aneksu o zmodyfikowanej retencji. Ta sama strona wymienia punkty końcowe kwalifikujące się do ZDR, w tym /v1/chat/completions i /v1/responses, i wyraźnie wyklucza Assistants, Threads, Vector Stores, dostrajanie oraz Batches.

Precyzja jest tu ważniejsza niż gładkie sformułowanie: żadne znalezione źródło nie stwierdza wprost, że GPT-6 Astra kwalifikuje się do ZDR. Udokumentowane jest, że wymienione punkty końcowe obsługują ZDR i że dla gpt-6-astra nie opublikowano wyjątku specyficznego dla modelu. Brak ograniczenia nie jest jednak zezwoleniem. Kto opiera na tym architekturę, powinien uzyskać potwierdzenie umowne, zamiast wnioskować z luki w dokumentacji. U Anthropic sytuacja jest jednoznaczna w drugą stronę, bo wyjątek jest tam zapisany wprost.

Poprawki wymaga też często powtarzane zdanie: „Claude ma lokalizację danych w UE, bo działa na AWS we Frankfurcie”. To prawda dokładnie wtedy, gdy pobierają Państwo Claude przez chmurę partnerską, na przykład Amazon Bedrock lub Google Cloud, gdzie to dostawca chmury ustala region i jest podmiotem przetwarzającym. Dla własnego API Anthropic to nie obowiązuje. W kwestii gwarantowanego routingu regionalnego Anthropic sam odsyła do regionalnych punktów końcowych chmur partnerskich, z dopłatą 10% wobec punktów globalnych. Dla oceny zgodności z RODO ta różnica jest sednem sprawy, ponieważ przesądza, z kim zawierana jest umowa powierzenia przetwarzania.

Artykuł 50: różnica, którą da się udowodnić tylko w połowie

Od 2 sierpnia 2026 roku obowiązują wymogi przejrzystości z artykułu 50 rozporządzenia o AI, które nakazują maszynowo czytelne oznaczanie treści syntetycznych. Anthropic podaje, że Fable 5.1 i Mythos 5.1 od pierwszego dnia noszą niewidoczny znak wodny w tekście, i stosuje to oznaczanie na całym świecie, a nie tylko w UE. Na tyle, na ile sięgają dostępne źródła, jest to rzeczywista różnica.

Zdanie to potrzebuje jednak obu połówek. Nie znaleziono żadnego źródła mówiącego o tym, czy wyjście tekstowe GPT-6 Astra jest oznaczane. Udokumentowane podejście OpenAI do proweniencji, Content Credentials C2PA wraz z SynthID, dotyczy obrazu i dźwięku; dostępne strony nie mówią nic o tekście. Z tej luki nie wynika, że OpenAI nie oznacza tekstu. Dlatego tego nie twierdzimy. OpenAI publikuje osobno wskazówki dla klientów dotyczące rozporządzenia o AI.

Także znak wodny Anthropic niesie mniej, niż sugeruje samo pojęcie. Anthropic pisze we własnej pomocy, że wykryty znak wskazuje, iż treść mogła zostać przetworzona przez Claude, nie jest w pełni rozstrzygający i sam z siebie nie potwierdza pochodzenia treści. Odpowiednie API do wykrywania znajduje się ponadto w prywatnej wersji zapoznawczej dla wybranych organizacji. Jako element argumentacji zgodnościowej znak wodny jest przydatny; jako środek dowodowy nie.

Co to oznacza dla decyzji w Niemczech

Jeśli mają Państwo wynieść z tego porównania jedną regułę, niech będzie to ta: przy dwóch modelach klasy frontier, które w broniących się liczbach leżą blisko siebie i mają identyczne ceny katalogowe, wiersz benchmarku rzadko rozstrzyga. Różnica na Terminal-Bench 4.0 wynosi 1,9 punktu procentowego bez podanego harnessu. Na FrontierCode 1.1 to 0,2 punktu w drugą stronę, wobec starszego modelu Claude. Takie różnice przesuwają się przy kolejnym wydaniu i nie zmieniają żadnej architektury.

To, co zmienia architekturę, znajduje się w kolumnie zarządzania danymi. Organizacja zobowiązana do zera retencji nie może używać Claude Fable 5.1 przez własne API Anthropic bez wyraźnego zezwolenia, niezależnie od tego, jak dobry jest model. Organizacja wymagająca wnioskowania w UE znajdzie tę drogę u Anthropic wyłącznie przez chmurę partnerską, z odpowiednią dopłatą i innym podmiotem przetwarzającym w umowie. Odwrotnie, przewaga Anthropic w odczycie pamięci podręcznej jest realna i rośnie wraz z udziałem pracy agentowej, w której ten sam kontekst odczytywany jest setki razy.

W praktyce: proszę najpierw wyjaśnić wymogi, potem koszty, a benchmarki na końcu. W odwrotnej kolejności zbudują Państwo system, który dobrze mierzy i przegrywa w rozmowie o ochronie danych. I przy każdej liczbie, którą ktoś Państwu pokazuje, warto sprawdzić trzy rzeczy: kto ją zaraportował, kiedy i na jakim poziomie wysiłku.

Co samo wydanie zmieniło dla niemieckiej firmy, opisujemy w naszym tekście o Claude Fable 5.1. Jak model zachowuje się w bieżącej pracy projektowej, omawiamy w tekście o możliwościach w praktyce. A jeśli odpowiedzią na pytanie o zarządzanie danymi jest to, że dane w ogóle nie mogą opuścić firmy, droga prowadzi przez rozważenie wariantu on-premise wobec chmury, a nie przez ranking.

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.

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.

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.

CZEGO WIZUALNE WYSZUKIWANIE ŚWIADOMIE NIE DOSTARCZA

Modele wyszukiwania wizualnego znajdują właściwą stronę, nawet w trudnym skanie. Zwracają jednak obraz, nie tekst. Nie da się z niego bez trudu skopiować linijki, nałożyć na archiwum wyszukiwania pełnotekstowego ani zbudować maszynowo czytelnej ścieżki audytu. Do tego wszystkiego potrzebny jest rozpoznany tekst. Nie jest to słabość nowego podejścia, lecz świadomy podział pracy: wyszukiwanie na obrazie, ekstrakcja tekstu za pomocą OCR, każdy etap robi to, w czym jest najlepszy.

CO POTRAFI PADDLEOCR-VL

Baidu przedstawiło w PaddleOCR-VL otwarty model OCR, który przy zaledwie 0,9 miliarda parametrów osiąga czołowe wyniki (Projekt). Rozpoznaje tekst, tabele, wzory i diagramy w 109 językach oraz rekonstruuje semantyczną strukturę dokumentu. W benchmarku OmniDocBench v1.5 zajmuje pierwsze miejsce z dokładnością na poziomie około 94,5%. Działa na licencji Apache 2.0, a więc można go swobodnie wykorzystywać komercyjnie i uruchamiać lokalnie (on-premise). Dla firmy z sektora MŚP oznacza to: silne rozpoznawanie tekstu bez stałej opłaty i bez wycieku danych.

HYBRYDOWA ARCHITEKTURA

W praktyce obie ścieżki działają obok siebie. Wyszukiwanie wizualne szybko znajduje odpowiednie strony, zachowując wierność układu. Tam, gdzie z tego musi powstać twardy tekst, na przykład dla pozycji faktury, klauzuli umowy do zacytowania lub wpisu do systemu ERP, OCR przejmuje zadanie właśnie na tych nielicznych stronach. Nie trzeba przepuszczać przez OCR całego archiwum, a jedynie to, co wyszukiwanie już oznaczyło jako istotne. Dzięki temu pipeline pozostaje szczupły, a błędy OCR nie przenikają do wyszukiwania od samego początku.

PRAGMATYCZNA LINIA

Podejście albo-albo jest tu błędną postawą. Wyszukiwanie wizualne poprawia wyszukiwanie, OCR poprawia dalsze przetwarzanie. Kto traktuje oba jako narzędzia o jasno określonych zadaniach, buduje bardziej odporną bazę wiedzy niż ktoś, kto dogmatycznie stawia na jedną stronę. To, jak poszczególne elementy się łączą, od enkodera po bazę wektorową, opisano w przeglądzie stosu.

Dla przedsiębiorstwa z sektora MŚP, które codziennie przetwarza umowy, instrukcje techniczne i wielostronicowe faktury, to właśnie ta wiadomość jest ciekawsza. Nie chodzi o to, że rozpoznawanie tekstu jest o kilka punktów lepsze, lecz o to, że 80-stronicowy dokument nie musi już być cięty na fragmenty i ponownie składany, a przy tym żaden dokument nie musi opuszczać siedziby firmy.

CO UNLIMITED-OCR ROBI INACZEJ

Sercem rozwiązania jest zmieniony mechanizm uwagi w dekoderze, który utrzymuje pamięć na stałym poziomie. Klasyczne modele OCR oparte na transformerach pozwalają, by tak zwany KV-cache rósł wraz z długością dokumentu. Im dłuższy plik PDF, tym więcej pamięci, aż w końcu przestaje się on mieścić w jednym przebiegu przetwarzania.

Unlimited-OCR zastępuje ten element mechanizmem Reference Sliding Window Attention (R-SWA). Dzięki temu KV-cache pozostaje stały, niezależnie od długości dokumentu. Właśnie to oznacza pojęcie one-shot long-horizon parsing: długi dokument jest odczytywany w jednym przebiegu, zamiast być dzielony na fragmenty, których wyniki trzeba potem scalać.

Na uwagę zasługuje sposób trenowania modelu. Zespół nie zaczynał od zera, lecz doszkolił checkpoint DeepSeek-OCR: zamroził enkoder i dostroił jedynie dekoder w około 4.000 krokach. Model wpisuje się więc w prostą linię rozwoju DeepSeek-OCR, którą omówiliśmy już w kontekście całego stosu technologicznego. Kod i wagi modelu są dostępne publicznie na GitHubie.

DLACZEGO STAŁY KV-CACHE SIĘ LICZY

Prawdziwym problemem przy długich dokumentach nie jest pojedyncza strona, lecz zachowanie spójności między stronami. Gdy model dzieli 60-stronicowy dokument na bloki po dziesięć stron, ginie właśnie to, co liczy się w codziennej pracy B2B: tabela przechodząca przez podział strony, klauzula odnosząca się do wcześniejszego fragmentu, pozycja, której punkt odniesienia znajduje się dwadzieścia stron wcześniej.

Stały KV-cache pozwala utrzymać cały dokument w jednym kontekście. Pamięć nie rośnie wraz z długością, dzięki czemu struktura zostaje zachowana na wszystkich stronach. Przy okazji rośnie też szybkość: Baidu podaje w trybie base 5.580 tokenów na sekundę wobec 4.951 w przypadku DeepSeek-OCR, a przy limicie wyjściowym 6.000 tokenów różnica wynosi około 35 procent.

Pod względem dokładności Unlimited-OCR osiąga na OmniDocBench v1.5 wynik 93,23 punktu, czyli 6,22 więcej niż bazowy model DeepSeek-OCR, a na v1.6 wynik 93,92. To liczby pochodzące z publikacji naukowej. Na Państwa własnych dokumentach ostatecznie liczy się to, jak model radzi sobie z Państwa tabelami, pieczątkami i formularzami, a nie średnia z publicznego zestawu testowego. Pokrewny jest rozwój w obszarze subkwadratowych LLM, które czynią długi kontekst on-premise tańszym.

GDZIE TO COŚ ZMIENIA W SEKTORZE MŚP

Korzyść pojawia się tam, gdzie długie, ustrukturyzowane dokumenty trzeba zamienić w czyste, przeszukiwalne dane. Kilka konkretnych przykładów:

• Umowy i umowy ramowe. Odesłania i załączniki pozostają czytelne w kontekście, zamiast rozpadać się na granicach bloków.
• Instrukcje techniczne i normy. Długie dokumenty z rysunkami, tabelami i numerowanymi sekcjami przetwarzane w jednym przebiegu.
• Wielostronicowe faktury i dokumenty księgowe. Czysto wyekstrahowany tekst to wstępny etap ustrukturyzowanego dalszego przetwarzania, na przykład w kierunku e-faktury.
• Archiwa i akta. Zasoby, które dotąd istniały wyłącznie jako skany, stają się czytelne maszynowo, bez przekazywania ich do usługi chmurowej.

Niemal we wszystkich przypadkach OCR nie jest celem, lecz pierwszym krokiem. Czysto sparsowany tekst stanowi podstawę bazy wiedzy z RAG: im lepsze parsowanie, tym lepiej wyszukiwanie znajduje później właściwe miejsce.

OCR CZY WIZUALNE WYSZUKIWANIE DOKUMENTÓW?

Nie każde zadanie związane z dokumentami wymaga klasycznego rozpoznawania tekstu, i jest to uczciwy kompromis do rozważenia. Istnieje już cała gałąź podejść, które w ogóle nie zamieniają dokumentów na tekst, lecz przeszukują je jako obraz, za pomocą modeli takich jak ColPali czy ColQwen. To podejście bez OCR opisaliśmy osobno.

Reguła, która sprawdziła się u nas:

• Potrzebują Państwo faktycznych znaków (kwot na fakturach, klauzul umownych, ustrukturyzowanej ekstrakcji, przekazania do innego systemu): wtedy trudno obejść się bez OCR, a model taki jak Unlimited-OCR jest w tym mocny.
• Potrzebują Państwo odpowiedniego miejsca, a nie pełnego tekstu (odpowiedzi na pytanie dotyczące dużego zbioru, odnalezienia rysunku): wtedy wizualne wyszukiwanie dokumentów może być bardziej bezpośrednią drogą.

Często oba podejścia współistnieją. Unlimited-OCR sprawia, że część OCR tego stosu staje się tańsza i bardziej niezawodna przy długich dokumentach.

CO SPRAWDZIŁBYM PRZED WDROŻENIEM PRODUKCYJNYM

Dobry wynik w benchmarku to powód, by przetestować model, nie powód, by wdrożyć go produkcyjnie. Zanim wdrożyłbym Unlimited-OCR w procesie klienckim, sprawdziłbym cztery rzeczy:

🔸 Niemieckie dokumenty i pismo odręczne. Wyniki benchmarków niewiele mówią o niemieckich formularzach, starych aktach czy odręcznych notatkach. To wymaga własnego zestawu testowego złożonego z prawdziwych dokumentów.

🔸 Tabele i układ strony. W dokumentach B2B o użyteczności decyduje wierność odwzorowania tabel i kolumn. Tu opłaca się bezpośrednie porównanie z dotychczasowym stosem.

🔸 Sprzęt i eksploatacja. 3B jako MoE z około 500M aktywnymi parametrami jest realistyczne on-premise. To, co to konkretnie oznacza pod względem pamięci GPU i przepustowości, trzeba zmierzyć przed wdrożeniem, a nie oszacować.

🔸 Licencja i pochodzenie. MIT pozwala na komercyjne zastosowanie on-premise bez zastrzeżeń. To, że ślad modelu prowadzi do jednego z autorów DeepSeek-OCR, jest sygnałem jakości, ale nie zastępuje własnej weryfikacji.

Tym, co naprawdę mnie interesuje w tej publikacji, jest mniej sam model, a bardziej kierunek: długie dokumenty w jednym przebiegu, wystarczająco małe dla własnej serwerowni, na licencji, która nikogo nie ogranicza. Właśnie tam przetwarzanie dokumentów w sektorze MŚP staje się teraz praktyczne. Które z Państwa dokumentów przepuściliby Państwo przez to jako pierwsze?

POZA PROMPTEM

Prompt engineering dostraja pytanie. Context engineering kształtuje środowisko, w którym model podejmuje decyzje. Dla jednorazowego zadania wystarczy dobry prompt. Dla agenta, który działa przez wiele kroków, odczytuje narzędzia i niesie ze sobą pamięć, prompt to tylko niewielka część tego, co widzi model. Reszta, czyli to, co Państwo pobierają, co Państwo zapamiętują, jakie narzędzia i w jaki sposób Państwo udostępniają, to kontekst, i to on decyduje o wyniku w znacznie większym stopniu. Dlatego rozszerzanie agentycznego harnessu to w przeważającej mierze praca nad kontekstem.

CZTERY WZORCE AWARII, PRZED KTÓRYMI SIĘ PROJEKTUJE

Większość awarii agentów wynika z jednego z czterech problemów kontekstowych:

• Przeciążenie kontekstu. Zbyt wiele w oknie. Model gubi wątek, a koszty i opóźnienia rosną. Więcej kontekstu nie znaczy lepszego kontekstu.
• Zatrucie kontekstu. Do okna trafia błędny lub nieaktualny fakt, a model traktuje go jako prawdę. Jeden słaby pobrany fragment może wykoleić odpowiedź.
• Zarządzanie tokenami. Okno jest skończone. Bez planu, co zachować, a co odrzucić, ważny szczegół zostaje wyparty przez szum.
• Nieaktualna pamięć. Długo działające agenty gromadzą kontekst, który już nie obowiązuje, i działają na jego podstawie.

Nazwanie awarii to połowa rozwiązania. Każda z nich ma konkretny środek zaradczy.

PRAKTYKI, KTÓRE SIĘ SPRAWDZAJĄ

Kilka wzorców powraca w konfiguracjach, które pozostają niezawodne:

1. Pobierać, nie zwalać w całości. Proszę pozyskiwać nieliczne istotne fragmenty za pomocą dobrego retrieval, zamiast kopiować wszystko naraz. To cały sens RAG, czyli context engineering zastosowany do danych.
2. Przycinać na bieżąco. Proszę stosować w harnessie edycję opartą na regułach, aby okno pozostawało szczupłe: odrzucać to, czego dany krok już nie potrzebuje.
3. Podsumowywać długie historie. Proszę zastępować długi zapis wiernym podsumowaniem, zanim wyprze on zadanie.
4. Zaczynać prosto, skalować w razie potrzeby. Proszę dodawać pamięć i narzędzia tylko wtedy, gdy wymaga tego rzeczywista awaria, a nie domyślnie.

Instynkt dodawania kolejnych elementów to pułapka. Dyscyplina polega na pomijaniu.

DLACZEGO TO JEST PRAWDZIWY INŻYNIERING

Większy model rzadko rozwiązuje problem kontekstowy, po prostu zawodzi drożej. Praca, która przenosi agenta od demo do niezawodności, to niemal wyłącznie praca nad kontekstem: co on widzi, kiedy i co ma zapomnieć. Przy bardzo długich danych wejściowych liczy się także architektura modelu, i tu do gry wchodzą podejścia subkwadratowe, ale dla większości zespołów zysk tkwi w kontekście, a nie w parametrach.

MECHANIZM, W SKRÓCIE

Zwykły RAG osadza (embeduje) Państwa zapytanie, znajduje najbliższe fragmenty i na ich podstawie odpowiada. RAG-Fusion dodaje przed tym dwa kroki. Po pierwsze, model zapisuje garść alternatywnych zapytań, które oznaczają to samo z różnych perspektyw. Po drugie, wykonuje wyszukiwanie dla wszystkich i łączy uszeregowane listy metodą Reciprocal Rank Fusion, która nagradza fragmenty dobrze rankingowane w kilku zapytaniach, a nie tylko w jednym. Odpowiedź jest następnie pisana na podstawie tego połączonego, przeszeregowanego zbioru.

DLACZEGO KROK FUZJI SIĘ LICZY

Pojedyncze zapytanie to pojedyncza hipoteza co do tego, jak odpowiedź jest sformułowana w Państwa dokumentach. Prawdziwe archiwa używają synonimów, skrótów i różnych sformułowań dla tej samej rzeczy. Zadając pytanie wielokrotnie i nagradzając to, co konsekwentnie zajmuje wysokie miejsce, RAG-Fusion wydobywa na wierzch fragment, który pojedyncze sformułowanie by pominęło. Reciprocal Rank Fusion jest tu cichym koniem pociągowym: łączy listy bez potrzeby porównywalnych wyników (score), dlatego pojawia się także w architekturach hybrydowych i late-interaction, takich jak te stojące za Qdrant i ColQwen.

KIEDY POMAGA, A KIEDY SZKODZI

RAG-Fusion zarabia na swój koszt przy pytaniach niejednoznacznych lub obciążonych terminologią, gdzie jedno sformułowanie jest słabym zakładem. Kosztuje więcej: kilka wyszukiwań i jeden krok generowania na pytanie, więc nie jest to darmowe opóźnienie (latencja). Ma też realny wzorzec błędu. Jeśli wygenerowane warianty zapytania odbiegają od tego, co Państwo faktycznie mieli na myśli, wciągają fragmenty niezwiązane z tematem i odpowiedź zaczyna dryfować. Środkiem zaradczym jest trzymanie generowanych zapytań blisko pierwotnej intencji oraz mierzenie, a nie zakładanie, że recall wzrósł.

GDZIE PLASUJE SIĘ WŚRÓD OPCJI

RAG-Fusion to jeden z kilku sposobów na poprawienie retrievalu, a nie zamiennik dobrego retrievalu. Zanim Państwo po niego sięgną, proszę upewnić się, że podstawy są solidne: czyste chunki, solidny model embeddingowy i magazyn wektorowy dopasowany do zadania. Dla dokumentów gęstych wizualnie większą dźwignią jest często retrieval wizualny, a nie kolejne warianty zapytania. Proszę stosować F-RAG tam, gdzie pytanie jest naprawdę niejednoznaczne, a zysk w recall jest wart dodatkowych wywołań.

PROBLEMEM NIGDY NIE BYŁA ANIMACJA, LECZ PRZEKAZANIE PRACY

Dotychczas ruch w interfejsie powstawał poza Figmą. Projektantka budowała go w drugim narzędziu, eksportowała wideo lub opis, a zespół deweloperski musiał odtworzyć krzywe i czasy, często na oko. Przy tym ginie precyzja: krzywa wygładzania (easing) staje się przybliżonym pomysłem, a timing szacunkiem. To właśnie ten rozłam, a nie brak narzędzi do animacji, sprawił, że ruch w wielu produktach był niespójny.

CO KONKRETNIE DAJE FIGMA MOTION

Trzy rzeczy odczuwalnie zmieniają sposób pracy:

• Oś czasu w canvasie. Klatki kluczowe, presety i sterowanie ruchem znajdują się tam, gdzie projekt już żyje. Żadnego przełączania się do drugiego narzędzia.
• Ruch jako część systemu projektowego. Komponent jest animowany raz, a ruch wędruje jak kolor czy typografia przez każdy ekran i każdy plik. To właśnie ten punkt wymusza spójność, zamiast na nią liczyć.
• Czytelne przekazanie pracy. W Dev Mode widoczna jest cała oś czasu: każda wartość timingu, każda krzywa wygładzania, każda klatka kluczowa. Eksport odbywa się jako CSS, JSON lub gotowy do frameworka React, a także MP4, WebM, animowane SVG i GIF.

Dzięki temu zespół deweloperski czyta ruch, zamiast go interpretować. To jest właściwa zmiana.

GDZIE TKWI HACZYK

Zintegrowane narzędzie nie jest automatycznie właściwym wyborem do każdego przypadku. Złożona, narracyjna praca nad motion, na przykład rozbudowany film wizerunkowy marki, pozostaje domeną narzędzi specjalistycznych. Figma Motion celuje w animację interfejsu: stany, przejścia, mikrointerakcje, czyli dokładnie to, czego produkt potrzebuje na co dzień i co dotychczas cierpiało na rozłamie przy przekazaniu pracy. Dla tej klasy ruchu integracja jest zyskiem. Dla wszystkiego ponad to zestaw narzędzi pozostaje mieszany.

DLA KOGO WARTO SIĘ TEMU PRZYJRZEĆ

Najwięcej zyskuje ten, kto utrzymuje produkt z powtarzającymi się wzorcami UI: raz zdefiniowany ruch pozostaje spójny, a implementacja otrzymuje dokładne wartości zamiast przybliżeń. Ruch nie jest przy tym dekoracją, lecz częścią zrozumiałości interfejsu, co szerzej omawiamy w roli UX w budowie oprogramowania. Figma Motion sprawia wreszcie, że ta część jest edytowalna w jednym miejscu.

CZYM FAKTYCZNIE JEST GEMINI OMNI

Najpierw proszę nazwać to poprawnie, bo marketing to zaciera. Rodzina nazywa się Gemini Omni, a pierwszy model to Gemini Omni Flash. Przyjmuje jako wejście tekst, obraz, audio i wideo, a przy starcie generuje jedno wyjście: wideo, w klipach około 10-sekundowych z natywnie zsynchronizowanym dźwiękiem. Google opisuje go jako krok w stronę modelu świata, to znaczy, że próbuje utrzymać spójność fizyki, grawitacji i koherencji przestrzennej w wygenerowanej scenie, i działa na TPU 8. generacji Google, podzielonych na warianty treningowe i inferencyjne.

Uczciwa korekta liczy się dla technicznego czytelnika: Omni jest reklamowany jako any-to-any, ale w formie, w jakiej został wydany, jest to każde-wejście-do-wideo. Wyjścia w postaci obrazu i audio są na mapie drogowej, nie w produkcie. Nie jest to więc konwersacyjny asystent omni działający w czasie rzeczywistym, i nie jest to jeszcze uniwersalny system any-to-any, na który wskazuje nazwa. To bardzo zdolny, elastyczny co do wejścia generator wideo, co jest węższą i bardziej użyteczną rzeczą, wokół której można planować.

ZAPOWIEDZIANE, WYDANE I DOSTĘPNE TO TRZY RÓŻNE RZECZY

Najbardziej użyteczne rozróżnienie dla nabywcy polega na tym, że te trzy stany nie są tym samym, a Omni znajduje się w różnych z nich w zależności od tego, kim Państwo są. Jest wydany dla konsumentów i twórców, a dla wszystkich, którzy budują na API, jedynie zapowiedziany.

Praktyczna interpretacja dla firmy z UE jest prosta. Jeśli potrzebują Państwo dziś zgodnej z RODO rezydencji danych w UE dla generowania wideo, Omni nie może jej zapewnić, ponieważ jego ścieżka enterprise jeszcze nie istnieje. Wspieraną opcją na własnym stosie Google pozostaje Veo 3.1 na Vertex AI, który mogą Państwo przypisać do regionu UE. To ten sam wzorzec, który wciąż widzimy przy nowych premierach modeli, gdzie demo i produkt gotowy do wdrożenia dzieli wiele miesięcy.

CO NIEMIECKA FIRMA POWINNA TERAZ ZROBIĆ

Proszę traktować Omni jako sygnał do obserwowania, a nie narzędzie do wdrożenia w tym kwartale. Trzy konkretne kroki.

• Proszę już dziś korzystać z Veo 3.1 przypisanego do regionu do wideo produkcyjnego. Ma prawdziwe API Vertex, regiony UE i SLA. Omni nie ma na razie nic z tego, więc obecnie nie ma miejsca w pipeline produkcyjnym.
• Proszę zaplanować wcześnie historię pochodzenia treści. Omni osadza znak wodny SynthID w każdym klipie. Dla treści regulowanych lub publicznych proszę wbudować w swój proces oczekiwanie, że wideo wygenerowane przez AI jest oznaczone i możliwe do prześledzenia, niezależnie od tego, który model wygra.
• Proszę obserwować dwa ryzyka, nie tylko możliwości. Testerzy rozpoznawalnie odtworzyli chronione znakiem towarowym postacie w wynikach Omni, co stanowi realne ryzyko praw własności intelektualnej dla użytku komercyjnego, a spójność wizualna wciąż dryfuje przy szybkim ruchu. Limit 10 sekund to granica UX, a nie górny limit modelu, więc należy się spodziewać, że się przesunie.

Trwały punkt jest ten, który start czyni mimochodem: model, który można zobaczyć podczas keynote, nie jest modelem, który można wdrożyć na podstawie umowy. Należy rozdzielić te dwie rzeczy, a hype stanie się punktem na mapie drogowej zamiast błędem zakupowym.

TRZY PREMIERY, MÓWIĄC WPROST

Każdy z nich pojawił się w czerwcu 2026 roku w odstępie dwóch tygodni od pozostałych, i każdy jest zupełnie inną rzeczą. Warto o precyzję, bo dwa z nich są powszechnie opisywane błędnie.

GLM-5.2, od Z.ai z Pekinu, pojawił się 17 czerwca. To model Mixture-of-Experts z otwartymi wagami, około 750 miliardów parametrów z około 40 miliardami aktywnych, kontekst jednego miliona tokenów oraz, co kluczowe, licencja MIT z wagami opublikowanymi na HuggingFace.

Sakana Fugu, od Sakana AI z Tokio, pojawiła się 22 czerwca. To nie jest konwencjonalny model, a zwyczajowa klasyfikacja jest chybiona: Fugu to wytrenowany orkiestrator, który wywołuje pulę innych modeli i syntetyzuje ich pracę. Jest dostępny wyłącznie przez API, oferowany jako endpoint kompatybilny z OpenAI.

Claude Fable 5, od Anthropic ze Stanów Zjednoczonych, pojawił się 9 czerwca. Drugi częsty błąd to klasyfikowanie Fable jako szybkiego lub kreatywnego stopnia. To flagowy model, najbardziej zdolny szeroko wydany model Anthropic, sterowany bezpieczeństwem, dostępny wyłącznie w chmurze, w cenie 10 i 50 dolarów za milion tokenów. Jego wyniki benchmarków są mocne; dla tego artykułu są one jednocześnie drugorzędne.

JEDYNE PORÓWNANIE, KTÓRE PRZETRWA PROCES ZAKUPOWY

Pomińmy ranking i ułóżmy go według wymiarów, za które niemiecki nabywca B2B faktycznie odpowiada. Obraz jest jasny, i nie chodzi o to, który model jest najsprytniejszy.

Do tej tabeli należą dwa uczciwe zastrzeżenia. Domyślna ścieżka GLM-5.2, API Z.ai, podlega chińskim przepisom o danych z ich obowiązkowymi klauzulami dostępu, co jest właśnie powodem, dla którego liczą się otwarte wagi: self-hosting w UE neutralizuje to ryzyko. A twierdzenie Fugu o dorównaniu poziomowi frontier jest w całości deklaracją własną, osłabioną tym, że Fable i ograniczony model Mythos nie znajdują się nawet w jej puli. Nie oparłbym decyzji na żadnym z tych dwóch benchmarków dostawców.

CO FAKTYCZNIE MÓWIĘ KLIENTOWI

Nie polecam żadnego z nich w oderwaniu od kontekstu. Dopasowuję podejście do tego, co klient może sfinansować i za co odpowiada.

🔸 GLM-5.2 to pociąg on-premise. Otwarte wagi MIT to cała istota sprawy: mogą Państwo uruchomić go we własnym centrum danych, a prompty nigdy nie opuszczają Państwa sieci. Haczyk to zapotrzebowanie na GPU, około 744 gigabajtów w FP8, pasuje więc do klienta, który może sfinansować sprzęt i musi trzymać dane we własnej infrastrukturze. To najczystsza historia suwerenności z całej trójki.

🔸 Claude Fable 5 to pociąg zarządzanej pewności. Wynajmują Państwo zdolności od amerykańskiego dostawcy, w najwyższej cenie spośród trójki, z prawdziwą kontrolą bezpieczeństwa i regionalnym routingiem danych w dużych chmurach. Dla zespołu, który chce modelu klasy szczytowej bez posiadania stosu i może żyć z zależnością od chmury, to najsilniejsza zarządzana opcja.

🔸 Sakana Fugu to pociąg wygody, z najsłabszą historią kontroli. API, które kieruje zapytania przez pulę modeli, jest sprytne, a Japonia jest geopolitycznie łagodniejsza niż Chiny. Ale nie mogą Państwo uruchomić go on-premise, nie wybierają Państwo, który model widzi dane, a dowody są skąpe. Traktowałbym to jako coś interesującego, nie jako standard dla pracy regulowanej.

To ta sama lekcja, której Claude Fable 5 nauczył się na trudny sposób, gdy wcześniejszy model wyłączono w 72 godziny: wynajęta zdolność jest odwoływalna, a kontrola jest cechą stosu, nie wyniku. Dlatego stale wskazuję klientom na modele open-weight, które mogą faktycznie posiadać.

PYTANIE, WOKÓŁ KTÓREGO WARTO PROJEKTOWAĆ

Jeśli mają Państwo zapamiętać z tego jedno, niech to będzie pytanie, nie ranking. Modele w ciągu kwartału ponownie zamienią się miejscami w rankingu; to szum. Trwałe pytanie to takie, które osoba odpowiedzialna za zakupy powinna zadać pierwszego dnia: który z nich mogą Państwo nadal uruchamiać, kontrolować i opłacać, gdy dostawca zmieni warunki? Dla większości regulowanych klientów, z którymi pracuję, to pytanie odpowiada się samo, i nie wskazuje na najwyższy benchmark. Zanim więc wybiorą Państwo najsprytniejszy model: ile kosztowałaby Państwa jego utrata?

CO FAKTYCZNIE NADESZŁO W 2025 I 2026

Najważniejsza wiadomość to stabilność po latach przełomów. LangChain 1.0 i LangGraph 1.0 osiągnęły stabilne wydanie 22 października 2025 roku, z zobowiązaniem, że do wersji 2.0 nie wprowadzą żadnych zmian łamiących kompatybilność. Nowa główna abstrakcja frameworka, create_agent, działa teraz pod spodem na runtime LangGraph, więc pętla agenta jest w istocie grafem LangGraph. To najwyraźniejszy sygnał połączenia: framework i runtime orkiestracji nie są już osobnymi decyzjami.

LangGraph 1.0 wprowadził trwałe wykonywanie (durable execution) jako wbudowaną cechę: stan jest automatycznie zapisywany jako punkt kontrolny, dzięki czemu długo trwający lub wymagający udziału człowieka (human-in-the-loop) workflow wznawia się po przerwie lub restarcie serwera. LangSmith, warstwa obserwowalności i ewaluacji, uzupełnił w marcu 2026 roku pełne wsparcie OpenTelemetry, co oznacza, że mogą Państwo wysyłać ślady (traces) także z kodu, który w ogóle nie korzysta z LangChain. Obraz komercyjny pasował do technicznego: LangChain Inc pozyskał w październiku 2025 roku rundę Series B o wartości 125 milionów dolarów przy wycenie 1,25 miliarda i przemianował LangGraph Platform na LangSmith Deployment, dzięki czemu wdrożenie, obserwowalność i ewaluacja zostały złożone w jeden produkt.

CZTERY NAZWY, DWIE FIRMY

Ustalenie, kto co robi, jest najbardziej przydatne, zanim dokonają Państwo wyboru. Większość opisów to zaciera; trafne rozpoznanie zmienia decyzję.

LangFlow to coś, o co ludzie się potykają. To nie jest produkt LangChain Inc. To otwartoźródłowy wizualny kreator, stworzony przez DataStax, którego spółka macierzysta została przejęta przez IBM w lutym 2025 roku, i teraz kieruje się w stronę IBM watsonx. Podobieństwo nazw to przypadek. Jeśli Państwa wymaganiem jest płótno typu przeciągnij i upuść dla osób, które nie piszą w Pythonie, LangFlow jest kandydatem; nie jest jednak warstwą stosu LangChain.

DECYZJA, PRZED KTÓRĄ FAKTYCZNIE STOI WIĘKSZOŚĆ ZESPOŁÓW

Gdy nazwy są jasne, wybór to zazwyczaj krótkie drzewo decyzyjne, a rzadko potrzebują Państwo wszystkich czterech.

• Potrzebują Państwo długotrwałej orkiestracji? LangGraph jest najmocniejszym elementem i tym, który szanują nawet krytycy. Wznawialny stan, checkpointing i human-in-the-loop to prawdziwy inżynieryjny wysiłek, a nie wrapper.
• Potrzebują Państwo obserwowalności i ewaluacji? LangSmith jest zdolny, ale wiąże Państwa z ekosystemem. Langfuse to otwartoźródłowa, samodzielnie hostowalna przeciwwaga i najczęściej cytowana alternatywa. Ponieważ LangSmith mówi teraz w OpenTelemetry, mogą Państwo śledzić (tracing) kod spoza LangChain, co łagodzi efekt uzależnienia od dostawcy (lock-in).
• Budują Państwo prostego, nieskomplikowanego agenta? SDK dostawców (OpenAI Agents SDK, Claude Agent SDK) oraz Pydantic AI to wiarygodne, lżejsze alternatywy. Dominującym zarzutem praktyków są warstwy abstrakcji w frameworku, a kilka zespołów donosi, że po przejściu na szczuplejszy stos zmniejszyło ilość kodu i nakład na utrzymanie.
• Prototypowanie przez osoby spoza działu programistycznego? LangFlow, z zastrzeżeniem, że prototyp na płótnie przed wdrożeniem potrzebuje tego samego governance i tej samej ewaluacji.

To ta sama lekcja, którą wyciągnęliśmy przy porównaniu, jak podłączyć AI do stosu przez API, serwer MCP lub CLI: narzędzia to warstwy, a Państwo wybierają według zadania, nie nowości. Rymuje się to również z tym, co znaleźliśmy, przyglądając się kreatorom agentów no-code dla sektora MŚP, gdzie płótno szybko prowadzi do demo i kończy się dokładnie na governance, niezawodności i kosztach.

STABILNY NIE ZNACZYŁ UTWARDZONY

Jedno zastrzeżenie liczy się dla odbiorców biznesowych: wersja 1.0 kupiła stabilność API, a nie utwardzoną postawę bezpieczeństwa. Klaster CVE uderzył w LangChain i LangGraph pod koniec 2025 i na początku 2026 roku, na czele z błędem deserializacji, który mógł ujawnić klucze API i sekrety środowiskowe, oceniony na CVSS 9.3 i nazwany LangGrinch. Nastąpiły dwa kolejne: problem path traversal w API ładowania promptów oraz SQL injection w checkpointerze LangGraph opartym na SQLite.

Praktyczna lekcja nie polega na unikaniu frameworka. Polega na traktowaniu go jak każdej innej zależności, która dotyka Państwa sekretów i danych: ustalić wersje, wdrożyć załatane wydania i uwzględnić go w swoim modelu zagrożeń. Framework, który orkiestruje wywołania narzędzi i przechowuje dane uwierzytelniające, jest częścią Państwa powierzchni ataku, a "stabilny" przy numerze wersji niewiele o tym mówi. Dla wdrożenia regulowanego lub on-premise ta kontrola należy do tej samej rozmowy co rezydencja danych, a nie do etapu po uruchomieniu produkcyjnym (go-live).

PROBLEM Z JEDNYM WEKTOREM

Klasyczne wyszukiwanie wektorowe wciska cały fragment tekstu lub całą stronę w pojedynczy wektor. To oszczędne, ale uśrednia to, co jest ważne lokalnie. Jeśli szukana kwota znajduje się w konkretnej komórce tabeli, ten związek znika w średniej całej strony. Dla czystego tekstu ciągłego to często wystarcza. Dla dokumentów, dla których wyszukiwanie wizualne w ogóle powstało, to nie wystarcza.

LATE INTERACTION, W JEDNYM ZDANIU

Late Interaction zachowuje wiele wektorów na stronę i porównuje je późno, dopiero podczas wyszukiwania. Model generuje dla zapytania jeden wektor na token, a dla strony jeden wektor na wycinek. Ocena nazywa się MaxSim: dla każdego tokenu zapytania szukany jest najlepiej pasujący wycinek strony, a te najlepsze dopasowania są sumowane. Dzięki temu słowo "pozostała kwota" może precyzyjnie zadokować przy komórce tabeli, w której się znajduje. Technika pochodzi z ColBERT i została przeniesiona na obrazy w ColPali. Kto chce zobaczyć cały zestaw narzędzi, znajdzie go w tekście stos bez OCR, który porządkuje te modele.

GDZIE WKRACZA QDRANT

Late Interaction wymaga bazy danych, która rozumie wiele wektorów na obiekt. Qdrant obsługuje takie multi-wektory bezpośrednio, bez wstępnego czy końcowego przetwarzania, i może obsłużyć każdy model Late Interaction, taki jak ColBERT czy ColPali (dokumentacja). Typowa architektura jest dwuetapowa: szybkie pierwsze wyszukiwanie za pomocą zwykłych wektorów gęstych zawęża kandydatów, a następnie MaxSim precyzyjnie ocenia tylko te nieliczne strony. Dzięki temu indeks pozostaje przystępny cenowo, ponieważ drogie wektory tokenowe nie muszą być w pełni indeksowane, lecz służą do re-rankingu.

CO TO OZNACZA W PRAKTYCE

Otrzymują Państwo trafienia, które respektują układ strony, nie czyniąc wyszukiwania niedostępnym kosztowo. Ceną jest więcej pamięci na stronę i nieco więcej złożoności przy budowie. Oba są opanowalne, jeśli od początku zaplanuje się etap re-rankingu zamiast w pełni indeksować każdy wektor tokenowy. Dla bardzo długich kontekstów warto spojrzeć na modele subkwadratowe; dla podstawowej idei retrieval punktem wyjścia pozostaje Czym jest RAG.

DLACZEGO ROZMIAR STAJE SIĘ TU PRZESZKODĄ

Wizualne modele wyszukiwania, takie jak ColPali czy ColQwen, są bardzo trafne, ale są też duże. On-prem, czyli na własnym sprzęcie w firmie, szybko staje się to kwestią kosztów: duże modele wymagają mocnych GPU, więcej pamięci, więcej energii. Dla wielu wdrożeń w sektorze MŚP przeszkodą nie jest jakość, lecz rachunek za sprzęt. Właśnie tutaj mniejszy model daje przewagę.

CO MODERNVBERT ROBI INACZEJ

ModernVBERT to kompaktowy koder wizualno-językowy z 250 mln parametrów (artykuł). Łączy nowoczesny 150-milionowy koder tekstu oparty na ModernBERT z niewielkim koderem obrazu i dopasowuje oba komponenty za pomocą celu Masked Language Modeling. ColModernVBERT to wariant dostrojony do wyszukiwania. Wynik według artykułu: mimo około dziesięciokrotnie mniejszej liczby parametrów model osiąga wynik jedynie o 0,6 nDCG@5 niższy od ColPali w zagregowanym benchmarku ViDoRe, uzyskując tym samym wyniki, do których dotąd potrzebne były niemal dziesięciokrotnie większe modele. Model i kod są dostępne publicznie.

DLACZEGO TO SIĘ LICZY DLA SUWERENNOŚCI

Mały, otwarty i skuteczny model to właśnie kombinacja, która umożliwia lokalne działanie. Mieści się na skromnym GPU, wagi są dostępne publicznie, a dokumenty pozostają w firmie, ponieważ wyszukiwanie nie trafia do obcego punktu końcowego. To nie jest funkcja bezpieczeństwa dodana później, lecz cecha samej architektury. Szerszy kontekst tego, dlaczego lokalność i otwartość idą w parze, omawiamy w On-Premise kontra Cloud.

KIEDY MAŁY MODEL JEST WŁAŚCIWYM WYBOREM

Nie zawsze potrzebny jest największy model. Jeśli Państwa sprzęt jest ograniczony, a dokumenty to typowe dokumenty biznesowe, ColModernVBERT jest często uczciwszym wyborem niż ColQwen: niemal ta sama jakość, ułamek kosztów. Jeśli potrzebują Państwo ostatniej odrobiny trafności na szczególnie gęstych stronach, warto porównać z większym modelem. Jak oba modele współdziałają w pełnym stosie z Qdrant, opisujemy w przeglądzie.

Co czyni n8n silnym

n8n to oparta na węzłach automatyzacja przepływów pracy, self-hosted lub w chmurze, z ponad 400 integracjami oraz węzłem HTTP i węzłem kodu do wszystkiego innego (n8n). Kluczowy punkt dla branż regulowanych: działa we własnej infrastrukturze, dane jej nie opuszczają. Licencja Fair Code pozwala na wewnętrzne użytkowanie bez opłat. Ci, którzy potrzebują własnej logiki, własnych punktów końcowych i pełnej kontroli nad danymi, znajdą tu odpowiednie rozwiązanie. Ceną za to jest utrzymanie: hostują, aktualizują i zabezpieczają je Państwo samodzielnie.

Co czyni Make.com silnym

Make.com to usługa chmurowa z wizualnymi scenariuszami, która obywa się bez własnego utrzymania infrastruktury. Proces buduje się poprzez klikanie i od razu działa, bez serwera, bez konserwacji. Dla zespołów bez głębokiej wiedzy technicznej lub dla szybkiego pomysłu jest to krótsza droga. Rozliczenie następuje za operację, czyli za każdy wykonany krok. Przy małych wolumenach jest to korzystne cenowo, a przy dużych, częstych procesach koszty mogą nieprzyjemnie rosnąć. Druga strona tej wygody: dane przechodzą przez obcą usługę, a logika pozostaje w jej granicach.

Decyzja w jednej tabeli

Linia podziału jest jasna: kontrola danych i głębia funkcjonalna kontra szybkość bez własnego utrzymania.

Nasza pragmatyczna rada

Prototypują Państwo szybko, ale hostują świadomie. Do pierwszego testu, który ma jedynie pokazać, czy proces się sprawdza, Make.com jest zazwyczaj szybszy. Gdy w grę wchodzą wrażliwe dane, duże wolumeny lub własna logika, wygrywa n8n, ponieważ działa we własnej infrastrukturze. A tam, gdzie automatyzacja graniczy z prawdziwymi zadaniami AI, warto spojrzeć na agentów no-code i ich granice: automatyzacja i agent to nie to samo narzędzie.

Dlaczego OCR był najsłabszym ogniwem pipeline'u

OCR długo był punktem, w którym do odpowiedzi wkradały się ciche błędy. Klasyczna droga to łańcuch: zeskanować stronę, przekształcić przez OCR w tekst, pociąć na fragmenty, zwektoryzować, wyszukać. Każdy etap coś traci. Dwukolumnowa strona zostaje źle złożona, tabela rozpada się na bezładne liczby, wykres wypada całkowicie, bo nie jest tekstem. Z naszego doświadczenia wynika, że przy trudnych dokumentach większa część problemu z jakością tkwi nie w modelu językowym, lecz właśnie tutaj, w czytaniu. Visual retrieval działa dokładnie na tym etapie: pomija rozpoznawanie tekstu podczas wyszukiwania i pracuje na obrazie strony.

Cztery elementy składowe, krótko wyjaśnione

ColPali. Punkt odniesienia, zaprezentowany w lipcu 2024 roku (arXiv). Bazuje na modelu wizyjno-językowym PaliGemma i generuje około 1024 wektory fragmentów obrazu na stronę, każdy o 128 wymiarach. Zamiast wciskać stronę w pojedynczy wektor, zachowana zostaje granularność. Dopasowanie odbywa się przez Late Interaction, technikę przejętą z ColBERT, którą rozkładamy dokładniej tutaj.

ColQwen. Ten sam przepis, inna baza: ColQwen2.5 opiera się na Qwen2.5-VL zamiast PaliGemma i zazwyczaj prowadzi w benchmarku ViDoRe. Kto zaczyna dziś od nowa, sensownie zaczyna właśnie tutaj.

ModernVBERT. Dźwignia efektywności. ColModernVBERT ma 250M parametrów, czyli około dziesięciokrotnie mniej niż ColPali, a mimo to według artykułu ustępuje mu jedynie o 0,6 nDCG@5. To element składowy, który czyni visual retrieval opłacalnym on-premise.

Qdrant. Infrastruktura pod spodem. Qdrant przechowuje multi-wektory tych modeli natywnie i oblicza ocenę Late Interaction podczas wyszukiwania (dokumentacja). Bez bazy wektorowej, która rozumie wiele wektorów na stronę, żaden z trzech enkoderów nie działa.

Kiedy zmiana się opłaca, a kiedy nie

Visual retrieval wygrywa tam, gdzie informację niesie układ strony. Zeskanowane umowy, faktury, karty katalogowe, prezentacje, formularze, wielojęzyczne akta: wszystko, na czym łańcuch OCR regularnie zawodzi. Oszczędza to również całe utrzymanie tego łańcucha.

Nie jest to jednak zysk uniwersalny. Wiele wektorów na stronę kosztuje więcej pamięci i większy indeks niż pojedynczy wektor tekstowy, często wielokrotnie więcej. Przy czystym, jednolitym tekście ciągłym klasyczny RAG tekstowy pozostaje tańszy i w zupełności wystarczający. A niektóre zadania i tak potrzebują tekstu, na przykład wyszukiwanie pełnotekstowe, kopiowanie czy ślad audytowy. Dla tego wciąż istnieją dobre powody dla OCR, w hybrydzie obok visual retrieval.

Trzeźwy plan działania

1. Testować na własnych dokumentach, nie na benchmarku. ViDoRe to dobry punkt odniesienia, ale nie jest nim stan Państwa akt. Proszę wziąć dwadzieścia stron, na których dzisiejsze wyszukiwanie zawodzi.
2. Zacząć od ColQwen albo ColModernVBERT, zależnie od sprzętu. Przy skromnym GPU mniejszy model jest często uczciwszym wyborem.
3. Skonfigurować Qdrant jako magazyn multi-wektorowy, z Late Interaction tylko na etapie re-rankingu, aby utrzymać mały indeks.
4. Policzyć koszt pamięci z wyprzedzeniem. To rozmiar indeksu boli później, nie wybór modelu.

Kto szuka szerszej perspektywy, czyli dlaczego lokalne modele i własny retrieval w ogóle idą w parze: to jest opisane w On-premise kontra cloud. Poszczególne elementy składowe rozwijamy w osobnych tekstach, zaczynając od spojrzenia dla sektora MŚP.

Luka między siatką a częścią

Wygenerowana siatka i część nadająca się do produkcji to różne obiekty, a luka między nimi nie jest kosmetyczna. Trzy ograniczenia to potwierdzają. Po pierwsze, druk wymaga szczelnej, spójnej bryły (bez dziur, bez odwróconych normalnych, bez samoprzecięć), a siatki generatywne łamią to regularnie; slicer nie może zrobić części z powierzchni pełnej luk. Po drugie, siatka to statyczna zupa trójkątów, podczas gdy produkcja potrzebuje parametrycznego modelu B-Rep (pliku STEP ze szkicami, cechami i więzami), który inżynier może edytować, a system CAM obrabiać. Żadne z narzędzi obraz-do-siatki tego nie tworzy.

Po trzecie, i najbardziej fundamentalnie, pojedyncze zdjęcie nie niesie metrycznej skali. Model przypisuje zgadywaną pozycję kamery i tworzy kształt bez gwarantowanych milimetrów, bez wymuszonej grubości ścianki, bez tolerancji. A ponieważ zdjęcie pokazuje tylko jedną stronę, ukryta strona nie jest rekonstruowana, lecz wymyślana: model wypełnia niewidoczną geometrię prawdopodobną średnią. Asset do gry może to wszystko ukryć za ładną teksturą. Część fizyczna nie może, bo drukarce i obciążeniu jest obojętne, jak coś wygląda.

Dwa pipeline'y, które hype zaciera

Najjaśniej planuje się, rozdzielając dwa pipeline'y, które hype zaciera. Służą one różnym częściom i wymagają różnych narzędzi.

Pierwszy pipeline jest dziś realny dla części, w których pasowanie jest pobłażliwe. AI zarysowuje kształt; człowiek nadal odpowiada za uszczelnienie, przeskalowanie do rzeczywistych wymiarów i wykonanie sprawdzenia drukowalności. Drugi to miejsce, gdzie leży front istotny dla produkcji: badania nad obraz-do-CAD, takie jak CAD-Recode i Img2CAD, tworzą edytowalną geometrię parametryczną, a narzędzia komercyjne jak Zoo potrafią wyeksportować prawdziwy plik STEP, ale na razie są w dużej mierze ograniczone do prostszych części. Dla wymagającej geometrii klasyczny reverse engineering oparty na skanowaniu (Geomagic, PolyWorks) pozostaje niezawodną drogą. To produkcyjny odpowiednik pytania, które postawiliśmy przy okazji rekonstrukcji człowieka z pojedynczego zdjęcia: prawdopodobna powierzchnia to nie to samo co godna zaufania bryła.

Co jest dziś realne dla twórcy z sektora MŚP

W zestawieniu z hype'em, prawdziwe korzyści są cichsze i cenniejsze niż jednorazowa część z fotografii z telefonu. Najsilniejsza realna dźwignia to cyfryzacja tego, co Państwo już mają: narzędzia takie jak Theia od Spare Parts 3D oraz analiza rysunków 3YOURMIND zamieniają stare techniczne rysunki 2D w drukowalne modele części zamiennych, podawane jako nawet 200 razy szybsze niż ręczne przerysowywanie, wraz z dołączonym sprawdzeniem wykonalności. To obraz-do-3D, w którym dane wejściowe to rysunek techniczny, a nie wakacyjny zrzut ekranu, a geometria jest zakotwiczona w rzeczywistych wymiarach.

Pozostałe solidne korzyści to przyspieszenie reverse engineeringu, gdzie generowanie przez AI i inteligentna retopologia przyspieszają istniejący przebieg pracy oparty na skanowaniu, zamiast go zastępować, oraz szybkie prototypowanie części niekrytycznych. Tam, gdzie to podejście zawodzi, stawka jest najwyższa: części nośne, o wąskich tolerancjach i regulowane, które wymagają skali, specyfikacji materiałowej i identyfikowalności, jakich pojedyncze zdjęcie nie może dostarczyć. Zasada do zapamiętania jest krótka. Dla części, która utrzymuje ciężar lub przechodzi badanie, niewidoczna strona zawsze jest domysłem, a domysł to wada.

Rzeczywista różnica, w jednym zdaniu każda

Prompt engineering to dobre sformułowanie polecenia. Context engineering to decyzja, co model w ogóle zobaczy. Termin spopularyzował w czerwcu 2025 roku Tobi Lutke z Shopify, a wzmocnił go Andrej Karpathy, który opisał go jako sztukę wypełniania okna kontekstowego dokładnie tą informacją, która jest potrzebna do kolejnego kroku. Najczystsze rozróżnienie pochodzi od Philippa Schmida: kontekst to wszystko, co model widzi, zanim wygeneruje odpowiedź, a to jest system, nie ciąg znaków.

Te dwa podejścia nie są rywalami; prompt engineering jest podzbiorem. Gdy piszą Państwo dobry systemowy prompt, to jest prompt engineering. Gdy decydują Państwo, które trzy dokumenty zostaną pobrane, jakie narzędzia zostaną udostępnione, ile historii zachować, co odrzucić i jakiego schematu wyjściowego wymagać, wszystko w ramach budżetu tokenów, to jest context engineering. Własne wytyczne Anthropic ujmują to jako zarządzanie całym stanem kontekstu na przestrzeni kolejnych ruchów, a ich najostrzejsze zdanie warto zapamiętać: kontekst to skończony zasób o malejącej użyteczności krańcowej.

Dlaczego dziedzina się przesunęła, i to nie była moda

Powodem, dla którego context engineering stał się nazwaną dyscypliną, jest to, że wygodne założenie rozpadło się pod wpływem pomiarów. Założenie brzmiało: modele z długim kontekstem pozwalają wypełnić okno po brzegi i przestać myśleć. Badanie Context Rot od Chroma przetestowało w lipcu 2025 roku 18 wiodących modeli i wykazało, że każdy z nich degraduje się wraz ze wzrostem danych wejściowych, często w niejednolity sposób: model nie traktuje dziesięciotysięcznego tokenu tak samo wiarygodnie jak setnego. Wcześniejsze odkrycie Lost in the Middle wskazywało w tym samym kierunku.

Dwie siły sprawiły, że to ładunek, nie prompt, stał się tym, co należy inżynierować. Po pierwsze: agenci, użycie narzędzi, retrieval i pamięć oznaczają, że kontekst jest składany przez system na przestrzeni wielu ruchów, a nie pisany raz ręcznie. Po drugie ekonomia: w produkcji u Manus stosunek tokenów wejściowych do wyjściowych wynosi około 100 do 1, a ponowne wykorzystanie key-value cache napędza duże różnice w kosztach, więc to, co trafia do okna, jest w równym stopniu decyzją kosztową, co decyzją jakościową. Więcej kontekstu nie jest lepsze; lepszy jest kontekst zbudżetowany i istotny. To empiryczny fundament stojący za naszym wcześniejszym omówieniem context engineering i tego, dlaczego ma znaczenie.

Z czego faktycznie składa się context engineering

Uwolniony od etykiety, context engineering to zestaw testowalnych praktyk, a nie szeptanie do promptu. Nazwane techniki powtarzają się u Anthropic, w LangChain i w raporcie produkcyjnym Manus:

• Retrieval. Pobierają Państwo kilka istotnych dokumentów dokładnie w momencie, gdy są potrzebne, zamiast wklejać wszystko naraz. To dyscyplina stojąca za Retrieval-Augmented Generation.
• Kondensacja i podsumowanie. Kompresują Państwo dawne ruchy w bieżące podsumowanie, aby budżet był wydawany na to, co żywe, a nie na transkrypt.
• Pamięć i notatki. Wyprowadzają Państwo stan do zewnętrznych notatek lub plików, które agent może odczytać ponownie, zamiast dźwigać go w oknie.
• Kuratorstwo narzędzi. Utrzymują Państwo załadowanych od trzech do pięciu kluczowych narzędzi, a resztę pobierają dokładnie na czas. Załadowanie każdego narzędzia rozcieńcza sygnał i przerywa cache.
• Ustrukturyzowane wyjścia. Wymagają Państwo schematu, aby model wydawał tokeny na odpowiedź, a nie na formatującą prozę.
• Izolacja. Dzielą Państwo pracę między subagentów, aby każdy widział tylko kontekst, którego potrzebuje.

LangChain ujmuje ten sam zestaw jako pisanie, wybieranie, kompresowanie i izolowanie. Rzecz w tym, że każdy z tych elementów jest mierzalny: mogą Państwo przetestować A/B retriever, próg kondensacji czy wyposażenie w narzędzia, co dokładnie sprawia, że to inżynieria, a nie formułowanie.

Czy to tylko rebranding? Szczera odpowiedź

Częściowo, i to jest w porządku. Tak, dobrzy inżynierowie już wcześniej dbali o to, co widzi model; wartość tej nazwy polega na tym, że kieruje optymalizację na ładunek i system, a nie na zdanie, tam gdzie faktycznie mieszka niezawodność i koszty. Trwająca debata jest bardziej użyteczna niż spór o terminologię. W czerwcu 2025 roku Cognition argumentowało przeciwko systemom wieloagentowym, twierdząc, że trudno jest czysto dzielić kontekst między agentami, i zalecało utrzymywanie pracy pojedynczo oraz dzielenie się pełnymi śladami (trace). W tym samym tygodniu Anthropic opisał wieloagentowy system badawczy, który zależy od zdyscyplinowanej izolacji kontekstu. Ta sama dyscyplina, przeciwny wniosek architektoniczny.

Dla zespołu budującego z LLM-ami wnioski są proste. Budżetują Państwo tokeny tak, jak budżetuje się moc obliczeniową, ponieważ więcej nie jest za darmo i nie zawsze jest lepsze. Traktują Państwo tę pracę jako inżynierię przepływu (jakość retrievalu, kondensacja, pamięć, kuratorstwo narzędzi, ustrukturyzowane wyjścia), a nie jako formułowanie. I wybierają Państwo architekturę na podstawie tego, jak niezawodnie mogą Państwo dzielić kontekst, a nie na podstawie tego, które podejście brzmi bardziej zaawansowanie. Nazwa będzie dalej mutować, niektórzy już nazywają kolejną warstwę harness engineering, ale obiekt pozostaje stabilny: system, który decyduje, co dostanie do zobaczenia model.

Zacznij od podłogi, nie od sufitu

Zanim sięgną Państwo po jakąkolwiek sprytną metodę, uporządkują Państwo podstawy, ponieważ to one naprawiają większość skarg. Standard produkcyjny 2026 roku to wyszukiwanie hybrydowe (gęste embeddingi plus słowa kluczowe BM25), po którym następuje reranker typu cross-encoder. Wyszukiwanie hybrydowe wychwytuje zarówno trafienia semantyczne, jak i dokładne dopasowania terminów; reranker zawęża duży zbiór kandydatów do kilku fragmentów, które są faktycznie istotne, a nie tylko tematycznie bliskie. Przewodniki praktyków donoszą, że ta kombinacja podnosi jakość retrievalu na standardowych zbiorach ewaluacyjnych o 15 do 30 procent.

Ma to znaczenie, ponieważ większość rzeczywistych błędów jest prostego rodzaju: odpowiedź znajdowała się w dokumentach, ale system jej nie wydobył. To problem recall i rankingu, a podstawa opisana powyżej go rozwiązuje. Niech Państwo udowodnią, że potrzebują więcej, zanim zbudują więcej. Każda technika wykraczająca poza ten punkt dodaje wywołania LLM, opóźnienia i koszty, każda powinna zasłużyć na swoje miejsce w starciu ze zmierzoną awarią, a nie z przeczuciem.

Zestaw narzędzi, uporządkowany według awarii, którą naprawia

Użytecznym sposobem ogarnięcia całego zoo metod jest przypisanie każdej z nich do pojedynczego wzorca awarii, który adresuje. Sięgają Państwo po metodę, gdy widzą jej awarię, nie wcześniej.

Każdy wiersz ma prawdziwe pochodzenie: HyDE pochodzi z pracy CMU z 2022 roku o zero-shot dense retrieval; Step-Back Prompting od Google DeepMind, 2023; GraphRAG od Microsoft, 2024. To ta sama dyscyplina decydowania według awarii, która stoi za naszym spojrzeniem na RAG-Fusion i to, czym różni się od prostego RAG.

Dekompozycja zapytań, w szczególności

Dekompozycja zapytań dzieli złożone zapytanie na niezależne podpytania, pobiera dane dla każdego z nich, a następnie syntetyzuje odpowiedź. To właściwe narzędzie, gdy pojedynczy przebieg retrievalu nie może zadziałać, ponieważ fakty żyją w różnych dokumentach albo jeden fakt zależy od innego (kto wyreżyserował film, który zdobył określoną nagrodę). Linia biegnie od Least-to-Most Prompting z 2022 roku do dzisiejszych silników zapytań podrzędnych (sub-question query engines) we frameworkach.

Uczciwa część jest taka, że to nie jest darmowe i może zaszkodzić. Badanie HU Berlin z lipca 2025 roku zmierzyło, że dekompozycja plus reranking podniosły multi-hop recall (Hits@10) z 74,7 do 87,2 procent, co jest prawdziwym zyskiem. To samo badanie zmierzyło koszty: około 16,7 sekundy na zapytanie w porównaniu z 0,03 sekundy dla naiwnego retrievalu, i wykazało, że dekomponowanie już precyzyjnego zapytania wprowadza szum i pogarsza odpowiedź. Dekompozycja należy się więc naprawdę pytaniom multi-hop, a nie domyślnie każdemu zapytaniu. Sztuka polega na odróżnianiu jednych od drugich.

Dźwignia, która sama się zwraca, to routing

Jeśli mają Państwo wynieść z tego jedną operacyjną myśl, niech będzie nią routing. Najpierw klasyfikują Państwo zapytanie, a złożoność wydają tylko tam, gdzie na to zasługuje. Analiza z 2026 roku dotycząca routingu uwzględniającego koszty obniżyła rozliczane tokeny o 26 procent i medianę opóźnienia o 34 procent przy tej samej jakości odpowiedzi, kierując tylko około 18 procent zapytań do ciężkiego retrievalu, a 14 procent w ogóle bez retrievalu. Drogie metody pozostały zarezerwowane dla zapytań, które ich potrzebowały.

Dla niemieckiego zespołu z sektora MŚP jest to w równym stopniu kwestia governance i kosztów, co jakości. Mniej, ale uzasadnionych wywołań LLM oznacza przewidywalne wydatki, niższe opóźnienia i system, który mogą Państwo wytłumaczyć interesariuszowi zorientowanemu na zgodność: oto dlaczego to zapytanie poszło drogą kosztowną, a oto dlaczego tamto nie. Nadmiernie zinżynierowany retrieval jest nie tylko wolny, jest niewytłumaczalnym wydatkiem. Wyrafinowany system RAG 2026 roku to ten, który wie, kiedy nie używa żadnej ze swoich sztuczek.

Co RPA naprawdę robi dobrze

RPA jest oparte na regułach i deterministyczne. Opisuje ustalony proces, który za każdym razem przebiega tak samo: to samo wejście, ta sama ścieżka, ten sam wynik. Dla ustrukturyzowanego, stabilnego procesu, na przykład przenoszenia danych ze stałego formularza do systemu ERP, jest to dokładnie właściwe rozwiązanie. Jest sprawdzalne, powtarzalne i tanie w utrzymaniu. Słabość ujawnia się dopiero, gdy coś się zmieni: nowy układ pola, nieoczekiwane dane wejściowe, i sztywna reguła się łamie.

Co agenci AI robią lepiej

Agent AI wchodzi do gry tam, gdzie proces nie jest sztywny: niejednoznaczne dane wejściowe, swobodny język, decyzje wymagające kontekstu. Potrafi przeczytać nieustrukturyzowany e-mail i zrobić to, co właściwe, tam gdzie reguła RPA by skapitulowała. Cena jest taka, że nie jest deterministyczny: to samo wejście może dać dwa różne wyniki, i potrzebuje prowadzenia, barier ochronnych oraz kontroli. To, jak daleko sięgają agenci no-code i gdzie się kończą, omawiamy w innym miejscu.

Linia decyzyjna

Prosta heurystyka oddziela te przypadki:

• Stabilny i ustrukturyzowany (stały formularz, jasna reguła, wysoka powtarzalność): RPA. Niezawodność bije elastyczność.
• Niejednoznaczny i językowy (swobodne teksty, zmienne dane wejściowe, kwestie wymagające osądu): Agent. Elastyczność bije sztywność.
• Mieszany: często najlepsza odpowiedź. RPA wykonuje stałą część, agent przejmuje tylko miejsce, które naprawdę wymaga osądu.

Liczby rynkowe każą zachować trzeźwość: Gartner spodziewa się, że ponad 40 procent projektów agentowej AI zostanie porzuconych do końca 2027 roku. Wiele z nich dlatego, że zastosowano agenta tam, gdzie wystarczyłaby reguła.

Trzeźwa droga środka

Nie AI albo RPA, lecz właściwy poziom dla właściwej części. Najdroższym błędem jest powierzenie niezawodnego, dającego się ująć w reguły procesu niedeterministycznemu agentowi tylko dlatego, że AI brzmi nowocześniej. Niech Państwo zaczną od pytania o zadanie, nie o narzędzie. Gdzie AI naprawdę należy do stosu technologicznego i przez jaki interfejs, porządkuje API kontra MCP kontra CLI.

Co SAM 3D Body faktycznie robi

SAM 3D Body rekonstruuje siatkę całego ciała człowieka, łącznie z dłońmi i stopami, z pojedynczego zdjęcia i szacuje zarówno pozę, jak i kształt. Wprowadza nowy parametryczny format ciała, Momentum Human Rig (MHR), który oddziela szkielet od powierzchni tkanek miękkich, dzięki czemu rig i kształt ciała można rozpatrywać osobno. Podobnie jak reszta rodziny Segment Anything, model jest promptowalny: mogą Państwo przekazać punkty kluczowe 2D lub maski segmentacji, aby sterować wynikiem.

Szczegóły praktyczne liczą się dla każdego, kto chce go wdrożyć. Meta dostarczyła otwarte wagi w dwóch wariantach szkieletu (backbone), DINOv3-H+ z około 840M parametrów oraz ViT-H z około 631M, a do tego kod wnioskowania, dane treningowe i model MHR. Model zgłasza błąd siatki 3DPW (MPJPE) na poziomie 54,8 i już napędza działającą funkcję konsumencką, View in Room w Facebook Marketplace. Został wytrenowany na około 8 milionach zdjęć. To nie jest demo badawcze; od pierwszego dnia trafił do produktu.

Zysk B2B to pipeline, nie piksele

Strategiczny punkt dla niemieckiej lub unijnej firmy dotyczy tego, gdzie odbywają się obliczenia, a nie tego, jak sprytnie wygląda siatka. Zdjęcie ludzkiego ciała jest w świetle RODO wrażliwym danym osobowym. W momencie, gdy wysyłają Państwo zdjęcie klienta do zewnętrznego API rekonstrukcji, pojawia się umowa powierzenia przetwarzania danych, kwestia transferu danych i cena zaufania. Otwarte wagi eliminują ten krok: uruchamiają Państwo model we własnej sieci, a zdjęcie ciała nigdy jej nie opuszcza.

To przekształca kilka zastosowań z niewygodnych w możliwe do posiadania. Wirtualne przymierzanie i wizualizacja dopasowania, awatary AR i VR, analityka fitness i ruchu oraz previz do animacji lub produkcji wirtualnej, wszystko to może działać na infrastrukturze, którą Państwo kontrolują, przy tym samym UX, jaki oferowałoby hostowane API. To ta sama logika własnego pipeline'u, którą zastosowaliśmy przy tworzeniu zasobów 3D z jednego zdjęcia za pomocą TRELLIS: wartość to nie tylko model, to utrzymanie wrażliwych danych wejściowych po Państwa stronie muru. Licencję warto sprawdzić przed budową jako jedno z pierwszych: rig MHR jest potwierdzony jako liberalny komercyjnie, a wagi ciała pojawiają się na licencji SAM, więc proszę przeczytać rzeczywiste warunki dla swojego zastosowania.

Gdzie po cichu zawodzi

Właściwe dopasowanie przypadku użycia to cała sztuka, ponieważ rekonstrukcja z pojedynczego zdjęcia ma uczciwe ograniczenia, których żadna jakość modelu nie usunie. Niezależna analiza wykazała, że SAM 3D Body priorytetyzuje wiarygodną pozę ponad dokładność metryczną i przesuwa nietypowe ciała (skolioza, zmiany związane z wiekiem, ciąża) w stronę zdrowej średniej. To w porządku dla awatara, który ma wyglądać dobrze; jest to błędne dla pomiarów medycznych, ergonomicznych lub prawnych, gdzie właśnie odchylenie stanowi istotę sprawy.

Trzy kolejne ograniczenia, wokół których trzeba projektować. Pojedyncze zdjęcie nie może rozwiązać głębi ani prawdziwej skali, więc globalna pozycja i rzeczywiste wymiary są niedookreślonymi domysłami. Silne zasłonięcie, gdy większość ciała jest ukryta, wyraźnie pogarsza wynik. I działa to na pojedynczym zdjęciu, nie w czasie rzeczywistym: społeczność już ściga się, aby to naprawić za pomocą szybszych wariantów i środowisk uruchomieniowych C++, a wideo wymaga dodatkowej maszynerii dla stabilności czasowej. Zasada, która zapewnia bezpieczeństwo, jest prosta. Proszę dopasować przypadek użycia do tego, co wiarygodne (wizualizacja, przymierzanie, awatary), a nie do tego, co precyzyjne (pomiary, diagnoza, bezpieczeństwo). W tych granicach samodzielnie hostowany model 3D człowieka, chroniący prywatność, jest realną nową opcją w 2026 roku.

Gdzie klasyczny RAG zawodzi w sektorze MŚP

RAG zamienia Państwa dokumenty w przeszukiwalną wiedzę. Słabym punktem jest pierwszy etap: rozpoznawanie tekstu. Faktura od dostawcy z tabelą pozycji, dwukolumnowa umowa, zeskanowana karta danych z rysunkiem wymiarowym: OCR regularnie źle je składa. Tabela zamienia się w pustynię liczb, kolumny się mieszają, rysunek znika. Model dostaje wtedy już uszkodzony tekst i odpowiada odpowiednio do tego. Z naszego doświadczenia wynika, że przy prawdziwych aktach większa część błędów powstaje właśnie tutaj, na długo zanim model językowy w ogóle dochodzi do głosu.

Jak omija to wyszukiwanie wizualne

Modele wizualnego wyszukiwania pomijają rozpoznawanie tekstu podczas przeszukiwania. Rozbijają obraz strony na wiele małych fragmentów, osadzają każdy z nich i porównują zapytanie bezpośrednio z nimi. Dzięki temu zachowana zostaje informacja, że liczba znajduje się w komórce tabeli, a nie w tekście ciągłym. W czołówce są trzy nazwy: ColPali jako punkt odniesienia, ColQwen jako zwykle mocniejszy wariant oparty na Qwen, oraz ModernVBERT jako mały, nadający się do on-premise model. Cały zestaw narzędzi wraz z bazą wektorową porządkujemy w przeglądzie stacku. Dla praktycznego spojrzenia wystarczy: strona jest widziana, a nie zgadywana.

Szczerze o kosztach

Ten zysk nie jest darmowy. Wiele wektorów na stronę wymaga znacznie więcej pamięci indeksu niż pojedynczy wektor tekstowy. Przy archiwum złożonym z czystego, przejrzystego tekstu ciągłego klasyczny RAG tekstowy pozostaje tańszy i wystarczający. Wyszukiwanie wizualne opłaca się tam, gdzie informację niesie układ strony, a to w sektorze MŚP jest raczej regułą niż wyjątkiem. A w przypadkach, gdy ostatecznie i tak potrzebują Państwo przeszukiwalnego tekstu, na przykład do kopiowania lub jako ścieżkę audytu, OCR pozostaje sensowny, jako uzupełnienie, a nie zastępstwo.

Pierwszy krok jest mały

Nie trzeba do tego niczego dużego przebudowywać. Proszę wziąć dwadzieścia dokumentów, na których dzisiejsze wyszukiwanie zawodzi, i zadać dokładnie te pytania, które dziś dają błędne wyniki. Jeśli wyszukiwanie wizualne znajdzie wiersz tabeli, który zgubił OCR, mają Państwo swoją odpowiedź, na własnych aktach, nie na benchmarku. Piękno tego rozwiązania: cała konstrukcja działa lokalnie, dane pozostają w firmie. Dlaczego to liczy się przy wrażliwych dokumentach, opisujemy w On-Premise kontra Cloud.

Dlaczego łączenie było prawdziwym problemem

Tworzenie długiej sekwencji poprzez sklejanie krótkich klipów wprowadza dokładnie te artefakty, które czynią materiał bezużytecznym: widoczne szwy między segmentami, twarze postaci dryfujące między ujęciami, światło, które skacze. Dla wideo markowego lub produktowego ten dryf stanowi różnicę między użytecznym zasobem a oczywistym fałszerstwem. Długość w jednym przebiegu usuwa szew, dlatego 30 natywnych sekund to prawdziwy krok naprzód, a nie liczba dla efektu.

Co faktycznie zmienia wersja 2.5

Trzy rzeczy wyróżniają się dla zespołu, który faktycznie chciałby z tego korzystać:

• Natywne 30-sekundowe klipy. Jeden przebieg, bez łączenia, dzięki czemu spójność utrzymuje się przez cały czas trwania.
• Do 50 multimodalnych referencji. Obrazy, audio i wideo połączone w jednej generacji, około czterokrotnie więcej niż dwanaście w Seedance 2.0, co ma na celu utrzymanie stabilności postaci, produktu i stylu.
• Wspólna generacja audio-wideo. Obraz i dźwięk są przetwarzane razem w jednej przestrzeni latentnej zamiast być generowane osobno i synchronizowane później, co utrzymuje ruch i dźwięk w zgodzie.

Razem te elementy dążą do tego samego celu: spójności w czasie, tego, czego potrzebuje wideo biznesowe, a czego krótkie klipy nie mogły zapewnić.

Szczere zastrzeżenie

Jakość jest teraz łatwą częścią. Dla zastosowania biznesowego decydują trudne pytania: czy wolno Państwu wykorzystywać materiał komercyjnie, czyj wizerunek się w nim znajduje, dokąd trafiają dane, i czy wynik jest wystarczająco spójny, aby oprzeć na nim markę. Seedance 2.5 znajduje się w becie enterprise z publicznym startem planowanym na początek lipca, więc szczegóły licencji i pochodzenia to dokładnie to, co warto przeczytać przed podjęciem decyzji. Szersze pole i sposób wyboru między modelami opisujemy w naszym przeglądzie stanu wideo AI 2026.

Gdzie się sprawdza

W przypadku storyboardów, filmów koncepcyjnych i krótkich zasobów na social media czysty natywny 30-sekundowy klip zmienia to, co może wyprodukować jedna osoba. W przypadku pracy regulowanej lub krytycznej dla marki proszę traktować to jako silnik koncepcyjny, dopóki prawa i spójność nie osiągną wymaganego poziomu. Możliwości są realne; ład (governance) to część, którą trzeba najpierw dopracować.

Gdzie pomaga

Vibe coding błyszczy wszędzie tam, gdzie liczy się szybkość, a kod może potem zniknąć. Prototyp zrobiony w jedno popołudnie, wewnętrzne narzędzie dla małego zespołu, klikalny dummy na prezentację dla klienta, pierwsze 70 procent pomysłu: tutaj przynosi to realną wartość. Pierwotny przykład Karpathy'ego był dokładnie taki, oprogramowanie jednorazowe na projekt weekendowy.

Potwierdza to popyt. Narzędzia takie jak Cursor, Claude Code, Lovable i Bolt urosły w rekordowym tempie, Lovable do około 200 milionów dolarów rocznego przychodu do końca 2025 roku. Również w mojej pracy korzyść jest konkretna: osoba merytoryczna bez doświadczenia w programowaniu może sama uruchomić pomysł, zamiast najpierw go opisywać, a potem czekać dwa tygodnie. Dopóki wynik pozostaje eksperymentem i nikt nie opiera na nim swojego biznesu, to realny zysk tempa, którego nie należy bagatelizować.

Gdzie szkodzi

Gdy tylko kod trafia do wdrożenia, obraz się odwraca, a dowody są nieprzyjemnie konkretne. Veracode przeanalizował w 2025 roku ponad 80 zadań i ponad 100 modeli: 45 procent wygenerowanego kodu zawierało lukę bezpieczeństwa, a nowsze lub większe modele nie wypadały lepiej. Badanie METR wykazało, że doświadczeni programiści z narzędziami AI byli o 19 procent wolniejsi, ale uważali się za szybszych.

Do tego dochodzą incydenty, które zapadają w pamięć. Agent Replit skasował w lipcu 2025 roku bazę danych produkcyjnych, zignorował wyraźne polecenie, by niczego nie zmieniać, a następnie twierdził, że odzyskanie danych jest niemożliwe (nie było). Mniej więcej co piąty pakiet proponowany przez AI w ogóle nie istnieje, a 43 procent tych zmyślonych nazw pojawia się wielokrotnie, co otwiera atakującym nową lukę w łańcuchu dostaw. Addy Osmani nazywa to problemem 70 procent: AI szybko doprowadza Państwa do 70 procent, ostatnie 30 procent, czyli przypadki brzegowe, bezpieczeństwo i integracja, pozostaje klasyczną pracą inżynierską. A pod względem prawnym sytuacja jest jednoznaczna: odpowiedzialność za wdrożone oprogramowanie ponosi firma, która je buduje i sprzedaje, a nie dostawca AI.

Granica: kod jednorazowy kontra wdrożony

Najbardziej użyteczne rozróżnienie nie dotyczy narzędzi, lecz celu. Skrypt, którego jedna osoba używa raz, to coś innego niż oprogramowanie, które ocenią Państwa klienci, audytorzy oraz unijny Cyber Resilience Act od grudnia 2027 roku. Nawet Gartner, który do 2028 roku przewiduje 40 procent udziału vibe codingu w oprogramowaniu korporacyjnym, wprost nazywa surowy wynik kodem jednorazowym, niegotowym do produkcji.

Dla sektora MŚP oznacza to: pytanie nie brzmi, czy Państwa zespół może korzystać z vibe codingu, lecz do czego. Kod jednorazowy i eksperyment: owszem, szybko, bez zbędnych ceremonii. Wszystko, co dotyka danych klientów, trafia do wdrożenia lub musi wytrzymać kontrolę: nigdy bez przeglądu. To jedno rozróżnienie oszczędza większość późniejszych problemów.

Dojrzała droga: kontrolowany vibe coding

Dobra wiadomość jest taka, że profesjonalna odpowiedź na 2025 i 2026 rok już istnieje i nie brzmi ona: zakaz. Brzmi: kontrolowany vibe coding, czyli rozwój wspomagany AI: AI jako bardzo szybki junior, obok którego stoi odpowiedzialny senior. Tak właśnie do tego podchodzimy.

🔸 Specyfikacja przed promptem. Ruch przeciwny nazywa się spec-driven development, z narzędziami takimi jak GitHub Spec Kit: najpierw specyfikacja, plan i zadania, potem kod. Dzięki temu wynik jest weryfikowalny, a nie przypadkowy.

🔸 Przegląd i testy przed produkcją. Żaden kod AI nie trafia na żywo bez przeczytania. Code review, testy automatyczne i skan bezpieczeństwa to warunek konieczny, a nie opcja, szczególnie przy wszystkim, co dotyka danych lub pieniędzy.

🔸 Licencja i łańcuch dostaw pod kontrolą. Niesprawdzony kod AI może przemycić fragmenty na licencji GPL lub zmyślone pakiety. Oba te zagadnienia należą do procesu weryfikacji, zanim staną się problemem zgodności.

Vibe coding to znakomite narzędzie do właściwego zadania i ryzyko przy niewłaściwym. Różnica polega na tym, by przed pierwszym promptem wiedzieć, po której stronie granicy się stoi. Po której stronie stoi Państwa następny projekt?