Tablas multimodelo: Una tabla para archivos, incrustaciones y búsqueda híbrida para agentes.

Durante años, la base de datos en cuestión ha ido evolucionando hacia un sistema unificado que abarca el procesamiento de transacciones distribuidas para cargas de trabajo críticas, HTAP, datos multimodelo y búsquedas híbridas. Su producto Lakebase marca un cambio adicional en la orientación de esta tecnología. La pregunta ya no es solo qué puede procesar la base de datos, sino a quién sirve. Antes, las bases de datos se diseñaban para desarrolladores, administradores de bases de datos y aplicaciones. El proveedor sostiene que, en la era de la IA, también deben atender a un nuevo tipo de usuario: el agente.

Según esa definición, una “base de datos de IA” no es simplemente aquella que puede almacenar imágenes, PDF o vectores. Es una base diseñada para proporcionar a los agentes un contexto completo, actual y fiable con el que razonar y actuar, donde los embeddings, los archivos en bruto y las búsquedas híbridas ofrecen respuestas desde el mismo lugar. El resto describe la función de tabla multimodelo en Lakebase y el problema que aborda. Estas son las afirmaciones del proveedor, así que pruébelas con su propio volumen de trabajo.

El problema de datos del agente

Imagínese una decisión de un agente. Es posible que necesite un perfil de usuario estructurado, un resumen de texto de la conversación, el PDF original de una base de conocimientos, resultados semánticos obtenidos mediante recuperación de vectores y el estado actual del negocio, todo al mismo tiempo.

Hoy en día, esos cinco elementos suelen residir en cinco sistemas: almacenamiento de objetos, un motor de búsqueda, una base de datos vectorial, una base de datos empresarial y un almacén offline. No existe transacción compartida, ni instantánea consistente, ni línea de ascendencia común.

Si un PDF se actualiza mientras su referencia sigue apuntando a la versión antigua, el agente responde con confianza pero erróneamente, y nadie se da cuenta. Esto no se trata de almacenar más tipos de datos, sino de un problema de gobernanza. Una vez que los datos multimodelo se encuentran en la ruta crítica, alguien debe garantizar la consistencia de las versiones, la integridad de los cálculos, la trazabilidad y la confiabilidad. En muchos equipos, esa persona es el responsable del pipeline, que él mismo revisa, depura y reescribe cada trimestre.

La tabla multimodelo es la solución de Lakebase. Es la función central de gestión de datos del producto y administra imágenes, audio, video, PDF, capturas de pantalla, vectores, JSON y columnas estructuradas como objetos de base de datos propios por derecho propio. Todos ellos se encuentran en un mismo sistema que ofrece transacciones, consistencia, alta disponibilidad, búsqueda híbrida, cálculos analíticos y servicio en línea.

Por qué los agentes necesitan un modelo de datos diferente

Los objetos con los que trabaja un agente son, por naturaleza, multimodelos. Las entradas van desde el lenguaje natural hasta imágenes, PDF, páginas web, tablas y contexto empresarial. Durante su funcionamiento, el agente se apoya en la memoria del usuario, bases de conocimiento, resultados de RAG, datos empresariales estructurados, perfiles semánticos y resultados de modelos intermedios.

Sigue una serie de cuatro cambios:

1. Los datos no estructurados pasan a formar parte del camino crítico. Dejan de ser archivos adjuntos almacenados en sistemas de almacenamiento de objetos para convertirse en información clave para la toma de decisiones.
2. El acceso se vuelve una búsqueda híbrida. Una sola solicitud puede combinar filtros estructurados, recuperación de texto completo, recuperación vectorial y agregación analítica.
3. Aumentan las demandas en tiempo real. Los agentes operan las 24 horas del día, y los informes diarios ya no son suficientes.
4. Las características se generan de forma dinámica. Muchos campos no se escriben directamente; los modelos los extraen de forma asíncrona de los datos brutos.

La pregunta práctica es cómo unificar datos multimodelo brutos, campos estructurados, características derivadas y resultados asíncronos en una sola base de datos, permitiendo que sirvan a transacciones en línea, análisis y búsquedas híbridas al mismo tiempo sin perder consistencia ni visibilidad. Ese es el problema de diseño al que está orientada la tabla multimodelo.

Capacidades principales

Un único lugar para objetos multimodelo

Las tablas multimodelo colocan estos objetos bajo el propio control de transacciones y versiones de la base de datos. Los objetos grandes como imágenes, audio, video, PDFs y capturas de la web pueden almacenarse de varias maneras diferentes. Donde se encuentran físicamente los bytes importa menos que lo que la base de datos promete sobre ellos: un ID que no cambia, un lugar para acceder a él, un número de versión, un estado de visibilidad y un alcance de transacción definido.

Esto tiene como objetivo garantizar que un objeto en bruto y sus características derivadas, como resúmenes, etiquetas, embeddings y puntuaciones de riesgo, siempre coincidan con la misma versión de los datos. El error en el que un objeto se actualiza pero sus características siguen describiendo el contenido antiguo no debería ocurrir.

Columnas de características dinámicas

Los datos multimodelo son muy ricos, y un único objeto en bruto puede generar una serie interminable de características: semánticas, estructurales, relacionadas con la calidad y específicas del negocio. Del texto se pueden obtener temas, resúmenes, representaciones vectoriales, etiquetas de seguridad, el idioma y una puntuación de calidad. De una imagen provienen resultados de OCR, etiquetas, puntuaciones de riesgo y atributos empresariales. Cada nuevo modelo añade más.

Bajo un esquema clásico, cada nueva característica implica un cambio en el DDL. Cada cambio en el DDL provoca la invalidación de la caché, la amplificación de escrituras y presión para realizar compactación en segundo plano, por lo que el ritmo de trabajo con características se ralentiza hasta alcanzar la velocidad de los bloqueos de tablas.

Las tablas multimodelo utilizan un mecanismo de columnas dinámicas ligero. Agregar una funcionalidad no requiere cambios en el esquema, las consultas permanecen en formato SQL nativo, sigue aplicándose la optimización analítica y la búsqueda híbrida sigue accediendo a un índice. Esto no representa un retroceso hacia el almacenamiento clave-valor, que aunque es flexible, carece de capacidad para el análisis SQL y la optimización de búsquedas. El diseño establece un equilibrio deliberado entre una estructura optimizable y una extensibilidad dinámica, intentando mantener ambas características.

Computación asíncrona, casi en tiempo real

Muchas columnas no son escritas por los usuarios en absoluto. Las tareas de cálculo las generan, incluyendo embeddings, resúmenes, OCR, puntuaciones de calidad, índices de texto completo e índices vectoriales, utilizando funciones integradas del modelo, tareas en segundo plano o pipelines externos.

La inferencia de modelos suele tardar cientos de milisegundos a segundos, lo cual es demasiado lento como para bloquear una escritura en línea. Por eso, la tabla no espera:

1. Se registran primero los datos en bruto, manteniendo intacta la latencia de escritura en tiempo real.
2. Las tareas en segundo plano inician la extracción de características, la creación de índices y el relleno de datos según su línea de origen.
3. Los valores derivados aparecen dentro de un período casi en tiempo real.
4. Las lecturas siempre muestran una captura consistente.

La razón detrás de esto es que una sincronización estricta de cada columna derivada es poco práctica e innecesaria. Un equilibrio controlable entre latencia, rendimiento, eficiencia de almacenamiento y consistencia es el objetivo adecuado. Las tareas de cálculo generan los valores, y la tabla los hace gestionables, buscables, analizables y legibles de manera consistente.

Consistencia de los grupos de columnas

El cómputo asíncrono plantea un problema de visibilidad. Una vez que existe una fila, la característica A, la característica B, las incrustaciones, los índices de texto completo y las etiquetas de calidad pueden finalizarse en momentos diferentes, generados por tareas y modelos distintos. Si una consulta ve que B está completo mientras A aún está en proceso, devolverá respuestas incorrectas sin ninguna advertencia.

La consistencia de los grupos de columnas aborda este problema en la capa de almacenamiento. Un grupo de columnas empresariales se convierte en una nueva instantánea visible solo después de que todas las columnas derivadas relacionadas hayan finalizado. Las consultas y la búsqueda híbrida leen una instantánea consistente y nunca se encuentran con datos incompletos.

Almacenamiento y cómputo separados, con datos activos e inactivos juntos

Los datos multimodelo crecen sin límite alguno en documentos, imágenes, video, vectores y características derivadas, por lo que mantener todo ello en memoria activa no es viable a gran escala. Estas tablas se basan en una arquitectura desagregada con almacenamiento compartido y tratan los datos activos y los inactivos como un continuo:

• Los datos recientes, por ejemplo los de los últimos 90 días, se almacenan en caché en SSD para que el acceso sea rápido.
• Los datos más antiguos, como los de más de 90 días, se almacenan en un almacenamiento compartido más económico, aunque siguen siendo consultables, buscables y analizables a través de la misma interfaz.

Nadie necesita cambiar de sistema para acceder a datos inactivos, ni combinar una base de datos en línea, almacenamiento de objetos y un almacén offline para responder a una sola pregunta. Existe una única vista, una única superficie de consulta y un único modelo de gobernanza.

Linaje y un catálogo unificado

¿De qué segmento de texto proviene esa incrustación? ¿Qué modelo de auditoría asignó esa etiqueta de seguridad? ¿Qué versión del PDF describe ese resumen?

El linaje y el catálogo unificado constituyen la base de los metadatos. Capturan cómo los objetos en bruto, los campos estructurados, las columnas de características dinámicas, las tareas del modelo, las versiones y los permisos se relacionan entre sí. Los metadatos sirven para tres cosas:

1. Desencadenamiento. Las tareas en segundo plano para la extracción, la creación de índices y el relleno se inician automáticamente a partir del linaje.
2. Completitud. Antes de que se permita la visualización, el sistema verifica que un grupo de columnas o una instantánea haya sido calculado por completo.
3. Rastreabilidad. Cuando un agente da una respuesta, se puede rastrear hasta los documentos, imágenes, registros y características derivadas que utilizó.

Una capa de acceso para transacciones, análisis y búsquedas

Una tabla multimodelo se describe como una base compartida para tres tipos de cargas de trabajo sobre los mismos datos:

• transacciones en línea, es decir, escrituras empresariales con garantías ACID y alta disponibilidad;
• análisis, es decir, búsquedas a gran escala, agregaciones, filtros, uniones y análisis de características;
• búsqueda híbrida, es decir, filtros estructurados combinados con recuperación de texto completo, recuperación vectorial, filtrado por etiquetas y clasificación empresarial.

El acceso de los agentes es, por naturaleza, de múltiples pasos. Una solicitud puede filtrar según condiciones estructuradas, luego buscar descripciones como texto completo, después buscar contenido similar mediante recuperación vectorial, y finalmente clasificar según etiquetas, calidad, recencia y permisos. Ningún motor especializado abarca los cuatro pasos.

El compromiso central radica entre una operación casi en tiempo real y una sincronización sólida. La búsqueda y el análisis no necesitan características derivadas para completarse dentro de la transacción de escritura, pero esas características deben hacerse visibles dentro de un período breve y definido, y deben leerse a partir de una instantánea consistente. Así es como una sola tabla puede servir para escrituras en línea, recuperación híbrida y análisis, sin el costo de mantener tres copias combinadas.

Qué reemplaza

En un proyecto de agentes actual, su ventaja radica en que reemplaza una combinación de almacenamiento de objetos, un motor de búsqueda, una base de datos vectorial, una base de datos empresarial y un almacén offline. El antiguo compromiso entre amplitud multimodal y gobernanza a nivel de base de datos está destinado a desaparecer.

Por qué es importante

La verdadera pregunta no es si una base de datos de IA puede almacenar imágenes, PDFs o vectores. Se trata de los cambios que ocurren cuando los agentes se convierten en usuarios de primer nivel de la base de datos.

Si la respuesta es un sistema aislado adicional por tipo de dato, hay más superficies que proteger, más pipelines que interrumpir y más desviaciones silenciosas. Si la respuesta es una única tabla regulada en la que cada modalidad es un objeto de primera clase, se obtiene una verdadera base de datos en lugar de una estructura compuesta únicamente por pipelines.

Las tablas multimodelo reúnen datos estructurados, datos no estructurados, características derivadas de la IA y semántica empresarial bajo un mismo sistema para transacciones, gobernanza y cálculos. Las bases de datos se utilizan para unificar datos. En la era de la IA, es necesario unificar datos, semántica y las operaciones que los generan, y esta función representa el primer paso de Lakebase en esa dirección.

Evaluándolo

Las tablas multimodelo se incluyen como parte de Lakebase. Para evaluarlas según la carga de trabajo de su agente, enumere los tipos de datos que debe gestionar, el escenario del agente que está creando y cualquier requisito de rendimiento o gobernanza, luego modele una tabla multimodelo y compárela con la solución que reemplazaría. La prueba decisiva es si el agente deja de entregar respuestas incorrectas.

Leer más

• ¿Ontología o capa semántica? Qué necesita un agente de IA de ambos: Cómo difieren las ontologías y las capas semánticas, qué falla cuando solo existe una, dónde encajan los grafos de conocimiento y un orden práctico para construir la capa de contexto.
• Preguntas reutilizables para agentes de IA que todo desarrollador debería guardar: Una biblioteca de preguntas clasificadas para revisión de código, pruebas, depuración, diseño, documentación, Git y aprendizaje, además de cinco hábitos que mejoran el funcionamiento de cualquier pregunta para un agente.