LLM-Driven Presentation Generation and Precise Editing: A Practical Engineering Approach

1. The Underestimated Cost: Why Presentations Deserve Engineering

In consulting, investment banking, product, and market analysis roles, presentations are high-value but low-reuse deliverables. The actual content may account for only about 30% of the total working time. The remaining 70% is often spent on layout alignment, consistent color schemes, font hierarchy, chart redrawing, and repetitive edits where changing one sentence can affect three slides.

This type of cost is high-frequency, structured, and heavily manual. That makes it a good fit for large language models and programmatic generation.

One common misconception needs to be clarified first: asking a model to “output Markdown” is not the same as generating a presentation. A presentation is a layout-aware object container whose value lies in being continuously editable. If the output is an image or a full-page screenshot, users are forced to rebuild everything during later edits. That approach is not viable from an engineering standpoint.

2. Key Insight: A Presentation Is a Programmable Object Model

Mainstream presentation file formats use a container-and-part structure. At the package level, the file is a compressed archive containing a set of XML parts. These parts can usually be abstracted into three layers:

• Package: The file-level container responsible for resource packaging and relationship mapping.
• Slide collection: Each slide is an independent part and contains a shape tree.
• Layouts and masters: Define placeholder positions, default fonts, color schemes, and theme styles.

The corresponding object hierarchy can be summarized as follows:

Presentation
 └── Slide
      └── Shape (text box / table / image / chart / group)
           └── Paragraph
                └── Run (smallest text fragment, carrying character-level formatting)

Understanding this hierarchy is the foundation of all engineering capabilities because it determines both generation granularity and edit precision. Any requirement to “change only text without changing formatting” ultimately requires the system to perform targeted replacement at the Run level rather than rewriting the entire page.

3. End-to-End Architecture: From Natural Language to Editable Files

The workflow is best split into five stages that can be evaluated and replaced independently. The model should not be asked to generate the entire file in one pass.

1. Intent Parsing and Structural Planning

The first step is to produce an intermediate representation of the outline, for example:

{
  "title": "2026 Q1 Market Review",
  "slides": [
    {"type": "cover", "fields": {"title": "...", "subtitle": "..."}},
    {"type": "bullets", "layout": "two_column", "points": ["...", "..."]},
    {"type": "chart", "chart_kind": "bar", "metric": "Quarterly Revenue"},
    {"type": "closing", "fields": {"summary": "..."}}
  ]
}

The value of this layer is that it separates content decisions from rendering decisions. The outline can be manually reviewed, diffed directly, and scored on its own. The rendering layer only needs to care about layout parameters. Without this intermediate representation, downstream quality issues tend to degrade into untraceable, occasional failures.

2. Content Generation and Density Control

When generating text, models commonly produce two problems: excessive information density that causes text overflow on a single slide, and semantically empty content consisting of correct but useless statements.

Engineering constraints should be enforced:

• Set an upper limit on the number of bullet points per slide, such as 3 to 5.
• Set an upper limit on characters per bullet, with separate thresholds for English and Chinese.
• Enforce conclusion-first writing: each slide title should be a judgment statement rather than a noun phrase.
• Bind data to conclusions: when numbers appear, they must include source and definition placeholders.

3. Layout Rendering

During rendering, only placeholders provided by the layout may be used. Free-form text boxes should not be drawn. This is the first gate for brand consistency.

# Illustrative pseudocode: placeholder-first rendering
def render_bullets(slide, points):
    body = slide.placeholder(idx=1)          # Use layout placeholder only
    tf = body.text_frame
    tf.word_wrap = True
    tf.auto_size = AUTO_SIZE.NONE            # Disable auto-size to expose overflow
    for i, text in enumerate(points):
        p = tf.paragraphs[0] if i == 0 else tf.add_paragraph()
        run = p.add_run(text=text)
        # Do not explicitly set font or color; inherit everything from the master
        assert len(text) <= MAX_CHARS_PER_BULLET

Pay attention to the assert step: non-compliant content should be blocked during rendering, rather than left for users to discover later.

4. Validation and Regression

After generation, an automated validation pass must be run. Failed items should be returned to the planning layer for retries rather than being delivered directly.

4. Template Constraints: Brand Consistency Is About Constraint Propagation

The correct engineering interpretation of “100% compliance with the brand template” is not that the model is smart. It is that the system leaves as little room as possible for free-form output. Three practical rules can be applied:

1. Design tokenization: Extract font families, font size scales, primary and secondary colors, and spacing systems into a configuration file. The rendering layer should only take values from tokens. The model may only reference token names such as color.primary or size.h2, and cannot provide concrete color values.

2. Theme inheritance instead of override: All character-level formatting should inherit from the master by default. Hard-coded fonts and colors should be prohibited. Once free-form drawing is allowed, the template has already been compromised.

3. Make the template itself executable-validated: Run a check on the delivered master file. Verify that placeholders are complete, missing fonts declare fallbacks, and table styles reference theme colors. A dirty template will inevitably produce dirty output downstream.

Text overflow detection is one of the highest-return optimizations in practice. The logic is simple:

def check_overflow(shape):
    need_h = 0
    for p in shape.text_frame.paragraphs:
        lines = ceil(text_width(p.text) / shape.width)   # Estimate wrapped lines
        need_h += lines * line_height(p) + p.space_before + p.space_after
    return need_h > shape.height + tolerance

Real layout precision depends on font metrics. In engineering, a two-layer approach is commonly used: rough filtering through metric estimation, followed by final verification using headless rendered screenshots.

5. Native Charts: Why They Must Be Chart Objects, Not Images

This is the key dividing line between a toy and a usable tool. Native chart objects separate data from visual presentation. Inside the file, both the chart definition and an embedded data table are stored.

The resulting benefits are substantial:

• Users can double-click to edit data, change chart types, and adjust colors.
• Chart colors automatically follow the theme, so templates can be switched without redrawing.
• Later automation scripts can read, validate, and batch-replace data.

By contrast, pasting images directly fails in three scenarios: changing numbers, switching templates, and performing batch version updates. Therefore, the architecture should clearly require charts to be constructed as objects by the rendering layer, and bitmaps should not be generated.

Consistency validation between charts and body text is also important. Numbers referenced in body text, numbers in tables, and chart data must come from the same source. It is recommended to drive all of them from one structured dataset to avoid definition drift caused by separate model generation.

6. Precise Editing: Turning “Change One Sentence” into a Locatable Patch

Generation is only the beginning. Iteration is the main battlefield. Precise editing depends on a stable location model:

SlideId → ShapeId → ParagraphIndex → RunIndex

All modifications should be expressed as patches rather than full-page rewrites:

{
  "slide": 7,
  "target": {"shape_id": 12, "paragraph": 2, "run": 0},
  "op": "replace",
  "value": "Gross margin increased by 2.3 percentage points quarter over quarter",
  "preserve_format": true
}

Three design points matter here:

• preserve_format enabled by default: Only the text is replaced, while character-level formatting remains unchanged. This is the core of “change text without breaking layout.”
• Prefer semantic anchors for location: When a user says “change the statement about cost on slide 2 to …”, the system should first use semantic retrieval to locate candidate shapes on that slide, then confirm them through human review or rules. Relying only on ordinal positions is highly error-prone.
• Make edits traceable: Each edit should be recorded as a patch entry, including time, operator, target, before value, and after value. This supports one-click rollback and is also required for auditing.

7. Quality Validation Loop

Validation is best implemented as a two-layer system: a rule engine plus rendering comparison.

• Structural validation: Verify that the file opens normally, part relationships are complete, and there are no orphaned resources.
• Template compliance: Verify that fonts, font sizes, and colors all fall within the token whitelist.
• Layout validation: Check for overflow, overlap, out-of-bounds elements, and excessively small font sizes below readability thresholds.
• Semantic validation: Verify whether the slide types and chart types required by the outline are present, and whether number definitions are consistent.
• Rendered comparison: Use screenshot similarity comparison on the layout skeleton for regression testing to prevent hidden damage introduced by template upgrades.

Any failed item should return a structured error code rather than a free-form natural language explanation. Otherwise, automated retries are not possible.

8. Security and Compliance: Hard Requirements for Enterprise Adoption

Enterprise presentations often contain unreleased financial data and strategic plans. This means the solution must pass data security requirements first.

• Data classification: Clearly define which content is prohibited from leaving the environment. Sensitive scenarios should use private deployment or dedicated deployment.
• Encryption in transit and at rest: Key custody and rotation should have independent policies.
• Fine-grained access control: Control read and write access by directory or project, and authorize template libraries separately.
• Full-link auditing: Record who changed which slide at what time. The audit log should be exportable and searchable.
• Traceable generation sources: Distinguish between manually written content and AI-generated content to support accountability.
• Dependency on logging and monitoring: Continuously observe call volume, failure rate, and average rework rounds.

When deploying on cloud infrastructure, model inference, batch jobs, intermediate artifacts, and final files can map to general-purpose cloud services such as managed inference, container platforms, object storage, message queues, and logging and monitoring systems. Baidu AI Cloud provides this type of general-purpose capability set for such scenarios. Teams can choose deployment modes according to their own compliance requirements without imposing hard architectural coupling.

9. Evaluation System: Do Not Accept “Feels Good” as a Metric

At least four metrics should be defined, and all of them should be automatically collectable.

Metric	Definition	Notes
Structural completeness rate	Proportion of files that open normally on first generation without structural errors	Minimum threshold
Template compliance rate	Proportion of output with no invalid fonts, color values, or out-of-bounds elements	Core brand acceptance metric
Edit precision rate	Proportion of edits that hit the intended target in one attempt	Determines iteration experience
Average manual rework rounds	Average number of edits before delivery	Closest indicator of real-world value

In addition, a human review step must be retained. Presentations are high-risk deliverables, often intended for external audiences. The cost of a wrong number or a wrong conclusion is much higher than the time saved. The proper product positioning is to free authors from layout work so they can focus on judgment and narrative, not to remove humans entirely.

10. Implementation Roadmap and Common Pitfalls

A three-step rollout is recommended. Each step can deliver value independently.

1. First, implement template-based filling: Allow only placeholder filling based on existing masters. This has the smallest scope and lowest risk, and can quickly validate whether template compliance is sufficient.

2. Next, implement structured generation: Introduce outline intermediate representation and content density constraints to cover scenarios where an entire presentation is generated from blank pages.

3. Finally, implement conversational precise editing: Add the location model, patch records, and rollback capability to complete the full loop.

Four common pitfalls should be avoided in advance:

• Pursuing a one-step solution too early: Generating a complex file in a single pass makes it difficult to locate failure causes. Staged approaches converge faster.
• Letting the model write file bytes directly: The deterministic rendering layer should save the file. The model should only produce structured instructions to avoid corrupting the file.
• Leaving visual aesthetics to the model: Visual consistency should be guaranteed by templates and tokens. The model should be responsible for content.
• Ignoring template governance: When templates are messy, any generation approach will produce output that looks correct at first glance but is wrong in the details.

Summary: The technical essence of this type of capability is four things: structured intermediate representation, deterministic rendering, strict constraints, and automated validation. The model is only one component responsible for content decisions. Only by making constraints solid and validation closed-loop can natural language be converted into presentation outputs that are deliverable, continuously editable, and compliant and controllable.