Today's article comes from the journal of Materials Genome Engineering Advances. The authors are Shu et al., from Xi'an Jiaotong University, in China. In this paper, they've taken DeepSeek-R1 and fine-tuned it for a very specific task: lattice-structure design.
DOI: 10.1002/mgea.70064
On January 20th, 2025, an obscure Chinese hedge fund called "High-Flyer" did something very odd for a hedge fund. They released a large language model. A very large language model. 671 billion parameters, 37 billion active parameters per token, a 128K-token context window, and distilled variants ranging from 1.5B to 70B parameters each. And bizarrely enough, the entire thing was open-weight. So that anyone around the world could download it, run it, and test it for themselves. And test it they did. Within a few days of its release virtually every major tech publication had covered it, researchers had started benchmarking, probing and adapting it, and many of the largest players in the space had issued public responses: to calm their investors or otherwise defend their market positions. But much of that was too late. By the end of that month the free chatbot application wrapped around that model had become the most downloaded freeware app on the iOS app store in the US. And Nvidia (the chipmaker powering the largest competitors) had lost 18% off its share price. Quite the debut. Quite the media frenzy. Quite the public declaration, from a firm that very few people outside of China even realized were developing a model at all.
That model's name was DeepSeek-R1. And now, 18 months later, the academic literature is just starting to become filled with the applications, pipelines, extensions and downstream models that make use of that release.
Today's paper is no exception. In it the authors have taken DeepSeek and fine-tuned it for a very specific task: lattice-structure design. And their process turned that system from one that performs fairly-ok in this domain (72% accuracy) to one that performs well above-average (nearly 95% accuracy). On today's episode we're going to walk through how they did it, and see what we can learn from their process. Let's dive in.
The authors' methodology had two main phases.
And it was that final pipeline, with the fine-tuning and knowledge-graph attached that performed so well. To understand why, we first need to learn a bit more about the domain that the authors are operating in: lattice structures.
Lattice structures are engineered materials built from repeating cellular units. Their appeal is that they allow geometry to become a design variable. By changing the topology, strut thickness, cell size, orientation, material, density, or manufacturing process, engineers can tune properties like stiffness, strength, energy absorption, anisotropy, Poisson's ratio or weight. But this configurability makes the design space enormous. And a small change in any variable can significantly alter the mechanical behavior across multiple scales. The winning designs, therefore, are usually constrained not just by physical tradeoffs (like strength vs weight) but by the practical limits of how many different candidate designs can be modeled, manufactured and tested. All of that adds up to an unmet need in the industry: a faster way to search the design space, connect scattered findings from the literature, and generate plausible design directions. To be clear: engineers still need finite-element analysis and experimental validation before any candidate becomes real, but they also need better tools for the earlier stage: figuring out which designs are even worth testing in the first place.
So that's exactly what the authors wanted to do here: lattice-structure design exploration. In practice, that means taking a desired engineering outcome, like isotropic elasticity, high energy absorption or a negative Poisson's ratio, and working backwards to plausible lattice architectures, materials, manufacturing parameters, and verification methods that could get you there. The authors' system therefore needs the ability not just to answer questions about lattices, but to turn a natural-language design requirement into a technically grounded direction.
While the out-of-the-box Deepseek model is incredibly powerful on its own, it's not a specialist. And the task we're talking about here requires an incredible amount of obscure, cross-linked engineering knowledge: topology-property relationships, additive-manufacturing constraints, defect mechanisms, multiscale mechanics, process windows, experimental precedents, and the vocabulary of lattice-material research. So when the authors put the default model up to the task, it (predictably) did alright, but not amazing. The baseline DeepSeek-R1-14B model reached 71.7% accuracy overall. And in the case studies, it tended to give generic advice, like "use topology optimization" or "adjust process parameters," without enough concrete structural guidance. It was especially weak when the answer required connecting manufacturing details to mechanical effects, like distinguishing defects that merely damage a lattice from controlled defects that can actually improve auxetic behavior. None of that is to say that the model is useless, just that it's fairly unreasonable and unrealistic to think that it could perform these tasks on its own. Lattice-material design is a narrow technical domain, and many of the important relationships are buried in research papers, figures, process notes and experimental contexts. A general model may know the language of the field, but that does not mean it has absorbed the logic needed for it to be able to reason like a domain expert. Enter: fine-tuning.
In fine tuning you take an existing pretrained model and continue training it on narrower data so that its weights adapt to the specific domain or task that you need it for. You are not training the model from scratch. You are shifting the model's behavior, vocabulary and reasoning habits toward the examples you care about, and away from general-purpose knowledge and skills. In practice, that means feeding it domain-specific text, and task-specific examples paired with expected answers until it becomes better at producing the kind of output that specialty requires.
And that's exactly what the authors did. They took the vanilla model and pretrained it on 2,500 full-text lattice-structure articles. This helped the model absorb the vocabulary and conceptual structure of the field. Then they instruction-tuned it on 35,000 curated question-answer pairs covering topology optimization, functional design, mechanical properties, multiscale modeling, dynamics, impact mechanics, manufacturing, and defects. And they used parameter-efficient fine-tuning, so most of the base model stayed frozen while a smaller set of trainable adaptation weights were updated incrementally. That process produced what they called "DeepSeek-Lattice": a domain-adapted version that improved the base from 71.7% accuracy to 82.9%. A substantial gain.
Could the authors have stopped there? Sure. But they didn't. Because they still thought they could squeeze more performance out of the system. The issue is: they had already fine-tuned it to death. So they needed another technique that could add and update domain knowledge without requiring more model parameters or retraining. Something that could be implemented at inference time instead. That's where the knowledge-graph came in. They built a lattice-material knowledge graph from 50,000 publications, extracting hundreds of thousands of entities and relationships about structures, properties, manufacturing methods, defects, and applications. Then they stored that graph in Neo4j.
This made a new type of behavior possible. When a user asks a design question, the system now extracts the key concepts, converts them into Neo4j-cypher queries, retrieves the relevant connected subgraph from that database, and then feeds that structured knowledge back into the model. The final response is then generated from both the fine-tuned model's internal knowledge and the retrieved graph context. What I'm describing might sound generally like "RAG" (retrieval augmented generation). And sure, it technically is. But it also isn't, not really. Simply because it's just so much more sophisticated than what we typically describe as a RAG setup. While a RAG system typically retrieves semantically similar text chunks from a vector database and pastes them into the model's context window, this one retrieves structured relationships between domain entities. It can follow links between lattice topologies, properties, manufacturing processes and design precedents. It can preserve provenance, check for conflicts, distinguish surface-level disagreements from true contradictions, and update the knowledge base when it gets new information. So instead of just giving the model more text, it gives the model a structured map of the field, tailored to the specific question and subdomain being reasoned-about at the time.
This, I'd argue, fundamentally changes the nature of the system. From a standard LLM to a domain-specialized assistant that can synthesize thousands of pieces of research, retrieve meaningful evidence, generate recommendations, and keep its knowledge current without needing to retrain the language model at all. Pretty impressive.
So how did they test it?
First, they built a benchmark of around 2,000 expert-curated multiple-choice questions across six lattice-structure subdomains: topology optimization, functional design, dynamics and impact mechanics, multiscale modeling, mechanical properties, and advanced manufacturing and defects. The questions were split across basic conceptual understanding, application-oriented problem solving and analytical reasoning. This way the benchmark was not just testing memorized definitions, but whether the models could apply domain knowledge to solve real design-style problems. Then they compared the base DeepSeek-R1-14B, the fine-tuned DeepSeek-Lattice model, a conventional 14B-plus-knowledge-graph variant, a few larger general-purpose models like DeepSeek-R1-670B, and the final DeepSeek-Lattice-KG system.
They also tested temporal scalability by adding more recent papers to the graph and checking whether these systems could answer questions about research that appeared after the original graph's cutoff date. And as I mentioned at the beginning, the results were very (very) impressive. DeepSeek-Lattice-KG reached 94.8% accuracy overall, compared with 71.7% for the base, 82.9% for the fine-tuned model alone, 84.2% for the conventional knowledge-graph version, and 88.2% for DeepSeek-R1-670B. Then on the 2025 emerging-topics benchmark, the old graph reached 77%, DeepSeek-R1-670B reached 81%, and the updated DeepSeek-Lattice-KG reached 93%: genuinely dominating the others.
So, what can we learn from this paper? Is the key takeaway that DeepSeek is awesome? No, I think it's a bit more nuanced than that. There are really three parts here:
Want to go deeper? Make sure you download the paper. There's a lot we didn't get to here. Including how the authors detect and resolve disagreements in the graph, how the keyword extraction and query generation steps were prompted and tuned, and the full breakdown of the comparison models they used in their evaluation.