When large language models enter FMEA

In many enterprises, FMEA is repeatedly emphasized as "extremely important." However, when it comes to actual implementation, it often intimidates people. Relevant information is scattered across design documents, complaint records, meeting minutes, and historical reports, requiring repeated reviews. Inter - departmental meetings are held one after another, consuming a great deal of time and effort. Although the FMEA tables keep getting thicker, it's still hard to avoid missing key risks, and different people often come to inconsistent conclusions. As product complexity continues to increase and the volume of textual information multiplies, relying solely on manual labor to complete FMEA is becoming increasingly difficult and costly.

Meanwhile, a new type of AI technology proficient in handling large - scale textual information is rapidly developing. It can efficiently read, understand, and organize complex texts. This has prompted people to reconsider: Does FMEA have to be done through a large - scale manual effort? Can AI take on the arduous tasks of data organization and preliminary analysis, allowing experts to focus on judgment, selection, and decision - making, thus making FMEA more efficient and comprehensive while maintaining its professionalism? This article explores a more feasible direction in response to this real - world pain point.

What's the missing step in FMEA from "all - human" to "human - machine collaboration"?

Looking back at the development of FMEA, we can see that it's not a new concept. As early as in the aerospace and military industries, people began using FMEA to identify risks in advance and avoid catastrophic consequences. Later, various industry standards emerged, promoting this method to a wider range of manufacturing scenarios. However, regardless of how the standards have evolved, the core practices of FMEA have remained fundamentally unchanged - relying on manual analysis, dealing with bulky documents, and having dispersed experience. The knowledge gained from previous projects is difficult to reuse in subsequent ones.

In the past, some people tried to introduce AI technology to relieve the burden. They used machine learning, fuzzy logic, or multiple decision - making models to help calculate risk values and optimize rankings. These methods did improve efficiency in some specific areas, but they mainly addressed the issues of "more accurate calculation" or "faster ranking," offering limited help in dealing with the pain points of reading, understanding, and organizing a large amount of preliminary data.

In recent years, the emergence of large language models has brought new possibilities. These models are not good at calculating formulas but excel at "understanding text." They can comprehend the meaning of long texts and organize scattered information into structured results. Through appropriate questioning, combined with data retrieval, and even training with the enterprise's own data, the models can increasingly act like a "virtual assistant" familiar with the internal language.

Of course, introducing large language models into FMEA has its drawbacks as well. It can quickly process a large amount of historical data, reduce omissions, and enable small teams to handle complex analyses. However, it also brings risks such as data security, misunderstanding, and over - reliance. Just because the model seems to "sound correct" doesn't mean it's truly suitable for your products and scenarios.

Therefore, what is truly lacking in this field is not some dazzling AI technique, but a systematic approach to safely integrate large language models into the entire FMEA process, with real - world cases proving that it is usable, effective, and controllable.

The implementation path of "AI + FMEA" from method to system

What truly matters is not "using AI to create an FMEA table," but how to stably and controllably integrate AI into the entire FMEA process. The "AI + FMEA framework" introduced here is essentially a practical methodology that answers a key question: Without weakening professional judgment, in which aspects can AI truly relieve human burdens?

This method breaks down traditional FMEA into five clear steps.

Step 1: Enterprises need to systematically collect relevant information, including design data, historical issues, customer complaints, and feedback.

Step 2: Pre - process these materials by cleaning irrelevant content and standardizing formats to lay a foundation for subsequent analysis.

Step 3: Based on the enterprise's data conditions and security requirements, choose an appropriate way to use the model. For example, use the model directly through prompts, or enhance retrieval by combining internal data. Custom training can be carried out if necessary.

Step 4: With the assistance of the model, extract key information required for FMEA from a large amount of text, such as potential failure modes, impacts, causes, current controls, and improvement suggestions.

Step 5: Integrate these results into the enterprise's existing information system instead of leaving them as one - time analysis results.

In practice, the design at the information system level is particularly emphasized. FMEA should not be just a table that is archived after completion but should become part of the enterprise's knowledge system. Once the analysis results generated by AI enter a platform similar to a knowledge management system, new projects can reuse existing experience. Management can also regularly see which components have the most concentrated problems and which failures occur repeatedly, thus better supporting decisions on engineering changes and corrective actions.

The core value of this framework lies in that large language models do not replace experts. Instead, they gradually transform the enterprise's scattered and hard - to - reuse experience into sustainable system capabilities, truly upgrading FMEA from a "one - time task" to a long - term management tool.

It's not about "claiming it's useful," but using data to verify "whether it can be used"

Whether a new method is worth promoting depends not on how advanced the concept is but on whether there is verifiable evidence. In this section, the research team chose a relatively conservative and industry - acceptable approach to test the actual value of "AI's participation in FMEA."

To avoid touching on corporate secrets, they used public data - a large number of real user reviews. Although these reviews are not engineering documents, they are exactly where the "problem clues" are most concentrated. With a data scale of hundreds of thousands of reviews, they were first aggregated and then filtered, simulating the typical scenario of "abundant data with a lot of noise" in real enterprises.

In the data - processing stage, the first step is not direct analysis but to find valuable information.

On one hand, by identifying whether specific components are mentioned in the reviews, the problem objects are initially located.

On the other hand, negative reviews are mainly filtered because complaints and dissatisfaction are more likely to hide potential failures.

This step uses both simple rules and models to handle complex situations such as spelling mistakes and multiple languages, making it closer to the real application environment.

Subsequently, different large language models were used for the same task: extracting information such as possible failure modes and problem manifestations from these reviews. Meanwhile, human experts first provided "reference answers," which were then compared with the model results, and the similarity was used to evaluate the model's performance.

The conclusion is clear: Large language models have obvious advantages in processing speed and problem coverage, capable of finding a large number of potential problem clues from massive text in a short time. However, it must also be noted that the models are not "always correct." There are some problems that humans can identify but the models miss, and some that the models identify but experts do not consider as engineering failures.

Therefore, the key message conveyed by this case is not that "AI can replace experts," but that large language models are very suitable for preliminary screening and clue extraction, while the final judgment and qualitative analysis must still be done by professionals. This is the real boundary of human - machine collaboration in the FMEA scenario.

From "seemingly usable" to "stably usable in enterprises"

Introducing this method into enterprises is not simply a matter of copying the process. This section discusses the most easily overlooked but most realistic issues in the implementation process.

In real - world scenarios, if an enterprise wants to analyze the failure situation of a certain component in a large number of documents, reviews, or historical data, there are usually two approaches.

One approach is to comprehensively extract information from all data first and then filter it by component. This method has the widest coverage and is less likely to miss information, but it requires more computing power and time.

The other approach is to conduct targeted analysis around a specific component from the start, directly extracting relevant information through more focused questions. This is more efficient, but it requires a clearly defined problem scope. Different enterprises at different stages may require different strategies.

In practical applications, efficiency and cost can be further balanced through batch processing, classification before extraction, etc. These are not just technical gimmicks but "engineering details" that determine whether the system can run in the long term.

It's also important to emphasize a point that is easily misunderstood: Textual data such as user reviews are more suitable for finding problem clues rather than directly obtaining rigorous engineering values. Therefore, the severity, occurrence frequency, or detectability given by large language models should be regarded as reference suggestions rather than directly adoptable conclusions. When making real - world decisions, it is necessary to combine the enterprise's internal data system and have it verified by experienced personnel.

Large language models are very good at finding "signals worthy of attention" in messy information. However, whenever it comes to key numbers and engineering judgments, human involvement is still required, and it should be based on the enterprise's own data and standard system. Only by clarifying this boundary can AI be used stably and for a long time in real enterprises.

It's not about "whether to use AI," but "how to use it correctly"

Large language models have clearly demonstrated their value in the FMEA scenario. Facing a large amount of textual data such as design specifications, historical problems, and complaint records, LLM can significantly improve analysis speed, reduce manual input, expand the coverage of risk identification, and thus lower the probability of missing key failures.

However, it must also be clear that FMEA is not suitable for full automation. Models are more suitable as "front - end assistants" responsible for information organization and clue mining. The real judgment, selection, and decision - making must still be done by experienced experts. Only with a clear division of labor between humans and machines can FMEA be both efficient and reliable.

Looking to the future, what truly determines whether this method can be implemented in enterprises in the long term is not just the model's capabilities themselves but the maturity of supporting research and practice. This includes how to deploy the model while ensuring data security, how to make the model better understand specific products and terms through industry - or enterprise - level custom training, how to reduce the risk of the model "seeming reasonable but being inaccurate," and how to continuously verify its effectiveness in larger - scale, real - world industrial scenarios. These are the key directions for the sustainable application of "AI + FMEA."

This article is from the WeChat official account "TPP Management Consulting," author: TPP Management Consulting. Republished by 36Kr with permission.