Notas del camino / Nuestra historia con la IA

Dejamos de esperar.
Empezamos a construir.

Cómo cambiamos de rumbo en American Data Networks y empezamos a aprender a construir nosotros mismos la automatización que queríamos.

Teníamos que hacerlo nosotros mismos.
Ese fue el punto de cambio.
2años
2expertos en IA
4programadores

Estaba cansado de esperar.

Contraté a dos expertos en IA y cuatro programadores porque quería incorporar automatización a mi empresa. Dos años después, todavía no tenía la automatización que había estado esperando.

Prescindí del equipo. Le dije a mi hijo que teníamos que hacerlo nosotros mismos.

Así recuerdo ese punto de cambio. Fue una decisión de asumir la responsabilidad de sacar el trabajo adelante. Tendríamos que aprender cosas que todavía no sabíamos.

Las personas que lo hacen posible.

Mi hijo y yo asumimos el reto. Mike es parte de este camino, y José Alejandro también.

José Alejandro es una pieza clave. Está dispuesto a hacer lo que haga falta, a cualquier hora, desde hardware hasta software. Cuando uno intenta construir algo, esa disposición importa. Siempre hay otro problema por resolver, y el trabajo no se limita a una descripción de puesto.

Quiero que tenga un lugar de verdad en esta historia. Los proyectos importan, pero también las personas dispuestas a hacer lo necesario para sacarlos adelante.

¿Cómo se instala Linux?

Hay un momento que quiero encontrar en el historial de ChatGPT de Mike. Preguntó cómo instalar Linux en un servidor que teníamos en la oficina. Recuerdo que fue en septiembre.

Me gusta incluirlo en nuestra historia porque es un punto de partida muy básico y práctico. Teníamos un servidor. Teníamos algo que queríamos hacer. Primero necesitábamos aprender a ponerlo a funcionar.

Todavía necesito la conversación original para ponerle una fecha exacta. Prefiero dejar eso pendiente antes que contar la historia con más certeza de la que tengo.

El trabajo empezó a tomar forma.

Al revisar nuestros mensajes y registros de proyectos, veo cómo las preguntas se volvieron más concretas. ¿Podemos dejar de hacer esta prueba a mano? ¿Podemos encontrar la información que ya tiene la empresa? ¿Podemos saber quién es responsable del seguimiento?

Los registros también me obligan a ser honesto con el orden de los hechos. Un correo de septiembre informa de una prueba automatizada de ancho de banda que se ejecutó a finales de agosto. Todavía necesito ubicarla respecto al cambio de equipo. No quiero dejar de reconocer trabajo que se hizo en el camino solo para simplificar la historia.

Empezar con algo útil.

Las pruebas de ancho de banda fueron un ejemplo práctico. Quería que funcionaran sin que alguien tuviera que hacer cada paso a mano. Un correo de entrega informó de una ejecución sin intervención. Es una parte útil de la historia, aunque todavía estemos revisando la secuencia completa.

Dar al trabajo un lugar donde ejecutarse.

Los mensajes pasan a tratar sobre un servidor Linux para recopilar información. La pregunta de instalación que recuerdo de Mike pertenece a algún punto de esta primera etapa; su lugar exacto sigue pendiente.

Conectar las piezas.

El conocimiento de la empresa, las conversaciones con clientes, las revisiones de facturación y el enrutamiento de solicitudes se convirtieron en proyectos concretos. Algunas herramientas se implementaron. Otras partes todavía estaban en diseño o en pruebas.

Descubrir dónde falla.

Las nuevas pruebas encontraron cosas que el sistema de enrutamiento no detectaba. Un modelo local de IA produjo respuestas convincentes que iban más allá de la evidencia. Esos hallazgos nos dejaron trabajo por hacer antes de permitir que otras personas dependieran de los resultados.

Lo que realmente quiero de la IA.

Quiero que haga trabajo útil en la empresa. Encontrar una respuesta sin buscar conversación por conversación. Facilitar que veamos qué necesita atención. Ayudarnos a cumplir lo que le dijimos a un cliente que haríamos.

Suena sencillo hasta que uno empieza a unir las piezas. La información puede contradecirse. Un cliente puede preguntar lo mismo de distintas maneras. Un sistema puede decir que una tarea está cerrada mientras la persona del otro lado sigue esperando.

Esos son los problemas detrás de los proyectos.

Aprender haciendo

Los problemas
que se convirtieron en proyectos.

¿Quién se está haciendo cargo del cliente?

Puede haber un chat, un correo, un nombre asignado y una actualización prometida. Quiero saber quién realmente asumió la responsabilidad y qué sigue.

Creamos un panel para reunir esas piezas. Nos ayuda a revisar la conversación, dar seguimiento a los compromisos y preparar una respuesta con el contexto a la vista.

Hay una distinción que me importa: poner el nombre de alguien en un caso no significa que lo haya aceptado. Cerrar un caso no demuestra que el problema del cliente esté resuelto. La herramienta nos ayuda a ver el trabajo; las personas todavía tienen que cumplir los compromisos.

El servicio y la factura deberían contar la misma historia.

Trabajamos en un auditor para comparar el estado del servicio con la facturación recurrente. Si esos registros no coinciden, necesitamos entender por qué.

También tuvimos que aprender cuándo dejar algo como está. Una suscripción pausada no siempre significa lo mismo. Un nombre de cuenta parecido no basta para hacer un cambio.

El proyecto se convirtió en un monitor con correcciones muy limitadas y comprobaciones posteriores. Algunos contratos revisados se reabrieron con aprobación. Otros casos quedaron en manos de personas porque la evidencia no era suficientemente clara. Quiero que la automatización ahorre trabajo sin crearle un problema nuevo al cliente.

Ya sabíamos más de lo que podíamos encontrar fácilmente.

American Data tiene información repartida entre correos, registros de clientes, servicios, registros de red y órdenes de trabajo. Empezamos a reunir esas fuentes en Brain para poder buscarlas.

A finales de octubre, un informe guardado mostraba ocho índices con datos, incluidos más de dos millones de registros de correo. Era un avance concreto: teníamos mucha más información de la empresa disponible para consultar.

No era la meta final. Todavía había que investigar registros faltantes. Había que comprobar los accesos. La información contradictoria todavía requería decidir en qué fuente confiar. Reunir la información nos dio una base para seguir construyendo.

Nuestros clientes hablan como nuestros clientes.

La gente no escribe a soporte usando las etiquetas de nuestros sistemas. Usa expresiones locales, comete errores de ortografía y alterna entre español e inglés.

Preparamos un diccionario de expresiones costarricenses para el sistema de enrutamiento. La idea era ayudarlo a reconocer lo que la gente quiere decir tal como habla en realidad.

Ese diccionario está construido, pero todavía necesita revisión local y pruebas antes de que dependamos de él. Entender una expresión debería ayudarnos a hacer una mejor pregunta. No debería darle permiso a un sistema para cambiar una factura o decidir que una avería está confirmada.

Tuvimos que hacerle preguntas que no había practicado.

Un sistema de enrutamiento puede verse bien con los ejemplos que ya venimos usando. Yo quería saber qué pasaría con otras formas de preguntar.

Un nuevo conjunto de pruebas reveló solicitudes que no entendía bien, incluidas expresiones locales y preguntas que necesitaban aclaración. Las pruebas conocidas pasaban, pero las nuevas mostraron vacíos.

Eso también es un avance útil. Nos dice dónde trabajar después. Todavía necesitamos pruebas más amplias y revisión humana antes de considerar esos resultados una prueba de que está listo para el uso diario.

Responder rápido no basta.

Probamos un modelo local de IA con fragmentos de correos reales. ¿Podía convertir lo que encontrábamos en una respuesta mientras la búsqueda y el procesamiento de correo seguían funcionando?

Respondía rápido. Pero al comparar las respuestas con los fragmentos originales, algunas agregaban hechos que la fuente no respaldaba. Podía haber una cita y aun así la respuesta podía estar equivocada.

Una versión más restringida comprobaba citas textuales y rechazó una que había sido modificada. También descubrimos que generar respuestas ralentizaba la búsqueda más de lo permitido por nuestro plan de pruebas.

Por eso, ese piloto no estaba listo para el personal. Habíamos construido algo que podíamos probar, y la prueba nos mostró lo que todavía había que corregir. Prefiero saberlo ahora antes que poner una respuesta equivocada y convincente frente a alguien que confía en ella.

Seguimos construyendo.

No quiero que esta página dé a entender que ya terminamos todo. Tenemos herramientas, pruebas y piezas que funcionan. También tenemos vacíos, errores por corregir y decisiones que todavía necesitan a una persona.

Lo que cambió fue que tomamos el trabajo en nuestras manos. Empezamos a hacer las preguntas básicas, mirar los resultados y decidir qué intentar después.

Ese es el camino que quiero compartir aquí. Las personas, los proyectos y lo que aprendemos mientras seguimos adelante.