El texto es un blog post que busca compartir la experiencia personal y profesional del autor (CDO de ixpantia) sobre el uso de LLMs (Large Language Models), tanto en su trabajo individual como en la implementación organizacional, describiendo casos de uso actuales y perspectivas futuras.
Ayer me preguntaron cómo estoy usando LLMs y no pude formular una respuesta inmediata. Soy el Chief Data Officer de ixpantia, y es un tema que me interesa de sobremanera. Estoy dedicando bastante tiempo para experimentar con estas herramientas, en mi propio tiempo y con el equipo. Si bien los estoy usando cada vez más en mi día a día me costó responder porque mi mente está en una lista de aplicaciones que aún estamos por desarrollar. Nuestros ensayos se enfocan en entender el impacto de LLM sobre la eficacia y eficiencia en nuestros flujos de trabajo. Buscamos identificar las aplicaciones que tienen sentido hacer parte de las herramientas en el día a día del equipo para la ejecución de proyectos.
En general veo lo siguiente: En mi uso personal sin duda alguna los LLMs están impactando positivamente mi productividad. Para el equipo el enfoque está en desarrollar herramientas compartidas para impactar la productividad de una forma consistente y coherente, y para mejorar el control de calidad de entradas de productos en proyectos.
Cada LLM tiene sus características y esto es importante tenerlo en cuenta, porque implica que cada modelo da mejores resultados formulando las preguntas y respuestas que das de forma ligeramente diferente. En los últimos 6 meses he usado LLMs principalmente para lo siguiente:
Particularmente para configurar sistemas noto que cualquier problema de configuración en Linux lo busco resolver primero en un chat de LLM. Típicamente lo resuelvo rápido pero pocas veces la primera respuesta es la correcta y hay que leer las respuestas antes de ejecutarlas.
Como buscador de respuestas, LLMs tienden a llevar a la respuesta más rápidamente, en comparación a ir a través del contenido de una lista de links, pero hay que saber discernir cuando hay respuestas que no tienen lógica. Esta actividad de discernir entre una respuesta que tiene sentido, y una respuesta que no, no siempre es tan fácil o obvio. Si el código propuesto no funciona, no funciona. Pero para casos donde "correr" no es lo mismo que "funcionar" - algo que es típico al trabajar con datos - esto requiere que pensar en pruebas y validaciones. Por ejemplo, puedes pedir código para calcular una métrica compleja. El código propuesto por LLMs puede arrojar código que funciona, pero la métrica calculada no necesariamente es la correcta - necesitas un paso adicional para validarlo. }
Por suerte, no solamente la calidad del código propuesto por LLMs cada vez es mejor, pero también son buenos en escribir pruebas automáticas. Hace un año di una charla donde mostraba los paquetes que ChatGPT alucinaba paquetes para resolver un problema. Ese tipo de errores los estamos viendo menos.
Con el equipo estamos trabajando para llevar estas experiencias a nuestro día a día de trabajo colaborativo. Si bien somos el gremio donde estas herramientas tienen mayor adopción, llevar a un equipo el uso de LLMs para agilizar sus procesos de programación requiere que todos tengamos un proceso compartido que seguimos para resolver retos. Si seguimos pasos similares es más fácil pre-configurar un LLM para que nos ayude a cumplir con el estilo, los lineamientos y mejores prácticas de la organización.
Por otro lado, tengo un amigo que desarrolla y mantiene un producto SaaS en su empresa. Él ve esto completamente diferente: Su objetivo - y se está acercando - es que el desarrollador se enfoque en formular requerimientos y validar la integración del resultado con el resto del producto existente. Si no está correcto, la idea no es corregir el código que produce el LLM, sino ajustar los prompts que contienen la descripción del requisito para que el LLM genere, compile y pruebe una nueva versión de la solución. Esto es posible cuando el alcance de lo que se está construyendo está bien definido. En nuestra práctica en ixpantia hoy día sería más trabajo definir el contexto para cada cliente y cada proyecto y desarrollar los prompts para las situaciones específicas dentro del cual estamos desarrollando que escribir el código.
A manera de experimento, un colega creó un NotebookLM con toda nuestra documentación sobre soluciones y algoritmos de recomendación. Es mucha información y tomaría días leerlo por encima, para tener una idea del contenido. Con el LLM tenemos buenos resúmenes y referencias a detalles puntuales que necesitamos para formular una solución o ejecutar en un proyecto. No quita la necesidad de leer y sacar el rato para procesar y entender los documentos fuente. Pero sirve como guía para acceder a los párrafos de particular interés. Vemos que el uso de LLMs para este tipo de aplicaciones requiere tener la disciplina de validar la fuente a la que apunta antes de usar el resultado. La documentación con la que el LLM está alimentado tiene diferentes niveles de calidad y validación.
Lo que está en proceso de desplegar en el equipo es una herramienta que busca mejorar la calidad de entregas de productos de datos. Estamos trabajando en el uso de LLM's para interpretar un contrato de datos - que contiene todas las especificaciones para uno o más ETL's solicitados - para crear de forma automática el código con las pruebas de calidad de datos y las visualizaciones para una inspección visual. Ambos pasos toman suficiente tiempo para que sea algo que fácilmente queda incompleto porque nos apuramos para lograr la entrega a tiempo. Además, tenemos la tendencia de pensar que ya lo vimos, y lo hicimos bien, y que por ende no hace falta escribir esas pruebas automáticas.
Este tipo de herramientas enfocadas en validación de calidad de datos, y calidad de entrega de código y documentación es nuestro enfoque interno en este momento. Al automatizar la creación de pruebas y procesos de validación esperamos tener entregas que siempre respondan por completo a la solicitud inicial.
La entrega de documentación a clientes también va a cambiar. Nuestra forma de trabajo, con énfasis en documentación escrita, ya facilita que nuestros clientes lo incluyan en un LLM interno. Pero queremos hacer más y entregar un formato que incluya la documentación y un prompt optimizado para ponero en el contexto técnico y contexto de negocio adecuado para maximizar su usabilidad. Esto es independiente de la herramienta LLM que el cliente decida usar para dar el servicio a su organización.
Para experimentar hay dos desarrollos recientes que nos han llamado la atención y que estamos trabajando activamente por su potencial valor en proyectos. Primero esta Ollama, y la creciente lista de modelos destilados para ser buenos en aplicaciones puntuales. Allí hay un mundo de oportunidades para ofrecer herramientas de valor a un menor costo para nuestros clientes.
A la misma vez surgen plataformas como groq.com donde pronto esperamos poder subir modelos LLM a medida. La apuesta de empresas como groq es crear una infraestructura de inferencia más costo eficiente. Y esto en un futuro cercano nos va a dar la posibilidad de desplegar modelos privados a producción a bajo costo, lo que cambia la economía de las soluciones que podemos crear.
Hay mucho más que se nos viene a la mente y muchas novedades por venir en los próximos meses. Si este blog post te aportó valor, háznoslo saber, y si quieren hablar del tema con uno de nuestros expertos en ciencia, ingeniería y estrategia de datos para buscar valor en aplicaciones de LLM en tu organización, contáctanos en hola@ixpantia.com.