Skip to content

Latest commit

 

History

History
80 lines (68 loc) · 5.43 KB

README.md

File metadata and controls

80 lines (68 loc) · 5.43 KB
Raw

描述约定

  • smp2023_gbb4.zip 推理代码，提交得镜像代码
  • smp2023_gbb4_nl2sql.zip 训练代码

为了后续沟通方便，这里将type1定义为3类

  • type1
    • type11，问一个单项存在于数据库内容的题目
    • type12，统计题目
    • type11-2，法定代表人是否相同的题目，赛方定义为type23，我这里定义为11，不变
  • type2
    • type21，特定型公式，如速动比率这样的公式
    • type22，增长率，其实就是type11的一个组合
  • type31
    • 同赛方
  • type32
    • 同赛方

总体思路

如何解决type1, type2

以下三个大步骤均训练了一个ptuningv2 prefix_encoder。

  1. 路由 - 分发问题

    • 数据：
      • B榜2k条query通过关键词解析，三元分析得到的数据集。具体可以看一下query_analyze.py中的query_type_router，自动构建完后人工扫了一遍，主要扫的比较容易搞混的type1和type31
      • 将B榜和初赛的query集通过解析增强得到的数据集。具体是对于type1、type2提取中间的关键词，随机替换为词表中其他词来获得
    • 测评效果
      • 在训练集上应该已经过拟合了，B榜2k条相对于label有2条估错

  2. nl2sql - 将精准查询转化为sql语句

    • 数据：
      • type11部分的nl2sql主要来自完全解析后的自动构建，为了让该模型能学到如负债合计->总负债这样的不在词库里的映射，在训练集中也进行了加强处理，通过alias表替换来进行训练
      • type12部分主要来chatgpt生成，需要的话我可以把相关prompt和截图发出来（api由于没开外卡限速太严重，用的web批处理的），不过chatgpt仍然会有10%~20%的错误表现，需要人工扫过来进行纠正
      • type11-2，这部分解析也能完成很多，人工也标了一部分
    • nl2sql的数据列\公式召回
      • 目前使用的方案是对query分词后去停词，对于每个剩下的关键词向量召回词表内的词，最后再进行编辑距离硬卡，这里虽然加入了解析结果的数据列，但是会对数据列进行shuffle来进行训练，所以应该没有泄露
    • 测评效果
      • type11基本cover，从来没有扫到相关badcase
      • type12，偶尔出错，有可能是和type11混的太严重以及数据比例不协调的问题导致注册地址偶尔用in，不过整体效果也还是很不错的
      • type11-2，基本都是对的

  3. normalizer - 将sql查询结果和问题整理成符合问题格式的输出

    • 数据：
      • 首先用少量数据通过chatgpt训练了一个v1版的normalizer，然后通过它生成的答案进一步纠错数据再次训练得到新的normalizer，type2和type11-2的答案是固定的格式可以直接当label
    • 测评效果
      • 其实还不错。在正确工作的时候可以很完美的生成答案，但是会有5%左右的概率type1漏词比如少公司名或者少答案；type12表现得不够好，常常漏金额，可能还是数据质量不够高得原因，中间审得时候很多错误没审过来，type11-2回答也可能会少某一年得法定代表人或者少最终答案，可能可以达到90%得效果，但是对于本次评测来说可能不如规则生成答案

如何解决type31

因为数据结构早期构建得问题，这类问题本方案比较方便。通过txt构建得第一层数据结构是一棵文档树，每一级标题作为一个中间节点往下继续挂节点，所以通过向量搜索直接搜索中间得标题节点比较方便，然后把标题节点得子节点join一下喂给chatglm2，这个type因为时间精力问题基本没咋弄，但是感觉最好训练一个summarizer

如何解决type32

直接喂得query

注

type1得整体流程都经历过三大步骤，对于type12由于训练得不够好得问题会对答案作一些adjust type2，法定代表人题目最后一步是规则生成得（规则生成和模型生成差八分，没办法），其他得只有router是过得模型，后面是规则生成，不过子项也可以直接走type1得流程 type31，查找知识直接喂 type32，直接喂

为什么type2得多数问题不走模型：因为模型效果不够好，为了提分没法子。其实感觉模型对于pattern太重得数据集确实没有规则好，模型得主要优势还是在泛化性能和更加复杂pattern得数据集上

附录 - 数据流程示例

  1. query 哪家上市公司，在北京注册，2020年总负债最高？金额为？
  2. router to type12
    • prompt = query
    • response type12
  3. nl2sql
    • prompt \n 你的任务是将问题转化为SQL。\n 1. SQL语句查询的表名为: big\n 2. 涉及到的列名有: 注册地址,负债合计,预计负债,股票简称,公司名称,股票代码,年份\n\n 【问题】哪家上市公司，在北京注册，2020年总负债最高？金额为？\n 【SQL】
    • response select 公司名称, 负债合计 from big where 注册地址 like '%北京%' and 年份 = '2020年' order by 负债合计 desc limit 1
  4. normalize
    • prompt 根据查询结果回答问题。【查询结果】{'公司名称': ['华能国际电力股份有限公司'], '负债合计': ['296730398479']}【问题】哪家上市公司，在北京注册，2020年总负债最高？金额为？【回答】
    • response 华能国际电力股份有限公司在2020年总负债最高，金额为296730398479元。