Experimente con prompts LLM y configuraciones de agentes de IA

Las aplicaciones basadas en un modelo de lenguaje extenso (LLM) y los agentes de IA son no deterministas. Cambiar un prompt, un modelo, una estrategia de recuperación, una configuración de herramientas o un flujo de trabajo del agente puede afectar a la calidad de las respuestas, al coste operativo, a la latencia y al comportamiento de los usuarios de formas distintas y difíciles de predecir. Los frameworks de evaluación como RAGAS puntúan si una respuesta individual cumple un umbral de calidad, pero esa puntuación no indica si el cambio ayuda a los usuarios a lograr aquello para lo que llegaron a su producto. Puede utilizar las funcionalidades de Kameleoon Feature Experimentation para personalizar, probar y lanzar la configuración que hay detrás de una aplicación de IA generativa o un agente de IA. Una variable de feature almacena una única pieza de esa configuración (un prompt, un parámetro del modelo, una estrategia de recuperación, una definición de herramienta), de modo que su equipo pueda gestionarla fuera del código de la aplicación. Cada variación representa una configuración candidata, lo que le permite iterar, experimentar y publicar cambios de forma más segura, sin volver a implementar la aplicación. Por ejemplo, un agente de IA de atención al cliente puede exponer su prompt de sistema, el modelo, el nivel de esfuerzo de razonamiento y los ajustes de recuperación como cuatro variables independientes, de modo que pueda probar una combinación nueva de las cuatro a la vez en lugar de esperar a un despliegue por cada una. Reparta el tráfico entre las variaciones y compare su impacto mediante varios tipos de métricas:

• Métricas de calidad de IA, como la precisión, la fundamentación, la relevancia, la calidad del contexto, la seguridad o el cumplimiento normativo
• Métricas de rendimiento del agente, como el uso correcto de herramientas o la finalización de tareas
• Métricas operativas, como la latencia, el consumo de tokens, los errores y el coste
• Métricas de usuario y de negocio, como la satisfacción, la escalación, la conversión, la retención y los ingresos

Como la configuración vive en un feature flag en lugar de en su código fuente, puede añadir, editar o revertir una variación directamente desde la plataforma Kameleoon en cualquier momento.

​

La evaluación y la experimentación resuelven problemas distintos

La evaluación determina si la salida individual de un modelo o de un agente cumple un estándar de calidad definido. Las herramientas de observabilidad permiten inspeccionar los prompts, las respuestas, las trazas, los pasos de recuperación y las llamadas a herramientas que hay detrás de esa salida. La experimentación determina si un cambio en la configuración subyacente produce una mejora medible para los usuarios o para el negocio: una pregunta que ni la evaluación ni la observabilidad responden. Por ejemplo, un juez basado en un LLM podría puntuar el prompt de sistema reescrito de un agente de atención al cliente como más fundamentado que el actual. Un experimento de Kameleoon responde a las preguntas de las que su equipo es responsable: si esa misma configuración resuelve más tickets sin escalarlos a un humano, y qué coste tiene en latencia y en consumo de tokens conseguirlo. Kameleoon no sustituye su stack de observabilidad o evaluación de LLM. Introduzca en Kameleoon las puntuaciones de evaluadores como RAGAS, un juez basado en un LLM o un proceso de revisión humana, en forma de objetivo personalizado, y haga seguimiento de esas puntuaciones junto con los objetivos de comportamiento y de negocio que su experimento ya mide. Sus señales de calidad a nivel de modelo se conectan entonces con una medición estadísticamente fiable del impacto real en los usuarios. En la mayoría de los experimentos de IA, combine varios tipos de métricas en lugar de basarse en uno solo:

• Establezca un resultado de usuario o de negocio como objetivo principal.
• Haga seguimiento de las métricas de calidad de IA como objetivos secundarios o salvaguardas.
• Supervise la latencia, el coste, los errores y la seguridad como salvaguardas operativas.
• Valide los jueces automatizados frente a una muestra de ejemplos revisados por humanos antes de confiar en sus puntuaciones a gran escala.

​

Cómo funciona

Un experimento sobre una aplicación LLM o un agente de IA pasa por cinco etapas en Kameleoon:

1. Un feature flag almacena la configuración. Cada parte de la configuración, como un prompt o el nombre de un modelo, se convierte en una variable de feature del flag.
2. Cada variación establece sus propios valores. Una variación es una configuración candidata completa, con un valor para cada variable.
3. El SDK asigna una variación a cada visitante. Cuando un visitante llega a su aplicación, su código solicita el flag y recibe los valores de la variación asignada, y después los utiliza para llamar al LLM o configurar el agente.
4. Los objetivos registran lo que ha ocurrido. Su aplicación hace seguimiento de una conversión para cada objetivo adjunto al flag, incluida una conversión de salvaguarda que se activa solo cuando una respuesta incumple un umbral aceptable de calidad o de latencia.
5. La página de resultados compara las variaciones. Después de reunir suficiente tráfico, compare las variaciones en todos los objetivos adjuntos para decidir qué configuración lanzar.

​

Requisitos previos

• Una cuenta de Kameleoon con un proyecto configurado para Feature Experimentation.
• El ID de cliente y el secreto de cliente de su cuenta. Para encontrar estos valores, consulte Credenciales de API.
• Una aplicación del lado del servidor en la que pueda instalar un SDK de Kameleoon, por ejemplo una aplicación Python.

​

Configurar su experimento de agente de IA en Kameleoon

Los siguientes pasos construyen un experimento concreto: ¿un prompt de sistema reescrito, combinado con un modelo más potente y un mayor esfuerzo de razonamiento, ayuda a un agente de IA de atención al cliente a resolver más tickets por sí mismo, y mantiene la latencia dentro de un rango aceptable mientras lo hace? Configure el feature flag, las variaciones y los objetivos de seguimiento en la plataforma Kameleoon antes de tocar su código de aplicación.

​

Crear el feature flag

Cree un feature flag para almacenar la configuración de su agente y controlar el lanzamiento de su experimento.

1. En la aplicación Kameleoon, haga clic en Features > Flags & Experiments > New feature flag.
2. Introduzca un nombre, por ejemplo AI support agent config, y seleccione el proyecto para el flag.
3. En el campo Description, indique qué controla el flag, por ejemplo “Controla el prompt de sistema, el modelo, el esfuerzo de razonamiento y los ajustes de recuperación del chatbot de soporte”, para que otros miembros de su equipo entiendan su propósito.
4. Haga clic en Validate.
5. Kameleoon genera una clave de feature a partir del nombre del flag. Anote la clave generada, o edítela como ai_support_agent. El código de su aplicación identifica el flag por esta clave, no por su nombre, así que ambas deben coincidir.

Los flags nuevos empiezan en el estado OFF. Active el flag en el Rollout Planner después de terminar de configurarlo. Para más detalles, consulte Crear un feature flag.

​

Almacenar la configuración del agente en variables de feature

Añada una variable de feature por cada parte de la configuración del agente que quiera probar, de modo que pueda cambiar cualquiera de ellas desde la plataforma Kameleoon sin editar el código de su aplicación. Este ejemplo prueba cuatro variables:

1. En la página del flag, en la barra lateral izquierda, haga clic en Set Up > Variables > Add Variable.
2. Establezca el Type de la variable según la tabla, ya sea String o Number.
3. Introduzca la Variable Key de la tabla, por ejemplo system_prompt.
4. Establezca el Default Value con el valor que su aplicación utiliza hoy en producción. Cada variación que cree más adelante empieza rellenada previamente con estos valores, así que unos valores predeterminados precisos le ahorran trabajo y le dan una configuración fiable a la que recurrir.
5. Haga clic en Save.
6. Repita estos pasos para cada una de las variables restantes de la tabla.

Para más detalles, consulte Definir variables de feature.

​

Crear sus variaciones

Una regla de entrega solo puede servir Off o una variación que haya creado usted mismo, así que una comparación A/B necesita una variación para su configuración actual, además de una por cada configuración nueva que quiera probar. Este ejemplo crea dos variaciones: Baseline, que refleja lo que su aplicación ya sirve en producción, y Grounded, high reasoning, una variación retadora que combina un prompt reescrito y más explícito con un modelo más potente y más esfuerzo de razonamiento.

1. En la barra lateral izquierda, haga clic en Set Up > Variations > Add variation.
2. Introduzca un Name, por ejemplo Baseline, y una Variation Key correspondiente, por ejemplo baseline. Cada variable aparece rellenada previamente con su valor predeterminado, así que deje las cuatro sin cambios.
3. Haga clic en Save.
4. Repita estos pasos para una segunda variación llamada Grounded, high reasoning (clave grounded_high_reasoning), editando cada una de las cuatro variables para que coincida con el valor de la tabla para esta variación.
5. Haga clic en Save.

Para más detalles, consulte Definir variaciones de feature.

​

Adjuntar objetivos de impacto en el negocio, calidad de IA y latencia

Adjunte varios objetivos al feature flag para poder comparar las variaciones en función de los resultados de los que su equipo es responsable, no solo de la calidad de las respuestas. Como Kameleoon es una plataforma unificada, puede adjuntar cualquier objetivo que ya exista en su organización, o crear un objetivo específico para su función basada en un LLM. Este ejemplo adjunta tres objetivos, uno de cada categoría de métrica relevante para un agente de IA: Cree los tres como Custom goals que active su backend, ya que es su aplicación la que los dispara, no el navegador del visitante. Al crear cada objetivo, seleccione Custom goal como Type, y después elija la opción para un evento de backend a través del SDK.

1. En la página del flag, en el menú Set Up, haga clic en Goals > Add goal.
2. Seleccione un objetivo existente, o haga clic en Create a new goal para definir uno. Añada primero Ticket resolved without escalation, ya que Kameleoon establece automáticamente el primer objetivo que adjunte como Primary goal.
3. Haga clic en Save.
4. Repita estos pasos para Response groundedness score y Response latency, que Kameleoon adjunta como Secondary goals.

Response groundedness score y Response latency no transportan un valor numérico. Su aplicación decide si una respuesta concreta incumple un umbral aceptable, ya sea por ser demasiado lenta o por no estar suficientemente fundamentada, y activa la conversión del objetivo solo cuando lo hace. Kameleoon reporta entonces la tasa de conversión de cada objetivo por variación, indicando qué fracción de las respuestas incumplió ese umbral. Para más detalles sobre los tipos de objetivos, incluido cómo activar un objetivo personalizado desde su backend, consulte Crear un objetivo.

​

Desplegar el experimento

Añada una regla Experiment que reparta el tráfico entre sus dos variaciones y, después, active el flag para empezar a recopilar datos. El menú Add a rule agrupa las reglas por finalidad. Feature testing contiene la regla Experiment, que reparte el tráfico y mide una comparación estadísticamente significativa entre variaciones, mientras que Feature delivery contiene Progressive delivery y Targeted delivery, que lanzan una única variación de forma gradual o hacia un segmento específico sin comparar entre sí. Un test A/B necesita la regla Experiment.

1. En Rollout Planner, seleccione el entorno que quiera segmentar, por ejemplo Production.
2. Haga clic en Add a rule y, después, en Feature testing, seleccione Experiment.
3. En Variations to serve, establezca Baseline como Control y añada Grounded, high reasoning como Treatment. Kameleoon mide los resultados de cada tratamiento frente al control, así que el control debe ser la configuración que ya ejecuta en producción.
4. Establezca la distribución de tráfico entre las dos variaciones, por ejemplo un 50 % cada una.
5. Establezca el targeting de la regla para incluir a los visitantes que quiera probar, por ejemplo todos los visitantes que abran una conversación de soporte.
6. En el desplegable Then, for everyone else in production, serve, seleccione Baseline. Los visitantes que queden fuera del targeting de la regla reciben entonces su configuración actual y validada, y su aplicación sigue obteniendo un conjunto completo de variables para ellos.
7. Ponga el interruptor ON/OFF del flag en ON.
8. Haga clic en Save.

Para más detalles, consulte Crear feature experiments. Después de guardar la regla, Kameleoon empieza a asignar visitantes a una configuración y a servir las variables correspondientes. Para cambiar un valor o añadir una variación más adelante, edítelo directamente en la plataforma Kameleoon. No necesita volver a implementar su aplicación para realizar estos cambios.

​

Recuperar la configuración en su aplicación

Instale el SDK de Python de Kameleoon, después recupere la configuración asignada al visitante y haga seguimiento de una conversión para cada objetivo a medida que avanza el ticket del visitante. El mismo patrón se aplica a cualquier SDK de Kameleoon del lado del servidor, incluidos Node.js, Java y Go. Como Kameleoon solo proporciona los valores de configuración, el mismo patrón también funciona con cualquier framework de agentes, como el OpenAI Agents SDK, el Claude Agent SDK o LangChain. La mayoría del código de agentes se ejecuta en Python o TypeScript, así que elija el que coincida con su aplicación.

1. Instale el SDK como dependencia:
   pip install kameleoon-client-python
   
2. Inicialice el cliente con su site code y sus credenciales. Establezca environment en el mismo entorno de Rollout Planner que contiene su regla Experiment; en caso contrario, el SDK evalúa las reglas de otro entorno:
   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():
       # El SDK no se ha podido inicializar. Recurra a su configuración de producción.
       ...
   
3. Recupere la configuración asignada antes de llamar a su LLM, y haga seguimiento de una conversión para cada objetivo a medida que avanza el ticket del visitante:
   from anthropic import AsyncAnthropic
   
   judge_client = AsyncAnthropic()
   
   # Refleja los valores predeterminados del flag, para usar cuando el SDK no puede conectar con Kameleoon.
   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,
   }
   
   # Una respuesta incumple la salvaguarda de latencia por encima de este valor.
   LATENCY_THRESHOLD_MS = 5000
   # Una respuesta incumple la salvaguarda de fundamentación por debajo de este valor.
   QUALITY_THRESHOLD = 0.7
   
   
   def get_agent_config_for_visitor(visitor_code: str) -> dict:
       try:
           variation = kameleoon_client.get_variation(visitor_code, FEATURE_KEY)
       # Estas clases de excepción se incluyen con el SDK de Kameleoon.
       except (FeatureNotFound, FeatureEnvironmentDisabled, VisitorCodeInvalid):
           # El visitante no está en el experimento, así que sirva la configuración conocida como válida.
           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)
   
   
   # Juez basado en un LLM: extrae las afirmaciones fácticas de `response` y
   # puntúa la fracción que `retrieved_context` respalda.
   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)
   
   Llame a get_agent_config_for_visitor() con el visitor_code del visitante antes de enviar una solicitud a su LLM, y utilice los valores devueltos para construir la solicitud: el prompt de sistema, el modelo, el esfuerzo de razonamiento y el número de documentos recuperados. Llame a track_ticket_resolved() cuando el agente resuelva el problema del visitante sin escalarlo a un humano. Después de que el agente responda, llame a score_response_groundedness() con los documentos que recuperó y la respuesta que generó, y después pase la puntuación devuelta a track_quality_score(). Llame a track_response_latency() con el tiempo de respuesta en milisegundos después de cada llamada al LLM. Tanto track_quality_score() como track_response_latency() hacen seguimiento de una conversión solo cuando el valor incumple su umbral, así que una respuesta que se mantiene dentro de ambas salvaguardas no activa ninguno de los dos objetivos. score_response_groundedness() es un ejemplo mínimo de juez basado en un LLM: pide a un modelo que compare las afirmaciones de la respuesta con el contexto recuperado y devuelva la fracción que respalda. La métrica Factual Correctness de RAGAS puntúa la misma idea subyacente, y puede sustituirla, o sustituir otro framework de evaluación que su equipo ya utilice, por un prompt de juez hecho a mano. Kameleoon reporta entonces la tasa de conversión de cada objetivo por variación, indicando qué fracción de las respuestas incumplió la salvaguarda de calidad o de latencia, en lugar de hacer seguimiento de la puntuación bruta o del valor en milisegundos.

​

Supervisar e iterar

Abra la página de resultados del feature flag para comparar Baseline y Grounded, high reasoning en los tres objetivos adjuntos. Kameleoon hace seguimiento de las exposiciones y las conversiones automáticamente en cuanto su aplicación llama a get_variation() y track_conversion(), por lo que no necesita ninguna instrumentación adicional. Analice los tres objetivos en conjunto, no de forma aislada. La variación retadora de este ejemplo ejecuta un modelo más grande con un mayor esfuerzo de razonamiento y recupera más documentos, así que cuesta más por conversación y tiene más probabilidades de superar la salvaguarda de latencia. Una mejora en Ticket resolved without escalation solo justifica ese coste si Response latency y Response groundedness score no convierten con más frecuencia en la variación retadora que en Baseline. Si el objetivo principal mejora pero la tasa de conversión de una salvaguarda supera lo que está dispuesto a aceptar, siga sirviendo Baseline y refine la variación retadora. Cuando una variación retadora gane, promociónela: actualice el Default Value de cada variable con la configuración ganadora para que se convierta en la nueva base conocida como válida, y después retire la regla de experimento o reutilice la variación para su siguiente hipótesis. Para más detalles, consulte Ver los resultados generales de su feature flag.

​

Próximos pasos

• Lea la referencia del SDK de Python para conocer opciones avanzadas como el custom data, la experimentación cross-device y las condiciones de targeting.
• Adjunte criterios de segmentación precisos para segmentar el experimento hacia una audiencia específica, por ejemplo solo los tickets etiquetados con un área de producto determinada.
• Añada un objetivo de coste de tokens junto a la latencia, haciendo seguimiento de los tokens consumidos por conversación como un custom goal numérico, para poder calcular directamente la diferencia de coste entre una configuración de Sonnet y una de Opus. Consulte Crear un objetivo.
• Añada un objetivo de relevancia del contexto para comprobar si aumentar retrieval_top_k mejora realmente los documentos que recupera el agente, ya que una respuesta fundamentada puede seguir basándose en los documentos equivocados. Consulte Crear un objetivo.
• Añada un objetivo de feedback directo del usuario, como un control de me gusta o no me gusta después de cada respuesta, para capturar la satisfacción del visitante junto con las señales de comportamiento de las que este ejemplo ya hace seguimiento. Consulte Crear un objetivo.
• Añada más variables para probar otras partes de la configuración del agente, como la temperatura, las definiciones de herramientas o un modelo de reserva para reintentos. Consulte Definir variables de feature.
• Valide su umbral de Response groundedness score comparando una muestra de puntuaciones automatizadas con una revisión humana antes de confiar en él a gran escala. Consulte Crear objetivos para feature flags.