微调垂直领域大模型

本项目旨在利用先进的预训练语言模型技术,结合特定领域的专业知识,打造一个专注于无人机飞行安全规范的专家问答机器人。

项目以 DeepSeek-R1-Distill-Qwen-1.5B 作为基础模型,利用收集到的无人机安全飞行监控相关数据进行参数高效微调(PEFT)。最终目标是生成一个能够准确、结构化地回答无人机飞行安全和风险相关问题的专业问答模型,并能遵循特定的回答格式(包含思考过程)。

 

 

模型托管地址

微调后的模型已托管至 Hugging Face Hub,可通过以下地址访问:https://huggingface.co/GabrielCheng/Deepseek-r1-finetuned-drone-safty

国内可访问魔搭社区下载:https://www.modelscope.cn/models/gabrielai/Deepseek-r1-finetuned-drone-safty/

 

 

模型调用代码示意

可通过以下 Python 代码调用(Hugging Face Hub上托管)微调后的模型:

 

 

模型使用演示

这里展示了微调前后的效果对比:

 

 

技术实现

数据处理
  1. 数据来源:原始数据来源于 Hugging Face 平台的无人机云数据集 (pohsjxx/default-domain-cot-dataset)。
  2. 样本筛选与清洗:从中提取约 3500 个样本作为训练基础,并进行清洗。然后拆分为训练集(85%)和验证集(15%)。
  3. 关键处理 – 格式对齐:
    • 调整了原数据集中 answer 字段的文字表述,使其更通用。
    • 为了适配推理模型采用的“思考-回答”格式(Chain-of-Thought, CoT),我们将原数据集中的 reasoning(推理过程)字段和 answer(最终答案)字段进行了对调。即,将原始的 answer 内容作为模型的思考过程(放入 </think> 标签前),将原始的 reasoning 内容作为模型的最终正式回答。这一转换旨在使训练数据的格式更贴近 DeepSeek-R1 等模型常见的 CoT 数据模式。

 

微调训练
  1. 框架:采用 Hugging Face 的 transformers 和 peft 库,实现了 LoRA (Low-Rank Adaptation) 参数高效微调。
  2. 硬件平台:利用 Google Colab 提供的 T4 GPU (约 16GB 显存) 进行训练。
  3. 关键超参数设置与考量:
    • 显存优化:针对 T4 显存限制,设置了较小的批次大小 (per_device_train_batch_size=2),并启用了梯度检查点 (gradient_checkpointing=True) 以节省显存(牺牲少量训练速度)。同时使用混合精度训练 (fp16=True)。
    • 模拟大批次:通过梯度累积 (gradient_accumulation_steps=16),实现有效批次大小为 32 (2 * 16),有助于稳定训练。
    • 防止过拟合:考虑到样本量(3500)相对较小,设置了 LoRA Dropout (lora_dropout=0.1) 和权重衰减 (weight_decay=0.01)。
    • LoRA 配置:r=8, lora_alpha=32。
    • 训练周期与学习率:num_train_epochs=5,learning_rate=1e-4,并使用 cosine 学习率调度器。

 

微调效果
  1. 损失函数表现:训练集和验证集的损失均从初始的约 2.8 下降至 0.8 左右,且验证集损失未出现明显反弹,表明模型有效收敛且基本没有出现过拟合现象。
  2. 语义相似度提升:使用验证集数据,通过计算模型生成回答与标准答案之间的语义相似度(Sentence Transformers),发现微调后模型的平均相似度得分从 0.77 提升至 0.95 左右。这表明微调明显提高了模型回答内容与目标答案在语义层面上的一致性。

 

 

项目局限性

  • 缺乏真实输入:当前的问答模式主要基于文本问题。真实的无人机安全监控场景往往需要结合飞行轨迹、环境感知等多模态数据作为输入。本模型未包含这部分数据和能力,主要目的是展示问答格式和领域知识上的一致性,实用性有限。
  • 数据构造影响:训练数据中“思考”(<think>部分)和“回答”部分是通过对调原始数据集的 answer 和 reasoning 字段构造的。这两部分之间可能缺乏原生数据那样清晰、自然的逻辑关联,这可能对模型深度理解和生成真正连贯思考过程的能力造成一定阻碍。
  • 基础模型的能力限制:考虑到 Google Colab T4 GPU 的算力与显存限制,本项目选取了 1.5B 参数量的 DeepSeek-R1-Qwen 蒸馏模型作为基础模型。虽然该规模的模型足以验证微调流程和概念,但在处理复杂或边缘问题时还是稳定性不足,时常出现回答格式混乱的情况。对于追求高稳定性和准确性的真实应用场景,建议选用参数量更大(如 7B 或以上)的基础模型进行微调。

 

舆情洞察(语义分析+情感评价)

这是一个精华液产品的消费者洞察示例。在分析中引入大语言模型的语义分析和情感分析能力,替代复杂的传统机器学习模型。使得分析更为深入和灵活。

基础数据来源于某主流内容平台与 “精华液” 产品相关的消费者笔记。引入大语言模型对笔记内容进行语义分析和情感评价,并整理获得规整的结构化数据。最终以数据报表的形式展示信息。

 

交互式报表入口

 

技术实现

  • 在小红书平台上,以“精华液”及相关品牌词为关键词进行搜索筛选消费者笔记。采用 Python 的 DrissionPage 包,抓取约5000条。
  • API 接入大语言模型(Google Gemini Flash 1.5)进行语义分析和情感评价:
    • 语义分析:提取笔记中有关特定维度的点评内容。如:提取产品使用场景相关语句。
    • 情感评价:判断笔记作者对产品和品牌的特定维度的态度。如:对产品功效是否满意。
  • 采用 Python 的 jieba 包对语义分析提取的内容进行清洗,整理获得规整的结构化数据。
  • 在 Tableau Public 平台进行数据可视化,并展示发布。

 

局限性

  • 受限于内容平台的搜索和算法推送规则,可能出现笔记样本代表性不足的情况。可能需要扩大收集笔记数量来弥补这一问题。
  • 大语言模型的语义分析和情感评价准确性受制于模型自身能力,提示词质量和任务复杂程度。如果为了追求时间效率,在提示词中要求大语言模型一次完成多个任务会导致输出结果质量明显下降。

 

未来改进方向

  • 扩大收集笔记数量来提升样本代表性。
  • 可以考虑引入两个以上的大语言模型处理相同任务,再对任务输出结果进行对比校验,提升准确性。

 

 

Text-to-SQL数据查询系统

利用大语言模型的自然语言理解和代码生成能力,打造一个用自然语言查询数据库的检索系统。你可以用简单的语言描述你的查询需求,系统会自动生成对应的 SQL 代码,并以表格和图形的形式呈现查询结果。

 

 

技术实现

  • 该应用基于 Python 开发,查询和数据可视化功能依赖 VannaAI 的 Python 包,前端界面则采用 Gradio 包实现。
  • SQL 数据库和修正后的 SQL 代码存储在本地。数据库元数据以向量数据库的形式存储在 VannaAI 云端。如果使用本地部署的大语言模型,则所有数据都可以在本地进行处理,避免信息泄露的风险。
  • 应用 Demo 使用了公开的示例数据库 “Chinook”。数据库的表格和字段关系如下:

 

局限性

  • 目前,系统在处理简单的查询方面表现良好,但对于多层嵌套的 SQL 查询,还缺乏足够的处理能力。
  • 自然语言转 SQL 的准确性是这个系统的核心,而这方面受到大语言模型代码生成能力和用户与模型沟通能力的限制。

 

 

未来改进方向

  • 可以收集用户查询和生成的 SQL 代码,微调一个自然语言转 SQL 的专家模型,替代通用大模型,以提高准确性和效率。
  • 对于多层嵌套的 SQL 查询,可以考虑采用分步查询的方案,将复杂查询分解成多个简单的查询步骤,逐步完成。

 

 

操作方法

  1. 在登录页面输入用户名和密码(目前都设为 “ailab”)。
  2. 在第一个文本框中输入你的查询语句,例如 “查询开发票数量最多的三个员工”,然后点击 “第一步:生成 SQL 语句” 按钮。
  3. 系统会自动生成对应的 SQL 代码,并在第二个文本框中显示。
  4. 点击 “第二步:用 SQL 语句查询” 按钮,系统会执行生成的 SQL 代码,并将查询结果以表格形式展示。
  5. 如果查询结果适合用图形展示,你可以点击 “第三步:用图形展示查询结果” 按钮,系统会自动生成相应的图表。
  6. 如果发现系统生成的 SQL 语句有误,你可以直接在文本框中修改 SQL 语句,并点击 “保存纠正后的 SQL 语句” 按钮。 这样,系统在未来收到类似的查询请求时,会参考你修正的 SQL 代码,避免再次出错。
  7. 点击“清空查询”,开始下一次查询。

视频演示:

 

 

测试体验入口

  • http://111.228.59.109:7860/
  • 注意:为控制成本,应用接入的是免费的API服务。一些使用限制可能导致系统反应慢或运行异常。如遇到这些情况,请等待重试,或在页面底部留言告知。

 

 

RAG客服机器人

利用检索增强生成 (RAG) 技术,结合知识库检索和大语言模型的优势,搭建一个即智能又可靠的客服机器人。它能够从预先构建的知识库中检索相关信息,并用自然流畅的语言回答用户的问题。有效避免大语言模型常见的“幻觉”问题 (即生成虚假信息)。

为了更直观地展示项目效果,本项目模拟新东方客服机器人:以新东方主页为模板,嵌入一个对话窗口。可以回答与新东方主页新东方2024Q4财报相关的问题。

 

测试体验入口

  • 请点击 https://www.gabriel-ai.cn/other-page/New_Oriental.html(如果页面插件加载出错,则可以直接访问对话窗口 https://udify.app/chat/QuZBVNLgnhrCv2VC 体验)
  • 注意:为控制成本,本应用接入的是免费的API服务。一些使用限制可能导致系统反应慢或运行异常。如遇到这些情况,请等待重试,或在页面底部留言告知。

 

操作方法

  1. 点击页面右下角的对话标签,在弹出的客服初始窗口中点击“开始对话”。
  2. 在对话窗口中输入你的问题。机器人会检索知识库,并为你解答。如果答案信息来自知识库,则它会在回答中提示参考的信息来源,便于核实。

视频演示:

 

技术实现

  • 该应用基于 Dify 平台,利用其知识库功能搭建。
  • 对新东方主页 HTML 文件采用 Dify 内嵌的 Unstructured ETL 方案解析。财报 PDF 文件转换为 Markdown 格式,做了长表格切分,并简单清洗。
  • 采用父子分段模式切分文本。然后接入 BAAI/bge-m3 模型将文本片段转换为向量,存入向量数据库,以便进行语义检索。
  • 采用 “混合检索” 模式,并使用 Cohere 的 rerank-multilingual-v3 模型进行 Rerank。
  • 利用 Dify 平台搭建工作流,接入大语言模型根据检索结果回复问题。
  • 应用的前端入口以 JavaScript 形式嵌入网页 HTML 代码中。

 

局限性

  • 目前知识库的检索召回率约为 70%-80%。影响召回率的主要问题是:一些以字体大小形式呈现的段落归属关系无法被系统自动解析;长表格分段之后可能会遗漏表头信息,而无法被检索到。这凸显了数据预处理的重要性。对于包含大量文件的知识库,需要建立 人工+自动化 的文件清洗流程。
  • Dify 自带的知识库系统无法处理和存储图片。

 

未来改进方向

  • 将知识库文件中的图片存储在云端图床,并以 URL 链接的形式嵌入,以此实现在检索结果中展示图片。
  • 尝试使用 LlamaIndex 或 RAGFlow 框架中的文档解析能力构建知识库,并与 Dify 的知识库进行效果对比。