Suchmodus, Modell und Sitzung: Das Prüfprotokoll für einen KI-Vergleich

Zuerst festlegen, was sich unterscheiden darf

„Wir stellen zwei KI-Systemen dieselbe Frage“ ist noch kein vollständiger Versuchsplan. Wollen Sie zwei Produkte im normalen Gebrauch vergleichen, zwei Modelle über eine API untersuchen oder den Einfluss einer Suchfunktion prüfen? Diese drei Aufgaben brauchen unterschiedliche Vergleichsregeln. Bei einem Produktvergleich gehören die jeweiligen Such- und Antwortfunktionen zum untersuchten Gesamtprodukt; daraus lässt sich kein isolierter Modellvergleich ableiten.

Schreiben Sie vorab einen Satz wie: „Wir vergleichen bei unverändertem Prompt und gleicher API die Konfiguration ohne Suchwerkzeug mit einer Konfiguration, in der das Suchwerkzeug angeboten wird.“ Der Suchzugang ist dann die beabsichtigte Änderung. Modell, Anweisungen, Sprache und mitgesendeter Kontext sollen gleich bleiben. Ein Wechsel dieser Bedingungen erhält einen eigenen Versuchsarm oder wird als Abweichung dokumentiert.

Dieser Beitrag liefert eine redaktionelle Arbeitsmethode. Die API-Feldbeispiele beziehen sich auf die am 17. September 2026 geprüfte OpenAI- und Claude-Dokumentation. Die Beispielprotokolle sind ausdrücklich illustrativ und nicht ausgeführt. Es werden weder Antworten noch Leistungsunterschiede zwischen Anbietern als Messergebnis dargestellt.

Pro Versuch ein Protokoll mit drei Arten von Angaben

Legen Sie für jede abgesendete Frage einen Eintrag an. Eine Zeile für ein ganzes Produkt reicht nicht: Ein erneuter Versuch, ein fortgesetztes Gespräch oder ein geänderter Suchmodus kann andere Bedingungen haben. Die kopierbare Textvorlage im Quellenbereich enthält die Felder und zwei illustrative Planbeispiele.

Kennzeichnen Sie Angaben als konfiguriert, beobachtet oder unbekannt. „Websuche angeboten“ beschreibt die Konfiguration. „Suchaufruf im vollständigen Antwortprotokoll vorhanden“ beschreibt eine Beobachtung. „Oberfläche zeigt keine Werkzeugereignisse“ bedeutet unbekannt. Leere Felder sind ungünstig, weil später niemand erkennt, ob eine Bedingung fehlte oder nur nicht notiert wurde. Verwenden Sie deshalb auch die Werte „nicht unterstützt“, „nicht verfügbar“ und „nicht ausgeführt“ ausdrücklich.

• Auftrag: Vergleichsfrage, bewusst veränderte Bedingung, geplante Auswertungsregeln und Kennung des Versuchsarms.
• Eingabe: Prompt-ID, Version und vollständiger Wortlaut; gewünschte Antwortsprache und im Prompt beschriebener Zielmarkt.
• Zugang: Anbieter, konkrete App beziehungsweise API-Endpunkt, sichtbare Produktversion sowie angeforderte und tatsächlich zurückgemeldete Modellbezeichnung, soweit verfügbar.
• Bedingungen: Suchwerkzeuge und Filter, Suchstandort, Kontext, Zusatzanweisungen, Anhänge und alle unterstützten Generierungsparameter mit ihrem Wert oder dokumentierten Standard.
• Durchführung: Beginn und Ende mit Zeitzone, Status, Wiederholungsversuche, Antwort- oder Anfragekennung und Fundort der gesicherten Belege.

Suchzugang und tatsächlich erfolgte Suche getrennt prüfen

Die OpenAI-Dokumentation unterscheidet bei der Responses API zwischen einem angebotenen Websuchwerkzeug und dessen Nutzung. Bei tool_choice: auto ist die Suche optional. Ein web_search_call im Rückgabeverlauf dokumentiert Werkzeugaktivität; zusätzlich werden zitierte URLs über Annotationen ausgegeben. Protokollieren Sie daher sowohl den gesendeten tools-Eintrag als auch den erhaltenen Werkzeugverlauf. Halten Sie außerdem einen ausdrücklich gesetzten Live-Zugriff, Filter und Standort fest; übernehmen Sie solche Einstellungen nicht ungeprüft aus einer anderen Schnittstelle.

Bei Claude gehören zur dokumentierten Websuche unter anderem Werkzeugversion, Suchlimit, Domainfilter und user_location. Bei vollständiger Ergebnisausgabe enthält die Antwort eigene Suchaufruf- und Ergebnisblöcke. Die Option response_inclusion kann bestimmte verschachtelte Suchblöcke ausblenden; protokollieren Sie deshalb auch die Ausgabekonfiguration. Ein Suchfehler kann innerhalb einer ansonsten erfolgreichen HTTP-Antwort stehen. „HTTP 200“ allein bestätigt deshalb keinen erfolgreichen Suchdurchlauf. Prüfen Sie neben dem Transportstatus auch den Werkzeugstatus und bewahren Sie die sichtbaren Quellen getrennt auf.

Eine bloße Linkliste im Antworttext ersetzt dieses Protokoll nicht. Wenn Ihr Export nur den Endtext enthält, lässt sich daraus nicht zuverlässig bestimmen, welche Werkzeuge aufgerufen wurden. Tragen Sie „Suchnutzung unbekannt; Export ohne Werkzeugverlauf“ ein. Fehlen Links, darf daraus ebenso wenig automatisch „Suche ausgeschaltet“ werden.

Den Gesprächskontext konkret beschreiben

„Neuer Chat“ ist als Prüfvermerk zu ungenau. Notieren Sie, ob frühere Nachrichten, zusätzliche Anweisungen, Dateien, Projektwissen oder sichtbare Personalisierung vorhanden sind. Prüfen Sie in einer Oberfläche die verfügbaren Einstellungen und sichern Sie deren Zustand. Was sich nicht einsehen lässt, bleibt unbekannt. Setzen Sie unsichtbare Systemeinstellungen nicht allein deshalb auf „aus“, weil Sie ein neues Fenster geöffnet haben.

Für die OpenAI Responses API beschreibt die Dokumentation mehrere Wege, Gesprächskontext weiterzugeben: frühere Nachrichten als Eingabe, eine bestehende Conversation oder previous_response_id. Soll ein Versuch ohne vorherige Unterhaltung starten, prüfen Sie alle diese Wege sowie Ihre eigenen mitgesendeten Anweisungen und Dateien. Eine neu vergebene lokale Versuchsnummer löscht keinen solchen Kontext.

Trennen Sie außerdem den Markt in der Frage vom Suchstandort. „Software für österreichische Unternehmen“ ist eine inhaltliche Anforderung. Eine explizite Standortkonfiguration des Suchwerkzeugs ist ein anderes Feld. Die Sprache der Antwort beweist weder den verwendeten Suchstandort noch den tatsächlichen Nutzerstandort. Halten Sie nur fest, was Sie gesetzt oder nachvollziehbar beobachtet haben.

Planbeispiel: Eine Suchfunktion als einzigen Faktor ändern

Das folgende Beispiel ist ein nicht ausgeführter Versuchsplan. Der identische Prompt lautet: „Welche CRM-Lösungen kommen für ein deutschsprachiges Vertriebsteam mit 20 Mitarbeitenden infrage? Vergleichen Sie die Eignung für gemeinsame Kontaktpflege und nachvollziehbare Vertriebsprozesse. Benennen Sie offene Informationen.“ Es werden keine Anbieter vorgegeben und keine angeblichen Antworten ergänzt.

Plan A verwendet die OpenAI Responses API ohne angebotene Werkzeuge. Plan B verwendet dieselbe Schnittstelle mit web_search und tool_choice: auto. Vor einer Durchführung werden in beiden Plänen dieselbe konkret verfügbare Modellkennung, dieselben Anweisungen, Ausgabelimits und sonstigen unterstützten Parameter eingetragen. Beide beginnen ohne mitgesendete Vorgeschichte oder vorhandene Gesprächsverknüpfung. Die verbleibenden Platzhalter sind keine gültigen Messdaten.

Der richtige Vergleichstitel lautet hier „Suchwerkzeug nicht angeboten versus angeboten“. Er lautet nicht „Antwort ohne Suche versus Antwort mit Suche“: Plan B garantiert bei automatischer Werkzeugwahl noch keinen Suchaufruf. Nach einer späteren Ausführung würden die tatsächlichen Werkzeugereignisse separat erfasst. Läufe ohne Suche dürfen nicht nachträglich verschwinden, nur weil die gewünschte Suchbedingung nicht eingetreten ist.

Wenn stattdessen eine zwingende Suche untersucht werden soll, muss die unterstützte Werkzeugsteuerung vorher passend konfiguriert und dokumentiert werden. Das ist ein geänderter Versuchsplan. Die beiden Konfigurationen dürfen nicht unbemerkt in dieselbe Gruppe fließen.

Gegenproben für Kontext und unvollständige Belege

Eine zweite geplante Gegenprobe hält Modell und Suchkonfiguration konstant und verändert nur den mitgesendeten Gesprächskontext. Variante A enthält allein die definierte Käuferfrage und die gemeinsamen Anweisungen. Variante B enthält zusätzlich eine genau gespeicherte vorausgehende Nachricht, etwa „Berücksichtigen Sie ausschließlich Systeme mit einem dokumentierten Export der Kontaktdaten.“ Welche Antworten daraus entstehen würden, bleibt offen. Die zusätzliche Anforderung ist der untersuchte Faktor; das Ergebnis wäre keine allgemeine Aussage über die Bekanntheit einer Marke.

Prüfen Sie Ihr Protokoll auch mit einem absichtlich unvollständigen Planfall: Es soll später lediglich ein Antworttext mit Links vorliegen, aber keine Information über Modellversion oder Werkzeugaufrufe. Die vorgesehene Entscheidung lautet dann „als sichtbare Antwort dokumentierbar; für einen kontrollierten Modell- oder Suchvergleich nicht ausreichend“. Ersetzen Sie die fehlenden Angaben nicht durch Annahmen aus dem Namen der App.

Wechseln Sie zwischen App und API, behandeln Sie das zunächst als eigenen Untersuchungsweg. Gleicher Prompt und ähnlicher Modellname genügen nicht, um alle übrigen Bedingungen als identisch einzustufen. Lassen Sie pro Schnittstelle nur die Felder ausfüllen, die tatsächlich verfügbar sind; dokumentieren Sie die verbleibenden Grenzen direkt beim Vergleich.

Vor der Auswertung über die Vergleichbarkeit entscheiden

Geben Sie jedem Versuch einen technischen Status und jedem geplanten Vergleich eine begründete Einordnung. Ein vollständig gespeicherter Endtext kann für eine Inhaltsprüfung nutzbar sein, obwohl die Suchnutzung unbekannt bleibt. Umgekehrt macht ein korrekt protokollierter Suchaufruf einen abgebrochenen Endtext nicht vollständig. Prüfen Sie die Eignung immer für die vorher festgelegte Frage.

Bewahren Sie Antworttext, sichtbare Zitate und Werkzeugprotokoll unverändert als Beleg auf. Ihre Bewertung – etwa „Marke genannt“ oder „Quelle trägt die Aussage nicht“ – steht in eigenen Feldern. Dokumentieren Sie jeden technischen Wiederholungsversuch separat. Eine erfolgreich wiederholte Anfrage ersetzt den ursprünglichen Fehler nicht rückwirkend.

• Passende Vergleichsbedingungen: Der beabsichtigte Unterschied ist dokumentiert, die übrigen erforderlichen Bedingungen stimmen überein und die benötigten Belege sind vollständig.
• Separater Versuchsarm: Eine relevante zusätzliche Bedingung hat sich verändert, beispielsweise Kontext, Oberfläche oder Modellkennung. Ergebnisse getrennt führen.
• Unbekannte Vergleichsbedingung: Eine notwendige Einstellung oder Beobachtung fehlt. Die konkrete Einschränkung nennen und daraus keine kontrollierte Wirkungsbehauptung ableiten.
• Technisch unvollständig: Anfrage, Werkzeug oder Ausgabe scheitert beziehungsweise wird abgeschnitten. Fehler festhalten und nicht als gültige Antwort ohne Markennennung zählen.

Das Protokoll vor dem ersten echten Lauf übergeben

Lassen Sie eine zweite Person anhand der Vorlage erklären, welche Anfrage sie stellen würde, welche Bedingungen gleich bleiben sollen und welche Belege sie anschließend sichern muss. Wenn sie dafür Annahmen ergänzen muss, fehlt eine Definition. Dieser einfache Probelauf prüft die Verständlichkeit der Anleitung, nicht die Qualität eines Modells.

Geben Sie dem Plan nach dieser Prüfung eine Version. Änderungen an Prompt, Modellkennung oder Auswertungsregel werden sichtbar dokumentiert. Speichern Sie Belege so, dass Berechtigte sie dem jeweiligen Versuch zuordnen können; Zugangsschlüssel und unnötige vertrauliche Inhalte gehören nicht in eine geteilte Vorlage.

Auch ein sauber dokumentierter Ablauf liefert keine Garantie identischer Antworten oder einen Beweis für die Ursache einer einzelnen Abweichung. Das Protokoll macht prüfbar, unter welchen bekannten Bedingungen eine Antwort entstanden ist und welche Fragen offenbleiben. Erst damit lässt sich entscheiden, welche Wiederholungen oder weitergehenden Untersuchungen sinnvoll sind.