<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">The Case for Instance-Optimized LLMs in OLAP Databases</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Bardia</forename><surname>Mohammadi</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">Max Planck Institute for Software Systems</orgName>
								<address>
									<settlement>Saarbrücken</settlement>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Laurent</forename><surname>Bindschaedler</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">Max Planck Institute for Software Systems</orgName>
								<address>
									<settlement>Saarbrücken</settlement>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">The Case for Instance-Optimized LLMs in OLAP Databases</title>
					</analytic>
					<monogr>
						<idno type="ISSN">1613-0073</idno>
					</monogr>
					<idno type="MD5">06199C98A37600B30721623DA566831F</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2025-04-23T18:09+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<textClass>
				<keywords>
					<term>analytics</term>
					<term>cube</term>
					<term>OLAP</term>
					<term>LLM</term>
					<term>instance-optimization</term>
					<term>scalability</term>
					<term>quantization</term>
					<term>sparsification</term>
					<term>pruning</term>
				</keywords>
			</textClass>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>Large Language Models (LLMs) can enhance analytics systems with powerful data summarization, cleaning, and semantic transformation capabilities. However, deploying LLMs at scale -processing millions to billions of rows -remains prohibitively expensive in computation and memory. We present IOLM-DB, a novel system that makes LLM-enhanced database queries practical through query-specific model optimization. Instead of using general-purpose LLMs, IOLM-DB generates lightweight, specialized models tailored to each query's specific needs using representative data samples. IOLM-DB reduces model footprints by up to 76% and increases throughput by up to 3.31× while maintaining accuracy through aggressive compression techniques, including quantization, sparsification, and structural pruning. We further show how our approach enables higher parallelism on existing hardware and seamlessly supports caching and batching strategies to reduce overheads. Our prototype demonstrates that leveraging LLM queries inside analytics systems is feasible at scale, opening new possibilities for future OLAP applications.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.">Introduction</head><p>LLMs have demonstrated exceptional capabilities in natural language understanding and generation <ref type="bibr" target="#b0">[1,</ref><ref type="bibr" target="#b1">2,</ref><ref type="bibr" target="#b2">3,</ref><ref type="bibr" target="#b3">4]</ref>. One promising application in data management is integrating LLM prompting into database queries. This approach is particularly useful in analytical database systems, enabling users to harness the power of LLMs directly in their queries <ref type="bibr" target="#b4">[5,</ref><ref type="bibr" target="#b5">6]</ref>. For instance, given a table of unstructured product reviews, a user could write a query like:</p><p>SELECT product_id, user_id, prompt('summarize in 5 words: ' || review) AS review_summary FROM product_reviews;</p><p>This approach opens up new possibilities for generating, summarizing, cleaning, and transforming structured and unstructured data directly within the database.</p><p>However, applying LLM prompts to each row of data presents significant challenges. A typical query, such as a transformation, classification, or schema extraction, requires a separate LLM invocation involving tokenization, context encoding, and autoregressive decoding. This perrow inference results in high computational overhead, as even simple queries can trigger millions or billions of LLM calls, leading to excessive latency and resource consumption, especially for large tables. While running local models <ref type="bibr" target="#b2">[3,</ref><ref type="bibr" target="#b6">7]</ref> instead of cloud-based models <ref type="bibr" target="#b7">[8,</ref><ref type="bibr" target="#b8">9,</ref><ref type="bibr" target="#b1">2]</ref> may reduce costs and latency, the overheads typically remain significant relative to conventional database operations, and running large-scale distributed models may prove challenging due to the lack of co-located accelerators and large memory requirements. These limitations highlight the importance of developing efficient strategies to integrate LLMs into analytics workflows without compromising performance or scalability. We propose a practical approach to mitigate these challenges: instance-optimized LLMs for databases (IOLM-DB). By tailoring models to the specific workloads and data distributions of a given query and database instance, we reduce the cost of LLM inference, making it more practical to use at scale. We find that the OLAP setup is an ideal environment for creating optimized models because it operates in a controlled setting where the workload and data are predictable. IOLM-DB combines multiple model compression techniques, including quantization (reducing numerical precision) <ref type="bibr" target="#b9">[10]</ref>, sparsification (introducing zero elements) <ref type="bibr" target="#b10">[11]</ref>, and structural pruning (removing non-essential components) <ref type="bibr" target="#b11">[12]</ref>. The resulting models preserve task-relevant capabilities while being significantly smaller and cheaper to execute with higher parallelism, helping to narrow the performance gap for row-by-row LLM execution.</p><p>We have developed an initial prototype of IOLM-DB that targets Python's pandas library <ref type="bibr" target="#b12">[13]</ref> for rapid iteration. By working in this simplified environment, we can experiment with various optimization strategies and gather initial performance insights before integrating these strategies into a production environment. The main objective of this paper is to provide a proof-of-concept for our approach, allowing us to evaluate potential performance gains and identify challenges that may arise when implementing and deploying instance-optimized models. Our preliminary results indicate that IOLM-DB can generate compressed models on the fly that are up to 3.28× smaller than the base model while sporting similar or better accuracy, achieves higher parallelism on the same hardware, and increases throughput between 2.52× and 3.31× on three representative workloads.</p><p>The paper makes the following contributions:</p><p>• We propose an end-to-end system for prototyping LLM prompting in OLAP scenarios and a series of workloads to assess its performance. • We introduce the first method for generating instance-optimized LLMs in database environments. • We evaluate the efficiency of our method on the proposed workloads, showing significant performance improvements. These results indicate a promising first step toward demonstrating the feasibility of LLM compression for such applications.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.">Background and Motivation</head><p>This section briefly overviews key concepts and related work that motivate our approach.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>LLM Prompting in Databases</head><p>Augmenting databases with the ability to prompt LLMs can facilitate data wrangling and analysis by enabling natural language queries and transformations <ref type="bibr" target="#b5">[6]</ref>. Rather than exporting data for external processing or implementing complex client-side integrations, bringing LLM capabilities directly into the database execution environment offers a more streamlined approach.</p><p>Recent non-peer-reviewed work, such as LOTUS <ref type="bibr" target="#b13">[14]</ref>, has demonstrated the feasibility of extending relational models with LLM-powered semantic operators, enabling AI-based operations like natural language-driven sorting and aggregation. This paper considers a system that integrates LLM prompts as first-class operations within the query processing pipeline, allowing them to be composed with traditional database operations. While our focus is on OLAP systems, the principles extend to other database architectures.</p><p>New LLM-Based Capabilities LLM integration enables powerful new capabilities for database systems, especially when working with unstructured or semi-structured data. These capabilities include summarization, sentiment analysis, data extraction, error correction, and semantic transformations. LLMs can also enable more flexible abnd intuitive operations, such as fuzzy matching and semantic joins beyond exact string matching.</p><p>Other Approaches Existing approaches to adding these capabilities have notable limitations. Code generation techniques <ref type="bibr" target="#b14">[15,</ref><ref type="bibr" target="#b4">5]</ref>, where LLMs generate executable database code, can be brittle and struggle with complex transformations that require deep semantic understanding. Alternative approaches using simpler models trained on input-output pairs <ref type="bibr" target="#b15">[16,</ref><ref type="bibr" target="#b16">17,</ref><ref type="bibr" target="#b17">18]</ref> face challenges handling diverse scenarios and require extensive training data curation. While these methods can work for specific use cases, they often fail to provide the flexibility and generality needed for broad adoption in database systems.</p><p>The Need for Instance-Optimization We argue that anything short of directly invoking the LLM for such tasks is inherently limiting, as it would restrict the system's expressiveness. Therefore, efficiency is paramount to making LLMs practical at scale, especially for large-scale analytics. Many anticipated use cases require invoking the LLM at a fine-grained level, such as once per row or more frequently <ref type="bibr" target="#b5">[6]</ref>. This granularity requires a new approach that reduces inference costs while maintaining accuracy, which motivates our approach of specializing LLMs for specific prompts and data patterns. OLAP environments are particularly well-suited for such optimizations, as their controlled setting often allows query patterns and data characteristics to be inferred or extracted in advance, enabling model optimization tailored to these patterns. Similarly, interactive queries frequently exhibit recurring or predictable patterns that can be leveraged to create instance-optimized models, improving efficiency and accuracy as these patterns evolve over time. Although our current method may introduce too much overhead for some use cases, we expect it to be highly effective for long-running queries, where significant performance gains outweigh the upfront cost of optimization during execution.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>LLM Compression Techniques</head><p>Recent advances in LLM optimization provide a foundation for our approach. We leverage three key techniques from the literature: quantization, which reduces numerical precision to decrease memory requirements <ref type="bibr" target="#b18">[19]</ref>; sparsification, which introduces strategic zero elements to minimize computational overhead <ref type="bibr" target="#b10">[11]</ref>; and structural pruning, which removes non-essential model components <ref type="bibr" target="#b11">[12]</ref>. While these techniques have proven effective for domain-specific optimization, our scenario presents unique challenges. We need to optimize at a much finer granularity -for individual queries or prompts rather than broad domains -and ensure consistent, predictable behavior when working with structured data.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.">System Design and Architecture</head><p>IOLM-DB is an OLAP system that integrates LLM invocation directly into its execution pipeline while ensuring that this integration is efficient, scalable, and cost-effective.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1.">Overview</head><p>We assume a setup where the user executes queries over one or more database tables (in our prototype, pandas DataFrames). These queries can include calls to an LLM, for example, to summarize free-form text columns, transform semi-structured fields, or provide semantic annotations. Rather than invoking a general-purpose LLM repeatedly and incurring high computational and memory overhead at runtime, IOLM-DB creates a specialized, instance-optimized LLM explicitly tailored for the query and dataset. For example, a query performing text summarization on product reviews requires a different optimization than a data correction query. To achieve this specialization, the model is compressed and pruned based on the query type and data characteristics. This approach is necessary because a onesize-fits-all model is inefficient; different queries demand varying levels of understanding, precision, and computational cost.</p><p>IOLM-DB works in tandem with the underlying analytics engine. While the engine handles standard relational operations efficiently, we introduce custom operators that intercept LLM prompts in the query. These operators trigger a workflow that generates a specialized LLM for that particular query and data distribution. This process leverages a suite of techniques -quantification, sparsification, and pruning -to minimize both the memory footprint of the LLM and the inference costs, ensuring that at runtime the optimized LLM can be invoked with minimal latency and resource usage.</p><p>We drastically reduce per-row inference overhead by producing a specialized LLM for each query instance. This approach enables running LLM-based transformations and analyses at scale, supporting massive parallelism and efficient resource utilization. Ultimately, the goal is to handle large workloads and large numbers of concurrent queries while providing near-interactive response times.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2.">Techniques to Generate</head><p>Instance-Optimized Model</p><p>Our system combines multiple compression techniques to reduce memory consumption and compute costs at the LLM level. By carefully integrating these methods, we maintain model accuracy while achieving significant resource savings. We combine the following techniques in IOLM-DB.</p><p>Quantization By lowering numerical precision (e.g., using 8-bit weights and sometimes 8-bit activations), we reduce both the GPU memory footprint and computational overhead. Quantization retains the model's core capabilities but significantly increases inference throughput.</p><p>Sparsification Imposing structured or unstructured sparsity patterns in model weights reduces the number of active parameters, leading to fewer operations during inference and, in some cases, allows for hardware-level support for sparse computations.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Structural Pruning</head><p>Removing entire components such as attention heads or entire layers that contribute little to the task at hand reduces model depth and complexity. Full structural pruning, aided by tools such as LLM-Pruner <ref type="bibr" target="#b19">[20]</ref>, enables the construction of ultra-compact models specialized for the given query patterns. These techniques are not applied in isolation. Methods such as GPTQ <ref type="bibr" target="#b20">[21]</ref> and SmoothQuant <ref type="bibr" target="#b21">[22]</ref> combine pruning and quantization steps to preserve accuracy while aggressively reducing size. SparseGPT <ref type="bibr" target="#b10">[11]</ref> applies pruning strategies suitable for large models in a one-shot manner, maintaining accuracy even at high sparsity levels. The result is a highly compressed model tailored to the query's distribution and the dataset's characteristics. We use calibration data -small, unlabeled samples representing the query's input domain -to finetune quantization parameters and pruning thresholds. This process ensures that the specialized LLM efficiently handles the target data, reducing resource requirements while minimizing accuracy loss.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.3.">Runtime and Invocation Optimizations</head><p>At runtime, the optimized LLM is invoked by custom operators within the OLAP engine's execution pipeline. IOLM-DB uses the following optimizations to further reduce overhead.</p><p>Caching Intermediate results and repeated inputs are cached so that identical LLM queries need not be recomputed, which is especially valuable when data contains frequent duplicates or recurring patterns.</p><p>Batching We batch multiple requests to the LLM together to amortize invocation overhead. By grouping multiple rows or operations, we minimize switching costs and achieve higher throughput.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Cascading (Future Work)</head><p>We plan to explore cascading strategies in the future, where an initial coarse-grained LLM invocation feeds into more specialized or higher-precision models only where needed. This approach could further refine trade-offs between speed, cost, and accuracy.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.">Workloads and Use Cases</head><p>We evaluate our approach on three representative workloads, each designed to highlight a different aspect of integrating LLM invocations into OLAP queries. All these workloads operate on real-world datasets (e.g., Amazon Review <ref type="bibr" target="#b22">[23]</ref>, Github Typos <ref type="bibr" target="#b23">[24]</ref>) and are designed to stress different points along the performance-accuracy spectrum.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.1.">Summarization (Text Reduction)</head><p>This workload involves condensing verbose free-text fields into short summaries. An example use case is taking product reviews, extracting their essential meaning, and outputting a concise summary -e.g., summarizing each product review into five words. Such summarization helps analysts quickly gain insights from large volumes of textual data without manually sifting through lengthy entries. By operating on unstructured Amazon Reviews datasets <ref type="bibr" target="#b22">[23]</ref>, we test the system's ability to scale and maintain accuracy when transforming large amounts of unstructured text.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.2.">Data Correction</head><p>Data correction enhances data quality by addressing errors or inconsistencies. For instance, we can provide a specific data type or category and task the system with correcting typos or mismatches. By applying a per-row invocation of the language model, we can correct misspelled code or text records in GitHub for subsequent analysis <ref type="bibr" target="#b23">[24]</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.3.">Fuzzy Joins (Semantic Mapping)</head><p>Fuzzy joins address the problem of integrating data from multiple tables by understanding semantic similarity rather than relying on exact string matches. For example, the system can determine whether two entries from different datasets refer to the same entity despite slight differences in wording or formatting, even when textual fields do not perfectly align, improving data integration and discovery.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.">Evaluation</head><p>We conduct a preliminary evaluation of IOLM-DB through experiments on the three workloads and associated datasets described in Section 4. Our key objective is to verify the viability of our approach for scaling LLM invocations per row in a realistic setting.</p><p>Metrics Our evaluation centers on the following metrics:</p><p>• Throughput: The number of rows processed per second by the system, which reflects its overall efficiency and scalability. • Model Size: The size of the model, which serves as a proxy for GPU memory usage and its capacity to parallelize execution effectively. Smaller models typically reduce memory pressure and improve resource utilization. • Accuracy: The proportion of rows where the system produces correct results. For this evaluation, we assume the baseline model achieves perfect accuracy (accuracy = 1), and we compare the optimized models by normalizing against this standard.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Models</head><p>We conduct our evaluation using Meta's Llama 3.1 Instruct model with 8 billion parameters instructiontuned language model (Llama-3.1-Instruct-8B) <ref type="bibr" target="#b2">[3]</ref>, which strikes a balance between size and performance for the workloads under consideration. The model is compact enough to fit on a single modern GPU yet powerful enough to deliver strong performance across all tasks. We verified our Llama model's suitability for these tasks by comparing it against OpenAI's GPT4o and Anthropic's Claude Sonnet 3.5 and manually verifying the results.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Baseline and Configurations</head><p>We execute IOLM-DB using Llama-3.1-Instruct-8B, which serves as our baseline for all metrics. Building upon this foundation, we evaluate two optimized variants: Throughput, memory usage, and accuracy score (normalized to the baseline) for each of the three workloads considered in this paper. IOLM-DB-Perf corresponds to the compressed model with the highest throughput, while IOLM-DB-Acc is the compressed model with the highest accuracy score. We report the overall throughput in rows per second.</p><note type="other">Workload Model Model Size Accuracy Score Throughput Summarization</note><p>• IOLM-DB-Perf: instance-optimized version of the Llama-3.1-Instruct-8B with the best throughput. • IOLM-DB-Acc: instance-optimized version of the Llama-3.1-Instruct-8B with the best accuracy.</p><p>These two variants highlight an interesting trade-off between performance and accuracy enabled by IOLM-DB which we aim to explore in future work, allowing the user to select whether to spend more time for better results or to produce slightly less accurate results faster.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Hardware and Configuration</head><p>We run these experiments on a machine equipped with an NVIDIA Hopper H100 80 GB SXM GPU, two AMD CPUs (EPYC 9654), and 2 TB of DDR5. The operating system is 64-bit Debian Linux (kernel version 5.15). We use CUDA 11.8, vLLM 0.6.3, and HuggingFace 4.46.1 transformers.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.1.">Performance, Model Size, and Accuracy</head><p>Table <ref type="table" target="#tab_0">1</ref> compares the baseline with our IOLM-DB instanceoptimized models. We show the overall model size as measured on the GPU, the resulting accuracy in our dataset (normalized to the baseline), and the throughput achieved in each case (in rows processed per second).</p><p>These results underscore the benefits of instanceoptimization for LLMs across all workloads considered. In all cases except summarization, both IOLM-DB-Perf and IOLM-DB-Acc achieve an accuracy score of 1, demonstrating that our approach maintains baseline-level accuracy. This outcome highlights that our optimizations preserve model quality while reducing resource requirements.</p><p>Our method achieves significant reductions in model size, with compression factors of up to 76%, through quantization, sparsification, and pruning. These reductions lower memory requirements and improve computational efficiency. The throughput improvements are substantial: 2.78× for data correction and 2.52× for fuzzy join workloads. For summarization, despite a slight accuracy decrease in IOLM-DB-Perf, we observe a 3.31× throughput improvement. These performance gains stem from the compressed models and reduced model size, enabling higher parallelism.</p><p>The results demonstrate that instance-optimized LLMs can effectively balance accuracy and efficiency, making them suitable for performance-critical applications.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.2.">Discussion</head><p>Although these results are preliminary, they highlight the potential of instance-optimization to enable efficient LLM querying in analytics workloads. Our evaluation also revealed several areas for improvement that could further enhance the performance and scalability of our solution.</p><p>One key bottleneck identified in our initial prototype is the space consumed by the vLLM cache. Optimizing the cache design could further reduce memory usage and enable increased parallelism, particularly for workloads with high concurrency demands. Also, the interface between the pandas library and our instance-optimized operators presents another area for improvement. Reengineering this interface to reduce overhead and improve integration could significantly boost overall performance. We expect to gain one or two orders of magnitude performance improvements from these optimizations.</p><p>An interesting observation is that the resulting quality, particularly for IOLM-DB-Acc, often improves compared to the baseline. However, the normalization of the accuracy score prevents this improvement from being reflected in Table <ref type="table" target="#tab_0">1</ref>. These findings suggest that our instance-optimized approach not only preserves accuracy but can, in some cases, enhance it. Further investigation is needed to understand the underlying factors driving these improvements and to explore how they can be consistently leveraged.</p><p>Finally, we plan to explore additional techniques in the LLM compression space, such as advanced quantization methods and knowledge distillation. The time to generate an instance-optimized LLM is in the order of single-digit minutes, which we believe is acceptable for most table sizes. However, reducing that further could unlock additional use cases outside the OLAP space.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="6.">Conclusion</head><p>This paper presented IOLM-DB, a proof-of-concept system for integrating LLM operations directly into OLAP query pipelines. The core innovation lies in instance-optimizing LLMs based on the specific query and dataset at hand. IOLM-DB can generate specialized models that drastically reduce inference costs without sacrificing accuracy by leveraging quantization, sparsification, and pruning techniques. Our preliminary results suggest that this approach makes rowby-row invocation of LLMs at scale both practical and efficient, bridging the gap between powerful linguistic transformations and large-scale analytics.</p><p>This line of work opens up promising research directions, encouraging the community to refine these techniques further, explore new instance-level optimizations, and ultimately bring high-performance, query-aware LLM capabilities into mainstream analytical workflows.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head></head><label></label><figDesc>DOLAP 2025: 27th International Workshop on Design, Optimization, Languages and Analytical Processing of Big Data, co-located with EDBT/ICDT 2025, March 25, 2025, Barcelona, Spain * Corresponding author. Envelope bmohamma@mpi-sws.org (B. Mohammadi); bindsch@mpi-sws.org (L. Bindschaedler) GLOBE https://bardia-mhd.github.io/ (B. Mohammadi); https://binds.ch (L. Bindschaedler) Orcid 0009-0001-3658-7291 (B. Mohammadi); 0000-0003-0559-631X (L. Bindschaedler)</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_0"><head>Table 1</head><label>1</label><figDesc></figDesc><table><row><cell></cell><cell>Baseline</cell><cell>14.98 GB</cell><cell>1</cell><cell>4.67 rows/s</cell></row><row><cell></cell><cell>IOLM-DB-Perf</cell><cell>8.48 GB</cell><cell>0.91</cell><cell>15.50 rows/s</cell></row><row><cell></cell><cell>IOLM-DB-Acc</cell><cell>8.48 GB</cell><cell>1</cell><cell>11.97 rows/s</cell></row><row><cell></cell><cell>Baseline</cell><cell>14.98 GB</cell><cell>1</cell><cell>2.73 rows/s</cell></row><row><cell>Data Correction</cell><cell>IOLM-DB-Perf</cell><cell>8.48 GB</cell><cell>1</cell><cell>7.60 rows/s</cell></row><row><cell></cell><cell>IOLM-DB-Acc</cell><cell>8.48 GB</cell><cell>1</cell><cell>7.60 rows/s</cell></row><row><cell></cell><cell>Baseline</cell><cell>14.98 GB</cell><cell>1</cell><cell>14.92 rows/s</cell></row><row><cell>Fuzzy Join</cell><cell>IOLM-DB-Perf</cell><cell>8.48 GB</cell><cell>1</cell><cell>37.72 rows/s</cell></row><row><cell></cell><cell>IOLM-DB-Acc</cell><cell>8.48 GB</cell><cell>1</cell><cell>37.72 rows/s</cell></row></table></figure>
		</body>
		<back>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">Language models are few-shot learners</title>
		<author>
			<persName><forename type="first">T</forename><surname>Brown</surname></persName>
		</author>
		<author>
			<persName><forename type="first">B</forename><surname>Mann</surname></persName>
		</author>
		<author>
			<persName><forename type="first">N</forename><surname>Ryder</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Subbiah</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><forename type="middle">D</forename><surname>Kaplan</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><surname>Dhariwal</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Neelakantan</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><surname>Shyam</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Sastry</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Askell</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Advances in neural information processing systems</title>
		<imprint>
			<biblScope unit="volume">33</biblScope>
			<biblScope unit="page" from="1877" to="1901" />
			<date type="published" when="2020">2020</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<monogr>
		<author>
			<persName><forename type="first">G</forename><surname>Team</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><surname>Anil</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Borgeaud</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J.-B</forename><surname>Alayrac</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Yu</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><surname>Soricut</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Schalkwyk</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><forename type="middle">M</forename><surname>Dai</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Hauth</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K</forename><surname>Millican</surname></persName>
		</author>
		<idno type="arXiv">arXiv:2312.11805</idno>
		<title level="m">Gemini: a family of highly capable multimodal models</title>
				<imprint>
			<date type="published" when="2023">2023</date>
		</imprint>
	</monogr>
	<note type="report_type">arXiv preprint</note>
</biblStruct>

<biblStruct xml:id="b2">
	<monogr>
		<author>
			<persName><forename type="first">H</forename><surname>Touvron</surname></persName>
		</author>
		<author>
			<persName><forename type="first">T</forename><surname>Lavril</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Izacard</surname></persName>
		</author>
		<author>
			<persName><forename type="first">X</forename><surname>Martinet</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M.-A</forename><surname>Lachaux</surname></persName>
		</author>
		<author>
			<persName><forename type="first">T</forename><surname>Lacroix</surname></persName>
		</author>
		<author>
			<persName><forename type="first">B</forename><surname>Rozière</surname></persName>
		</author>
		<author>
			<persName><forename type="first">N</forename><surname>Goyal</surname></persName>
		</author>
		<author>
			<persName><forename type="first">E</forename><surname>Hambro</surname></persName>
		</author>
		<author>
			<persName><forename type="first">F</forename><surname>Azhar</surname></persName>
		</author>
		<idno type="arXiv">arXiv:2302.13971</idno>
		<title level="m">Llama: Open and efficient foundation language models</title>
				<imprint>
			<date type="published" when="2023">2023</date>
		</imprint>
	</monogr>
	<note type="report_type">arXiv preprint</note>
</biblStruct>

<biblStruct xml:id="b3">
	<monogr>
		<author>
			<persName><forename type="first">S</forename><surname>Bubeck</surname></persName>
		</author>
		<author>
			<persName><forename type="first">V</forename><surname>Chandrasekaran</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><surname>Eldan</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Gehrke</surname></persName>
		</author>
		<author>
			<persName><forename type="first">E</forename><surname>Horvitz</surname></persName>
		</author>
		<author>
			<persName><forename type="first">E</forename><surname>Kamar</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><surname>Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Y</forename><forename type="middle">T</forename><surname>Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Y</forename><surname>Li</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Lundberg</surname></persName>
		</author>
		<idno type="arXiv">arXiv:2303.12712</idno>
		<title level="m">Sparks of artificial general intelligence: Early experiments with gpt-4</title>
				<imprint>
			<date type="published" when="2023">2023</date>
		</imprint>
	</monogr>
	<note type="report_type">arXiv preprint</note>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">Towards efficient data wrangling with llms using code generation</title>
		<author>
			<persName><forename type="first">X</forename><surname>Li</surname></persName>
		</author>
		<author>
			<persName><forename type="first">T</forename><surname>Döhmen</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the Eighth Workshop on Data Management for Endto-End Machine Learning</title>
				<meeting>the Eighth Workshop on Data Management for Endto-End Machine Learning</meeting>
		<imprint>
			<date type="published" when="2024">2024</date>
			<biblScope unit="page" from="62" to="66" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<monogr>
		<author>
			<persName><forename type="first">A</forename><surname>Narayan</surname></persName>
		</author>
		<author>
			<persName><forename type="first">I</forename><surname>Chami</surname></persName>
		</author>
		<author>
			<persName><forename type="first">L</forename><surname>Orr</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Arora</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Ré</surname></persName>
		</author>
		<idno type="arXiv">arXiv:2205.09911</idno>
		<title level="m">Can foundation models wrangle your data?</title>
				<imprint>
			<date type="published" when="2022">2022</date>
		</imprint>
	</monogr>
	<note type="report_type">arXiv preprint</note>
</biblStruct>

<biblStruct xml:id="b6">
	<monogr>
		<author>
			<persName><forename type="first">A</forename><forename type="middle">Q</forename><surname>Jiang</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Sablayrolles</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Mensch</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Bamford</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D</forename><forename type="middle">S</forename><surname>Chaplot</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D</forename><surname>Casas</surname></persName>
		</author>
		<author>
			<persName><forename type="first">F</forename><surname>Bressand</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Lengyel</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Lample</surname></persName>
		</author>
		<author>
			<persName><forename type="first">L</forename><surname>Saulnier</surname></persName>
		</author>
		<idno type="arXiv">arXiv:2310.06825</idno>
		<title level="m">Mistral 7b</title>
				<imprint>
			<date type="published" when="2023">2023</date>
		</imprint>
	</monogr>
	<note type="report_type">arXiv preprint</note>
</biblStruct>

<biblStruct xml:id="b7">
	<monogr>
		<author>
			<persName><forename type="first">J</forename><surname>Achiam</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Adler</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Agarwal</surname></persName>
		</author>
		<author>
			<persName><forename type="first">L</forename><surname>Ahmad</surname></persName>
		</author>
		<author>
			<persName><forename type="first">I</forename><surname>Akkaya</surname></persName>
		</author>
		<author>
			<persName><forename type="first">F</forename><forename type="middle">L</forename><surname>Aleman</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D</forename><surname>Almeida</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Altenschmidt</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Altman</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Anadkat</surname></persName>
		</author>
		<idno type="arXiv">arXiv:2303.08774</idno>
		<title level="m">Gpt-4 technical report</title>
				<imprint>
			<date type="published" when="2023">2023</date>
		</imprint>
	</monogr>
	<note type="report_type">arXiv preprint</note>
</biblStruct>

<biblStruct xml:id="b8">
	<monogr>
		<title/>
		<author>
			<persName><forename type="first">Claude</forename><surname>Anthropic</surname></persName>
		</author>
		<ptr target="https://www.anthropic.com/claude,largelanguagemodel" />
		<imprint>
			<date type="published" when="2024">2024</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b9">
	<analytic>
		<title level="a" type="main">Exploiting LLM quantization</title>
		<author>
			<persName><forename type="first">K</forename><surname>Egashira</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Vero</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><surname>Staab</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>He</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Vechev</surname></persName>
		</author>
		<ptr target="https://openreview.net/forum?id=ISa7mMe7Vg" />
	</analytic>
	<monogr>
		<title level="m">The Thirty-eighth Annual Conference on Neural Information Processing Systems</title>
				<imprint>
			<date type="published" when="2024">2024</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b10">
	<monogr>
		<title level="m" type="main">Sparsegpt: Massive language models can be accurately pruned in oneshot</title>
		<author>
			<persName><forename type="first">E</forename><surname>Frantar</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D</forename><surname>Alistarh</surname></persName>
		</author>
		<idno>ArXiv abs/2301.00774</idno>
		<ptr target="https://api.semanticscholar.org/CorpusID:255372747" />
		<imprint>
			<date type="published" when="2023">2023</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b11">
	<monogr>
		<title level="m" type="main">Llm-pruner: On the structural pruning of large language models</title>
		<author>
			<persName><forename type="first">X</forename><surname>Ma</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Fang</surname></persName>
		</author>
		<author>
			<persName><forename type="first">X</forename><surname>Wang</surname></persName>
		</author>
		<idno>ArXiv abs/2305.11627</idno>
		<ptr target="https://api.semanticscholar.org/CorpusID:258823276" />
		<imprint>
			<date type="published" when="2023">2023</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b12">
	<monogr>
		<title level="m" type="main">pandas: a foundational python library for data analysis and statistics, Python for high performance and scientific computing</title>
		<author>
			<persName><forename type="first">W</forename><surname>Mckinney</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2011">2011</date>
			<biblScope unit="volume">14</biblScope>
			<biblScope unit="page" from="1" to="9" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b13">
	<monogr>
		<author>
			<persName><forename type="first">L</forename><surname>Patel</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Jha</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Guestrin</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Zaharia</surname></persName>
		</author>
		<idno type="arXiv">arXiv:2407.11418</idno>
		<title level="m">Lotus: Enabling semantic queries with llms over tables of unstructured and structured data</title>
				<imprint>
			<date type="published" when="2024">2024</date>
		</imprint>
	</monogr>
	<note type="report_type">arXiv preprint</note>
</biblStruct>

<biblStruct xml:id="b14">
	<monogr>
		<author>
			<persName><forename type="first">M</forename><surname>Chen</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Tworek</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Jun</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Q</forename><surname>Yuan</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><forename type="middle">P D O</forename><surname>Pinto</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Kaplan</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Edwards</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Y</forename><surname>Burda</surname></persName>
		</author>
		<author>
			<persName><forename type="first">N</forename><surname>Joseph</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Brockman</surname></persName>
		</author>
		<idno type="arXiv">arXiv:2107.03374</idno>
		<title level="m">Evaluating large language models trained on code</title>
				<imprint>
			<date type="published" when="2021">2021</date>
		</imprint>
	</monogr>
	<note type="report_type">arXiv preprint</note>
</biblStruct>

<biblStruct xml:id="b15">
	<analytic>
		<title level="a" type="main">Flashfill++: Scaling programming by example by cutting to the chase</title>
		<author>
			<persName><forename type="first">J</forename><surname>Cambronero</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Gulwani</surname></persName>
		</author>
		<author>
			<persName><forename type="first">V</forename><surname>Le</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D</forename><surname>Perelman</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Radhakrishna</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Simon</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Tiwari</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the ACM on Programming Languages</title>
				<meeting>the ACM on Programming Languages</meeting>
		<imprint>
			<date type="published" when="2023">2023</date>
			<biblScope unit="volume">7</biblScope>
			<biblScope unit="page" from="952" to="981" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b16">
	<analytic>
		<title level="a" type="main">Data extraction via semantic regular expression synthesis</title>
		<author>
			<persName><forename type="first">Q</forename><surname>Chen</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Banerjee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Ç</forename><surname>Demiralp</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Durrett</surname></persName>
		</author>
		<author>
			<persName><forename type="first">I</forename><surname>Dil</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the ACM on Programming Languages</title>
				<meeting>the ACM on Programming Languages</meeting>
		<imprint>
			<date type="published" when="2023">2023</date>
			<biblScope unit="volume">7</biblScope>
			<biblScope unit="page" from="1848" to="1877" />
		</imprint>
	</monogr>
	<note>lig</note>
</biblStruct>

<biblStruct xml:id="b17">
	<analytic>
		<title level="a" type="main">Transform-data-by-example (tde) an extensible search engine for data transformations</title>
		<author>
			<persName><forename type="first">Y</forename><surname>He</surname></persName>
		</author>
		<author>
			<persName><forename type="first">X</forename><surname>Chu</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K</forename><surname>Ganjam</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Y</forename><surname>Zheng</surname></persName>
		</author>
		<author>
			<persName><forename type="first">V</forename><surname>Narasayya</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Chaudhuri</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Proceedings of the VLDB Endowment</title>
		<imprint>
			<biblScope unit="volume">11</biblScope>
			<biblScope unit="page" from="1165" to="1177" />
			<date type="published" when="2018">2018</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b18">
	<monogr>
		<author>
			<persName><forename type="first">E</forename><surname>Frantar</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Ashkboos</surname></persName>
		</author>
		<author>
			<persName><forename type="first">T</forename><surname>Hoefler</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D</forename><surname>Alistarh</surname></persName>
		</author>
		<idno>ArXiv abs/2210.17323</idno>
		<ptr target="https://api.semanticscholar.org/CorpusID:253237200" />
		<title level="m">Gptq: Accurate post-training quantization for generative pre-trained transformers</title>
				<imprint>
			<date type="published" when="2022">2022</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b19">
	<analytic>
		<title level="a" type="main">Llm-pruner: On the structural pruning of large language models</title>
		<author>
			<persName><forename type="first">X</forename><surname>Ma</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Fang</surname></persName>
		</author>
		<author>
			<persName><forename type="first">X</forename><surname>Wang</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Advances in neural information processing systems</title>
		<imprint>
			<biblScope unit="volume">36</biblScope>
			<biblScope unit="page" from="21702" to="21720" />
			<date type="published" when="2023">2023</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b20">
	<analytic>
		<title level="a" type="main">Gptq: Accurate post-training quantization for generative pretrained transformers</title>
		<author>
			<persName><forename type="first">E</forename><surname>Frantar</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Ashkboos</surname></persName>
		</author>
		<author>
			<persName><forename type="first">T</forename><surname>Hoefler</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D</forename><surname>Alistarh</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">The Eleventh International Conference on Learning Representations</title>
				<imprint>
			<date type="published" when="2023">2023</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b21">
	<analytic>
		<title level="a" type="main">Smoothquant: Accurate and efficient post-training quantization for large language models</title>
		<author>
			<persName><forename type="first">G</forename><surname>Xiao</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Lin</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Seznec</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Wu</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Demouth</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Han</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">International Conference on Machine Learning</title>
				<meeting><address><addrLine>PMLR</addrLine></address></meeting>
		<imprint>
			<date type="published" when="2023">2023</date>
			<biblScope unit="page" from="38087" to="38099" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b22">
	<analytic>
		<title level="a" type="main">Justifying recommendations using distantly-labeled reviews and fine-grained aspects</title>
		<author>
			<persName><forename type="first">J</forename><surname>Ni</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Li</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Mcauley</surname></persName>
		</author>
		<ptr target="https://api.semanticscholar.org/CorpusID:202621357" />
	</analytic>
	<monogr>
		<title level="m">Conference on Empirical Methods in Natural Language Processing</title>
				<imprint>
			<date type="published" when="2019">2019</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b23">
	<analytic>
		<title level="a" type="main">GitHub typo corpus: A largescale multilingual dataset of misspellings and grammatical errors</title>
		<author>
			<persName><forename type="first">M</forename><surname>Hagiwara</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Mita</surname></persName>
		</author>
		<ptr target="https://aclanthology.org/2020.lrec-1.835" />
	</analytic>
	<monogr>
		<title level="m">Proceedings of the Twelfth Language Resources and Evaluation Conference, European Language Resources Association</title>
				<editor>
			<persName><forename type="first">N</forename><surname>Calzolari</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">F</forename><surname>Béchet</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">P</forename><surname>Blache</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">K</forename><surname>Choukri</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">C</forename><surname>Cieri</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">T</forename><surname>Declerck</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">S</forename><surname>Goggi</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">H</forename><surname>Isahara</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">B</forename><surname>Maegaard</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">J</forename><surname>Mariani</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">H</forename><surname>Mazo</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">A</forename><surname>Moreno</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">J</forename><surname>Odijk</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">S</forename><surname>Piperidis</surname></persName>
		</editor>
		<meeting>the Twelfth Language Resources and Evaluation Conference, European Language Resources Association<address><addrLine>Marseille, France</addrLine></address></meeting>
		<imprint>
			<date type="published" when="2020">2020</date>
			<biblScope unit="page" from="6761" to="6768" />
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
