The Case for Instance-Optimized LLMs in OLAP Databases

Bardia Mohammadi; Laurent Bindschaedler

REVIEW 4 major objections 6 minor 24 references

The Case for Instance-Optimized LLMs in OLAP Databases

T0 review · 4 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read IOLM-DB compresses a general-purpose LLM into a small per-query model, cutting memory by up to 76% and raising row-wise OLAP throughput by up to 3.31x while holding accuracy.

desk verdict A genuinely new idea—per-query compressed LLMs for OLAP—but the accuracy metric measures agreement with an assumed-perfect baseline, and the headline size-reduction numbers don't match the table, so the central claims are not yet supported. read the letter →

arxiv 2507.04967 v1 pith:CSY7LI36 submitted 2025-07-07 cs.DB cs.LG

Bardia Mohammadi , Laurent Bindschaedler This is my paper

classification cs.DBcs.LG

keywords instance-optimizedLLMOLAPmodelcompressionquantizationsparsificationstructuralpruninginferencedatatransformation

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

IOLM-DB is a proposed system for making per-row LLM calls inside analytical database queries affordable. Instead of running a large general-purpose model on every row, IOLM-DB generates a small, query-specific model by compressing an 8-billion-parameter instruction-tuned LLM with quantization, sparsification, and structural pruning, using representative rows as calibration data. The paper claims this reduces the model footprint by up to 76% and raises throughput by up to 3.31x across three workloads (summarization, data correction, and fuzzy joins) while effectively preserving output quality, with the fastest summarization variant dropping to 0.91 normalized accuracy. The motivating idea is that OLAP workloads are predictable enough for per-query specialization to amortize its upfront cost over long-running queries.

What carries the argument

The load-bearing object is IOLM-DB's generation workflow: a query and its data distribution are summarized by representative calibration samples, which are then used to tune quantization parameters and pruning thresholds while compressing the base model. The three compression techniques do the work: quantization lowers numerical precision to shrink memory and compute, sparsification introduces zero weights to reduce active operations, and structural pruning removes whole components that contribute little to the target task. Because a smaller model needs less GPU memory, more instances can run in parallel on the same hardware, which is the main source of the reported throughput gains. Runtime caching and batching are complementary mechanisms that amortize invocation overhead once the optimized model is in place.

What would settle it

Run the three workloads on a held-out set of rows with human-verified labels, and compare the baseline and optimized models on that set; the maintained-accuracy claim fails if the optimized models are substantially less accurate than the baseline. Separately, rerun the throughput experiments with caching and batching disabled to confirm that the speedup comes from compression rather than request amortization.

Watch

Extended reading notes

Core claim

The central claim is that instance-optimization can bridge the gap between expressive LLM-based transformations and scalable OLAP execution. Concretely, IOLM-DB intercepts LLM prompts in a query, samples representative rows from the target data, and applies three compression techniques — quantization (reduced numerical precision), sparsification (zeroed weights), and structural pruning (removed attention heads or layers) — to produce a specialized model for that specific query and dataset. On the paper's three workloads, the optimized variants run 2.52x to 3.31x faster than the uncompressed baseline, occupy 8.48 GB instead of 14.98 GB, and match the baseline's normalized accuracy score of 1 on all but the fastest summarization variant, which scores 0.91. The paper also notes that the best-accuracy variant sometimes improves on the baseline's output quality, but that the normalization hides this improvement.

Load-bearing premise

The reported accuracy relies on treating the uncompressed baseline as perfectly correct and measuring the optimized models only by their agreement with that baseline on data drawn from the same distribution used for calibration, with no independent ground-truth labels.

Editorial extensions

If this is right

If the reported gains hold, row-by-row LLM invocations in OLAP queries become practical for long-running workloads, since the per-query optimization cost is amortized over millions of rows.
The 76% footprint reduction implies that several optimized instances can co-reside on one GPU, enabling higher parallelism and more concurrent queries without new hardware.
The two exposed variants give users a per-query accuracy-versus-speed choice, letting them accept a small accuracy drop on summarization for a 3.31x throughput gain or keep full accuracy at 2.56x.
Caching and batching should compound with compression on workloads with repeated or similar rows, further reducing effective cost.
The approach is positioned for long-running, predictable OLAP queries; short interactive queries may not amortize the single-digit-minute optimization time.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Because the accuracy score is agreement with the baseline on calibration-distribution data rather than against human-labeled ground truth, the true task accuracy of the compressed models remains an open question; a held-out, human-verified evaluation would resolve it.
The per-query optimization cost makes the economic case strongest for repeated or cached query patterns; the authors do not quantify how many executions are needed to break even.
The same compression pipeline should transfer to larger or smaller base models and to other instruction-tuned LLMs, but the paper only demonstrates the 8-billion-parameter case, so the generality is an untested extension.
A natural next step the paper lists as future work is cascading — running a cheap model first and escalating only uncertain rows — which could push the accuracy/speed tradeoff further than any single compressed model.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The new thing here is real: instead of invoking a general-purpose LLM per row, IOLM-DB compresses a model for each query, using calibration samples from the query's data, and then runs the compressed model at scale. That's a sensible niche for OLAP, where queries are predictable and long-running enough to amortize the compression cost. Applying GPTQ, SparseGPT, and LLM-Pruner at this per-query granularity is, as far as the cited literature goes, new. The paper also positions itself cleanly against LOTUS, code-generation approaches, and TDE, and it ships an artifact on GitHub.

The proof-of-concept evaluation shows throughput gains of 2.5–3.3x on three workloads and reports accuracy scores of 1.0 for all but one configuration. Those throughput and size numbers are measured and could be reproduced. The problem is the accuracy metric. Section 5 says the baseline is assumed to achieve perfect accuracy and the optimized models are normalized against that standard. That makes the reported score an agreement-with-baseline rate, not accuracy. For summarization there is no canonical ground truth; for fuzzy joins and GitHub typo correction, labeled data exists but isn't used. On top of that, the paper never states that accuracy is measured on rows held out from the calibration used for quantization and pruning. If the same distribution or rows are used, the scores partly reflect calibration fit. So the abstract's "maintaining accuracy" claim is not established—this is the load-bearing weakness.

There's also a numbers problem. The abstract claims "up to 76%" footprint reduction, the introduction says "up to 3.28x smaller," and Table 1 shows 8.48 GB versus 14.98 GB, which is a 43% reduction (1.77x). Those can't all be true for the same artifact. The paper should also report the actual compression settings per variant—bit-width, sparsity level, pruning ratio—and give error bars, since we're seeing single numbers on one H100.

The core idea holds up conceptually; it's the evidence that's underdeveloped. This is explicitly a proof-of-concept, and the authors are honest about that, but the accuracy claim needs a proper ground-truth evaluation before the main message can be trusted.

Who gets value from this paper: anyone working on LLM-powered analytics, especially on making row-by-row inference practical. It deserves a serious referee, because the idea is novel and the evaluation can be fixed with held-out labels and reconciled numbers. I'd send it to review, but I'd expect major revisions before the claims are accepted.

Referee Report

4 major / 6 minor

Summary. The paper presents IOLM-DB, a prototype system that generates query-specific compressed LLMs for OLAP workloads by combining quantization, sparsification, and structural pruning. The system is evaluated on three workloads (text summarization, data correction, and fuzzy join) using Llama-3.1-Instruct-8B as the baseline, with experiments run in a pandas-based environment on an H100 GPU. The paper reports throughput improvements of up to 3.31x and claims footprint reductions of up to 76% while maintaining accuracy.

Significance. If the claims were fully supported, IOLM-DB would provide a useful proof-of-concept for making row-by-row LLM invocation in OLAP queries more practical, and the open-source artifact is a positive contribution. However, the accuracy metric is currently defined as agreement with a baseline assumed to be perfect, rather than as correctness against ground truth, and the reported footprint reductions are internally inconsistent. These issues directly undermine the central 'maintaining accuracy' and 'up to 76%' claims, so the significance of the work is not yet established.

major comments (4)

[Section 5 (Metrics) and Section 5.1] The accuracy metric is defined as agreement with a baseline that is assumed to be perfect ('we assume the baseline model achieves perfect accuracy (accuracy = 1)'). For all three workloads, external ground truth exists (e.g., corrected tokens in the GitHub Typo Corpus, entity-match labels for fuzzy joins, and reference summaries), but the paper does not use these labels to measure correctness. As a result, the claim that IOLM-DB 'maintains accuracy' is not established: a compressed model that merely reproduces the baseline's errors would score 1.0. This is load-bearing because accuracy preservation is a central claim in the abstract and introduction.
[Abstract, Section 1, Section 5.1, Table 1] The reported footprint reductions are internally inconsistent. The abstract claims 'up to 76%' reduction, Section 1 claims '3.28x smaller,' and Section 5.1 claims 'compression factors of up to 76%,' but Table 1 reports a single optimized model size of 8.48 GB versus 14.98 GB for the baseline, which is a 43% reduction (1.77x). No data in the paper support the 76% or 3.28x figures. Please reconcile these numbers or remove the unsupported claims.
[Section 3.2 and Section 5] Calibration data are described as 'small, unlabeled samples representing the query's input domain,' and the evaluation does not state whether accuracy is measured on rows held out from calibration. If the same distribution or rows are used, the reported accuracy scores partly reflect calibration fit rather than generalization. Please state whether the calibration and evaluation sets are disjoint, and if not, hold out rows for evaluation.
[Section 5 (Baseline and Configurations) and Table 1] The paper does not specify which compression techniques and hyperparameters (quantization bit-width, sparsity level, pruning ratio, calibration sample size) were applied to produce the IOLM-DB-Perf and IOLM-DB-Acc variants for each workload, nor how the two variants differ. This information is necessary to substantiate the claim that the optimization is query-specific and to make the results reproducible.

minor comments (6)

[Section 2] In the second paragraph of the Background section, the word 'abnd' appears to be a typo for 'and'.
[Section 3.1] In the Overview, the term 'quantification' should be 'quantization' to match the rest of the paper.
[Section 5.2] The statement that reengineering the pandas interface 'could significantly boost overall performance' and the expectation of 'one or two orders of magnitude performance improvements' is speculative and not tied to any measurement in the paper.
[Table 1] Throughput is reported as a single number per configuration with no variance or number of runs; adding error bars or stating the number of trials would strengthen the comparison.
[References] Several references appear in both arXiv preprint and published conference versions (e.g., [11], [12], [19]); please align the citation formats for consistency.
[Section 5 (Metrics)] The term 'Accuracy Score' is introduced without a formal definition beyond normalized baseline agreement; consider renaming it 'Normalized Agreement' to avoid implying absolute accuracy.

Circularity Check

1 steps flagged · score 6.0 of 10

Reported accuracy is defined as agreement with a baseline assumed perfect, so the claim of maintaining accuracy reduces to matching that baseline by construction.

self definitional [Section 5, Metrics; Table 1 caption; Section 5.1]
"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. ... 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."

The paper's 'Accuracy Score' is defined as normalized agreement with the baseline, not as correctness against ground truth. A score of 1 means 'same outputs as Llama-3.1-Instruct-8B on the evaluation data,' not 'correct results.' By definition, any compressed model that matches the baseline receives 1, independent of whether either model is correct. The conclusion that IOLM-DB 'maintains accuracy' is therefore not an empirical finding about correctness; it is the same statement as the metric's definition plus the unverified assumption that the baseline is perfect. The result is contained in the measurement setup by construction, so the accuracy-maintenance claim reduces to a baseline-agreement claim.

full rationale

The compression pipeline itself and the reported throughput and model-size improvements are independent empirical measurements and are not circular; there are no load-bearing self-citations. The one load-bearing circular step is the accuracy metric: the paper defines the accuracy score by normalizing against a baseline assumed to have accuracy 1, then cites a score of 1 as evidence of maintaining baseline-level accuracy. That conclusion is a restatement of the metric rather than a validated ground-truth result. Separately, the abstract's 'up to 76%' footprint reduction conflicts with Table 1's 8.48/14.98 GB (about 43%) reduction, and the evaluation never states that accuracy is measured on rows held out from calibration; these are validity and reporting concerns rather than derivation-level circularity.

Assumptions & free parameters 4 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new physical or mathematical entities. It relies on standard compression techniques with several hand-chosen but unreported hyperparameters, plus domain assumptions about OLAP predictability, calibration representativeness, and baseline perfection.

free parameters (4)

Quantization bit-width = 8-bit (reported in Section 3.2)
The paper states 8-bit weights and sometimes 8-bit activations; this is a hand-chosen compression level that determines the model size (8.48 GB observed).
Sparsity level = unreported
The paper claims sparsification but does not report the sparsity ratio used; the resulting throughput and accuracy depend on this.
Pruning ratio = unreported
Structural pruning is claimed via LLM-Pruner, but no layer or head removal counts or ratios are given; this affects model size and accuracy.
Calibration sample size and composition = unreported
Calibration data is described as 'small, unlabeled samples' (Section 3.2) but size and selection criteria are not specified; this drives the accuracy of the compressed model.

assumptions (4)

domain assumption The baseline Llama-3.1-Instruct-8B achieves perfect accuracy on the three workloads
Section 5 Metrics states 'we assume the baseline model achieves perfect accuracy (accuracy = 1)', which is the reference point for all accuracy comparisons.
domain assumption OLAP workloads and data distributions are predictable and can be inferred in advance, making per-query optimization worthwhile
Section 2 argues OLAP's controlled setting allows query patterns to be extracted in advance; this is necessary for the overhead of model generation to pay off.
domain assumption Calibration samples are representative of the query's input distribution
Section 3.2 uses calibration data to set quantization parameters and pruning thresholds; if unrepresentative, accuracy claims would not hold.
domain assumption vLLM and HuggingFace transformers provide correct and comparable inference for both baseline and compressed models
All measurements rely on these libraries; version differences could affect the numbers.

how reviews work

0 comments

Cite this review

Pith. "Pith review of The Case for Instance-Optimized LLMs in OLAP Databases." pith.science (2026). https://pith.science/paper/CSY7LI36

@misc{pith2026250704967,
  author       = {Pith},
  title        = {Pith review of: The Case for Instance-Optimized LLMs in OLAP Databases},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CSY7LI36}},
  note         = {Machine review of arXiv:2507.04967}
}

abstract

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$\times$ 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.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

24 extracted references · 12 canonical work pages

[1]

Brown, B

T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Ka- plan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sas- try, A. Askell, et al., Language models are few-shot learners, Advances in neural information processing systems 33 (2020) 1877–1901

2020
[2]

G. Team, R. Anil, S. Borgeaud, J.-B. Alayrac, J. Yu, R. Soricut, J. Schalkwyk, A. M. Dai, A. Hauth, K. Milli- can, et al., Gemini: a family of highly capable multi- modal models, arXiv preprint arXiv:2312.11805 (2023)

arXiv 2023
[3]

Touvron, T

H. Touvron, T. Lavril, G. Izacard, X. Martinet, M.-A. Lachaux, T. Lacroix, B. Rozière, N. Goyal, E. Hambro, F. Azhar, et al., Llama: Open and efficient foundation language models, arXiv preprint arXiv:2302.13971 (2023)

arXiv 2023
[4]

Bubeck, V

S. Bubeck, V. Chandrasekaran, R. Eldan, J. Gehrke, E. Horvitz, E. Kamar, P. Lee, Y. T. Lee, Y. Li, S. Lundberg, et al., Sparks of artificial general intelligence: Early ex- periments with gpt-4, arXiv preprint arXiv:2303.12712 (2023)

arXiv 2023
[5]

X. Li, T. Döhmen, Towards efficient data wrangling with llms using code generation, in: Proceedings of the Eighth Workshop on Data Management for End- to-End Machine Learning, 2024, pp. 62–66

work page 2024
[6]

Narayan, I

A. Narayan, I. Chami, L. Orr, S. Arora, C. Ré, Can foundation models wrangle your data?, arXiv preprint arXiv:2205.09911 (2022)

arXiv 2022
[7]

A. Q. Jiang, A. Sablayrolles, A. Mensch, C. Bamford, D. S. Chaplot, D. d. l. Casas, F. Bressand, G. Lengyel, G. Lample, L. Saulnier, et al., Mistral 7b, arXiv preprint arXiv:2310.06825 (2023)

arXiv 2023
[8]

Achiam, S

J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkat, et al., Gpt-4 technical report, arXiv preprint arXiv:2303.08774 (2023)

arXiv 2023

Show all 24 references

[9]

URL: https://www.anthropic

Anthropic, Claude, 2024. URL: https://www.anthropic. com/claude, large language model

2024
[10]

Egashira, M

K. Egashira, M. Vero, R. Staab, J. He, M. Vechev, Ex- ploiting LLM quantization, in: The Thirty-eighth An- nual Conference on Neural Information Processing Systems, 2024. URL: https://openreview.net/forum? id=ISa7mMe7Vg

2024
[11]

Frantar, D

E. Frantar, D. Alistarh, Sparsegpt: Massive lan- guage models can be accurately pruned in one- shot, ArXiv abs/2301.00774 (2023). URL: https://api. semanticscholar.org/CorpusID:255372747

2023 arXiv
[12]

X. Ma, G. Fang, X. Wang, Llm-pruner: On the structural pruning of large language mod- els, ArXiv abs/2305.11627 (2023). URL: https://api. semanticscholar.org/CorpusID:258823276

2023 arXiv
[13]

McKinney, et al., pandas: a foundational python library for data analysis and statistics, Python for high performance and scientific computing 14 (2011) 1–9

W. McKinney, et al., pandas: a foundational python library for data analysis and statistics, Python for high performance and scientific computing 14 (2011) 1–9

2011
[14]

Patel, S

L. Patel, S. Jha, C. Guestrin, M. Zaharia, Lotus: Enabling semantic queries with llms over tables of unstructured and structured data, arXiv preprint arXiv:2407.11418 (2024)

2024 arXiv
[15]

M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. D. O. Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brock- man, et al., Evaluating large language models trained on code, arXiv preprint arXiv:2107.03374 (2021)

2021 arXiv
[16]

Cambronero, S

J. Cambronero, S. Gulwani, V. Le, D. Perelman, A. Rad- hakrishna, C. Simon, A. Tiwari, Flashfill++: Scaling programming by example by cutting to the chase, Pro- ceedings of the ACM on Programming Languages 7 (2023) 952–981

2023
[17]

Q. Chen, A. Banerjee, Ç. Demiralp, G. Durrett, I. Dil- lig, Data extraction via semantic regular expression synthesis, Proceedings of the ACM on Programming Languages 7 (2023) 1848–1877

2023
[18]

Y. He, X. Chu, K. Ganjam, Y. Zheng, V. Narasayya, S. Chaudhuri, Transform-data-by-example (tde) an extensible search engine for data transformations, Pro- ceedings of the VLDB Endowment 11 (2018) 1165– 1177

2018
[19]

Frantar, S

E. Frantar, S. Ashkboos, T. Hoefler, D. Alistarh, Gptq: Accurate post-training quantization for generative pre-trained transformers, ArXiv abs/2210.17323 (2022). URL: https://api.semanticscholar.org/CorpusID: 253237200

2022 arXiv
[20]

X. Ma, G. Fang, X. Wang, Llm-pruner: On the struc- tural pruning of large language models, Advances in neural information processing systems 36 (2023) 21702–21720

2023
[21]

Frantar, S

E. Frantar, S. Ashkboos, T. Hoefler, D. Alistarh, Gptq: Accurate post-training quantization for generative pre- trained transformers, in: The Eleventh International Conference on Learning Representations, 2023

2023
[22]

G. Xiao, J. Lin, M. Seznec, H. Wu, J. Demouth, S. Han, Smoothquant: Accurate and efficient post-training quantization for large language models, in: Interna- tional Conference on Machine Learning, PMLR, 2023, pp. 38087–38099

2023
[23]

J. Ni, J. Li, J. McAuley, Justifying recommendations using distantly-labeled reviews and fine-grained as- pects, in: Conference on Empirical Methods in Natural Language Processing, 2019. URL: https://api. semanticscholar.org/CorpusID:202621357

2019
[24]

Hagiwara, M

M. Hagiwara, M. Mita, GitHub typo corpus: A large- scale multilingual dataset of misspellings and gram- matical errors, in: N. Calzolari, F. Béchet, P. Blache, K. Choukri, C. Cieri, T. Declerck, S. Goggi, H. Isa- hara, B. Maegaard, J. Mariani, H. Mazo, A. Moreno, J. Odijk, S. ...

2020

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.

[1] [1]

Brown, B

T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Ka- plan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sas- try, A. Askell, et al., Language models are few-shot learners, Advances in neural information processing systems 33 (2020) 1877–1901

2020

[2] [2]

G. Team, R. Anil, S. Borgeaud, J.-B. Alayrac, J. Yu, R. Soricut, J. Schalkwyk, A. M. Dai, A. Hauth, K. Milli- can, et al., Gemini: a family of highly capable multi- modal models, arXiv preprint arXiv:2312.11805 (2023)

arXiv 2023

[3] [3]

Touvron, T

H. Touvron, T. Lavril, G. Izacard, X. Martinet, M.-A. Lachaux, T. Lacroix, B. Rozière, N. Goyal, E. Hambro, F. Azhar, et al., Llama: Open and efficient foundation language models, arXiv preprint arXiv:2302.13971 (2023)

arXiv 2023

[4] [4]

Bubeck, V

S. Bubeck, V. Chandrasekaran, R. Eldan, J. Gehrke, E. Horvitz, E. Kamar, P. Lee, Y. T. Lee, Y. Li, S. Lundberg, et al., Sparks of artificial general intelligence: Early ex- periments with gpt-4, arXiv preprint arXiv:2303.12712 (2023)

arXiv 2023

[5] [5]

X. Li, T. Döhmen, Towards efficient data wrangling with llms using code generation, in: Proceedings of the Eighth Workshop on Data Management for End- to-End Machine Learning, 2024, pp. 62–66

work page 2024

[6] [6]

Narayan, I

A. Narayan, I. Chami, L. Orr, S. Arora, C. Ré, Can foundation models wrangle your data?, arXiv preprint arXiv:2205.09911 (2022)

arXiv 2022

[7] [7]

A. Q. Jiang, A. Sablayrolles, A. Mensch, C. Bamford, D. S. Chaplot, D. d. l. Casas, F. Bressand, G. Lengyel, G. Lample, L. Saulnier, et al., Mistral 7b, arXiv preprint arXiv:2310.06825 (2023)

arXiv 2023

[8] [8]

Achiam, S

J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkat, et al., Gpt-4 technical report, arXiv preprint arXiv:2303.08774 (2023)

arXiv 2023