Beyond Parameters: How Post-Training Advances Enhance LLM Capabilities in Code, 3D, and Finance

The open-source AI community recently witnessed a significant capability upgrade. A domestic LLM team released a comprehensively enhanced model version built upon its base model through a systematic post-training pipeline. Unlike the traditional narrative of scaling parameters, this update focuses on data construction, reward modeling, and task generalization during the post-training phase, achieving simultaneous progress across code generation, 3D modeling, and financial document analysis. This article dissects the methodologies and engineering practices behind these improvements, providing technical insights for developers and enterprises during model selection and integration.

1. Why Post-Training is the New Battleground for Capability Leaps

Pre-training defines a model’s knowledge base, while post-training determines whether it “can get things right.” The current mainstream post-training pipeline typically involves three stages:

1. Supervised Fine-Tuning (SFT): Aligning output formats and reasoning styles using high-quality task trajectories.
2. Preference Optimization (e.g., DPO, RLHF variants): Constraining the model’s decision-making tendencies using pairwise comparison data.
3. Reinforcement Learning with Verifiable Rewards (RLVR): Directly using result correctness as the reward signal for tasks with clear judging criteria (e.g., code passing tests, exact mathematical answers, executable scripts).

Code and 3D script generation perfectly fit this third category—whether the output is usable can be objectively determined by compilation, execution, or rendering results. This means the post-training phase can automatically construct training signals at scale without relying on expensive manual annotation. This is the technical root cause for the most significant improvements in code and 3D capabilities in this recent upgrade.

It is worth emphasizing that the cost structure of post-training differs from traditional fine-tuning: the engineering effort for data construction and reward design often exceeds the training itself. A reusable lesson is to use “task verifiability” as the first filter for data selection—prioritize accumulating auto-scorable data before gradually expanding to more subjective tasks.

2. Code Capabilities: Optimizing Performance and Cost on Terminal Tasks

2.1 Focus of Terminal-Style Benchmarks

Terminal-style code benchmarks are fundamentally different from traditional function-level code completion tests. They require the model to perform multi-step operations in a real command-line environment: reading error messages, locating files, modifying code, running tests, and iteratively fixing issues. These tasks assess comprehensive abilities in long-range planning, tool calling, and self-correction, closely mirroring actual development workflows.

According to official disclosures, the new model version achieved high scores on this type of benchmark, leading among similar open-source models. In terms of cost, official statistics show that its unit task cost is at a competitive level among frontier models—while slightly higher per task compared to some lightweight models known for low prices, its task completion rate is significantly better, resulting in a higher overall cost-performance ratio.

2.2 Balancing Cost and Performance

For engineering teams, model selection should not focus solely on the single-call price, but rather on the “total cost per completed task”:

Effective Cost = (Single Call Cost × Average Attempts) / Task Success Rate

A cheap model that requires repeated retries might have a much higher effective cost than a slightly more expensive model with a higher first-pass success rate. In practice, the following evaluation steps are recommended:

• Extract 50 to 100 issues or failing test cases from real repositories to construct an internal evaluation set.
• Record each model’s first-pass success rate, average interaction rounds, and total token consumption.
• Rank models based on “effective cost” rather than “unit price”.
• Track high-frequency tasks (e.g., unit test fixes, dependency upgrades) separately to prevent averages from masking long-tail issues.

2.3 Integration Recommendations

When integrating such models into CI/CD pipelines, a sandboxed execution and feedback-loop architecture is recommended. The model should only generate patches and commands, while actual execution occurs in an isolated container. Test results are fed back to the model as signals for the next round of corrections. This leverages the model’s self-correction capabilities while preventing untrusted code from directly touching the production environment. It is crucial to restrict network access and file system mounts in the sandbox to prevent malicious model-generated code from stealing host environment credentials or data.

3. 3D Modeling: From “Calling Tools” to “Writing Scripts”

3.1 Shift in Capability Positioning

Previously, the mainstream way for models to participate in 3D creation was by relying on external tool protocols (such as various MCP services) to call modeling software interfaces, with the model acting merely as a “decision maker.” A notable shift in the new version is that the model can directly generate script code tailored for professional modeling tools (e.g., geometry construction, material assignment, layout adjustments), completing asset building and detailing without an intermediate protocol layer.

The technical significance of this shift is that scripts are plain text, version-controllable, and parameterizable. The model’s script generation capability directly translates into programming capability for the modeling process. For scenarios requiring batch generation of variants (e.g., different colors or sizes of the same product), the reusability of a scripted path far exceeds that of interactive operations.

3.2 Evaluation Performance in Spatial Reasoning

In benchmarks for CAD-type tasks, the new version scored close to the first tier when utilizing tools, achieving top-tier results among open-source models. Objectively, there remains a slight gap compared to top closed-source models, primarily in constraint satisfaction and multi-part interference checks within complex assemblies. These problems require deep spatial reasoning and represent a key focus for future iterations.

3.3 Engineering Implementation Path

Integrating scripted modeling into production workflows can follow a layered structure. The pseudo-code below uses the Blender Python API as a directional reference and must be replaced with the target tool’s SDK before running:

# Illustrative: Scripted modeling pipeline based on Blender Python API (replace with target tool SDK)
import bpy  # Illustrative only, replace with the Python binding of the corresponding modeling tool
def build_asset(spec: dict) -> Asset:
    script = model.generate(
        task="Modeling script generation",
        inputs={"spec": spec, "target_tool": "General modeling environment"},
        constraints=["Executable", "Parameterized", "Consistent units"]
    )
    validate(script)          # Static check: syntax, API validity
    result = sandbox_run(script)  # Sandbox execution, produces geometry and materials
    if not result.ok:
        script = model.repair(script, result.errors)  # Iterate based on errors
    return export(result, formats=["Model file", "Preview video"])

Key engineering points include: front-loading static validation (to avoid invalid executions), isolated sandbox execution, structured error feedback (to accelerate convergence during repair rounds), and standardized output formats (facilitating downstream printing, rendering, or importing into other pipelines).

3.4 Value of Online Preview and Sharing

Accompanying online preview and editing capabilities lower the barrier to using 3D content: generated results can be viewed and adjusted directly in the browser, then exported as printable files or dynamic preview assets. For content creators, this significantly shortens the link from “idea” to “deliverable.” For enterprises, it enables the rapid production of marketing assets or product prototypes, reducing initial reliance on specialized modeling personnel.

4. Financial Document Analysis: Retrieval, Multi-step Reasoning, and Hallucination Control

4.1 Task Challenges

Real-world financial document analysis is not simple Q&A; it is a composite task involving cross-document retrieval, caliber reconciliation, and multi-step numerical reasoning. A typical query might be: “Compare the changes in disclosure calibers for this item over the past three annual reports and calculate the adjusted compound growth rate.” This requires the model to locate multiple documents, identify caliber differences, execute calculations, and provide traceable conclusions.

The new version achieved leading scores on complex analysis benchmarks using real financial documents, and showed significant improvement in evaluations covering complete investment workflows (from target screening to profitability analysis), placing it near the first tier. This demonstrates that the structured reasoning data and tool-usage trajectories introduced during post-training yielded practical effects.

4.2 Engineering Methods to Reduce Hallucinations

Internal stress tests disclosed by the official team show that the new version significantly improved hallucination control, with error rates dropping substantially compared to the previous generation. Beyond model-side improvements, the engineering side can stack the following methods:

• Mandatory Citations: Require every numerical conclusion to include document page numbers or paragraph locations.
• Externalized Computation: Delegate numerical operations to deterministic calculation tools; the model only handles orchestration and interpretation.
• Cross-Validation: Require at least two corroborating sources for key metrics. Explicitly flag conflicts rather than forcefully merging them.
• Confidence-Based Triage: Route low-confidence results to manual review queues instead of outputting them directly.

Furthermore, in financial scenarios, compliance requirements must be carefully observed, such as data citation and conclusion statement constraints found in public company disclosure regulations, to avoid model outputs violating relevant regulatory rules.

5. Selection and Implementation Recommendations

Overall, this upgrade reflects a clear trend: post-training is becoming the primary lever for open-source models to close the gap with closed-source frontiers, and verifiable tasks are the most effective entry point. Recommendations for enterprise users include:

1. Layer by Task Verifiability: Prioritize deploying tasks that can be auto-scored, such as code fixes and script generation, for the most direct returns.
2. Build Internal Evaluation Sets: Public benchmarks are for reference only; evaluation sets based on real business distributions are the true selection criteria.
3. Focus on Effective Cost: Make decisions based on total cost weighted by task success rate, not unit price.
4. Maintain Human Fallbacks: In high-risk scenarios like finance and modeling, position the model as an “accelerator” rather than a “decision maker.”
5. Prioritize Pipeline Engineering: Supporting infrastructure like sandboxes, validation, feedback loops, and output standardization often determines the final user experience more than the model itself.
6. Conduct Periodic Re-evaluations: Model versions iterate rapidly. Re-score using internal evaluation sets quarterly to ensure selection decisions remain current.

The capability boundaries of open-source models are still shifting rapidly. For developers, what truly creates a competitive edge is not “which model was used,” but whether an engineering system that is verifiable, iterable, and operable can be built around the model.