## 5 Experiment
### Experimental Performance Evaluation of Language Frameworks Based on Dynamic Tuple Extraction
With the increase in the number of input commands, the performance indicators of the generated AOM intermediate language are decreased, where the parsing performance of command types a and b are above 90%, and the parsing time is between 0.9 and 1 s. It can be considered that the TF-IDF algorithm combined with the use of the Glove word vector to calculate the cosine similarity has good results in the parsing of these two types of commands. The average response time of instruction type b is slightly longer than that of instruction type a. The main reason is the time consumption \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**No.** & **Number** & **Accuracy** & **Precision** & **Recall** & **F-Score** & **Time Taken** \\ \hline
1 & 50 & 92.16\% & 95.10\% & 93.27\% & 94.18\% & 1.86 s \\
2 & 100 & 90.10\% & 89.81\% & 90.65\% & 90.22 \% & 1.96 s \\
3 & 150 & 88.15\% & 87.58\% & 89.91\% & 88.73\% & 1.96 s \\
4 & 200 & 89.47\% & 89.58\% & 90.72\% & 90.15\% & 1.87 s \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Command type d Experimental results. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**No.** & **Number** & **Accuracy** & **Precision** & **Recall** & **F-Score** & **Time Taken** \\ \hline
1 & 50 & 87.57\% & 86.52\% & 85.12\% & 85.81\% & 2.02 s \\
2 & 100 & 85.47\% & 84.12\% & 83.39\% & 83.75\% & 2.06 s \\
3 & 150 & 83.39\% & 82.21\% & 81.19\% & 81.70\% & 2.06 s \\
4 & 200 & 81.27\% & 80.23\% & 79.81\% & 80.02\% & 2.07 s \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Command type e Experimental results. Figure 12: (**a**) Accuracy result graph of the commands. (**b**) Precision result graph of the commands. (**c**) The resulting graph of the recall value of the commands. (**d**) F-score result graph of the commands  
of the process of cutting complex natural language commands into basic natural language commands. The good parsing performance is mainly because the commands themselves generate simple AOM statements in the form of a basic triplet. Therefore, this method is reliable for generating NL2 AOM datasets for commands a and b. * Command types c and d have index values above 85% when generating the AOM intermediate language, and the change curves of their F-score values overlap significantly when the number of input commands is 100 to 150, indicating that Algorithms 2 and 3 are more similar in performance, mainly the characteristics of these two commands are more similar; the former belongs to object juxtaposition, and the latter belongs to member juxtaposition. The response time of generating AOM intermediate language is between 1.85 and 2.0 s, so the training data can be collected effectively. * Command type e has index values for the generation of close to 80% AOM intermediate language; the main reason for consideration is the complexity of object nesting. For example, \" \" \" (\"check the temperature of the sensor in the shed\") where \" \" \"(\"shed\") and \" \" \" (\"sensor\") are objects, and \"  
* The reason for the low accuracy of the extracted field Object is that the indicator can easily cause ambiguity; that is, the same keyword can have different indicators in different instructions; for example, \" \" \" \" (\"check what is the temperature of the air conditioner in the shed\"). The \" \" \" \" (\"air conditioner\") index of this command belongs to Object_2, which forms a nested relationship with the \" \" \" (\"shed\"). However, \" \" \" \" \" \" \" \" \" \" \" (\"Please help me turn on the air conditioner in the shed\"), where \" \" \" \" \" (air conditioner\") belongs to Member_1 and forms a verb-object relationship (VOB) with \" \" \"(\"turn on\"). Therefore, the accuracy rate is relatively low.