Erst die Daten richtig lesen, dann richtig rechnen

Pize ist ein KI-Programmierassistent für wissenschaftliches Rechnen und statistische Analysen. Er läuft in Pize Code und Positron und ist außerdem als SDK verfügbar.

Die meisten Programmieragenten konzentrieren sich darauf, mehr Code zu schreiben. Fehler in Statistik und Forschung entstehen meist früher: Werden Daten falsch eingelesen, übernehmen alle späteren Tests, Modelle und Schlussfolgerungen unbemerkt diesen Fehler. Genau hier setzt Pize an – zuerst kennt das Modell Form, Typen und fehlende Werte der Daten; danach schreibt und führt es Code aus, liest Diagramme und korrigiert Ergebnisse in der bereits verwendeten R / Python-Sitzung.

Pize ist zugleich ein vollständiger Programmieragent: dateiübergreifende Änderungen, Terminalzugriff, Planung und Ausführung, Projektregeln, eine Auswahl an Modellen sowie MCP für den Zugriff auf bereits vorhandene Werkzeuge in Labor- oder internen Systemen. Nutzen Sie ihn in Pize Code, Positron, über die CLI oder das SDK.

• Was es ist. Ein für mathematisches Rechnen und statistische Analysen optimierter Programmieragent. Einlesen, Berechnen und Testen erfolgen in einer laufenden Sitzung. Ergebnisse lassen sich erneut berechnen.
• Was es nicht ist. Keine neue Oberfläche für eine allgemeine Codevervollständigung und kein Cursor-Ersatz, der von allem etwas schreibt. Im Mittelpunkt steht nicht die Vervollständigung, sondern das korrekte Einlesen der Daten und eine verlässliche Berechnung.
• Wo es läuft. In Pize Code, Positron, über die CLI und das SDK.
• Was das Modell erhält. Struktur, Typen, fehlende Werte und Zusammenfassungen – nicht die gesamte Tabelle im Kontext. Die Rohbeobachtungen verbleiben in der Sitzung.

Derselbe Programmieragent liest Dateien, schreibt Code, führt Befehle aus und kann einen Browser steuern. Jeder Schreibvorgang und jeder Befehl erfordert Ihre Zustimmung. Nutzen Sie ihn in Pize Code, Positron, der CLI oder über das SDK.

Derzeit verfügbare Einsatzmöglichkeiten

• Pize Code. Ein Seitenleisten-Plugin im Editor. Dateiübergreifende Bearbeitung, Terminal, Planungs- und Ausführungsmodus sowie überprüfbare Diffs.
• Positron. Derselbe Agent, ergänzt um eine Brücke in die bereits fokussierte R- oder Python-Sitzung.
• SDK. Derselbe Agent, eingebettet in ein Programm, das Sie bereits nutzen, und über die CLI verfügbar.

Bezahlung der Modellnutzung

Die Self-Service-Nutzung wird mit Prepaid-Credits bezahlt. Ein Credit entspricht einem US-Cent. Kaufen Sie auf der Preisseite ein Paket; Stripe wickelt die Zahlung ab. Enterprise-Konditionen werden nach Kontaktaufnahme vereinbart.

Enterprise

Für Labore und individuelle Konditionen gibt es keinen veröffentlichten Preis. Sie werden nach Kontaktaufnahme vereinbart.

Es ist zugleich ein vollständiger Programmieragent

Das Einlesen und die Sitzungsbrücke sind die zusätzliche Ebene von Pize. Danach folgen die Funktionen eines vollständigen Programmieragenten, die Pize ebenfalls bietet – ohne sie schließt sich auch der statistische Arbeitsablauf nicht.

Ein SDK (Software Development Kit) bündelt APIs, Typen und Beispiele, damit ein anderes Programm eine Funktion direkt aufrufen kann, ohne sie erneut implementieren zu müssen.

Ohne SDK schreibt jede Integration eigene HTTP-Aufrufe und muss Felder erraten. Mit einem SDK erhält die aufrufende Anwendung stabile Funktionsnamen, Typen und ein tatsächlich ausführbares Beispiel. Auf dieser Ebene wird ein Modell in eine Labor-Erfassungssoftware oder eine interne Analyseplattform eingebettet.

• Was es bereitstellt. Aufrufbare Schnittstellen, Typen und das kleinste lauffähige Beispiel. Die aufrufende Anwendung muss weder das Einlesen der Daten noch die Sitzung neu entwickeln.
• Was es nicht bereitstellt. Es ersetzt weder Ihre Produktoberfläche noch wählt es die statistische Methode. Die Methode wird weiterhin vom Modell vorgeschlagen und von Ihnen bestätigt.
• Der Unterschied zum Plugin. Das Plugin wird im Editor geöffnet. Das SDK bettet denselben Agenten in ein bereits verwendetes Programm ein, ohne eine weitere Seitenleiste zu benötigen.

MCP (Model Context Protocol) ist ein offenes Protokoll. Es ermöglicht einem Modell, zur Laufzeit auf externe Werkzeuge, Daten und Prompts zuzugreifen, ohne für jede Quelle eine eigene Verbindung zu entwickeln.

Ein Modell führt nur Schlussfolgerungen aus. Es kann Ihre Datenbank nicht sehen und keine Parameter in der Instrumentensoftware bedienen. MCP definiert drei Dinge: Werkzeuge (aufrufbare Aktionen), Ressourcen (lesbare Daten) und Prompts (wiederverwendbare Anweisungen). Jedes System, das diese Vereinbarung implementiert, kann vom Modell auf dieselbe Weise genutzt werden.

• Welches Problem es löst. Modell und externes System müssen nicht mehr jeweils eine eigene Verbindung erfinden. Datenbanken, Wissensdatenbanken und interne Gateways sind über ein gemeinsames Protokoll erreichbar.
• Was es nicht ist. Es ist weder ein Modell noch ein SDK. Es legt nicht fest, wie Sie den Agenten in Ihr eigenes Programm einbetten, sondern nur, wie der laufende Agent externe Systeme anbindet.
• In Pize. Pize greift als Client auf andere MCP-Server zu. Die Sicherheitsgrenze bleibt Ihre Freigabe: standardmäßig nur lesend; Aktionen warten auf Ihre Bestätigung.

Damit ein KI-System in der Forschung zu korrekten Zahlen gelangt, fehlt selten nur „ein größeres Modell“. Entscheidend ist, ob das Modell reale Daten sehen, reale Werkzeuge bedienen und in bereits verwendeter Software arbeiten kann.

Pize trennt diese drei Ebenen und verbindet sie zugleich. Das Modell wählt eine Methode und schreibt Code. Das SDK bringt den Agenten in Ihre Werkzeuge. MCP ermöglicht ihm zur Laufzeit den Zugriff auf Bibliotheken, Instrumentensoftware und interne Systeme. Das Einlesen steht weiterhin am Anfang: Sind die Daten falsch, tragen die beiden anderen Ebenen den Fehler nur weiter.

Statistische Fehler zeigen sich selten als Absturz. Ein falsches Trennzeichen verschiebt jede Spalte; wird die erste Zeile als Kopfzeile behandelt, geht die erste Beobachtung verloren; werden NA und NULL zu 0, verändern sich Mittelwert und Varianz; und eine als Text eingestufte numerische Spalte wird in einem Regressionsmodell als Faktor behandelt. Nichts davon hält das Programm an. Es liefert unbemerkt eine plausibel wirkende, aber falsche Zahl — und weil der Fehler beim Einlesen entstand, übernehmen ihn alle späteren Tests, Modelle und Schlussfolgerungen.

Pize ist deshalb nicht darauf optimiert, dass das Modell mehr Code schreibt. Zuerst soll es die Form der Daten, die Typen der einzelnen Spalten, den Umfang der fehlenden Werte und die ungefähre Zeilenzahl kennen. Erst dann schreibt es Berechnungs- und Modellierungscode und führt ihn in Ihrer tatsächlichen Sitzung aus, sodass Sie die Ergebnisse sehen können.

Die Formaterkennung richtet sich nach dem Inhalt, nicht nach der Dateiendung — in Forschungsdaten enthält eine .txt-Datei oft eine Tabelle, während eine .csv-Datei mitunter nur aus drei Konfigurationszeilen besteht. Jede der folgenden Entscheidungen wirkt sich direkt auf die späteren Ergebnisse aus.

• Trennzeichenerkennung. Zur Auswahl stehen Tabulator, Komma, Semikolon und das Pipe-Zeichen (|). Die Zeilen müssen eine stabile Spaltenzahl aufweisen und die Felder wie Tabellenzellen aussehen, damit Prosa mit einem Komma in jedem Satz nicht als zweispaltige Tabelle interpretiert wird.
• Kopfzeile oder Daten. Enthält die erste Zeile an den Positionen numerischer Spalten weiterhin Zahlen, handelt es sich um eine Beobachtung und nicht um Spaltennamen. Die erste Beobachtung fälschlich als Kopfzeile zu behandeln, ist ein klassischer Grund dafür, dass eine Stichprobe verloren geht.
• Fehlende Werte bleiben bei der Typinferenz unberücksichtigt. Leere Zeichenfolgen, NA, NaN und NULL werden gesondert erkannt; andernfalls könnte eine vollständig leere Spalte als numerisch eingestuft werden und das Modell Kennzahlen für nicht vorhandene Werte berechnen.
• Typinferenz je Spalte. Numerisch, Text oder leer — die Einstufung erfolgt für jede Spalte einzeln. Dieser Schritt entscheidet, ob eine Spalte für Mittelwert, Varianz oder Regression verwendet werden kann.
• Kommentare und Metadaten werden entfernt. Vorangestellte Blöcke, die mit #, ! oder @XX beginnen, werden zuerst entfernt. Bei VCF stehen die Spaltennamen in der letzten Kommentarzeile; Pize stellt sie wieder her, damit die Spalten korrekt benannt sind.
• Komprimierte Tabellen werden transparent eingelesen. .gz-Dateien werden automatisch entpackt; maßgeblich ist die Größe nach dem Entpacken — ein 1-MB-Archiv kann eine 20-MB-Tabelle enthalten.
• Schätzung der Zeilenzahl. Die Gesamtzahl der Zeilen wird anhand des Byteanteils des bereits gelesenen Präfixes geschätzt und ausdrücklich als Schätzung, nicht als Tatsache, gekennzeichnet.
• Zu große Dateien erhalten eine Datenkarte statt einer Fehlermeldung. Wird das Kontextbudget überschritten, liefert Pize Dateigröße, Trennzeichen, geschätzte Zeilenzahl, Spaltennamen mit den abgeleiteten Typen und die ersten beiden Zeilen. Anhand dieser Karte kann das Modell den richtigen Einlesecode schreiben, ohne dass eine Tabelle mit einer Million Zeilen das Kontextbudget aufbraucht.

Erst lesen, dann rechnen. Pize erfindet keine statistischen Methoden für Sie. Es sorgt dafür, dass das Modell Ihre echten Daten sieht und Sie jeden Schritt sehen.

• Methode anhand der tatsächlichen Verteilung wählen. Das Modell erhält Zeilen- und Spaltenzahlen, Typen, die Anzahl fehlender Werte und Zusammenfassungen. Auf dieser Grundlage entscheidet es zwischen parametrischen und nichtparametrischen Verfahren, über nötige Transformationen und den Umgang mit fehlenden Werten.
• Schreiben, dann ausführen. Erzeugtes R oder Python läuft nach Ihrer Bestätigung in der aktuellen Sitzung. Zurück kommt echte Ausgabe, keine erdachte Zahl.
• Diagnose anhand von Grafiken. Die zuletzt erzeugte Grafik kann abgerufen werden — etwa QQ-Plots, Residualplots oder Verteilungsplots, deren Aussage sich nur visuell beurteilen lässt. Das Modell kann diese Beurteilung unterstützen.
• Geschlossener Iterationszyklus. Ausführen, Ergebnisse lesen und korrigieren geschieht in derselben Sitzung. Zwischenvariablen gehen nicht durch den Start eines neuen Prozesses verloren.
• Nur Aggregate, nie Rohzeilen. Tabellenzusammenfassungen liefern Struktur und Kennzahlen. Rohbeobachtungen bleiben in der Sitzung.

Die Wahrheit einer Analyse liegt nicht in der Datei, sondern im Speicher. Die Brücke liest über Positrons öffentliche Erweiterungs-API die R- oder Python-Sitzung, die gerade im Fokus ist. Sie erzeugt und wechselt keine Laufzeit. Sie nutzt nur die, die Sie schon verwenden.

• Regressionstests mit generierten Korpora. Für 31 Dateiformen werden beschriftete Stichproben erzeugt und in Blöcken von zehntausend durch den Detektor geschickt. Beim ersten Durchlauf schlugen 458 Fälle fehl; dadurch wurden vier Fehlerklassen sichtbar und einzeln behoben. Der Zufalls-Seed ist fest, sodass sich mit denselben Eingaben prüfen lässt, dass die behobenen Fehler nicht wiederkehren.
• Tripwire-Tests an jeder Anbindung. Jede Anbindung an den Upstream-Code ist getestet. Verliert ein Merge eine einzelne Verdrahtungszeile, schlägt der Test sofort fehl — die Funktion kann nicht unbemerkt ausfallen, während die Testsuite grün bleibt.
• Die volle Checkliste bei jedem Merge. Tausende Unit-Tests, zwei Typprüfer, Repo-weites Lint; nach dem Packen wird das Artefakt geöffnet, um zu bestätigen, dass das Verhalten wirklich enthalten ist.
• Selbstcheck mit einem Klick. Die Brückenprüfung in der Befehlspalette liest wirklich eine Sitzung. Bestand bedeutet: die Werkzeuge erreichten echte Daten.
• Neben dem offiziellen Build. Eigene Extension-ID, installierbar neben dem Upstream-Plugin, ohne es zu überschreiben.

Für die Architektur gilt durchgehend eine Regel: Neues Verhalten kommt immer in neue Dateien; Upstream-Dateien werden nur an den erforderlichen Aufrufstellen geändert. Deshalb kann ein Merge mit zehn Upstream-Commits an nur einer Zeile in Konflikt geraten — die Erweiterung kann dem Upstream dauerhaft folgen, statt einmal veröffentlicht zu werden und dann stehenzubleiben.