Upload 8 files

allpdf-part1.zip

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:672353667a9d06f3ee8c688c6b0ebad30bf25847eaab2597d15b7f9b0ce52d6a
+size 13964776279

allpdf-part2.zip

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:076e18898ced0960cac9d0c69ed6fbcbe58ac37822582d0991658fd0c8d2e8f5
+size 11846496543

allpdf-part3.zip

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:dd9dcb6f4d958a1c3ee5e60ba549eacd08329c0492c97951bc9ed2656f8d7a4e
+size 9776684018

大模型综合项目二.zip

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:231396ca42d895a130bb04e0def6cddfb3366e360cb210fdfff79c7e44b23ef3
+size 1705888038

简历模版-项目实战2-7ba0301a9462.md

@@ -0,0 +1,79 @@
+# 简历模版
+
+## 【重要】
+
+项目实战2提供了3个简历模版，提供一些定制化简历的一些思路，大家可以酌情使用但不能完全照抄。根据学到的大模型技术进行扩展（例如，部署阶段，RAG基础和进阶的阶段，大模型微调阶段，还有推理优化阶段），技术方案是通用的，而不是局限于某一种场景，大家完全可以拓展到其他项目背景，或者与自己的研究方向，实习方向，工作方向相结合。将所学技术融会贯通，形成有“自身鲜明特点”的项目。
+
+## 题目1:金融年报解读智能交互系统
+
+#### 项目背景：
+
+基于A股上市公司1万+份年报PDF，结合LLM构建了一个交互问答系统，解读上市公司年报并回答金融相关的问题。微调了3个7B的领域子模型和32B的总结模型，用大小模型协同的方式，完成了基本信息查询，统计分析查询，以及开放性问题三种细粒度的金融场景问答交互。
+
+#### 工作内容：
+
+- 采用xpdf解析PDF提取页面文字，根据关键词完成页面召回，camelot库实现基于图像识别的表格提取，并完成非合并报表，调整报表，母公司报表等信息整合和过滤；
+- 问答系统采用分层设计，构造6k条高质量SFT数据，微调Qwen2.5-7B意图识别模型，针对用户query的问题类型实现精准落域，落域准确率94%；
+- LoRA微调了NL2SQL查询模型和Keywords抽取模型，精准问答走数据库NL2SQL引擎，非精准问答走检索+LLM总结生成，构建不同问题类型的Prompt，用Qwen2.5-32B生成回复，评测准确率87%；
+- 模型部署采用vLLM做推理加速，并采用Docker容器化部署。针对3个子模型以及全链路做了性能压测，采用流式输出，平均0.8s出首token，整体平均2.7s；
+
+项目亮点：
+
+- 加入 prefix cache 优化推理速度，首 token 耗时下降 70%；采用 GPTQ 方法将模型量化至 INT8版本，推理延迟平均下降 1.1s；引入 qwen2.5-7B 通过投机采样的方式加速32B模型推理。最终，模型能够在平均 2.7秒完成答案生成；
+- 利用vLLM+Punica实现单底座+多adaper的部署模式，SGMV算子实现3个LoRA模型的batch推理，并节省2倍的GPU部署资源；
+
+## 题目2: FinMind: 基于大模型的金融对话交互与智能分析助手
+
+#### 项目概要: 
+
+FinMind 是一个基于大语言模型的金融对话系统，专注于上市公司年报解析与自动化问答，为分析师投资决策提供数据支持，提高信息处理效率。系统整合了多模态数据处理、自然语言理解与生成技术，支持从海量年报中快速提取关键信息。
+
+#### 个人职责:
+
+- PDF 解析与信息抽取：解析 11588 份上市公司年报（70GB 数据），采用 pdf2text 和 camelot-py 进行文
+  本抽取和表格提取。
+- 问题分类：结合 P-Tuning v2 微调后的 GLM4-9B 构建问题分类器，针对如公司财务报表、统计分析等问题进行分类，实现约 90% 的分类准确率。
+- 关键词抽取：基于 LoRA 微调后的GLM4-9B 构建自动化关键词生成流程，结合 Prompt 和少样本学习对提取结果进行筛选和降噪，将用户问题的核心要点结构化输出。
+- NL2SQL 生成：利用 SQL 模板和数据增强构造训练数据，结合 GaLore 微调后的 GLM4-9B实现自
+  然语言到 SQL 语句的转换，使 SQL 生成准确率提升至 82%。
+
+#### 项目成果: 
+
+解析了覆盖 3102 家上市公司的公司年报，支持金融尽职调查、投资研究等场景，节省分析师约 50% 的初级筛查时间
+
+# 题目3: 深度学习作业自动化批注助手
+
+### 项目介绍
+
+基于深度学习课程作业批注需求，需构建一个高效、精准的自动化作业批注系统，支持对多种类型作业（如基础知识性问答、代码编写、论文总结）的智能化评估。由于作业内容形式多样（文本+代码，主观题+客观题）、任务类型复杂，需结合LLM与专业领域知识处理技术，实现高准确率、低延迟的批注服务。
+
+#### 主要工作
+
+- 分层模型架构：
+  1. 作业类型分类层 ：
+     - 微调Qwen2.5-7B意图识别模型（6k条SFT数据），实现94%的落域准确率，区分作业类型（如客观题/主观题）。
+     - 使用Prompt工程定义清晰的分类模板，例如“判断该作业是否包含代码片段”或“判断该作业是否涉及论文总结”。
+  2. 客观题批注层 ：
+     - 针对选择题和填空题，使用正则表达式或关键词匹配验证答案正确性。
+     - 对于复杂填空题，结合规则+微调轻量级模型（Sentence-Bert）进行答案相似度计算。
+  3. 主观题批注层 ：
+     - 微调Keywords抽取模型（Qwen2.5-7B），提取学生回答中的关键概念，与标准答案对照，结合LLM生成评分。
+     - 针对论文总结作业，使用大语言模型（Qwen2.5-32B）+ Prompt设计从忠实度，内容覆盖率和答案���关性三个方面进行打分。
+  4. 综合答案输出层 ：
+     - 整合各层批注结果，生成最终评分和综合反馈，包括得分详情、错误点分析和改进建议。
+
+#### 性能优化与部署
+
+- **推理加速** ：
+  1. 采用vLLM实现前缀缓存（首Token耗时降低70%）和GPTQ量化（INT8模型延迟降低1.1s）。
+  2. 通过投机采样（Qwen2.5-7B加速Qwen-32B）进一步提速。
+- **资源节省** ：基于vLLM+Punica实现单底座多Adapter部署，利用SGMV算子批量推理3个LoRA模型，节省50% GPU资源。
+- **容器化** ：Docker封装全链路服务，压测后平均响应时间2.7秒（首Token 0.8秒）。
+
+### 项目亮点
+
+✓ 系统支持多作业场景批注，意图识别准确率94%，答案判别准确率87%，显著优于通用LLM。
+
+✓ 多模型协同部署方案节省2倍GPU资源，支持高并发场景下的稳定服务。
+
+✓ 为深度学习课程作业提供高效批注工具，后续可扩展至其他学科（如数学建模、自然语言处理实验）的作业评估场景。

简历模版-项目实战2.md

@@ -0,0 +1,79 @@
+# 简历模版
+
+## 【重要】
+
+项目实战2提供了3个简历模版，提供一些定制化简历的一些思路，大家可以酌情使用但不能完全照抄。根据学到的大模型技术进行扩展（例如，部署阶段，RAG基础和进阶的阶段，大模型微调阶段，还有推理优化阶段），技术方案是通用的，而不是局限于某一种场景，大家完全可以拓展到其他项目背景，或者与自己的研究方向，实习方向，工作方向相结合。将所学技术融会贯通，形成有“自身鲜明特点”的项目。
+
+## 题目1:金融年报解读智能交互系统
+
+#### 项目背景：
+
+基于A股上市公司1万+份年报PDF，结合LLM构建了一个交互问答系统，解读上市公司年报并回答金融相关的问题。微调了3个7B的领域子模型和32B的总结模型，用大小模型协同的方式，完成了基本信息查询，统计分析查询，以及开放性问题三种细粒度的金融场景问答交互。
+
+#### 工作内容：
+
+- 采用xpdf解析PDF提取页面文字，根据关键词完成页面召回，camelot库实现基于图像识别的表格提取，并完成非合并报表，调整报表，母公司报表等信息整合和过滤；
+- 问答系统采用分层设计，构造6k条高质量SFT数据，微调Qwen2.5-7B意图识别模型，针对用户query的问题类型实现精准落域，落域准确率94%；
+- LoRA微调了NL2SQL查询模型和Keywords抽取模型，精准问答走数据库NL2SQL引擎，非精准问答走检索+LLM总结生成，构建不同问题类型的Prompt，用Qwen2.5-32B生成回复，评测准确率87%；
+- 模型部署采用vLLM做推理加速，并采用Docker容器化部署。针对3个子模型以及全链路做了性能压测，采用流式输出，平均0.8s出首token，整体平均2.7s；
+
+项目亮点：
+
+- 加入 prefix cache 优化推理速度，首 token 耗时下降 70%；采用 GPTQ 方法将模型量化至 INT8版本，推理延迟平均下降 1.1s；引入 qwen2.5-7B 通过投机采样的方式加速32B模型推理。最终，模型能够在平均 2.7秒完成答案生成；
+- 利用vLLM+Punica实现单底座+多adaper的部署模式，SGMV算子实现3个LoRA模型的batch推理，并节省2倍的GPU部署资源；
+
+## 题目2: FinMind: 基于大模型的金融对话交互与智能分析助手
+
+#### 项目概要: 
+
+FinMind 是一个基于大语言模型的金融对话系统，专注于上市公司年报解析与自动化问答，为分析师投资决策提供数据支持，提高信息处理效率。系统整合了多模态数据处理、自然语言理解与生成技术，支持从海量年报中快速提取关键信息。
+
+#### 个人职责:
+
+- PDF 解析与信息抽取：解析 11588 份上市公司年报（70GB 数据），采用 pdf2text 和 camelot-py 进行文
+  本抽取和表格提取。
+- 问题分类：结合 P-Tuning v2 微调后的 GLM4-9B 构建问题分类器，针对如公司财务报表、统计分析等问题进行分类，实现约 90% 的分类准确率。
+- 关键词抽取：基于 LoRA 微调后的GLM4-9B 构建自动化关键词生成流程，结合 Prompt 和少样本学习对提取结果进行筛选和降噪，将用户问题的核心要点结构化输出。
+- NL2SQL 生成：利用 SQL 模板和数据增强构造训练数据，结合 GaLore 微调后的 GLM4-9B实现自
+  然语言到 SQL 语句的转换，使 SQL 生成准确率提升至 82%。
+
+#### 项目成果: 
+
+解析了覆盖 3102 家上市公司的公司年报，支持金融尽职调查、投资研究等场景，节省分析师约 50% 的初级筛查时间
+
+# 题目3: 深度学习作业自动化批注助手
+
+### 项目介绍
+
+基于深度学习课程作业批注需求，需构建一个高效、精准的自动化作业批注系统，支持对多种类型作业（如基础知识性问答、代码编写、论文总结）的智能化评估。由于作业内容形式多样（文本+代码，主观题+客观题）、任务类型复杂，需结合LLM与专业领域知识处理技术，实现高准确率、低延迟的批注服务。
+
+#### 主要工作
+
+- 分层模型架构：
+  1. 作业类型分类层 ：
+     - 微调Qwen2.5-7B意图识别模型（6k条SFT数据），实现94%的落域准确率，区分作业类型（如客观题/主观题）。
+     - 使用Prompt工程定义清晰的分类模板，例如“判断该作业是否包含代码片段”或“判断该作业是否涉及论文总结”。
+  2. 客观题批注层 ：
+     - 针对选择题和填空题，使用正则表达式或关键词匹配验证答案正确性。
+     - 对于复杂填空题，结合规则+微调轻量级模型（Sentence-Bert）进行答案相似度计算。
+  3. 主观题批注层 ：
+     - 微调Keywords抽取模型（Qwen2.5-7B），提取学生回答中的关键概念，与标准答案对照，结合LLM生成评分。
+     - 针对论文总结作业，使用大语言模型（Qwen2.5-32B）+ Prompt设计从忠实度，内容覆盖率和答案���关性三个方面进行打分。
+  4. 综合答案输出层 ：
+     - 整合各层批注结果，生成最终评分和综合反馈，包括得分详情、错误点分析和改进建议。
+
+#### 性能优化与部署
+
+- **推理加速** ：
+  1. 采用vLLM实现前缀缓存（首Token耗时降低70%）和GPTQ量化（INT8模型延迟降低1.1s）。
+  2. 通过投机采样（Qwen2.5-7B加速Qwen-32B）进一步提速。
+- **资源节省** ：基于vLLM+Punica实现单底座多Adapter部署，利用SGMV算子批量推理3个LoRA模型，节省50% GPU资源。
+- **容器化** ：Docker封装全链路服务，压测后平均响应时间2.7秒（首Token 0.8秒）。
+
+### 项目亮点
+
+✓ 系统支持多作业场景批注，意图识别准确率94%，答案判别准确率87%，显著优于通用LLM。
+
+✓ 多模型协同部署方案节省2倍GPU资源，支持高并发场景下的稳定服务。
+
+✓ 为深度学习课程作业提供高效批注工具，后续可扩展至其他学科（如数学建模、自然语言处理实验）的作业评估场景。

项目题库-项目实战2-5263d3fd3011.md

@@ -0,0 +1,223 @@
+# 项目题库
+
+### 面试官可能问的问题
+
+#### 1.请介绍一下这个项目
+
+答：这个项目是基于A股在2019～2021年上市公司1万多份年报PDF文件，结合Qwen2大模型构建了一个交互问答系统，解读上市公司年报并回答用户金融相关的问题。
+
+在项目中，微调了3个Qwen-7B的领域子模型，分别用来做意图识别，NL2SQL，以及关键词抽取，最后再利用Qwen-32B大模型做总结生成，项目采用大小模型协同的方式，完成了基本信息查询，统计分析查询，以及开放性问题三种细粒度的金融场景问答交互，最终的问答准确率达到87%。
+
+同时利用Docker容器化部署，服务采用流式输出，并利用prefix cache和vllm实现推理加速，以及punica的多LoRA融合节省2倍的GPU资源，实现低成本部署。
+
+#### 2.这个项目的难点或挑战是什么？
+
+答：这个项目因为是处理真实的上市公司年报数据，并以大模型为中心来实现一个问答系统，在做这个项目的时候，遇到不少的挑战，主要有以下5个方面：
+
+- 测试集问题种类多样，包含计算类、查询类、分析类等，很难通过一个模型来解决，需要引入多个模型与工具。
+- 数据格式比较复杂，直接从pdf中抽取出规范化数据也是比较困难的，例如表格跨页的问题，还有PDF解析失败的问题
+- 没有微调数据集，人工标注数据成本高，如何利用GPT4等API，自动，高效的构造出高质量的SFT数据集
+- 小模型6B/7B的幻觉问题比较重，下游微调可以缓解幻觉乱说的情况。
+- 大模型生成不可控，难以保证输出结果的规范性，这部分需要精调prompt来控制
+
+#### 3.具体介绍一下基本信息查询，统计分析查询，以及开放性问题三类任务的不同
+
+答：公司基本信息查询是直接能从年报中找到并定位答案的，包括公司的法人，雇员情况，研发成本，财务费用，营业支出等。统计分析查询是指需要经过一些关联指标查询和简单数学运算，例如某个公司的研发费用增长率是多少。第三类问题是开放性问题，一般是需要总结推理的问题，比较适合用大模型直接总结输出，例如某个公司的技术领域是否涉及国家创新技术领域，是否属于AI 人工智能领域，或者总结一下某公司的核心技术优势，亮点有哪些。
+
+#### 4.模型结果是如何评测的，怎么计算回答的准确度
+
+答：评测针对不同问题类型采用了两种指标计算方法。对于基本信息查询和统计分析查询，输出有关键词信息，还有数值答案，以及生成的回复。得分采用数值答案+关键词信息 + 答案相似度得分三部分加权。但如果数值答案是错的，那得分就是0分。如果数值答案是正确的，关键词是错误的，那得分就是0.25+0.5\*答案相似度得分，如果数值答案和关键词都是对的，那得分就是0.5+0.5\*答案相似度得分。对于第三类开放性问题，直接采用答案匹配相似度得分。其中相似度采用了text2vec-large-chinese作为向量匹配模型。
+
+#### 5.做这个项目的过程中，你遇到的难点或挑战是什么？
+
+答：这个项目数据量很大，大约有70G，而且年报数据格式不统一，对于解析，处理，查询，生成每个阶段都有不小的挑战，具体来说，有以下几点：
+
+1、测试集问题种类多样，包含计算类、查询类、分析类等，单个框架难以处理
+
+2、数据格式复杂，难以直接从pdf中抽取出规范化数据
+
+3、没有微调数据集，人工标注数据成本高，如何高效的设计高质量的数据集
+
+4、大模型生成不可控，难以保证输出结果的规范性
+
+#### 6.PDF非结构化数据解析有没有遇到什么问题？是怎么解决的？
+
+答：RAG应用中处理复杂文档内容是一个挑战，特别是处理PDF文档中的图片和表格。解析和检索PDF文件中的表格是一个技术难点，需要使用OCR技术来识别表格内容。
+
+我在做这个项目的时候，调研了几种主流的技术方案，首先是用Nougat作为解析PDF文档的工具，可以将表格内容转换为结构化数据，然后使用LlamaIndex可以对解析后的表格数据进行索引和检索。UnstructuredIO方案是将PDF文件转换为HTML文件，然后使用LlamaIndex进行处理。比较高级一点的是采用多模态的思路，使用OpenAI的GPT4o模型来处理表格内容。但目前还没有一种方案可以完美满足所有需求。
+
+最后发现，camelot-py基于图像识别的表格提取精度还不错，考虑精度和速度两方面的因素折中，最终采用了这种方案。首先根据报表名称设置关键词找到对应的页，提取表格字段和value后，为了查询方便，将关系型数据（包括表格和基本信息），按照每家公司一行的方式，做成一张大宽表。这样可以避免跨表查���的复杂度。
+
+#### 7.为什么要在前面做一层问题分类，有什么好处？
+
+答：如果不做问题分类，直接做检索召回生成，各自问题混合在一起，精度会受到很大的影响。因为不同问题类型所需要的输入信息，prompt都是不一样的。利用一个前置模型做一层问题分类的意图分发，可以有效的把问题分流落域，然后再分门别类的处理，针对每一种query都可以定制不同的处理方式，以及关联对应的输入字段，还有调优prompt。所以，做成2层的漏斗系统可以同时提高问题的效率和精度。
+
+#### 8.问题分类做了哪几个类别？
+
+答：问题分类做了六大类别。
+
+第一个是公司基本信息，这个可以通过检索【公司基本信息表】来获取答案；
+
+第二个是公司员工信息，这个可以通过检索【公司员工信息表】来获取答案；
+
+第三个是财务报表相关内容，这个可以通过【财务三大报标】来获取结果；
+
+第四个是计算题，需要根据问题类型检索计算因子来完成计算；
+
+第五个是统计题，需要根据问题类型分析条件检索来获取结果；
+
+第六个是开放性问题，根据问题关键词来检索全文相关匹配的召回材料来总结回答问题；
+
+#### 9.问题分类的指令微调数据是怎么构造的？
+
+答：指令微调的数据主要是通过少样本in-context 学习生成数据集，并进行人工校验的方式来生成的。抽取几十个个样例报标喂给gpt4，构造问题分类描述的prompt，然后让gpt4根据文档来提问，并自己回答问题的类型；这样可以得到一批种子训练语料，然后在人工对这批语料进行check，去除标注错误的数据和脏数据。为了让指令微调的数据具有多样性和高质量，我们还利用GPT4对这批数据进行说法泛化，具体包括为句式的改变，转换为非正式或口语化说法，以及省略说法，和句子容错等处理，最后得到6k条高质量的问题分类指令微调数据集。
+
+#### 10.那在微调过程中，有遇到什么问题吗，是如何解决的？
+
+答：最早期的一次微调，一开始的效果比较糟糕，最后发现是训练字段小于传入的模版+问题的字符串，导致训练过程中的传入字段丢失截断。loss一直在0.20下不去，距离第一轮训练目标0.10以下还有很大差距，实用情况比较糟糕。
+
+通过统计问题和答案的长度，最后调整了max\_source\_length参数符合max（问题+答案)的条件，确认了max\_source\_length为512，max\_target\_length为128，使用qwen2-7b进行LoRA微调，step为250，训练结果的loss到了0.09，基本可用级别。
+
+为了获取更好的效果，尝试对prompt不断进行调整，从一开始的只有选项的题目，到有一定信息的选项描述（高频的关键字等），同时对训练step加大到400，对微调训练有很大的帮助，loss的下降比较明显, 最优平均值达到0.01以下，拥有比较优秀的分类能力。在微调过程中，还发现尝试调低Learning rate可以获得更快的训练收敛效益，这也是在小数据微调时的一个技巧。
+
+#### 11.为什么要做NL2SQL生成，你是如何做的？
+
+答：因为很多计算和统计类型的问题，需要操作数据库表里的字段进行简单运算，所以用SQL就是很方便和自然的。我这边测试过，Qwen本身有一定的NL2SQL能力，但是难以在项目中稳定输出有效正确的SQL格式的语句。Qwen官网的商用版本，Qwen-Max具有有良好的NL2SQL的性能，所以我判断应该可以透过微调训练来增强7B的SQL能力。早期尝试用公共的NL2SQL训练集（2019年NL2SQL大赛的公开标注数据集），大概40000多道题目（包含电影、书籍、评价、金融等等五花八门的题目类型）。结果发现，不仅没有能够很好对题目进行SQL生成（loss在0.36-0.50降下不去），而且丧失了基本的对话能力。
+
+经过分析，我觉得要想稳定生产准确有效SQL语言，是需要根据实际的任务情况和方向来设定训练目标，最后决定自己来标注训练集，为了加快效率，使用gpt4/Bard来协助生成该写出不同提问模板，再透过字段的随机条件填充。构建针对其模版格式的问题训练集，根据四个模版SQL扩充了24种不同问法，并且强化了除了查询以外的SQL语句如排序，输出范围，统计计数，条件求和，单字段检索，多字段检索，多字段检索多字段，字段的过滤等。最后构造了1000多条高质量涵盖所有查询类型的微调语料，对Qwen2-7B进行了微调，微调后的效果很好，准确率在95%以上，满足查询要求。
+
+#### 12.你刚才提到用了模版来构造NL2SQL的语料，具体是怎么做的？
+
+答：NL2SQL任务涉及将自然语言问题转化为SQL查询，以从数据库中检索信息。构建NL2SQL模板的步骤如下：
+
+- 定义查询类型：查询，排序，输出范围，计数，求和，单字段检索，多字段检索，多字段检索多字段，字段的过滤等SQL执行需求。
+- 示例对话：催眠大语言模型进行Agent扮演Mysql数据库开发人员，通过自然语言问题和相应的SQL查询的示例对话提供对指令的理解。
+- 数据库字段：传入数据库表名，设计的字段，该数据库已经较好的清洗合并数据，同类型字段检索能有较好的性能。
+- 生成SQL查询：根据SQL语法树，生成正确的的SQL执行语句。
+- 参数替换：将自然语言问题中的参数（如列名、条件等）替换为存在库中的数据库元素。
+
+模版构造好以后，就采用随机变量填充+GP4说法泛化来进一步扩充到更大的语料。
+
+#### 13.线上NL2SQL要做的好不容易，你在这个过程中有哪些好的实践经验
+
+答：NL2SQL微调训练重点任务还是构造训练数据集。但是，要针对实际数据查询场景构造数据集，而非使用Spider等通用的数据集。GPT4生成泛化的数据还是需要进一步人工来做校验，对于微调来说，数据的质量要求，远大于数据的数量要求。我还总结了以下三点有用的做法：
+
+1. 使用一张大宽表 **，** 而不是多表，单表查询的SQL语句比较简单，生成SQL语句的准确率很高。
+2. 在Prompt中可以明确指定字段，提升准确率。至于如何准确定位库表字段，可以采用关键词匹配的方式。
+3. 当遇到一些需要计算的场景，比如：营业利润率 = 营业利润 / 营业收入。此时最好拆分问题，生成多个简单的SQL查询语句，分别获取营业利润和营业收入后，再调用公式计算。
+
+#### 14.讲一下关键词提取是怎么做的？
+
+答：很多场景下，我们都需要通过Prompt，给到大模型来提取关键词。比如，通过提取用户问题中的关键词，我们可以理解用户意图，再按照规则来匹配回答问题的方法。但是对于专业领域，如果像Qwen-7B这样的模型，不能很好地理解和准确提取专业术语，那么就可以微调一个关键词模型，用于在用户提问中提取相关专业的关键词。关键词提取任务涉及从文本中提取关键词或短语，有助于后面检索相关信息，越精准的提取越能够让返回的信息更加准确。以下是构建关键词提取模板的步骤：
+
+- 构建关键词提取的prompt，需要不断尝试prompt对问题的处理和稳定性，非微调的情况下few-shot也能有合格的表现。提示可以写成：“请帮我从以下句子中提取关键词。这些关键词是句子中最重要、最能概括句子主题的词汇。通过这些关键词，你可以更好地理解句子的内容。你只需要回答文本中的关键词，不要回答其他内容.”
+- 示例文本：收集不同具有代表性的问题所包含所需关键词类型的示例文本
+- 构建模板：根据问题集的问题遍历提取用户提问，构建训练集的prompt模板
+
+有了模版以后再利用GPT4泛化和人工修正，最后微调出一个7B模型。初次之外，针对金融领域的某些专业名词，模型不容易学习到，我还构建维护了一个专业名词缩略语库和同义词库，用AC自动机匹配的方式提取这部分的关键词信息，提升了关键词的召回能力。
+
+#### 15.你说说基本信息类问题的处理流程是什么？
+
+答：根据用户提问，首先提取query中的公司名称和年份信息，根据公司名称和年份以及意图匹配报表的表格字段。若干匹配到文本字段与多个年份，则加入文本比较信息，把多个年份的数据都定位抽取出来。然后利用组合信息自动生成prompt，在生成prompt的过程中，有几点注意的，首先是文本类字段讲字段值加双引号，非文本类字段将字段名称加双引号。对于人数类的字段结果为XX有XX人，其他字段结果为XX是XX，金额类的字段结果为XX是XX元。构造好prompt以后，再喂给32B大模型，生成最终的答案。
+
+#### **16.你说一下统计计算类问题的处理流程是什么**？
+
+答：对于统计计算类的问题，首先根据用户问题匹配问题中是否出现比值类的关键字，把这些关键字匹配出来，提前维护了一个比值类计算公式的映射表，然后根据找到关键字取出对应比值的计算公式。然后根据公式生成问题链，也就是公式的所需要的变量，然后通过问题链解析所需要的字段值，然后调用NL2SQL生成对应的SQL语句，然后利用SQL从表中提取出来，有了字段值，最后就可以通过python计算得到结果。然后把计算结果，query，以及问题链一起输入给32B的生成大模型，得到最终的回答。
+
+#### 17.对于总结类的问题，处理流程是什么？
+
+答：首先根据query识别，识别提问中的公司名称，年份和意图关键词，然后根据关键词和问题分别召回top3相关的文本片段，这里关键词召回采用了BM25的匹配，问题召回采用了BGE embedding做语义召回，最后根据召回的文本，自动组合生成prompt，最后再把prompt输入给qwen-32b大模型，输出最终的答案。总结类问题相对第一种和第二种类型简单一点，采用的是RAG的常见流程和做法。
+
+#### 18.你这个项目里面不同的问题构造来不同的prompt，那在prompt构造方面，有没有什么心得可以分享下？
+
+答：是的，prompt构造在这个项目中是非常重要的，针对不同问题类型，都定制和调优了最适合的prompt。心得方面，主要有这几个方面。
+
+首先就是角色定义，这个写法一定要精确，与需要完成任务所需要的背景知识要匹配。
+
+第二是任务的目标描述要简洁明了，避免使用模糊或带有歧义的词汇。
+
+第三是任务的具体要求，步骤多用美剧，少用否定句，对于某些流程较长的需要考虑拆分为多个任务，也就是思维链的思想。
+
+最后一个是输出要有明确的输出格式要求，对于重要任务的要求，可以在prompt里面做二次强调。对于强制json类输出的任务，可以把左大括号先打出来放到提示的最后，经过实际验证表面，这样写会比直接让大模型输出json更能够锁得住格式。
+
+#### 19.模型微调这块，有没有想过做进一步优化？
+
+答：模型微调这块确实想过做进一步的优化。因为现在是3个7B的子模型微调，指令微调的数据和prompt也是3种，在训练方面需要训练三次，导出三个不同的lora adapter，但基模是一样的。这对资源是一种浪费。考虑过一种优化方案就是对指令微调的数据集做一个合并，把意图分类的，NL2SQL和关键词抽取合到一起，做一个多任务的指令微调，最后就导出一个lora权重，这样可以很大的减少模型处理的复杂度，也节省一定的计算资源。针对三个lora权重的问题，我在服务部署的时候，采用了另一种解决思路，可以同时对三个子模型进行批量的推理。具体做法是利用了单底座+多lora合并的方案，即把做个lora挂载到一个底座上，推理的时候直接进行批量推理，底层把这三种模型的请求自动做合并，这样一方面保证了推理的速度，另一方面又节省了部署GPU资源。
+
+#### 20.那你展开说一下单底座+多lora是怎么做的？
+
+答：好的，这块其实最近有相关论文做这方面的研究。因为在采用同一个底座微调多个模型的时候，只有lora部分的权重是不一样的，底座是完全相同的。如果部署的时候还是分开部署，那每次请求，底座都要重复计算N次，而且需要分开部署多个服务实例，对资源是一种很大的浪费。因此有论文就考虑做这方面的优化，比如国外predibase公司的LoraX，以及伯克利提出的SLoRA，还有最近华盛顿大学提出的Punica。这个任务的核心问题就是如何把多个lora的多次矩阵乘法合并成一个矩阵乘法运算。一般采用的算子有两种，一个是SGMV，另一个是BGMV，在最新的vLLM框架中集成了了punica的高效BGMV算子的实现，同时支持了多lora。最后，项目服务部署上线也采用了vLLM多lora部署的方式，实测并发lora调用下，跟单个lora调用，性能几乎没有下降。
+
+#### 21.我看你还用了prefix cache做优化，讲一下它的原理吧？
+
+答：Prompt 计算（Prefill 阶段）和生成阶段的计算特性很不相同。为避免重复计算，所有框架的 prefill 阶段主要作用就是给迭代的生成阶段准备 KV Cache。但这些 KV Cache 仅仅是为单次生成式请求服务的，那很自然的一种想法就是，KV Cache 能不能跨请求复用。在我们的项目场景下，多次请求的 Prompt 可能会共享同一个前缀（Prefix），比如系统的prompt，query，上下文内容等。这些情况下，很多请求的前缀的 KV Cache 计算的结果是相同的，像一般互联网服务的请求缓存一样，可以被缓存起来，给下一个请求复用。 vLLM 的实现是给 generate 接口增加一个 prefix\_pos 参数，通过 prefix\_pos 输入参数为每个请求指定 prefix 长度，为 prefix 建一个带淘汰的哈希缓存。后来觉得这样做使用上不够便利，升级成了自动前缀缓存，即将 prompt 的 kv cache 分成 block，然后为 block 建设 LRU 缓存机制，这样就不必在接口上使用 prefix\_pos 指定哪部分是 prefix 了。自动前缀缓存功能默认是不开启的，开启的配置项为 --enable-prefix-caching ，本项目是开启了这个优化，首 token 耗时下降 70%。
+
+#### 22.模型部署还用来GPTQ来量化，说一下它的原理？
+
+答：GPTQ 并不是凭空出现的，它的原理来自于另一个量化方法OBQ，而OBQ 实际上是对 OBS(一种比较经典的剪枝方法）的魔改， 而OBS则来自于OBD，由 Yann LeCun 在1990年提出的剪枝方法。GPTQ 对 OBQ 做了一些算法和性能上的优化，在降低量化算法复杂度的同时保留了模型的精度，因而可以实现大模型的高效量化。可以说 GPTQ 是它的加速版，使用 GPTQ 量化一个 Bloom 模型 (176B) 则只需不到 4 个小时；并且 GPTQ 的量化有严谨的数学理论推导，所有的算法步骤都有理论支撑。
+
+GPTQ采用 int4/fp16 (W4A16) 的混合量化方案，其中模型权重被量化为 int4 数值类型，而激活值则保留在 float16，是一种仅权重量化方法。在推理阶段，模型权重被动态地反量化回 float16 并在该数值类型下进行实际的运算；同 OBQ 一样，GPTQ还是从单层量化的角度考虑，希望找到一个量化过的权重，使的新的权重和老的权重之间输出的结果差别最小。
+
+GPTQ 将权重分组（如：128列为一组）为多个子矩阵（block）。对某个 block 内的所有参数逐个量化，每个参数量化后，需要适当调整这个 block 内其他未量化的参数，以弥补量化造成的精度损失。因此，GPTQ 量化需要准备校准数据集。
+
+GPTQ 的工作原理如下：
+
+- 首先，GPTQ 使用 group 量化将权重分组为多个子矩阵。
+  然后，GPTQ 使用 OBQ 方法来量化每个子矩阵。
+  最后，GPTQ 使用动态反量化来恢复权重的原始值。
+
+GPTQ 的改进主要体现在以下几个方面：
+
+- 分组量化：GPTQ 使用分组量化来将权重分组为多个子矩阵，这可以降低量化精度损失。
+  OBQ 方法：GPTQ 使用 OBQ 方法来量化权重，该方法可以实现高精度的量化。
+  动态反量化：GPTQ 使用动态反量化来恢复权重的原始值，这可以提高量化的性能。
+
+总结一下，GPTQ 是把量化问题视作优化问题，逐层寻找最优的量化权重。
+
+#### 23.有对比过其他的量化算法吗？
+
+答：有的，我这边对比过AWQ量化，AWQ是一种面向LLM低比特权重量化的硬件友好方法。它基于激活感知的权重量化策略，通过观察激活而不是权重来搜索保护显著权重的最佳通道缩放。
+
+AWQ的优点在于它能够保留更多的模型信息，同时实现高效的权重量化。AWQ量化后的推理速度确实要快一点，不过我这边利用autoAWQ量化模型，尝试了几种不同的校准数据集，包括公开的校准数据集以及训练数据，发现精度都没有GPTQ高，有一定量化损失，而且AWQ的量化成本比较高，因此最后还是采用比较成熟的GPTQ量化，qwen官网发布的Int8量化版本，因为我用的是A100卡，有Int8的TensorCore，所以Int8的推理速度是最快的，这也是没有采用Int4的原因。
+
+#### 24.除此之外，还用了哪些方法来加速推理
+
+答：除了量化和vLLM的paged attention加速以外，还采用了speculative decoding来对32B的生成大模型来做生成加速。Speculative Sampling引入了一个小模型，它的潜在假设是许多常见的文本和句子是很容易被预测出来的，可以用更简单的模型来近似。在自回归解码中加入投机采样，其原理简单来说就是：使用两个模型，一个是原始目标模型，另一个是比目标模型小得多的近似模型。近似模型用于进行自回归的串行采样，大模型对采样的结果进行评估，决定是否接受近似模型的采样结果，这样大模型只需要处理小模型无法处理的复杂部分，这个方法不需要修改大模型的结构，也不需要重新训练模型，降低推理成本的同时，实现推理提速。最后，我评测对比了0.5B, 1.8B, 7B，以及14B的效果，综合加速比来看7B的加速比是最高的，最终小模型采用了qwen2-7B来作为speculative decoding的小模型，达到了1.7倍的加速。
+
+#### 25.这个项目有什么收获，学到了哪些有用的经验
+
+答：好的，这个项目做完有很多实践的经验和教训，比如：
+
+- 大模型的泛化处理能力是比较强的, 可以适应各种NLP任务, 文本分类/意图识别/实体提取/SQL生成等
+- 行业大模型应用场景，比如做的这个金融类场景，要比ToC端的场景更加复杂。很难通过一个模型来解决，需要引入多个模型与工具。
+- 6B的幻觉问题比较重，下游微调可以有效缓解。
+- 大模型对微调数据质量要求非常高，重要性在数据量之上。
+- 少量数据微调能得到非常不错的效果，（几百～几千条，人工就可梳理）
+- QA系统搭建经验：精准问答走数据库nl2sql引擎，非精准问答走检索+LLM生成。
+- 奥卡姆剃刀原则：能用规则解决的，尽量不用微调模型，能用小模型微调解决的，尽量不要用大模型。
+
+#### 26.这个项目后续还有其他优化方向吗？
+
+答：这块我在做完项目后，也有一些复盘和思考。这个项目整体上完成得还是不错的，但也存在一些不足。可以从以下几个方面继续做迭代优化：
+
+首先是准确性方面，提高召回准确率，在匹配和���义方面可以做微调，包括数据分片，数据规整和清洗方面可以继续下功夫。还可以增强模型指令遵循的能力，包括简单指令，复杂链是指令。还可以提高模型自身的能力，包括构建知识库和知识图谱，减少生成幻觉，保证事实一致性。
+
+第二是在速度方面，可以采用会更精准的召回，减少需要处理的token数，在工程方面，可以加cache，对高频问题做LRU缓存，提高query命中率和相应速度。
+
+第三是通用性方面，是检索再回答，还是可以研究下搜索引擎+RAG相结合的方式。回复生成模型是不是也可以进一步微调，获得更好的指令遵循和格式化输出的效果。
+
+#### 27.RAG和NL2SQL有做竞品调研吗，其他公司在真实业务场景中是怎么去做的？
+
+答：首先，为什么要选择用NL2SQl，原因是因为里面有表格的计算题，而计算题跟文本理解不一样，大模型并不擅长。如果直接把表格的字段扔给大模型，效果其实不太好，主要是文本和噪声混在一起，对大模型来说噪声比较大。因此在本项目中，采用了SQL命令的方式，把表格相关字段解析出来写入数据库，然后用SQL查询的方式来做，把查询结果以及prompt再输入给大模型进行答案生成，这样可以减少幻觉和计算错误。在本项目中，经过微调的NL2SQL模型准确率做出来是很高的，我这边构造case评测过，准确率高于98%。分析原因主要有两方面：一是里面的自然语言是用prompt构造的，具有特定的格式，不是口语化差异很大的query。第二个原因是在本项目中采用的一张大宽表，而不是做成多张数据表，不涉及多表join或者查询，所以SQL命令是不复杂的的。这两个原因使得模型经过微调以后，准确率达到了在项目中可用的水平。对于更广义的业务场景，如涉及几十张表甚至几百张表的情况，查询指令比较复杂，SQL语句也比较复杂，包含orderBy、union、except、groupBy、intersect、limit、having 关键字，以及嵌套查询等。这种场景对模型的跨表、生成复杂SQL的能力提出了比较高要求，目前的业界最好的模型也只有60%左右的准确度。另外，对于更加口语化的场景，也会增加解析和识别的难度。因此，该方法推广到更复杂的业务场景，还需要做优化。
+
+#### 28.nl2sql模型微调的时候遇到过什么bad case，有没有做分析，怎么解决？
+
+答：有遇到badcase，最开始做的时候，一个很明显的问题就是column列名很相似的字段，在生成SQL的时候容易抽错，大模型不能很好的区分，特别是对金融领域的专有名词，即使微调过的模型也一样。分析了一下原因，是因为大模型在这些专业领域的知识方面比较欠缺，所以不能很好的区分细微的差别。后来想了一个办法去做优化，我通过计算列名相似度的方式（采用编辑距离）来把很相似的column找出来，然后对这些column写一个字段含义的详细解释，建立了一个映射表。在模型微调的时候，把字段的解释也和字段本身一起都作为上下文，然后微调模型，最后对这类问题解决的效果比较明显。
+
+#### 29.这个项目性能怎么样，QPS做到了多少？
+
+答：这个项目利用vLLM框架对Qwen大模型进行推理加速，实现4卡v100分布式部署，加入 prefix cache 优化，并对模型做了INT8量化，引入 了qwen2-7B 通过投机采样的方式加速32B模型推理，推理效率得到了很大的提升。上线前，我们做过压力测试，最大测试到了128个并发，vllm内部采用了continuous batching技术，所以相当于batch size是128，GPU利用率可以完全打满。因为整个系统是流式的输出，所以性能指标采用的是两种业界常用的指标首字延迟，和平均吞吐率。在最大并发下，平均0.8s出首token，平均吞吐率4.8k token/s，整体平均2.7s；
+
+#### 30.nl2sql 训练完成后，会加入新的表格吗，在新表格的基准测试表现如何？这块怎么去做的
+
+答：会加入新的表格来测试，新表格效果下降还是比较明显的，主要原因是对于NL2SQL这个任务，大模型对数据的分布依赖是比较重的。之前我们也尝试过用外部通用的text2sql语料来训练我们的模型，后来发现这个模型在金融领域的表格数据问答效果很一般。对于新表格的数据，还是需要构造少量的数据，通过设计和之前一样的promot在微调过的模型基础上继续增量微调，这样可以大模型适应新的数据分布。

项目题库-项目实战2.md

@@ -0,0 +1,223 @@
+# 项目题库
+
+### 面试官可能问的问题
+
+#### 1.请介绍一下这个项目
+
+答：这个项目是基于A股在2019～2021年上市公司1万多份年报PDF文件，结合Qwen2大模型构建了一个交互问答系统，解读上市公司年报并回答用户金融相关的问题。
+
+在项目中，微调了3个Qwen-7B的领域子模型，分别用来做意图识别，NL2SQL，以及关键词抽取，最后再利用Qwen-32B大模型做总结生成，项目采用大小模型协同的方式，完成了基本信息查询，统计分析查询，以及开放性问题三种细粒度的金融场景问答交互，最终的问答准确率达到87%。
+
+同时利用Docker容器化部署，服务采用流式输出，并利用prefix cache和vllm实现推理加速，以及punica的多LoRA融合节省2倍的GPU资源，实现低成本部署。
+
+#### 2.这个项目的难点或挑战是什么？
+
+答：这个项目因为是处理真实的上市公司年报数据，并以大模型为中心来实现一个问答系统，在做这个项目的时候，遇到不少的挑战，主要有以下5个方面：
+
+- 测试集问题种类多样，包含计算类、查询类、分析类等，很难通过一个模型来解决，需要引入多个模型与工具。
+- 数据格式比较复杂，直接从pdf中抽取出规范化数据也是比较困难的，例如表格跨页的问题，还有PDF解析失败的问题
+- 没有微调数据集，人工标注数据成本高，如何利用GPT4等API，自动，高效的构造出高质量的SFT数据集
+- 小模型6B/7B的幻觉问题比较重，下游微调可以缓解幻觉乱说的情况。
+- 大模型生成不可控，难以保证输出结果的规范性，这部分需要精调prompt来控制
+
+#### 3.具体介绍一下基本信息查询，统计分析查询，以及开放性问题三类任务的不同
+
+答：公司基本信息查询是直接能从年报中找到并定位答案的，包括公司的法人，雇员情况，研发成本，财务费用，营业支出等。统计分析查询是指需要经过一些关联指标查询和简单数学运算，例如某个公司的研发费用增长率是多少。第三类问题是开放性问题，一般是需要总结推理的问题，比较适合用大模型直接总结输出，例如某个公司的技术领域是否涉及国家创新技术领域，是否属于AI 人工智能领域，或者总结一下某公司的核心技术优势，亮点有哪些。
+
+#### 4.模型结果是如何评测的，怎么计算回答的准确度
+
+答：评测针对不同问题类型采用了两种指标计算方法。对于基本信息查询和统计分析查询，输出有关键词信息，还有数值答案，以及生成的回复。得分采用数值答案+关键词信息 + 答案相似度得分三部分加权。但如果数值答案是错的，那得分就是0分。如果数值答案是正确的，关键词是错误的，那得分就是0.25+0.5\*答案相似度得分，如果数值答案和关键词都是对的，那得分就是0.5+0.5\*答案相似度得分。对于第三类开放性问题，直接采用答案匹配相似度得分。其中相似度采用了text2vec-large-chinese作为向量匹配模型。
+
+#### 5.做这个项目的过程中，你遇到的难点或挑战是什么？
+
+答：这个项目数据量很大，大约有70G，而且年报数据格式不统一，对于解析，处理，查询，生成每个阶段都有不小的挑战，具体来说，有以下几点：
+
+1、测试集问题种类多样，包含计算类、查询类、分析类等，单个框架难以处理
+
+2、数据格式复杂，难以直接从pdf中抽取出规范化数据
+
+3、没有微调数据集，人工标注数据成本高，如何高效的设计高质量的数据集
+
+4、大模型生成不可控，难以保证输出结果的规范性
+
+#### 6.PDF非结构化数据解析有没有遇到什么问题？是怎么解决的？
+
+答：RAG应用中处理复杂文档内容是一个挑战，特别是处理PDF文档中的图片和表格。解析和检索PDF文件中的表格是一个技术难点，需要使用OCR技术来识别表格内容。
+
+我在做这个项目的时候，调研了几种主流的技术方案，首先是用Nougat作为解析PDF文档的工具，可以将表格内容转换为结构化数据，然后使用LlamaIndex可以对解析后的表格数据进行索引和检索。UnstructuredIO方案是将PDF文件转换为HTML文件，然后使用LlamaIndex进行处理。比较高级一点的是采用多模态的思路，使用OpenAI的GPT4o模型来处理表格内容。但目前还没有一种方案可以完美满足所有需求。
+
+最后发现，camelot-py基于图像识别的表格提取精度还不错，考虑精度和速度两方面的因素折中，最终采用了这种方案。首先根据报表名称设置关键词找到对应的页，提取表格字段和value后，为了查询方便，将关系型数据（包括表格和基本信息），按照每家公司一行的方式，做成一张大宽表。这样可以避免跨表查���的复杂度。
+
+#### 7.为什么要在前面做一层问题分类，有什么好处？
+
+答：如果不做问题分类，直接做检索召回生成，各自问题混合在一起，精度会受到很大的影响。因为不同问题类型所需要的输入信息，prompt都是不一样的。利用一个前置模型做一层问题分类的意图分发，可以有效的把问题分流落域，然后再分门别类的处理，针对每一种query都可以定制不同的处理方式，以及关联对应的输入字段，还有调优prompt。所以，做成2层的漏斗系统可以同时提高问题的效率和精度。
+
+#### 8.问题分类做了哪几个类别？
+
+答：问题分类做了六大类别。
+
+第一个是公司基本信息，这个可以通过检索【公司基本信息表】来获取答案；
+
+第二个是公司员工信息，这个可以通过检索【公司员工信息表】来获取答案；
+
+第三个是财务报表相关内容，这个可以通过【财务三大报标】来获取结果；
+
+第四个是计算题，需要根据问题类型检索计算因子来完成计算；
+
+第五个是统计题，需要根据问题类型分析条件检索来获取结果；
+
+第六个是开放性问题，根据问题关键词来检索全文相关匹配的召回材料来总结回答问题；
+
+#### 9.问题分类的指令微调数据是怎么构造的？
+
+答：指令微调的数据主要是通过少样本in-context 学习生成数据集，并进行人工校验的方式来生成的。抽取几十个个样例报标喂给gpt4，构造问题分类描述的prompt，然后让gpt4根据文档来提问，并自己回答问题的类型；这样可以得到一批种子训练语料，然后在人工对这批语料进行check，去除标注错误的数据和脏数据。为了让指令微调的数据具有多样性和高质量，我们还利用GPT4对这批数据进行说法泛化，具体包括为句式的改变，转换为非正式或口语化说法，以及省略说法，和句子容错等处理，最后得到6k条高质量的问题分类指令微调数据集。
+
+#### 10.那在微调过程中，有遇到什么问题吗，是如何解决的？
+
+答：最早期的一次微调，一开始的效果比较糟糕，最后发现是训练字段小于传入的模版+问题的字符串，导致训练过程中的传入字段丢失截断。loss一直在0.20下不去，距离第一轮训练目标0.10以下还有很大差距，实用情况比较糟糕。
+
+通过统计问题和答案的长度，最后调整了max\_source\_length参数符合max（问题+答案)的条件，确认了max\_source\_length为512，max\_target\_length为128，使用qwen2-7b进行LoRA微调，step为250，训练结果的loss到了0.09，基本可用级别。
+
+为了获取更好的效果，尝试对prompt不断进行调整，从一开始的只有选项的题目，到有一定信息的选项描述（高频的关键字等），同时对训练step加大到400，对微调训练有很大的帮助，loss的下降比较明显, 最优平均值达到0.01以下，拥有比较优秀的分类能力。在微调过程中，还发现尝试调低Learning rate可以获得更快的训练收敛效益，这也是在小数据微调时的一个技巧。
+
+#### 11.为什么要做NL2SQL生成，你是如何做的？
+
+答：因为很多计算和统计类型的问题，需要操作数据库表里的字段进行简单运算，所以用SQL就是很方便和自然的。我这边测试过，Qwen本身有一定的NL2SQL能力，但是难以在项目中稳定输出有效正确的SQL格式的语句。Qwen官网的商用版本，Qwen-Max具有有良好的NL2SQL的性能，所以我判断应该可以透过微调训练来增强7B的SQL能力。早期尝试用公共的NL2SQL训练集（2019年NL2SQL大赛的公开标注数据集），大概40000多道题目（包含电影、书籍、评价、金融等等五花八门的题目类型）。结果发现，不仅没有能够很好对题目进行SQL生成（loss在0.36-0.50降下不去），而且丧失了基本的对话能力。
+
+经过分析，我觉得要想稳定生产准确有效SQL语言，是需要根据实际的任务情况和方向来设定训练目标，最后决定自己来标注训练集，为了加快效率，使用gpt4/Bard来协助生成该写出不同提问模板，再透过字段的随机条件填充。构建针对其模版格式的问题训练集，根据四个模版SQL扩充了24种不同问法，并且强化了除了查询以外的SQL语句如排序，输出范围，统计计数，条件求和，单字段检索，多字段检索，多字段检索多字段，字段的过滤等。最后构造了1000多条高质量涵盖所有查询类型的微调语料，对Qwen2-7B进行了微调，微调后的效果很好，准确率在95%以上，满足查询要求。
+
+#### 12.你刚才提到用了模版来构造NL2SQL的语料，具体是怎么做的？
+
+答：NL2SQL任务涉及将自然语言问题转化为SQL查询，以从数据库中检索信息。构建NL2SQL模板的步骤如下：
+
+- 定义查询类型：查询，排序，输出范围，计数，求和，单字段检索，多字段检索，多字段检索多字段，字段的过滤等SQL执行需求。
+- 示例对话：催眠大语言模型进行Agent扮演Mysql数据库开发人员，通过自然语言问题和相应的SQL查询的示例对话提供对指令的理解。
+- 数据库字段：传入数据库表名，设计的字段，该数据库已经较好的清洗合并数据，同类型字段检索能有较好的性能。
+- 生成SQL查询：根据SQL语法树，生成正确的的SQL执行语句。
+- 参数替换：将自然语言问题中的参数（如列名、条件等）替换为存在库中的数据库元素。
+
+模版构造好以后，就采用随机变量填充+GP4说法泛化来进一步扩充到更大的语料。
+
+#### 13.线上NL2SQL要做的好不容易，你在这个过程中有哪些好的实践经验
+
+答：NL2SQL微调训练重点任务还是构造训练数据集。但是，要针对实际数据查询场景构造数据集，而非使用Spider等通用的数据集。GPT4生成泛化的数据还是需要进一步人工来做校验，对于微调来说，数据的质量要求，远大于数据的数量要求。我还总结了以下三点有用的做法：
+
+1. 使用一张大宽表 **，** 而不是多表，单表查询的SQL语句比较简单，生成SQL语句的准确率很高。
+2. 在Prompt中可以明确指定字段，提升准确率。至于如何准确定位库表字段，可以采用关键词匹配的方式。
+3. 当遇到一些需要计算的场景，比如：营业利润率 = 营业利润 / 营业收入。此时最好拆分问题，生成多个简单的SQL查询语句，分别获取营业利润和营业收入后，再调用公式计算。
+
+#### 14.讲一下关键词提取是怎么做的？
+
+答：很多场景下，我们都需要通过Prompt，给到大模型来提取关键词。比如，通过提取用户问题中的关键词，我们可以理解用户意图，再按照规则来匹配回答问题的方法。但是对于专业领域，如果像Qwen-7B这样的模型，不能很好地理解和准确提取专业术语，那么就可以微调一个关键词模型，用于在用户提问中提取相关专业的关键词。关键词提取任务涉及从文本中提取关键词或短语，有助于后面检索相关信息，越精准的提取越能够让返回的信息更加准确。以下是构建关键词提取模板的步骤：
+
+- 构建关键词提取的prompt，需要不断尝试prompt对问题的处理和稳定性，非微调的情况下few-shot也能有合格的表现。提示可以写成：“请帮我从以下句子中提取关键词。这些关键词是句子中最重要、最能概括句子主题的词汇。通过这些关键词，你可以更好地理解句子的内容。你只需要回答文本中的关键词，不要回答其他内容.”
+- 示例文本：收集不同具有代表性的问题所包含所需关键词类型的示例文本
+- 构建模板：根据问题集的问题遍历提取用户提问，构建训练集的prompt模板
+
+有了模版以后再利用GPT4泛化和人工修正，最后微调出一个7B模型。初次之外，针对金融领域的某些专业名词，模型不容易学习到，我还构建维护了一个专业名词缩略语库和同义词库，用AC自动机匹配的方式提取这部分的关键词信息，提升了关键词的召回能力。
+
+#### 15.你说说基本信息类问题的处理流程是什么？
+
+答：根据用户提问，首先提取query中的公司名称和年份信息，根据公司名称和年份以及意图匹配报表的表格字段。若干匹配到文本字段与多个年份，则加入文本比较信息，把多个年份的数据都定位抽取出来。然后利用组合信息自动生成prompt，在生成prompt的过程中，有几点注意的，首先是文本类字段讲字段值加双引号，非文本类字段将字段名称加双引号。对于人数类的字段结果为XX有XX人，其他字段结果为XX是XX，金额类的字段结果为XX是XX元。构造好prompt以后，再喂给32B大模型，生成最终的答案。
+
+#### **16.你说一下统计计算类问题的处理流程是什么**？
+
+答：对于统计计算类的问题，首先根据用户问题匹配问题中是否出现比值类的关键字，把这些关键字匹配出来，提前维护了一个比值类计算公式的映射表，然后根据找到关键字取出对应比值的计算公式。然后根据公式生成问题链，也就是公式的所需要的变量，然后通过问题链解析所需要的字段值，然后调用NL2SQL生成对应的SQL语句，然后利用SQL从表中提取出来，有了字段值，最后就可以通过python计算得到结果。然后把计算结果，query，以及问题链一起输入给32B的生成大模型，得到最终的回答。
+
+#### 17.对于总结类的问题，处理流程是什么？
+
+答：首先根据query识别，识别提问中的公司名称，年份和意图关键词，然后根据关键词和问题分别召回top3相关的文本片段，这里关键词召回采用了BM25的匹配，问题召回采用了BGE embedding做语义召回，最后根据召回的文本，自动组合生成prompt，最后再把prompt输入给qwen-32b大模型，输出最终的答案。总结类问题相对第一种和第二种类型简单一点，采用的是RAG的常见流程和做法。
+
+#### 18.你这个项目里面不同的问题构造来不同的prompt，那在prompt构造方面，有没有什么心得可以分享下？
+
+答：是的，prompt构造在这个项目中是非常重要的，针对不同问题类型，都定制和调优了最适合的prompt。心得方面，主要有这几个方面。
+
+首先就是角色定义，这个写法一定要精确，与需要完成任务所需要的背景知识要匹配。
+
+第二是任务的目标描述要简洁明了，避免使用模糊或带有歧义的词汇。
+
+第三是任务的具体要求，步骤多用美剧，少用否定句，对于某些流程较长的需要考虑拆分为多个任务，也就是思维链的思想。
+
+最后一个是输出要有明确的输出格式要求，对于重要任务的要求，可以在prompt里面做二次强调。对于强制json类输出的任务，可以把左大括号先打出来放到提示的最后，经过实际验证表面，这样写会比直接让大模型输出json更能够锁得住格式。
+
+#### 19.模型微调这块，有没有想过做进一步优化？
+
+答：模型微调这块确实想过做进一步的优化。因为现在是3个7B的子模型微调，指令微调的数据和prompt也是3种，在训练方面需要训练三次，导出三个不同的lora adapter，但基模是一样的。这对资源是一种浪费。考虑过一种优化方案就是对指令微调的数据集做一个合并，把意图分类的，NL2SQL和关键词抽取合到一起，做一个多任务的指令微调，最后就导出一个lora权重，这样可以很大的减少模型处理的复杂度，也节省一定的计算资源。针对三个lora权重的问题，我在服务部署的时候，采用了另一种解决思路，可以同时对三个子模型进行批量的推理。具体做法是利用了单底座+多lora合并的方案，即把做个lora挂载到一个底座上，推理的时候直接进行批量推理，底层把这三种模型的请求自动做合并，这样一方面保证了推理的速度，另一方面又节省了部署GPU资源。
+
+#### 20.那你展开说一下单底座+多lora是怎么做的？
+
+答：好的，这块其实最近有相关论文做这方面的研究。因为在采用同一个底座微调多个模型的时候，只有lora部分的权重是不一样的，底座是完全相同的。如果部署的时候还是分开部署，那每次请求，底座都要重复计算N次，而且需要分开部署多个服务实例，对资源是一种很大的浪费。因此有论文就考虑做这方面的优化，比如国外predibase公司的LoraX，以及伯克利提出的SLoRA，还有最近华盛顿大学提出的Punica。这个任务的核心问题就是如何把多个lora的多次矩阵乘法合并成一个矩阵乘法运算。一般采用的算子有两种，一个是SGMV，另一个是BGMV，在最新的vLLM框架中集成了了punica的高效BGMV算子的实现，同时支持了多lora。最后，项目服务部署上线也采用了vLLM多lora部署的方式，实测并发lora调用下，跟单个lora调用，性能几乎没有下降。
+
+#### 21.我看你还用了prefix cache做优化，讲一下它的原理吧？
+
+答：Prompt 计算（Prefill 阶段）和生成阶段的计算特性很不相同。为避免重复计算，所有框架的 prefill 阶段主要作用就是给迭代的生成阶段准备 KV Cache。但这些 KV Cache 仅仅是为单次生成式请求服务的，那很自然的一种想法就是，KV Cache 能不能跨请求复用。在我们的项目场景下，多次请求的 Prompt 可能会共享同一个前缀（Prefix），比如系统的prompt，query，上下文内容等。这些情况下，很多请求的前缀的 KV Cache 计算的结果是相同的，像一般互联网服务的请求缓存一样，可以被缓存起来，给下一个请求复用。 vLLM 的实现是给 generate 接口增加一个 prefix\_pos 参数，通过 prefix\_pos 输入参数为每个请求指定 prefix 长度，为 prefix 建一个带淘汰的哈希缓存。后来觉得这样做使用上不够便利，升级成了自动前缀缓存，即将 prompt 的 kv cache 分成 block，然后为 block 建设 LRU 缓存机制，这样就不必在接口上使用 prefix\_pos 指定哪部分是 prefix 了。自动前缀缓存功能默认是不开启的，开启的配置项为 --enable-prefix-caching ，本项目是开启了这个优化，首 token 耗时下降 70%。
+
+#### 22.模型部署还用来GPTQ来量化，说一下它的原理？
+
+答：GPTQ 并不是凭空出现的，它的原理来自于另一个量化方法OBQ，而OBQ 实际上是对 OBS(一种比较经典的剪枝方法）的魔改， 而OBS则来自于OBD，由 Yann LeCun 在1990年提出的剪枝方法。GPTQ 对 OBQ 做了一些算法和性能上的优化，在降低量化算法复杂度的同时保留了模型的精度，因而可以实现大模型的高效量化。可以说 GPTQ 是它的加速版，使用 GPTQ 量化一个 Bloom 模型 (176B) 则只需不到 4 个小时；并且 GPTQ 的量化有严谨的数学理论推导，所有的算法步骤都有理论支撑。
+
+GPTQ采用 int4/fp16 (W4A16) 的混合量化方案，其中模型权重被量化为 int4 数值类型，而激活值则保留在 float16，是一种仅权重量化方法。在推理阶段，模型权重被动态地反量化回 float16 并在该数值类型下进行实际的运算；同 OBQ 一样，GPTQ还是从单层量化的角度考虑，希望找到一个量化过的权重，使的新的权重和老的权重之间输出的结果差别最小。
+
+GPTQ 将权重分组（如：128列为一组）为多个子矩阵（block）。对某个 block 内的所有参数逐个量化，每个参数量化后，需要适当调整这个 block 内其他未量化的参数，以弥补量化造成的精度损失。因此，GPTQ 量化需要准备校准数据集。
+
+GPTQ 的工作原理如下：
+
+- 首先，GPTQ 使用 group 量化将权重分组为多个子矩阵。
+  然后，GPTQ 使用 OBQ 方法来量化每个子矩阵。
+  最后，GPTQ 使用动态反量化来恢复权重的原始值。
+
+GPTQ 的改进主要体现在以下几个方面：
+
+- 分组量化：GPTQ 使用分组量化来将权重分组为多个子矩阵，这可以降低量化精度损失。
+  OBQ 方法：GPTQ 使用 OBQ 方法来量化权重，该方法可以实现高精度的量化。
+  动态反量化：GPTQ 使用动态反量化来恢复权重的原始值，这可以提高量化的性能。
+
+总结一下，GPTQ 是把量化问题视作优化问题，逐层寻找最优的量化权重。
+
+#### 23.有对比过其他的量化算法吗？
+
+答：有的，我这边对比过AWQ量化，AWQ是一种面向LLM低比特权重量化的硬件友好方法。它基于激活感知的权重量化策略，通过观察激活而不是权重来搜索保护显著权重的最佳通道缩放。
+
+AWQ的优点在于它能够保留更多的模型信息，同时实现高效的权重量化。AWQ量化后的推理速度确实要快一点，不过我这边利用autoAWQ量化模型，尝试了几种不同的校准数据集，包括公开的校准数据集以及训练数据，发现精度都没有GPTQ高，有一定量化损失，而且AWQ的量化成本比较高，因此最后还是采用比较成熟的GPTQ量化，qwen官网发布的Int8量化版本，因为我用的是A100卡，有Int8的TensorCore，所以Int8的推理速度是最快的，这也是没有采用Int4的原因。
+
+#### 24.除此之外，还用了哪些方法来加速推理
+
+答：除了量化和vLLM的paged attention加速以外，还采用了speculative decoding来对32B的生成大模型来做生成加速。Speculative Sampling引入了一个小模型，它的潜在假设是许多常见的文本和句子是很容易被预测出来的，可以用更简单的模型来近似。在自回归解码中加入投机采样，其原理简单来说就是：使用两个模型，一个是原始目标模型，另一个是比目标模型小得多的近似模型。近似模型用于进行自回归的串行采样，大模型对采样的结果进行评估，决定是否接受近似模型的采样结果，这样大模型只需要处理小模型无法处理的复杂部分，这个方法不需要修改大模型的结构，也不需要重新训练模型，降低推理成本的同时，实现推理提速。最后，我评测对比了0.5B, 1.8B, 7B，以及14B的效果，综合加速比来看7B的加速比是最高的，最终小模型采用了qwen2-7B来作为speculative decoding的小模型，达到了1.7倍的加速。
+
+#### 25.这个项目有什么收获，学到了哪些有用的经验
+
+答：好的，这个项目做完有很多实践的经验和教训，比如：
+
+- 大模型的泛化处理能力是比较强的, 可以适应各种NLP任务, 文本分类/意图识别/实体提取/SQL生成等
+- 行业大模型应用场景，比如做的这个金融类场景，要比ToC端的场景更加复杂。很难通过一个模型来解决，需要引入多个模型与工具。
+- 6B的幻觉问题比较重，下游微调可以有效缓解。
+- 大模型对微调数据质量要求非常高，重要性在数据量之上。
+- 少量数据微调能得到非常不错的效果，（几百～几千条，人工就可梳理）
+- QA系统搭建经验：精准问答走数据库nl2sql引擎，非精准问答走检索+LLM生成。
+- 奥卡姆剃刀原则：能用规则解决的，尽量不用微调模型，能用小模型微调解决的，尽量不要用大模型。
+
+#### 26.这个项目后续还有其他优化方向吗？
+
+答：这块我在做完项目后，也有一些复盘和思考。这个项目整体上完成得还是不错的，但也存在一些不足。可以从以下几个方面继续做迭代优化：
+
+首先是准确性方面，提高召回准确率，在匹配和���义方面可以做微调，包括数据分片，数据规整和清洗方面可以继续下功夫。还可以增强模型指令遵循的能力，包括简单指令，复杂链是指令。还可以提高模型自身的能力，包括构建知识库和知识图谱，减少生成幻觉，保证事实一致性。
+
+第二是在速度方面，可以采用会更精准的召回，减少需要处理的token数，在工程方面，可以加cache，对高频问题做LRU缓存，提高query命中率和相应速度。
+
+第三是通用性方面，是检索再回答，还是可以研究下搜索引擎+RAG相结合的方式。回复生成模型是不是也可以进一步微调，获得更好的指令遵循和格式化输出的效果。
+
+#### 27.RAG和NL2SQL有做竞品调研吗，其他公司在真实业务场景中是怎么去做的？
+
+答：首先，为什么要选择用NL2SQl，原因是因为里面有表格的计算题，而计算题跟文本理解不一样，大模型并不擅长。如果直接把表格的字段扔给大模型，效果其实不太好，主要是文本和噪声混在一起，对大模型来说噪声比较大。因此在本项目中，采用了SQL命令的方式，把表格相关字段解析出来写入数据库，然后用SQL查询的方式来做，把查询结果以及prompt再输入给大模型进行答案生成，这样可以减少幻觉和计算错误。在本项目中，经过微调的NL2SQL模型准确率做出来是很高的，我这边构造case评测过，准确率高于98%。分析原因主要有两方面：一是里面的自然语言是用prompt构造的，具有特定的格式，不是口语化差异很大的query。第二个原因是在本项目中采用的一张大宽表，而不是做成多张数据表，不涉及多表join或者查询，所以SQL命令是不复杂的的。这两个原因使得模型经过微调以后，准确率达到了在项目中可用的水平。对于更广义的业务场景，如涉及几十张表甚至几百张表的情况，查询指令比较复杂，SQL语句也比较复杂，包含orderBy、union、except、groupBy、intersect、limit、having 关键字，以及嵌套查询等。这种场景对模型的跨表、生成复杂SQL的能力提出了比较高要求，目前的业界最好的模型也只有60%左右的准确度。另外，对于更加口语化的场景，也会增加解析和识别的难度。因此，该方法推广到更复杂的业务场景，还需要做优化。
+
+#### 28.nl2sql模型微调的时候遇到过什么bad case，有没有做分析，怎么解决？
+
+答：有遇到badcase，最开始做的时候，一个很明显的问题就是column列名很相似的字段，在生成SQL的时候容易抽错，大模型不能很好的区分，特别是对金融领域的专有名词，即使微调过的模型也一样。分析了一下原因，是因为大模型在这些专业领域的知识方面比较欠缺，所以不能很好的区分细微的差别。后来想了一个办法去做优化，我通过计算列名相似度的方式（采用编辑距离）来把很相似的column找出来，然后对这些column写一个字段含义的详细解释，建立了一个映射表。在模型微调的时候，把字段的解释也和字段本身一起都作为上下文，然后微调模型，最后对这类问题解决的效果比较明显。
+
+#### 29.这个项目性能怎么样，QPS做到了多少？
+
+答：这个项目利用vLLM框架对Qwen大模型进行推理加速，实现4卡v100分布式部署，加入 prefix cache 优化，并对模型做了INT8量化，引入 了qwen2-7B 通过投机采样的方式加速32B模型推理，推理效率得到了很大的提升。上线前，我们做过压力测试，最大测试到了128个并发，vllm内部采用了continuous batching技术，所以相当于batch size是128，GPU利用率可以完全打满。因为整个系统是流式的输出，所以性能指标采用的是两种业界常用的指标首字延迟，和平均吞吐率。在最大并发下，平均0.8s出首token，平均吞吐率4.8k token/s，整体平均2.7s；
+
+#### 30.nl2sql 训练完成后，会加入新的表格吗，在新表格的基准测试表现如何？这块怎么去做的
+
+答：会加入新的表格来测试，新表格效果下降还是比较明显的，主要原因是对于NL2SQL这个任务，大模型对数据的分布依赖是比较重的。之前我们也尝试过用外部通用的text2sql语料来训练我们的模型，后来发现这个模型在金融领域的表格数据问答效果很一般。对于新表格的数据，还是需要构造少量的数据，通过设计和之前一样的promot在微调过的模型基础上继续增量微调，这样可以大模型适应新的数据分布。