Escuchar al usuario: feedback como señal

5.1El 95% que pasa sin que nadie escuche

En N5·L2 montaste evals online sobre el tráfico real de Aurora. Tu LLM-as-judge del N2 corre en producción, pero con sampling: evalúa el 5% de las trazas. Más sería disparar la factura.

El 5% está cubierto. El otro 95% pasa sin una sola señal de calidad.

Y sin embargo, ese 95% no es silencio. Mira la actividad de un martes cualquiera en el agente de Aurora:

• Tres clientes pulsan el pulgar abajo bajo una respuesta sobre reembolsos.
• Cuarenta clientes reformulan la misma pregunta en el turno siguiente, con otras palabras.
• Doce abandonan la conversación a mitad, sin volver.

Esos sesenta y cinco usuarios te están diciendo si la respuesta sirvió. El que pulsó el pulgar te lo dice con una palabra. El que reformuló te lo dice con su frustración. El que abandonó te lo dice con el silencio.

Esa señal existe ahora mismo. Y la estás tirando a la basura.

5.2Qué vas a poder hacer

Al terminar esta lección sabrás:

• Distinguir feedback explícito (el usuario lo emite a propósito) de feedback implícito (lo deduces de su comportamiento), y nombrar el sesgo de cada uno.
• Instrumentar Aurora para registrar un thumbs down y un reintento como scores en Langfuse, usando la API real del SDK.
• Detectar reward hacking: por qué optimizar una métrica de feedback puede degradar la calidad real, y cómo no dejarte engañar.

Necesitas saber antes:

• Qué es un score en Langfuse y sobre qué entidades se aplica (N2: traces, observations, sessions, dataset runs; tipos Numeric, Categorical, Boolean, Text).
• Qué cubre el sampling de un eval online y qué deja fuera (N5·L2).

Esta lección no entrena ningún modelo con el feedback. Convierte el feedback en señal medible. Qué hacer con esa señal en un experimento llega en L4.

5.3Recupera

Antes de seguir, responde mentalmente. No mires lo de abajo hasta tener una respuesta.

1. En N2 creaste scores con tu LLM-as-judge. ¿Sobre qué entidades de Langfuse se puede colgar un score? ¿Qué tipos de valor admite?
2. Del sampling de L2: si evalúas el 5% de las trazas, ¿qué porcentaje del tráfico queda sin ninguna señal de calidad del juez?
3. Un cliente de Aurora recibe una respuesta, no pulsa nada, y vuelve a preguntar lo mismo con otras palabras. ¿Eso es una señal de calidad? ¿De qué tipo?

La respuesta a la 1: un score se cuelga de una traza, una observación, una sesión o un dataset run, con valor NUMERIC, CATEGORICAL, BOOLEAN o TEXT. La 2: el 95% queda sin señal del juez. La 3 es la pregunta que abre esta lección: sí es una señal, pero el cliente no la emitió a propósito. La dedujiste de su conducta. Eso tiene nombre y lo definimos ahora.

5.4El concepto: dos formas de escuchar

Empecemos por lo concreto —los sesenta y cinco usuarios del martes— y subamos a la distinción que los ordena.

Explícito frente a implícito

El feedback explícito es la señal que el usuario emite a propósito para evaluarte: un pulgar arriba o abajo, una estrella, un "esto no me sirve". El cliente decide darte esa información.

El feedback implícito es la señal que deduces de su comportamiento, sin que el usuario quisiera evaluarte: que reformule la pregunta, que copie tu respuesta, que la acepte y siga, que abandone. El cliente no te calificó; tú interpretas lo que hizo.

Una analogía: el feedback explícito es la encuesta que rellenas al salir del restaurante; el implícito es si dejaste el plato a medias. La analogía falla en un punto. La encuesta y el plato miden lo mismo (te gustó). Pero un thumbs down y un reintento pueden medir cosas distintas: uno juzga la respuesta, el otro quizá solo refleja una pregunta mal formulada por el cliente.

Langfuse capta ambos como scores. Para el explícito, la doc oficial documenta dos vías: desde el front, langfuse.score.create({ traceId, name, value, comment }) ligando al traceId; desde el server, langfuse.create_score(...) (Langfuse docs, user-feedback, jun 2026). El implícito no tiene un botón: lo derivas tú de las trazas y lo escribes como score igual.

El trade-off que define todo el tema

Cada tipo de feedback paga un precio. Esta es la idea central de la lección, así que léela despacio.

El feedback explícito es señal clara pero de baja adopción. Cuando alguien pulsa el pulgar abajo, la intención es inequívoca: esa respuesta no sirvió. Pero casi nadie pulsa. Tienes pocas muestras y muy fiables.

El feedback implícito es más volumen pero requiere interpretación. Tienes reintentos, copias y abandonos a montones, pero ninguno viene etiquetado. ¿El cliente reformuló porque tu respuesta fue mala, o porque su primera pregunta fue ambigua? (Langfuse docs, user-feedback, jun 2026.)

Aquí va el matiz honesto, y es el que distingue a quien entiende esto de quien lo cita de memoria. La investigación reciente lo mide: el feedback implícito es "informative yet noisy as a learning signal" —informativo pero ruidoso como señal de aprendizaje—. Ayuda en tareas simples (benchmark MTBench), pero no en tareas complejas (WildBench) (Liu, Zhang & Choi, "Implicit User Feedback in Human-LLM Dialogues", jun 2025).

Traducido a Aurora: para "¿el agente entendió que el cliente pedía un reembolso?" —tarea simple— el implícito sirve. Para "¿la política que recuperó era la correcta y la aplicó bien?" —tarea compleja, el reembolso fantasma del N0·L1— el implícito te miente con frecuencia. No lo trates como verdad; trátalo como una pista que hay que corroborar.

Reward hacking: cuando optimizar la señal rompe el producto

Es tentador, una vez tienes la señal, optimizar directamente por ella. Resistir esa tentación es el aprendizaje más caro del tema.

El reward hacking ocurre cuando un sistema optimiza tan bien la medida de éxito que deja de perseguir el éxito real. La medida sube; la calidad baja. Es la versión de máquina de "lo que se mide se gestiona, y lo que se gestiona se distorsiona".

El caso documentado: RLUF entrenó un reward model sobre las reacciones de usuario (la probabilidad de un "Love") y logró +28% de Love Reactions en un A/B en vivo. El mismo paper avisa, explícitamente, del riesgo de reward hacking que eso introduce (RLUF, arXiv:2505.14946, may 2025). Más "Loves" no es lo mismo que mejores respuestas.

Llevado a Aurora: imagina un cambio de prompt que sube los thumbs up del 71% al 78% porque el agente ahora promete reembolsos con más alegría. Los usuarios pulsan el pulgar arriba —les encanta que les digan que sí—. Pero la groundedness de tu juez baja: el agente promete reembolsos que la política no permite. Has optimizado la sonrisa del cliente y roto la veracidad. Eso es reward hacking, y por eso nunca miras una sola señal de feedback en aislamiento.

El puente al ground truth, y la prueba en customer support

Dos piezas más cierran el cuadro.

Cuando necesitas señal de calidad certificada —no ruidosa— Langfuse ofrece Annotation Queues: expertos revisan trazas, observaciones o sesiones con Score Configs predefinidas, corrigen outputs y dejan comentarios. Ese material sirve como ground truth (Langfuse docs, annotation-queues, jun 2026). Es la señal explícita de máxima fiabilidad: la de tu propio equipo, no la del usuario anónimo.

¿Funciona esto en un caso como Aurora? Hay evidencia específica de soporte al cliente. El estudio Agent-in-the-Loop de Airbnb recogió feedback de agentes humanos de soporte. Con él, subió el retrieval recall@75 +11.7% y la utilidad de la generación +8.4%, acortando el ciclo de mejora de meses a semanas (Airbnb, "Agent-in-the-Loop", arXiv:2510.06674). Es el caso de uso de Aurora —soporte— no una analogía lejana. El feedback, bien capturado, mueve las métricas que de verdad importan.

5.5Míralo funcionar: dos señales del mismo turno

Vamos a instrumentar Aurora para capturar dos señales del mismo cliente: un thumbs down explícito y un reintento implícito. Es código que corre con la API real del SDK de Langfuse.

Esta sección mezcla dos vías de captura distintas. Léelas enteras primero; después analizamos por qué van separadas.

Señal A — thumbs down explícito como Boolean score

El cliente pulsó el pulgar abajo. Lo registras como un score BOOLEAN sobre la traza de esa conversación. Pero hay un detalle de cuándo llega ese pulgar que decide la API correcta, así que vamos despacio.

El feedback de usuario no llega durante la request: llega después. El agente respondió hace minutos, la traza ya se cerró, y solo entonces el cliente pulsa el pulgar. En ese momento ya no estás dentro del span de aquella conversación —ese contexto se cerró—. Solo tienes una cosa: el trace_id que guardaste. Por eso usas langfuse.create_score(), que liga el score a una traza por su id, sin necesidad de tener un span abierto:

1from langfuse import get_client
2
3langfuse = get_client()
4
5def registrar_feedback_explicito(trace_id: str, le_sirvio: bool, comentario: str | None = None):
6    """El cliente pulsó pulgar arriba/abajo. Señal clara, baja adopción.
7    Llega DESPUÉS de la request → liga por trace_id, sin span abierto."""
8    langfuse.create_score(
9        name="user-feedback",
10        value=1 if le_sirvio else 0,   # 1 = True, 0 = False
11        trace_id=trace_id,             # liga a la traza de la conversación
12        data_type="BOOLEAN",
13        comment=comentario,            # texto libre del cliente, si lo dejó
14    )
15    langfuse.flush()
16
17# El cliente pulsó pulgar abajo en la respuesta sobre su reembolso:
18registrar_feedback_explicito(
19    trace_id="conv_8f3a",
20    le_sirvio=False,
21    comentario="me dijo que sí pero luego me cobraron igual",
22)

El trace_id="conv_8f3a" entra y se usa: create_score cuelga el score sobre esa traza concreta. El thumbs down queda enganchado a la conversación real del cliente.

Existe una alternativa, span.score_trace(...), pero solo sirve cuando aún estás dentro del span de la traza original —scorea la traza padre del span activo, sin recibir un trace_id—. Eso encaja para scorear sobre la marcha (p.ej. tu propio juez durante la request), no para feedback que llega minutos después. Para el pulgar del usuario, create_score(trace_id=...) es la vía: no necesita un span abierto y liga por id. Esa es la diferencia que decide cuál usar.

Si capturas el feedback desde el frontend en lugar del backend, la doc usa langfuse.score.create({ traceId, name, value, comment }) ligando al traceId del backend. Mismo score, distinto punto de captura.

Señal B — reintento implícito como Numeric score derivado

Nadie pulsó nada. Pero el cliente reformuló la misma pregunta en el turno siguiente. Eso lo detectas tú —comparando turnos consecutivos de la sesión— y lo escribes como score NUMERIC sobre la traza del primer turno:

1from langfuse import get_client
2
3langfuse = get_client()
4
5def registrar_reintento_implicito(trace_id: str, hubo_reintento: bool):
6    """El cliente reformuló la misma pregunta → señal implícita.
7    Más volumen que el pulgar, pero ruidosa: requiere interpretación."""
8    langfuse.create_score(
9        name="implicit-retry",
10        value=1.0 if hubo_reintento else 0.0,   # 1.0 = el cliente reintentó
11        trace_id=trace_id,
12        data_type="NUMERIC",
13        comment="cliente reformuló la misma intención en el turno siguiente",
14    )
15    langfuse.flush()
16
17# El mismo cliente, mismo trace: no pulsó nada, pero reformuló:
18registrar_reintento_implicito(trace_id="conv_8f3a", hubo_reintento=True)

Las dos señales usan langfuse.create_score() con trace_id por la misma razón: ambas llegan después de que la traza se cerró. El pulgar lo emite el cliente; el reintento lo deduces tú al comparar turnos. Ninguna ocurre dentro del span original, así que ninguna puede usar span.score_trace().

Ahora la pregunta de auto-explicación. Antes de leer el análisis, responde: ¿por qué el thumbs down (Señal A) es más fiable pero menos abundante que el reintento (Señal B)?

El thumbs down es más fiable porque el cliente eligió darlo: su intención de calificar negativamente es inequívoca. Es menos abundante porque calificar cuesta un gesto extra que casi nadie hace —baja adopción—. El reintento es más abundante porque ocurre solo, sin pedirlo: el cliente reformula porque quiere su respuesta, no para evaluarte. Y es menos fiable por lo mismo: quizá reformuló porque tú fallaste, o quizá porque su primera pregunta fue ambigua. La Señal A llega etiquetada; la Señal B la etiquetas tú, y ahí entra el ruido.

Un matiz honesto: la Señal B de este ejemplo asume que ya tienes la lógica que decide hubo_reintento —comparar la intención de dos turnos de la misma sesión—. Esa lógica es trabajo aparte (otra llamada al LLM, o una heurística de similitud). El score solo registra su veredicto.

5.6Hazlo tú

Ejercicio 1 — andamiaje parcial

Tienes un lote de señales mezcladas de Aurora de un martes. Clasifícalas: marca cada una como explícita o implícita, y nombra qué sesgo o ruido la afecta. Las dos primeras van resueltas; completa las dos últimas.

Ejercicio 2 — autónomo

Diseña la captura de una señal implícita nueva: "el cliente copió el número de tracking que el agente le dio". Sin mirar la solución, escribe:

1. Qué tipo de score usarías (NUMERIC, BOOLEAN, CATEGORICAL o TEXT) y por qué.
2. Sobre qué entidad lo colgarías (traza, observación o sesión).
3. Qué firma del SDK llamarías y con qué argumentos clave.
4. Qué interpretación —y qué ruido— tiene esa señal. (Pista: copiar el tracking sugiere que la respuesta fue útil… ¿o solo que el cliente quería el número para reclamar en otro sitio?)

Antes de seguir, una pregunta de interrogación elaborativa. Respóndela tú primero: ¿por qué registrar el feedback implícito como score —en vez de solo loggearlo en un archivo aparte— ayuda al flywheel?

Porque un score vive sobre la misma traza que el resto de tus evals. Eso te deja cruzar la señal implícita con la del juez online (L2) en la misma vista: "de las trazas donde el cliente reintentó, ¿cuántas tenían baja groundedness según el juez?". Un log aparte no se cruza con nada. El score, sí —y ese cruce es lo que delata el ruido del implícito y, más adelante, el reward hacking.

5.7Comprueba

Sin pistas. Un equipo de Aurora propone un cambio de prompt. Tras una semana en producción, observa esto:

• Los thumbs up subieron del 71% al 79%.
• La groundedness medida por tu LLM-as-judge bajó de 0,88 a 0,79.
• Los reintentos se mantuvieron planos.

El equipo quiere desplegar el cambio a todo el tráfico porque "a los usuarios les gusta más". Responde:

1. ¿Cómo se llama el fenómeno que probablemente está ocurriendo?
2. ¿Qué hace que la subida de thumbs up sea engañosa aquí?
3. ¿Qué harías para no dejarte engañar antes de decidir?

5.8Conecta

Vuelve a los sesenta y cinco usuarios del martes.

Ya no los tiras a la basura. El que pulsó el pulgar abajo es ahora un score BOOLEAN sobre su traza. El que reformuló es un score NUMERIC derivado. El que abandonó, una señal implícita más que puedes capturar. El 95% del tráfico que el juez no toca ya no es silencio: es señal estructurada que vive junto a tus evals.

Ahora tienes dos fuentes de señal en producción: el juez online de L2 y el feedback del usuario de esta lección. Una la decides tú; la otra te la regalan los usuarios, en volumen.

Pero tener dos señales plantea la pregunta de L4: cuando cambias el prompt de Aurora y los thumbs suben tres puntos, ¿es una mejora real o ruido de muestreo? El reward hacking que viste aquí es la prueba de que "subió la señal" no basta. L4 usa estas señales como métricas de un experimento de verdad —shadow, canary, A/B— y decide con criterio estadístico, no con vibes.

¿Dónde lo aplicarías en tu trabajo? Piensa en cualquier sistema LLM que hayas tocado. ¿Captura algún feedback del usuario? Si solo tiene thumbs, estás escuchando al 2% más ruidoso de tus usuarios. Si no captura nada, ese sistema tiene una mina de señal implícita —reintentos, abandonos— ardiendo sin que nadie la lea.

5.9Reflexiona

Tómate dos minutos. Estas preguntas consolidan más que releer.

• Con tus palabras: ¿qué gana y qué pierde el feedback explícito frente al implícito?
• ¿Por qué una métrica de feedback que sube no prueba que el sistema mejoró? Nombra el fenómeno.
• ¿Qué sigue sin estar claro? Si es "cómo decido si una subida de feedback es real o ruido", es la pregunta correcta —la responde L4—.

Referencia rápida

• Feedback explícito: el usuario lo emite a propósito (thumbs, estrella). Señal clara pero de baja adopción. API: front langfuse.score.create({ traceId, name, value, comment }) / server langfuse.create_score(trace_id=..., ...) (Langfuse docs, jun 2026).
• Feedback implícito: lo deduces de la conducta (reintento, copia, abandono). Más volumen, pero requiere interpretación. Es "informative yet noisy": ayuda en tareas simples, no en complejas (Liu, Zhang & Choi, jun 2025).
• Cuándo create_score vs score_trace: el feedback de usuario llega después de la request (la traza ya se cerró) → langfuse.create_score(trace_id=...), que liga por id sin span abierto. span.score_trace() solo sirve dentro del span activo de la traza original.
• Score por tipo: thumbs → BOOLEAN (0/1); reintento → NUMERIC (0.0/1.0); cuelga del trace_id, observation_id o session_id.
• Reward hacking: optimizar la medida de feedback degrada la calidad real. RLUF: +28% Love Reactions con riesgo explícito de reward hacking (arXiv:2505.14946, may 2025). Regla: nunca una señal en aislamiento; crúzala con el juez.
• Annotation Queues: expertos califican trazas con Score Configs → ground truth fiable (Langfuse docs, jun 2026).
• Evidencia de soporte: Airbnb Agent-in-the-Loop subió retrieval recall@75 +11.7% y helpfulness +8.4%, ciclo de meses a semanas (arXiv:2510.06674).