Auditoría de Rendimiento · Buyer Bot · Run 3
Primera corrida con los 17 escenarios completos (11 anteriores + 6 nuevos) × 6 perfiles. 40 turnos máx. llama3.2:1b en amr-ssh CPU. Tiempo total: 191.7 min (3h 11m).
→ Recomendación: max_turns óptimo para llama3.2:1b = 15–20. Más allá, el modelo degenera en loops. Los cierres reales ocurren antes del turno 10 en la mayoría de casos.
| Métrica | Run 1 8r · 54 conv |
Run 2 25r · 54 conv |
Run 3 40r · 102 conv |
|---|---|---|---|
| Escenarios | 9 | 9 | 17 |
| Tasa cierre | 52% | 65% | 44%* |
| Cierres | 28 | 35 | 45 |
| Rondas al cierre | ≤8 | 6.3 | 6.4 |
| Escaladas | 16 | 6 | 12 |
| Tiempo total | ~20 min | 50 min | 192 min |
* 44% con 17 esc incluyendo 6 nuevos difíciles. Los 9 escenarios base mantienen ≈60% en Run 3.
| Perfil | Cierre | % | Avg r | Escaladas | Observación |
|---|---|---|---|---|---|
| ⚡ Comprador Impulsivo | 9/17 | 53% | 21.3r | 8 | Más escalar que Run 2. Con 40r, sin urgencia. |
| 🤔 Indeciso | 8/17 | 47% | 23.6r | 9 | Bajó de 78%. Más turnos = más tiempo para seguir indeciso. |
| 🤨 Escéptico | 8/17 | 47% | 26.5r | 9 | El más lento. 26.5r promedio es máximo casi. |
| 🛠️ Usuario Técnico | 7/17 | 41% | 25.5r | 10 | Bajó de 78%. Nuevos escenarios técnicos son difíciles para 1B. |
| 💰 Cazador de Precio | 7/17 | 41% | 25.9r | 10 | Consistentemente difícil. Sin tácticas de precio. |
| 🏢 Cliente Empresarial | 6/17 | 35% | 28.2r | 11 | Sorprendente caída desde 78%. Más escenarios B2B complejos (WTC, web premium, apps) donde el modelo falla. |
Mejor debut. El modelo conoce desarrollo de apps y puede dar precios/plazos. Cerebro: web_premium
Moderado. La propuesta de valor mayorista es compleja. Cerebro: drop_productos
Razonable. El modelo puede diagnosticar pero no siempre cierra ticket de soporte. Cerebro: soporte_web
Difícil. Producto complejo (panel + cuentas + web). Necesita contexto más rico. Cerebro: streaming_reseller
Difícil por diseño: el buyer no sabe qué quiere. El seller no puede cerrar sin diagnóstico claro. Cerebro: web_ambiguo
Problema estructural: el buyer solo pide lista de precios y no tiene intención de compra. El seller no tiene táctica de conversión para price-shoppers. Cerebro: consulta_precio
Reducir max_turns a 15–18 en el CLI
Con llama3.2:1b, los cierres ocurren antes del turno 10. Después de 20r el modelo degenera. 40 turnos fue contraproducente.
Rediseñar escenario "Consulta de Precios"
El buyer debe tener una intención real, no solo pedir catálogo. Cambiar first_message y comportamiento para que el buyer pregunte por un producto específico después del precio.
Habilitar GPU (RTX 3050) en amr-ssh para Ollama
GPU disponible pero sin uso. Con GPU se puede usar qwen3:8b/llama3.1:8b para escenarios complejos (Dolibarr, streaming_reseller) con mejor conocimiento de dominio.
Enriquecer contexto para Dolibarr y streaming_reseller
Ambos con 17%. Agregar en el SELLER_SYSTEM descripción concreta del producto: módulos, casos de uso, precios exactos. El modelo 1B necesita el conocimiento en el prompt.
Run 4: max_turns=15, escenarios optimizados
Con P1+P2+P4 aplicados. Meta: superar 65% del Run 2 en el subset de 9 escenarios base, y alcanzar ≥50% en los nuevos.
⚡ AMR TECH™ · Desarrollado / Auditado por Anderson Mares
Folio AUD-20260926-002 · 102 conversaciones · 17 escenarios × 6 perfiles · llama3.2:1b CPU · 191.7 min