La idea es dividir el flujo de trabajo en dos flujos para optimizar costos y estabilidad, como se propuso con el Arquitectura LATMcon algunas mejoras adicionales para administrar datos y memorias específicas de Recetas de datos…
Corriente 1: Asistente de recetas
Esta corriente utiliza agentes LLM y modelos más potentes para generar fragmentos de código (recetas) a través de una interfaz conversacional. El LLM recibe información sobre fuentes de datos (especificaciones API y esquema de base de datos) para que la persona que crea recetas pueda programar nuevas habilidades de manera conversacional más fácilmente. Es importante destacar que el proceso implementa una etapa de revisión en la que un ser humano puede verificar y modificar el código generado y los resultados antes de guardarlos en la memoria. Para una mejor generación de código, esta corriente utiliza modelos más potentes y agentes autónomos, lo que genera mayores costos por solicitud. Sin embargo, hay menos tráfico por lo que los costes están controlados.
Corriente 2: Asistente de análisis de datos
Esta corriente es utilizada por un grupo más amplio de usuarios finales que hacen preguntas sobre los datos. El sistema verifica la memoria para ver si su solicitud existe como un hecho, por ejemplo “¿Cuál es la población de Malí?”. Si no, comprueba las recetas para ver si tiene la habilidad de obtener la respuesta, por ejemplo, ‘Cómo obtener la población de cualquier país.‘. Si no existe memoria o habilidad, se envía una solicitud a la cola del asistente de recetas para que se agregue la receta. Idealmente, el sistema se puede completar previamente con recetas antes del lanzamiento, pero la biblioteca de recetas puede crecer activamente con el tiempo según la telemetría del usuario. Tenga en cuenta que el flujo de usuarios finales no genera código ni consultas sobre la marcha y, por lo tanto, puede utilizar LLM menos potentes, es más estable y seguro e incurre en costos más bajos.
Actualización de datos asincrónica
Para mejorar los tiempos de respuesta para los usuarios finales, las recetas se actualizan de forma asincrónica siempre que sea posible. La memoria de recetas contiene código que se puede ejecutar según un cronograma establecido. Las recetas se pueden ejecutar de forma preventiva para prepoblar el sistema, por ejemplo, recuperando la población total de todos los países antes de que los usuarios finales las soliciten. Además, los casos que requieren agregación de grandes volúmenes de datos extraídos de API se pueden ejecutar fuera de horario, mitigando, aunque en parte, la limitación de consultas agregadas que utilizan datos de API.
Jerarquía de la memoria: recordar habilidades y hechos
Lo anterior implementa una jerarquía de memoria para guardar “hechos” que pueden promoverse a “habilidades” más generales. La promoción de la recuperación de memoria a recetas se logra mediante una combinación de búsqueda semántica y reclasificación y transformación de LLM, por ejemplo, solicitando a un LLM que genere una intención y un código generales, por ejemplo, ‘Obtenga la población total de cualquier país.‘a partir de una intención y un código específicos, por ejemplo, ‘¿Cuál es la población total de Malí?‘.
Además, al incluir automáticamente recetas como funciones disponibles para el LLM de generación de código, su conjunto de herramientas reutilizable crece de manera que las nuevas recetas son eficientes y llaman a recetas anteriores en lugar de generar todo el código desde cero.
Al capturar las solicitudes de análisis de datos de los usuarios y hacerlas muy visibles en el sistema, se aumenta la transparencia. El código generado por LLM se puede examinar, optimizar y ajustar de cerca, y las respuestas producidas por dicho código se comprenden bien y son reproducibles. Esto actúa para reducir la incertidumbre que enfrentan muchas solicitudes de LLM en torno a la conexión a tierra y las alucinaciones.
Otro aspecto interesante de esta arquitectura es que captura requisitos específicos de análisis de datos y la frecuencia con la que los usuarios los solicitan. Esto se puede utilizar para invertir en recetas más utilizadas que aporten beneficios a los usuarios finales. Por ejemplo, si se accede con frecuencia a una receta para generar un informe de situación de respuesta humanitaria, el código de receta para ese informe se puede mejorar de forma proactiva.
Este enfoque abre la posibilidad de una biblioteca de recetas de datos mantenida por la comunidad que abarque múltiples dominios: un centro de recetas de datos. De manera similar a los sitios web de fragmentos de código que ya existen, agregaría la dimensión de datos y ayudaría a los usuarios en la creación al proporcionar programación conversacional asistida por LLM. Las recetas podrían recibir puntos de reputación y otros comentarios similares de las plataformas sociales.
Como ocurre con cualquier arquitectura, es posible que no funcione bien en todas las situaciones. Una gran parte de las recetas de datos está orientada a reducir los costos y riesgos asociados con la creación de código sobre la marcha y, en cambio, a construir una biblioteca reutilizable con más transparencia e intervención humana. Por supuesto, se dará el caso de que un usuario pueda solicitar algo nuevo que aún no sea compatible con la biblioteca de recetas. Podemos crear una cola para procesar estas solicitudes y, al proporcionar programación asistida por LLM, esperamos que se reduzcan los tiempos de desarrollo, pero habrá un retraso para el usuario final. Sin embargo, esta es una compensación aceptable en muchas situaciones en las que no es deseable dejar libre código no moderado generado por LLM.
Otra cosa a considerar es la actualización asincrónica de recetas. Dependiendo de la cantidad de datos necesarios, esto puede resultar costoso. Además, es posible que esta actualización no funcione bien en los casos en los que los datos de origen cambian rápidamente y los usuarios necesitan esta información muy rápidamente. En tales casos, la receta se ejecutará cada vez en lugar de recuperar el resultado de la memoria.
El mecanismo de actualización debería ayudar con las tareas de agregación de datos en las que los datos provienen de API, pero aún existe el hecho de que los datos sin procesar subyacentes se incorporarán como parte de la receta. Por supuesto, esto no funcionará bien para volúmenes de datos masivos, pero al menos limita la ingesta en función de la demanda del usuario en lugar de intentar ingerir un conjunto de datos remoto completo.
Finalmente, como ocurre con todas las aplicaciones de ‘Chat con datos’, serán tan buenas como los datos a los que tienen acceso. Si los datos deseados no existen o son de baja calidad, el rendimiento percibido será deficiente. Además, existen desigualdades y sesgos comunes en los conjuntos de datos, por lo que es importante realizar una auditoría de datos antes de presentar información al usuario. Por supuesto, esto no es específico de las recetas de datos, sino uno de los mayores desafíos que plantea la puesta en práctica de tales técnicas. ¡Basura dentro basura fuera!
La arquitectura propuesta tiene como objetivo abordar algunos de los desafíos que enfrenta LLM “Chat With Data”, al ser…
- Transparente — Las recetas son muy visibles y revisadas por un humano antes de ser promocionadas, lo que mitiga los problemas relacionados con las alucinaciones y los resúmenes de LLM.
- determinista — Al ser código, producirán los mismos resultados cada vez, a diferencia del resumen de datos de LLM.
- Actuante — Implementar una memoria que capture no solo hechos sino habilidades, que pueda actualizarse de forma asincrónica, mejora los tiempos de respuesta
- Barato— Al estructurar el flujo de trabajo en dos flujos, el flujo de usuarios finales de gran volumen puede utilizar LLM de menor costo
- Seguro — El grupo principal de usuarios finales no activa la generación y ejecución de código o consultas sobre la marcha, y cualquier código se somete a una evaluación humana para garantizar su seguridad y precisión.
Publicaré una serie de publicaciones de blog de seguimiento que detallan la implementación técnica de Data Recipes a medida que trabajamos en las pruebas de usuario en Tipo de datos.
Grandes modelos de lenguaje como creadores de herramientas, Cai y otros, 2023.
A menos que se indique lo contrario, todas las imágenes son del autor.
Si lo deseas, dale me gusta a este artículo y ¡estaría encantado de que me siguieras! Puedes encontrar más artículos. aquí.