text-davinci-003是OpenAI推出的一个基于这些理念的大规模语言模型，它经过专门训练，能够理解和执行更加复杂、具体的指令，从而在多项任务中展现出更高的灵活性和准确性。

途径二：Unnatural-instructions是大规模的指令遵循数据集，其收集过程几乎不需要人工。使用三个上下文演示 x1、x2、x3 的种子来创建一个包含指令、输入和输出的大型 NLP 任务数据集。第一步，先从语言模型M中对指令、输入和约束进行采样。第二步，使用 M 生成相应的输出。最后，数据可用于指令调优。这里的M用的是GPT-3 的text-davinci-002。

途径三：UltraChat多回合对话数据集，通过迭代调用两个不同的GPT-3.5 API 生成，其中一个扮演用户角色生成查询，另一个生成响应。通过设计过的提示来指导用户模型，使其模仿人类用户的行为，并迭代地调用这两个API，最后，生成的对话会再次处理和过滤来提高质量。

其中，途径一和二为单轮对话，途径三为多轮对话数据集。

自然语言转代码数据一共6GB。为了弥补自然语言提问与SQL查询之间的差距，预训练的语料从4中途径获得。

途径二：CodeAlpaca-20k，通过Self-Instruct论文技术生成的20k条指令遵循数据集，该数据集用于Code Alpaca 模型微调

途径三：Jupyter-structured-clean-dedup，StarCoder 预训练语料库的一部分，它包含了一个庞大的结构化 Jupyter Notebook集合。这些Notebook不仅包含了代码，还附有相应的自然语言说明，为理解和执行代码提供了丰富的上下文

途径四：NL-SQL-458K，论文作者们创建的数据集，首先使用正则表达式从三大开源语料库：The Pile 、The Stack以及 GitHub Code5 中提取所有“SELECT”查询。接着，滤除有语法错误的查询，最终得到45.8万个SQL查询。为了为每个SQL查询生成相应的自然语言提问，利用了GPT-3.5，借助8个配对（SQL，问题）示范的提示来进行生成。

CodeS训练小细节

在完成语料的准备之后。CodeS基于StarCoder构建，对StarCoder 进行增量预训练时，在SQL相关数据上进行了两个epoch，在自然语言相关数据和自然语言转代码数据上各进行一个epoch。这种自然语言与代码的混合训练方式为两个领域的广泛任务带来了好处。

训练过程中通过采用 AdamW 优化器来最大化序列的概率，学习率设定为5? −5，并且结合了权重衰减策略，调度器采用余弦衰减方式，不包含任何预热步骤。每批包含4m Token，采用了梯度裁剪策略来保证稳定性，裁剪阈值为1.0 。

论文作者利用了DeepSpeed Zero-3框架，结合BF16混合精度计算，来优化预训练期间的GPU内存消耗。同时将FlashAttention-2集成到CodeS中，增强了其处理更长上下文长度的能力。CodeS-(1B, 3B, 7B)最多能处理8192个token的上下文长度，而CodeS-15B只能到6144个token。

模块B：数据库提示词构建

先带着大家看下这个Text转SQL的查询模板的长相：

用户仅仅输入问题，后台需要为其额外的补上信息以便于查询能够更加精准和高效。用户输入问题的时候，若能够从用户问题自动在后台检索出出相关的表或者列或者数据库数据，以及数据库的各种元数据，那么生成SQL精准度就大为提高。因此论文作者特此设计了两个核心组件，Schema Filter和Value Retriever。当然这两个策略事先需要整合数据库数据和元数据。具体的流程如下图，左侧为流程图版本，右图为伪代码版本，都是表达相同的意思。

Schema Filter：

考虑到模型处理上下文长度有限，论文作者参考了《RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQ》的方法。RESDSQL试图解耦schema link和Skeleton Parsing，以降低文本到SQL难度。

具体的过程如下，这个组件先开发一个经过训练的Schema分类器，这个训练器是用作预测用户的提问与表和列之间关联性的分数（算法图中的1）。这里对应着下图Cross-encoder的输出，可以看到airports的表相关度最高，里面的city的列关联度也很高。然后从输出中利用分数，保留排名top k1的表以及表中排名top k2的列（算法图中的2），schema分类器构建如下。

下图来至RESDSQL这篇论文。在原始的论文中得出和查询相关的表和列之后，会进一步将问题+相关的表和列+额外的外键再次输入新的骨架模型，输出类似select..的SQL语句。这种算法其实就是解耦了数据库元信息和SQL语句生成。

Value Retriever：论文作者认为，如果模型在构造SQL查询时能获取到问题中提及的具体值，能提高生成的查询语句的准确性。文中拿了BIRD评估基准的问题举例，“Jesenik分行开设账户的客户中有多少是女性？”，这里就需要与数据库中的数据进行对比。若在“district”表中的“a2”列存储着值“Jesenik”，将“district.a2 = 'Jesenik'带入到数据库提示中来帮助模型生成更精准的回答。

考虑计算数据库值与问题之间匹配度的算法LCS（longest common substring）会及其耗时。作者采用的办法是采用“从粗到精”的逻辑，先用粗粒度的索引缩小匹配的方位，然后再采用LCS进行精校。

这里采用Lucene来为数据库中存储得所有值构建BM25索引，当查询用户提问时利用索引快速找到可能相关得值（算法图中的3.），再采用LCS方法来计算匹配程度，从而找出最相关的值（算法图4.）

BM25是信息索引领域用来计算query与文档相似度得分的经典算法。不同于TF-IDF，BM25的公式主要由三个部分组成：query中每个单词??与文档d之间的相关性。单词??与query之间的相似性。每个单词权重。

BM25的一般公式：?????(?,?)=∑???(??,?)。其中?表示一条query，??表示query中的单词。d表示某个搜索文档。?? 表示单词权重，这里其实就是IDF:???(??)=log⁡(?−???+0.5)/(???+0.5)。

其中N表示索引中全部文档数， ??? 为包含了??的文档的个数。依据IDF的作用，对于某个??，包含??的文档数越多，说明??重要性越小，或者区分度越低，IDF越小。因此IDF可以用来刻画??与文档的相似性。

Database Metadata：在提示模板中还融入了元数据信息，包括列得数据类型、注释（提高语义理解和模式关联正确性）、典型数据库值（类似枚举值等）和主外键关联关系（确保JOIN ON子句的准确生成）。

模块C：双向语料自动生成与增强

Spider是一个广受认可的文本到SQL评估基准，涵盖了75个常见的SQL模板。例如，一个模板化的问题：“返回{TABLE}中最低的{COLUMN}”，以及其对应的模板化SQL：“SELECT {COLUMN} FROM {TABLE} GROUP BY {COLUMN} ORDER BY COUNT(*) ASC LIMIT 1”。

为了继续增加这些(QRefine, SQL)对的数量，研究人员将三元组带上剩下的模板提问一并给到GPT-3.5来自动生成对应的QRefine，以便生成更多的(QRefine, SQL)对。

• 如何优雅的谈论大模型
• LLM背后的基础模型
• AI架构设计