Experimente mit LLM-Prompts und KI-Agent-Konfigurationen durchführen

LLM-basierte Anwendungen und KI-Agenten sind nicht deterministisch. Wenn Sie einen Prompt, ein Modell, eine Retrieval-Strategie, eine Tool-Konfiguration oder einen Agenten-Workflow ändern, wirkt sich das auf unterschiedliche, schwer vorhersehbare Weise auf Antwortqualität, Betriebskosten, Latenz und Nutzerverhalten aus. Evaluierungs-Frameworks wie RAGAS bewerten, ob eine einzelne Antwort einen Qualitätsstandard erfüllt, aber diese Bewertung sagt Ihnen nicht, ob die Änderung den Nutzern hilft, das zu erreichen, weswegen sie Ihr Produkt überhaupt nutzen. Sie können die Funktionen von Kameleoon Feature Experimentation nutzen, um die Konfiguration hinter einer generativen KI-Anwendung oder einem KI-Agenten anzupassen, zu testen und auszurollen. Eine Feature-Variable enthält jeweils einen Teil dieser Konfiguration (einen Prompt, einen Modellparameter, eine Retrieval-Strategie, eine Tool-Definition), sodass Ihr Team sie außerhalb des Anwendungscodes verwalten kann. Jede Variation stellt eine mögliche Konfiguration dar, was Ihnen ermöglicht, Änderungen zu iterieren, zu testen und sicherer zu veröffentlichen, ohne erneut bereitzustellen. Ein KI-gestützter Kundensupport-Agent könnte beispielsweise seinen System-Prompt, sein Modell, den Reasoning-Aufwand und die Retrieval-Einstellungen als vier separate Variablen bereitstellen, sodass Sie eine neue Kombination aller vier gleichzeitig testen können, anstatt bei jeder Variable auf ein separates Deployment zu warten. Verteilen Sie den Traffic auf die Variationen, und vergleichen Sie deren Auswirkungen anhand mehrerer Metriktypen:

• KI-Qualitätsmetriken, wie Korrektheit, Fundiertheit (Groundedness), Relevanz, Kontextqualität, Sicherheit oder Compliance
• Agenten-Leistungsmetriken, wie erfolgreiche Tool-Nutzung oder Aufgabenerfüllung
• Operative Metriken, wie Latenz, Token-Verbrauch, Fehler und Kosten
• Nutzer- und Geschäftsmetriken, wie Zufriedenheit, Eskalation, Conversion, Bindung und Umsatz

Da die Konfiguration in einem Feature Flag statt in Ihrem Quellcode liegt, können Sie jederzeit direkt über die Kameleoon-Plattform eine Variation hinzufügen, bearbeiten oder zurücksetzen.

​

Evaluierung und Experimente lösen unterschiedliche Probleme

Evaluierung stellt fest, ob eine einzelne Modell- oder Agenten-Ausgabe einen definierten Qualitätsstandard erfüllt. Observability-Tools ermöglichen es Ihnen, die Prompts, Antworten, Traces, Retrieval-Schritte und Tool-Aufrufe hinter dieser Ausgabe zu untersuchen. Experimente stellen fest, ob eine Änderung an der zugrunde liegenden Konfiguration eine messbare Verbesserung für Nutzer oder das Geschäft bewirkt: eine Frage, die weder die Evaluierung noch die Observability beantwortet. Ein LLM-Judge könnte beispielsweise den überarbeiteten System-Prompt eines Kundensupport-Agenten als fundierter bewerten als den aktuellen. Ein Kameleoon-Experiment beantwortet die Fragen, für die Ihr Team verantwortlich ist: ob dieselbe Konfiguration mehr Tickets löst, ohne an einen Menschen zu eskalieren, und was das an Latenz und Token-Kosten kostet. Kameleoon ersetzt nicht Ihren LLM-Observability- oder Evaluierungs-Stack. Speisen Sie Bewertungsergebnisse aus RAGAS, einem LLM-Judge oder einem menschlichen Review-Prozess als benutzerdefiniertes Ziel in Kameleoon ein, und verfolgen Sie diese Werte zusammen mit den Verhaltens- und Geschäftszielen, die Ihr Experiment bereits misst. Ihre Qualitätssignale auf Modellebene lassen sich damit mit einer statistisch zuverlässigen Messung der tatsächlichen Auswirkung auf Nutzer verbinden. Kombinieren Sie bei den meisten KI-Experimenten mehrere Metriktypen, anstatt sich auf einen einzigen zu verlassen:

• Legen Sie ein Nutzer- oder Geschäftsergebnis als primäres Ziel fest.
• Verfolgen Sie KI-Qualitätsmetriken als sekundäre Ziele oder Guardrails.
• Überwachen Sie Latenz, Kosten, Fehler und Sicherheit als operative Guardrails.
• Validieren Sie automatisierte Judges anhand einer Stichprobe menschlich geprüfter Beispiele, bevor Sie deren Bewertungen im großen Maßstab vertrauen.

​

Funktionsweise

Ein Experiment mit einer LLM-Anwendung oder einem KI-Agenten durchläuft in Kameleoon fünf Phasen:

1. Ein Feature Flag speichert die Konfiguration. Jeder Teil der Konfiguration, etwa ein Prompt oder ein Modellname, wird zu einer Feature-Variable des Flags.
2. Jede Variation legt ihre eigenen Werte fest. Eine Variation ist eine vollständige mögliche Konfiguration mit einem Wert für jede Variable.
3. Das SDK weist jedem Besucher eine Variation zu. Wenn ein Besucher Ihre Anwendung erreicht, fragt Ihr Code das Flag ab und erhält die Werte der zugewiesenen Variation, um damit das LLM aufzurufen oder den Agenten zu konfigurieren.
4. Ziele erfassen, was passiert ist. Ihre Anwendung verfolgt eine Conversion für jedes an das Flag angehängte Ziel, einschließlich einer Guardrail-Conversion, die nur eintritt, wenn eine Antwort einen akzeptablen Schwellenwert für Qualität oder Latenz verletzt.
5. Die Ergebnisseite vergleicht die Variationen. Sobald Sie genügend Traffic gesammelt haben, vergleichen Sie die Variationen anhand aller angehängten Ziele, um zu entscheiden, welche Konfiguration Sie ausrollen.

​

Voraussetzungen

• Ein Kameleoon-Konto mit einem für Feature Experimentation eingerichteten Projekt.
• Die Client-ID und das Client-Secret Ihres Kontos. Diese Werte finden Sie unter API-Anmeldeinformationen.
• Eine serverseitige Anwendung, in der Sie ein Kameleoon SDK installieren können, zum Beispiel eine Python-Anwendung.

​

Ihr KI-Agenten-Experiment in Kameleoon einrichten

Die folgenden Schritte bauen ein konkretes Experiment auf: Hilft ein überarbeiteter System-Prompt in Kombination mit einem stärkeren Modell und einem höheren Reasoning-Aufwand einem Kundensupport-KI-Agenten dabei, mehr Tickets eigenständig zu lösen, und bleibt die Latenz dabei in einem akzeptablen Bereich? Konfigurieren Sie das Feature Flag, die Variationen und die Tracking-Ziele in der Kameleoon-Plattform, bevor Sie Ihren Anwendungscode anfassen.

​

Das Feature Flag erstellen

Erstellen Sie ein Feature Flag, um die Konfiguration Ihres Agenten aufzunehmen und die Bereitstellung Ihres Experiments zu steuern.

1. Klicken Sie in der Kameleoon-App auf Features > Flags & Experiments > New feature flag.
2. Geben Sie einen Namen ein, zum Beispiel AI support agent config, und wählen Sie das Projekt für das Flag aus.
3. Notieren Sie im Feld Description, wofür das Flag steht, zum Beispiel “Steuert den System-Prompt, das Modell, den Reasoning-Aufwand und die Retrieval-Einstellungen für den Support-Chatbot”, damit andere Teammitglieder seinen Zweck verstehen.
4. Klicken Sie auf Validate.
5. Kameleoon generiert aus dem Namen des Flags einen Feature-Key. Notieren Sie sich den generierten Key, oder bearbeiten Sie ihn zu ai_support_agent. Ihr Anwendungscode identifiziert das Flag anhand dieses Keys und nicht anhand seines Namens, daher müssen beide übereinstimmen.

Neue Flags starten im Zustand OFF. Sie aktivieren das Flag nach Abschluss der Konfiguration im Rollout Planner. Weitere Details finden Sie unter Ein Feature Flag erstellen.

​

Die Agenten-Konfiguration in Feature-Variablen speichern

Fügen Sie für jeden Teil der Agenten-Konfiguration, den Sie testen möchten, eine Feature-Variable hinzu, sodass Sie jede davon über die Kameleoon-Plattform ändern können, ohne Ihren Anwendungscode zu bearbeiten. Dieses Beispiel testet vier Variablen:

1. Klicken Sie auf der Seite des Flags in der linken Seitenleiste auf Set Up > Variables > Add Variable.
2. Setzen Sie den Type der Variable passend zur Tabelle auf String oder Number.
3. Geben Sie den Variable Key aus der Tabelle ein, zum Beispiel system_prompt.
4. Setzen Sie die Default Value auf den Wert, den Ihre Anwendung heute in der Produktion verwendet. Jede Variation, die Sie später erstellen, wird zunächst mit diesen Werten vorausgefüllt. Genaue Standardwerte ersparen Ihnen daher Arbeit und liefern eine bewährte Konfiguration, auf die Sie zurückgreifen können.
5. Klicken Sie auf Save.
6. Wiederholen Sie diese Schritte für jede verbleibende Variable in der Tabelle.

Weitere Details finden Sie unter Feature-Variablen definieren.

​

Ihre Variationen erstellen

Eine Auslieferungsregel kann nur Off oder eine selbst erstellte Variation ausliefern, daher benötigt ein A/B-Vergleich sowohl eine Variation für Ihre aktuelle Konfiguration als auch eine für jede neue Konfiguration, die Sie testen möchten. Dieses Beispiel erstellt zwei Variationen: Baseline, die widerspiegelt, was Ihre Anwendung bereits in der Produktion ausliefert, und Grounded, high reasoning, eine Challenger-Variation, die einen überarbeiteten, expliziteren Prompt mit einem stärkeren Modell und mehr Reasoning-Aufwand kombiniert.

1. Klicken Sie in der linken Seitenleiste auf Set Up > Variations > Add variation.
2. Geben Sie einen Name ein, zum Beispiel Baseline, sowie einen passenden Variation Key, zum Beispiel baseline. Jede Variable ist bereits mit ihrem Standardwert vorausgefüllt, lassen Sie daher alle vier unverändert.
3. Klicken Sie auf Save.
4. Wiederholen Sie diese Schritte für eine zweite Variation namens Grounded, high reasoning (Key grounded_high_reasoning), und bearbeiten Sie dabei alle vier Variablen so, dass sie dem Wert in der Tabelle für diese Variation entsprechen.
5. Klicken Sie auf Save.

Weitere Details finden Sie unter Feature-Variationen definieren.

​

Ziele für Geschäftsauswirkung, KI-Qualität und Latenz anhängen

Hängen Sie mehrere Ziele an das Feature Flag an, damit Sie Variationen anhand der Ergebnisse vergleichen können, für die Ihr Team verantwortlich ist, nicht nur anhand der Antwortqualität. Da Kameleoon eine einheitliche Plattform ist, können Sie jedes bereits in Ihrer Organisation vorhandene Ziel anhängen oder ein Ziel erstellen, das speziell auf Ihre LLM-basierte Funktion zugeschnitten ist. Dieses Beispiel hängt drei Ziele an, jeweils eines aus jeder Metrikkategorie, die für einen KI-Agenten relevant ist: Erstellen Sie alle drei als Custom goals, die Ihr Backend auslöst, da Ihre Anwendung sie auslöst und nicht der Browser des Besuchers. Wählen Sie beim Erstellen jedes Ziels Custom goal als Type aus, und wählen Sie dann die Option für ein Backend-Ereignis über SDK.

1. Klicken Sie auf der Seite des Flags im Menü Set Up auf Goals > Add goal.
2. Wählen Sie ein vorhandenes Ziel aus, oder klicken Sie auf Create a new goal, um eines zu definieren. Fügen Sie zuerst Ticket resolved without escalation hinzu, da Kameleoon das erste angehängte Ziel automatisch als Primary goal festlegt.
3. Klicken Sie auf Save.
4. Wiederholen Sie diese Schritte für Response groundedness score und Response latency, die Kameleoon als Secondary goals anhängt.

Response groundedness score und Response latency tragen keinen numerischen Wert. Ihre Anwendung entscheidet, ob eine bestimmte Antwort einen akzeptablen Schwellenwert verletzt hat, entweder zu langsam oder zu wenig fundiert, und löst die Conversion des Ziels nur aus, wenn das der Fall war. Kameleoon meldet dann die Conversion-Rate jedes Ziels pro Variation und zeigt Ihnen so, welcher Anteil der Antworten diesen Schwellenwert verletzt hat. Weitere Details zu Zieltypen, einschließlich wie Sie ein benutzerdefiniertes Ziel von Ihrem Backend aus auslösen, finden Sie unter Ein Ziel erstellen.

​

Das Experiment ausrollen

Fügen Sie eine Experiment-Regel hinzu, die den Traffic auf Ihre beiden Variationen verteilt, und schalten Sie das Flag dann ein, um mit der Datenerfassung zu beginnen. Das Menü Add a rule gruppiert Regeln nach Zweck. Feature testing enthält die Experiment-Regel, die den Traffic aufteilt und einen statistisch signifikanten Vergleich zwischen Variationen misst, während Feature delivery Progressive delivery und Targeted delivery enthält, die eine einzelne Variation schrittweise oder an ein bestimmtes Segment ausliefern, ohne Varianten zu vergleichen. Ein A/B-Test benötigt die Experiment-Regel.

1. Wählen Sie im Rollout Planner die Umgebung aus, die Sie anvisieren möchten, zum Beispiel Production.
2. Klicken Sie auf Add a rule, und wählen Sie dann unter Feature testing die Option Experiment aus.
3. Legen Sie unter Variations to serve Baseline als Control fest, und fügen Sie Grounded, high reasoning als Treatment hinzu. Kameleoon misst die Ergebnisse jedes Treatments gegen die Control, daher muss die Control die Konfiguration sein, die Sie bereits in der Produktion einsetzen.
4. Legen Sie die Traffic-Verteilung auf die beiden Variationen fest, zum Beispiel je 50 %.
5. Legen Sie das Targeting der Regel so fest, dass es die Besucher einschließt, die Sie testen möchten, zum Beispiel alle Besucher, die ein Support-Gespräch beginnen.
6. Wählen Sie im Drop-down Then, for everyone else in production, serve Baseline aus. Besucher, die außerhalb des Targetings der Regel liegen, erhalten dann Ihre aktuelle, validierte Konfiguration, und Ihre Anwendung erhält weiterhin einen vollständigen Variablensatz für sie.
7. Schalten Sie den ON/OFF-Schalter des Flags auf ON.
8. Klicken Sie auf Save.

Weitere Details finden Sie unter Feature-Experimente erstellen. Nachdem Sie die Regel gespeichert haben, beginnt Kameleoon damit, Besuchern eine Konfiguration zuzuweisen und die entsprechenden Variablen auszuliefern. Um einen Wert später zu ändern oder eine Variation hinzuzufügen, bearbeiten Sie ihn direkt in der Kameleoon-Plattform. Sie müssen Ihre Anwendung nicht neu bereitstellen, um diese Änderungen vorzunehmen.

​

Die Konfiguration in Ihrer Anwendung abrufen

Installieren Sie das Kameleoon Python SDK, rufen Sie dann die dem Besucher zugewiesene Konfiguration ab, und verfolgen Sie im Verlauf des Tickets des Besuchers eine Conversion für jedes Ziel. Das gleiche Muster gilt für jedes serverseitige Kameleoon SDK, einschließlich Node.js, Java und Go. Da Kameleoon nur die Konfigurationswerte liefert, funktioniert dasselbe Muster auch mit jedem Agenten-Framework, etwa dem OpenAI Agents SDK, dem Claude Agent SDK oder LangChain. Der meiste Agenten-Code läuft auf Python oder TypeScript, wählen Sie also, was zu Ihrer Anwendung passt.

1. Installieren Sie das SDK als Abhängigkeit:
   pip install kameleoon-client-python
   
2. Initialisieren Sie den Client mit Ihrem Site Code und Ihren Zugangsdaten. Setzen Sie environment auf dieselbe Rollout-Planner-Umgebung, in der Ihre Experiment-Regel liegt, da das SDK sonst die Regeln einer anderen Umgebung auswertet:
   from kameleoon import KameleoonClientConfig, KameleoonClientFactory
   
   SITE_CODE = "a8st4f59bj"
   FEATURE_KEY = "ai_support_agent"
   TASK_GOAL_ID = 12345      # "Ticket resolved without escalation"
   QUALITY_GOAL_ID = 12346   # "Response groundedness score"
   LATENCY_GOAL_ID = 12347   # "Response latency"
   
   configuration = KameleoonClientConfig(
       client_id="your-client-id",
       client_secret="your-client-secret",
       environment="production",
   )
   kameleoon_client = KameleoonClientFactory.create(SITE_CODE, configuration)
   
   if not await kameleoon_client.wait_init_async():
       # Die Initialisierung des SDK ist fehlgeschlagen. Verwenden Sie Ihre Produktionskonfiguration als Fallback.
       ...
   
3. Rufen Sie die zugewiesene Konfiguration ab, bevor Sie Ihr LLM aufrufen, und verfolgen Sie im Verlauf des Tickets des Besuchers eine Conversion für jedes Ziel:
   from anthropic import AsyncAnthropic
   
   judge_client = AsyncAnthropic()
   
   # Spiegelt die Standardwerte des Flags wider, zur Verwendung, wenn das SDK Kameleoon nicht erreichen kann.
   FALLBACK_CONFIG = {
       "system_prompt": "You are the support assistant for Kameleoon's help center. ...",
       "model": "claude-sonnet-5",
       "reasoning_effort": "low",
       "retrieval_top_k": 3,
   }
   
   # Eine Antwort verletzt die Latenz-Guardrail oberhalb dieses Werts.
   LATENCY_THRESHOLD_MS = 5000
   # Eine Antwort verletzt die Fundiertheits-Guardrail unterhalb dieses Werts.
   QUALITY_THRESHOLD = 0.7
   
   
   def get_agent_config_for_visitor(visitor_code: str) -> dict:
       try:
           variation = kameleoon_client.get_variation(visitor_code, FEATURE_KEY)
       # Diese Exception-Klassen sind Teil des Kameleoon SDK.
       except (FeatureNotFound, FeatureEnvironmentDisabled, VisitorCodeInvalid):
           # Der Besucher ist nicht Teil des Experiments, daher wird die bewährte Konfiguration ausgeliefert.
           return FALLBACK_CONFIG
   
       variables = variation.variables
       if not variables:
           return FALLBACK_CONFIG
   
       return {
           "system_prompt": variables["system_prompt"].value,
           "model": variables["model"].value,
           "reasoning_effort": variables["reasoning_effort"].value,
           "retrieval_top_k": int(variables["retrieval_top_k"].value),
       }
   
   
   def track_ticket_resolved(visitor_code: str) -> None:
       kameleoon_client.track_conversion(visitor_code, TASK_GOAL_ID)
   
   
   # LLM-as-a-Judge: Extrahiert die sachlichen Behauptungen in `response` und bewertet
   # den Anteil, den `retrieved_context` stützt.
   async def score_response_groundedness(retrieved_context: str, response: str) -> float:
       judge_prompt = (
           "List the factual claims in RESPONSE. For each claim, check "
           "whether CONTEXT supports it. Return only a number from 0 to 1: "
           "the fraction of RESPONSE claims that CONTEXT supports.\n\n"
           f"CONTEXT:\n{retrieved_context}\n\nRESPONSE:\n{response}"
       )
       judge_reply = await judge_client.messages.create(
           model="claude-opus-5",
           max_tokens=10,
           messages=[{"role": "user", "content": judge_prompt}],
       )
       return float(judge_reply.content[0].text)
   
   
   def track_quality_score(visitor_code: str, score: float) -> None:
       if score < QUALITY_THRESHOLD:
           kameleoon_client.track_conversion(visitor_code, QUALITY_GOAL_ID)
   
   
   def track_response_latency(visitor_code: str, latency_ms: float) -> None:
       if latency_ms > LATENCY_THRESHOLD_MS:
           kameleoon_client.track_conversion(visitor_code, LATENCY_GOAL_ID)
   
   Rufen Sie get_agent_config_for_visitor() mit dem visitor_code des Besuchers auf, bevor Sie eine Anfrage an Ihr LLM senden, und verwenden Sie die zurückgegebenen Werte, um die Anfrage aufzubauen: den System-Prompt, das Modell, den Reasoning-Aufwand und die Anzahl der abgerufenen Dokumente. Rufen Sie track_ticket_resolved() auf, wenn der Agent das Problem des Besuchers löst, ohne an einen Menschen zu eskalieren. Nachdem der Agent geantwortet hat, rufen Sie score_response_groundedness() mit den abgerufenen Dokumenten und der generierten Antwort auf, und übergeben Sie den zurückgegebenen Score dann an track_quality_score(). Rufen Sie track_response_latency() mit der Antwortzeit in Millisekunden nach jedem LLM-Aufruf auf. Sowohl track_quality_score() als auch track_response_latency() verfolgen eine Conversion nur, wenn der Wert seinen Schwellenwert verletzt, sodass eine Antwort, die innerhalb beider Guardrails bleibt, keines der beiden Ziele auslöst. score_response_groundedness() ist ein minimales LLM-as-a-Judge-Beispiel: Es fordert ein Modell auf, die Behauptungen der Antwort mit dem abgerufenen Kontext zu vergleichen und den unterstützten Anteil zurückzugeben. RAGAS’ Factual-Correctness-Metrik bewertet dieselbe grundlegende Idee, und Sie können sie oder ein anderes Evaluierungs-Framework, das Ihr Team bereits verwendet, anstelle eines selbst geschriebenen Judge-Prompts einsetzen. Kameleoon meldet dann die Conversion-Rate jedes Ziels pro Variation und zeigt Ihnen so, welcher Anteil der Antworten die Qualitäts- oder Latenz-Guardrail verletzt hat, statt den rohen Score- oder Millisekundenwert selbst zu erfassen.

​

Überwachen und iterieren

Öffnen Sie die Ergebnisseite des Feature Flags, um Baseline und Grounded, high reasoning anhand aller drei angehängten Ziele zu vergleichen. Kameleoon verfolgt Expositionen und Conversions automatisch, sobald Ihre Anwendung get_variation() und track_conversion() aufruft, sodass Sie keine zusätzliche Instrumentierung benötigen. Betrachten Sie die drei Ziele gemeinsam und nicht isoliert. Der Challenger in diesem Beispiel setzt ein größeres Modell mit höherem Reasoning-Aufwand ein und ruft mehr Dokumente ab, kostet also pro Konversation mehr und verletzt mit höherer Wahrscheinlichkeit die Latenz-Guardrail. Ein Gewinn bei Ticket resolved without escalation rechtfertigt diesen Kompromiss nur, wenn Response latency und Response groundedness score beim Challenger nicht häufiger konvertieren als bei Baseline. Wenn sich das primäre Ziel verbessert, die Conversion-Rate eines Guardrails aber stärker ansteigt, als Sie bereit sind zu akzeptieren, liefern Sie weiterhin Baseline aus und verfeinern Sie den Challenger. Wenn ein Challenger gewinnt, übernehmen Sie ihn: Aktualisieren Sie die Default Value jeder Variable auf die gewinnende Konfiguration, damit sie zur neuen bewährten Baseline wird, und deaktivieren Sie anschließend die Experiment-Regel, oder verwenden Sie die Variation für Ihre nächste Hypothese weiter. Weitere Details finden Sie unter Die Gesamtergebnisse eines Feature Flags anzeigen.

​

Nächste Schritte

• Lesen Sie die Python SDK-Referenz für erweiterte Optionen wie Custom Data, geräteübergreifende Experimente und Targeting-Bedingungen.
• Hängen Sie präzise Segmentierungskriterien an, um das Experiment auf eine bestimmte Zielgruppe auszurichten, zum Beispiel nur Tickets, die mit einem bestimmten Produktbereich getaggt sind.
• Fügen Sie neben der Latenz ein Ziel für Token-Kosten hinzu, das die pro Konversation verbrauchten Tokens als numerisches benutzerdefiniertes Ziel erfasst, damit Sie den Kostenunterschied zwischen einer Sonnet- und einer Opus-Konfiguration direkt beziffern können. Siehe Ein Ziel erstellen.
• Fügen Sie ein Ziel für Kontextrelevanz hinzu, um zu prüfen, ob eine Erhöhung von retrieval_top_k tatsächlich verbessert, welche Dokumente der Agent abruft, da eine fundierte Antwort trotzdem aus den falschen Dokumenten stammen kann. Siehe Ein Ziel erstellen.
• Fügen Sie ein Ziel für direktes Nutzerfeedback hinzu, etwa ein Daumen-hoch/Daumen-runter-Element nach jeder Antwort, um die Zufriedenheit der Besucher zusammen mit den Verhaltenssignalen zu erfassen, die dieses Beispiel bereits verfolgt. Siehe Ein Ziel erstellen.
• Fügen Sie weitere Variablen hinzu, um andere Teile der Agenten-Konfiguration zu testen, etwa die Temperatur, Tool-Definitionen oder ein Fallback-Modell für Wiederholungsversuche. Siehe Feature-Variablen definieren.
• Validieren Sie den Schwellenwert Ihres Ziels Response groundedness score, indem Sie eine Stichprobe automatisierter Scores mit einem menschlichen Review vergleichen, bevor Sie ihm im großen Maßstab vertrauen. Siehe Ziele für Feature Flags erstellen.