Post-Training Evolution of Chinese Large Models: From Code Intelligence to 3D Creation

Why Post-Training Has Become the Capability Differentiator

The iteration rhythm of large models is shifting. Pre-training focuses on data scale and compute reserves, but as base model capabilities converge, the real gap emerges in the post-training phase—encompassing supervised fine-tuning, preference alignment, tool-use training, and reasoning trace distillation. A base model may perform modestly at release, yet after a round of high-quality post-training, its performance on specific tasks can improve severalfold.

A recent open-source model update from a cloud vendor exemplifies this approach. The version builds on its predecessor through post-training enhancements, delivering significant gains across code generation, 3D modeling, and financial document analysis. This article sets aside brand specifics and instead examines what these post-training enhancements actually do, why they work, and which engineering practices developers can adopt.

Core Technical Paths in Post-Training

Based on publicly available technical information, post-training capability enhancement typically follows three paths:

• Task-specific fine-tuning: Supervised fine-tuning on high-quality domain data (code repositories, CAD scripts, financial statements) to teach the model input-output patterns for specific tasks.
• Tool invocation and script generation training: Teaching the model to output operational steps rather than direct answers. In 3D modeling, for instance, the model generates executable scripts for professional software instead of raw mesh vertices.
• Reasoning trace optimization: Using rejection sampling, process reward modeling, and similar techniques to filter high-quality reasoning chains, then distilling them back into the model to improve multi-step reasoning stability.

These paths are not used in isolation; real-world engineering typically combines them. The following sections analyze each in the context of code, 3D, and financial scenarios.

Code Intelligence: Balancing Cost and Performance on Terminal Tasks

Evaluation Logic for Terminal-Class Code Tasks

Terminal benchmarks assess a model’s ability to operate in real command-line environments: understanding task descriptions, generating correct command sequences, handling filesystem operations, parsing outputs, and correcting errors. These tasks differ fundamentally from function-level code generation—they require “environment awareness,” not just syntactic correctness.

On such benchmarks, post-training-enhanced open-source models can approach the level of leading closed-source models while offering clear cost advantages. This raises an important question: why does cost control matter so much in these tasks?

Engineering Trade-offs in Cost-Sensitive Scenarios

Terminal tasks typically involve multi-turn interaction: the model executes commands, reads outputs, then decides the next action. Each turn is an inference call, and token consumption scales linearly with task complexity. If per-call costs are too high, total costs for long tasks quickly spiral out of control.

From an engineering perspective, cost control measures include:

• Inference step compression: Training the model to complete tasks in fewer interaction turns, reducing ineffective exploration.
• Output length constraints: Terminal commands are typically short; the model should not generate verbose explanatory text.
• Caching and reuse: Caching repeated environment queries to avoid redundant inference.

The following pseudocode illustrates a terminal task execution loop, showing how a model completes tasks through scripted operations:

# Illustrative pseudocode: terminal task execution loop
def run_terminal_task(task_description, max_steps=20):
    context = init_context(task_description)
    for step in range(max_steps):
        # Model generates next command and expected result
        action = model.generate(context, mode="terminal_action")
        if action.type == "finish":
            return action.result
        # Execute command and capture output
        observation = execute_in_sandbox(action.command)
        # Append observation to context for next turn
        context = update_context(context, action, observation)
    return timeout_result()

The key element is mode="terminal_action"—the post-training phase requires specially constructed data for this action space, teaching the model to choose between “generate command” and “declare completion.” Constructing such training data is costly, but once done, the model’s generalization on similar tasks improves significantly.

Gap Analysis with Closed-Source Models

Public benchmarks show that leading closed-source models still hold an edge on terminal tasks, but the gap is narrowing. Open-source models have already overtaken in some subcategories at lower cost. For enterprise users, this means open-source solutions are now viable in scenarios like CI/CD automation, operations script generation, and test case writing.

3D Modeling: The Scripted Generation Approach

Why Scripts Instead of Direct Mesh Generation

3D content generation offers multiple technical routes: direct mesh generation, implicit field generation, multi-view generation with reconstruction, and others. But these routes share a fundamental flaw: limited editability. Generated meshes resist parametric adjustment, geometry and materials are tightly coupled, and downstream modifications are expensive.

Scripted generation takes a different path: the model outputs scripts executable by professional modeling software, which then generates the final asset. The advantages:

• Parametric editability: Dimensions, positions, and materials in the script are explicit parameters, easy to adjust.
• Reusability: The same script can generate batches of variants.
• Workflow compatibility: Modelers can continue adjusting directly in professional software.

From public case studies, post-training-enhanced models can generate complete scripts from natural language descriptions—covering geometry construction, material assignment, and layout adjustments—for tasks ranging from interior scene setup to mechanical structure modeling and product appearance design.

Training Essentials for Script Generation

The challenge in training models to generate modeling scripts is not syntax—it’s spatial reasoning. The model must understand constraints like “the lampshade should sit above the lamp base” or “turbofan blades need to align along the axial direction.”

Engineering approaches typically include:

• Structured intermediate representations: Decomposing modeling tasks into “object list + spatial relationships + material properties” before mapping to scripts.
• Execution feedback loops: Actually executing generated scripts in the training environment to check for errors and geometric plausibility, using execution results as reward signals.
• Multi-turn correction training: Teaching models to fix scripts based on execution error messages rather than generating everything in one pass.

Below is an illustrative modeling script structure showing the code form the model needs to generate:

# Illustrative pseudocode: structured generation of a modeling script
scene = Scene()
# 1. Geometry construction
lamp_base = create_cylinder(radius=0.08, height=0.02, location=(0, 0, 0))
lamp_pole = create_cylinder(radius=0.01, height=0.35, location=(0, 0, 0.02))
lamp_shade = create_cone(radius_top=0.12, radius_bottom=0.18,
                         height=0.15, location=(0, 0, 0.37))
# 2. Material assignment
assign_material(lamp_base, material="brushed_metal")
assign_material(lamp_shade, material="translucent_white")
# 3. Spatial relationship validation
assert is_above(lamp_shade, lamp_pole)
assert is_centered(lamp_pole, lamp_base)

Note the validation statements at the end—these are both part of the script and part of the training signal. Models that learn “self-check after generation” during training significantly reduce execution failure rates.

Online Preview and Export Capabilities

Once scripts are generated, a runtime environment must preview and export the results. Current technical solutions typically include an online 3D previewer supporting rotation, scaling, and material switching, plus export to standard formats (e.g., mesh formats for 3D printing) or rendering to images/videos. The technical challenge here: the script execution result must match what the previewer renders, avoiding “what you see is not what you get.”

Financial Document Analysis: Retrieval Augmentation and Hallucination Control

Reasoning Challenges in Complex Financial Documents

Financial document analysis tasks share several characteristics: long documents (annual reports often run hundreds of pages), heavy table usage, dense numerical calculations, and frequent cross-document references. Models must handle retrieval, table parsing, multi-step numerical computation, and conclusion verification.

For these tasks, post-training focus is not on “memorizing more financial knowledge” but on “learning more rigorous reasoning processes.” Specifically:

• Retrieval-augmented invocation training: Teaching the model to actively retrieve relevant passages when needed rather than relying on parametric memory.
• Table understanding specialization: Financial tables have complex layouts; models must learn to locate headers, align rows and columns, and handle merged cells.
• Intermediate validation in multi-step calculations: Inserting validation steps during numerical computation to reduce cumulative errors.

Engineering Control of Hallucination Rates

Financial scenarios have extremely low tolerance for hallucination. A fabricated number can lead to serious decision errors. Therefore, the post-training phase requires specially constructed hallucination stress tests to measure how the model behaves when it does not know an answer—specifically, whether it admits ignorance.

From an engineering perspective, hallucination control includes:

• Refusal training: Including samples in training data where the conclusion is “cannot be determined from the given documents,” teaching the model to output refusals when evidence is insufficient.
• Mandatory citation: Requiring the model to attach source references when giving conclusions, facilitating manual verification.
• Consistency checking: Asking the same question in different phrasings and checking for answer consistency; triggering manual review on inconsistency.

Public information indicates that after targeted post-training, error rates on hallucination stress tests can drop from high levels to single-digit percentages. This improvement is critical for financial deployment.

Investment Workflow Support

Beyond point document analysis, financial scenarios require the model to support complete workflows: from target screening, financial metric calculation, earnings forecasting, to report writing. This demands long-context management and task decomposition capabilities. The post-training phase typically constructs multi-stage task samples to help the model maintain goal consistency across long workflows.

Practical Insights for Developers

Data Quality Trumps Quantity in Post-Training

Across the three scenarios above, post-training effectiveness depends heavily on data quality. High-quality domain data—real terminal operation traces, modeling scripts with execution feedback, financial Q&A with citation annotations—improves specific task performance far more than massive generic data. Developers building domain-specific models should prioritize data construction.

Tool-Use Capabilities Require Explicit Training

Models do not naturally learn to “generate scripts instead of direct answers.” This requires deliberate action-space design and execution feedback loops. If your business involves professional software operations, plan tool-use training data early.

Cost Control Is Part of Engineering Feasibility

Performance gains cannot come at the cost of runaway expenses. In multi-turn interaction scenarios, inference step compression and output length constraints should be part of training objectives, not afterthought optimizations.

Hallucination Control Needs Independent Evaluation

Different scenarios tolerate hallucination differently. Build scenario-specific hallucination test sets, using refusal rate and citation accuracy as core metrics rather than relying solely on generic benchmark scores.

Conclusion

Post-training capability enhancement is becoming the main battleground in large model competition. From cost optimization in code terminal tasks, to scripted generation in 3D modeling, to retrieval augmentation and hallucination control in financial documents, the technical paths differ across scenarios—but the underlying logic is consistent: use high-quality domain data, execution feedback loops, and explicit behavioral constraints to steer base model capabilities toward specific tasks.

For developers, the focus should not be on any specific benchmark score, but on the engineering methods behind these capabilities: how to construct training data, how to design action spaces, and how to build evaluation systems. These methods hold reusable value across models and scenarios, and constitute the core competitive advantage in building domain-specific intelligent applications.