PayPal: de 43% a 95% de acierto sin cambiar el LLM

PayPal pasó de 43% a 95% de acierto sin cambiar el modelo

El asistente interno de data science de PayPal respondía correctamente el 43% de las preguntas de negocio que le llegaban. Hoy acierta el 95%, y el modelo de lenguaje (LLM) que hay debajo es exactamente el mismo. Lo que cambió fue otra cosa: la compañía construyó una capa de conocimiento con definiciones, patrones de consulta y procedimientos analíticos propios, y la mantuvo separada del modelo que la usa.

Para un founder que está peleando con un asistente que «a veces funciona», la lección no es técnica sino estratégica: el cuello de botella de la IA empresarial ya no está en el modelo, está en el contexto que le entregas.

Ren Zhang, VP y head global de producto de IA de PayPal, contó el caso en una sesión de la AI Impact Series de VentureBeat. Su diagnóstico de partida: el asistente ya tenía acceso a datos limpios y verificados, pero eso no lo hacía capaz de responder preguntas de negocio.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Por qué los datos correctos no bastan para responder bien?

El ejemplo que dio Zhang es el mejor resumen del problema. Si preguntas por «cuentas nuevas», un agente puede recuperar los registros correctos y aun así aplicar una definición equivocada de «nueva». Qué cuenta como nueva depende de reglas de negocio que hay que entregar explícitamente; no se infieren de la disponibilidad del dato.

La solución de PayPal fue una capa de conocimiento con varios componentes:

Golden query: una consulta que especifica cómo recuperar los datos para un propósito concreto.
Playbook analítico: cómo investigar una pregunta, qué segmentos, productos o comportamientos revisar (por ejemplo, fallos de login y uso de passkeys).
Procedimientos ordenados: cuando el equipo descubrió que un asistente interno de RRHH fallaba, el problema no era el acceso a la información sino el formato. Las instrucciones estaban troceadas en fragmentos separados; las reescribieron conservando los pasos en orden.

«Creemos que nuestra propiedad intelectual está realmente en construir esa capa de conocimiento», dijo Zhang.

¿Conviene hacer fine-tuning o construir contexto?

PayPal también probó el camino opuesto con su agente de comercio orientado al cliente: evaluó cuatro o cinco modelos. Los más grandes daban buena capacidad pero arrancaban con unos 15 segundos de latencia. Al pasar a un modelo de 8.000 millones de parámetros la latencia mejoró mucho y la precisión cayó; un ajuste fino especializado en comercio la recuperó en parte, pero no lo suficiente.

La decisión posterior fue reducir el peso del fine-tuning extensivo. La razón es de economía operativa: cada nueva versión de modelo obliga a repetir el proceso, y el proceso exige expertise especializado. «¿Cuántos modelos han salido últimamente? Uno es mejor que el otro. Si lo entrenas con demasiada frecuencia, es demasiado costoso», dijo Zhang.

Por eso diseñó el asistente interno como agnóstico al modelo: «Si el modelo mejora, lo enchufo y listo. No debería cambiar mi conocimiento».

El sector está convergiendo en esa idea. Gartner, en su Market Overview de plataformas de contexto para IA de agosto de 2026 —citado en el lanzamiento del Context Engine de Neo4j— define estas plataformas como software que permite construir, gobernar y entregar conocimiento semánticamente organizado a los agentes, y subraya que tratar el contexto como un activo empresarial de primer nivel «separa el ciclo de vida del conocimiento organizacional del ciclo de vida de cada agente individual».

Del asistente que responde al agente que actúa

El segundo problema es distinto: aunque el agente sepa, ¿cuándo puede decidir por su cuenta? Deepika Khera, senior director de IA de PayPal, explicó en el Agentic Infrastructure Stack Summit de VentureBeat que la compañía construye una plataforma que da acceso a conocimiento empresarial, valida las decisiones propuestas contra fuentes autorizadas y define cuándo hace falta aprobación humana.

Su caso más exigente es respuesta a incidentes: un flujo de siete agentes que investiga alertas en más de 33.000 servicios, cruzando información de Datadog, ServiceNow y logs internos para separar señal de ruido. Un flujo separado de revisión de seguridad usa hasta 18 agentes. La cantidad no es capricho: responde a los roles, el contexto y los permisos de cada tarea.

El riesgo central sigue ahí, y Khera lo nombró sin rodeos: un diagnóstico incorrecto lleva a una solución incorrecta. «Cada decisión que se propone se valida contra la fuente de verdad».

Ahí entra la memoria: fuentes de datos certificadas y procedimientos operativos estándar, más políticas y evaluaciones de riesgo como controles adicionales. Muchas decisiones siguen requiriendo verificación humana.

Un detalle muy accionable: no siempre conviene dejar que el agente decida cuándo consultar su memoria. PayPal usa el Model Context Protocol (MCP) cuando el agente necesita razonar qué herramienta elegir, pero en su flujo de desarrollo de software forzó la consulta de memoria en un paso determinado. «Para ese flujo tuvimos que forzar: aquí es donde quiero usar la memoria», dijo Khera.

También experimentan con memoria episódica: registran sesiones y resultados de pull requests, y un proceso nocturno de destilación busca lecciones entre usuarios para convertirlas en guía reutilizable.

¿Cómo saber si tu agente funciona de verdad?

Zhang puso el dedo en la herida más común de las evaluaciones: probar con las preguntas equivocadas. Un sistema puede acertar casi todo en su set de test y fallar en producción si los usuarios reales preguntan mayoritariamente lo que el sistema hace mal. «Tu modelo es el mismo, tu proceso es el mismo, pero la distribución es completamente distinta».

Los números del VB Pulse Agentic Reliability and Evals Report de octubre de 2026 muestran que el problema es generalizado: el 42% de los encuestados cuyas organizaciones hacen evaluaciones previas al despliegue reportó que una función de IA o un agente pasó las pruebas internas y falló después en el último año. De quienes reportaron fallos, el 49% dijo que su incidente más grave llegó a clientes. Y el 39% no tenía ningún chequeo automático ni alerta de monitoreo entre las formas en que detectaría una salida de IA incorrecta: dependían de que alguien lo notara.

PayPal responde con simulaciones offline más amplias, generación sintética de preguntas, pruebas de un turno y multiturno, y evaluación con modelos más revisión humana. En el asistente interno midieron más de 1.000 preguntas y unas 1.600 horas ahorradas en 10 semanas, con la advertencia de Zhang de que el volumen de preguntas por sí solo no demuestra productividad.

Qué significa esto para tu startup

El mensaje para un equipo pequeño con presupuesto limitado es incómodo pero liberador: no necesitas el modelo más caro, necesitas escribir lo que tu empresa sabe.

Documenta las definiciones antes de tocar el prompt. Haz una lista de los términos que tu equipo usa y que un modelo no puede adivinar: qué es un cliente activo, qué es churn, qué cuenta como lead calificado, cómo se calcula el MRR. Ese documento es tu primera golden query.
Separa conocimiento de modelo. Guarda definiciones, consultas validadas y playbooks en archivos o en una base propia, no incrustados en un prompt que se rompe con cada actualización. Si mañana cambias de proveedor, el activo se queda contigo.
Antes de hacer fine-tuning, calcula el costo de mantenerlo. Pregúntate cuántas horas de trabajo especializado necesitas cada vez que sale un modelo nuevo. En muchos casos el retorno no está en entrenar, sino en dar mejor contexto.
Arma un set de evaluación con preguntas reales, ponderado por frecuencia. No 50 casos inventados: las preguntas que tus usuarios hacen de verdad, ordenadas por volumen. Si el 60% de las consultas son de facturación, ese 60% pesa en tu métrica.
Fuerza la consulta de memoria en los pasos críticos. Deja autonomía para lo reversible y pon verificación obligatoria contra la fuente de verdad donde un error sea caro.
Instala monitoreo de salidas. El 39% que confía en que un humano lo note es la mejor descripción de un incidente en camino.

El ecosistema de herramientas se mueve en esa dirección y conviene saberlo: en BoxWorks 2026, Box presentó junto a Nvidia un motor de recuperación de contenido que, según la compañía, mejora la precisión de búsqueda un 20% y reduce el consumo de tokens hasta un 90% (SiliconANGLE). La competencia ya no es por quién tiene el mejor modelo, sino por quién estructura mejor el contexto de su empresa.

Conclusión

El salto de 43% a 95% de PayPal no es una historia sobre IA más potente. Es una historia sobre conocimiento mal capturado. La compañía ya tenía los datos; lo que faltaba era el criterio para interpretarlos, escrito de forma portable y probado contra preguntas parecidas a las que la gente pregunta de verdad.

Para un founder, la implicación práctica es que el trabajo aburrido —documentar definiciones, ordenar procedimientos, medir con la distribución real de uso— es exactamente el que genera ventaja. Y es trabajo que ningún proveedor de modelos puede hacer por ti.