人造言语转SQL（nl2sql）技术是指人造言语查问转化为SQL查问，降落个别用户和专家用户在访问海量数据集和失掉数据剖析结果时的门槛。
上图展现了过去二十年nl2sql方法的演进历程，从基于规定的方法，到基于深度神经网络的方法，再到可调的预训练言语模型（PLMs），直至大型言语模型（LLMs），整个环节随同着数据集的开展，比如Spider和BIRD等基准测试的开展。
LLMs（如GPT-4和Llama2）相较于PLMs（如GPT-2和BART）是规模更大的言语模型，展现出更深档次的言语了解才干。在nl2sql 义务中运行PLMs须要在特定义务的数据集上启动微调，而应用LLMs则可以经过提醒（高低文学习）或仅对开源LLMs启动微调（即SFT）。
上图对比了基于PLM（蓝点）和基于LLM（绿点）的nl2sql模型在Spider排行榜上的准确率。
可以看出基于LLM的nl2sql模型自2023年2月（DINSQL + CodeX）起便与基于PLM的模型展现出相当的准确率。
但是，随着LLMs的迅猛开展，基于LLM和PLM模型之间的性能差距正在扩展，标明了基于LLM方法长处十分清楚。
依据上图，能否可以判定基于LLM的模型是一切nl2sql运行的“首选”？换句话说，总是决定排行榜首位的模型能否总是最佳战略？
讨论这一疑问前，作者剖析了商业化场景的一些特色：
• 多样化的数据畛域（Various>• 复杂的SQL操作（Complex SQL operations） ：实践运行中往往须要口头蕴含多个JOIN、嵌套查问和聚合函数等初级操作的复杂SQL查问。准确生成这些复杂查问的才干是权衡nl2sql模型性能的关键目的。
• 新兴的言语现象（New Linguistic Phenomena） ：关于同一查问用意，不同用户或者会经常使用不同的缩写、同义词和疑问格调提出疑问。因此，nl2sql模型准确解读各种人造言语查问变体的才干至关关键。
上图从多个维度对比了Spider开发数据集上的SOTA PLM和LLM模型，评价目的是口头准确性（Execution-Accuracy）。
• 多样化的数据畛域（Various> •复杂的SQL操作（Complex SQL operations）：上图(b)比拟了仅蕴含JOIN操作符的SQL查问用例中的不同模型。基于PLM的方法RESDSQL-3B+NatSQL位居榜首，逾越了一切基于LLM的方法。但是，当比拟仅蕴含嵌套SQL查问的用例时，基于LLM的方法理论优于基于PLM的方法。
•新兴的言语现象（New Linguistic Phenomena）：比拟了不同言语现象下方法的平均准确率（例如，“ 前往一切生产总额超越1000的客户”与“生产超越1000的客户名单是什么？”）。上图(d)显示，虽然两种类型的方法都体现良好，但微调的LLM和PLM在nl2sql义务上优于基于提醒的LLM。关键是由于微调模型能更好地将不同的查问变体与数据库架构相婚配。
所以，并非一切状况都实用同一处置打算；也就是说，即使是目前最弱小的LLM GPT-4支持的模型，也没有一个nl2sql模型能在一切不同的经常使用场景中都成为清楚的赢家。实在运行场景远比公共nl2sql基准测试（如Spider和BIRD）所能调查的要复杂得多。因此，迫切 须要能够从不同角度系统评价给定基准上nl2sql模型的工具 。
依据文章最开局的退化树，NL2SQL可以分为四大流派：
• 基于规定的方法：早期钻研依赖于预设规定或语义解析器。例如，NaLIR应用句法解析器和手工规定将人造言语查问转换为SQL查问。但这些方法在顺应性、扩展性和泛化力上存在局限。
• 基于神经网络的方法：应用神经网络将人造言语查问译为SQL查问。随之颁布了若干大规模基准数据集，例如WikiSQL和Spider。相继开发了诸如IRNet的序列到序列nl2sql方法。IRNet经过编码器对人造言语查问和数据库架构启动编码，并借助解码器生成SQL查问。
• 基于PLM的方法：随着Transformer的问世和Spider数据集的推出，基于神经网络的方法迅速崛起，BERT和T5等模型开启了预训练言语模型的新纪元，在基准数据集上屡创佳绩。例如，RESDSQL，作为Spider排行榜的佼佼者，采用两阶段框架：先从人造言语查问中识别相关架构元素，再构建SQL查问。
• 基于LLM的方法：ChatGPT和GPT-4等大型言语模型的出现，彻底改造了nl2sql处置打算。当初，基于LLM的方法已在nl2sql畛域占据主导位置。以DAIL-SQL为例，它借助GPT-4和提醒工程，在Spider数据集上取得了不俗的效果。
上表依据外围模型和若干关键组件对上游的nl2sql方法启动了分类。
为了更好的、系统性的测评NL2SQL义务，作者推出了NL2SQL测评平台。
上图展现了NL2SQL360测试平台框架，由六个外围组件导致：
• 基准数据集。会集了多种宽泛采用的基准数据集，包括Spider 、BIRD 、Spider-Realistic 、Dr.Spider 、KaggleDBQA 、WikiSQL 等。
• 模型库。收录了一系列在Spider和BIRD排行榜上体现出色的竞争性开源NL2SQL模型，关键包括基于LLM和PLM的方法。
• 数据集挑选器。传统评价方法经过计算整个基准数据集的平均性能，疏忽了不同场景下NL2SQL的纤细差异。为补偿这一无余，精心挑选了特定的基准数据集子集，包括特定的数据库、人造言语查问和SQL查问，以凸显查问复杂性、数据库架构多样性以及SQL个性（如JOIN操作或嵌套查问）等共同要素。因此，在NL2SQL360中引入了数据集挑选机制。这使得测试数据集能够依据不同的规范被划分为愈加专一的子集：
• (1) 场景一：SQL复杂度。依据复杂度对SQL查问启动分类，从便捷查问到蕴含多个子句和条件的复杂查问。分类规范遵照Spider的准绳，目的是评价NL2SQL方法处置不同难度SQL的才干。
• (2) 场景二：SQL个性。测验关键应用特定个性的SQL查问，例如JOIN操作、子查问或聚合函数。经过基于这些个性对查问启动分类，评价NL2SQL系统处置不同SQL配置的才干。例如，商业智能平台经常须要处置蕴含嵌套子查问的剖析型查问。
• 评价规范。采用了广受认可的评价规范。
• 采用口头准确度（EX）与齐全婚配准确度（EM）来评价生成的SQL查问的效果。
• 应用有效效率得分（VES）来权衡生成有效SQL查问的效率。
• 查问变同性测试更片面地评价nl2sql处置打算处置人造言语查问变动时的稳固性与顺应性
• 评价工具。依据日志中的数据，评价工具智能生成定量评价报告，并以表格或排行榜等直观格局展现。装备了可视化工具和仪表板，支持用户启动交互式剖析，轻松比拟不同nl2sql处置打算在数据库畛域和SQL个性等方面的性能体现。
作者采用了Spider 和 BIRD 的开发数据集启动试验，区分蕴含1034和1534个人造言语与SQL样本。BIRD数据集的SQL结构更为复杂，涵盖了Spider未蕴含的CASE、IIF等关键字，参与了对模型人造言语转SQL才干的应战。此外，BIRD中的数据库结构也比Spider更为复杂。
• (1) DINSQL：将SQL查问生成分解为多个子义务，并为每个子义务设计了特定的提醒，以指点GPT-4生成最终的SQL查问。
• (2) DAILSQL：以SQL代码格调对疑问和数据库架构启动编码，依据结构和查问的相似性决定大指示例，这些元素被整分解一个高效的提醒，疏导GPT-4启动操作。
• (3) DAILSQL(SC) ：DAILSQL的自我分歧性（SC，Self Consistence）战略后处置版本。
• (4) C3SQL ：结合了形式链接过滤（schema linking filterin）和为GPT-3.5定制的校准偏向提醒，用于生成SQL查问，并采用自我分歧性战略（SC，Self Consistence）启动后处置。
• (5-8) SFT CodeS (1B/3B/7B/15B) 是基于StarCoder ，经常使用少量SQL相关语料库逐渐预训练的，在后续试验中，经常使用了与Spider或BIRD数据集微调的SFT CodeS。试验中蕴含了SFT CodeS家族的四个版本。
• (9) Llama2-7B 采用优化的Transformer作为自回归言语模型，由Meta在庞大的语料库上预训练。
• (10) Llama3-8B 在超越15T的令牌数据上训练，训练数据集规模是Llama 2的7倍，包括4倍多的代码。
• (11) StarCoder-7B 是一个代码LLM，已在GitHub上容许的数据上启动训练，包括超越80种编程言语的代码。
• (12) CodeLlama-7B 是Llama2的增强版，经过在代码库数据集上启动额外训练启动了优化。
• (13) Deepseek-Coder-7B 在名目级代码语料库和填空义务上启动训练，以优化代码补全才干。
• (1) Graphix-3B+PICARD 将预训练的T5-3B变换器与图感知增强集成，用于人造言语转SQL义务，并应用PICARD 提高性能。
• (2-4) RESDSQL(Base/Large/3B) 引入了排名增强编码和骨架感知解码，将形式链接与骨架解析分别。
• (5-7) RESDSQL(Base/Large/3B)+NatSQL 结合了NatSQL 以取得更好性能的版本。试验中经常使用了六个版本的RESDSQL家族模型。
从口头准确度（EX）的视角来看（下面两图区分展现了Spider数据集和Bird数据集上结果），基于LLM的方法在不同难度的子集中均逾越了基于PLM的方法。特意是在BIRD测试数据集中，DAILSQL(SC)在应战性子集上的体现超越了基于LLM的最新最佳方法SFT CodeS15B，这或者是由于GPT-4在推理才干上的清楚长处。
从准确婚配准确度（EM）的角度剖析，经过监视微调的基于LLM的方法理论比基于提醒的LLM方法展现出更高的EM性能。微调之后，无论是基于LLM还是PLM的模型，其输入都愈加贴近特定数据集的数据散布，从而能够预测出与该数据集中相似的SQL结构。
洞察1 ： 微调是优化性能的殊途同归 。特意是，经过微调的基于LLM的方法在口头准确度（EX）目的上取得了最优的全体体现，而基于PLM的方法在准确婚配准确度（EM）目的上全体体现最为出色。
在实在场景中，经常须要构建蕴含诸如子查问、逻辑衔接器、排序（ORDER BY）以及多重衔接（JOIN）等初级操作的SQL查问。
因此，将测验人造言语转SQL模型在生成具有不同个性的SQL查问方面的精准度。
所以，依据四个维度对SQL查问启动分类：
• (1) 能否蕴含子查问
• (2) 逻辑衔接器的数量
• (3) 能否经常使用排序配置
• (4) 衔接操作的次数
NL2SQL360能够依据单个SQL子句、它们的组合或用户自定义的条件来过滤SQL查问。展现了四个具有代表性的维度。
从下面两个可以看出，在触及子查问的状况下，一切方法的体现都不尽善尽美，标明 经过子查问启动逻辑推理是一个难题 。
上图提醒了在没有子查问的状况下，基于LLM的方法在Spider数据集上稍微上游于基于PLM的方法，而在BIRD数据集上则平均体现清楚更佳。
当存在子查问时，基于LLM的方法在两个数据集上都大放异彩。这是由于构建带有子查问的SQL语句要求模型先深化了解子查问，再生成完整的SQL语句，这对模型的逻辑推理才干提出了高要求。
一切基于LLM的方法， 尤其是那些由GPT-4驱动的，处置子查问时更为出色 ，不只逾越了经过微调的基于LLM的方法，也超越了基于PLM的方法。模型外在的推理才干关于处置含子查问的SQL至关关键。
洞察2 ：在蕴含子查问的场景中，基于LLM的方法总体上逾越了基于PLM的方法，尤其是那些采用GPT-4的（即基于提醒的LLM）方法，体现尤为突出。 模型的外在推理才干或者是准确预测子查问的关键所在 。
逻辑衔接符（如AND、OR）用于衔接条件、挑选查问结果及其余操作，因此评价模型处置逻辑衔接符的性能至关关键。
在未触及逻辑衔接符的状况下，基于LLM的智能体在Spider数据集上并未清楚逾越基于PLM的方法。但在结构更复杂的BIRD数据集中，基于LLM的智能体则体现出色。
一旦触及到逻辑衔接符，基于LLM的智能体在两个数据集上均继续上游于基于PLM的智能体。
洞察3 ：在须要逻辑衔接符的情境下， 基于LLM的智能体相较于基于PLM的智能体，展现出更优的性能 。
实践运行中，经常须要构建触及多表衔接的SQL查问，对模型准确掌握复杂数据库架构的才干提出了应战。
在不触及衔接操作的状况下，基于LLM和PLM的方法在Spider和BIRD数据集上的体现错落不齐，难分伯仲。
当触及到须要口头衔接操作的场景时，基于LLM的在两个数据集中均清楚优于基于PLM的。或者是由于衔接操作要求深化了解数据库的复杂结构，而LLM在这方面理论体现出色，得益于其出色的高低文了解才干。
NatSQL的踊跃作用也不容漠视。在处置蕴含衔接的SQL查问时，DINSQL在基于提醒的智能体中体现最佳，而RESDSQL-3B+NatSQL则在基于PLM的智能体中独占鳌头。两者都采用了NatSQL 作为两边示意层，这或者得益于其简化的方式，省去了衔接关键字并缩小了架构项的预测，从而在衔接场景中简化了SQL的预测环节。
洞察4 ：在须要口头衔接操作的场景中，基于LLM的智能体比基于PLM的智能体体现更佳。采用NatSQL作为两边示意层，不只降落了预测衔接操作的复杂性，还或者进一步优化模型的性能。
在缺乏ORDER BY指令时，基于LLM的在Spider与BIRD两个数据集上均优于基于PLM的方法。但当引入ORDER BY指令后，状况在Spider数据集上出现了逆转，基于LLM的方法体现略胜一筹，而在BIRD数据集上则照旧坚持上游。这种差异可动力于BIRD数据集的复杂度高于Spider。
洞察5 ：在触及ORDER BY指令的场景中，基于PLM和LLM的智能体在不同数据集间的体现出现出差异。大体来看， 基于LLM的智能体展现出了更优越的泛化才干 。
测验nl2sql系统对多样化人造言语表述和结构的顺应力，模拟实践运行中或者遇到的丰盛场景。
在BIRD数据集中，很少有SQL查问与多个不同的人造言语表白相对应。因此，决定了Spider开发集来构建QVT数据集，它蕴含了469个SQL查问，每个都对应着两个以上的不同人造言语查问，这正合乎QVT的初衷。
如上图，基于LLM的智能体与基于PLM的智能体在QVT方面难分伯仲。
不过，经过微调的LLM智能体理论在QVT上体现更佳，或者是由于微调使得模型输入与特定数据散布愈加吻合，从而缩小了人造言语变动对性能的冲击。
值得留意的是，虽然Graphix+PICARD方法在全体口头准确度（EX）上不迭其余基于提醒的智能体，却在QVT上逾越了它们。
洞察6 ：在QVT方面，基于LLM与基于PLM的智能体并无清楚优劣之分。针对特定义务数据集对模型启动微调，或者有助于提高其在面对人造言语变动时的性能稳固性。
在人造言语到SQL的实践运行案例中，往往须要处置特定畛域的数据库，比如电影或体育畛域，各自领有共同的架构设计和专业术语。因此，跨不同畛域的粗疏体现评价关于模型的有效运行极为关键。
对Spider训练集中的140个数据库和开发集中的20个数据库启动了分类，共划分出33个不同的畛域。一切基于微调的LLM和PLM智能体均经常使用训练集启动调优。
上图展现了Spider数据集中，不同数据库畛域内的口头准确度（EX）体现。不同的人造言语到SQL方法对不同畛域有着不同的偏好，基于LLM和基于PLM的智能体并没有清楚的优劣之分。
上图展现了全体体现。在领有较多训练数据库的畛域（如大学、竞赛、交通），基于微调的方法体现更佳。而在训练数据库较少的畛域，基于提醒的办规律更为出色。这说明，在微调阶段引入畛域内的训练数据关于优化模型在特定畛域的性能至关关键。
洞察7 ：不同方法对不同畛域有着不同的偏好，基于LLM和基于PLM的智能体并无相对的胜出者。不过，在微调阶段的畛域内训练数据关于模型在特定畛域的体现极为关键。
探求在人造言语转SQL义务中，对开源大型言语模型（LLM）启动监视式微调（SFT）的效果。
DAILSQL 在SFT环节中，不雷同本量和提醒表述的影响，但并未明白指出哪些开源LLM最适宜用于人造言语转SQL义务的SFT。采用SQL格调的提醒对优化效果有益，因此在零样本设置中也采取了相似的提醒战略，如下图。
思考到人造言语转SQL义务与代码编写亲密相关，挑选了五款具有不同代码处置才干的开源LLM，并经过HumanEval (Pass@1) 目的启动了评价。
如上图，经过SFT，各模型的性能（EX）均有优化，但优化幅度在不同基础模型间差异清楚。
性能优化与模型在SFT前的外在编码才干（HumanEval）之间存在正相关相关。这标明，决定具有低劣编码才干的LLM作为基础模型，关于顺应人造言语转SQL义务大有裨益。
洞察8 ：在对开源LLM启动人造言语转SQL义务的监视式微调（SFT）后，发现SFT后的性能与模型在SFT前的固有编码才干之间存在正相关。这说明， 具有初级编码才干的LLM是顺应人造言语转SQL义务的关键 。
思考到国际模型很廉价，这局部觉自得义不大，间接看洞察
洞察9 ：依据口头准确度（EX）与平均老本的比值，发现调用GPT-3.5-turbo的基于提醒的LLM智能体具有更高的老本效益。虽然DAILSQL(SC)在Spider和BIRD数据集上相较于DAILSQL在EX上有所优化，但其参与的老本也降落了其全体的老本效益。
对六种模型启动了三名目的的评价：
• 口头准确度（EX）
• 样本提前
• GPU内存
如上图，随着模型规模的增长，GPU内存消耗和提前也随之回升。但是，RESDSQL-Base+NatSQL（2.2亿参数）与RESDSQL-Large（7.7亿参数）在口头准确度上体现相近（区分为80.2%和80.1%），而前者在提前和内存经常使用上更为经济。雷同，RESDSQL-Large+NatSQL与RESDSQL-3B在口头准确度上不相高低，但在提前和配件需求上存在差异。因此，在模型的决定上，须要权衡提前和配件资源。
洞察10 ：随着模型参数规模的扩展，其提前和配件资源的需求也会相应增长。此外，即使性能相近，不同模型在提前和配件资源需求上也或者天壤之别。
在事实环球的运用中，不只需确保模型产出的SQL查问准确无误，更要器重其口头的高效性。BIRD 提出了有效效率评分（VES，Valid Efficiency Score），用以权衡正确生成的SQL查问的口头效劳。
上图展现了试验的效果。橙色标注了最高的VES得分。在各个难度层级的子集中，VES得分最高的方法并不固定，无论是基于LLM还是基于PLM的方法，都未见清楚的长处。大体而言，同一方法在处置更为复杂的子集时，往往会有较低的VES体现，这或者与口头难度的参与和所需期间的延伸无关。
洞察11 ：依据VES评分，在基于LLM和基于PLM的方法之间，并没有清楚的赢家。关于同一方法而言，它在面对更具应战性的子集时，往往会展现出较低的VES。
无论是基于PLM还是经过微调的LLM方法，随着人造言语到SQL训练数据的增多，性能均有所优化，并在训练样本到达0时取得满意的性能体现。但是，随着数据集规模的扩展，口头准确度（EX）的增益逐渐缩小。
洞察12 ：随着人造言语到SQL训练数据的参与，基于PLM和LLM的方法性能均有所提高。但值得留意的是，随着数据集规模的增长，口头准确度（EX）的优化幅度逐渐降落。若数据隐衷成为关注点或有足够的标注数据，对LLM/PLM启动微调展现出渺小的后劲。
如上图，可以将NL2SQL打算大抵划分为以上模块：
• (1) 预处置阶段：预处置环节涵盖了 架构关联和数据库 内容两大外围。架构关联将人造言语查问指向数据库架构元素（例如表和列），从而优化了跨畛域通用性和复杂查问的生成才干。数据库内容模块经过字符串婚配，常罕用于将查问条件与数据库内容相婚配，进一步丰盛列的细节消息。
• (2) 提醒战略：提醒战略可分为零样本和少样本两种，零样本战略在模型输入中不蕴含任何人造言语到SQL的示例，而少样本战略则蕴含必定数量的示例，如“3样本”、“5样本”等。基于PLM的方法理论偏好零样本战略，而基于LLM的办规律各有所长：C3SQL采用零样本战略，而DAILSQL和DINSQL则采用少样本战略。DINSQL的少样本示例是人工设计且固定的，相较之下，DAILSQL的示例则是基于目的疑问与训练集示例间的相似度灵活决定的。
• (3) SQL构建战略：言语智能体在生成SQL时采取多样化的战略，这些战略可演绎为三个外围要素：分步构建、解码技巧和两边表白方式。
• (a) 分步构建，相似于思想链（Chain-of-Thought, COT）的逻辑，经过火阶段结构SQL查问，尤其适宜处置复杂查问。两种分步战略：“SQL框架 - SQL”战略源自基于PLM的RESDSQL ，“子查问 - SQL”战略则来自DINSQL 。
• (b) 解码技巧关注的是LLM在解码环节中如何确保输入结果的有效性。基于PLM的PICARD 确保其输入严厉遵守SQL语法规定，而基于LLM的办规律经过OpenAI的API启动操作，不受此类解码层面的限度。
• (c) 两边表白方式战略讨论能否采用某种中介查问格局来弥合人造言语与SQL之间的差异，由于SQL面向相关数据库的设计并不总是与人造言语的语义相吻合。市场上曾经出现了诸如NatSQL等多样化的处置打算。基于LLM的DINSQL 和若干基于PLM的方法都采用了NatSQL。
• (4) 后处置：思考了以下几类后处置战略：
• (a) 自我纠错，由DINSQL 提出，它准许智能体对生成的SQL启动自我审查，以批改潜在的失误。
• (b) 自我分歧性审核，触及对繁多人造言语查问口头多种有效的SQL查问，并经过比对结果的分歧性，采用投票机制选出最适宜的SQL作为最终结果。这一战略在C3SQL和DAILSQL中失掉了运行。
• (c) 口头疏导的SQL挑选器，作为一个模块，它依次口头智能体生成的SQL查问，并将初次无误的口头结果作为有效的SQL。
• (d) N-best重排器，经过为多个候选SQL查问打分，挑选出或者性最高的查问作为最终的查问。
基于以上论断，作者提出了SuperSQL，SuperSQL包括如下组件：
• (1) 预处置：采用RESDSQL的架构链接和BRIDGE v2的数据库内容；
• (2) 提醒：DAILSQL的大批样本模块经过相似性挑选高低文中的示例；
• (3) SQL生成：采用OpenAI的贪心解码战略，不触及多步骤或NatSQL；
• (4) 后处置：采用DAILSQL的自我分歧性模块。
SuperSQL在Spider开发集上对SuperSQL启动评价，EX到达了87.0%，逾越了其余方法。
SuperSQL在中等难度、高难度以及额外难度子集上均有出色的体现，证明了其有效性。在BIRD开发集上，SuperSQL雷同展现了不俗的性能。
还对Spider和BIRD的测试集启动了SuperSQL评价，在Spider上EX到达了87.0%（排名第二），在BIRD上EX到达了62.66%（排名第九）。
SuperSQL在其设计空间内逾越了一切基准。详细来说，在BIRD测试集上，SuperSQL比最强的基准——DAILSQL(SC)——提高了5.25%。这一优化关键得益于咱们的NL2SQL360-AAS，它有效地在设计空间内基于不同基准寻觅更优的模块组合。估量经过NL2SQL360-AAS参与更多弱小的基准将进一步优化SuperSQL。
SuperSQL的高效性能：SuperSQL在两个数据集上区分取得了99.18和61.99的VES总分，均优于其余方法。
• 优化人造言语到SQL方法的可信度：现有方法或者发生不准确的SQL结果，要素或者包括：
• 1.人造言语查问含混且不完整
• 2.数据库架构模糊且内容不规范
• 3.架构链接才干无余。
• 应答含混和不明白的人造言语查问：思考以下战略来改善这些疑问：
• (i) 查问改写器旨在智能优化给定的人造言语查问，确保其明白性。
• (ii) 查问智能补全经过介绍与数据库高度相关的候选词汇，帮忙用户构建查问。
• 解析人造言语到SQL的处置打算。
• (i) 人造言语到SQL调试工具能够发现失误的SQL查问，准许用户逐渐跟踪SQL生成流程，并辅佐识别失误或不婚配之处。
• (ii) SQL及查问结果的解释方法经常使用户能够评价生成的SQL和查问结果能否合乎预期。
• 打造高性价比的人造言语到SQL方法。基于LLM的人造言语到SQL方法前景宽广，但在令牌消耗上老本较高，这影响了老本和推理期间。探求在缩小令牌经常使用的同时优化准确性的方法至关关键。特
• 自顺应训练数据生成。人造言语到SQL方法的有效性极大水平上依赖于训练数据的品质和广度。这些方法在顺应未知数据库时经常遇到应战。一个充溢宿愿的钻研方向是应用模型评价反应灵活生成（人造言语，SQL）对，这种方法经过从人造言语到SQL的性能洞察中吸取阅历，确保训练数据的多样性和高品质，处置畛域顺应疑问。
本文转载自，作者：
本网站的文章部分内容可能来源于网络和网友发布，仅供大家学习与参考，如有侵权，请联系站长进行删除处理，不代表本网站立场，转载联系作者并注明出处：https://duobeib.com/diannaowangluoweixiu/5527.html
咚波服务与支持