From Code to 3D: Decoding the Post-Training Capability Leap in Large Models

Introduction: Post-Training as the Battleground for Capability Leaps

As pretraining of foundation models gradually converges, post-training—including supervised fine-tuning (SFT), reinforcement learning from human feedback (RLHF), and reinforcement learning with verifiable rewards (RLVR)—has become the dividing line that determines how much of a model’s potential is actually realized. The same generation of base models, subjected to post-training of different scale and quality, can perform like entirely different product generations on vertical tasks.

Recent industry practice shows a clear trend: model teams are shifting focus from stacking parameters and pretraining data to scaling and refining the post-training stage—more high-quality trajectory data for agent scenarios, stricter verifiable reward signals, and more complete tool-use loops. The direct result is visible leaps in professional dimensions such as coding, 3D modeling, financial analysis, factual accuracy, and vulnerability research. This article breaks down the technical logic, evaluation methods, and engineering implementation points for each of these five directions.

1. Coding Capability: From “Writing Correct Functions” to “Completing Tasks End-to-End”

1. What Terminal-Style Benchmarks Actually Test

Traditional coding benchmarks focus on “completing functions and passing unit tests,” but the evaluation target of the new generation of terminal-task benchmarks has fundamentally changed: after receiving a real engineering problem, the model must autonomously complete the entire workflow in a terminal environment—installing dependencies, configuring the environment, modifying code, compiling and running, and iterating on fixes based on error messages. A typical structure includes:

• Task input: a containerized, isolated real project environment with defects or incomplete work;
• Execution process: the model acts as an agent, calling tools such as the shell and editor to advance through multiple steps;
• Judgment criteria: end-to-end results—tests pass and the service runs as expected—rather than generated code that “looks correct.”

The focus shifts from “syntax correctness rate” to “task success rate,” which explains why agent trajectory data in post-training (especially complete trajectories of self-repair after failure) is extremely valuable—it directly corresponds to the behavioral patterns these benchmarks require.

2. Self-Repair Capability Is the Watershed

In practice, what determines task success is often not whether the model gets it right the first time, but three underlying capabilities:

• Error localization: reading call stacks, reliably reproducing issues, and progressively narrowing scope rather than blindly retrying;
• Closed-loop iteration: forming a stable cycle of “modify → run → observe → modify again” without spinning in place on the same approach;
• Long-context consistency: maintaining consistent memory of project structure to avoid regression problems where “fixing A breaks B.”

From a post-training perspective, these capabilities are mainly injected through two paths: first, curating or synthesizing high-quality repair trajectory data (including complete paths from failure to success); second, reinforcement learning with verifiable rewards—where the reward signal is “final tests pass,” forcing the model to learn effective exploration strategies in sparse-reward multi-step environments.

3. Cost Perspective: Cheap Unit Price ≠ Low Total Cost

When evaluating coding task costs, you should not look only at the price per million tokens, but calculate the “expected cost per successfully solved task”:

Expected cost = (unit price × average tokens consumed) ÷ task success rate

A model with an extremely low unit price but equally low success rate will repeatedly consume tokens on long tasks without finishing, and its overall cost may exceed that of a stronger model with a higher sticker price—plus the human cost of engineers taking over to troubleshoot. Common engineering optimizations include:

• Cascade routing: assigning simple tasks to lightweight models, escalating to stronger models on failure or complex scenarios;
• Budget control: setting maximum step and token limits per task, with alerts or handoff to humans when exceeded;
• Cache reuse: caching results for recurring build and test workflows to reduce wasted consumption.

2. 3D Modeling and Spatial Reasoning: Script-Driven Professional Toolchains

1. Trade-offs Between Two Technical Routes

Text-to-3D currently has two main routes. The native generation route has the model directly output mesh or voxel representations—fast end-to-end, but limited in geometric precision, topology quality, and editability. The tool-script route has the model understand natural language requirements and then generate code against the scripting interface of professional modeling software, with a mature engine handling the modeling. The latter has distinct advantages: outputs are parametric and editable—layout, materials, geometry, and lighting are all explicit properties that designers can continue refining in professional tools, and it is naturally compatible with industrial workflows (CAD drawings, 3D printing slicing, etc.).

This route poses three challenges for models:

• Spatial reasoning: relative positions, proportions, and occlusion relationships between objects;
• Domain knowledge: the modeling script’s interface system, coordinate conventions, units, and precision;
• Program synthesis: decomposing vague descriptions like “a terminal with an indoor atrium landscape” into component lists and modeling steps.

Compared with solutions that relay tools through external intermediate protocols, programming directly against the modeling tool’s scripting interface removes a layer of adaptation and more easily handles parametric modifications where “changing one place updates many.”

2. Typical Scenarios and Workflow Illustration

There are three typical application scenarios: architectural and interior visualization (rapid construction of atrium landscapes, greenery, and circulation paths), industrial part modeling (such as turbine-class surface modeling, which demands strong parametric capability), and consumer manufacturing (design and direct 3D printing of small items like lamps and storage pieces). A typical scripted modeling workflow looks like this (illustrative pseudocode with fictional interfaces):

scene = tool.scene.create(name="indoor_forest")
# 1. Ground and main structure
scene.add_ground(size=(120, 60))
scene.import_plan("floorplan.svg")
# 2. Parametric vegetation: batch placement with spacing constraints
for i, (x, z) in enumerate(sample_grid(area="atrium", spacing=4.5)):
    tree = scene.spawn("tree", variant=i % 3, scale=0.8 + 0.4 * noise(i))
    tree.set_material("foliage", roughness=0.7)
# 3. Lighting, camera, and multi-format export
scene.set_light(type="area", intensity=1200)
scene.place_camera(pos=(-30, 8, 20), look_at="atrium.center")
scene.export("atrium_v1", formats=["mesh", "print-ready", "video"])

Supporting online preview, model download, and video export capabilities can compress the “generate → inspect → share” loop into a single workflow—a key step in moving 3D capability from model to product.

3. Evaluation Points: Tool-in-the-Loop, Not Just Rendered Images

3D evaluation should focus on three levels:

• Geometric correctness: watertightness, normal consistency, and whether face count and topology meet printing or rendering requirements;
• Semantic conformance: whether key objects from the requirements are present, and whether proportions and layout are reasonable;
• Editability: whether outputs are structured and parametric, and how much effort designers need to take over.

The industry-standard “tool-in-the-loop” CAD benchmarks connect models to real modeling environments and score by conformance of the final artifact to specifications. When selecting models, prioritize results from such evaluations rather than the visual appeal of static rendered images.

3. Financial Document Analysis: Retrieval, Cross-Document Verification, and Multi-Step Reasoning

Financial scenarios are a comprehensive stress test for models: financial reports and announcements mix tables with unstructured text; a single conclusion often requires cross-validation across multiple documents (such as consistency of accounting bases between annual report notes and audit reports); numerical calculations involve unit conversion, ratios, and year-over-year or quarter-over-quarter comparisons, and any error in an intermediate step invalidates the conclusion.

1. Finance Is a High-Risk Zone for Hallucination

Financial numbers have strong “pseudo-credibility”—when a model fabricates a number with correct formatting and plausible magnitude, non-expert readers can hardly notice. Therefore, financial factuality evaluations typically construct “traceable answers” based on real anonymized documents, focusing on three points:

• Whether answers are strictly grounded in the given materials rather than relying on parameter memory;
• Whether the model explicitly states “insufficient evidence” for information unavailable in the materials rather than forcing an answer;
• Whether the intermediate process of numerical calculation is inspectable and re-verifiable.

2. From Single-Point Q&A to Complete Investment Workflows

A deeper level of evaluation examines “workflow completeness”: end-to-end support from target screening, financial data extraction, profitability and valuation analysis, to conclusion output. It requires the model to maintain consistent accounting bases and not lose constraint conditions across long-chain tasks. This places extremely high demands on post-training: real financial corpora must be used to construct training data with verification signals, making “every step verifiable” the default behavior.

3. Engineering Practice Recommendations

• Mandatory citation: attach source paragraphs or table locations to every key number;
• Dual-channel verification: run numerical conclusions through both “generation + programmatic recomputation” pipelines, blocking on inconsistency;
• Basis management: financial report revisions and accounting policy changes must be promptly reflected in retrieval indexes and context.

4. Hallucination Suppression: From Probabilistic Generation to Evidence Constraints

Factuality is the foundation of all vertical capabilities. Leading models have generally shown significant declines in hallucination error rates in internal stress tests, with three main technical roots:

• Verifiable rewards: answers must be checkable and traceable; unverifiable responses receive no high reward;
• Refusal training: explicitly training models to express uncertainty when evidence is insufficient rather than forcing an answer;
• Internalized retrieval augmentation: making “retrieve first, then answer” a default behavioral habit.

For enterprises, hallucination evaluation should not stop at public leaderboards; it is more important to build domain-internal adversarial evaluation sets: specifically collecting trap questions that occur frequently in business but are error-prone for models (outdated data, entities with identical names, basis differences, etc.), and continuously tracking error rate changes. Internal benchmarks often predict online performance better than public leaderboards.

5. Vulnerability Research: Security Capabilities Spill Over with Training Scale

An easily overlooked phenomenon: as post-training scale expands, model capabilities on vulnerability research tasks continue to improve—including reading complex code to locate defects, understanding vulnerability trigger conditions, and writing proofs of concept. This is not surprising in principle: the large volume of code review and defect repair trajectories injected during post-training inherently reinforces the model’s defect recognition circuits.

But this double-edged sword requires a supporting governance framework:

• Tiered access: high-risk capabilities opened in a controlled manner through permission tiers and use-case review;
• Red team first: complete adversarial red team testing before capability release, covering attack surfaces such as jailbreaks and indirect injection;
• Full-chain auditing: log retention and traceability standards for security research calls should be higher than for general scenarios.

6. Selection and Deployment: A Five-Dimension Evaluation Framework

Based on the above analysis, enterprises are advised to build model evaluation frameworks across five dimensions:

1. Task success rate: construct evaluation sets from your own business samples and look at end-to-end success rates, not static leaderboard scores;
2. Cost per task: calculated by combining unit price, average consumption, and success rate;
3. Factuality and traceability: error rate performance on domain-internal adversarial evaluation sets;
4. Toolchain compatibility: integration cost with existing R&D tools, modeling software, and data platforms;
5. Governance and compliance: completeness of permission tiers, log auditing, and content safety policies.

For deployment architecture, general-purpose capabilities from cloud platforms such as Baidu AI Cloud can accelerate closed-loop construction: use container platforms to host evaluation pipelines and batch-run comparative experiments across models; use object storage to uniformly manage evaluation datasets, model outputs, and traceability materials; use logging services and monitoring alerts to continuously track online task success rates, token costs, and hallucination interception rates, forming an iterative loop of “evaluate—monitor—re-evaluate.”

Conclusion

Post-training has become the main battleground of large model competition: pretraining gaps between base models of the same generation are often quickly erased or amplified by post-training quality. For developers and enterprise users, this brings two direct takeaways: first, do not let paper metrics like parameter count drive model selection—let your own business evaluation sets speak; second, treat evaluation and monitoring as first-class citizens and engineer them accordingly—only with continuously observable curves for cost, success rate, and factuality can you stay ahead in a rapidly iterating market. Capabilities are leaping, and evaluation frameworks must evolve in step.