Mit Evidenz entwickeln.
Oloproof hilft Teams, KI-Systeme mit wiederholbaren Tests, Diagnosen und entscheidungsfähiger Evidenz zu evaluieren.
Läuft in Ihrer CI. Ihre Evidenz bleibt auf Ihrem Rechner.
Prompts von Hand zu testen übersteht die Produktion nicht.
Teams liefern jede Woche Änderungen an Modellen und Prompts aus. Eine Handvoll Ausgaben in einem Playground stichprobenartig zu prüfen, sagt Ihnen fast nichts darüber, was sich geändert hat, für wen, oder ob ein Release sicher ist.
Oloproof ersetzt das durch eine gemessene Aufzeichnung: dieselben Fälle, dieselben Judges, dieselben Seeds, bei jeder Änderung ausgeführt.
Eine Prompt-Änderung behebt eine Fehlerklasse und bricht still eine andere. Niemand bemerkt es, bis ein Kunde es bemerkt.
Bei einem produktiven RAG-System änderte etwa jeder neunte beobachtete Fall sein Urteil zwischen identischen Messungen.
Ein produktiver Harness wertete seine 13,8 % HTTP-500-Antworten als Nullen und lastete Ausfälle dem Modell an. Ein Durchschnitt kann keine Entscheidung tragen.
Wenn Risikomanagement, Rechtsabteilung oder ein Kunde fragt, was Sie getestet haben, sind Screenshots in einem Thread keine Antwort.
Vier Dinge, die jede Release-Entscheidung braucht.
Versionierte Datensätze, fixierte Seeds und deklarative Judges. Jeder Lauf lässt sich exakt reproduzieren, auch Monate später.
Differenzen mit Konfidenzintervallen und Schwellenwerten, damit eine Bewegung um zwei Punkte nie mit einem Gewinn verwechselt wird.
Fehler gruppiert nach Segment, Intention und Tool-Pfad, jeweils verknüpft mit den genauen Traces dahinter.
Eine Release-Empfehlung mit angehängter Evidenz — exportierbar für Review, Audit und Kunden.
Jedes Intervall schneidet die gestrichelte Nulllinie. Allein nach den Punktschätzungen wäre der Reranker ausgeliefert worden.
Für Teams, die das Release begründen müssen.
Definieren Sie Datensätze, Judges und Schwellenwerte in der Versionsverwaltung. Prüfen Sie Änderungen an der Evaluierung so, wie Sie Code prüfen.
Programmatische Prüfungen, LLM-Judges, trainierte Klassifikatoren, die Text auf Ihrem eigenen Rechner bewerten, und menschliche Labels in einer Pipeline. Die Übereinstimmung jedes Judges mit Menschen wird mit einem Intervall gemessen, und ein Judge, der seine Hürde nicht genommen hat, kann kein Release entscheiden.
Lassen Sie einen Pull Request fehlschlagen, wenn eine Metrik ihren Schwellenwert überschreitet. Das Gate meldet, welche Fälle sich bewegt haben und um wie viel.
Jeder Score verweist auf Eingaben, Ausgaben, Tool-Aufrufe, abgerufenen Kontext und die Begründung des Judges. Nichts ist eine Blackbox.
Qualität ist nie die einzige Achse. Verfolgen Sie Ausgaben und Tail-Latenz neben der Korrektheit, unter denselben Schwellenwerten.
Teilen Sie Lauf, Diagnose und Empfehlung, ohne die gemessene Entscheidung darin zu verändern.
Drei Schritte, dann läuft es von selbst.
Bringen Sie Ihre eigenen Fälle als JSONL-Datei mit. Deklarieren Sie Judges und die Schwellenwerte, die ein Release erreichen muss.
Ein Befehl lokal, derselbe Befehl in der CI. Änderungen an Prompt, Modell, Retrieval und Tools werden alle gleich behandelt.
Lesen Sie die Differenzen, öffnen Sie die fehlschlagenden Traces und halten Sie die Evidenz an der getroffenen Entscheidung fest.
Jede Zahl führt auf einen Fall zurück.
Läufe sind unveränderlich und datiert. Datensätze, Prompts, Judges und Konfiguration werden gemeinsam versioniert, sodass jedes Ergebnis reproduziert oder angefochten werden kann.
Nach den Punktschätzungen liefert der Reranker +12,7 Punkte hit@1. Ehrlich gelesen kann dieses Panel nicht sagen, ob er hilft oder schadet.
Was dies noch nicht ist.
Alles Folgende gilt an dem Tag, an dem Sie es lesen.
- 01
Es gibt kein gehostetes Deployment, für das Sie sich registrieren können. Der Zugang erfolgt auf Einladung.
- 02
Es gibt keine Preise. Die Einheit ist ein evaluierter Fall; die Tarife sind nicht festgelegt.
- 03
Es gibt kein Sicherheitsaudit, keinen SOC-2-Bericht und keinen DPA. Es gibt keine Kunden und keine Fallstudien, daher werden keine zitiert.
- 04
Benachrichtigungen gibt es nur per E-Mail: kein Slack, kein Pager, kein Webhook. Es gibt kein Berichtsdokument. Ein Lauf wird in der Workbench gelesen oder als Bundle exportiert.
- 05
Die Bewertung in Produktion ist nicht gebaut: Traces werden auf Ihrem eigenen Rechner empfangen, und noch bewertet nichts den Produktionsverkehr.
- 06
Es wurde durchgängig gegen genau ein produktives Drittsystem ausgeführt. Das ist die Evidenz oben, und es ist ein System.
Messen, bevor Sie ausliefern.
Bringen Sie ein System und einen Datensatz mit. Beginnen Sie mit einem lokalen Lauf und behalten Sie die Evidenz auf Ihrem Rechner.