Talleres del curso
Tres hojas encadenadas que tu equipo va llenando durante la semana. Cada taller produce una pieza del proyecto final: primero delimitas el alcance, luego dibujas la arquitectura con su fallback humano, y por último defines los KPIs y el plan de piloto.
Imprime la hoja del taller que te toca y llénala a mano en equipo, o trabájala en la laptop. Al cierre de cada taller tu equipo presenta el resultado en dos minutos. Guarda todo: cada hoja alimenta la siguiente y la propuesta del proyecto.
Tiempo del taller
Elige la duración de la dinámica e inícialo. No se imprime.
Delimitación de alcance y "buena respuesta"
Qué decide tu equipo en esta hoja
- Qué sabe y qué no sabe el chatbot que van a diseñar.
- Qué cuenta, por adelantado, como una buena respuesta.
- El cimiento del resto de la semana: corpus, arquitectura, evaluación y pitch.
Equipo: Integrantes (código/ID):
Sector elegido: Banca Retail Educación Salud Telecom Otro:
Parte 0 · Idea central (una frase)
Antes de delimitar, escribe en una sola frase el caso de uso que eligieron del cuadrante ganador (alto impacto y alta factibilidad):
"Nuestro chatbot ayudará a respondiendo consultas sobre ."
Recuerda la matriz Impacto × Factibilidad. Impacto: cuánto mejora el servicio o baja el costo (volumen, dolor del cliente, ahorro). Factibilidad: si pueden hacerlo bien y pronto (documentación buena, conocimiento estable, error no catastrófico, RAG puro sin integración compleja). Si tu caso es muy ambicioso pero poco factible esta semana, recórtalo hasta que quepa en el verde: ambición aquí es reducir alcance.
Parte 1 · Ficha del caso de uso
Completen los seis campos. No dejen ninguno vacío.
| Campo | Qué pide | Su respuesta |
|---|---|---|
| Problema | El dolor concreto, con su síntoma medible (no "no tenemos chatbot") | |
| Usuario | Quién hace la pregunta (perfil, contexto, estado de ánimo) | |
| Proceso | En qué punto de la atención actúa el bot (qué reemplaza, qué escala) | |
| Fuentes de conocimiento | Qué documentos concretos y existentes alimentan el bot | |
| Valor esperado | Beneficio para el negocio y para el cliente | |
| Métrica objetivo de QoS | La meta medible, con número (debe incluir groundedness, no solo eficiencia) |
Un caso de uso sin número de groundedness premia a un bot que deflecta inventando. Toda meta de chatbot debe incluir una métrica de calidad de la respuesta, no solo de eficiencia.
Parte 2 · Plantilla A: delimitación de alcance
In-scope es lo que el bot SÍ atiende, y la fuente que respalda cada tema (todo in-scope necesita respaldo documental). Out-of-scope es lo que el bot NO atiende: fuera de alcance no es callar, es reconocer y derivar.
In-scope · el bot SÍ atiende
| # | Tema que SÍ atiende | Fuente que lo respalda (documento del corpus) |
|---|---|---|
| 1 | ||
| 2 | ||
| 3 | ||
| 4 |
Out-of-scope · el bot NO atiende
Marca la razón: (N) no está en el corpus · (S) sensible o de alto riesgo · (T) transaccional o dato vivo (necesita API, no documentos).
| # | Tema que NO atiende | Razón (N / S / T) | ¿Qué hace el bot en su lugar? |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 | |||
| 4 |
Regla de escalación
Completa la frase. Pista: ¿cuál es la pregunta que MÁS daño haría (legal, de dinero o de salud) si el bot la contesta solo?
"Cuando el cliente pregunte , el bot debe (derivar a un humano / decir 'no tengo esa información' / pedir un dato y pasar a un agente)."
Métrica objetivo de QoS (con número)
| Eficiencia (ej. deflexión, FRT) | Calidad (groundedness) |
|---|---|
Parte 3 · Plantilla B: rúbrica de "buena respuesta"
Estas son las cinco propiedades de una buena respuesta. Para cada respuesta del bot se marca 0 / 1 / 2 en cada una. Reutilizarás esta rúbrica para evaluar contra el gold set.
| Propiedad | Criterio (qué cuenta como cumplido) | 0 / 1 / 2 |
|---|---|---|
| 1. Correcta | El contenido coincide con la fuente; sin datos inventados ni erróneos. | |
| 2. Fundamentada / citada (groundedness) | Se apoya en una fuente del corpus e indica cuál (documento, artículo o sección). | |
| 3. Completa | Responde toda la pregunta: condiciones, excepciones y siguiente paso si aplica. | |
| 4. Tono adecuado | Registro, cortesía y claridad apropiados al usuario y al sector. | |
| 5. Escalación correcta | Si era out-of-scope, sensible o sin fundamento, derivó o admitió el límite. Si no aplicaba, no escaló de más. |
Una respuesta es "buena" solo si TOTAL ≥ ______ Y la propiedad 2 (groundedness) ≠ 0. Sin fundamento no hay buena respuesta, aunque el resto sume: una respuesta elocuente pero inventada reprueba automáticamente.
Parte 4 · Un ejemplo calificado por tu equipo
Redacta una pregunta típica que recibiría tu bot y la respuesta ideal; luego califícala con tu propia rúbrica de la Parte 3.
| Campo | Contenido |
|---|---|
| Pregunta típica | |
| Respuesta ideal del bot | |
| Calificación | Correcta __ · Fundamentada __ · Completa __ · Tono __ · Escalación __ → TOTAL: __ /10 ¿Es "buena"? Sí / No |
Ficha del caso (Parte 1) con los seis campos llenos; Plantilla A con al menos 4 in-scope con fuente y 4 out-of-scope con razón, más la regla de escalación redactada; y Plantilla B con su umbral de "buena" y el ejemplo calificado de la Parte 4.
Arquitectura conceptual del chatbot y fallback humano
Qué construye tu equipo en esta hoja
- El plano de negocio del chatbot: de dónde sale lo que dice y cómo lo recupera.
- Cómo redacta la respuesta y la cita de su fuente.
- Lo más importante de hoy: qué pasa cuando el bot no debe o no puede contestar (el fallback humano).
No se escribe código: son cajas y flechas que tu equipo puede dibujar en una pizarra y defender ante un comité directivo. Trabaja sobre el mismo caso de sector que vienes llevando desde el Taller 1.
Equipo: Sector:
Parte 0 · La notación (cajas y flechas)
Usa siempre estos símbolos. Cuantos menos, mejor.
+--------------+ Caja de proceso: algo que el sistema HACE (recuperar, generar, validar). +--------------+ #==============# Almacen / fuente: algo que GUARDA informacion (corpus, indice, logs). #==============# <> Decision <> Rombo: una bifurcacion con condicion (similitud alta? tema sensible?). --------> Flecha: flujo normal de la conversacion. - - - - > Flecha punteada: camino de EXCEPCION (escalacion, "no se", error). (H) Humano Actor humano (agente, supervisor).
Tres reglas que tu diagrama debe respetar
- Toda flecha que sale de un rombo va etiquetada con su condición ("sí / no", "similitud baja", "tema = devolución de dinero").
- Todo diagrama de servicio tiene al menos un camino punteado que termina en (H). Un diagrama sin salida humana está incompleto.
- La caja de Generación nunca apunta directo al cliente: pasa siempre por un guardrail de salida.
Parte 1 · Lienzo de arquitectura
Llena cada caja con texto y, si trabajas en papel, dibuja las flechas, incluidos los dos caminos de excepción: "no sé" por baja similitud y "escalar" por decisión.
#==========================================================================#
| LIENZO DE ARQUITECTURA DEL CHATBOT Equipo: ________ Sector: ________ |
#==========================================================================#
1) FUENTES / CORPUS 2) INDEXACION (base de conocimiento)
De donde sale el saber? Como se organiza para buscar?
+----------------------+ +----------------------+
| | --> | |
+----------------------+ +----------------------+
^ Quien actualiza y cuando? ________________________________
3) GUARDRAIL ENTRADA 4) RECUPERACION
Que filtras al entrar? Que fragmentos traes?
+----------------------+ +----------------------+
| | --> | |
+----------------------+ +----------------------+
5) <> HAY MATCH RELEVANTE? <> Umbral de similitud: ______
| SI --> (ir a 6) NO - - -> CAMINO "NO SE" (ir a 9)
6) GENERACION 7) <> ESCALAR? <> Cual de los 5 gatillos?
Como redacta, apoyada en que? +----------------------+
+----------------------+ | [ ] baja confianza |
| | --> | [ ] fuera de alcance |
+----------------------+ | [ ] sensible/riesgo |
| [ ] sentimiento neg. |
| [ ] peticion explicita|
+----------------------+
| NO escala --> (ir a 8) SI escala - - -> (ir a 10)
8) GUARDRAIL SALIDA --> SALIDA AL CLIENTE
+----------------------+ +----------------------------------+
| cita? no-promesas? | | Respuesta + CITA de la fuente: |
| no-fuga de datos? | | ______________________________ |
+----------------------+ +----------------------------------+
9) RESPUESTA "NO SE" 10) FALLBACK HUMANO
Texto honesto + salida: El handoff transfiere:
+----------------------+ +----------------------+
| |->(H) | [ ] transcripcion | --> (H) Agente
+----------------------+ | [ ] motivo escalacion |
SLA del fallback: ________ | [ ] contexto (pedido) |
+----------------------+
11) #====================================================#
| LOGGING / AUDITORIA que eventos registras? |
| ___________________________________________________|
#====================================================#
#==========================================================================#
Tu diagrama debe contener todas estas cajas y los dos caminos punteados (el "no sé" por baja similitud y el "escalar" por decisión). Esos dos caminos son el corazón del taller.
Parte 2 · Checklist de disparadores de escalación
Estos son los cinco disparadores: las cinco campanas que, si suenan, llaman a un humano. Para cada uno, escribe una pregunta real de tu sector que lo activaría.
| # | Disparador | Qué lo activa | Ejemplo de tu sector |
|---|---|---|---|
| 1 | Baja confianza / similitud | El mejor fragmento recuperado no supera el umbral | |
| 2 | Tema fuera de alcance | La pregunta no mapea a ningún tema del corpus | |
| 3 | Solicitud sensible / de riesgo | Operación financiera, legal, médica o irreversible | |
| 4 | Sentimiento negativo | Enojo, frustración, amenaza, lenguaje de reclamo | |
| 5 | Petición explícita | El cliente pide hablar con una persona |
El handoff (cómo escalar bien). Marca lo que tu bot transferirá al agente para que no empiece de cero: Transcripción completa Motivo de la escalación (cuál disparador) Contexto estructurado (n.º de pedido, intención) Lo que el bot ya intentó (qué citó, qué no encontró).
Cuando la recuperación no trae nada relevante, el bot debe ser honesto: reconocer sin tecnicismos, no inventar y ofrecer una salida. " ¿Le conecto con un agente?"
SLA del fallback (un compromiso medible). Escribe al menos uno:
Ejemplos: "Toda escalación urgente llega a un agente en menos de 2 min"; "El 100% de las solicitudes financieras se derivan, el bot no resuelve ninguna solo".
Parte 3 · Hoja de revisión por pares
Intercambia tu lienzo con el equipo de al lado. No rediseñen el diagrama ajeno: interróguenlo con esta hoja y anoten hallazgos. Cada hallazgo se redacta como pregunta o riesgo concreto, no como "está mal" (por ejemplo: "¿qué pasa si el cliente pide un humano en el paso 6? No veo la flecha"). Encuentren al menos un hallazgo por dimensión. Puntúen 0 a 2 (0 = ausente, 1 = presente pero débil, 2 = claro y bien diseñado).
| Dimensión | Qué se verifica | 0 / 1 / 2 |
|---|---|---|
| A. ¿De dónde sale el conocimiento? | Fuentes nombradas concretamente (no "internet"); hay flecha y responsable de actualización; no confunde documentos (RAG) con transacciones (API). | |
| B. ¿Qué pasa si no encuentra? | Existe el camino de excepción por baja similitud (punteado); el "no sé" es honesto y no inventa; ofrece una salida. | |
| C. ¿Cuándo interviene un humano? | Al menos un camino termina en (H); disparadores identificados; el handoff transfiere contexto; hay un SLA de fallback. | |
| D. ¿Cita fuentes y es auditable? | La salida incluye cita de la fuente; la generación pasa por un guardrail de salida; existe logging/auditoría. |
Hallazgo obligatorio por dimensión, una pregunta abierta al equipo revisado, y un elogio más una mejora prioritaria. Puntaje total: ____ / 26.
Las cuatro dimensiones son las mismas cuatro preguntas que hará un comité directivo: de dónde sale, qué pasa si no sabe, cuándo entra un humano y si cita. Si tu diagrama las contesta, tu proyecto se defiende solo.
Lienzo de arquitectura con todas las cajas llenas y los dos caminos de excepción; checklist de disparadores con un ejemplo por gatillo, el handoff marcado, la respuesta "no sé" redactada y al menos un SLA de fallback; y la hoja de revisión por pares del lienzo que les tocó revisar, con un hallazgo por dimensión.
Tablero de KPIs y plan de piloto
Qué construye tu equipo en esta hoja
- El tablero con el que medirías tu chatbot.
- El plan de piloto con el que lo probarías en el mundo real sin arriesgar a la organización.
- La idea-fuerza: un buen tablero responde a la vez "¿el modelo recupera y responde bien?" y "¿mejora el servicio y baja el costo?".
Equipo: Sector: Proceso que se evalúa:
Parte 1 · Ficha de KPIs
Un tablero útil mezcla cuatro capas, y cada una responde una pregunta:
¿Es eficiente?
Contención/deflexión, escalación, FCR, FRT, AHT.
¿Gustó?
CSAT, CES, NPS.
¿Tiene razón?
Groundedness, recall, precision@k, tasa de "no sé" apropiada.
¿Conviene?
Costo por contacto, ahorro por deflexión, ROI.
Define al menos un KPI por capa. Cada KPI necesita definición cerrada, meta/SLA, fuente, frecuencia y dueño.
| Capa | KPI elegido | Definición operacional (qué cuenta, qué ventana) | Meta / SLA | Fuente | Frecuencia | Dueño |
|---|---|---|---|---|---|---|
| Operativo | ||||||
| Experiencia | ||||||
| Modelo / RAG | ||||||
| Negocio / costo |
¿Qué dos KPIs van emparejados para evitar un incentivo perverso (que nadie suba la contención "atrapando" clientes)? ↔ Pista: contención ↔ CSAT/CES, o deflexión ↔ groundedness.
Regla del tablero: si un número no va a cambiar ninguna decisión, no va en el tablero, va en un anexo. Y cada capa tiene su propio reloj: lo operativo casi en vivo, el modelo por release, el negocio mensual, el NPS trimestral.
Parte 2 · Plan de piloto
Un tablero mide; un piloto decide. Antes de soltar el chatbot a toda la base de clientes, se prueba en pequeño, con red de seguridad, y se decide con datos si avanza (go) o se detiene (no-go).
| Elemento | Su decisión | Justificación breve |
|---|---|---|
| 1. Alcance acotado (tema / canal / horario) | ||
| 2. Selección de usuarios (inclusión / exclusión) | ||
| 3. Duración | ||
| 4. Diseño de comparación (shadow / A-B / pre-post) | ||
| 5. Evidencias que se recolectan | ||
| 6. Criterios GO (umbrales con SLA) | ||
| 7. Criterios NO-GO bloqueantes |
Ayuda para el punto 4 · ¿qué diseño de comparación?
| Diseño | ¿El cliente ve el bot? | Mide modelo | Mide experiencia | Riesgo | Cuándo usarlo |
|---|---|---|---|---|---|
| Shadow mode (modo sombra) | No | Sí | No | Mínimo | Primer filtro de calidad, sin exponer a nadie |
| A/B test | La mitad (aleatorio) | Sí | Sí (causal) | Medio | Medir mejora real con volumen suficiente |
| Pre / post | Sí (todos, después) | Sí | Sí (no causal) | Medio-alto | Cuando no se puede aleatorizar |
Orden recomendado: primero shadow ("¿el bot tendría razón?" sin tocar al cliente), luego A/B ("¿mejora el servicio?" tocando a la mitad).
Ayuda para los puntos 6 y 7 · criterios go/no-go
Distingue bloqueantes (un solo fallo grave = no-go) de graduales (por debajo del umbral se itera, no se cancela).
| Condición | Umbral (SLA) | Tipo |
|---|---|---|
| Groundedness | ≥ 95% | Bloqueante |
| Respuestas peligrosas / mal escaladas | 0 incidentes graves | Bloqueante |
| CSAT del bot ≥ humano | CSAT_B ≥ CSAT_A − 3 pts | Gradual (iterar) |
| Contención genuina | ≥ 50% | Gradual (iterar) |
| Ahorro neto proyectado | > 0 a 12 meses | Gradual (revisar caso) |
Escribe tu go/no-go antes de empezar. Un piloto sin criterios de éxito definidos de antemano no es un experimento: es solo un acto de fe.
Parte 3 · Esquema de evaluación (media página)
En prosa, conecta en un solo párrafo: qué KPIs miras, con qué piloto los obtienes, y qué decisión tomas según el resultado. Debe poder leerse como algo que un gerente entendería.
La contención alta no es lo mismo que ahorro. Solo cuentan las deflexiones genuinas (clientes bien resueltos), no las "falsas resoluciones" donde el cliente se rindió. Por eso el ahorro se cruza siempre con CSAT/CES y groundedness.
Ficha de KPIs con al menos un KPI por cada una de las cuatro capas y el par de incentivos identificado; plan de piloto con los siete elementos decididos y el go/no-go atado a un SLA numérico; y el esquema de evaluación de media página.
El Taller 1 fija el alcance y la "buena respuesta"; el Taller 2 lo convierte en arquitectura con fallback; el Taller 3 le pone tablero y piloto. Los tres alimentan directamente la propuesta y el pitch del proyecto. Consulta cómo se evalúa cada pieza →