Text Generation Applications: Use Cases and Quality

Article links

Make inline references clickable

Language models have always generated text, but for most of their history that capability was a means to an end. An n-gram language model generated the next token to estimate perplexity; a sequence-to-sequence model generated translations to satisfy a task. What changed with modern large language models was the realization that generation itself, unconstrained and open-ended, is the universal interface. You describe what you want in plain language and the model produces it. The resulting applications span an enormous range: marketing copy, legal briefs, code, poetry, customer-service replies, product descriptions, educational explanations, and technical documentation. Understanding how to use generation well, and where it breaks down, requires understanding both the mechanisms underneath and the quality dimensions that matter in practice.

This chapter covers text generation applications. We begin with the core use-case categories, examine what "quality" means for generated text, walk through practical code for each major task type, and close with honest limitations and their implications. The next chapter covers summarization in depth, which is a specialized generation regime with its own quality constraints.

A large language model trained with causal language modeling learns one objective: predict the next token given all previous tokens. We covered this objective in detail in the chapter on Causal Language Modeling. What makes this deceptively powerful is that the same objective, applied at sufficient scale on sufficiently diverse text, produces a model that can perform nearly any text manipulation task when prompted correctly.

The generation paradigm has three essential ingredients:

• A pre-trained language model with broad world knowledge encoded in its parameters
• A prompt that frames the task, provides context, and shapes the output style
• A decoding strategy that selects tokens from the model's probability distribution

The chapters on Autoregressive Generation, Decoding Temperature, Top-k Sampling, Nucleus Sampling, and Repetition Penalties covered decoding strategies. Here we focus on the application layer: what you build on top of that generation machinery.

It is worth pausing to appreciate how unusual this situation is. Traditional software requires explicit programming: a developer writes rules, a compiler translates them to machine code, and the system executes those rules exactly. A text generation system inverts this entirely. You describe the desired behavior in natural language, and the system produces outputs that approximate it. The approximation is almost never perfect, which is why evaluation, constraint checking, and quality pipelines are not optional extras in production systems. They are the engineering layer that compensates for probabilistic behavior.

Early GPT-style models performed completion: given a prefix, continue the text. This works for generation tasks if you carefully craft a prefix that demonstrates the pattern, but it requires users to think like the model. Effective few-shot prompting for completion models required providing two or three examples of the desired input-output pattern before the actual query, so that the model could infer the task from the distributional signal of the examples. This is called few-shot in-context learning, which we explored in the In-Context Learning chapter.

Instruction-tuned models, as covered in the Instruction Tuning chapters, shift the interface. You describe what you want ("Write a product description for a wireless keyboard targeting remote workers") and the model complies. This distinction matters practically because it determines how you write prompts and how reliably the model follows task constraints. Completion models require prompt engineering as a craft; instruction-following models require it as a discipline, but the craft is more forgiving.

The instruction-following interface also matters for how constraints are communicated. A completion model implicitly infers constraints from the examples you provide; an instruction-following model reads constraints you state explicitly. This makes constraint specification more reliable and more debuggable. When the model violates a constraint, you can inspect your prompt and identify whether the constraint was stated clearly, whether conflicting instructions existed, or whether the model simply failed to follow an unambiguous instruction.

Not all text generation capabilities emerge at the same model scale. The ability to generate grammatically correct text appears at relatively small scales; the ability to maintain factual consistency across a 500-word document requires substantially more capacity; the ability to follow complex multi-constraint instructions (generate a 200-word summary in the voice of a 19th-century novelist without using the word "the") requires very large models. This graduation means that application requirements drive model selection, and cost-performance trade-offs are real. Matching the model to the task is one of the most important engineering decisions in production text generation systems.

Small models (under 7 billion parameters) are fast and cheap but struggle with complex instruction following and factual accuracy. Medium models (7 to 70 billion parameters) balance capability and cost well for most content generation tasks. Very large models (70 billion parameters and above) are justified for high-stakes tasks where accuracy and nuance matter more than cost. Distillation techniques, which transfer knowledge from large models into small ones, are increasingly practical for specific tasks, as we will discuss in the Model Compression chapters.

Content creation is the most commercially visible use of text generation. Businesses produce enormous volumes of written content: product descriptions, blog posts, email newsletters, social media posts, ad copy, and press releases. LLMs can draft, revise, and adapt this content at speeds that human writers cannot match.

What makes language models effective for content creation is that much of commercial writing follows patterns. A product description for a wireless keyboard follows roughly the same structure as one for a standing desk: establish the problem or need, present key features, close with a value proposition. Models trained on billions of examples of commercial writing have absorbed these patterns deeply. The challenge for practitioners is not discovering this capability, but controlling its outputs, making sure factual accuracy, and integrating the generation step into an existing content workflow.

E-commerce platforms maintain catalogs with thousands of products. Writing an effective, SEO-friendly description for each one manually does not scale. A language model can generate descriptions from structured product attributes, maintaining consistency in tone while adapting to product-specific details.

The key challenge is factual grounding. The model should not invent features the product does not have. Effective prompts constrain the model to the provided attributes and explicitly prohibit adding unverified claims. This sounds straightforward, but models have a strong prior from training on marketing text toward adding positive attributes that were common in similar products. A keyboard description might acquire "water-resistant coating" or "anti-ghosting keys" if those phrases appeared frequently in the training set's keyboard descriptions, even if the specific product being described has neither feature.

Combating this requires explicit negative instructions in the prompt ("Do not add any features not listed in the provided attributes") and downstream factual verification. For structured domains, the verification step can be automated: extract claims from the generated text, compare against the attribute list, and flag any claim that lacks a corresponding attribute. This combination of generation with automated verification is a pattern that appears across factual content generation domains.

The business case for LLM-based product description generation rests on throughput. A human copywriter can produce roughly 20 to 50 product descriptions per day, depending on complexity. An LLM pipeline can produce thousands per hour. Even accounting for the review and revision time required to catch quality problems, the cost per description drops by an order of magnitude. This is why e-commerce has been one of the earliest commercial adopters of LLM-based content generation.

Advertising copy requires a different register from product descriptions: concise, attention-grabbing, emotionally resonant. Models can generate multiple variants of ad headlines or email subject lines for A/B testing. The human role shifts from writing to selection and refinement.

A practical workflow combines generation with evaluation: generate 10 headline variants, apply a preference model or human review, select the top 2, and route them into testing. This workflow converts a bottleneck (a single writer generating a single headline) into a pipeline that produces dozens of candidates cheaply and quickly.

The reasons models excel here are the same reasons they excel everywhere: they have read enormous amounts of advertising copy, marketing collateral, and conversion-optimized landing pages. They have implicitly learned which words and phrases tend to appear in successful headlines (specificity, urgency, benefit-driven language) and which combinations produce the cadences that marketers favor. They cannot guarantee that any given headline will perform well in a live test, because advertising performance depends on audience, context, and timing factors the model cannot observe. But they can generate candidates that are plausible starting points much faster than a human writer could.

One underappreciated advantage is stylistic range. A human copywriter has a personal voice that naturally infuses their work. A language model can shift register on command: formal or casual, urgency-driven or aspirational, technical or accessible. This makes it easy to generate variants targeted at different audience segments from the same underlying product brief.

Long-form generation exposes its most significant quality challenge: coherence over long spans. Models trained with a context window can maintain consistency within that window, but multi-section articles with complex arguments may drift or repeat themselves. A model generating a 2,000-word article without structural guidance may start with one thesis, wander into a related topic in the middle, and end with a conclusion that addresses something slightly different.

Effective long-form generation uses a hierarchical approach. First generate an outline. Then generate each section independently using the outline as a constraint. This reduces the coherence problem to section-level generation, where models excel.

The hierarchical approach works because it separates two distinct tasks: planning and execution. Planning (producing an outline) is a low-temperature task that benefits from structure and specificity. Execution (filling in each section) is a constrained generation task where the outline prevents drift. Separating them allows you to apply different prompting strategies and quality checks at each stage. For example, you can validate the outline against a topic brief before generating any body text, catching structural problems before they propagate into hundreds of words of content that would need to be rewritten.

Long-form generation also requires managing cross-reference consistency. If the introduction defines a term one way and a later section uses the same term differently, the article is incoherent even if each section is individually well-written. Post-processing steps that normalize terminology across sections, or prompting strategies that explicitly list the defined terms before each section, address this problem. Some practitioners maintain a running "fact sheet" document that is included in the context for each section, making sure consistent use of names, numbers, and defined concepts throughout.

A practical consideration for long-form generation is token economics. Generating a 2,000-word article requires roughly 2,700 to 3,000 input tokens (for the prompt plus context) and 2,000 to 2,500 output tokens. At current API pricing, this costs a fraction of a cent for small models and a few cents for large models. The economic case for AI-assisted content is clear at this price point, but the cumulative cost across thousands of articles warrants careful monitoring in production.

Email drafting is one of the most immediately useful applications of text generation for individual users. The task is well-constrained: given a context (who you are, who you are writing to, what you want to say), produce a draft that the user can review and edit. The model reduces the blank-page problem, which is the cognitive barrier of starting to write, and produces a reasonable first draft in seconds.

Quality requirements for email drafting are interesting. Tone accuracy matters enormously: a draft that is too formal for a casual colleague relationship, or too casual for a regulatory authority, is worse than no draft at all because it creates the wrong impression. Models generally handle explicit tone instructions well ("Write in a professional but warm tone") but may default to overly formal language without explicit guidance. Users who integrate LLM drafting into their workflow typically develop personal prompt templates that encode their preferred register for different communication types.

The privacy consideration in email drafting is non-trivial. Effective email drafts require context about the sender, the recipient, and the subject matter, all of which may be sensitive. Enterprise deployments typically use models running on-premises or in private cloud environments rather than shared API endpoints to address this. For personal use, users make their own risk assessments about sharing context with third-party providers.

Writing assistance differs from content creation in an important way: the model helps a human writer rather than replacing them. The human retains ownership and responsibility for the final text; the model acts as a capable, tireless collaborator.

This distinction changes how to think about quality and failure modes. When a model creates content autonomously, quality failures are the system's responsibility and must be caught before publication. When a model assists a human writer, the human is a natural quality filter: they accept suggestions that improve their text and discard those that do not. Writing assistance can therefore tolerate a higher rate of mediocre suggestions than autonomous content generation, because humans naturally filter in the loop.

This also reshapes the skill requirement for effective use. A writer using LLM assistance well needs to develop judgment about which suggestions to accept, modify, or reject. The model's suggestions reflect patterns in training data, which encode the median of a vast distribution of writing. That median may not match the writer's voice, intended audience, or specific argumentative purpose. Good judgment about when to use the suggestion as-is, when to adapt it, and when to discard it entirely is what separates effective users of writing assistance from ineffective ones.

The most basic writing assistance is error correction. Models can fix grammar mistakes, improve sentence clarity, and adjust style to match a target register (formal, casual, technical). Unlike rule-based grammar checkers, models understand context. They can tell whether "affect" or "effect" is correct by reading the surrounding sentences.

The contextual advantage extends to stylistic suggestions. A rule-based checker can flag passive voice or flag sentences over a certain length, but it cannot reason about whether a passive construction is appropriate given the writer's intended focus. A language model can evaluate a sentence in context and suggest revisions that preserve meaning while improving flow. This kind of context-sensitive editing has historically required a human editor; language models now offer a first pass at that work at near-zero cost.

One subtle failure mode in grammar and style correction is meaning drift. A model may "correct" a sentence by changing a word or restructuring a clause in a way that alters the intended meaning. Writers using correction tools need to verify that the suggested revision preserves their intended semantics, not merely that it sounds more polished. This is especially important in legal, scientific, and technical writing where precise word choice carries precise meaning.

Style transfer is a more ambitious form of style assistance: rewriting a text to match a different register, vocabulary level, or even the style of a specific author or publication. Style transfer works well for broad register changes (formal to informal, technical to accessible) but struggles with fine-grained stylistic imitation because style is a complex, emergent property that the model may approximate but rarely captures exactly.

Writers frequently know what they want to say but struggle to say it fluently. Giving the model a partial draft and asking it to continue, expand a bullet point, or rephrase a clumsy sentence exploits generation in a targeted way. The model's suggestions serve as raw material, not finished product.

The continuation task benefits from a clear interface: the model receives the text written so far plus an instruction specifying what comes next. "Continue the above with a paragraph explaining the main limitation" is more reliable than "Continue the above." Specific continuations allow the model to maintain topical coherence; open-ended continuation may surprise you with a direction you did not intend.

Expansion of bullet points into paragraphs is a particularly well-suited task. Bullet points capture the core idea without the connective tissue of full prose. A model asked to expand them produces the connecting sentences, supporting detail, and transitional phrasing that makes the bullet readable as prose. The resulting paragraph often needs light editing, but the heavy work of drafting from a blank page is done.

Machine translation is one of the most mature text generation applications. The sequence-to-sequence architectures we covered in the Encoder-Decoder chapters were originally designed for translation. Modern LLMs often match or exceed dedicated translation models on standard language pairs, with the added benefit of adapting tone and formality to context.

The performance of LLMs on translation varies significantly by language pair. For high-resource language pairs like English-French, English-Spanish, or English-German, LLMs trained on large multilingual corpora can produce high-quality translations that match or exceed dedicated neural machine translation (NMT) systems like Google Translate or DeepL. For low-resource language pairs where less training data exists, dedicated translation models trained with parallel corpora often outperform general-purpose LLMs.

Localization goes beyond translation: it adapts content to cultural expectations, unit conventions, and regional idioms. Models that have absorbed multilingual web text often handle localization well, though cultural nuance remains an area requiring human review. A translated marketing headline that works perfectly in English may carry a different connotation in the target language, require adjustment for local pricing conventions, or reference a cultural analogy that does not translate. Human review by native speakers remains essential for high-stakes localization work.

The formality dimension in translation is particularly interesting. Many languages distinguish formal and informal registers grammatically (German Sie vs. du, French vous vs. tu, Japanese keigo). LLMs can be prompted to use a specific register, but they sometimes slip between registers across a long document. Explicit instruction with a reminder in each section prompt helps maintain register consistency.

Code generation is perhaps the most economically significant writing assistance application. Models trained on large code corpora can generate function implementations from docstrings, complete partially written functions, translate code between languages, write unit tests, and explain what existing code does.

Code generation has a distinctive quality criterion: functional correctness. A generated code snippet that looks plausible but produces wrong output is worse than no output, because it may pass superficial review. The HumanEval benchmark and its pass@k metric were designed specifically for this evaluation challenge.

The pass@k metric captures the practical reality of code generation workflows: you rarely submit the first generated snippet directly. Instead, you generate several candidates and test them. Pass@1 measures how often the first candidate passes all tests; pass@10 measures how often at least one of ten candidates passes. Models with high pass@10 but lower pass@1 are well-suited to workflows where automated testing filters out incorrect candidates cheaply. This is why code generation integrates best with a test suite: the tests serve as the automated constraint checker analogous to what we will build for text generation below.

The failure modes in code generation are also distinct from prose generation. A generated text description that is partially wrong may still convey useful information. A generated function that contains a subtle off-by-one error or handles only the happy path produces a bug that can sit undetected for months. Responsibility lies with the developer who accepts the code, which is why treating model-generated code as a draft requiring review, not a finished implementation, is the correct professional posture.

Code generation quality improves significantly when the prompt provides function signatures, docstrings describing expected behavior, and example input-output pairs. These constraints give the model a precise specification to work toward. Without them, the model infers what the function should do from the function name, which is often insufficient for non-trivial implementations. The pattern of specifying behavior first and then asking for implementation is good software engineering practice with or without LLMs, but it matters especially for generation quality.

Conversational AI applications include customer service bots, educational tutors, interview preparation tools, and general-purpose assistants. These differ from single-turn generation tasks in one critical way: they require maintaining consistency across multiple turns. A model that says the company's return policy is 30 days in one turn and 60 days in the next has a consistency problem that is worse than saying nothing.

Multi-turn coherence requires passing the conversation history as context on each turn. This works well within the context window but degrades as conversations grow long. Conversation management strategies like summarizing older turns, maintaining a structured memory of stated facts, or using retrieval over previous turns address this limitation. We will cover conversational memory architectures more thoroughly in the RAG chapters.

Persona consistency is a related challenge. Customer service bots often have defined personas: a name, a communication style, an instruction set about what topics they can and cannot address. Models generally follow persona instructions well for the first several turns, but in very long conversations they may drift, especially if the user asks questions that pull the model toward its generic instruction-following behavior rather than its persona constraints.

Quality in text generation is multi-dimensional. No single score captures whether output is good, and different applications weight dimensions differently. Understanding these dimensions allows you to design better prompts and evaluation pipelines.

Fluency measures how natural and grammatically correct generated text reads. Modern large language models almost always produce fluent text; fluency failures are rare except at very low temperatures that cause repetition or very high temperatures that cause incoherence. Fluency is necessary but not sufficient.

It is worth understanding why fluency is so reliable in modern models. The causal language modeling objective, applied over billions of tokens of well-written text, powerfully incentivizes grammatical correctness: an ungrammatical continuation is almost always lower probability than a grammatical one. Models that cannot produce grammatical text have high perplexity on standard benchmarks, which pushes against them during training. Fluency is, in a sense, the dimension that training data quality most directly addresses.

Relevance measures how well the output addresses the prompt. A fluent but irrelevant response fails the task. Relevance depends heavily on prompt quality: vague prompts produce tangentially relevant outputs; precise prompts with explicit constraints produce tighter results.

A common relevance failure is scope creep: the model addresses the prompt but adds substantial content that is adjacent to but outside the requested scope. A prompt asking for a 100-word explanation of gradient descent may produce a 300-word explanation that covers gradient descent, its variants, applications to neural networks, and comparison to second-order methods. Each individual claim may be accurate, but the output does not comply with the task. Explicit length constraints and instructions to focus exclusively on the stated topic reduce scope creep.

Another relevance failure is question reframing: the model subtly rewrites the question it was asked before answering, producing a response that is internally coherent but does not address the original prompt. This happens because the model generates both its interpretation of the task and its response to that interpretation sequentially. Prompts that ask the model to state its interpretation before answering, or that provide explicit markers for the input task, help catch this failure early.

Factual accuracy is the dimension where generation most commonly fails. Models generate based on distributional patterns in training data, not by looking up ground truth. They can produce convincing, fluent, completely false statements. This is the hallucination problem covered in detail in the Hallucination chapters.

Hallucination is not uniformly distributed. Models are more likely to hallucinate when asked about specific facts (dates, statistics, citations, names of obscure entities) than when asked about well-established general knowledge. They are more likely to hallucinate when the requested information is rare in the training set than when it is common. They are more likely to hallucinate in domains (medicine, law, finance) where training data may contain contradictory or outdated information. Understanding these patterns allows practitioners to identify which parts of a generation pipeline require retrieval augmentation or human verification.

For content creation applications where factual accuracy matters, the standard mitigation is retrieval-augmented generation (RAG). The model is given relevant retrieved documents as context and instructed to base its output on them. We covered RAG in depth in the RAG chapters. RAG does not eliminate hallucination, but it substantially reduces it for facts that appear in the retrieved documents. The model can still hallucinate by misquoting the retrieved context, conflating information from different documents, or generating claims beyond the scope of the retrieved context.

Coherence measures whether the text holds together as a unified piece: whether it maintains consistent facts, does not contradict itself, and follows a logical structure. Long outputs challenge coherence more than short ones. Hierarchical generation strategies and explicit document outlines improve coherence.

Coherence also has a subtle intra-session dimension. When a model generates a multi-section document in a single call, it may drift in its terminology: the first section calls something "token embedding" and the third section calls the same concept "input representation." These are not factual errors, but they reduce readability and suggest the text was generated without a unified plan. Instructing the model to maintain a defined glossary, or post-processing outputs to normalize terminology, addresses this failure mode.

Logical coherence is a more demanding criterion than terminological coherence. An argument that makes a claim in one paragraph, then makes a supporting claim in the next paragraph that contradicts the first, is logically incoherent even if every sentence is individually grammatical. Logical coherence checking requires semantic understanding of the content, which is difficult to automate. Models asked to critique their own outputs for logical consistency can catch some of these issues, but self-critique is unreliable for the same reasons that self-verification is unreliable: the model that generated the error often also fails to detect it.

Many applications impose hard constraints: word count limits, required inclusions or exclusions, stylistic rules, format requirements (JSON, markdown headers, bullet lists). Adherence measures whether the model respects these constraints. Models often violate constraints at the margins, particularly count constraints ("write exactly 100 words"). Verifying adherence programmatically and retrying on failure is standard practice.

Hard constraints form a hierarchy by verifiability. Word count is trivially verifiable by a tokenizer. Required phrase inclusion is verifiable by substring search. JSON format validity is verifiable by a JSON parser. Logical consistency and tone appropriateness are much harder to verify programmatically. Building a production constraint-checking pipeline means distinguishing between hard constraints that can be checked algorithmically and soft constraints that require semantic evaluation.

Diversity is a quality dimension in some applications. When generating multiple variants for A/B testing, you want outputs that are materially different, not paraphrases of the same content. Higher temperature increases diversity at the cost of reliability. Techniques like sampling with different random seeds, modifying system prompts, or using diverse persona descriptions improve output variety.

It is worth understanding why models tend to produce similar outputs when temperature is low. A low-temperature model concentrates probability mass on the few highest-probability tokens at each step. Since the same tokens tend to be highest probability across similar prompts, the model effectively follows the most common pattern in its training data, which produces similar outputs for similar prompts. Raising temperature introduces randomness that pulls the model off the most-trodden path, exploring less common but still plausible continuations. The trade-off is real: those less common paths are less common partly because they are less appropriate, not only because they are less frequent. This is why high-diversity applications require human filtering to discard the outputs that are different but worse.

A practical diversity enhancement technique is persona prompting: prefacing each generation with a different persona instruction ("You are a concise technical writer" vs. "You are an enthusiastic marketing copywriter") to push the model toward different stylistic registers. This reliably produces outputs that differ in tone and vocabulary even at moderate temperature, without the coherence risk of very high temperature.

Let's build practical implementations of the main generation use cases. We use the transformers library to demonstrate generation locally, and show patterns that apply when calling hosted APIs.

Simulating Generation OutputsLink Copied

One measure of generation quality is lexical diversity: how much of the vocabulary is unique versus repeated. Repetitive outputs suggest the model is stuck in a pattern, often a sign of decoding issues or insufficient temperature. The most common lexical diversity metric is the Type-Token Ratio (TTR):

where:

• : the ordered sequence of words in text (the token list)
• : the number of distinct word types (unique vocabulary)
• : the total number of word tokens (including repetitions)

TTR ranges from 0 (every token is identical) to 1 (every token is unique). For typical natural language, values above 0.70 indicate good lexical variety. TTR is sensitive to document length: longer texts accumulate more repeats, so TTR tends to decrease as documents grow. The Moving-Average TTR (MATTR) addresses this by computing TTR over a sliding window of fixed size and averaging across all window positions, making it comparable across texts of different lengths.

Why does lexical diversity matter for generation quality? A model generating repetitive text is either stuck in a local probability maximum (a phrase that keeps predicting itself), or it has settled into a high-probability pattern from training data that happens to repeat a phrase or sentence. Both situations indicate that the generation is not fully exploring the model's distribution. Repetition penalties, which we covered in the Repetition Penalties chapter, directly address this by reducing the probability of recently generated tokens. Low TTR in an output is a signal that either repetition penalties were not applied, or that the applied penalties were insufficient for the task.

Many generation tasks have hard constraints. Let's implement a constraint checker that validates output against a specification.

Temperature is the primary control for balancing output quality against diversity. Recall from the Decoding Temperature chapter that temperature rescales the model's logits before the softmax. Given logits over a vocabulary of tokens, the probability assigned to token is:

where:

• : the raw logit for token , produced by the final linear layer of the model
• : the temperature parameter; leaves the distribution unchanged, sharpens it, flattens it
• : dividing by before exponentiation amplifies (for ) or compresses (for ) differences between logits

At , the distribution collapses to a point mass on the highest-logit token (greedy decoding). At , all tokens become equally probable (uniform random sampling). Let's visualize this relationship concretely using a simulation based on real vocabulary statistics.

A common production pattern generates multiple outputs and selects the best by scoring. Let's implement a simple scoring pipeline.

Prompt quality drives output quality more than any other single factor. A well-structured prompt reduces constraint violations, improves factual grounding, and produces more consistent outputs. Let's examine the components of effective generation prompts.

A generation prompt for a structured task has four components that each play a distinct role. The role specification tells the model what perspective to adopt and activates the relevant subset of its training distribution. The task description precisely states what output is expected, preventing ambiguity about format or scope. The constraint section makes explicit requirements unambiguous and separates them from the task description, so they do not get buried in narrative prose. The input data section provides the grounding information the model needs to produce factually accurate output.

A final visualization shows how attribute coverage varies with output length. This pattern is useful when deciding whether to use a word-count constraint: very short descriptions cannot cover all key attributes, while very long ones may add fabricated details.

The key parameters for generation quality control are:

• temperature: Controls the diversity-coherence trade-off. Values from 0.7 to 1.2 work well for most content generation tasks. Use 0.3 to 0.7 for structured, factual outputs; use 1.0 to 1.5 for creative, varied outputs.
• min_words / max_words: Hard word-count bounds. Set min to ensure full attribute coverage; set max to prevent verbose, padded outputs.
• required_phrases: Must-include terms for SEO or brand compliance. Check with case-insensitive substring matching.
• forbidden_phrases: Must-exclude terms for brand safety or regulatory compliance. Any match is a hard failure.
• compliance weight (0.50): The fraction of the composite score assigned to constraint compliance. Keeping this high (above 0.40) ensures constraint violations are always penalized.
• retry_limit (3): Maximum number of generation attempts before reporting failure. Three retries resolve the vast majority of constraint violations.

Production text generation requires automated evaluation to catch quality regressions and constraint violations at scale. Evaluation is not a one-time activity at deployment; it is a continuous monitoring function. Models are updated, prompts drift, and the distribution of user inputs changes over time. A quality regression that would have been caught at launch may develop gradually and go unnoticed without ongoing measurement.

The most effective production evaluation systems layer multiple complementary signals. No single signal is sufficient. Hard constraint checks catch violations but say nothing about quality within the constraints. Reference-based metrics measure similarity to known-good outputs but cannot detect valid outputs that happen to be phrased differently. LLM judges evaluate overall quality but introduce their own biases. Human evaluation is the gold standard but is expensive and slow. The art of production evaluation design is combining these signals in a cost-effective way.

Reference-based metrics compare generated text against one or more human-written references. BLEU and ROUGE, covered in the Evaluation Fundamentals chapters, are the most common. They measure n-gram overlap and work well when there is an accepted reference (e.g., translation, summarization). They work poorly for open-ended generation where many valid outputs exist.

BLEU was designed for machine translation, where the task has a clearly defined correct output and deviations from it are meaningful. For content creation tasks where creativity and novelty are valued, a BLEU score penalizes outputs that use different but equally valid phrasing. This makes BLEU a poor choice as a primary metric for most content generation evaluation. However, BLEU remains useful as a regression-detection metric: if the BLEU score for a generation pipeline drops significantly from baseline, something has changed in the model or prompt, and investigation is warranted.

BERTScore is a more semantically sensitive alternative to BLEU that uses contextual embeddings to compute similarity. It can recognize paraphrases that BLEU would penalize, making it better-suited to content generation evaluation. The trade-off is computational cost: BERTScore requires running a BERT-sized model on every output, which is significantly more expensive than n-gram overlap computation.

A strong language model can evaluate generated text by reading the output and answering specific questions about quality dimensions. This is now the standard approach for evaluating instruction-following quality. The pattern is: generate outputs, send each to an evaluation model with a scoring rubric, aggregate scores. The primary caveat is that judge models have their own biases, particularly toward outputs that are verbose and confident.

The design of the scoring rubric is the most important engineering decision in an LLM-as-judge setup. A rubric that asks "Rate the quality of this text from 1 to 10" is too vague to produce reliable scores. A rubric that asks specific questions ("Does the text include the product's battery life? Yes or No. Is the text under 120 words? Yes or No. Does the text avoid making claims not supported by the provided attributes? Rate 1 to 5.") produces more reliable and interpretable results.

Judge model bias is a real concern. Models are known to prefer outputs from models similar to themselves, to prefer longer outputs to shorter ones of equivalent quality, and to give inflated scores to outputs that use confident language. The standard mitigation is to validate judge scores against human judgments on a calibration set, and to use multiple judge models and aggregate their scores rather than trusting a single judge.

Hard constraints (word count, required inclusions, forbidden content) should always be checked programmatically. These checks run quickly and reliably while catching a significant fraction of output failures. The constraint checker we built above is a simplified version of what production systems use.

The programmatic constraint-checking layer should be treated as a gate, not a score. Outputs that fail hard constraints are rejected, not downgraded. This reflects the business reality that constraint violations often have qualitative implications that scoring cannot capture: an email draft that mentions a competitor's product when forbidden is a brand safety violation regardless of how well-written the rest of the email is.

For high-stakes applications (legal documents, medical content, financial disclosures), human review remains essential. The statistical properties of human evaluation, including inter-annotator agreement and preference evaluation design, are covered in the Human Evaluation Design and Preference Evaluation chapters (not yet published).

Human evaluation for text generation typically uses either Likert scales (rate from 1 to 5 on each quality dimension) or pairwise preference judgments (which of these two outputs is better?). Pairwise preferences produce more consistent inter-annotator agreement because they are a simpler cognitive task than absolute scale judgment. The Bradley-Terry model and similar pairwise comparison models can convert pairwise preferences into a global quality ranking, which is how most modern preference-based evaluation systems work.

The cost of high-quality human evaluation should not be underestimated. Evaluating 1,000 generated outputs on five quality dimensions at two annotators per output, at a professional annotation rate, costs thousands of dollars. This is why automated evaluation is not optional for production systems: it is the cost-effective primary signal, with human evaluation reserved for calibration, auditing, and high-stakes decisions.

Prompt engineering for text generation is broader than getting a first output; it requires designing prompts that reliably produce high-quality outputs across the distribution of inputs the system will encounter. The gap between a prompt that works for a demo and one that works in production is often large.

Zero-shot prompts describe the task without providing examples. Few-shot prompts include one or more example input-output pairs before the actual query. For instruction-tuned models, zero-shot prompting works well for common tasks that were well-represented in the fine-tuning data. For unusual formats, edge cases, or tasks that require a specific style not easily described in words, few-shot examples are more reliable.

The number of examples matters. One or two examples establish the pattern; more than five examples yield diminishing returns and use tokens that could be used for input context. Selecting diverse, high-quality examples is more important than maximizing example count. For production systems, maintaining a curated library of few-shot examples, selected based on performance on held-out validation sets, is standard practice.

For generation tasks that require planning or reasoning (e.g., writing a legal clause that must satisfy multiple conditions), asking the model to think through its approach before writing produces better outputs. The chain-of-thought pattern says: "First, outline the key points your response should cover. Then write the response." The planning step produces a structured intermediate representation that constrains the generation step, analogous to the hierarchical approach we discussed for long-form articles.

Chain-of-thought prompting also makes the model's reasoning visible for debugging. If the output is wrong, you can inspect the thinking step to see where the model's plan went wrong, rather than just observing a bad output with no insight into why.

Most production APIs separate the system prompt (which configures the model's behavior globally) from the user prompt (which specifies the current task). System prompts are the right place for stable configuration: persona, tone, general constraints, output format requirements, and safety rules. User prompts are the right place for variable input: the specific task, the input data, and per-request constraints.

Mixing these concerns causes problems. System prompts that include user-level constraints cause issues when those constraints need to vary across requests. User prompts that include persona configuration produce inconsistent behavior because the persona has to be re-established on every call. A strict separation between system and user prompt layers makes prompts more maintainable and easier to test.

The most fundamental limitation of LLM text generation is the gap between linguistic competence and epistemic reliability. A model can produce a fluent, well-organized, confidently worded paragraph that contains completely false information. This is not a quirk of certain models; it is a structural feature of systems trained to predict plausible next tokens rather than retrieve verified facts.

The hallucination problem has practical implications that depend on application. For creative writing and fiction, hallucination is irrelevant. For marketing copy about fictional products, moderate factual grounding through attribute-constrained prompts is sufficient. For legal briefs, medical information, or financial documents, any factual error is potentially catastrophic. The mitigation strategy scales accordingly: no mitigation for creative work, retrieval augmentation for factual domains, and mandatory human review for high-stakes decisions.

A second limitation is consistency across generations. The same prompt with the same model produces different outputs on each call (unless temperature is 0). This is valuable for generating variants but problematic for applications that need deterministic outputs. Version-locking (specifying an exact model version and setting a fixed seed where the API allows) reduces but does not eliminate variability. The non-determinism is not a bug; it is inherent to probabilistic sampling. Production systems that require deterministic outputs should store and reuse generated outputs rather than regenerating them on each request.

A third limitation is the context window ceiling. Modern models have context windows of 8,000 to 200,000 tokens, but even the longest windows constrain what a model can "see" during generation. Very long documents, multi-turn conversation histories, and complex generation tasks that require integrating many sources may exceed the window or suffer degraded attention at very long ranges, as discussed in the Long Context chapters. Chunking, summarization of earlier context, and retrieval-augmented approaches all address this limitation in different ways, with different cost and latency implications.

A fourth limitation concerns the training data cutoff. Models cannot know about events, products, or facts that postdate their training data. For time-sensitive applications (news, current events, recent product releases), this is a hard constraint that no amount of prompt engineering can overcome. Retrieval augmentation is the standard solution, but it requires maintaining current, searchable knowledge sources alongside the model, which adds architectural complexity.

Finally, generation cost and latency are real constraints for interactive applications. Generating a 500-word article from a large model may take several seconds and cost fractions of a cent per call. At scale, these costs add up. Practical systems use smaller models for low-stakes tasks, cache frequently generated content, and reserve large model calls for high-value outputs. The emergence of efficient small models (under 7 billion parameters with instruction-following capability) has substantially improved the cost-performance trade-off for many production generation tasks.

The ethical dimensions of text generation deserve acknowledgment. At scale, language model generation has the potential to flood information channels with low-cost synthetic content, including misinformation, spam, and plagiarized material. Responsible deployment of generation systems includes thinking carefully about the downstream uses of generated content, applying safety filtering where appropriate, watermarking or disclosing AI-generated content where transparency is required, and designing for human review in high-stakes workflows.

Text generation has evolved from a byproduct of language model training into the central interface for a wide range of NLP applications. The key takeaways from this chapter:

• Generation covers a spectrum from open-ended content creation to constrained assistance, each with different quality requirements and different mitigation strategies for the same underlying failure modes
• Quality is multi-dimensional: fluency, relevance, accuracy, coherence, and constraint compliance all matter, with different weights for different applications; no single metric captures all of these simultaneously
• Temperature controls the diversity-coherence trade-off: practical generation tasks operate between 0.7 and 1.2, with lower values for factual precision and higher values for creative variety
• Constraint verification should be automated: programmatic checks catch a significant fraction of output failures before they reach users, and structuring failure types allows targeted retry prompting
• Scoring multiple outputs and selecting the best is more reliable than hoping a single output meets all requirements; the scoring weights encode business priorities and should be calibrated against human judgments
• Prompt structure matters: separating role specification, task description, constraints, and input data into distinct prompt sections reduces violation rates and improves output consistency
• Hallucination is the primary reliability risk: mitigate with retrieval augmentation for factual tasks, and with mandatory human review for high-stakes domains
• Production evaluation requires layered signals: programmatic constraint checking, reference-based metrics, LLM-as-judge, and periodic human evaluation each play different roles in a complete evaluation pipeline

The next chapter, on Summarization, examines a specialized generation regime where the input is a long document and the required output is a concise, faithful reduction of its content. Summarization introduces faithfulness as an additional quality dimension and brings its own evaluation challenges, particularly around the trade-off between compression and information preservation.

QuizLink Copied