La 'lección humanoide': ¿le dejará la IA algo por hacer a la investigación en bases de datos?

El artículo es una reseña crítica, publicada en el blog de A. Jesse Jiryu Davis, de un paper académico de investigadores de Berkeley y Stanford titulado 'What Happens When the Model Eats the Stack? Rethinking the Research Agenda for Data Agents to Withstand the Bitter Lesson'. La tesis de fondo que discute es incómoda para cualquier campo de investigación aplicada: si los modelos fundacionales siguen mejorando según la 'Bitter Lesson' (la idea, ya clásica en IA, de que los métodos generales que aprovechan más cómputo terminan superando a cualquier técnica artesanal diseñada para compensar debilidades puntuales de los modelos), ¿qué le queda por hacer a un investigador de bases de datos que no trabaje en OpenAI, Anthropic o NVIDIA?

El autor recuerda que ya hemos visto este patrón repetirse: cada vez que la comunidad diseña un 'harness' (un andamiaje de herramientas, prompts o procesos) para paliar una limitación de los LLM, la siguiente generación de modelos vuelve innecesario ese andamiaje. Incluso se han creado meta-harnesses para automatizar el propio diseño de harnesses, y aun así el patrón se repite: nunca se contradice la Bitter Lesson, simplemente se la vuelve a aprender.

El paper reseñado responde a esa pregunta con un 'sí': propone una agenda de investigación para adaptar los sistemas de datos al uso por parte de agentes de IA. Pero el autor se muestra escéptico y lo describe abiertamente como una especie de 'cope' (una forma de autoconsuelo ante una realidad incómoda). Su duda de fondo es que la IA no dejará ningún software 'en el plato': los problemas que sobreviven son, según él, los mismos que la humanidad arrastra desde el inicio de la era de la información, porque las IA y los humanos comparten una dificultad similar para acceder al conocimiento tácito o 'tribal' de las organizaciones.

El texto conecta este paper con uno anterior, de dos de los mismos autores, titulado 'Supporting Our AI Overlords: Redesigning Data Systems to be Agent-First', que predecía que los agentes de IA inundarían las bases de datos con consultas especulativas y poco optimizadas, y que por tanto los sistemas de datos deberían rediseñarse para absorber ese patrón de carga. El nuevo paper matiza esa predicción: sostiene que los modelos más recientes de agentes de codificación están reduciendo drásticamente el número medio de turnos y tokens necesarios por consulta, lo que cuestionaría la premisa de que los sistemas de datos futuros estarán limitados por la especulación agencial a gran escala e ineficiente. Los autores afirman que los modelos nuevos mejoran de forma nativa la eficiencia en una tarea dada, resolviendo cada una con menos acciones y fallos, generación tras generación.

El reseñista concede que es razonable que los modelos nuevos 'fallen menos', pero señala una inconsistencia: el paper de los 'Overlords' también advertía sobre la heterogeneidad de las consultas de los agentes, y a su juicio no hay evidencia nueva de que esa heterogeneidad deje de ser un problema para bases de datos diseñadas tradicionalmente para cargas OLTP repetitivas. También apunta, de pasada, que el estudio mide eficiencia y precisión solo sobre modelos GPT (citando específicamente resultados con 'GPT-5.6 Sol' en el Data Agent Benchmark) sin incluir modelos de la familia Claude, algo que le extraña.

Un hallazgo del paper que el autor sí valora es el cambio en la naturaleza de los errores a medida que los modelos mejoran: los fallos por uso incorrecto de herramientas o errores de ejecución disminuyen, pero los errores restantes pasan a estar dominados por fallos de conocimiento del entorno. Según cita textualmente, más del 60% de los fallos de los modelos más avanzados provienen de una mala interpretación semántica: no entender el significado real de la tarea, apoyarse en proxies inválidos, usar las fuentes, tablas, campos o métricas equivocadas, o manejar mal entidades, claves de unión e identificadores.

A partir de ahí, los autores del paper proponen que la comunidad investigadora debería estudiar cómo dotar a las IA de 'contexto semántico persistente': conocimiento curado sobre qué datos existen, qué significan y qué fuentes son autoritativas. Ponen como ejemplo una tarea típica de negocio: redactar una revisión trimestral que explique por qué los ingresos europeos no alcanzaron la previsión, reconciliar la discrepancia con las cifras oficiales del departamento de Finanzas y recomendar acciones correctivas, una tarea que exige identificar conjuntos de datos autoritativos repartidos en varios sistemas, resolver definiciones de métricas en conflicto, entender convenciones de negocio propias de la organización, interpretar documentación semiestructurada y validar resultados intermedios.

El autor del blog acepta el diagnóstico, pero rechaza que sea un problema nuevo: sostiene que llevamos décadas hablando de exactamente este tipo de 'contexto semántico persistente' bajo el nombre de conocimiento tribal. Cualquier profesional competente que se incorpora a una empresa, o cambia de equipo, tropieza con la misma dificultad para encontrar información no documentada formalmente. Para él, la IA no cambia nada sustancial en este punto.

Es aquí donde propone su propia idea, a modo de contrapunto irónico a la Bitter Lesson: la 'Lección Humanoide' (Humanoid Lesson). Su formulación es que, para adivinar las fortalezas y debilidades de un LLM, una buena primera aproximación es antropomorfizarlo: las IA tienen los mismos problemas que las personas. Si se deja caer a una persona brillante en una gran corporación, pasará la mayor parte de su tiempo descubriendo el conocimiento informal de la organización, especialmente si además —como ocurre con un LLM— sufre una suerte de amnesia total cada pocos minutos. Y del mismo modo que esa persona brillante rinde mejor si se le da libertad en lugar de imponerle un proceso rígido, sugiere que ocurre algo parecido con los modelos.

El autor critica que el paper plantee, como si fuera una pregunta inédita propia de la era de la IA, quién debe enterarse de una actualización de conocimiento, cómo debe propagarse a través de ámbitos solapados y cuándo deben reconciliarse o convivir visiones semánticas en conflicto. Su respuesta es que esa pregunta es idéntica para humanos que para máquinas, y que las pocas cuestiones realmente interesantes del paper seguirían siendo interesantes aunque los LLM no existieran.

En la sección que titula 'Just Use Git' (simplemente usa Git), el autor lleva su argumento a un terreno muy concreto, apoyándose en su propia experiencia. Cuenta que en los primeros tiempos de MongoDB la documentación vivía en una wiki separada del código, y ambos se desincronizaban constantemente, lo que generaba preguntas interesantes —pero evitables— sobre consistencia. La solución no fue una técnica novedosa, sino un cambio de proceso: empezaron a mantener las guías de arquitectura en el propio repositorio Git, modificándolas en el mismo commit que el código que describen, y desarrollaron un proceso en su gestor de tickets y en las revisiones de código para verificar qué documentación se veía afectada por cada cambio. Su conclusión es que la única diferencia real entre humanos y LLM en este terreno es que los humanos son perezosos y los LLM son 'maníacos'.

Sobre si el contexto desactualizado debe corregirse de inmediato o bajo demanda —otra pregunta que el paper deja abierta como problema de investigación—, el autor la considera igualmente sobreanalizada: da por hecho que la documentación se lee mucho más de lo que se escribe, así que casi siempre compensa actualizarla de forma inmediata; si un fragmento de conocimiento tribal nunca se consulta, lo sensato es borrarlo o averiguar por qué nadie lo encuentra, no diseñar un sistema de consistencia sofisticado para gestionarlo.

El cierre del artículo amplía el marco a una discusión de actualidad en los mercados: la pregunta de si una tecnología determinada es un complemento o un sustituto de los LLM. El autor recuerda que en febrero los inversores decidieron que Claude era un sustituto de todo el software, porque podía construir cualquier aplicación bajo demanda, lo que llevó a una venta masiva de acciones de empresas SaaS (episodio que él llama la 'SaaSpocalypse'). Después, esos mismos inversores decidieron que algunas empresas SaaS eran en realidad complementos de la IA, y sus acciones se recuperaron; desde entonces, dice, el mercado sigue oscilando entre ambas lecturas.

Traslada esa misma incertidumbre a la investigación en sistemas de datos: si se inventa alguna técnica que hace funcionar mejor hoy a un modelo (menciona a Claude Fable), cabe preguntarse si esa mejora se acumulará también en la siguiente generación de modelos, o si el propio modelo terminará absorbiendo esa capacidad y volviendo obsoleta la técnica. El paper reseñado apuesta por la primera opción, sugiriendo que la pila tecnológica actual está casi obsoleta pero que una nueva pila proporcionará valor duradero; el autor se declara escéptico y plantea como igual de probable que las IA futuras terminen superando cualquier sistema existente escribiendo software nuevo desde cero para cada aplicación concreta. Cierra reconociendo, sin resolverlo, que esa sería una lección tan amarga como la original, y que no sabe cómo la comunidad —lectores incluidos— va a lidiar con ella.