Model Lakes

Abstract.

Given a set of deep learning models, it can be hard to find models appropriate to a task, understand the models, and characterize how models are different one from another. Currently, practitioners rely on manually-written documentation to understand and choose models. However, not all models have complete and reliable documentation. As the number of machine learning models increases, this issue of finding, differentiating, and understanding models is becoming more crucial. Inspired from research on data lakes, we introduce and define the concept of model lakes. We discuss fundamental research challenges in the management of large models. And we discuss what principled data management techniques can be brought to bear on the study of large model management.

1. Introduction

With the rise of AI Chatbots (ChatGPT (OpenAI, [n.d.]a), BARD (Google, [n.d.]a), etc.) and other AI-integrated apps (AI, [n.d.]a; Microsoft, [n.d.]; AI, [n.d.]b; Labs, [n.d.]b; Google, [n.d.]b; Chintagunta et al., 2021; Trummer, 2022) many organizations commit significant resources to develo** Machine Learning Models, most of which are fine-tuned versions of popular models such as BERT (Devlin et al., 2019), BART (Lewis et al., 2020), GPT-3 (Brown et al., 2020), LLAMA-2 (Touvron et al., 2023), and more. Recently, OpenAI created a mechanism (OpenAI, [n.d.]b) to allow users to create custom version of ChatGPT. To support this proliferation, sharing, and reuse (finetuning and editing) of large models, many models are hosted on platforms to support the collaborative use and sharing of models such as HuggingFace (Face, 2023) and Kaggle (Kaggle, 2023).

In the data management community, we have done a lot of introspection about how machine learning and Large Language models will revolutionize data management (Halevy et al., 2023; Fernandez et al., 2023). It is true that for many important (and stubbornly hard) semantic data management problems such as data discovery and data wrangling, advanced machine learning models are out performing other approaches (Fan et al., 2023b, a; Dong et al., 2023; Li et al., 2020; Narayan et al., 2022). Exciting research challenges remain in applying these models in data management and some point out the lack of exploration of models beyond LLMs (Borisov et al., 2022). However, we do not believe this makes machine learning an existential threat to data management or a challenge to the the raison d’être of data management  (Fernandez et al., 2023). Rather, we argue that the large model revolution poses some new and fascinating scientific challenges that data management researchers are, perhaps, uniquely qualified to tackle. In this vision paper, we pose the question of how can principled data management revolutionize the use and management of models, including important problems like model selection (see  Example 1) and model provenance. While model management (Bernstein et al., 2000) has long been a core topic in data management, we have been slow to move beyond the management of schemas and map**s (Doan et al., 2012) to the management of large machine learning models. Today, the way in which we search for models is through 20th century keyword search over (usually manually specified) names or metadata. The way in which we understand the relationship between two models is quite primitive (for example, is one manually declared to be a fine-tuned version of another). And the study of model provenance or lineage is just emerging (Mei et al., 2022; Mu et al., 2023).

We draw on lessons learned from collaborative data sharing platforms, such as Data Hub (Bhardwaj et al., 2015), that led to the development of data lakes (Nargesian et al., 2019) as powerful repositories for the management of heterogeneous collections of data. We introduce model lakes, as a parallel to data lakes, and discuss how important innovations in data lakes, including data discovery, annotation, and version management, can (and should) be applied within model lakes and studied with the same vigor.

Example 1 ().

Model Selection Problem: Consider a situation where a user wants to find a model that can summarize a legal document and simplify it in a non-technical manner. On HuggingFace (as of Jan 2024), the user finds that there are around 489,000 models uploaded and around 1500 of them have the ‘summarization’ task tag. While there are filters (trending, most likes, most downloads, model name search, and more), the user finds it hard to choose which model they should actually use. There are various concerns that the user goes through as she scrolls through different model cards (a common semi-structured form of model documentation). Is this model aware of legal jargon? Is it good at summarizing and simplifying legal documents? Is this the latest version of the model? Was this model trained on legal texts and if so which texts? What are other models that are similar to this model? Are they also trained on the same or different legal texts?

2. Models

Consider a model, $M$, which is trained with dataset, $D$. This model has an algorithm (function), $A$, where $A:X\rightarrow Y$. Based on the training objective provided by $A$, $M$ can be discriminative or generative in nature. In the case of discriminative models, $M$ would learn to differentiate and classify different kinds of data instances. In the generative case, $M$ can be a sampling process that produces a distribution of new data instances. For instance, text-conditional diffusion models (Saharia et al., 2022; Ramesh et al., 2022; Rombach et al., 2022) take a text input, $X$ and produce an output $Y$ that contain pixel values that form an image that matches the text description. For large language models (Touvron et al., 2023; Zheng et al., 2023; Brown et al., 2020), the output $Y$ can be generated text (which may be in the format of tabular or semi-structured data), that the model creates in response to an input prompt $X$. In general, training data $D$ can be of various types or combinations — it can be text documents, images, audio files, etc., that may be labeled or unlabeled. The full algorithm $A$ would include both $M$’s architecture and a pipeline for training and testing it. $M$ could be a parameterized model with any architecture, such as a Convolutional Neural Network (Cun et al., 1990) or a Transformer (Vaswani et al., 2017) or a simpler model. Note that unlike others (Fernandez et al., 2023), in our work, we consider not just LLMs, but also the worker-bee models that may be discriminative or generative, and that have been driving data science innovation since before the ChatGPT era. Moreover, recent findings from a survey on deep learning and tabular data (Borisov et al., 2022) underscore the necessity of investigating novel architectures for adoption, including diffusion or hybrid classical machine learning and deep learning models. They stress this is particularly important for handling heterogeneous collections of tabular data with better predictive performance and computational complexity. By develo** and advancing a semantic model management system, the exploration of these models can be conducted in a more informed and efficient manner.

3. State-of-the-art in Model Management

Model Repositories and Model Registries. The proliferation of models has lead to the emergence of model repositories such as Civitai (Inc., 2023), HuggingFace (Face, 2023), or Kaggle (Kaggle, 2023) that openly share models. Companies, such as AWS also provide model repository products (such as the Amazon Elastic Container Registry) that can be used to share models within an organization. These platforms let users search for models by browsing through catalogs or by doing keyword search over manually created model names (and sometimes metadata). Beyond the hosting and sharing of models, a model registry provides clear naming conventions (for models and versions) and standardized, structured metadata (examples include Neptune (Labs, [n.d.]a) and AWS’ Sagemaker Model Registry (Verma et al., 2022)) and is more of a comprehensive system that enables documentation of the entire lifespan of machine learning models.

Documenting Models. Models that are deployed are usually accompanied with documentation known as model cards (Mitchell et al., 2019). This report generally contains the following categories of information.

1. Model Details: Information about the model such as model date, version, type, training algorithms used and other resources to learn more about the model.

2. Intended Use: Use cases that were imagined while develo** the model and related primary users.

3. Factors: Summary of model performance across relevant features (like gender in people-centric models), instrumentation (like recording instrument for audio-based models), and environment (like image lighting for image-based models).

4. Metrics: Details of model performance measures, decision thresholds, and approaches to uncertainty and variability.

5. Evaluation Data: Information on dataset(s) used for quantitative analyses, the motivation behind choosing the dataset(s) and related preprocessing methods.

6. Training Data: Similar to information present for evaluation data section, but on data used to train the models.

7. Quantitative Analyses: Results of evaluating a model based on the metrics, which may be broken-down based on factors mentioned earlier. This includes unitary, i.e., model performance with respect to each factor, and intersectional results, i.e., model performance with respect to the intersection of factors.

8. Ethical Considerations: Information on ethical concerns such as model usage of sensitive data, intention of using the model for human life-related decisions, potential ethical risks and harms.

9. Caveats and Recommendations: Details of concerns or suggestions for using the model that are not covered elsewhere.

Similar to datasheets (Gebru et al., 2021), model cards are designed to guide developers in documenting models in a structured way. Model cards can be and should be augmented with information more similar to nutritional labels (Stoyanovich and Howe, 2019) that also include information about fairness and bias in the data (models). They can be further enriched with lineage and security related documentation such as adversarial attack and related defense measure policies, which are outlined in FactSheets for AI services (Arnold et al., 2019).

Model Search and Discovery. In  Example 1, we showcase a potential scenario for the Model Selection Problem. The current solution pipeline involves a user searching for a relevant model by naming specific models or by ty** related keyworks like legal to find models that either have that word in their name or in their model card. In other words, the search relies on the model’s name and documentation. Hence, any sorting of the answer by relevance is just the relevance (prevalence) of the keywords and is not a semantic notion. Of course, this search may fail if the documentation is incomplete or inaccurate. The state-of-the-art in verifying the documentation of a model is also in its infancy.

Interpretability. Interpretability has been defined as the extraction of relevant knowledge from a model concerning relationships either contained in data or learned by a model (Murdoch et al., 2019). Interpretability is critical for model analytics to enable semantic analysis and understanding of models and their training data. Several works have surveyed techniques and research questions in this area (Singh et al., 2024; Luo and Specia, 2024; Zhao et al., 2024; Räuker et al., 2022; Doshi-Velez and Kim, 2017; Gilpin et al., 2018), which can be broadly categorized into the following areas: Local model explanations explain the sensitivity of individual output predictions to local changes in inputs using gradients (Sundararajan et al., 2017), masks (Petsiuk et al., 2018; Fong et al., 2019), local models (Ribeiro et al., 2016), or Shapley values (Lundberg and Lee, 2017; Chen et al., 2023). Global explanations explain the mechanisms of the overall model at the level of attention patterns (Clark et al., 2019), representations (Belinkov, 2022; Zou et al., 2023), circuits (Elhage et al., 2021; Wang et al., 2022), or neurons (Bau et al., 2018, 2017; Geva et al., 2023). Models can be designed to be inherently interpretable (Rudin et al., 2022). Lastly, datasets can be explained using natural language explanations (Narayan et al., 2022), data visualizations (Dibia, 2023), or by training inherently interpretable models (Ustun and Rudin, 2016; Singh et al., 2023) of the data set.

Provenance. A new and important line of inquiry considers questions related to provenance (Mei et al., 2022; Mu et al., 2023). These issues pose similar questions to those studied in the database community (Buneman and Tan, 2018): from where did a generated fact derive or why was a predication made? A subset of these questions are also posed in model interpretability as part of local and global explanations. As in data provenance, the main issue is in whittling down all the provenance associated with some process (such as a model) into simple, but useful explanations (Buneman and Tan, 2018). More than two decades of research in the data management community have produced elegant and simple, yet powerful, models for data provenance when the process is a query (Buneman et al., 2008, 2016) or workflow (Moreau et al., 2013; Moreau and Groth, 2013). In large model provenance, the goal cannot be to understand and track all inputs (data, hyperparameters, code, training regimes, …) that were used to create a specific model output. Rather research is needed on finding meaningful sets of concepts that can be tracked efficiently and which provide important insights into model behavior.

There has been some initial research on solving the model provenance. Mu et al (Mu et al., 2023), for instance, uses a data-driven and model-driven representation learning method to encode ‘Model DNA’, which the authors then use as part of a framework for model provenance identification. Their goal is identify whether a model is a pre-trained model of another model. The former model is known as the source model while the latter model is known as the target model. This technique assumes a relaxed condition where the source and target model have the same architecture or structure and the target model’s training is based entirely on the source model. Furthermore, it assumes that we can access training data of the source model. However, there are harder conditions that can exist where the target model is trained based on a subset of the parameters of the source model or when the architecture of the target model is different from that of the source model. We define the granularity of such model conditions in  Section 5 and explore various ways a model can be different from one another.

Model Versions. Models are valuable assets that are reused in numerous ways to create new versions. Based on the training type, the function or algorithm, $A$ can vary. For instance, if a model $M$ is pre-trained, $A$ would include a pipeline were it would encourage $M$ to learn general features from dataset $D$. However, if $M$ is fine-tuned, $M$ would start off with weights from a previously trained model and learn features from $D$ to understand a specific task better. While pre-training and fine-tuning are some of the most common training objectives for creating new versions of a model, there are newer, more surgical-like training objectives such as model editing (Sinitsin et al., 2020; Meng et al., 2022) where $A$ focuses on updating certain facts (for instance, updating the name of the current President of a country) learned by a model in a more localized fashion. With various options for training methods, architecture, and dataset combinations, enormous numbers of models have been created with varying degrees of similarities and differences amongst each other.

Among the versioning methods, we examine fine-tuning and editing in more detail. Fine-tuning is the process of further training the parameters of an existing model to improve its performance, usually on specific task(s) or domain(s). For instance, T5 (Raffel et al., 2020) is a pre-trained model that has been trained on a collection of large collection of text (about 750 GB) to perform well on a diverse set of tasks. This has been further fine-tuned with the MIMIC-III (Johnson et al., 2016) and IV (Johnson et al., 2023) dataset to form Clinical-T5 (Lu et al., 2022) to perform better for medical domain-related tasks. Another model instance is FLAN-T5 (Chung et al., 2022) that has been fine-tuned on data with 1.8K tasks phrased as instruction so that it can handle such prompts better. Apart from datasets and training goals, there are also various optimizations schemes that could differentiate various fine-tuned models. For instance,  Hu et al. (2022) experimented with a GPT-2 model fine-tuned with Adam (Kingma and Ba, 2015) and another GPT-2 model instance fine-tuned with their Low Rank Adaption (LoRA) (Hu et al., 2022). They both have the same task goals and are fine-tuned from the same source model, but have a difference in performance due to the fine-tuning optimization conducted. Consequently, with different datasets, training goals and algorithms, various versions of a pre-trained model can be created. Because they have the same source model, the fine-tuned models can also be considered to be related to each other.

Direct model Editing. Large language models (LLMs) contain a wealth of knowledge encoded in their parameters. As a result, they can respond to natural-language queries such as those that relate to factual statements. However, LLMs can sometimes hallucinate or point to outdated information. Hence, there have been several studies that look into localizing and understanding the internal mechanisms within LLMs. Zhu et al. (2020), for instance, proposed the task of modifying factual knowledge in transformer models such as BERT (Devlin et al., 2019) by performing a constrained fine-tuning on the original model with specific facts. De Cao et al. (2021), on the other hand, introduced Knowledge Editor, that uses hyper-networks (Ha et al., 2017) to tune the model’s parameters for editing specific knowledge. In terms of finding these facts,  Dai et al. (2022) proposed the idea of knowledge neurons, whose activation highly correlated with their related knowledge expression. MEND (Mitchell et al., 2022) also edits local knowledge, but it does so by training a collection of Multi-Layer Perceptrons (MLP) to modify model gradients that would result in the production of local model edits. In contrast, ROME (Meng et al., 2022) uses rank one modification of the MLP weights of a single layer to directly edit appropriate weights that would change the fact associated to an information present the transformer model. MEMIT (Meng et al., 2023) builds upon ROME to be able to edit multiple knowledge expressions in the model. Direct model editing can also be applied to multimodal models: the TIME (Orgad et al., 2023) and UCE (Gandikota et al., 2024) methods edit text-to-image diffusion models. All these methods showcase various ways to edit a model, and hence, can be useful to understand how a current model is changed from its base model when a fact is changed.

4. Model Lakes: Vision

Given this state-of-the-art, we now outline our vision for model lakes: powerful repositories for the management of heterogeneous models. We enumerate challenges that require new scientific solutions and provide evidence that these challenges can be met.

Content-based Model Search. In analogy with dataset search, Google provides a comparable service to model registries, but for datasets (Benjelloun et al., 2020; Alrashed et al., 2021). They require dataset owners to follow their naming conventions and use metadata from Schema.org. Note this type of search only works well when there are clear incentives for artifact owners to provide complete and compliant metadata. Google provides this by returning datasets that comply with its best practices, though even Google struggles with impostors who game the system (Alrashed et al., 2021) by giving invalid semantic annotations. Current model repositories, such as Hugging Face, have found that they are subject to model designers who give sparse or ambiguous metadata within their model names or model cards (Liang et al., 2024). There is a danger that people could intentionally misinform with malicious intent (Security, [n.d.]b).

Within open data and enterprise data, researchers have learned that they cannot rely on metadata for datasets to be accurate, complete, or consistent within a data lake (Nargesian et al., 2019). As a result, there is a great deal of work on content-based search in data lakes including join search (Zhu et al., 2016, 2019; Khatiwada et al., 2022), union search (Nargesian et al., 2018; Khatiwada et al., 2023; Fan et al., 2023b), and related dataset search (Fernandez et al., 2018; Chapman et al., 2020). As mentioned in the introduction, machine learning models have revolutionized content-based dataset search. Important and impactful work has shown how we can use machine learning to create meaningful semantic representations of tuples, columns, and full tables to enhance dataset search and other semantic tasks like data integration and alignment.

But what about content-based model search? There is a bit of “physician, heal thyself” here. To the best of our knowledge, this is an area in its infancy. Lu et al. (2023) are the first to introduce the task of content-based model search, ”which aims to find the most relevant deep image generative models that satisfy a user’s input query”. Their solution builds a representation of the output distribution of a generative image model and uses this to find models that are most relevant to an input image or to an input model (or more precisely to its distribution). The trend of using meta-learning (and creating a hyper-network) for this task continues in other methods, such as AutoMRM, which is a model retrieval method based on multi-modal query and meta-learning (Li et al., 2023). A current limitation of these methods are that they are only able to perform retrieval for models that generate images. HuggingGPT (Shen et al., 2024) overcomes this limitation by using an LLM (in their case, ChatGPT) as a controller to decide which models to use based on a user’s prompt. This, however, is a metadata-based search and not a content based one, since the LLM would parse the user’s prompt into solvable tasks and then utilize another input of model descriptions (metadata) to decide which models would be relevant for each task. This approach allows queries and solutions in any modality or in any domain. However, it is limited by the capabilities of the LLM employed and the quality and accuracy of the model documentation. Furthermore, unlike content-based search, metadata-based ones would primarily fail when object-centric tags do not describe the model fully. As part of our vision, it is crucial that the content-based model search methods cover all types of models in the model lakes, including large language models. Additionally, ensuring their commercial usability, driven mainly by speed and accuracy, is essential. A hybrid approach combining metadata and content-based search could be effective, especially when exhaustive and verified metadata is accessible.

Related Model Search. Another important problem is related model search. A model is considered similar or related to another if they have some degree of commonality in one or more combinations of the following categories: datasets, training algorithms, behavior, or purpose. One approach to addressing related-model search was explored by Lu et al. (2023), which searches for image generative models by using the behavior of another image model as a query. We propose extending such model-query searches to all models in a model lake to help users identify related models when exploring the model in question. This can then be used as an informative analytics visualization as shown in  Figure 1.

Documentation Verification and Auditing. It is crucial to be able to verify that manually created documentation is correct and complete. When documentation is missing or incomplete, can we learn it? This is similar to discovering and annotating metadata in data lakes (Sawadogo and Darmont, 2021; Zhao et al., 2021; Korini and Bizer, 2023; Fan et al., 2023a). If there is a documentation, the goal would be to verify them and add any information that was left out. Currently, Mithril AICert (Security, [n.d.]a), for instance, runs an initiative to provide certification to indicate that a model is trained with the specified algorithm and with the specified training dataset. However, there are a couple of caveats. First, this initiative is still under development and hence, cannot be used for production at the time of writing. Second, this mechanism is dependent on creators signing up to gain such certification. Furthermore, based on the limitations provided on AICert (Security, [n.d.]c) website, the training code and data itself cannot be audited for threats such as “backdoors injected into a model by the code or poisonous data.” Lastly, it also states that AICert also needs to be inspected since we are currently trusting that it is running at a safe server and does not have a malignant app from which users have to run their code on the training data. Hence, there are a couple of broad research questions to explore within the document-centric verification realm – What information do we need for a model to be reproducible? If the information is provided, how can we verify the information without being compromised in the process? If the information is not provided, how can we gather the necessary information from the models themselves? How can we automate this process? While develo** models, there are systems like MISTIQUE (Vartak et al., 2018), that allows developers to perform model diagnosis, i.e., the process of examining machine learning model performance, and aiming to understand where the model excels and where it falls short. MISTIQUE can do so by capturing and storing the model intermediates, which are generally data artifacts that relate to the model including input data, prediction values, and data representations produced by model. These intermediate values can then be queried by the developers to diagnose the model to understand its performance. However, such frameworks are limited to white-box models, which are models where users can have full access including access to weights, activation, and gradients. However, we also need to consider documentation verification for other variations of model access such as black-box access, where users can only see the model’s output for their queries. Currently, there is no rigorous scheme present, especially for AI auditing (Casper et al., 2024).

Data Citation. Data Citation helps stakeholders identify the source, ownership, and authorship of the data used for a particular analysis. It is important to use proper data citation because the structure and contents of database can evolve (Buneman et al., 2016). Hence, this problem is also extended to machine learning research, since a big part of model training is its dataset. Based on a study conducted on 13K model cards (Liang et al., 2024), researchers found that if a training section of the model card is filled out, they generally include the name of the dataset, volume and characteristics of the dataset. This is not sufficient since the exact version of the dataset is usually not specified and the download links to the datasets may become stale. Furthermore, without any standardization and automated process on how to reference these datasets, many model cards might not contain such information or could feature varied statements regarding their referencing, as exemplified in the case shared by (Buneman et al., 2016).

In addition to citing datasets used during the model’s training and evaluation stages, we also need to consider how to manage data generated by these models. It is important to do so because users can use the generated information to train another model. One of the solutions for at least recognizing a generated data output is use watermarks (Kirchenbauer et al., 2023). Another scenario is when data is generated by a model and is being used by a consumer. It is important to know the model’s version and input prompts to the model to improve the chances of recreating this dataset. Hence, there is a need to advance data citation research for models to build an ecosystem where crucial information about related databases are recorded in both data and model lakes.

Provenance. A general research question for model provenance can be as follows: Given a potential source model, $M_{S}$, and a single target model, $M_{T}$, is $M_{S}$ the source model of $M_{T}$? If so, how is $M_{S}$ transformed into $M_{T}$? These transformations could be related to dataset being updated, training algorithms being changed, and/or changes in requirements of the model indicated by the developer as described by  Mei et al. (2022). Inspired from data provenance, we can also explore where-, how- and why-provenance with respect to models. To get a comprehensive understanding of model provenance, it is important to know what data was used to train it. Using data citation helps us collect this information effectively. There are, however, alternative methods (Liu et al., 2023) that rely on intermediate model training checkpoints and not training data to at least verify model ownership. In terms of exploring why-provenance, we can try to extract datasets used or changed with the source and target models. For instance, there are a range of facts that can be edited using model editing techniques. A 1-fact edited model would mean that there was one fact used whose association is different from its source model. For instance, if ROME algorithm (Meng et al., 2022) was used to change the location of the Eiffel Tower from Paris to Rome, we intend to edit one sentence representation from “Eiffel Tower is located in Paris” to “Eiffel Tower is located in Rome”. Hence, the resulting model would be a 1-fact edited model of its source model. The first comparison that can be made within this sub-area, i.e., can we determine whether one model is 1-fact edited model of another. A general approach to understanding such models would be to reverse engineer the model’s prediction of outputs, which can lead to circuit discovery (Wang et al., 2022; Conmy et al., 2023; Elhage et al., 2021) or even understanding how to unlearn knowledge learned in models (Jang et al., 2023; Eldan and Russinovich, 2023; Gandikota et al., 2023; Belrose et al., 2023; Kumari et al., 2023). We can extend the idea of such reverse engineering techniques to understand the process of 1-fact editing algorithms such as ROME on such models. Once such an ”edit or change” detector can be created, we could modify and extend its application. From model editing, we can then move on to model partial-tuning where a subset of the models’ parameters are used for training. We can look into the changed values for those parameters and understand what changed between its source and its current form. After building detectors for such cases, we can extend them further to understand the difference between one model that was fine-tuned from another model. Within fine-tuning, there are special cases of one-shot and few-shot training. Understanding these cases could help us build better detectors for the completely fine-tuned models where all model parameter values are usually changed. By creating such detectors, we can explain the transformation between a source and a target model, which is required for an exhaustive understanding of the target model’s provenance.

Model Version Search. While model provenance is a research challenge for identifying and explaining the transformation of one model, an extension to this challenge could be to identify versions given a set of models, $M_{SET}=[M_{1},M_{2},...,M_{N}]$ and a set of datasets, $D_{SET}=[D_{1},D_{2},...,D_{K}]$. A model is considered a version of another when one can be transformed into another (such as through updates in dataset and/or training algorithm) and have the same true source model (i.e., the same first version). Apart from the approaches mentioned earlier, an alternative way to explore versioning is to understand how different entities have similar and/or different information present in various models. This could, for instance, be a post-hoc analysis through creation of knowledge graphs based on particular facts in data lakes that we know change from time to time, such as the President of the United States. By doing so, we could create a version history for data through models published at various time period, and by extension, identify the chronological order of the models based on their knowledge space.

Finally, by being able to pursue any direction indicated in the roadmap above, we can create a dataset or benchmark for such research so that the research community can build upon and create better methods for detecting such model differences. In addition to such benchmarks, it is also crucial to create metrics to understand how well these methods perform. By doing so, we can also increase outside-the-box access of AI models, where obtaining verified contextual information about the model can provide better transparency and evaluation for AI audits (Casper et al., 2024). Lastly, the solution to these methods would need visualization mechanisms to illustrate how these models and data are related. For instance, maybe we can have a hierarchical/network map of how different models are connected together? The next set of questions would be which parts of this mechanism can be automated and which ones would require a human-in-the-loop.

5. Granularity of Model Differences

There are various levels of granularity of model differences to consider. One aspect of granularity is explaining the transformation of a model. A low level granularity to identify the difference would be to identify the set of facts or data that were changed or were affected. A medium level of granularity could look like identifying the parameters that were changed and what dataset was it most likely trained on. A high level of granularity would be to just identify whether a model-in-question was fine-tuned from other model.

Figure 1. Potential new user interaction with model lakes. The left figure shows how a user can input the task and data they are interested in and find relevant models based on potential relevant identified tags. The figure on the right shows a model card of one of the models and with visualization of various model lake analytics.

Another aspect of granularity is the level of information used to understand the model differences – did we use just the model weights? do we need their datasets? did we also use their documentation, i.e., their model cards? If we can find the difference between models by just using their model weights, then we can consider this difference to be a low-level information granularity. If we assume that we know at least one of the models’ datasets, then we can consider the difference to be a medium level. Lastly, if we depend on documentation to understand a pair of models’ differences, then we would consider it as a high-level of granularity. This can also scale the level of trust or confidence we can have for each model difference or similarity identification. For instance, identifying the difference between two models using just documentation has low level of confidence because we rely on trusting that the documentation is accurate. Furthermore, the accessibility of documentation can be limited because there is currently no structured way of documenting a model’s training process and inputs. However, if we rely on just the model’s weights, we can trust the identification more since it does not have an extra layer of information to process and understand the model.

Caveats and Considerations. There are a couple concerns with respect to extracting information about a model with low level granularity. If we were able to extract specific training data facts using just model weights, it can also be considered a privacy attack, which would mean that the model is unsafe in terms of privacy. Hence, in terms of providing granularity/verification scores as shown in  Figure 1, it would have a high data verification score, but a low confidence in privacy. Another challenge with model lake tasks is differentiating between a predictive path and a deterministic path. For instance, in the case of identifying the source model of a certain model (model provenance task), we might find a couple of models that meet the possibility of it being a source model. In such cases, a lower than normal granularity score can be assigned unless a potential source model option is backed by another source of information, such as the model card.

6. MODEL LAKES: APPLICATION

Similar to a data lake, a model lake can be defined as a system or repository of many heterogeneous models and their related data stored in their natural format, for example, as files of model parameters. As the community progresses along the proposed directions, we can develop an intuitive navigation of a model lake, as depicted in  Figure 1. This improvement can be helpful for addressing the Model Selection Problem shared in  Example 1. In the left-side of  Figure 1, we show that a user can search for models by ty** out the task and type of data they are interested in working with. Based on this input, there can be an algorithm to semantically parse this text and find closely related task and data tags. Based on these tags, the search engine can share the most relevant models. Upon clicking a model, the model lake interface can lead to a model card page that may look similar to the right-side of the same figure. In this page, the users can view the model card description as well as what the model’s previous, next, source, and related models. In addition, they can also view what the training data was in order to understand if it was trained on desired text. If the training data is not specified, another way of understanding whether the model has a semantic understanding of the type of text the user cares about (for instance, legal jargon in the case of  Example 1) is by viewing a semantic knowledge graph of the model and filtering for ‘legal’ within that graph. Within the model card, there can also be a privacy scale of low, medium, and high to gauge whether the model tends to share private information that was used in training data. Lastly, it could also have a set of verification scores (verifiable documentation task) to gauge how well this model is verified. The verification is categorized into data, code, and document verification. This scale would vary based on the level of granularity that they were verified with. 0 would indicate that they haven’t been verified and 1-5 would represent high level to low level verification where where high level implies less aspects of the model verified verses low level indicates that most, if not all, the verification was done using the model weight values.

7. Conclusion

The database community has responded to the “Big Model” revolution by proposing platforms like Agora (Traub et al., 2020), that manage data-related assets, including models, datasets, software, and compute resources in a coherent ecosystem. There is now a need for general methods for managing model lakes. It will be important that the methods generalize, irrespective of how many models we are trying to understand, how they are trained, or what base of information we wish to use to resolve our tasks. We call on the database community to contribute to the vision of model lakes, supporting users to better distinguish a set of models that they might want to choose from for their own tasks as well as alleviate future data and model management concerns that come up the rise of deep learning models. Our vision is for a fundamentally new platform that extends and integrates works on data/model provenance, data/model citation, and data/model version management.