text2sql(NL2Sql)综述《The Dawn of Natural Language to SQL: Are We Fully Ready?》

《The Dawn of Natural Language to SQL: Are We Fully Ready?》(github)出自2024年6月的NL2SQL(Natural language to SQL )综述论文。这篇论文尝试回答如下三个问题:

问题1:NL2SQL的现状是什么?(Q1:Where Are we Now?)

  • 论文图1总结了近20年NL2SQL方法的演变,从基于规则的方法,基于深度神经网络的方法,基于预训练模型(PLMs)的方法,演变到了基于大语言模型的方法(LLMs)。
    在这里插入图片描述

  • 论文图2比较了PLM-based NL2SQL方法(蓝色的点)和LLM-based NL2SQL方法的在Spider数据集上的准确率对比,这个图表明在2023年2月时两者的准确率差不多,但是随着LLM的演进,两者的差距逐渐拉大。
    在这里插入图片描述

问题2: LLM-based方法是完胜者吗?(Are LLM-based Models the clear Winner?)。
基于论文图2,我们就能得出结论说LLM-base方法就是NL2SQL应用的唯一选择了吗?
考虑一下传统BI(Business Intelligence)场景,有如下特点:

  • 不同的数据领域(Various Data Domains), BI平台如Tableau通常有不同的数据领域如电影和运动,每个数据域涉及到不同的schemas和术语。理想的NL2SQL必须能够在不同的领域有泛化效果且满足即席查询要求。
  • 复查的SQL操作(Complex SQL operations),实际应用通常包括复杂SQL查询如多个JOIN操作,嵌套查询,聚合函数等。所以NL2SQL模型需要能够生成复杂的SQL查询语句。
  • 新语言表述(New Linguistic Phenomena),对于同一个查询意图,不同的用户可能会用不同缩写、问题风格、同义词来提出自然语言问题。所以NL2SQL模型需要准确地理解自然语言问题描述的变化。

论文图3比较了SOTA PLM-based和LLM-based方法在上面提出的三个BI应用特点上的执行准确率,结果表明没有任何一个模型或方法能够在所有应用特点上都是最优的。
在这里插入图片描述

问题3:能够组合PLM-based和LLM-based方法并设计出一个super NL2SQL模型吗?(Q3: Can we combine the best of both worlds and design a super NL2SQL model?)。

NL2SQL定义:设 N \mathcal{N} N是一个自然语言问题, D \mathcal{D} D是一个有n个表的关系数据库。NL2SQL就是基于 N \mathcal{N} N D \mathcal{D} D生成一个SQL查询 Q \mathcal{Q} Q

论文表1归纳了一些PLM-based和LLM-basedNL2SQL模型和它们包含的关键组件(后面会介绍各个组件)。
在这里插入图片描述

论文作者认为之前的NL2SQL的实验和评估有如下几个限制:

  • 忽视了使用场景:通常只有在整个基准数据集如Spider数据集上整体的评估,缺少在数据子集上进行详细比较(参考论文图3)
  • 缺少直接和综合比较:没有在已有基准和自建数据集上的系统比较。
  • NL2SQL设计空间的有限探索:缺少对LLM-based和PLM-based模块框架设计空间的探索,就限制了对它们协同使用来解决NL2SQL的理解。

为了解决这些现有限制,论文提出了一个测试平台(testbed),NL2SQL360,如论文图4所示,一共包含6个关键模块。
在这里插入图片描述

  • 基准数据集(Benchmark Datasets): 包括被广泛使用的基准Spider, BIRD , Spider-Realistic, Dr.Spider , KaggleDBQA, WikiSQL。

  • 模型动作园(Model Zoo):包括在Spider和BERT排行榜上领先的模型,主要是LLM-based和PLM-based模型。

  • 数据集过滤器(Dataset Filter):引入数据集过滤机制,将基准数据集划分成不同的子集。

    • 场景1:SQL复杂度(SQL Complexity)。通过复杂度来区分SQL,从简单的SQL到有多个条件和子句的复杂SQL。分类标准与Spider一致,主要评估不同的NL2SQL方法能否处理不同难度的SQL。
    • 场景2:SQL特色(SQL Characteristics)。检查SQL是否使用了如JOIN操作、子查询、聚合函数等特性。主要评估NL2QL能否处理不同的SQL功能。
    • 场景3:数据领域(Data Domain)。在不同的数据领域如金融、健康或零售来探索NL2QL的表现。主要评估NL2SQL领域相关的能力和限制。
    • 场景4:查询语句变化测试(Query Variance Testing)。测试在自然语言查询不同的短语描述和结构下NL2QL的鲁棒性和灵活性。
  • 评估指标(Evalutation Metrics):

    • Execution Accuracy (EX),与Spider一样

    • Exact Match Accuaracy (EM),与Spider一样

    • Valid Efficiency Score (VES),评估生成可用SQL的效率,与BIRD一样。用预测SQL执行时间除以标准SQL执行时间。

    • Query Variance Testing(QVT),论文新提出的指标用来评估模型在不同形式的自然语言查询上的适应性有多好。给定一个SQL查询 Q i Q_i Qi,它对应着多个自然语言查询语句,记为 { ( N 1 , Q i ) , ( N 2 , Q i ) , … , ( N m , Q i ) } \{(N_1, Q_i),(N_2, Q_i),\ldots,(N_m, Q_i) \} {(N1,Qi),(N2,Qi),,(Nm,Qi)},在评估模型时,这些自然语言查询与SQL对中至少有一个被模型正确处理。QVT准确率的定义如下:
      Q V T = 1 M ∑ i = 1 M ( ∑ j = 1 m i 1 ( F ( N i j ) = Q i ) m i ) Q V T=\frac{1}{M} \sum_{i=1}^M\left(\frac{\sum_{j=1}^{m_i} \mathbb{1}\left(\mathcal{F}\left(N_{i j}\right)=Q_i\right)}{m_i}\right) QVT=M1i=1M(mij=1mi1(F(Nij)=Qi))
      上式中M是测试集中SQL查询的总数, m i m_i mi是每个SQL查询 Q i Q_i Qi对应的自然语言查询语句形式数目。 F ( N i j ) \mathcal{F}(N_{ij}) F(Nij)表示NL2SQL模型对 Q i Q_i Qi的第 j j j个自然语言查询语句形式生成的SQL查询。 1 ( ⋅ ) \mathbb{1}(\cdot) 1() 是指示函数,如果两个sql相等则返回1否则返回0。

  • 执行器和日志(Executor and logs):用户可以定制NL2SQL模型的评估流程,设置超参数和评估指标。测试平台会在测试基准如Spider上自动运行这些模型并对输出进行记录。

  • 评估器(Evaluator):利用日志中的数据,评估器自动生成量化评价,以表格或者排行榜的形式来展示这些结果。

论文的实验

实验设置:

  • 数据集:以Spider 和 BIRD作为实验数据集,分别包括1034和1054个(NL, SQL)对。BIRD数据集的SQL结构和数据库都更复杂,统计信息如论文表格2。
    在这里插入图片描述

  • NL2SQL方法:评估了开源的LLM-based和PLM-based NL2SQL 方法。

  • 比较了4种基于prompt的LLM-based方法

    • (1) DINSQL:将SQL语句的生成分解成不同的子问题,对每个子问题使用不同prompt让GPT-4生成最终的SQL语句。
    • (2) DAILSQL:在prompt中将问题和数据库schema表示成代码风格,通过结构(骨架)相似性和问题相似性来选择few-shot例子。这些元素作为prompt来指导GPT-4生成SQL。
    • (3) DAILSQL(SC):用Self-Consistency (SC)策略进行后处理的DAILSQL版本。
    • (4) C3SQL用了schema linking过滤和calibration bias prompt让GPT-3.5来生成sql,也用了Self-Consistency (SC)策略进行后处理。
  • 比较了9中基于微调的LLM-based方法

    • (5-8) SFT CodeS (1B/3B/7B/15B):CodeS是在SQL相关语料集上对StarCoder进行增量预训练得到的模型,在Spider或BIRD数据集上对CodeS进行指令微调(SFT)得到SFT CodeS,一共有四个不同大小的版本。
    • (9) Llama2-7B
    • (10) Llama3-8B
    • (11) StarCoder-7B: StarCoder是用GitHub上有许可的数据训练得到的Code LLM,训练数据包括超过80种编程语言的代码,Git mommits, GitHub issues, Jupyter notebooks。
    • (12) CodeLlama-7B
    • (13) Deepseek-Coder-7B: 在项目级代码语料上训练,用fill-in-the-blank任务来提升代码补全能力。
  • 比较了7中PLM-based 方法

    • (1) Graphix-3B+PICARD,用T5-3B加上graph-aware来进行SQL生成,并用PICARD解码来提升性能。
    • (2-4) RESDSQL(Base/Large/3B),用ranking-enhanced编码和skeleton-aware解码将schema linking从骨架解析中分离。
    • (5-7) RESDSQL(Base/Large/3B)+NatSQL, 用NatSQL来提升RESDSQL的性能。
  • 指标,包括Exact Match Accuracy (EM), Execution Accuracy (EX), Query Variance Testing (QVT), Valid Efficiency Socre (VES), Token Efficiency, Latency。

评估准确性的实验

如下的每一个实验对应着一个实验发现。

  • Exp-1: Accuracy vs. SQL Complexity。评估了前面提到的所有方法在Spider和BIRD测试集上改变SQL复杂度时的准确率。论文表3和表4是实验结果,将EX的SOTA结果用橙色标记,EM的SOTA结果用蓝色标记。(注意RESDSQL在BIRD测试集上从头训练了,但没有因为缺少源码没有包括NatSQL)
    • LLM-based方法在不同难度的SQL数据子集上的EX指标都超过了PLM-based方法。在表4中,DAILSQL(SC)方法可能受益于GPT-4d的推理能力在Challenging子集上超过了SFT CodeS 15B。
    • 表格3中微调之后的LLM-based方法普通性能要比prompt-based LLM方法的EM指标更好。在微调之后,LLM-based和PLM-based模型的输出更接近数据集的数据分布,使它们输出与数据集更相似的SQL结构。
    • 发现1:微调是提高性能的重要策略,微调后的LLM-based方法在EX指标上普遍取得最好的结果,微调后的PLM-based在EM指标上总体而言表现最好。
      在这里插入图片描述

在这里插入图片描述

  • Exp-2: Accuracy vs. SQL Characteristics。将SQL查询按照四个标准来分类:(1) 子查询的存在,(2)逻辑连接符的个数 (3) ORDER BY的个数 (4) JOIN的数据。在这四个SQL查询子集上测试模型并计算EX指标。论文图5显示了在Spider和BIRD数据集上EX表现分布。论文图6和图7是详细结果。
    • Exp-2.1: #-Subquery。如图6和图7所示,所有方法在包括子查询的SQL上都表现最差。图5显示没有子查询时,LLM-based方法在Spider数据集上比PLM-based方法好一点点,而在BIRD数据集上好很多。而有子查询的场景下,LLM-based方法在两个数据集上表现都好很多。因为带子查询的SQL要求模型先考虑子查询再生成整个SQL,对模型的推理能力要求很高。在LLM-based方法中,用prompt GPT-4方法效果更好,超过了基于微调的LLM-based方法和PLM-based方法,表明模型的内在推理能力对处理带子查询的SQL很重要。
    • 发现2:在SQL子查询场景下,LLM-based方法总体超过PLM-based方法,用GPT-4的基于prompt的LLM-based方法表现最好,模型的内在推理能力对处理带子查询的SQL可能很关键。
    • Exp-2.2: #-Logical Connector。没有逻辑连接符时,LLM-based方法在Spider数据集上没有超过PLM-based方法,在更复杂的BIRD数据集上LLM-based方法是领先的。当有逻辑连接符时,LLM-based方法在两个数据集上都超过PLM-based方法。
    • 发现3:在逻辑连接符是必需的场景下,LLM-based方法比PLM-based方法更好。
    • Exp-2.3: #-JOIN。在不带JOIN的SQL场景下,LLM-based方法和PLM-based方法在两个数据集上表现还是不一致,没有完胜者。在带JOIN的SQL场景下,LLM-basd方法在两个数据集上都比PLM-based方法更好,可能是因为JOIN操作需要理解数据库schame,而LLM因为其上下文理解能力而获胜。 在图6中,用了NatSQL的DINSQL和RESDSQL-3B+NatSQL的方法在它们对应的模型类别中都是表现最好的,说明使用NatSQL可能会使带JOIN的SQL场景更简单。
    • **发现4:**在带JOIN操作的SQL场景中,LLM-based方法比PLM-based方法更好。用NatSQL作为中间表示可减少预测JOIN操作的复杂度并提升模型性能。
    • Exp-2.4: #-ORDER BY。在没有ORDER BY语句时,LLM-based方法比PLM-based方法更好;在有ORDER BY语句时,LLM-based方法在Spider数据上的性能更差。
    • 发现5:在有ORDER BY的SQL场景下,LLM-based方法的性能在不同数据集中变化,普遍来说,LLM-based方法的泛化性更好。
    • Exp-3: Query Variance Testing。

在这里插入图片描述
在这里插入图片描述

  • Exp-3: Query Variance Testing。基于Spider Dev数据集构建了QVT数据集并根据前面QVT的公式计算得分。实验结果如下图所示,LLM-based方法和PLM-based方法没有赢家。但是微调LLM-based方法比prompt LLM-based的的QVT得分更高,可能因为微调之后对数据分布进行了对齐。Graphix+PICARD方法在EX上比所有prompt-based方法低,但是在QVT上超过了它们。

  • 发现6: 在QVT对比上,LLM-based方法和PLM-based方法没有赢家,用任务相关数据集微调模型可能使模型在自然语句变化上表现得更稳定。
    在这里插入图片描述

  • Exp-4: Database Domain Adaption。将Spider训练集里的140个数据库和开发集的20个数据库划分为33个领域。将基于微调的LLM-based方法和PLM-based方法在测试集上进行训练。论文图9是实验结果。图9(a)表明不同的方法在不同领域表现不一样,LLM-based和PLM-based方法里没有赢家。图9(b)表明在有更多数据集的领域(College,Competition,Transportation)微调方法表现更好,相反地,在有更少训练数据的领域,prompt-based方法表现更突出。

  • 发现7:不同的方法在不同领域表现不一样,LLM-based和PLM-based方法里没有赢家。在特定领域,微调过程中的可用领域训练数据对模型性能很关键。
    在这里插入图片描述

  • Exp-5: Supervised Fine-tuning of LLM-based Methods。验证了开源LLM经过指令微调之后在NL2SQL任务上的表现。采用的prompt与DAILSQL类似,如论文图10所示,比较的LLM大小都为7B,实验结果如论文图11所示,经过SFT之后,不同模型的EX指标都有提升但是提升效果不同。在模型固有的编码能力与SFT前后性能提升大小存在正相关。
    在这里插入图片描述

  • 发现8:在对开源 LLM 进行 NL2SQL 任务的监督微调 (SFT) 后,SFT 后的性能与 SFT 之前模型固有的编码能力呈正相关。这表明具有高级编码能力的基础 LLM 对于适应 NL2SQL任务非常重要。

评估效率的实验

如下的每一个实验对应着一个实验发现。

  • Exp-6: Economy of LLM-based Methods。论文表5比较了LLM-based方法消耗的平均token上和花费(美元)。
    在这里插入图片描述

  • 发现9:调用GPT-3.5-turbo模型的的prompt-based LLM NL2SQL方法有更高的性价比(cost-effectiveness)。尽管DAIL-SQL(SC)比DAIL-SQL在Spider和BIRD数据集上的EX都有提升,但是它的费用更高降低了其性价比。

  • Exp-7: Efficiency of PLM-based Methods。在Spder开发集上比较了RESDSQL-Base/Large/3B 和 RESDSQL-Base/Large/3B + NatSQL的执行准确度(EX),每个样本的latency,GPU内存使用指标。结果如论文表6。

在这里插入图片描述

  • 发现10:对同一种方法,模型参数越多相应的latency和硬件资源要求都会增加。相似性能的方法在latency和硬件资源要求上是不一样的。
  • Exp-8: SQL Efficiency - Valid Efficiency Score。NL2SQL方法在Spider和BIRD数据集上的VES如论文表7所示,最好的结果用橙色颜色标注。
  • 发现11:在VES指标上,LLM-based方法和PLM-based方法没有赢家,对于同一种方法,在更高难度的子集上有更低的VES得分。

在这里插入图片描述

  • Exp-9: The Impact of the #-Training Samples。比较在不同数目训练样本,各个模型的表现,结果如图12所示,模型效果随着训练数目增加而提升,在大概4000样本左右时可实现可接受的性能。

  • 发现12:PLM-based和LLM-based方法的性能都随着训练数据的增加而提升,但是边际效应会递减,也就是随着数据大小增加EX性能增益减小。如果有数据隐私忧虑或充足的标注数据,微调LLM/PLM是一个好选择。

在这里插入图片描述

将基于语言模型的NL2SQL方法的设计空间总结如论文图13所示(前面论文表1总结了每种方法按照这个框架定义的组件)。

  • 预处理(Pre-Processing):预处理模块主要包括schema linking 和DB contents。Schema linking 将自然语言查询与数据库schema元素关联,可提升跨领域泛化性和复杂查询生成,LLM-based和PLM-based方法都会使用Schema linking。DB contents模块将查询条件与数据库内容对齐,通常通过字符串匹配来丰富列细节;DB contents方法在PLM-based方法中很流行,但是很少被LLM-based方法使用。
  • promp策略(Prompting Strategy):Prompt策略分为zero-shot和few-shot,zero-shot在模型输入里不包括NL2SQL例子,few-shot在模型输入中包括NL2SQL例子,根据例子的个数不同,记为"3-shot"、"5-shot"等。如论文表1显示PLM-based方法基本上使用zero-shot,而LLM-based方法有些使用zero-shot,有些使用few-shot。DINSQL的few-shot例子是人工设计且固定的,而DAILSQL是基于查询问题与训练集例子的相似度来动态选择的。
  • SQL生成策略(SQL Generation Strategy):在生成SQL时,语言模型会使用多种策略,将其归类为如下三种。
    • Multi-Step:主要指COT(Chain-of-Thought)过程,对于复杂查询很有效,主要包括两种类型的策略:PLM-based方法RESDSQL使用的"SQL skeleton-SQL"和LLM-Based方法DINSQL使用的"Subquery-SQL"。
    • Decoding Strategy:在模型的解码过程中进行约束保证输出的有效性。PLM-Based方法PICARD在输出时强制SQL语法规则,但是利用OpenAI接口的LLM-based方法缺少解码时的限制。
    • Intermediate Representation:试图通过中间查询(intermediary query)来解决自然语言到SQL翻译过程中的不匹配问题(mismatch problem, 指关系数据库的SQL设计与自然语言语义不一致)。论文只考虑NatSQL。
  • 后处理(Post-Processing):包括如下策略。
    • Self-Correction。出自DINSQL,将生成的SQL提供给模型来修复潜在的问题。
    • Self-Consistency。对单个自然语言问题生成不同的SQL查询,用投票机制来决定最后的SQL。C3SQL和DAILSQL使用了它。
    • Execution-Guided SQL Selector。执行模型生成的SQL,将第一个执行成功的SQL作为可用SQL。
    • N-best Rerankers。将多个候选SQL查询排序,将最可能的一个作为最后的结果。

接下来论文尝试基于NL2SQL360设计一种算法NL2SQL360-AAS来选择NL2SQL设计空间里的组件来得到一个最优的NL2SQL方法,算法基于遗传算法(Genetic Algorithm(GA)),如论文图14所示。
在这里插入图片描述

由NL2SQL360-AAS搜索得到了一个名为SuperSQL的算法,这个算法在之前的实验中表现出了很高的准确率和效率。SuperSQL的各个组成部分如下:

  • 预处理:使用了RESDSQL的schema linking方法和BRIDGE v2的DB Contents。prompt如论文图15.
  • prompt:使用DAILSQL的通过相似度来选择few-shot思路。
  • SQL生成:仅使用OpenAI接口里的贪心解码(Greedy-decoding)。
  • 后处理:使用DAILSQL的Self-Consistency。

在这里插入图片描述

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/879491.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Cyber Weekly #24

赛博新闻 1、OpenAI发布最强模型o1 本周四(9月12日),OpenAI宣布推出OpenAIo1系列模型,标志着AI推理能力的新高度。o1系列包括性能强大的o1以及经济高效的o1-mini,适用于不同复杂度的推理任务。新模型在科学、编码、数…

比亚迪电动汽车的市场占比太惊人

比亚迪(BYD)在中国电动汽车市场的崛起无疑是近年来最显著的现象之一。凭借其强大的技术整合、丰富的产品线以及价格优势,比亚迪已经迅速成为中国乃至全球电动汽车领域的领导者。在2024年,比亚迪的市场份额在中国汽车市场达到了惊人…

SSHamble:一款针对SSH技术安全的研究与分析工具

关于SSHamble SSHamble是一款功能强大的SSH技术安全分析与研究工具,该工具基于Go语言开发,可以帮助广大研究人员更好地分析SSH相关的安全技术与缺陷问题。 功能介绍 SSHamble 是用于 SSH 实现的研究工具,其中包含下列功能: 1、针…

MySQL练手题--公司和部门平均工资比较(困难)

一、准备工作 Create table If Not Exists Salary (id int, employee_id int, amount int, pay_date date); Create table If Not Exists Employee (employee_id int, department_id int); Truncate table Salary; insert into Salary (id, employee_id, amount, pay_date) va…

危机中的机遇:客户服务在品牌危机管理中的角色与价值

在瞬息万变的商业环境中,品牌危机如同暗流涌动的漩涡,随时可能将企业卷入深渊。然而,正如古语所云:“祸兮福之所倚”,危机之中往往也蕴藏着转机与机遇。在这一过程中,客户服务作为企业与消费者之间的桥梁&a…

各类元器件调试记录-E+H

一、EH压力传感器 适用型号为: Cerabar S PMC71, PMP71/75 Deltabar S FMD76/77/78, PMD70/75 Deltapilot S FMB70 调试过程:(后续补上图片) 一、湿标(湿调) 1、前提条件:罐体可以灌满和实际水箱水位高度 2、调试步骤: A、调节语…

C++在Linux实现多线程和多进程的TCP服务器和客户端通信

多进程版本 服务器 #include <arpa/inet.h> #include <stdlib.h> #include <stdio.h> #include <string.h> #include <unistd.h> #include <sys/socket.h> #include <sys/wait.h> #include <signal.h> #include <string&…

uni-app和Node.js使用uni-push2.0实现通知栏消息推送功能

前言 uniapp 提供了 unipush 统一推送服务,但是每次要推送消息的时候都要登陆 Dcloud 开发者后台&#xff0c;有点不方便&#xff0c;运营需要在我们的后台系统就可以完成操作。 效果演示 消息下发流程 名词解释 名词解释通知消息指定通知标题和内容后&#xff0c;由个推 SD…

电脑上如何多开微信软件(多个微信同时使用)

想登录几个就下面这种文件里&#xff0c;复制几行即可&#xff1a; 创建的是以 .bat 文件结尾的txt文件&#xff08;先创建一个txt文本文档&#xff0c;等写好了命令保存后&#xff0c;再把文件的后缀名改为: .bat &#xff09;再保存即可。然后&#xff0c;右键以管理员运行&a…

炫酷HTML蜘蛛侠登录页面

全篇使用HTML、CSS、JavaScript&#xff0c;建议有过基础的进行阅读。 一、预览图 二、HTML代码 <!DOCTYPE html> <html lang"en"> <head><meta charset"UTF-8"><meta name"viewport" content"widthdevice-w…

C语言的结构体类型

在我们使用C语言进行编写代码时&#xff0c;常常会使用已经给定的类型来创建变量&#xff0c;比如int型&#xff0c;char型&#xff0c;double型等&#xff0c;而当我们想创建一些较为复杂的东西时&#xff0c;单单用一个类型变量是没办法做到的&#xff0c;比如我们想创建一个…

DPDK基础入门(十):虚拟化

I/O虚拟化 全虚拟化&#xff1a;宿主机截获客户机对I/O设备的访问请求&#xff0c;然后通过软件模拟真实的硬件。这种方式对客户机而言非常透明&#xff0c;无需考虑底层硬件的情况&#xff0c;不需要修改操作系统。 半虚拟化&#xff1a;通过前端驱动/后端驱动模拟实现I/O虚拟…

嵌入式鸿蒙系统开发语言与开发方法分析

大家好,今天主要给大家分享一下,HarmonyOS系统的主力开发语言ArkTS语言开发方法,它是基于TypeScript(简称TS)语言扩展而来。 第一:ArkTS语言基本特性 目的:声明式UI,让开发者以更简洁,更自然的方式开发高性能应用。 声明式 UI基本特性: 基本UI描述:ArkTS定义了各种装饰…

使用Ubuntu耳机输出正弦波信号

最近有一个项目想使用喇叭发出一个标准的正弦波测试信号&#xff0c;故记录下操作过程 sudo apt install libasound2-dev 否则有可能会报错&#xff1a; alsaaudio.c:28:10: fatal error: alsa/asoundlib.h: No such file or directory 安装pyalsaaudio&#xff1a; pip …

合肥鲸天科技的外卖会员卡系统有人做过吗?赚钱吗?

我们先来了解一下这个合肥鲸天科技&#xff0c;通过我在网上找到的资料和企业查询&#xff0c;这家公司还是很有实力的&#xff0c;合肥鲸天科技有限公司也是欢迎有合作的人到公司来进行一个考察和合作其他一些项目的。 外卖会员卡简介绍&#xff1a; 这个外卖会员卡&#xf…

Linux | 探索 Linux 信号机制:信号的产生和自定义捕捉

信号是 Linux 操作系统中非常重要的进程控制机制&#xff0c;用来异步通知进程发生某种事件。理解信号的产生、阻塞、递达、捕捉等概念&#xff0c;可以帮助开发者更好地编写健壮的应用程序&#xff0c;避免由于未处理的信号导致程序异常退出。本文将带你从基础概念开始&#x…

Redis Key的过期策略

Redis 的过期策略主要是指管理和删除那些设定了过期时间的键&#xff0c;以确保内存的有效使用和数据的及时清理。 具体来说&#xff0c;Redis 有三种主要的过期策略&#xff1a;定期删除&#xff08;Scheduled Deletion&#xff09;、惰性删除&#xff08;Lazy Deletion&#…

C#命令行参数解析库System.CommandLine介绍

命令行参数 平常在日常的开发过程中&#xff0c;会经常用到命令行工具。如cmd下的各种命令。 以下为sc命令执行后的截图&#xff0c;可以看到&#xff0c;由于没有输入任何附带参数&#xff0c;所以程序并未执行任何操作&#xff0c;只是输出了描述和用法。 系统在创建一个新…

【BFS专题】— 解决最短路问题

1、迷宫中离入口最近的出口 - 力扣&#xff08;LeetCode&#xff09; 思路&#xff1a; 利用BFS层序遍历&#xff0c;新建一个变量统计步数代码&#xff1a; class Solution {int dx[] {0, 0, -1, 1};int dy[] {1, -1, 0, 0};public int nearestExit(char[][] maze, int[] en…

URP 线性空间 ui资源制作规范

前言&#xff1a; 关于颜色空间的介绍&#xff0c;可参阅 unity 文档 Color space URP实现了基于物理的渲染&#xff0c;为了保证光照计算的准确&#xff0c;需要使用线性空间&#xff1b; 使用线性空间会带来一个问题&#xff0c;ui资源在unity中进行透明度混合时&#xff…