Enfrentamos a los 6 mejores LLMs a un backend de leads de verdad. Los resultados no son los que esperas
Mismo encargo, sandbox idéntico, tests ocultos y trampas de spam: seis de los mejores LLMs construyen un backend de leads de verdad. Quién no te llena la bandeja de basura lo decide el dato, no el marketing.
En este artículo
Cinco comerciales, cientos de leads diarios, duplicados por todas partes y spam que se cuela hasta en la sopa. El encargo era claro: construye una API que lo aguante todo. Seis modelos entraron al ring. Uno salió con la corona, pero no fue el que más rápido respondió.
El problema que duele de verdad
Un equipo de ventas pequeño, cinco personas, recibe leads desde varios formularios simultáneos. El caos es el de siempre: el mismo cliente envía el formulario tres veces porque no le llegó la confirmación, bots rellenan campos con basura, y los comerciales pierden tiempo separando oro de escoria antes de poder llamar a nadie.
La solución técnica no es glamurosa, pero es crítica: una API interna que registre leads sin duplicados, filtre la basura automáticamente, priorice los contactos calientes y sea idempotente (que si el mismo lead llega dos veces, no lo guarde dos veces). Barata de operar, rápida de respuesta y que no se vuelva loca bajo carga concurrente.
Ese fue el encargo. Sin ambigüedad, sin margen para la interpretación creativa.
Las reglas del combate
Seis modelos. Mismo enunciado, palabra por palabra. Mismo contenedor Docker, sin acceso a internet durante las pruebas, sin librerías externas no declaradas en el encargo. Nadie tuvo ventaja de contexto, nadie vio lo que hizo el de al lado.
Los competidores:
- GPT-5.5
- Claude Opus 4-8
- Kimi K2.7-Code
- MiniMax M3
- Gemini 3.1 Pro Preview
- DeepSeek V4 Pro
Cada uno generó su implementación. Después se ejecutaron dos tandas de pruebas idénticas sobre cada solución: baterías de tests de aceptación automatizados más evaluación de un panel de jueces humanos para los criterios cualitativos (arquitectura, documentación, calidad del código).
Cómo medimos esto
Las métricas son deterministas donde se puede ser determinista, y subjetivas donde no queda otra, pero con el panel de jueces para que no sea solo la opinión de uno.
- Limpieza (detección de spam): de 130 leads basura inyectados, ¿cuántos cazó cada modelo? Número exacto, sin interpretación.
- Latencia p95: el percentil 95 de tiempo de respuesta bajo carga. Objetivo marcado en el encargo: menos de 300 ms.
- Cobertura: de 390 leads buenos inyectados, ¿cuántos conservó sin tirarlos a la basura por error?
- Estabilidad: ¿el rendimiento fue consistente entre la tanda 1 y la tanda 2, o el modelo se comportó diferente sin razón aparente?
- Tests de aceptación: batería de 5 tests por tanda que validan los requisitos del contrato (idempotencia, filtro por source, concurrencia, etc.).
¿Quieres verificar los números tú mismo? Descarga los artefactos del experimento: código de cada modelo, transcripts y scores completos.
Métrica por métrica: quién ganó y por qué
Limpieza de spam: el que más basura cazó
Ganador: GPT-5.5 con 123/130 (94,6 %)
GPT-5.5 cazó 123 de los 130 leads basura. Solo se le colaron 7. El siguiente mejor, Gemini, se quedó en 110/130. Claude llegó a 114 pero dejó pasar 16. MiniMax fue el peor con diferencia: 92/130, casi 4 de cada 10 spams pasaron sin que nadie los parara.
La diferencia está en la heurística. GPT-5.5 implementó un sistema de señales acumulativas: si un lead activa suficientes indicadores de spam (email desechable, teléfono con formato inválido, nombre con caracteres sospechosos, etc.), cae. Sin contemplaciones.
| Modelo | Spam cazado | Ratio |
|---|---|---|
| GPT-5.5 | 123/130 | 94,6 % |
| Claude Opus 4-8 | 114/130 | 87,7 % |
| Gemini 3.1 Pro | 110/130 | 84,6 % |
| Kimi K2.7-Code | 105/130 | 80,8 % |
| MiniMax M3 | 92/130 | 70,8 % |
| DeepSeek V4 Pro | 84/130 | 64,6 % |
Latencia p95: quién responde antes de que el comercial se aburra
Ganador: Claude Opus 4-8 con 53 ms p95
El objetivo era menos de 300 ms. Claude llegó a 53 ms. GPT-5.5 se fue a 1.016 ms, más de tres veces por encima del límite, . Kimi, que apostó por Go esperando velocidad, también se disparó a 1.006 ms. El resto sí cumplió el objetivo: Gemini en 96 ms, DeepSeek en 109 ms, MiniMax en algún punto razonable.
La razón de Claude: prescindió de frameworks. Usó Python stdlib puro, sin FastAPI, sin ninguna capa de abstracción que añada overhead. Una apuesta minimalista que le dio la latencia más baja del experimento.
GPT-5.5 y Kimi tienen un problema real aquí: en producción, con un equipo de ventas que espera respuesta mientras está al teléfono con un cliente, 1.016 ms no es un número, es una queja de usuario.
Cobertura: los leads buenos que no se pueden perder
Ganador compartido: Claude Opus 4-8, Kimi K2.7-Code, MiniMax M3 y DeepSeek V4 Pro con 390/390 (100 %)
Cuatro modelos conservaron todos los leads válidos. Claude entre ellos. GPT-5.5, el mejor cazador de spam, pagó el precio de su agresividad: tiró 28 leads buenos a la basura. Gemini perdió 35.
El dilema es clásico en cualquier sistema de filtrado: cuanto más agresivo eres con el spam, más riesgo de tirar algo bueno. Claude lo resolvió con una regla de doble señal: para marcar un lead como spam necesita activar al menos dos indicadores independientes, no uno solo.
GPT-5.5 no tuvo esa cautela. Resultado: 28 leads válidos perdidos. En ventas, eso son 28 oportunidades de negocio que nadie va a llamar.
Estabilidad: ¿el modelo se comporta igual mañana que hoy?
Ganador: Claude Opus 4-8 con 8,8/10 en ambas tandas exactamente
Claude sacó 8,8 en la tanda 1 y 8,8 en la tanda 2. Mismo número, sin variación. GPT-5.5 varió entre 8,6 y 9,1, su media también da 8,8, pero el comportamiento fue inconsistente, . Kimi bajó a 8,3 de media. MiniMax y DeepSeek en 7,9.
Lo preocupante: Gemini y DeepSeek fallaron tests de aceptación en una o ambas tandas. No es variación de décimas: es que el sistema directamente no cumplió un requisito del contrato en algún momento de la prueba.
El retrato de cada modelo
GPT-5.5: el obsesivo de la limpieza que no mira el reloj
GPT-5.5 entró al experimento como favorito y ganó. Pero la forma en que ganó dice mucho de sus limitaciones.
Su heurística de spam es la más sofisticada del grupo: acumula señales, pondera, decide. 94,6 % de acierto es un número difícil de discutir. Su coste de tokens también fue bajo, lo que en producción importa cuando procesas cientos de leads al día.
La sorpresa fue su latencia. 1.016 ms p95 en un sistema que debía responder en menos de 300 ms no es un fallo menor: es un requisito del contrato que no cumplió. Y los 28 leads válidos que tiró a la basura por ir demasiado agresivo son el precio de su obsesión con la limpieza.
En producción real: funciona si puedes asumir la latencia y tienes margen para perder algún lead bueno. Para un equipo de ventas pequeño donde cada lead cuenta, ese 7,2 % de falsos positivos duele.
Claude Opus 4-8: el ingeniero que resolvió el problema sin complicarse
Claude es el modelo que más sorprendió del experimento. No por sus números de spam, se quedó en 87,7 %, claramente por debajo de GPT, sino por cómo resolvió el resto del problema.
53 ms de latencia p95 con Python stdlib puro. Sin FastAPI, sin nada. Mientras otros traían frameworks enteros para construir una API interna, Claude fue al mínimo necesario y ganó en lo que más importa en tiempo real.
Cobertura perfecta: 390/390 leads buenos conservados. La única del experimento. Su regla de doble señal para marcar spam es más conservadora, lo que le cuesta en detección pero le salva en falsos positivos.
Su cagada: 16 spams que pasaron sin que nadie los pillara. En un equipo de ventas, eso es ruido que alguien tiene que limpiar a mano.
La consistencia de 8,8/10 en ambas tandas es el dato que más habla de su arquitectura: no hay magia, no hay variabilidad, el sistema se comporta igual siempre.
Kimi K2.7-Code: la apuesta diferente que no salió
Kimi fue el único que eligió Go. La lógica era correcta: Go tiene menos overhead que Python para APIs de alto rendimiento. El resultado fue el opuesto de lo esperado: 1.006 ms p95, prácticamente igual que GPT-5.5.
También fue el único que usó almacenamiento en archivo JSON en lugar de base de datos. Una decisión que le costó en concurrencia: solo pasó 188 de 200 requests simultáneas correctamente.
Kimi tuvo buena cobertura (390/390 leads buenos) y una detección de spam decente (105/130), pero la combinación de latencia inaceptable y fallos de concurrencia lo alejan de cualquier uso en producción real.
MiniMax M3: la mejor documentación, el peor filtro
MiniMax escribió la documentación más valorada por el panel de jueces: 9,0/10. La arquitectura también estaba bien planteada. El problema es que la API que documentó tan bien dejaba pasar 38 spams de cada 130.
70,8 % de detección de spam es el segundo peor ratio del experimento, solo por delante de DeepSeek. En un sistema cuyo objetivo principal es filtrar basura, ese número es difícil de justificar con buena documentación.
Su cobertura fue perfecta (390/390), lo que indica que el problema no era agresividad excesiva sino lo contrario: un filtro demasiado permisivo que prefería no arriesgarse a tirar nada.
Gemini 3.1 Pro Preview: bueno en una tanda, roto en la otra
Gemini tuvo el peor tipo de problema: inestabilidad funcional. Pasó de 5/5 tests de aceptación en la primera tanda a 4/5 en la segunda. El test que falló en la segunda tanda fue el de filtrado por source, uno de los requisitos explícitos del contrato, .
Su latencia fue excelente: 96 ms con FastAPI, lo que demuestra que el framework no es el culpable de los problemas de GPT-5.5 o Kimi. Y su detección de spam fue razonable (110/130, 84,6 %).
Pero un sistema que cumple el contrato en una tanda y no en la siguiente no es un sistema en el que puedas confiar. En producción, ese tipo de inconsistencia es peor que una limitación conocida.
DeepSeek V4 Pro: el que no implementó lo que le pedían
DeepSeek tiene el problema más grave del grupo: falló el test de filtrado por source en las dos tandas. No en una. En las dos.
Eso significa que nunca entregó la funcionalidad completa. El filtro por source era un requisito explícito del encargo, no un bonus opcional. Su código estaba bien estructurado, su latencia fue decente (109 ms), pero si no cumples el contrato, el resto da igual.
64,6 % de detección de spam y un requisito fundamental sin implementar correctamente lo sitúan al final de la tabla, independientemente de lo ordenado que esté el código.
El veredicto
GPT-5.5 gana con 9,03/10. Su detección de spam (9,5 en esa métrica) y su bajo coste de tokens le dan la corona. Es el modelo que mejor resolvió el problema central del encargo: sacar la basura.
Claude Opus 4-8 queda segundo con 8,85/10. Si la latencia hubiera pesado más en la puntuación final, o si el equipo de ventas necesitara respuesta en tiempo real, el resultado podría haber sido otro. 53 ms frente a 1.016 ms es una diferencia que en producción se nota.
El resto:
- Kimi K2.7-Code: 8,33, buena cobertura, latencia inaceptable, fallos de concurrencia.
- MiniMax M3: 8,01, documentación excelente, filtro de spam insuficiente.
- Gemini 3.1 Pro Preview: 7,91, inestabilidad funcional entre tandas.
- DeepSeek V4 Pro: 7,87, no implementó un requisito del contrato en ninguna tanda.
La diferencia entre primero y segundo es de 0,18 puntos. Entre segundo y tercero, 0,52. El pelotón de cola está agrupado en menos de medio punto, pero por razones distintas: unos por inestabilidad, otros por no cumplir el contrato.
Resumen por modelo
GPT-5.5 fue el mejor en lo que más importaba: limpieza. 9,5 en detección de spam, 94,6 % de acierto, coste de tokens bajo. Su variación entre tandas (8,6 → 9,1) no es dramática, pero existe. El lastre real es la latencia: 1.016 ms p95 triplica el objetivo del encargo y, en un uso con usuarios esperando respuesta, es un problema de producción, no una anécdota. También perdió 28 leads válidos por agresividad excesiva. Ganó el experimento, pero con condiciones.
Claude Opus 4-8 fue el más estable del grupo: 8,8/10 exacto en ambas tandas, sin variación. 53 ms de latencia p95 es el mejor número del experimento y viene de una decisión de arquitectura deliberada (stdlib puro, sin frameworks). Cobertura perfecta: 390/390. Su punto débil es claro: 114/130 en spam, dejando pasar 16. Su filtro conservador es una elección de diseño, no un error, pero tiene un coste real en limpieza.
Kimi K2.7-Code apostó por Go buscando rendimiento y acabó con 1.006 ms de latencia, peor que la mayoría de las soluciones en Python. El almacenamiento en JSON le costó en concurrencia (188/200 OK). Buena cobertura (390/390) y detección de spam decente (105/130), pero los problemas de latencia y concurrencia lo hacen inviable para el caso de uso real. Inestable: 8,3 de media con variación entre tandas.
MiniMax M3 escribió la documentación más valorada del experimento (9,0/10 del panel) y su arquitectura fue bien recibida. Pero dejó pasar 38 spams de 130, 70,8 % de detección, el segundo peor ratio, . Cobertura perfecta (390/390), lo que confirma que el problema no era agresividad sino permisividad excesiva. Inestable en calidad general: 7,9 de media con caída en la segunda tanda.
Gemini 3.1 Pro Preview tuvo el problema más difícil de aceptar: falló el test de filtrado por source en la segunda tanda, un requisito explícito del contrato. Su latencia fue buena (96 ms con FastAPI) y su detección de spam razonable (110/130, 84,6 %), pero la inconsistencia funcional entre tandas (5/5 tests → 4/5 tests) es una señal de alarma para cualquier despliegue en producción. No puedes confiar en un sistema que cumple el contrato un día y no al siguiente.
DeepSeek V4 Pro falló el test de filtrado por source en las dos tandas. No en una: en las dos. Eso es un requisito del contrato sin implementar, punto. Su latencia fue decente (109 ms) y el código estaba bien estructurado, pero la detección de spam fue la peor del grupo (84/130, 64,6 %) y la funcionalidad incompleta lo sitúa al final independientemente de cualquier otra métrica. Estabilidad de 7,9, pero estable en no cumplir el encargo.
Para llevarse a casa
El experimento deja dos ideas concretas.
La primera: limpiar bien y responder rápido son objetivos que tiran en direcciones opuestas. GPT-5.5 optimizó para limpieza y pagó en latencia. Claude optimizó para velocidad y cobertura, y pagó en detección de spam. No hay un modelo que domine todo a la vez. Elegir cuál te duele menos depende del caso de uso, no del benchmark.
La segunda: cumplir el contrato es el mínimo, no el mérito. Dos modelos del grupo no implementaron correctamente un requisito explícito del encargo. Documentación bonita, código limpio, latencia decente: todo eso da igual si el sistema no hace lo que le pediste. En producción real, eso no es una décima menos en el ranking; es un bug en producción.
