…gobierno del pueblo, por el pueblo, para el pueblo…
— Abraham Lincoln, Discurso de Gettysburg (1863)
El costo de la IA está cayendo rápidamente. Las capacidades de clase GPT-4 costaban aproximadamente 30 dólares por millón de tokens a principios de 2023; hoy en día, lo mismo cuesta menos de $1 , y algunos proveedores están bajando los costos por debajo de $0,10 . En todos los puntos de referencia, los precios de inferencia han caído entre 9 y 900 veces por año, con una caída media cercana a 50 veces. Incluso los modelos de vanguardia se están volviendo dramáticamente más baratos con cada generación, seguidos de cerca por los modelos de código abierto. Y, lo que es más importante, incluso si la inteligencia “a nivel de genio ganadora del Premio Nobel” aún no está aquí, la inteligencia que es suficiente para la gran mayoría del trabajo de conocimiento ya está aquí y se vuelve más barata cada mes. A este ritmo, pronto entraremos en la era de la inteligencia prácticamente libre, del tipo que es más que suficiente para el trabajo cotidiano del conocimiento.
Divulgación: esta publicación es una perspectiva dirigida por Aditya G. Parameswaran, profesor asociado de EECS y codirector del Laboratorio de datos EPIC en UC Berkeley, junto con sus colaboradores. Es en parte un estudio del panorama y en parte una perspectiva, y varias de las direcciones de investigación que se analizan a continuación (incluida la especulación agente, la memoria estructurada y la síntesis de sistemas de datos personalizados desde cero) se basan en el trabajo en curso de los propios autores.
Entonces, ¿qué significa esta nueva era de inteligencia casi gratuita para los sistemas de datos? Creemos que tres nuevos desafíos (y oportunidades) surgen de costos de inferencia casi nulos:
Sistemas de datos para agentes. Los agentes pronto se convertirán en la carga de trabajo dominante para los sistemas de datos, con enjambres de agentes creados en respuesta a cada solicitud del usuario final. Dadas las diferencias en las características entre agentes y humanos (o aplicaciones que actúan en su nombre), ¿cómo deberíamos rediseñar los sistemas de datos para dichos usuarios agentes?
Sistemas de datos de agentes. A medida que los agentes comienzan a asumir la mayor parte del trabajo de conocimiento, se necesita un nuevo sustrato para que miles de agentes administren el estado en tareas de larga duración, coordinen y alcancen consensos, y aborden fallas. ¿Cómo son los sistemas de datos que ejecutan y gestionan enjambres de agentes de manera confiable y eficiente?
Sistemas de datos por agentes. Los agentes se están volviendo rápidamente capaces de sintetizar sistemas de datos completos de una sola vez, lo que significa que podemos reconstruir sistemas personalizados para cada nueva carga de trabajo. Verificar que dichos sistemas coincidan con el comportamiento previsto es un desafío. ¿Qué se necesita para permitir que los agentes sinteticen sistemas de datos en los que realmente podamos confiar?
Sistemas de datos para, de y por agentes
A continuación, analizaremos cada uno de ellos con más detalle y luego analizaremos el futuro entrelazado de los sistemas y agentes de datos, especialmente cuando los tres desafíos se cruzan.
Sistemas de datos para agentes
Un agente que consulta una base de datos no se comporta como una persona o una herramienta de BI. Realiza lo que llamamos especulación agente: un flujo de trabajo heterogéneo y de gran volumen que abarca la introspección de esquemas, la exploración en columnas y la formulación de consultas parciales y luego completas. Con varios agentes, cada uno de los cuales explora partes del espacio de hipótesis, cada solicitud de usuario podría ascender a miles de consultas SQL individuales. Ahora, los usuarios pueden realizar tareas de datos de 'alto nivel', por ejemplo, análisis de causa raíz (por ejemplo, 'por qué cayeron las ventas de café en Berkeley este año') o análisis de cohortes exploratorios (por ejemplo, 'qué segmentos de usuarios tienen más probabilidades de abandonar el próximo trimestre'), cada uno de los cuales involucra un espacio combinatorio de uniones, agregaciones y combinaciones de filtros potenciales.
Sistemas de datos rediseñados para respaldar de manera más efectiva la especulación agente
Las solicitudes de estos agentes tienen varias oportunidades de optimización. Por ejemplo, en una prueba comparativa de texto a SQL con varios agentes intentando cada tarea, solo entre el 10 y el 20 % de los subplanes son distintos. Por tanto, entre el 80 y el 90% de las subconsultas realizan trabajo duplicado. Los mismos experimentos muestran que las tasas de éxito de las tareas aumentan significativamente con más intentos agentes, por lo que la redundancia es realmente útil. Pero desde la perspectiva del sistema de datos es un trabajo inútil.
Un sistema de datos centrado en el agente puede explotar estas propiedades para ayudar a los agentes a progresar más rápido. Puede reutilizar resultados en subplanes superpuestos, basándose en ideas de literatura de décadas de antigüedad sobre optimización de consultas múltiples y escaneos compartidos. O el sistema de datos puede intentar satisfacer, devolviendo respuestas aproximadas que sean lo suficientemente buenas para que los agentes progresen, aprovechando el trabajo de la literatura AQP, o transmitiendo los resultados de los operadores finales o intermedios para ayudar a los agentes a decidir si ver el resto es necesario o útil.
Otra oportunidad aquí es repensar completamente la interfaz de consulta: en lugar de que los agentes emitan una única consulta SQL a la vez, podrían emitir un lote de consultas, cada una con sus propios requisitos de aproximación. Dado que enumerar un espacio de búsqueda exponencial (como en los ejemplos anteriores de causa raíz o análisis de cohorte) no es un buen uso de la capacidad de razonamiento agente, tal vez los sistemas de datos deberían admitir primitivas de nivel superior en lugar de requerir que los agentes enumeren cada consulta SQL explícitamente. Una idea aquí es recurrir a macros Jinja estilo DBT para proporcionar primitivas basadas en bucles para que los agentes interactúen con los sistemas de datos.
Un ejército de agentes con cafeína listos para completar incansablemente sus tareas de datos
Una última oportunidad aquí es dejar de pensar en los sistemas de datos como ejecutores pasivos de consultas; Los sistemas de datos podrían ser proactivos, ya que poseen más bases en datos y características del sistema de las que los agentes pueden carecer a priori: podrían guiar a los agentes en diferentes direcciones, proporcionar resultados para consultas relacionadas y también proporcionar retroalimentación a nivel de desempeño (por ejemplo, en lugar de ejecutar una consulta costosa, el sistema podría proporcionar primero al agente una estimación de latencia). La razón por la que podemos hacer esto ahora a diferencia del pasado es que un agente puede aceptar cualquier forma de comentarios textuales y no espera un resultado de consulta SQL estricto. De hecho, el sistema de datos también podría preparar vistas tanto materializadas como virtuales para un agente de antemano, proporcionándolas al agente como parte del contexto, ya que esto puede ser más barato o más efectivo que tener un agente que las cree o las use.
Sistemas de datos de agentes
Anteriormente, nos centramos en cómo interactúan los agentes con los sistemas de datos. Ahora, consideramos todo lo demás que los agentes necesitan para seguir trabajando: dónde viven, cómo recuerdan, cómo se coordinan entre sí y cómo abordan los fracasos de los demás. Este sustrato agente está separado de la pila de inferencias que alimenta la inteligencia en bruto. Sin embargo, la pila de inferencia en sí se está abstrayendo a través de API (por ejemplo, de OpenAI o Anthropic) o, para modelos abiertos, a través de marcos de servicio que ocultan detalles de bajo nivel. Hasta ahora, el sustrato agente se ha gestionado a través de arneses como Claude Code y Codex, junto con varios mecanismos para almacenar y recuperar la memoria.
Primero, en el frente de la memoria, la creencia actual es que todo lo que se necesita son archivos; Los agentes escriben en archivos Markdown no estructurados (MD), que luego se pueden buscar mediante grep o mediante recuperación basada en incrustaciones. De hecho, muchos argumentan que la solución al aprendizaje continuo es hacer que los agentes consuman mucho (por ejemplo, una base de código completa, slack, wikis de la empresa, etc.) y luego escriban sus aprendizajes en archivos MD, que luego se recuperan selectivamente según demanda. De hecho, los sistemas de archivos, los scripts bash y los archivos MD son y seguirán siendo importantes para los agentes. Sin embargo, a escala, cuando los agentes realicen la gran mayoría del trabajo de conocimiento, este enfoque ya no será eficaz.
Dadas las ventanas de contexto limitadas, la recuperación de todos los fragmentos de archivos MD que puedan ser relevantes y su inclusión en el contexto fallará en algún momento. Incluso si las ventanas de contexto continúan creciendo, existen beneficios de latencia al no poner toda la información en contexto y, en muchos casos, por ejemplo, cuando el trabajo de conocimiento implica interactuar con grandes bases de datos o bases de código, será inviable serializar todos los datos relevantes en contexto.
Los sistemas de datos como sustrato para enjambres de agentes múltiples
Se podría utilizar una representación de gráfico de conocimiento, pero los gráficos de conocimiento sufren las mismas limitaciones que la memoria no estructurada basada en MD debido a su falta de búsqueda estructurada. Lo que se necesita es poder recuperar sólo la memoria que sea pertinente para la tarea, a través de múltiples atributos (o facetas) de interés. Por ejemplo, un agente que depura una prueba inestable debería poder extraer solo los recuerdos etiquetados con el módulo, lenguaje, marco y modo de falla relevantes, en lugar de recuperarlos basándose en palabras clave o incrustando similitudes. Una cuestión aparte es qué recuperar realmente; Los rastros de agentes sin procesar con errores no son muy útiles ya que inducirán a los agentes a repetir el mismo error; en cambio, queremos que la memoria recuperada sea correctiva.
Recientemente exploramos una noción relacionada de memoria estructurada, donde organizamos la memoria en varios atributos, cada uno de los cuales podría establecerse como * para indicar aplicabilidad universal, o establecerse como una lista de valores que deben coincidir. Para un agente de datos, las dimensiones podrían incluir las columnas y tablas, el tipo de operación y, finalmente, instrucciones correctivas abiertas en lenguaje natural. Por lo tanto, podríamos incluir memoria que solo se aplique a un tipo determinado de operación (p. ej., "al realizar operaciones de fecha y hora, use el año fiscal en lugar de las convenciones de año calendario"), o una tabla determinada (p. ej., "se prefiere la columna producto_limpiado a la columna producto cuando se consulta el nombre del producto"). Una cuestión abierta es definir una memoria estructurada específica de una aplicación, o lo que otros han llamado modelos mundiales de memoria. Creemos que esto es similar a definir un esquema para cada aplicación, y tal vez los propios agentes puedan ayudarnos a definirlo y perfeccionarlo con el tiempo.
Una posible forma de almacenar y recuperar conocimiento estructurado [desde aquí]
La memoria estructurada también será útil para que los marcos evolutivos gestionen eficazmente los espacios de búsqueda. De hecho, almacenar, estructurar y extraer grandes volúmenes de trazas de agentes únicos y múltiples puede ayudar a que los agentes futuros sean mucho más eficientes, lo que potencialmente permitirá una superación personal recursiva eficaz a través de mecanismos estructurados basados en la memoria.
Otro desafío es admitir ediciones simultáneas en la memoria compartida y ediciones simultáneas en general, cuando hay muchos agentes realizando transformaciones. Si bien ha habido algunos intentos útiles de soportar la semántica de multiversión y copia en escritura, no está claro que tales técnicas sean suficientes cuando miles de agentes intentan editar el estado compartido al mismo tiempo. Por ejemplo, cuando los agentes intentan varias transacciones potenciales en respuesta a la solicitud de un usuario, es necesario revertir los efectos de la gran mayoría de estas transacciones, y solo persiste el resultado de la transacción "correcta". El trabajo para respaldar la semántica exactamente una vez es relevante aquí, al igual que las técnicas subyacentes basadas en CRDT y la transformación operativa. Para las actualizaciones de mecanismos difusos como la memoria, es posible que podamos sacrificar la coherencia por una corrección perfecta en aras de la latencia. Si bien los agentes pueden razonar sobre la semántica para compensar o revertir sus acciones para eventualmente finalizar la mayoría de las tareas, el principal desafío radica en el grado en que se pisan unos a otros durante el proceso. Un modo de fracaso importante que se debe evitar es una forma de “livelock”, donde las incesantes acciones compensatorias impiden cualquier progreso significativo.
Más allá del estado compartido, surgen otras preocupaciones cuando se intenta apoyar a un ejército de agentes, incluido qué hacer cuando los agentes fallan, cómo deben comunicarse los agentes entre sí (directamente o a través de un estado compartido intermedio) y cómo debemos tratar con los agentes rezagados. Ha habido algunos avances en el soporte de la ejecución duradera de múltiples agentes, como Temporal, pero aún está por ver si dichas soluciones se aplicarán a escala en miles de agentes. En el tema de la comunicación, necesitamos mecanismos que permitan a los agentes negociar entre sí. Imagine cuatro agentes desarrolladores que intentan llegar a un consenso sobre un esquema compartido, con objetivos distintos pero superpuestos. En un entorno humano, esto implicaría discusiones y compromisos iterativos; para los enjambres de agentes, debemos definir los mecanismos que les permitan converger en un diseño que refleje los objetivos subyacentes de sus respectivos directores. O si todos los agentes requieren acceso a un recurso limitado, nuevamente será necesaria la comunicación. Queda por ver si esto se logra mejor mediante una coordinación centralizada o si es necesario un enfoque descentralizado.
Sistemas de datos por agentes
Finalmente, si la inteligencia es efectivamente gratuita, entonces podremos emplearla para sintetizar nuevos sistemas de datos desde cero. De hecho, en muchos entornos, los sistemas de datos de propósito general pueden resultar excesivos, ya que deben admitir todos los esquemas, consultas y objetivos de hardware. Dada una carga de trabajo, trabajos recientes, incluidos Bespoke OLAP y GenDB, han demostrado que se puede utilizar una canalización agente para sintetizar un motor analítico completo y específico para una carga de trabajo, en cuestión de minutos a unas pocas horas, a un costo de unos pocos dólares. Los motores son desechables: cuando cambia la carga de trabajo, uno puede simplemente regenerarlos. De manera análoga, nuestro trabajo ha demostrado que se pueden sintetizar almacenes de valores-clave personalizados desde cero, dirigidos a la carga de trabajo. De hecho, los IDE modernos, como Kiro, elevan las especificaciones para el desarrollo de sistemas a un nivel ciudadano de primera clase.
Los agentes pueden sintetizar sistemas de datos personalizados desde cero
El problema principal, sin embargo, es que las especificaciones suelen ser imperfectas y no cubren todos los casos extremos. Los agentes actuales explotarán las especificaciones faltantes para recompensar su camino hacia una métrica de alto rendimiento. En nuestro trabajo de almacenamiento de valores-clave personalizado, descubrimos que una forma de aliviar esto es tener agentes de verificación auxiliares que intenten generar casos de prueba que detecten la explotación de los casos de esquina, esencialmente expandiendo la especificación. Otro enfoque más es generar juntos un sistema y una prueba de su corrección, para lo cual hemos encontrado algunos éxitos iniciales, pero es necesario hacer más para solidificar el enfoque. Además, queda por ver cuál es la mejor manera de solicitar especificaciones escritas por humanos para un sistema: ¿se puede hacer esto de manera iterativa y con el ser humano en el circuito, en lugar de hacerlo de una sola vez e incompleto? De hecho, las especificaciones escritas por humanos están incompletas incluso para el software creado manualmente, por lo que uno esperaría que los futuros agentes que estén más alineados ejerzan cada vez mejor juicio al tomar decisiones de diseño.
Un posible canal de síntesis de sistemas de datos [desde aquí]
Otras preguntas aquí implican probar si comenzar desde un sistema maduro (por ejemplo, Postgres) y eliminar componentes/funcionalidades puede generar un mayor rendimiento o una mayor confianza del usuario. Por otra parte, ¿existe la oportunidad de hacer que el diseño sea componible, comprendiendo varios componentes verificados que se combinen y combinen dada una carga de trabajo? Por ejemplo, quizás la carga de trabajo no haya cambiado lo suficiente como para actualizar la capa de almacenamiento, pero quizás el optimizador de consultas requiera cambios. Una propuesta quizás más viable implica emplear agentes junto con sistemas de prueba para apuntar a partes críticas del código asociadas con pruebas formales, en lugar de hacerlo para todo el sistema.
Una última oportunidad aquí es alejarse de la pila de sistemas de datos tradicionales con interfaces claramente definidas (por ejemplo, analizador, optimizador de consultas, administrador de almacenamiento, etc.), cada una de las cuales era en gran medida prerrogativa de un solo equipo humano para administrar. En cambio, los agentes pueden encontrar nuevas formas de “combinar” estos componentes y, como resultado, tal vez identificar nuevas oportunidades de optimización. Los agentes también pueden llenar los vacíos faltantes en la funcionalidad para hacer que los sistemas existentes tengan muchas más funciones, o alcanzar la paridad de funciones con otros sistemas de la competencia, o de manera análoga, refinar continuamente los sistemas de código abierto en respuesta a solicitudes o problemas de funciones (¡quizás presentados por otros agentes!). Hacerlo de una manera que priorice la corrección, el mantenimiento a largo plazo y la interpretabilidad humana será un desafío.
Mirando más allá
En la era de la inteligencia casi gratuita, los sistemas de datos importan más que nunca. A medida que los agentes asuman la mayor parte del trabajo de conocimiento, la carga de trabajo de los sistemas de datos cambiará, habrá que construir el sustrato sobre el que necesitan funcionar y, cada vez más, participarán ellos mismos en el diseño de los sistemas de datos. Cada uno de estos cambios abre una agenda de investigación nueva y apasionante.
Coevolución de sistemas y agentes de datos
Mirando más allá, es probable que los límites entre los agentes y los sistemas de datos comiencen a desdibujarse. Por ejemplo, los agentes pueden diseñar los sistemas de datos que ellos mismos ejecutan, definiendo tanto las interfaces como los componentes del sistema subyacentes. Tanto las interfaces como las partes internas pueden evolucionar con el tiempo por parte de los agentes en una forma de superación personal recursiva. También existe una oportunidad de repensar los sistemas de datos como una fuente holística de verdad para la totalidad del estado relevante: incluidos los datos sin procesar, la memoria y el estado de coordinación, borrando aún más las distinciones entre los datos que son consultados por los agentes y los datos generados como resultado de la actividad de los agentes. Finalmente, los propios sistemas de datos pueden incorporar componentes agentes, evolucionando fundamentalmente desde motores de computación pasivos hacia arquitecturas inteligentes, proactivas y autooptimizadas. Es difícil predecir lo que nos deparará el futuro. ¡Nos espera un viaje salvaje!
Expresiones de gratitud
La perspectiva y el trabajo en curso descritos en esta publicación son producto de una investigación conjunta y muchas discusiones con maravillosos colaboradores del EPIC Data Lab, el grupo Data Systems & Foundations y la comunidad más amplia de Berkeley AI-Systems. ¡Gracias a todos!
BibTex para esta publicación: