A device intelligent recommendation method based on a large language model and a graph model

Abstract

The application relates to a device intelligent recommendation method based on a large language model and a graph model, which comprises the following steps: inputting a natural language for describing a device selection demand description through a large language model man-machine interaction interface; calling a Qwen32B large language model API, performing semantic analysis, and generating structured data in a Json format; converting the device selection demand into a graph database Cypher query language by extracting triplets in the Json data, performing multidimensional retrieval in a device knowledge graph, and returning a device ID; performing enhanced retrieval on the device ID returned by the graph in a device knowledge base; calling real-time data of a third-party system device through an API, filtering and screening; and constructing a device capability portrait and displaying the same. The application has higher precision and is more rapid.

Description

TECHNICAL FIELD

[0001] The application relates to a device intelligent recommendation method based on a large language model and a graph model, and belongs to the technical field of device intelligent management. BACKGROUND

[0002] Traditional device selection relies on manual implementation. The device selection process is as follows: the specific requirements for the device are proposed, and then an experienced engineer selects the device according to the requirements of the device. This requires a high level of skill for engineers, who need to be very familiar with many devices. The dependence of device selection on human experience is too high. Moreover, new devices are constantly emerging, and it is necessary to constantly update one's knowledge of new devices, which is a high work intensity and prone to memory confusion, leading to the possibility that the recommended device is not the optimal choice.

[0003] For example, a certain automobile electronic laboratory needs to select a test device for a new energy automobile battery management system (BMS), and the core requirements include:

[0004] 1. Test the voltage acquisition accuracy of the BMS in the temperature range of-40 DEG C to 85 DEG C.

[0005] 2. Verify the anti-interference ability of CAN bus communication.

[0006] 3. Capture millisecond-level pulse current (rise time <100us).

[0007] The traditional process pain points for the above requirements are as follows:

[0008] 1. A senior test engineer needs to manually compare the temperature drift parameters and protocol support list of 15+ devices (which takes 30+ minutes).

[0009] 2. Implicit requirements are easy to miss (such as “pulse current” needs to be associated with “bandwidth >=10MHz” parameters).

[0010] 3. The training period for new employees is long, and they need to go through a passive learning process of “consultation-operation-memory”.

[0011] As can be seen, relying on manpower for device selection recommendation is very inefficient, and there is a great risk that the recommended device is not the optimal choice, which leads to non-optimal decision-making and affects production efficiency or product performance. SUMMARY

[0012] In order to solve the above problems, the application discloses a device intelligent recommendation method based on a large language model and a graph model, and the specific technical solutions are as follows:

[0013] A device intelligent recommendation method based on a large language model and a graph model, comprising the following steps:

[0014] Step 1: Input Equipment Selection Requirements: Users input a natural language description of their equipment selection requirements through the large language model human-computer interaction interface;

[0015] Step 2: LLM Semantic Parsing: Call the Qwen32B Large Language Model API to perform semantic parsing and generate a structured data request format; the specific process is as follows: add descriptions to the prompt words, generate structured data in JSON format according to the template format, and the structured data content includes: intent category, explicit parameters, implicit requirements and entity relationships;

[0016] Step 3: Neo4j graph query: Extract triples from the structured JSON data using code, convert it into the Cypher query language for the graph database, perform multi-dimensional retrieval in the device knowledge graph, and return the device ID;

[0017] Step 4: RAG Search Enhancement: Perform enhanced search on the device IDs returned by the graph in the existing device knowledge base;

[0018] Step 5: Dynamic Status Filtering: Real-time data of device IDs in the SCADA system is retrieved through the API data interface, and filtered according to multiple dimensions such as device availability status, device failure rate, and device calibration time.

[0019] Step 6: Generate LLM inference decision: Build a device capability profile and display the device capability profile through a front-end visualization interface.

[0020] Furthermore, the natural language description of equipment selection requirements in step 1 includes key elements such as test objectives, performance indicators, and environmental conditions.

[0021] Furthermore, the specific process of semantic parsing in step 2 is as follows:

[0022] 2.1) Intent recognition: First, the Qwen32B large language model API interface is called, and then the PromptEngineering is used to automatically parse the requirements and determine the user's core testing objectives;

[0023] 2.2) Entity recognition: Identify specific performance parameters and technical indicators, and extract explicit parameters, including temperature range, protocol standard, and timing parameters;

[0024] 2.3) Relationship Establishment: Establish logical connections between explicit parameters;

[0025] 2.4) Implicit requirement derivation: Derivative requirements are automatically generated based on electronic principles.

[0026] Furthermore, the extraction of triples in step 3 includes:

[0027] Explicit parameter triples: including temperature range, protocol standard, and rise time.

[0028] Implicit demand triple: includes implicit bandwidth demand, implicit sampling rate demand, and implicit temperature drift compensation.

[0029] The derivation of the relational triplet includes deriving the bandwidth based on the rise time and deriving the required temperature drift compensation based on the temperature range.

[0030] Furthermore, the multi-dimensional retrieval in step 3 includes:

[0031] 3.1) Equipment-parameter relationship: Define technical specification constraints;

[0032] 3.2) Device-Rule Relationship: Experience-based logic in the storage domain;

[0033] 3.3) Device-Status Relationship: Dynamically linked to real-time data sources.

[0034] Furthermore, step 4, the enhanced retrieval, includes vectorized querying and multi-source retrieval. The multi-source retrieval includes equipment manual database retrieval, case database retrieval, standard document database retrieval, and contextual fusion retrieval, specifically:

[0035] 4.1) Vector retrieval: Based on similarity calculation using a vector database, quickly match the most relevant device knowledge;

[0036] 4.2) Local Knowledge Base: Construct a local knowledge base for equipment parameters, which includes a database of equipment manuals, a database of case studies, and a database of standard documents.

[0037] 4.3) Hybrid search engine: The Bge-Large-zh-v1.5 text embedding model is used to transform device parameter documents and user requirement descriptions into high-dimensional semantic vectors;

[0038] 4.4) Contextual Fusion Retrieval: The retrieval results are fused with user input requirements, and accurate recommendations are generated through the Qwen32B large language model.

[0039] Furthermore, the filtering rules in step 5 include:

[0040] a. The device is online and its availability status is online.

[0041] b. The failure rate is less than the failure rate threshold.

[0042] c. The next calibration time is longer than the set number of days.

[0043] If all the above conditions are met, the recommended output should be selected.

[0044] Furthermore, the decision in step 6 includes the following prompt words:

[0045] User requirements: Structured requirements;

[0046] Candidate Equipment: Equipment Technical Parameter Table;

[0047] Real-time status: Device status data;

[0048] Related knowledge: RAG search fragments.

[0049] Furthermore, the LLM inference decision in step 6 includes:

[0050] (1) Sort by matching degree in descending order.

[0051] (2) Compare and annotate key parameters.

[0052] (3) Explain the extent to which implicit needs are met.

[0053] (4) Additional risk warnings.

[0054] Furthermore, it also includes step 7: generating a visualized decision report from the recommendation results. The visualized decision report displays the main recommendation, alternative 1 and alternative 2, as well as the device model, matching degree, key parameter matching items, extension capability and dynamic prompts corresponding to the main recommendation, alternative 1 and alternative 2, and the key parameters and usage suggestions of the main recommendation.

[0055] The beneficial effects of this invention are:

[0056] This invention can quickly and accurately recommend devices, avoiding reliance on human experience and reducing the recommendation error rate. Attached Figure Description

[0057] Figure 1 This is a logic framework diagram of the present invention.

[0058] Figure 2 This is a flowchart illustrating the implementation of the present invention.

[0059] Figure 3 This is a screenshot of the equipment ledger table of this invention.

[0060] Figure 4 This is a visualized decision report diagram of the present invention. Detailed Implementation

[0061] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. It should be understood that the following specific embodiments are for illustrative purposes only and are not intended to limit the scope of the invention.

[0062] The following is in conjunction with the appendix Figure 1 and 2 Further explanation of the intelligent device recommendation method based on large language models, knowledge graphs, and RAG-enhanced knowledge retrieval technology in this invention:

[0063] Step S1, User Natural Language Input: The user inputs a description of the equipment selection requirements in natural language through the human-computer interaction interface. The description includes key elements such as test objectives, performance indicators, and environmental conditions.

[0064] Step S2, LLM semantic parsing: The backend system calls the Qwen32B large language model API to perform semantic parsing.

[0065] Entity recognition: Extract explicit parameters such as temperature range (-40~85℃), protocol standard (ISO 11898-2), and timing parameters (rise edge <100μs);

[0066] Relational reasoning: Establish logical connections between parameters (e.g., temperature range → temperature drift compensation requirements);

[0067] Implicit requirement derivation: Automatically generate derived requirements based on electronic principles (rise edge <100μs → bandwidth ≥10MHz).

[0068] Specifically, add a description to the prompt words. Please generate structured data in JSON format according to the following template. The structured data content is as follows:

[0069] {

[0070] "Intent Category": "BMS Test Equipment Selection"

[0071] "Explicit parameters": {

[0072] Temperature range: ["-40℃", "85℃"],

[0073] "Agreement Standard": ["ISO 11898-2"],

[0074] "Timing Parameters": {

[0075] "Rise time": "<100μs"

[0076] }

[0077] },

[0078] "Implicit needs": {

[0079] Bandwidth requirement: ≥10MHz

[0080] Sampling rate requirement: ≥10MS / s

[0081] "Temperature drift compensation requirement": "Yes"

[0082] },

[0083] "Entity Relationship": [

[0084] "Temperature range → Temperature drift compensation requirements"

[0085] "Rise time → Bandwidth requirement" ]

[0087] }

[0088] The specific process of semantic parsing is as follows:

[0089] 2.1) Intent recognition: First, the Qwen32B large language model API interface is called, and then the requirements are automatically parsed using PromptEngineering;

[0090] Core Prompt template structure:

[0091] Please strictly follow these steps to analyze user requirements:

[0092] ## Input:

[0093] {user_input}

[0094] ## Analysis Task:

[0095] 1. Intent Recognition: Determining the user's core testing objective.

[0096] 2. Entity Extraction: Identifying specific performance parameters and technical indicators.

[0097] 3. Relationship Establishment: Establishing logical relationships between relevant parameters.

[0098] 4. Implicit Requirements Derivation: Supplementing necessary but unstated requirements based on electronic principles.

[0099] ## Output format requirements:

[0100] Please output in JSON format, including the following fields:

[0101] - "intent": [List of intent categories]

[0102] - “explicit_parameters”: {parameter name: parameter value}

[0103] - "implicit_requirements": {implicit requirement name: requirement value}

[0104] - “parameter_relations”: [List of relation descriptions]

[0105] ## Domain Knowledge Reference:

[0106] {domain_knowledge_context}.

[0107] Example code:

[0108] def automated_requirement_parsing(user_input):

[0109] # Building a dynamic Prompt

[0110] prompt = build_parsing_prompt(user_input)

[0111] # Call the finely tuned Qwen32B model

[0112] response = call_qwen32b_api(prompt)

[0113] # Parse and validate the output

[0114] structured_output = validate_and_parse_response(response)

[0115] return structured_output

[0116] def build_parsing_prompt(user_input):

[0117] “Construct a Prompt containing the domain context”

[0118] domain_context = get_relevant_domain_knowledge(user_input)

[0119] prompt_template = "

[0120] As an equipment selection expert, please analyze the following requirements:

[0121] User requirement: "{user_input}"

[0122] Referenceable domain knowledge:

[0123] {domain_context}

[0124] Please output the JSON in the following structure:

[0125] {{

[0126] "intent": ["primary intent", "secondary intent"],

[0127] “explicit_parameters”: {{

[0128] "Parameter type": "Parameter value",

[0129] Temperature range: [Minimum temperature, Maximum temperature],

[0130] "Agreement Requirements": ["Agreement Standards"],

[0131] "Timing Parameters": {{

[0132] "Rise Time": "Value",

[0133] "Descent Time": "Value"

[0134] }}

[0135] }},

[0136] "implicit_requirements": {{

[0137] "Derived Requirements": "Requirement Values"

[0138] }},

[0139] “parameter_relations”: [

[0140] "Parameter A → Derivation → Parameter B" ]

[0142] }}

[0143] "return prompt_template.format(

[0144] user_input=user_input,

[0145] domain_context=domain_context

[0146] )”

[0147] def get_relevant_domain_knowledge(user_input):

[0148] "Retrieve relevant domain knowledge fragments based on user input" `relevant_knowledge = vector_search(user_input, domain_knowledge_base)`

[0149] return “\n”.join([f “- {item}” for item in relevant_knowledge]).

[0150] 2.2) Entity recognition: Extract explicit parameters, including temperature range, protocol standard, and timing parameters;

[0151] 2.3) Relational Reasoning: Establishing logical connections between explicit parameters;

[0152] 2.4) Implicit requirement derivation: Derivative requirements are automatically generated based on electronic principles.

[0153] Step S3, Neo4j graph query: The structured JSON data is extracted into triples by code and converted into the Cypher query language of the graph database. Multi-dimensional search is performed in the device knowledge graph to return the device ID;

[0154] The logic for extracting triples:

[0155] Explicit parameter triples:

[0156] (User requirement: Temperature range needed [-40℃, 85℃])

[0157] (User requirement: Protocol standard, "ISO 11898-2")

[0158] (User requirement: rise time < 100 μs)

[0159] Implicit demand triples:

[0160] (User requirements, implicit bandwidth requirements, "≥10MHz")

[0161] (User requirement, implicit sampling rate requirement, "≥10MS / s")

[0162] (User requirement, implicit temperature drift compensation, "Yes").

[0163] Derivation of relational triples:

[0164] (Rise time < 100μs, derived, bandwidth ≥ 10MHz)

[0165] (Temperature range -40~85℃, derived, temperature drift compensation required).

[0166] Based on the above logic, the Cypher query language corresponding to the graph database is generated.

[0167] / / Match devices that meet all conditions

[0168] MATCH (d:Device)

[0169] WHERE

[0170] / / Condition 1: Temperature range covers -40℃ to 85℃

[0171] EXISTS {

[0172] MATCH (d)-[:HAS_PARAMETER]->(p:Parameter {type: “temperature_range”})

[0173] WHERE p.min <= -40 AND p.max >= 85

[0174] }

[0175] AND

[0176] / / Condition 2: Support ISO 11898-2 protocol

[0177] EXISTS {

[0178] MATCH (d)-[:HAS_PARAMETER]->(p:Parameter {type: “protocol”})

[0179] WHERE p.value CONTAINS “ISO 11898-2”

[0180] }

[0181] AND

[0182] / / Condition 3: Rise time < 100μs

[0183] EXISTS {

[0184] MATCH (d)-[:HAS_PARAMETER]->(p:Parameter {type: “rise_time”})

[0185] WHERE p.value < 100

[0186] }

[0187] AND

[0188] / / Condition 4: Bandwidth ≥ 10MHz (Implicit requirement)

[0189] EXISTS {

[0190] MATCH (d)-[:HAS_PARAMETER]->(p:Parameter {type: “bandwidth”})

[0191] WHERE p.value >= 10

[0192] }

[0193] AND

[0194] / / Condition 5: Sampling rate ≥ 10MS / s (implicit requirement)

[0195] EXISTS {

[0196] MATCH (d)-[:HAS_PARAMETER]->(p:Parameter {type: “sampling_rate”})

[0197] WHERE p.value >= 10

[0198] }

[0199] AND

[0200] / / Condition 6: Temperature drift compensation requirement is true (implicit requirement)

[0201] EXISTS {

[0202] MATCH (d)-[:HAS_PARAMETER]->(p:Parameter {type: “temperature_compensation”})

[0203] WHERE p.value = true

[0204] }

[0205] RETURN d.id AS deviceId.

[0206] Multi-dimensional search includes:

[0207] Equipment-parameter relationships: defining technical specification constraints;

[0208] Device-rule relationship: Logic based on the experience of storage domain experts;

[0209] Device-state relationship: dynamically linked to real-time data sources.

[0210] Step S4, RAG Retrieval Enhancement: Perform enhanced retrieval on the device IDs returned by the map:

[0211] Vectorized query: query_vector = embed(“BMS voltage test anti-interference pulse capture”);

[0212] Multi-source retrieval:

[0213] 1. Equipment manual library (see) Figure 3 ): Return to key sections of the technical documentation;

[0214] 2. Case database: Matching similar historical test scenarios;

[0215] 3. Standard Document Library: Extract the ISO 11898-2 test specification;

[0216] 4. Context fusion: Injecting Top 3 related text fragments into the decision-making context;

[0217] Step S5, Dynamic Status Filtering: Call real-time data from a third-party system via API:

[0218] The filtering rules include:

[0219] 1. Device availability status = Online;

[0220] 2. Failure rate < threshold (0.1);

[0221] 3. Next calibration time > current date + 30 days; if all the above conditions are met, the recommended output is selected.

[0222] Step S6, LLM Reasoning and Decision Making: Constructing a Decision Cue Template:

[0223] Device recommendations are generated based on the following information:

[0224] User requirements:

[0225] {Structured requirements};

[0226] Candidate devices:

[0227] {Equipment Technical Parameter Table};

[0228] Real-time status:

[0229] {Device status data};

[0230] Related knowledge:

[0231] {RAG search fragment}.

[0232] Output requirements:

[0233] 1. Sort by matching degree in descending order.

[0234] 2. Compare key parameters.

[0235] 3. Explain the extent to which implicit needs are met.

[0236] 4. Additional risk warnings.

[0237] Step S7: Generate recommendation results and a visual decision report. (See attached image) Figure 4 .

[0238] For example, the task is to select and test equipment for the battery management system (BMS) of new energy vehicles. The core requirements include:

[0239] 1. Test the voltage acquisition accuracy of the BMS within the temperature range of -40℃ to 85℃.

[0240] 2. Verify the anti-interference capability of CAN bus communication.

[0241] 3. Capture millisecond-level pulse current (rise edge <100μs).

[0242] The technical solution to achieve the above objectives is:

[0243] 1. Intelligent Requirement Parsing Layer: Based on the Qwen32B large language model capability, implemented through Prompt Engineering:

[0244] Intent recognition: Automatically resolve "verify CAN bus anti-interference capability" to ISO 11898-2 standard test requirements;

[0245] Entity extraction: Extract key parameters (rise time, bandwidth requirements) from "capture millisecond-level pulse current".

[0246] Implicit requirement derivation: The knowledge graph is used to associate "pulse current" with implicit constraints such as "sampling rate ≥ 10MS / s" and "bandwidth ≥ 10MHz".

[0247] 2. RAG Knowledge Enhancement Retrieval Layer:

[0248] Local knowledge base: Building an equipment parameter ontology library (including temperature drift curves, protocol support matrices, dynamic response parameters, technical parameters, and other data for 1500+ equipment models);

[0249] Hybrid search engine: Employs the Bge-Large-zh-v1.5 text embedding model (the Bge-Large-zh-v1.5 text embedding model is a text embedding model responsible for vectorizing and storing documents in PGVector) to transform device parameter documents and user requirement descriptions into high-dimensional vectors;

[0250] Vector retrieval: Similarity calculation based on the PGVector vector database, that is, PGVector queries similarity data according to device ID to quickly match the most relevant device knowledge;

[0251] Example code:

[0252] -- Creating a vector table in PGVector

[0253] CREATE TABLE device_embeddings (

[0254] id SERIAL PRIMARY KEY,

[0255] device_id VARCHAR(50),

[0256] document_type VARCHAR(20), -- 'manual', 'case', 'standard'

[0257] content_text TEXT,

[0258] content_vector VECTOR(1024) -- Bge-Large-zh-v1.5 outputs a 1024-dimensional vector. );

[0260] -- Create vector indexes to speed up searching

[0261] CREATE INDEX ON device_embeddings

[0262] USING ivfflat (content_vector vector_cosine_ops)

[0263] WITH (lists = 100);

[0264] -- Similarity calculation query (cosine similarity)

[0265] SELECT

[0266] device_id,

[0267] content_text,

[0268] 1 - (content_vector <=> '[0.12, -0.05, ..., 0.08]') ASsimilarity_score

[0269] FROM device_embeddings

[0270] WHERE 1 - (content_vector <=> '[0.12, -0.05, ..., 0.08]') > 0.7

[0271] ORDER BY similarity_score DESC

[0272] LIMIT 5;

[0273] Context-enhanced generation: By integrating search results with user input requirements through the Qwen32B large language model, accurate recommendations are generated.

[0274] 3. Intelligent Reasoning and Decision-Making Layer

[0275] Build device capability profiles: Present user profiles of devices to users through a visual interface.

[0276] Those skilled in the art will understand that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless defined as herein.

[0277] Based on the above-described preferred embodiments of the present invention, and through the above description, those skilled in the art can make various changes and modifications without departing from the technical concept of the present invention.

Claims

1. A device intelligent recommendation method based on a large language model and a graph model, characterized in that, Includes the following steps: Step 1: Input Equipment Selection Requirements: Users input a natural language description of their equipment selection requirements through the large language model human-computer interaction interface; Step 2: LLM Semantic Parsing: Call the Qwen32B Large Language Model API to perform semantic parsing and generate a structured data request format; The specific process is as follows: add a description to the prompt words, and generate structured data in JSON format according to the template format. The structured data content includes: intent category, explicit parameters, implicit requirements and entity relationships. The specific process of semantic parsing is as follows: Step 2.1) Intent recognition: First, by calling the Qwen32B large language model API interface, and then using PromptEngineering to automatically parse the requirements, the user's core testing objectives are determined; Step 2.2) Entity recognition: Identify specific performance parameters and technical indicators, and extract explicit parameters, including temperature range, protocol standard and timing parameters; Step 2.3) Relationship Establishment: Establish logical relationships between explicit parameters; Step 2.4) Implicit Requirements Derivation: Automatically generate derived requirements based on electronic principles; Step 3: Neo4j graph query: Extract triples from the structured JSON data using code, convert it into the Cypher query language for the graph database, perform multi-dimensional retrieval in the device knowledge graph, and return the device ID; The extraction of triplet includes: Explicit parameter triples: including temperature range, protocol standard, and rise time. Implicit demand triple: includes implicit bandwidth demand, implicit sampling rate demand, and implicit temperature drift compensation. The derivation of the relational triplet includes deriving the bandwidth based on the rise time and deriving the required temperature drift compensation based on the temperature range. Step 4: RAG Retrieval Enhancement: For the device IDs returned by the graph, perform enhanced retrieval in the existing device knowledge base. Enhanced retrieval includes vectorized query and multi-source retrieval. The multi-source retrieval includes device manual library retrieval, case database retrieval, standard document library retrieval, and context fusion retrieval, specifically: 4.1) Vector retrieval: Based on similarity calculation using a vector database, quickly match the most relevant device knowledge; 4.2) Local Knowledge Base: Construct a local knowledge base for equipment parameters, which includes a database of equipment manuals, a database of case studies, and a database of standard documents. 4.3) Hybrid search engine: The Bge-Large-zh-v1.5 text embedding model is used to transform device parameter documents and user requirement descriptions into high-dimensional semantic vectors; 4.4) Contextual Fusion Retrieval: The retrieval results are fused with user input requirements, and accurate recommendations are generated through the Qwen32B large language model; Step 5: Dynamic Status Filtering: Real-time data of device IDs in the SCADA system is retrieved through the API data interface, and filtered according to multiple dimensions such as device availability status, device failure rate, and device calibration time. The filtering rules include: a. The device is online and its availability status is online. b. The failure rate is less than the failure rate threshold. c. The next calibration time is longer than the set number of days. If all the above conditions are met, the recommended output should be selected. Step 6: Generate LLM inference decision: Build a device capability profile and display the device capability profile through a front-end visualization interface.

2. The device intelligent recommendation method based on a large language model and graph model according to claim 1, characterized in that, The natural language description of equipment selection requirements in step 1 includes key elements such as test objectives, performance indicators, and environmental conditions.

3. The intelligent device recommendation method based on a large language model and a graph model according to claim 1, characterized in that, The multi-dimensional search in step 3 includes: 3.1) Equipment-parameter relationship: Define technical specification constraints; 3.2) Device-Rule Relationship: Experience-based logic in the storage domain; 3.3) Device-Status Relationship: Dynamically linked to real-time data sources.

4. The intelligent device recommendation method based on a large language model and a graph model according to claim 1, characterized in that, The decision-making process in step 6 includes the following prompts: User requirements: Structured requirements; Candidate Equipment: Equipment Technical Parameter Table; Real-time status: Device status data; Related knowledge: RAG search fragments.

5. The intelligent device recommendation method based on a large language model and a graph model according to claim 1, characterized in that, The LLM inference decision-making in step 6 includes: (1) Sort by matching degree in descending order. (2) Compare and annotate key parameters. (3) Explain the extent to which implicit needs are met. (4) Additional risk warnings.

6. The intelligent device recommendation method based on a large language model and a graph model according to claim 1, characterized in that, It also includes step 7: generating a visual decision report from the recommendation results. The visual decision report displays the main recommendation, alternative 1 and alternative 2, as well as the corresponding device models, matching degree, key parameter matching items, extension capabilities and dynamic prompts for the main recommendation, alternative 1 and alternative 2, and the key parameters and usage suggestions for the main recommendation.

Images