Unstructured data needs logical models that match the input requirements of each AI task and data type.
2
AI teams can reduce repeated computation by separating shared feature extraction from task-specific model layers.
3
Embeddings can support cost-effective AI systems when shared across tasks, especially as data grows from text to video.
Summary
Will Gaviria Rojas argues that AI systems need data designs built around unstructured content rather than storage formats created for traditional data. A JSON key-value record may be easy to store, but different AI tasks need different logical inputs. Sentiment analysis, language detection, summarization, and multimodal processing each require their own transformations. When data and AI teams do not share ownership of this boundary, both sides build workarounds and the pipeline becomes a bottleneck. Will also proposes treating foundation models as computation graphs. Much of the work is shared feature extraction, while individual tasks often change only the final layer. Reusing those extracted features can lower compute and latency and let one foundation model support more tasks. He closes by comparing the physical scale of numeric data, text, and video, arguing that systems built for unstructured visual data need data-centric designs that bring it into structured workflows.
Unstructured content has become the dominant data problem
Will says data has shifted from tables and rows toward rich text, images, audio, and video. He points to the expectation that 80% of worldwide data will be unstructured by 2025 and says generative AI will increase the amount of content organizations must understand. AI is the mechanism he sees for extracting value from this material, through tasks such as sentence analysis and object detection. The difficulty is making those AI operations work as a repeatable system instead of handling each use case as a one-off integration.
Organizations need AI-powered data systems instead of scattered workarounds
Will describes a common pattern in which organizations generate large amounts of unstructured data, archive it, label some of it by hand, or send it through separate AI APIs. Few companies do much more than archive this data, although adoption is increasing, especially for text. His proposed direction is to treat AI as a natural part of a data system that can run at scale. The lessons come from more than three years of user research and building systems for unstructured content.
A physical storage model might hold a comment in JSON as a key and a text value. AI models need more specific inputs. The required structure depends on both the data type, such as text, audio, image, or video, and the task, such as sentiment analysis or summarization. This creates many logical data models, with a mismatch between how data is stored and how it is consumed. Will says this boundary often has no clear owner, so data teams and AI teams build separate fixes that create a bottleneck.
Multimodal data needs an explicit logical representation
Will uses a social media post as an example of multimodal content. It may contain a comment, background audio, a video, and an image. A multimodal model may need to treat these components as related pieces of a logical entity rather than as one undifferentiated record. Teams can address the storage-to-consumption mismatch by designing logical models at scale. Will says data and AI teams working together can resolve the bottleneck and identify transformations that can be shared or optimized.
Shared transformations can reduce repeated GPU work
When data and AI teams inspect a pipeline together, they may find that the same image transformation is being performed repeatedly for different foundation model uses. A precomputed and pretransformed image can be consumed directly by the AI team instead. Will connects this change to more effective GPU use. The point is to make the transformation part of a shared logical data design rather than rebuilding it inside every individual AI workflow.
Foundation models should be split into reusable computation
Will says teams often begin with one foundation model for one task, then add more tasks until compute costs grow out of control. He suggests viewing a foundation model as a computation graph and separating the shared feature extractor from the task-specific output layer. In his description, most computation happens in the feature extractor, while tasks often change only the final layer. Reusing the extracted features across tasks can reduce latency and cost and make parallel foundation-model applications more practical.
The physical scale of data changes sharply across modalities
Will compares 10 million floating-point values, 10 million text documents, and video data. He estimates the numeric data at about 40 megabytes and the text at about 40 gigabytes, using lakes as a visual comparison. Video then moves into the terabyte range, which he compares with crossing the Pacific Ocean. His point is that systems must handle more than text. Visual data needs tools and designs that can support its much larger physical scale.
"We want to move towards a world where we're actually thinking about not just AI as a one-off thing, but AI as a natural system that can be done at scale."02:50
Who should watch
You are building AI features on top of text, image, audio, or video data and your storage format does not match the model inputs.
Your foundation-model costs are growing because several tasks repeat the same feature extraction work.
You work between data engineering and AI engineering and need a shared design for multimodal data pipelines.
