Generative Monoculture in Large Language Models

## Abstract

Abstract We introduce generative monoculture , a behavior observed in large language models (LLMs) characterized by a significant narrowing of model output diversity relative to available training data for a given task: for example, generating only positive book reviews for books with a mixed reception. While in some cases, generative monoculture enhances performance (e.g., LLMs more often produce efficient code), the dangers are exacerbated in others (e.g., LLMs refuse to share diverse opinions). As LLMs are increasingly used in high-impact settings such as education and web search, careful maintenance of LLM output diversity is essential to ensure a variety of facts and perspectives are preserved over time. We experimentally demonstrate the prevalence of generative monoculture through analysis of book review and code generation tasks, and find that simple countermeasures such as altering sampling or prompting strategies are insufficient to mitigate the behavior. Moreover, our results suggest that the root causes of generative monoculture are likely embedded within the LLM’s alignment processes, suggesting a need for developing fine-tuning paradigms that preserve or promote diversity.

## 1 Introduction

Figure: Figure 1: (Left) Comparison of the range of average-per-book sentiment scores for book reviews generated by an LLM (gen) and by human reviewers from the Goodreads dataset (src). Note the generated reviews have a much smaller range, as they are overwhelmingly positive. Model: Llama-2-chat. (Right) The spectrum of the mean pairwise Jaccard similarity among the algorithms of coding solutions. Note the generated code covers a narrower range of algorithms. Model: GPT-4
Refer to caption: figs/fig_demonstration_sentiment_stacked_barchart_mean_personalized_llama-2-13b_T-0.8_P-0.9_full.png

Large language models (LLMs) show promise due to their emergent abilities [] and state-of-the-art performance on several NLP tasks []. However, concerns have been raised about the increasing reliance on LLM-based systems with insufficient testing, and how they impact society [, ]. Recent evidence has shown that LLMs have dangerous tendencies: they convincingly return incorrect information [, , ], produce toxic language [, ], and can effectively propagate misinformation [, ].

In this paper, we focus on a different concern: that for a given prompt and task, LLMs do not faithfully represent the diversity of potential responses available in their training data. We call this behavior *generative monoculture*: given some task (e.g., generating book reviews) and a data attribute (e.g. sentiment), generative monoculture refers to the narrowing of the probability distribution of the considered attribute from source data (i.e., available human-generated book reviews as part of the training data) to the generated data (i.e., LLM-generated book reviews).

As a preview, for book reviews (Fig. 1(Left)), we compare the diversity in sentiment of Goodreads reviews [] (i.e., src)—very likely a portion of LLM training data []—with LLM-generated reviews (i.e., gen). The range of mean sentiment scores per book across gen book reviews is much narrower than that in the src: in the experiment pictured, the average sentiment score for gen reviews are mostly over 0.85, whereas the the average sentiment score for src reviews over the same books have a wider range from zero to one. For the code generation task (Fig. 1(Right)), the range of algorithms employed in (correct) solutions to a given coding problem (i.e., gen) was much less varied than a sample of human answers (src) available on the web []: we show this through the range of Jaccard similarity of the algorithms employed in sets of human-generated (src) as well as LLM-generated (gen) responses to a coding prompt.

Through the rapid adoption of LLMs such as ChatGPT, CoPilot, and Devin across education, code generation, and day-to-day information gathering, generative monoculture can harm society through loss of information, creativity, and intellectual diversity. For example, students asking LLMs questions about class material to get help researching for an essay may have their opinions formed without exposure to a sufficiently wide subset of available information; this will allow for certain opinions to die out over time. Concretely, a reduction in diversity of sentiment displayed above may lead to the loss of arguments from negative opinions on controversial books, potentially crucial for historical or literary context or a nuanced understanding of a book’s contributions.

Generative monoculture could even lead to security threats, depending on the application: software engineers across the globe relying on ChatGPT and CoPilot receiving similar code generations which do not reflect the true diversity of methods to solve a given problem may lead to similar code vulnerabilities across several large tech companies. Indeed, as we preview in Fig. 1 and show in detail in § 6, LLM output exhibits are less diverse than human-generated solutions in the training data (e.g., by employing a narrower array of algorithms), which could lead to similarity across a wide range of code bases, leading in turn to repeated vulnerabilities [, ]. However, in this case, LLM outputs not reflecting the full diversity of available coding examples can be positive: LLM outputs over-represent correct and efficient solutions. We present a nuanced picture of generative monoculture: while it can highlight the optimal portion of human-generated data for some attributes, its pervasiveness across generation tasks and attributes may cause harm without careful intervention.

In this paper, we (1) define the concept of generative monoculture, and compare it to prior work around related topics (§ 2 and 3); (2) introduce a paradigm for measuring generative monoculture in LLMs (§ 4); (3) show experimental evidence for the prevalence of generative monoculture across a variety of application areas (book reviews and code) and (open-source and proprietary) LLMs, and provide some evidence for what may exacerbate generative monoculture, such as alignment tuning [], (§ 6 and 7); and (4) show the (in)efficacy of several methods to abate generative monoculture; namely,
changing temperature, sampling, and prompting techniques (§ 6 and 7).

## 2 Defining Generative Monoculture

We broadly characterize generative monoculture as a distribution shift from source data (i.e., human-generated training data) to model generated data (i.e., model outputs) for a specific task, such as generating reviews for books or solutions to coding problems. This can be formalized using measures of statistical dispersion applied to various task-specific attributes.

###### Definition 1 (Generative Monoculture) .

For a given task, let $\mathcal{P}_{\texttt{src}}$ denote the probability distribution of the source data, $\mathcal{P}_{\texttt{gen}}$ denote the probability distribution of the LLM-generated data, $h$ denote a function extracting attributes from data (such as sentiment, or algorithms used in code), and $\text{Dispersion}(\cdot)$ denote a dispersion metric (e.g., entropy). Then we define generative monoculture as the condition where $\mathcal{P}_{\texttt{gen}}$ is statistically narrower than $\mathcal{P}_{\texttt{src}}$, namely: $\text{Dispersion}(h(x)|x\sim\mathcal{P}_{\texttt{gen}})<\text{Dispersion}(h(x)|x\sim\mathcal{P}_{\texttt{src}})$.

Note, $\mathcal{P}_{\texttt{src}}$/ $\mathcal{P}_{\texttt{gen}}$ can be the distribution of human-generated/model-generated responses, for a given task, conditioned on one specific given prompt (which we refer to as the conditional distribution), or the distribution of human-generated/model-generated responses for any possible prompt in a considered domain (which we call the unconditional distribution).

This phenomenon signifies a shift towards less varied outputs. We emphasize that the investigation of generative monoculture is intrinsically task-dependent, as the attributes of interest differ across tasks. In addition, as we often do not have access to the source distribution in practice, we approximate it using a source dataset ($D_{\texttt{src}}$), comprised of a subset of the training data of the LLMs we consider. Similarly, we approximate the generated distribution through a dataset generated by the model ($D_{\texttt{gen}}$).

Generative Monoculture, Human Preference, and Alignment: Generative monoculture can cause LLMs to over-emphasize human-preferred areas of a distribution for a certain data attribute; this is often desired behavior. For example, as we demonstrate in § 7, generative monoculture can result in having a narrower distribution of code correctness or efficiency biased towards correct, fast, and low-memory code. We conjecture this is a consequence of alignment procedures such as reinforcement learning with human feedback (RLHF) [].

However, when a tendency stemming from human preference bleeds beyond its intended use—e.g., a preference for positive sentiment affecting outputs that need not or should not be positive—these seemingly advantageous behaviors can prevent an equally important goal: maintaining diversity of human opinion and expression. Further, along data
attributes which do not have a clear preferred area of the distribution, generative monoculture can limit the scope of methods, topics, or ideas expressed.

###### Definition 1 (Generative Monoculture) .

## 3 Related Work

Diversity and LLMs. Santurkar et al. [] demonstrate that LLMs do not give representative opinions to polling questions when compared to the general U.S. population. Our work focuses on the narrowing of diversity in LLM output from its human-generated training data—while Santukar et al. demonstrate a narrowing in diversity from actual human survey respondents (and not training data). Additionally, our work proposes a general framework for measuring monoculture. Padmakumar and He [] demonstrate that using LLM assistance can lead to reduced diversity in human-generated argumentative essays when compared to essays written without LLM assistance. While they mention that this is partially because the models themselves do not produce diverse output, they do not focus on the narrowing of diversity from LLM training data to LLM-generated data. Finally, Sorensen et al. [] outline an alignment framework to emphasize *pluralism*, to work towards creating models which express a variety of opinions and perspectives. While this is certainly related to our work, generative monoculture as a phenomenon extends beyond differences in opinion, and expresses the narrowing of any number of task-specific attributes, from code correctness to topics covered to many others. One common thread across many of these works, which our work adds to, is that current alignment practices—namely RLHF— harms output diversity.

Other Notions of Monoculture.
Our notion of generative monoculture relates to, but differs from, other notions of monoculture in the AI literature.
For example, algorithmic monoculture [] and outcome homogeneity [] describe the societal state where many decision-making actors rely on the same underlying algorithms to generate (classification or ranking) predictions, from the perspective of decision-making actors and individuals subject to those decisions respectively. These works show that algorithmic monoculture is sub-optimal for both decision-making actors (due to correlated failures across models) and for those subject to model decisions, as repeated outcomes across models leave little room for algorithmic recourse. In contrast, generative monoculture focuses on documenting the phenomenon of individual LLMs narrowing the diversity of their output in relation to their source data—for example, only returning positive book reviews about a controversial book.
We do, however, document in this work that generative monoculture exists to similar extents and in similar directions across a variety of available LLMs, (e.g., Llama, Vicuna, ChatGPT-4) leaving open the possibility of concerns brought up by Kleinberg and Raghavan [], but in a generative context.

## 4 Measuring Generative Monoculture

We outline a general approach to measuring generative monoculture in LLMs. In particular, following Definition 1, we outline steps to construct $D_{{\texttt{src}}}$ and $D_{{\texttt{gen}}}$ and compare their diversity through extracting data attributes and calculating dispersion metrics. We illustrate our approach in Fig. 2.

### 4.1 Data Curation

For a given task, we aim to create a source dataset that is likely to have been used in training the LLM we wish to investigate. Training data for most LLMs is a closely guarded secret. While recent work [] describes how dataset contamination can be determined, such approaches are (a) riddled with false positives, and (b) computationally expensive. Thus, we often take an educated guess (based on dataset popularity and ease of use) in ascertaining if a given dataset is a likely training dataset candidate.

Formally, we define the source dataset as $D_{{\texttt{src}}}=\{q_{i},{\texttt{src}}_{i}\}_{i\in[N]}$ where (a) $q_{i}$ is a problem instance within a task (e.g., name of a book for which a review has to be written), and (b) ${\texttt{src}}_{i}=\{{\texttt{src}}_{i}^{j}\}_{j\in[n_{i}]}$ is a set of $n_{i}$ human-generated answers to the given prompt $q_{i}$ (e.g., a set of $n_{i}$ of book reviews for that particular book). In practice, we utilize existing datasets likely to be used during LLM training, and perform filtering and sub-sampling to obtain our $D_{\texttt{src}}$.

To create the model-generated dataset $D_{\texttt{gen}}$, for each sample $q_{i}$, we prompt the LLM we wish to evaluate, ${\mathcal{M}}$, $m_{i}$ times to generate a set of responses, ${\texttt{gen}}_{i}=\{{\texttt{gen}}_{i}^{j}\}_{j\in[m_{i}]}$. Here, ${\texttt{gen}}_{i}^{j}\leftarrow{\mathcal{M}}_{j}(P_{\text{task}}(q_{i}),\texttt{kwargs})$ is the response obtained in the $j$-th call of ${\mathcal{M}}$, where (a) $P_{\text{task}}$ denotes the task-specific formatting prompt that wraps the sample $q_{i}$, and (b) kwargs denotes the generation keyword arguments (e.g., temperature) that specify the sampling strategy.
Across both $D_{{\texttt{src}}}$ and $D_{{\texttt{gen}}}$, we select or generate a large enough number of responses per $q_{i}$ to ensure variety.

### 4.2 Attribute Extraction

For a given task, we identify and compile a list of attributes that are of interest from the perspective of preserving diversity. This is a subjective task, but we focus on metrics which target understanding the content of LLM output (e.g., book review sentiment and topic; code time complexity and algorithms used), as opposed to more general metrics of output language quality such as saliency, fluency and coherence. More importantly, we need to ensure that extraction functions are efficient, accurate, and reproducible—we outline our tests to ensure these qualities in § 6 and the Appendices B and D. For example, care must be taken to use LLMs for attribute extraction, as they are known to be biased towards their own responses []. For a given attribute $A$, extraction function $h_{A}$ takes a string tgt to obtain the attribute value $h_{A}({\texttt{tgt}})$. Note that tgt can either be ${\texttt{src}}_{i}^{j}$ or ${\texttt{gen}}_{i}^{j}$. The extracted attribute can either be a continuous/categorical variable or of other more complicated types, depending on the nature of the attribute.

Figure: Figure 2: An overview of the procedure.
Refer to caption: figs/procedures.png

### 4.3 Metric Calculation

As the last step, we compute metrics on the extracted attributes. Given a set of responses, dispersion metrics aim to capture their breadth or coverage of these attributes. We describe those used in this paper below and in Fig. 3.

Dispersion Metrics. We introduce dispersion metrics suited to different data types.

A. Distribution of the mean.
For ordinal or continuous attributes, we calculate the mean over the conditional distribution—that is, we calculate the metrics over each ${\texttt{src}}_{i}$ or ${\texttt{gen}}_{i}$ (e.g. reviews for a given book), and show the distribution of this mean over all $q_{i}$ for a certain task (e.g. over all books). While the mean itself does not directly measure dispersion, the distribution of the mean values sheds light on dispersion: concentrated mean values indicates a smaller dispersion of the data.
The advantage is that it not only describes dispersion, but also the qualitative tendency of the attribute (e.g. bias towards positive/negative sentiment), which cannot be captured otherwise.

B. Entropy and standard deviation. For categorical attributes, we measure dispersion using entropy over the conditional distribution. For continuous attributes, we use standard deviation over the conditional distribution to quantify the dispersion of values around the mean, providing the attribute’s variability.

C. Mean pairwise similarity. For attributes that are not easily characterized as categorical or continuous, we adopt specific similarity metrics catered to the data type. We then calculate the pairwise similarity values for the conditional distribution—i.e. calculate the mean similarity value for all the pairs of elements within each ${\texttt{src}}_{i}/{\texttt{gen}}_{i}$, then show the distribution for all $N$ samples. We use:

- 1.
Mean pairwise Jaccard index: Given two sets of categorical variables $A$ and $B$, the Jaccard index, $J(A,B)=\nicefrac{{|A\cap B|}}{{|A\cup B|}}$, measures similarity between them.
An example of such a set could be a set of several algorithms inferred from a piece of code.
A higher mean Jaccard index indicates a higher overall similarity between the set, and consequently, lower dispersion.
- 2.
Mean pairwise cosine similarity: Given two multi-dimensional embeddings $e_{1}$ and $e_{2}$ obtained via a sentence embedder [], we calculate their similarity via cosine similarity, i.e., $S_{C}(e_{1},e_{2})=\nicefrac{{\langle e_{1},e_{2}\rangle}}{{\|e_{1}\|\|e_{2}\|}}$. A higher mean cosine similarity indicates a higher similarity and lower dispersion.
- 3.
Mean pairwise fingerprint similarity: For tasks related to coding or computer programs, similarity is based on the overlap of selected hash values (or fingerprints) generated by Winnowing []. We adopt an existing open-source tool CopyDetect [], which takes in a set of programs and returns the pairwise similarity scores for all programs in the set. We then calculate the mean value of these pairwise similarity scores as an indicator of the similarity for the set of programs. A higher mean fingerprint similarity indicateshigher structural and syntactical similarity of the code.

In addition to the dispersion metrics, we consider one other approach—visualizing the top modes of unconditional distributions for certain attributes, e.g., topics.
This helps identify areas of emphasis in src and gen distributions, as well as the tendency of change across distributions.

## 5 Mitigating Generative Monoculture

To attempt to mitigate generative monoculture, we test four methods known to increase LLM output diversity: increasing the *temperature* $T$, top-$p$ parameter, setting a temperature decay, and changing prompts. More details are in Appendices A and C.6.

Temperature $T$. This determines the dispersion of the probability distribution over the next token: increasing the temperature leads to a more flat probability distribution and increases the likelihood of sampling from less probable tokens, resulting in more diverse generations.

Top-$p$. This controls the randomness of the generations by limiting the range of tokens considered. Specifically, it considers the smallest subset (consisting of the top probability tokens) whose cumulative probability exceeds the threshold $p$. A smaller $p$ encourages the model to sample from a more focused set of likely tokens.

Decaying Temperature. We choose the starting temperature $T=10.0$ and follow a linear schedule for temperature decay, over the course of $50$ time-steps (i.e., from the $1$-st output token to the $50$-th output token), with an ending temperature $T=1.2$. The method is inspired by Carlini et al. [].

Prompts. Tuning the specific content and framing of the prompt can steer the model’s output more effectively [, ] and significantly impact the diversity of the generated text. We use “role-playing” or impersonation [], which instructs the model to produce the output in the persona of a specific person, and expect it to induce more personalized and varied responses.

## 6 Experimental Setup

In this section, we describe our experimental setup for measuring and mitigating generative monoculture for two tasks, namely, generating book reviews and code solutions. We provide details for datasets, LLMs used, and most notably, the data attributes and metrics considered.
We open source our code at [https://github.com/GeMoLLM/GeMO](https://github.com/GeMoLLM/GeMO).

### 6.1 Generating Book Reviews

Data Curation: For $D_{\texttt{src}}$, we use the Goodreads dataset [], which contains multiple books with several reviews each. We perform filtering and sampling to ensure reliable attribute extraction (see Section B.1), and craft a final dataset of $N=742$ books with English titles, and $\forall i,n_{i}=10$ reviews per book such that the review length is between 300 and 700 words.

Figure: Figure 3: A summary of the scenarios, the attributes we consider, their data types, and the corresponding analysis levels as well as metrics. C and U stand for conditional and unconditional distributions.

To obtain $D_{\texttt{gen}}$, we used the following LLMs: (a) Llama-2-13b [] (henceforth referred to as Llama-2), (b) Llama-2-13b-chat [] (henceforth referred to as Llama-2-chat), (c) Vicuna-13b-v1.5 [] (henceforth referred to as Vicuna-13b), (d) GPT-3.5-turbo-instruct (0914) [] (henceforth referred to as GPT-3.5), and (e) GPT-4-turbo (0125) [, ] (henceforth referred to as GPT-4). We performed nucleus sampling [] with various sampling parameters: (a) temperature $T\in\{0.5,0.8,1.0,1.2,1.5\}$, and (b) top-$p\in\{0.90,0.95,0.98,1.00\}$. We also experimented with two candidates for $P_{\text{task}}$: prompt (1) “Write a personalized review of the book titled {title}:”, and prompt (2) “Write a book review for the book titled {title} as if you are {person}:”. Prompt (2) was chosen as LLMs are known to generate more diverse responses when instantiated with a persona []. We list the names of the 10 persons we considered in Section B.2. For each combination of LLM, sampling parameter, and prompt, we independently sampled from the LLM 10 times to generate responses. We filtered out low-quality (generated) reviews by examining their perplexity (see Section C.1). This is to ensure that the data used for analysis represents well-formed and coherent text, thereby improving the reliability of our findings. Thus, $\forall i,m_{i}\leq 10$.

Attribute Extraction: We want attributes that capture both the semantics and syntax of book reviews. These attributes are representative of the key thematic and linguistic elements in book reviews. Most importantly, while these attributes are not exhaustive, their extraction is reliable and efficient.

- 1.
Sentiment indicates whether a review is positive (praising the book) or negative (criticizing the book). We employ a fine-tuned sentiment classifier [] as the attribute extractor which accepts a text and returns a prediction in $\{0,1\}$. This model has been downloaded 5.4 million times in May 2024, and reaches an accuracy of 91.3 % on the dev set of SST-2 [].
- 2.
Topic refers to the themes discussed in a review [, ].
We leverage BERTopic [] pre-trained on Wikipedia [] which assigns one topic to each review out of a total of $\sim$2,000 topics.
- 3.
Word choice captures the lexical diversity in a review. To quantify this, we produce a frequency table of the unique words (see Section B.3), and immediately have the number of unique words.

Metric Calculation: For sentiment, we calculate mean and entropy for the conditional distribution.
For topic, we calculate entropy for the conditional distribution as well as visualize the unconditional distribution of topics across all reviews, focusing on the top $10$ classes. Finally, for word choice, we calculate count and entropy of the unconditional distribution.

### 6.2 Generating Code Solutions

Data Curation: For $D_{\texttt{src}}$, we chose the CodeContests dataset [], a competitive programming problem dataset where each problem comes with multiple correct and incorrect solutions. We limited the scope to a subset ($N=100$) of level-A problems (easy problems) on Codeforces [], and the language of the solutions to python3. More details in Section D.1. For each problem in the subset, we randomly sampled $\forall i,n_{i}=20$ correct solutions from all of the $n^{\text{correct}}_{i}$ solutions for that problem.

To obtain $D_{\texttt{gen}}$, we use the following LLMs: (a) GPT-4, and (b) Claude-3-Sonnet []. We did not use open-source LLMs, as these were not able to generate correct solutions for the problems we chose. More details are in Section E.4. We performed nucleus sampling [] with various sampling parameters: (a) temperature $T\in\{0.5,1.0\}$, and (b) top-$p\in\{0.9,1.0\}$. We used only one candidate for $P_{\text{task}}$ i.e., “Please read the below problem description and generate a python code to solve the problem {problem description} Please only generate code and nothing else.” While we experimented with providing the LLM with a persona i.e., asking the LLM to pretend to be a “grandmaster in solving competitive programming problems”, the resulting accuracy was lower (see Section E.2). For each combination of LLM, sampling parameter, and prompt, we produce $\forall i,m_{i}\geq 20$ generations such that at least 20 of the generated solutions were correct (details in Section D.2). We instantiated this by generating $k$ samples ($k=100$ for GPT-4 and $k=200$ for Claude-3), and verifying that at least 20 of them were correct.

Attribute Extraction:
We consider the following attributes which characterize different aspects of code. We rely on GPT-3.5 for extracting some of the attributes; we manually verified the extracted attributes and confirmed their quality is high (see Section E.3).

- 1.
Correctness refers to whether a piece of code correctly solves the given problem and passes all the test cases.
We measure accuracy as the ratio of correct solutions among all solutions (details in Section D.3), to quantify the quality of human-/model-generated solutions.
- 2.
Efficiency is crucial for scalability []. This is measured through: asymptotic time/space complexity and runtime efficiency. We prompt GPT-3.5 to infer the big $O$ time and space complexity [], and execute the code on test cases to measure runtime and memory usage (see Section D.4).
- 3.
Fingerprint provides insights into the structural and syntactical uniqueness of each code segment. As stated in Section 4.3, we use the CopyDetect tool for this.
- 4.
Code Summary (textual) explains the functionality of the code. Prior work has demonstrated the effectiveness of GPT-3.5 in code understanding []. Thus, we use it to produce text-based summaries, and a description, functionality, algorithm, and data structure (prompt for this task is in Section D.5). To compare the similarity for these text summaries, we produce their embeddings using the all-MiniLM-L6-v2 model [].
- 5.
Code Summary (categorical)
reflects the techniques employed in the code through categorical tags, as used on the Codeforces website. We prompt GPT-3.5 to assign tags to a code segment by providing it a set of tags to choose from (prompt for this task is in Section D.5). We obtain one set per code segment.
We similarly prompt GPT-3.5 to choose from a list of algorithms and data structures.

Metric Calculation: For correctness, we calculate the mean value i.e., accuracy over the conditional distribution. For efficiency (asymptotic complexity), we calculate: (a) entropy for the conditional distribution, and (b) plot the histogram for the unconditional distribution. For runtime efficiency, we calculate mean and standard deviation for the conditional distribution. We measure the following over the conditional distribution: fingerprints, where we calculate the mean pairwise fingerprint similarity; code summary (textual), where we calculate the mean pairwise cosine similarity in their embedding space, and code summary (categorical), where we calculate the mean pairwise Jaccard index.

## 7 Results and Takeaways

Figure: Figure 4: (a-c) stacked barplots for the mean sentiment scores under varying sampling parameters, prompts, and models. For these plots, in each bar, darker hues (bottom) represent lower scores while lighter one (top) denote higher scores. See the legend for the value range of each hue. In subfigure (b), (1) and (2) refer to the two prompts as introduced in Section 6.1. In subfigure (c), (a-c) refer to Llama-2-chat, Vicuna-13b, and Llama-2. (d) kernel density estimation (KDE) for the entropy values calculated on the conditional distribution of the topics. (e) unconditional topic distribution for top-10 topics. For all the subfigures, we mark the sampling parameters in them; unless marked with (1-2) or (a-c), the results are obtained on Llama-2-chat under prompt (1). These subfigures show that the model-generated reviews are overwhelmingly positive and cover a narrower range of the topics per book; moreover, there is distinctive under- and over-representation of the topics covered overall.
Refer to caption: figs/legend_fade.png

Guide: We present our results on measuring, and attempting to mitigate, generative monoculture in Fig. 4 and  5. We display results mainly in three formats: (a) stacked bar charts, where different hues correspond to different value ranges as indicated in the legend; (b) histograms (or grouped bar charts), to reflect the probability mass of a categorical variable; and (c) kernel density estimation (KDE) plots, to reflect the estimated probability density of a continuous variable. We note that, in the code results, for all plots except that evaluating accuracy, we restrict to correct solutions.

Takeaway 1: Monoculture Exists and is Severe, Within and Across LLMs.
As shown in Fig. 4 and 5, there exists significant narrowing from the source to generation distribution in all attributes considered for both scenarios, book reviews and coding.

Notably, for book review, proprietary OpenAI LLMs (GPT-3.5 and GPT-4) demonstrate even more severe monoculture compared with the open-source Llama family LLMs (see Fig. 9 in Section C.5 for more details).
Particularly, for both GPT-3.5 and GPT-4, 100% of the samples have average positivity falling in (0.95,1.00] under prompt (1), and 98.9% and 97.6% under prompt (2).
For coding, similar reductions in diversity can be seen: in Fig. 5(e), we see increased similarity in natural language descriptions of LLM-generated code solutions, and Fig. 5(f) shows the Jaccard similarity of the generated solutions in terms of the inferred algorithms, with the majority of problems displaying high similarity across generated solutions.
Of particular interest, the plagiarism scores of the LLM-generated code are extremely high (Fig. 5(b)), compared to the source solutions which achieve an utterly zero plagiarism score for all the problems.
We examine a few pairs of examples and their plagiarism scores in Section E.1.

Takeaway 2: LLMs tend to produce Human-favorable Generations. Our results show that LLMs tend to over-represent parts of the attribute distribution that are preferred by humans: humans largely prefer text with positive sentiment, as well as correct and efficient code. Fig. 4(a) and Section C.5 show that LLMs produce overwhelmingly positive generations. Fig. 5, as well as Fig. 21 and  22 in the Appendix reveal that LLM-generated code segments (a) are over $2\times$ more accurate than the average human solutions, (b) enjoy an overall lower asymptotic time and space complexity, and (c) use less runtime and memory during execution. This may just be the intended consequence of RLHF, which explicitly optimizes the LLM towards producing human-favored responses in its objective, as guided by a reward model trained on human preferences.

However, as our results show, this implies a loss of diversity guided by human preferences, which, if only naively understood and enforced, could lead to unwanted consequences if going unnoticed. One example of the unintended artifacts is the under- and over-represented topics (Fig. 4(e)); the topic group 15 which contains keywords “rob” and “kill” etc. is significantly under-represented, likely a consequence of RLHF alignment tuning.

Figure: Figure 5: (Left) (a) stacked barplot for accuracy and (b) probability mass along with KDE for plagiarism scores. (Middle) Time complexity: (c) histogram of the (unconditional) distribution of the asymptotic complexity and (d) probability mass for the (conditional) distribution of entropy values. (Right) Selected code summary: (e) KDE plot for the mean pairwise cosine similarity scores for “description” as natural language and (f) stacked barplot for the mean pairwise Jaccard scores for “algorithms” as categorical values. Overall, the model-generated solutions are more accurate and efficient, display higher description similarity to each other, and cover a narrower span of algorithms. (More results in Section E.5.)
Refer to caption: figs/legend_jaccard_fade.png

Takeaway 3: RLHF Hurts Diversity the Most. Llama-2-chat is obtained via performing RLHF tuning [] on the pre-trained (PT) Llama-2. Similarly, Vicuna-13b is obtained via supervised fine-tuning (SFT) on the PT Llama-2 []. Comparisons on these LLMs (see Fig. 4(c), as well as Fig. 8 in Section C.4) show that the PT LLM-generated reviews are much more similar to the source. The PT LLM Llama-2 has 5.9% of samples with average sentiment values falling in the range of (0.95,1.00], which is much closer to the source percentage of 2.8% than 44.7% for Vicuna-13b and 82.1% for Llama-2-chat.
Vicuna-13b also shows better diversity than Llama-2-chat—this is consistent with findings suggesting RLHF reduces output diversity compared with SFT (albeit with different metrics) [].

Takeaway 4: Naive Mitigations are Insufficient. Changing the sampling parameter (increasing $T$ and $p$) and using a more diversity-inducing prompt (e.g., prompt (2) for book reviews) can reduce the gap (see Fig. 4(a-b) and Fig. 5). For example, using prompt (2) reduces the percentage of the most positive range from 82.1% to 58.1% in Fig. 4(b) for $T=1.2,p=1.0$.
However, the gap is still large.
More results in Appendix (Figures 12 and 13, and Appendix E) show similar conclusions.

**Table 1: The average fraction of valid generations (out of a total of 10) for two models under various sampling parameters (temperature, top-$p$, and prompt–denoted (1) and (2)). We regard a “valid” generation as text of perplexity value $\leq$ 20—as a support, we present high perplexity samples in Section C.1. We observe that the number drops as the randomness increases (along the increase of both $T$ and top-$p$ values). As a reference, GPT-4 achieves an average ratio of 1.000 at $T=1.2$ and $p=1.0$.**
| LLama-2<br>-13b-chat<br>$p=0.90$<br>$p=0.95$<br>$p=0.98$<br>$p=1.00$<br>(1)<br>(2)<br>(1)<br>(2)<br>(1)<br>(2)<br>(1)<br>(2)<br>$T=0.5$<br>1.000<br>1.000<br>1.000<br>1.000<br>1.000<br>1.000<br>1.000<br>1.000<br>$T=1.0$<br>1.000<br>1.000<br>0.999<br>1.000<br>0.999<br>1.000<br>0.998<br>0.999<br>$T=1.5$<br>0.994<br>0.988<br>0.930<br>0.883<br>0.743<br>0.649<br>0.512<br>0.394<br>Vicuna<br>-13b<br>$p=0.90$<br>$p=0.95$<br>$p=0.98$<br>$p=1.00$<br>(1)<br>(2)<br>(1)<br>(2)<br>(1)<br>(2)<br>(1)<br>(2)<br>$T=0.5$<br>0.987<br>0.992<br>0.987<br>0.990<br>0.984<br>0.989<br>0.984<br>0.988<br>$T=1.0$<br>0.961<br>0.962<br>0.951<br>0.958<br>0.942<br>0.953<br>0.935<br>0.947<br>$T=1.5$<br>0.871<br>0.903<br>0.835<br>0.876<br>0.766<br>0.840<br>0.680<br>0.767 |
| --- |

We attempted two other strategies: (a) picking a higher temperature, and (b) leveraging a decaying temperature scheme (see § 5). Results in Section C.2 show that the gap still remains big even at such high randomness. Furthermore, for larger $T$, we notice a significant degradation of the generation quality as a result of the increased randomness.
In Table 1, we present the average fraction of valid generations for Llama-2-chat and Vicuna-13b under various sampling parameters. The table shows that the valid number of generations rapidly drops as the randomness increases, particularly at $T=1.5$; the implication is that such a high randomness setting cannot be adopted for practical use.

Though prior work showed promise for decaying temperature to encourage diversity while maintaining quality [], this too failed to achieve higher diversity (see Fig. 4(d) and Section C.6).

## 8 Conclusion and Limitations

In this work, we introduce the concept of generative monoculture, a phenomenon where LLMs narrow the diversity of their output relative to their source data for a given task. We experimentally demonstrate its prevalence across text and code generation tasks, and show the difficulty in mitigating the behavior.
Our work has limitations: first,
we did not analyze the full training set of the LLMs we study due to time and compute restrictions, as the corpora are large and often proprietary. Further, as we note in § 4, measuring monoculture is difficult as selecting attributes is subjective, and the attribute extraction process is sensitive to the reliability of extraction techniques. (We verify our own attribute extraction techniques in the appendix). Further, while generative monoculture itself can have unfair consequences by enforcing the suppression of minority opinions, mitigating monoculture without extreme care could lead to the proliferation of harmful ideas or even toxicity by allowing for representation of the entire distribution of source text. We look forward to future work mitigating monoculture while maintaining low levels of toxicity and other dangerous behavior.

## Appendix

We open source our code at [https://github.com/GeMoLLM/GeMO](https://github.com/GeMoLLM/GeMO).

## Appendix A Sampling Parameters

1. Temperature: Concretely, the temperature parameter $T$ determines the “dispersion” of the probability distribution over the next token. Mathematically, the probability of a token $w$ being generated is given by the softmax function: $P(w|x)=\frac{\exp(s(w|x)/T)}{\sum_{w^{\prime}}\exp(s(w^{\prime}|x)/T)}$
where $s(w|x)$ is the unnormalized log-probability of the token $w$ given the context $x$. Increasing the temperature leads to a more flat probability distribution and increases the likelihood of sampling from less probable tokens, resulting in more diverse generations. This can also be understood from the perspective of entropy of the next token, $H(W)=-\sum_{w}P(w|x)\log P(w|x)$,
where it can be seen that the increase of entropy directly follows.

2. Top-$p$: The top-$p$ parameter [] ($p\in(0,1]$) controls the randomness of the generations by limiting the range of tokens considered. Specifically, it considers the smallest subset (consisting of the top probability tokens) whose cumulative probability exceeds the threshold $p$. A smaller $p$ encourages the model to sample from a more focused set of likely tokens, while a larger $p$ allows sampling from a broader range and thus increases randomness ($p=1$ basically means no restriction on the vocabulary).

Different platforms have different default values for $T$ and top-$p$. GPT-3.5-turbo-instruct (0914) web version adopts $T=0.8$ []. The default values in OpenAI APIs are $T=1.0$ and $p=1.0$ [].

3. Generation Length: This parameter (max_new_tokens) dictates at most how many tokens the model should generate before it stops. We used 500 for book review generation and 2048 for code generation.

## Appendix B Additional Details: Book Reviews

### B.1 Construction of the Source Dataset

To ensure we picked popular books that the LLMs know about, we filtered the books according to the number of reviews they have. Constraining the number of reviews to be between 1,000 and 2,500, we obtained 750 books. We further filtered out books with non-English titles; we conducted this filtering because some downstream LLMs (e.g., sentiment classifiers) are not multilingual, and as a result can not analyze the generated non-English reviews. To ensure high quality of the reviews, we further filtered the review by length, constraining the length of each review to be between 300 and 700 words. After this step of filtering, we sampled 10 reviews per book. Eventually, we obtained a dataset of 742 books, where each book comes with 10 reviews.

### B.2 Names of the Celebrities Used in Prompt 2

We prompted GPT-4 to provide a list of celebrities suitable for writing diverse book reviews. The list of names are as follows: Trevor Noah, Janelle Monáe, Yuval Noah Harari, Serena Williams, Reshma Saujani, Neil deGrasse Tyson, Margaret Atwood, David Attenborough, Malala Yousafzai, Jordan Peele.

### B.3 Text Processing for Analyzing Wording Choice

We first concatenated all documents and converted them to lowercase to standardize the text. We then expanded contractions (e.g., “don’t” to “do not”). We then tokenize the text with word_tokenize() from the NLTK library [], and removed the punctuation. We continued by filtering out non-alphabetic tokens to focus solely on words. Lastly, we lemmatized tokens via WordNetLemmatizer() to their base forms, aiding in consistent frequency analysis. These steps are essential for minimizing textual noise and ensuring the reliability of our word frequency assessments.

## Appendix C Additional Results: Book Reviews

### C.1 Filtered-out Reviews

We established a perplexity threshold of 20 to filter out low-quality reviews.
To validate our choice, we randomly sampled reviews with perplexity scores at different intervals and manually inspected them.
For clarity, instead of presenting the entire review text, we selectively extracted chunks that exemplified the low-quality nature of the sampled reviews.

### C.2 Generation Results at Higher Randomness

We experimented with even higher randomness at $T=1.5$ motivated by the observation that increasing the randomness does help to increase the diversity. However, as we show in Fig. 6, even at high randomness, there is still a huge gap between the source and the generations.

Moreover, we notice a significant degradation of the generation quality as a result of the increased randomness. We present in Table 1 the average number of valid generations for two models under various sampling parameters.
The table shows that the valid number of generations rapidly drops as the randomness increases, particularly at $T=1.5$; the implication is that such a high randomness setting basically cannot be adopted for practical use.

Figure: Figure 6: Mean sentiment scores across different models (Llama-2-chat, Vicuna-13b) and prompts ((1) and (2)), and varying sampling parameters (temperature $T$ and top-$p$). We do observe an increase of diversity along the increase of generation randomness (i.e., increasing $T$ and $p$), but the gap remains high between the source and even the highest generation randomness setting. Moreover, we put a black cross $\times$ on the top of the setting with a concerning low number of valid number of generations (see Table 1 for a concrete explanation); they mostly only occur for the few highest randomness settings.
Refer to caption: figs/legend_fade.png

### C.3 Topic Shifts

We present in Fig. 7 the results of the unconditional topic distribution.
Across all three settings for comparison, we observe highly similar distribution shift signified by the over- and under-representation of certain topic groups.
Concretely,
the topic group 15 with the keywords “grace, rob, nick, anna, house, discovers, realizes, killed, confronts, killer” are under-represented, potentially because certain words like “rob” and “kill” are eliminated from the output as a result of RLHF.
On the other hand, the topic group 333 with the keywords “handmaid, novels, novel, writers, tale, book, books, literary, novellas, synopsis”
and the topic group 666 with the keywords
“nonfiction, bestseller, novelist, autobiography, novels, memoir, author, memoirs, paperback, novel” are over-represented.
The over-representation of topic group 333 in Vicuna-13b is much more severe than Llama-2-chat, as can be seen from the 3rd subfigure; this could be because a higher exposure to relevant materials during its fine-tuning.

Figure: Figure 7: Grouped bar charts of the unconditional distribution of the topic (i.e., the distribution of the topic over all the samples). (Left): generated by Llama-2-chat at different generation kwargs, where we fixed $T=1.2$ and varied $p\in\{0.90,0.95,0.98,1.00\}$. The prompt used is (1) as introduced in Section 6.1. (Middle): generated by Llama-2-chat under different prompts (1) and (2). (Right): generated by two models (a) Llama-2-chat and (b) Vicuna-13b, using the prompt (1). Across all three subfigures, we observe highly similar distribution shift signified by the over- and under-representation of certain topics.
Refer to caption: figs/fig_legend_topic_entropy.png

### C.4 Pre-trained Model

The aligned model is obtained from performing supervised fine-tuning followed by RLHF alignment tuning on the basis of the pre-trained model [].
We compare the performance of the aligned model llama-2-13b-chat with the pre-trained model llama-2-13b and present the results in Fig. 8.

Figure: Figure 8: Comparison between (a) the aligned model Llama-2-chat and (c) the pre-trained model Llama-2, under prompt (1), temperature $T=1.2$, and varying top-$p$ parameters. We present a subset of the results (sentiment, topic, and topic distribution), corresponding to Figure 7. The figures show that the pre-trained model enjoys much better diversity than the aligned model, and is much closer to the source.
Refer to caption: figs/legend_fade.png

From the 1st and 2nd subfigure, we observe that the pre-trained model is much more diverse than the aligned model; the pre-trained model is even very close to the source data (see the dark purple result tagged as $T=1.2,p=1.0$ (c)).

The 3rd subfigure delivers two messages. First of all, there still exists divergence from the pre-trained model and the source in terms of the covered topics.
We attribute this divergence we observe between the pre-trained model and the source data to the difference between the source data we use (the Goodreads dataset) and the ground-truth training data (a much broader corpus which we have no information about).
We regard the Goodreads dataset as a proxy of the ground-truth, but intrinsically Goodreads is smaller and does not fully accurately represent the groundtruth training distribution, especially in nuanced attributes like the unconditional topic distribution measured on all samples.
Second, the direction and trend of changes in the aligned model is not completely the same as the aligned models, e.g., the topic group 15 containing “rob” and “killer” is not inhibited as much as in the aligned models, potentially due to RLHF.

### C.5 Results of OpenAI models

Figure: Figure 9: Plots for OpenAI models. (Upper row): GPT-3.5 under prompt (1), $T=1.2$, and varing $p$. (Lower row): comparing GPT-3.5 and GPT-4 at $T=1.2,p=1.0$ and the two propmts (1) and (2). We present a subset of the results (sentiment, topic, and topic distribution), corresponding to Figure 7. The figures show that both GPT-3.5 and GPT-4 display severe GeMo, which cannot be effectively mitigated via varying the sampling parameters or using a diversity-inducing prompt.
Refer to caption: figs/legend_fade.png

We repeat the same set of experiments on the proprietary OpenAI models GPT-3.5-turbo-instruct (0914) and GPT-4-turbo (0125). We present the results in Fig. 9.

The sentiment results (in column 1) suggest that both models are overwhelmingly and invariably positive in their reviews, across various sampling parameters and prompts.

The results of the conditional topic distribution (in column 2) reveal similar conclusions—there is a significant deviation between the generated reviews and the source reviews across varying sampling parameters (see upper low) and for both GPT-3.5-instruct and GPT-4 (see lower row). Nevertheless, using a diversity-inducing prompt, i.e., prompt (2) does lead to increased diversity (see lower row).

The results of the unconditional topic distribution (in column 3) also demonstrate the distribution shift, though in a slightly different way than observed for llama family models (see presented in Section C.3). Concretely, the topic group 333 does not experience a significantly over-representation, while the topic group 30 does. As discussed previously, we attribute the difference in the nuanced topic distribution mainly to the difference in the training data.

### C.6 Mitigation via temperature decay

We describe the decaying temperature scheme. Concretely, we choose the starting temperature $T=10.0$ and follow a linear schedule for temperature decay, over the course of $50$ timesteps (i.e., from the $1$-st output token to the $50$-th output token), with an ending temperature $T=1.2$.
The method is inspired by Carlini et al. [] which reported this scheme as one sampling method that induce diversity and high quality output(^1^11We refer to [https://github.com/shreyansh26/Extracting-Training-Data-from-Large-Langauge-Models/blob/main/extraction_temperature_decay.py](https://github.com/shreyansh26/Extracting-Training-Data-from-Large-Langauge-Models/blob/main/extraction_temperature_decay.py) for an implementation of the temperature decay sampling scheme for HuggingFace models.).

Figure: Figure 10: Effect of temperature decay during decoding time for two models Llama-2-chat and Vicuna-13b, with top-$p$ parameter 1.0 and two prompts (1) and (2). We compare the fixed temperature ($T=1.2$) with the decaying temperature (decay $T$) and we present the results for sentiment and topic. The figures reveal the ineffectiveness of the temperature decay method.
Refer to caption: figs/legend_fade.png

We present the results in Fig. 10. For both the sentiment and the topic, we see that the fixed temperature scheme achieves a higher diversity compared to the decaying temperature scheme.

### C.7 More Results

Figure: Figure 11: Heatmap of the entropy of the (unconditional) distribution of the word choice in model-generated reviews. We present results of two models (Llama-2-chat and Vicuna-13b) and two prompts ((1) and (2)). As a reference, the entropy of the source is 9.99, higher than all the entropy values of model generations.
Refer to caption: figs/wordfreq_entropy_personalized_llama-2-13b-chat_500.png

Figure: Figure 12: (Row 1): Stacked bar charts of the mean sentiment scores. In each bar, darker hues (bottom) correspond to the lower scores while the lighter hues (upper) are the higher scores. See the legend for the detailed value range of each hue. (Row 2): Histograms of the entropy of the sentiment scores. Each bar group corresponds to a range of entropy values in $[x,x+0.2]$ where $x$ is the number under the bar group. (Row 3): Kernel density estimate (KDE) plots of the entropy of the topic. (Left): generated by Llama-2-chat at different generation kwargs, where we fixed $T=1.2$ and varied $p\in\{0.90,0.95,0.98,1.00\}$. More variations can be found in Figure 6 in Appendix C. The prompt used is (1); see later for the detail. (Middle): generated by Llama-2-chat under prompts (1) and (2). (Right): generated by two models (a) Llama-2-chat and (b) Vicuna-13b, using the prompt (1).
Refer to caption: figs/legend_fade.png

Figure: Figure 13: (Rows 1-2): varying $T$ under fixed $p$: (upper) entropy of the sentiment for the conditional distribution and (lower) Entropy of the topic for the conditional distribution. (Rows 3-4): varying $p$ under fixed $T$: (upper) entropy of the sentiment for the conditional distribution and (lower) entropy of the topic for the conditional distribution. Results are obtained via Llama-2 under prompt (1).
Refer to caption: figs/fig_legend_entropy_more_1.png

**Table 2: Count of unique words produced by different models (left: llama-2-13b-chat, right: GPT-3.5-instruct) under varying sampling parameters and prompt (1). As a reference, the count in the source dataset is 85,334.**
| $p=0.90$<br>$p=0.95$<br>$p=0.98$<br>$p=1.00$<br>$T=0.5$<br>18,900<br>19,041<br>19,145<br>19,275<br>$T=0.8$<br>20,020<br>20,516<br>20,935<br>21,688<br>$T=1.0$<br>21,295<br>22,024<br>23,181<br>24,738<br>$T=1.2$<br>23,509<br>25,742<br>28,532<br>33,908 | $p=0.90$<br>$p=0.95$<br>$p=0.98$<br>$p=1.00$<br>$T=0.5$<br>15,782<br>15,794<br>15,778<br>15,841<br>$T=0.8$<br>16,563<br>16,915<br>17,096<br>17,235<br>$T=1.0$<br>17,044<br>17,543<br>17,960<br>18,674<br>$T=1.2$<br>17,368<br>18,077<br>18,894<br>21,059 |
| --- | --- |

For the attribute word choice, we present the count of unique words in Table 2 and the entropy for the word distribution in Fig. 11, showing that model-generated reviews use a narrower vocabulary and is less diverse than the human-written reviews.

We present more results for various attributes and metrics in Fig. 12 and 13 where we vary several factors for detailed comparisons.
Overall, the results suggest the prevalence and severity of generative monoculture, as well as the ineffectiveness of naive mitigations.

## Appendix D Additional Details: Coding

### D.1 Restriction to Level-A Problems

We limit our scope to Codeforces level-A problems only for the coding scenario, which are the easiest problems on the Codeforces competitive programming platform(^2^22[https://codeforces.com/problemset](https://codeforces.com/problemset)).
We note that even though these are the easiest problems on the platform, they still require non-trivial intellectual efforts to solve(^3^33Interested readers can refer to this problem [https://codeforces.com/problemset/problem/1198/A](https://codeforces.com/problemset/problem/1198/A) to get a sense of the difficulty in problem understanding and solving).

There are two main reasons we restrict to level-A problems:

- 1.
Most LLMs perform best on level-A problems and much worse on more difficult ones. We started off evaluating a set of 81 problems ranging from difficulty A to G, and obtained an average accuracy of 50% on the 16 level-A problems, and less than 10% on others. Since we perform attribute extraction on the correct solutions only, a low accuracy means that to ensure reaching a minimum number of correct generations (20 in our experiments), a huge number of solutions need to be generated (e.g., over 200), which is prohibitively expensive in both time and money.
Thus we settle with the level-A problems.
- 2.
We manually verify the correctness of the attribute extraction (e.g., code summary, runtime complexity). Relatively simpler problems are easier to verify.

### D.2 Correctness Testing: Autojudge with Testcases

We simulated an Autojudge using the test cases provided in the dataset. Concretely, for each problem, we obtain 10 test cases in the format of input and output(^4^44In Codeforces, each test case is often consisted of multiple small tests; see an example at [https://codeforces.com/problemset/problem/1406/A](https://codeforces.com/problemset/problem/1406/A). As explained in the Input section on the page, “The input consists of multiple test cases.”. Thus, 10 test cases is adequate in testing the correctness of a solution).
We then measure each solution against the set of 10 test cases.
We regard the solution that passes all 10 test cases as a correct solution.

### D.3 Measuring Accuracy

We calculate accuracy as $n^{\text{correct}}_{i}/n_{\text{all}}$ per problem (where $n^{\text{correct}}_{i}$ is the number of correct solutions and $n_{\text{all}}$ is the number of all solutions).
For the source, both $n^{\text{correct}}_{i}$ and $n_{\text{all}}$ are available in the CodeContests dataset [].
For the generations, we test the correctness of the solutions via autojudge (see Section D.2) and measure the accuracy as ${n^{\text{correct}}_{i}}/{k}$.

### D.4 Measuring Runtime Efficiency

For runtime efficiency, we use the bash command /usr/bin/time [] to measure the elapsed real time (via %E) as well as the maximum resident set size of the process during its execution (via %M).
Concretely, for each solution, we run it on all 10 test cases with our autojudge and measure the runtime and memory.
We take the max value on all 10 test cases as a proxy of the runtime efficiency of the tested code.

### D.5 Prompting GPT-3.5 to Generate Code Summary (both Text Descriptions and Categorical Values)

We present below the instruction we provide to GPT-3.5.
We bold keywords in the prompt simply for the ease of reading.
When calling the GPT-3.5 API, we used temperature $T=0$ (i.e., greedy decoding) and max_tokens=500.

The list of tags (in the 1st prompt below) were collected from the CodeContests [] dataset—we traverse all the problems in the dataset and union all the “tags” attribute.

The lists of algorithms and data structures (in the 2nd prompt below) were obtained from analyzing Wikipedia and querying GPT-4-turbo (0125) for a suggested list.

These categorical attributes serve as a complement to the text description described above and enhance the reliability of the results.

## Appendix E Additional Results: Coding

### E.1 Examples for Plagiarism Scores

Figure: Figure 14: An example for a pair of model generated code with high plagiarism score.
Refer to caption: figs/fig-plagiarism-ex-1.png

Figure: Figure 15: An example for a pair of model generated code with relatively low plagiarism score.
Refer to caption: figs/fig-plagiarism-ex-2.png

Figure: Figure 16: An example for three human-written code with zero plagiarism score for all the pairs.
Refer to caption: figs/fig-plagiarism-ex-3.png

We present example model-generated code and human-written code as well as the plagiarism scores associated with the pairs in Fig. 14, 15,and 16.
All the code are correct solutions to the problem 409A. The Great Game(^5^55Link to the problem: [https://codeforces.com/problemset/problem/409/A](https://codeforces.com/problemset/problem/409/A)).

From the demonstrations it is evident that model-generated code (Fig. 14, 15) are highly similar in their style and structure; even the low score pair (Fig. 15) bear a significant level of similarity. In comparison, human-written code (Fig. 16) are clearly distinctive.
These results support the validity of using the plagiarism score to evaluate code similarity.

### E.2 Attempts on Varying Prompts

Figure: Figure 17: Four prompts for instructing the model GPT-4 to generate code solution to a provided problem in {problem_description}. Prompt 1 is the most plain prompt; Prompt 2 additionally instructs the model to generate only the code without additional explanations; Prompt 3 employs the technique of role-playing [], and Prompt 4 additionally integrates the technique of chain-of-thought prompting [].

We experimented with four prompts on GPT-4, one plain prompt, one instructing the model to generate only the code solution, one employing role-playing [] and one integrating chain-of-thought prompting [].
We present the concrete prompts in Fig. 17.

We evaluate the four prompts on Codeforces problems of varying difficulties and present the accuracy achieved by each prompt in Fig. 18.
Overall, prompt 2 achieves the best results among the four.

Figure: Figure 18: Accuracy achieved by using the four prompts on Codeforces problems of varying difficulties. The “Correct” and “Incorrect” refer to the results achieved by the human-written solutions in the source dataset CodeContests. Overall, we see that prompt 2 performs the best across different difficulty levels.
Refer to caption: figs/fig_code_gpt4_vary_prompts.png

### E.3 Human annotations for the quality of LLM summary

We annotate the quality of the LLM-generated summary of code given by GPT-3.5.

Step 1:
We randomly sample 20 solutions of different problems, and review the LLM-generated attributes for these solutions; the attributes include the textual ones (description, functionality, algorithm, data structure), the inferred asymptotic complexity (time complexity, space complexity), as well as the categorical ones (tags, algorithm, data structures).

Step 2:
We read through the problem description, the code solution, and the model-generated summary to evaluate the quality of model-generated summary.

Step 3:
We follow the instruction “In each cell please give a score from 1-3 – 3 meaning absolutely correct, 2 meaning with some minor errors but acceptable, 1 meaning entirely incorrect” to score each attribute.

Step 4:
We calculate the average score received by each attribute across the 20 sample and present the results in Table 3.

The high scores indicate that GPT-3.5 can provide fairly accurate summary of the given code, supporting our choice of relying GPT-3.5 to reliably extract the attributes.

**Table 3: The average scores given by human annotators on each attribute. We adopted a 3-point scale where 3 means absolutely correct, 2 means with some minor errors but acceptable, 1 means entirely incorrect. The high scores indicate that GPT-3.5 can provide fairly accurate summary of the given code.**
| Attribute | textual | complexity | categorical |  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| description | functionality | algorithm | data<br>structure | time<br>complexity | space<br>complexity | tags | algorithms | data<br>structures |  |
| Score | 2.65 | 2.55 | 2.90 | 3.00 | 2.95 | 2.70 | 2.90 | 2.50 | 2.90 |

### E.4 Failure results with open-source models

We experimented with two open-source code models on these competitive programming problems: CodeLlama [](^6^66Link at [https://huggingface.co/codellama/CodeLlama-13b-Instruct-hf](https://huggingface.co/codellama/CodeLlama-13b-Instruct-hf)) and StarCoder [](^7^77Link at [https://huggingface.co/bigcode/starcoder](https://huggingface.co/bigcode/starcoder)).
However, neither of the models were able to produce code solutions in our trials. We present one example interaction in Fig. 19, where the model demonstrated the memorization of a problem dataset but failed to produce a code solution to the given problem.

Figure: Figure 19: Generation result of StarCoder. The model was unable to generate the requested code solution as instructed; instead, it generated some boilerplate content such as input format and output format, which often exists in datasets of this kind of problems. After these boilerplate content, the model simply generated hundreds of $\backslash$n and then stopped.

### E.5 A Complete Set of Results for the Experiments on GPT-4

Accuracy The histogram of the accuracy can be found in Fig. 20(left).

Plagiarism score The histogram along with the KDE plot for the plagiarism scores can be found in Fig. 20(right).

Efficiency The efficiency results in terms of the asymptotic complexity (specifically, the histogram of the time complexity and space complexity) can be found in Fig. 21.
The efficiency results in terms of the runtime efficiency (specifically, the density plots of runtime and memory) can be found in Fig. 22.

Code summary The KDE plots of the mean pairwise embedding cosine similarity of the code summary (textual) can be found in Fig. 23.
The stacked bar plots of the mean pairwise Jaccard similarity of the code summary (categorical) can be found in Fig. 24.

Figure: Figure 20: Model: GPT-4. (Left) Stacked bar charts of the accuracy values achieved by the source solutions as well as GPT-4 generated solutions under various kwargs. (Right) Histogram plus kernel density estimation (KDE) plots of the plagiarism scores.
Refer to caption: figs/legend_jaccard_fade.png

Figure: Figure 21: Model: GPT-4. (Left) Histograms (or grouped bar charts) for the time and space complexity for the unconditional distribution. (Right) Histograms for the entropy of the time and space complexity for the conditional distribution. The figures suggest that the generated code is more efficient than the source code, while showing a decrease in diversity.
Refer to caption: figs/fig_legend_text_cossim.png

Figure: Figure 22: Model: GPT-4. Histograms of the mean and standard deviation (std) of runtime (in milliseconds) and memory usage (in kilobytes). We filtered out some datapoints for better visualization, specifically, runtime above 200 ms, and memory usage above 30,000 KB.
Refer to caption: figs/fig_legend_text_cossim.png

Figure: Figure 23: Model: GPT-4. Kernel density estimation (KDE) plots of the mean pairwise cosine similarity for the four attributes (description, functionality, algorithm, and data structure) represented as extracted embeddings of natural language descriptions.
Refer to caption: figs/fig_legend_text_cossim.png

Figure: Figure 24: Model: GPT-4. Stacked bar charts of the mean pairwise Jaccard index for the three attributes (tags, algorithms, and data structures) represented as sets of categorical variables.
Refer to caption: figs/legend_jaccard_fade.png

### E.6 Claude

Figure: Figure 25: Model: Claude-3-Sonnet. (Left) Stacked bar charts of the accuracy values achieved by the source solutions as well as Claude generated solutions under various kwargs. (Right) Histogram plus kernel density estimation (KDE) plots of the plagiarism scores for source solutions and Claude generated solutions.
Refer to caption: figs/legend_jaccard_fade.png

Figure: Figure 26: Model: Claude-3-Sonnet. (Left) Histograms (or grouped bar charts) for the time and space complexity for the unconditional distribution. (Right) Histograms for the entropy of the time and space complexity for the conditional distribution. The figures suggest that the generated code is more efficient than the source code, while showing a decrease in diversity.
Refer to caption: figs/fig_legend_text_cossim.png

Figure: Figure 27: Model: Claude-3-Sonnet. Histograms of the mean and standard deviation (std) of runtime (in milliseconds) and memory usage (in kilobytes). We filtered out some datapoints for better visualization, specifically, runtime above 200 ms, and memory usage above 30,000 KB.
Refer to caption: figs/fig_legend_text_cossim.png

Figure: Figure 28: Model: Claude-3-Sonnet. Kernel density estimation (KDE) plots of the mean pairwise cosine similarity for the four attributes (description, functionality, algorithm, and data structure) represented as extracted embeddings of natural language descriptions.
Refer to caption: figs/fig_legend_text_cossim.png

Figure: Figure 29: Model: Claude-3-Sonnet. Stacked bar charts of the mean pairwise Jaccard index for the three attributes (tags, algorithms, and data structures) represented as sets of categorical variables.
Refer to caption: figs/legend_jaccard_fade.png

Accuracy The histogram of the accuracy can be found in Fig. 25(left).
In comparison to GPT-4 (see Fig. 20(left)), the accuracy of Claude-3 is much lower.

Plagiarism score The histogram along with the KDE plot for the plagiarism scores can be found in Fig. 25(right).
The plagiarism scores achieved by Claude-3 remain high, similarly to that on GPT-4.

Efficiency The efficiency results in terms of the asymptotic complexity (specifically, the histogram of the time complexity and space complexity) can be found in Fig. 26.
The efficiency results in terms of the runtime efficiency (specifically, the density plots of runtime and memory) can be found in Fig. 27.
Different from GPT-4, solutions generated by Claude-3 are less efficient than source solutions.
This result, together with the accuracy result, indicates that the code generation ability of Claude-3 is inferior than GPT-4.

Code summary The KDE plots of the mean pairwise embedding cosine similarity of the code summary (textual) can be found in Fig. 28.
The stacked bar plots of the mean pairwise Jaccard similarity of the code summary (categorical) can be found in Fig. 29.
Similar to GPT-4, Claude-3 also demonstrate a narrower range of expressed ideas.

## Appendix F Additional Details for Experiments

### F.1 Compute

The book review generation ($N=742$, $n=10$, max_new_tokens=500) on open-source models took around 10 hours on one H100 card per run, i.e., per combination of sampling parameters ($T$ and $p$) and prompts.
The number increased to around 80 hours for GPT-4.

The code generation ($N=100$, $n=100$, max_new_tokens=2048) on GPT-4 took around 60 hours per run.
The rate of generation was similar on Claude-3-Sonnet; the total runtime doubled since we generated twice many solutions ($n=200$) due to its lower accuracy.

### F.2 Licenses

We used the Goodreads dataset [](^8^88Link to the dataset website: [https://mengtingwan.github.io/data/goodreads.html](https://mengtingwan.github.io/data/goodreads.html)) for the book review scenario.
Their license is Apache License(^9^99Link to the license: [https://github.com/MengtingWan/goodreads/blob/master/LICENSE](https://github.com/MengtingWan/goodreads/blob/master/LICENSE)) as provided in their repository.

We used the CodeContests dataset [](^10^1010Link to the dataset: [https://github.com/google-deepmind/code_contests](https://github.com/google-deepmind/code_contests)) for the coding scenario.
Their license is Apache License(^11^1111Link to the license: [https://github.com/google-deepmind/code_contests/blob/main/LICENSE](https://github.com/google-deepmind/code_contests/blob/main/LICENSE)) as provided in their repository.

## Peer Reviews

confidence: 4
contribution: 2
initial_rating: 5
presentation: 2
questions: I would like authors to comment on feedback loop effects. How do they anticipate monoculture evolving as LLMs are increasingly used to generate their own training data in feedback loops ? Do they think this will further exacerbate the monoculture effect. What strategies and/or guardrails do the authors suggest to mitigate this very long term "model collapse" situation ?

Authors could also further comment on composition of training data. Would increased diversity play a role in mitigating feedback loops and how can LLM training incorporate such diversity. 

Lastly, what role model size plays ? Have authors ablated along model size/complexity dimension ?
soundness: 2
strengths: This paper highlights a critical issue in LLMs around narrowing of output diversity compared to the training data. The paper addresses an important problem esp when LLMs are being increasingly applied in diverse fields such as automated product reviews, sentiment analysis, scholarly paper summarization etc. The paper demonstrates the prevalence of narrowing of output diversity, which they refer to as 'generative monoculture'. They consider book reviews and code solutions as two primary use cases to study the narrowing phenomenon. 
The paper tests various methods to mitigate 'monoculture', including temperature adjustment and prompting strategies. 

The paper provides a well-structured methodology for measuring generative monoculture, including diverse metrics like entropy, mean pairwise similarity and other such metrics. 

The paper discusses the impact of narrowing of output diversity on the societal and code security aspects. These discussions strengthens the paper.
summary: This paper addresses the critical issue of "generative monoculture" in large language models (LLMs), where output diversity narrows compared to training data. This is particularly concerning as LLMs are increasingly used in diverse applications like product reviews, sentiment analysis, and scholarly summarization. The study focuses on book reviews and code solutions to demonstrate this phenomenon and tests various mitigation strategies, such as temperature adjustment and prompt engineering, though with limited success.
weaknesses: While the paper tests various methods to mitigate 'monoculture', including temperature adjustment and prompting strategies, the attempted countermeasures showed limited efficacy in mitigating narrowing of output diversity. This warrants more experimentation and ideation. I would also think use cases/tasks other than book reviews and code generation should be investigated to test the generalizability of the method. Dialogue / chat bot as an application may be an important area to test these methods on. The inability to redefine the alignment process limits the degrees of freedom with which one could operate. I would have liked to see a bit broader scope that covers alignments and comparing the dispersions to alignment data rather than the training data of CPT. 

Rich getting richer / Echo Chamber / Feedback loops are commonly studied phenomenon in recommender system literature. Methods like Bandits and Exploration/Exploitation are commonly used to mitigate the homogeneity of recommended items over time. Authors have an opportunity to connect to this rich work and draw inspiration from this field.

---

confidence: 5
contribution: 4
initial_rating: 1
presentation: 3
questions: 1. What was `{person}` replaced with in the prompt?
2. I do not understand the method used to generate correct solutions for the coding task. Specifically, I did not understand this sentence (line 309): We instantiated this by generating k samples (100 for GPT-4 and 200 for Claude-3), and verifying that at least 20 of them were correct." What did you do if it wasn't the case that 20 were correct? Does your sampling method here ensure then that "correctness" will never fall below 20%?
soundness: 2
strengths: The main idea of this paper is very interesting, and I am glad the authors have done this exploration. The authors have done a good job of discussing nuances around the merits of diversity, and I appreciate their selection of two complementary domains where the value of having diversity is quite different.
summary: The main idea of this paper can be summarized in the following toy example: if 90% of humans say that chocolate is tasty, should language models *always* describe chocolate as tasty, or should they aim to somehow reflect the diversity in human opinions, and occasional refer to chocolate as bad-tasting?

The authors apply this thought experiment to two domains---book reviews and code implementation---and analyze the various ways in which language models enforce a monoculture by failing to model the diversity present in actual human-written content. Adding more entropy into the decoding pipeline helps a bit, but does not meaningfully bring diversity to human levels.

The authors include an interesting discussion of the scenarios in which diversity is desirable--for example, generated book reviews ought to reflect the range of opinions real reader mights have on said books---and the scenarious where diversity might be less important---for example, it is more important for generated code to be correct than to be diverse.
weaknesses: ## Primary weakness - incomplete description of methodology
Unfortunately, it is not possible to assess this paper as it was submitted because crucial information required to understand and reproduce the methodology is purported to be in the appendix, but no appendix was included in the submission. Since the paper is incomplete, there is no choice but to give a score of 1 (strong reject). Despite this, I have tried to leave some constructive feedback below for the authors.

## LLMs for attribute extraction
Line 163 states that "care must be taken to use LLMs for attribute extraction, as they are known to be biased towards their own responses." It seems like this care was taken for the sentiment classifier (the paper notes the classifier's accuracy on SST-2 and it's widespread usage). However, the same care does not seem to have been taken for the "efficiency" attribute, which uses gpt-3.5 to assess runtime efficiency of generated code. It is unclear why a reader should trust that gpt-3.5 is efficient and unbiased at this task.

## Takeaway #2

Line 393 states that humans "largely prefer text with positive sentiment." Is this actually true? In a 5 minute literature review, I found several papers such as the two listed below which suggest a much more complex story. Needless to say, statements such as this one should not be made without citation.

Sangwon Park, Juan L. Nicolau. Asymmetric effects of online consumer reviews, ISSN 0160-7383, (https://www.sciencedirect.com/science/article/pii/S0160738314001273).

Lotte M. Willemsen, Peter C. Neijens, Fred Bronner, Jan A. de Ridder. “Highly Recommended!” The Content Characteristics and Perceived Usefulness of Online Consumer Reviews, (https://academic.oup.com/jcmc/article/17/1/19/4067647).

## Takeaway #3

Takeaway #3 claims RLHF hurts diversity more than any of the other factors did. This claim would be much stronger if it had been backed by experiments with more than just one pair of models. I would like to see additional experiments with other model pairs (for example instruction-tuned and RLHF'ed OLMO). Otherwise, a caveat should be added to this claim about the limitation of the result.

## Nitpicks

Here are a few nitpicks (which wouldn't much affect my overall assessment).
1. I am not a fan of the phrase "human-generated." It is extremely atypical to talk about a human generating a book review or generating some code (unless the speaker wants to imply the human is using genAI tools); rather, in common parlance, humans **write** book reviews and **write** code. I suggest replacing instances of "human-generated" with "human-written."
2. I think the paper would be more engaging to read if the description of the attributes of interest was moved before the section on metric calculation (Section 3.3). Section 3.3 felt out of place to read when I didn't yet know what exactly the attributes were for each domain. 
3. Figure 4 has too much information in it, which impeded communication. It would be more effective to break this into multiple figures each with their own caption. In particular, the (a), (b) and (c) in the middle bar graph are especially confusing since (a), (b) and (c) are also used to refer to subfigures. Can you instead put shorthands for the actual names of the models? Also, for the topic model I am confused why the word 'novels' occurs in two groups. 
4. For Figure 5, an easier-to-understand x-axis label for the top-right plot would be "Self-similarity" rather than "Similarity."
5. One additional paper citation for the first paragraph of your Related Work section ("Forcing Diffuse Distributions out of Language Models" https://arxiv.org/abs/2404.10859).
6. Many of the references are formatted incorrectly with missing capitalization in the paper titles.

---

confidence: 4
contribution: 3
initial_rating: 8
presentation: 3
questions: None beyond what was raised in weaknesses
soundness: 3
strengths: The paper formalizes the idea of “monoculture”. This idea isn’t wildly novel–it’s intuitive and consistent with other similar ideas such as mode collapse–but to my knowledge there isn’t a clean documentation of it and thus the paper has value in being an official cite for this phenomenon

The authors focus on measuring monoculture using task-specific notions of salient attributes (e.g., sentiment in book reviews, algorithms in code) which differs meaningfully from measures that use e.g., vocabulary of generations. I think this distinction is meaningful as it's a better measure of the type of distribution shift that will matter in practice if GenAI is widely deployed.
summary: The paper defines and documents the problem of “generative monoculture” in LLMs – that is, the situation in which LLMs produce outputs that are significantly less diverse that what was present in their input training data. The authors focus on diversity over task-specific and intuitive metrics – specifically, the sentiment of book reviews or the algorithms employed in generated code. This is in contrast to measuring over some more systematic but arguably less informative metric such as lexical distributions. The authors find that, across models, the problem of generative monoculture is present and argue that it seems to get worse for models which are “aligned” to human preferences via RLHF.

I really like this paper. It's a nice, intuitive idea that deserves to be highlighted. I think the study was executed well for the most part but would have preferred to see some human evaluations, rather than solely automatic ones. But I think despite this, it warrants publication in the current form.
weaknesses: My primary concern is that the evaluation focuses entirely on automatic metrics. Granted, there are many metrics that the authors use, and they are somewhat diverse. Still, many of the metrics rely on using LLMs themselves (mostly GPT 3.5) to evaluate LLM output. There is something circular (though hard to articulate) about doing this especially given the premise of the paper itself. That is: if we assume LLMs are not good at generating diverse outputs, might we also worry that they aren’t good at recognizing such diversity? Or, said differently, why are we confident that the collapse is due to actual differences in what the LLMs produce, and not differences in what the LLM evaluator can detect? 

To address this, I think the paper should include some evaluations which are determined entirely by human judgments. I.e., ask humans to rate the sentiment rather than asking LLMs to do so, ask humans to evaluate the big-O complexity rather than having GPT do it, etc. I would be dramatically more convinced if the conclusions held up under human eval, rather than just automatic eval. But, admittedly, I do expect the result to hold even if all evaluations were switch to human eval.

---

confidence: 4
contribution: 3
initial_rating: 6
presentation: 3
questions: * Can the authors explain what they mean on line 309: “We instantiated this by generating k samples [...], and verifying that at least 20 of them were correct.” Does this mean 20 samples were checked, and 80 were not? 
* Can the authors provide a reference that shows that humans prefer positive reviews, to support take-away 2?
soundness: 3
strengths: * **Interesting quantification of generic monoculture:** As the authors also mention in their related work section, the idea that current alignment practices hurt diversity is not necessarily new. However, this work presents a new way of measuring this, which gives additional insights in the output of (aligned) LLMs.
* **Considerations (pros and cons) of approach are clearly presented, and largely make sense:** The authors clearly mention their considerations for adopting their chosen methodology, in a space where they sometimes had to make some shortcuts or assumptions. For example regarding their data selection and their used metrics.
* **Authors present negative results, that are insightful:** The presented mitigation strategies do not really help, but this is an insightful finding for the community.
summary: This paper introduces the concept of “generative monoculture”, which refers to the phenomena that an LLM's output distribution is less diverse than the original input (data) distribution.
Generative monoculture is investigated on two tasks: generating book reviews, and generating coding solutions, across multiple LLMs.
The monoculture is measured with a number of metrics (depending on the task): distribution of the mean, entropy and standard deviation, and mean pairwise similarity.
The authors find that monoculture exists across the LLMs that are investigated. The authors propose several mitigations, such as changing the sampling parameters, or diversifying the prompts, but this has little impact.
weaknesses: * **Investigated datasets are not very large.** This holds especially for the code solutions, where the data is limited to a subset of 100 easy solutions. Although this gives a first impression, I wonder how results hold over larger data samples, and especially when harder problems are included as well.
* **Coding solutions are checked by GPT-3.5.** The authors give some details in the appendix of the autojudge, but it is not entirely clear to me how quality is ensured. After all, GPT-3.5 needs to check the results of a stronger model (GPT-4) and, as the authors also mention elsewhere in the paper, LLMs tend to be biased towards their own responses.

---

confidence: 4
contribution: 2
initial_rating: 5
presentation: 4
questions: Q1: Could the authors explain how the plagiarism score is computed in Figure 5 (b)? It seems is not mentioned in paper.
soundness: 2
strengths: Generative monoculture is a subtle phenomenon that may not be immediately noticeable to users but can have a lasting impact on society, making it an important area of study. The paper is well-written and clearly presented.
summary: The paper investigates generative monoculture in LLMs, defined as the reduction in diversity from training data to the model’s outputs. It examines this phenomenon in two tasks: sentiment of book reviews and code generation. The paper found consistent monoculture in all experiments.
weaknesses: W1: One major risk in this study is that measuring generative monoculture with “a source dataset that is likely to have been used in training the LLM we wish to investigate” (line 128) could introduce substantial inaccuracies. This approach risks significant biases, undermining the validity of the measurements. I will elaborate below and hope the authors could discuss these risks and present evidence to support validity of their approach.

W1-1: First, the selected source data may not actually be part of the LLM’s training data.

W1-2: Even if the selected source dataset is indeed in the training data, it may not represent the full range of relevant training data. For instance, other sources or non-English reviews of the same books could dominate the distribution from training data, meaning that the measured distribution may not reflect the true distribution of the training data at all. This concern is especially relevant since the study uses relatively small datasets (742 books with 10 reviews per book for book reviews and 100 coding questions with 20 correct solutions each for code).

W1-3: Additionally, the filtering of the source dataset introduces biases. The authors mention in Appendix B2 that book reviews are filtered to be between 300-700 words. Filtering by length could affect the sentiment distribution, potentially skewing the results. 

W2: Could the authors clarify why they filter out low-quality (generated) book reviews by examining perplexity? While low-quality reviews may seem less helpful to users, excluding them might introduce bias in the sentiment distribution of LLM-generated book reviews. I recommend testing whether this filtering step influences the measured sentiment distribution, although it might be preferable to retain these low-quality reviews to avoid introducing additional bias.

W3: To strengthen the study’s validity, I suggest measuring generative monoculture in a more controlled environment, where the training data is known and the training distribution can be accurately measured. Without certainty that the source dataset is part of the training data, all findings are at risk of being unreliable.

W4: In Line 317, the efficiency of LLM generated code is measured by ``prompt GPT-3.5 to infer the big O time and space complexity’’. Please establish the reliability of this LLM evaluation.

W5: In line 328, Code Summary (categorical) is measured by “prompt GPT-3.5 to assign tags to a code segment by providing it a set of tags to choose from”. Please establish the reliability of this LLM evaluation.

W6: In Figure 4 (d), decay T p = 1.0 seems to have higher entropy, therefore more diverse, than source distribution. Could the authors discuss this, as it disagrees with the statement in line 379 “there exists significant narrowing from the source to generation distribution in all attributes considered for both scenarios”?

Meta-review: Quoting a reviewer’s summary of the paper’s main idea -- “The main idea of this paper can be summarized in the following toy example: if 90% of humans say that chocolate is tasty, should language models always describe chocolate as tasty, or should they aim to somehow reflect the diversity in human opinions, and occasional refer to chocolate as bad-tasting?” The authors study this diversity in two domains: the sentiment of book reviews and the algorithms employed in generated code. The work analyzes the various ways in which LLMs enforce a monoculture by failing to model the diversity present in actual human-written content, and argues that it seems to get worse for models which are “aligned” to human preferences via RLHF. The problem of “generative monoculture” in LLMs is interesting (though not completely new). The results/discussion presented in the paper is thorough and convincing, and the paper is well-written. One of the key concerns is that the evaluation is mostly based on automatic metrics, such as using GPT-3.5 for evaluating LLM outputs. It’s unclear how reliable GPT-3.5 could be as a judge (though the authors presented certain studies of the judgement quality).

Decision: Accept (Poster)