Envío de IA Bajo Restricciones: Construir, Comprar o Eliminar

Soy Dave. Soy un Gerente de Ingeniería en Capital Untap, y gracias por venir a mi charla sobre Envío de IA Bajo Restricciones. Cuando propuse la charla, no tenía el subtítulo de cómo desperdiciar 200k en IA. Así que, como pueden imaginar, han sido unos meses divertidos para mí.

Capital Untap es una fintech de tamaño medio. Hacemos crédito y ahorros para pequeñas y medianas empresas, Reino Unido y EE.UU., y solo tenemos alrededor de 100 o más desarrolladores, bastante pequeño para la cantidad de ingresos que generamos. Nuestros ejecutivos senior están muy interesados en la IA, muy entusiastas.

Cuando vimos el correo electrónico del CEO de Shopify anteriormente, me di cuenta de dónde mi CEO obtuvo muchas de sus ideas. Y tenemos una cultura de pilotos y experimentación dentro de la empresa. Y así, esta es solo una breve historia de fracaso, y cómo desperdiciamos una gran cantidad de dinero, y lo que estamos haciendo de manera diferente ahora. Y la lección clave que saqué de esto fue que le dimos un trato especial a la IA, y nos movimos demasiado rápido. ¿Qué significa moverse demasiado rápido? Bueno, el equipo de IA en realidad surgió del negocio. No comenzaron en ingeniería. El Jefe de IA originalmente venía del negocio.

Lo cual creo que es bastante sensato. Pero aquí estamos. No es el comienzo más fuerte. Si haces algún tipo de servicio al cliente, probablemente se te haya ocurrido que podrías tener un AI chat bot. Es un caso de uso muy obvio. Y es lo primero que el equipo de IA se propuso hacer. Intentando construir algo que pudiera chatear con los clientes, responder preguntas simples, y así sucesivamente.

Entonces, como digo, el equipo comenzó fuera de ingeniería, fuera de la gobernanza y estándares de ingeniería. Y después de ocho meses de arduo trabajo en este chatbot, entre otros proyectos, ingeniería ganó el argumento, y el equipo fue trasladado a trabajar para mí. Comencé con la evaluación de proyectos, asumiendo un nuevo equipo, evaluando lo que están haciendo. Había más que solo el chatbot, pero era el grande. Era su proyecto insignia. Era lo grande en lo que estábamos trabajando.

Y cuando llegó a mí, me decían, estamos a semanas de salir en vivo. Estamos muy cerca. Vamos. Así que aquí es donde entramos con la evaluación usando puertas de etapa. Quiero decir, el paso uno es solo evaluaciones. Estoy seguro de que todos en la audiencia saben lo que es, pero las pruebas de integración de LLM, esencialmente, llegan a un cierto nivel, pasan al modo sombra para nuestro chatbot. Así que comentaría sobre las consultas de los clientes y la producción. Y solo diría, esto es lo que habría dicho si estuviera hablando con el cliente.

Y eso dio una oportunidad a los agentes de operaciones para comparar lo que decían con el chatbot y darnos cualquier retroalimentación. Y por supuesto, necesitamos tener un alto nivel de confianza con esa puerta de etapa antes de pasar al contacto con el cliente. Aquí es donde el problema comenzó a surgir. Si le haces una pregunta al chatbot que no está en su base de conocimiento, la mayoría de las veces escalará a un humano, pero algunas veces simplemente inventará algo, lo cual estoy seguro que no sorprende a nadie, su trabajo con LLMs. Era bastante bueno, pero una precisión del 90 al 95% no era suficiente para algo que va a hablar con clientes miles de veces a la semana. Y aquí fue donde el problema comenzó a surgir, ¿verdad? Complejidad. Tuvimos mucho de esto cubriendo las grietas de un pequeño problema de LLM. Te está mintiendo, bien, ¿cómo solucionamos eso? Ponemos algo de validación después de que da su respuesta para solo verificar, ¿es esto fácticamente correcto? Y tal vez eso funcione bastante bien, pero en última instancia tenemos que construir la validación y probarla antes de saber. Así que no solo tienes la complejidad de una especie de solución tras solución, sino que es muy difícil de estimar porque realmente no sabemos qué tan bien va a funcionar.

No necesitas leer esta diapositiva, pero solo estaba tratando de darlo como un ejemplo de la complejidad con la que tuvimos que lidiar. Creo que necesitábamos duplicar el equipo a al menos cuatro desarrolladores y trabajar en ello por mucho más tiempo para llegar a un sistema adecuadamente en producción. Así que la complejidad y la incertidumbre realmente hicieron de este un proyecto fallido, en última instancia. Para dar un ejemplo contrario, hemos construido otros proyectos de IA dentro de Capital OnTap. Tenemos uno llamado Blaze, que es esencialmente transcripción de IA y resumen de llamadas de clientes. Es un poco más complejo que eso, pero es bastante sencillo. Y eso fue construido por el equipo de ingeniería de operaciones. Así que comenzó en el equipo correcto. Comenzó con un enfoque muy de producto, y comenzamos con el seguimiento de métricas operativas. Así que después de una llamada telefónica, el agente de operaciones hace el cierre, y hemos reducido ese tiempo de tres minutos a dos, lo cual es un impacto masivo para 600 llamadas al día. Así que llegó el momento de la decisión para Merlin, nuestro chatbot. Tuvimos que decidir qué hacer con él.

Habíamos gastado al menos 200K en salarios de personas, como los involucrados, y costos de LLM. Y tuvimos que decirle al negocio, mira, esto que pensabas que estaba a semanas de distancia en realidad va a ser pausado y ahora está a meses de distancia. Pero el CEO entiende la falacia del costo hundido, así que lo matamos y decidimos buscar proveedores externos. En última instancia, decidimos que esto no era nuestra competencia principal para un proyecto tan complejo, y deberíamos centrarnos en el lado fintech de las cosas y proyectos de IA más simples que podamos manejar dentro de los equipos de producto, pero ir con terceros para algo tan complicado como esto. Así que teníamos dos proveedores que nos gustaban. Básicamente, solo encontramos otros negocios que se habían integrado con ellos y fuimos a hablar con ellos solo para ver cómo se desempeñaban.

Uno fue mucho más rápido, y uno de ellos nos mintió sobre la cantidad de saldo, lo cual fue muy interesante de ver en el mundo real en vivo. Y mientras estábamos terminando el proyecto principal de IA, decidimos reiniciar cómo hacemos IA en CapitalTap, por lo que ya no tenemos un equipo de IA separado. Tenemos ingenieros de IA que se integrarán en un equipo de producto existente, les ayudarán a entregar su proyecto, y luego se retirarán.

En última instancia, decidimos que un equipo construido alrededor de una tecnología no puede poseer dominios y productos de la misma manera que un equipo de producto real puede. Y luego, nuevamente, volviendo a la comparación entre los dos. Blaze casi comenzó accidentalmente en el equipo correcto, la propiedad correcta. Y si lees esto muy brevemente, lo que ves no son realmente problemas de IA. Son solo problemas de ingeniería estándar, y esa es realmente la lección que tomamos de esto.

Nuevamente, fuera de nuestra competencia central para entregar un proyecto de IA muy complicado, así que no lo hicimos. Y utilizamos el mismo proceso de admisión para IA que para cualquier otro proyecto, cualquier otra característica. Así que tenemos un propietario de producto nombrado, métricas de éxito claras, puertas de etapa que te he mostrado. Cada puerta tiene un criterio de eliminación, por lo que puedes simplemente retirarte de un proyecto si no es lo suficientemente bueno. Y esto es lo que realmente se reduce para mí, ¿puede un equipo de producto poseerlo? ¿Necesitas especialistas permanentes en IA para poseerlo? Para nosotros, nuevamente, eso es una señal de alerta. No somos una empresa de IA.