# Round 1

我上传了一张图片，是我画的财报分析助手的框架，你能分析下这个框架么？
![picture](https://imgs.wantsong.life/2jjy6wHh3V.jpg)

你上传的财报分析助手框架图清晰地展示了一个相对完整的系统架构。从图中可以看出，这个助手的设计思路是将金融知识构建、检索与用户的查询意图相结合，最终生成有用的分析结果。下面我将对这个框架进行分析：

**一、核心模块划分：**

框架图主要可以分为以下几个核心模块：

1. **金融知识构建 (Financial Knowledge Construction):**
    * **数据来源:** 包括行业研报、财务报告、年报等多种格式（PDF、MD）。
    * **数据处理流程:**
        * **标题切分 (Title Segmentation):** 对文档进行结构化处理的第一步。
        * **文档树 (Document Tree):** 可能用于表示文档的层级结构，方便后续的chunking。
        * **Chunk:** 将文档内容分割成更小的知识单元。
        * **Embedding:** 对Chunk进行向量化表示，用于语义搜索。
        * **Table:** 识别和提取文档中的表格数据。
        * **Merge:** 可能指将不同来源或格式的数据进行整合。
        * **DataFrame:** 将表格数据存储为DataFrame格式，方便后续分析。
    * **知识存储:**
        * **Knowledge Base:** 作为一个总体的知识存储概念。
        * **Database:** 用于存储结构化数据。

2. **金融知识检索 (Financial Knowledge Retrieval):**
    * **查询类型:** 系统能够处理多种类型的专业知识问题和开放性问题。
    * **检索方式:**
        * **Vector DB:** 使用向量数据库进行基于语义的检索（向量召回）。
        * **ES DB:** 使用Elasticsearch等进行基于关键词的检索（关键词召回）。
    * **结果整合:** 将向量召回和关键词召回的结果进行合并（merge）。
    * **提示词模板填充 (Prompt Word Template Filling):** 用于构建最终答案的上下文。
    * **最终回答 (Final Answer):** 系统输出的分析结果。
    * **数据存储:**
        * **Vector DB & ES DB:** 存储用于检索的向量和索引。
        * **DataFrame & Database:** 存储用于支持检索和分析的结构化数据。
        * **API:** 提供数据查询接口。

3. **意图识别 (Intent Recognition):**
    * **用户输入:** 用户通过查询界面输入问题。
    * **问题分类 (Question Classification):** 将用户的问题分类到不同的意图类别，例如：
        * 基础信息查询 (例如：法定代表人是谁？)
        * 财务指标计算 (例如：资产负债率如何？)
        * 专业名词解释 (例如：什么是租赁负债？)
        * 报告解读分析 (例如：对XXX研发投入分析？)
    * **指标库 (Indicator Library):** 存储各种财务指标的计算方法和定义。

4. **基础信息查询 (Basic Information Query):**
    * 直接对接投资系统 (Investment System) 和数据库 (Database)，用于查询一些基础的公司信息。

**二、模块间交互流程：**

1. **知识构建流程:**
    * 从不同的数据源（行研报告、财报、年报等）获取数据。
    * 对不同格式的数据进行预处理，例如标题切分、提取表格等。
    * 将文本数据进行Chunk处理，并生成对应的向量表示（Embedding）。
    * 将处理后的数据存储到相应的知识库中（Knowledge Base, Vector DB, ES DB, Database, DataFrame）。

2. **查询分析流程:**
    * 用户输入查询问题。
    * 系统通过意图识别模块对问题进行分类，判断用户想要获取的信息类型。
    * 根据问题类型，系统可能采取不同的策略：
        * **基础信息查询:** 直接调用API查询投资系统或数据库。
        * **专业知识问题/开放性问题:** 在金融知识库中进行检索，可能同时使用向量检索和关键词检索，并将结果合并。
        * **财务指标计算:** 从指标库获取计算公式，并从DataFrame或Database中提取数据进行计算。
        * **报告解读分析:** 可能需要更复杂的逻辑，结合知识库中的信息和用户的具体问题进行分析。
    * 检索到的信息和预设的提示词模板进行填充，生成最终的回答。

**三、关键技术点：**

* **自然语言处理 (NLP):** 用于文本的切分、Chunk、Embedding、意图识别、问题分类等。
* **向量数据库 (Vector Database):** 用于高效地进行语义搜索。
* **搜索引擎 (如 Elasticsearch):** 用于关键词匹配和更灵活的搜索。
* **数据处理和存储技术:** 如DataFrame、关系型数据库等。
* **API设计:** 用于模块间的通信和数据交互。

**四、潜在的优点和考虑方向：**

* **结构化和非结构化数据结合:** 系统能够处理多种来源和格式的数据。
* **多样的查询方式:** 支持不同类型的查询，满足用户不同的分析需求。
* **知识库的构建和维护:** 如何高效地构建和更新知识库是关键。
* **意图识别的准确性:** 准确识别用户意图是提供有效回答的前提。
* **回答的质量和可解释性:** 如何确保最终答案的准确性和用户理解的便利性。
* **可扩展性:** 随着数据量和用户量的增加，系统是否能够保持高效运行。

**总结：**

你设计的财报分析助手框架是一个逻辑清晰、功能较为完善的系统。它涵盖了从数据获取、知识构建、意图识别到信息检索和最终答案生成的主要环节。在实际开发中，需要关注各个模块的具体实现细节，以及模块之间的协同工作，才能构建出一个高效、准确的财报分析助手。

如果你有关于某个特定模块的更详细的问题，或者想深入探讨某个方面，欢迎随时提出。

---

# Round 2 金融知识构建

首先先明确下，我对知识库的重定义。
**知识库**（Knowledge Base, KB），作为一个综合性的信息存储与管理系统，旨在整合来自不同来源的数据，无论是结构化的还是非结构化的，形成一个统一的信息资源池。核心在于它能够打通数据的整个生命周期——从数据的生成到收集、再到协作处理与最终的利用，及对多种数据形式的支持和融合能力。在这个过程中，知识库不仅仅是一个静态的数据仓库，而是一个活跃的数据生态系统。通过引入先进的人工智能（AI）和机器学习（ML）技术，知识库不仅能够处理传统的结构化数据，还可以高效地管理和利用非结构化数据。

金融智能助手包括为三大部分：

* **金融知识构建**，搭建金融知识库，包括了结构化的和非结构化的数据，结构化的数据为第三方系统提供，以关系型数据库或者API的形式提供。
* **意图识别**，在智能体部分，首先做意图识别，以确定客户想要调取哪些资源或者能力。
* **金融知识检索**，根据客户意图，到匹配的知识库中进行检索，最后经过大模型加工后输出。

我现在想逐步细化每一个大模块，现在做**金融知识构建**部分的细化。

上市公司发布的财务报告中，通常会包含一些重要的文本描述、财务表格和其他附注信息。每个财务报表都提供了不同方面的财务数据，用来展示公司的财务状况、经营成果和现金流情况。这些表格数据结构化程度高，需要提取出完整有用的数据信息进行加工处理。而财报文本部分则包含大量公司简介、业务描述、风险分析和管理层讨论等重要信息。我们希望大模型能够通过深入理解文本内容，提取对投资决策有帮助的信息，如公司未来的战略规划、市场风险和机遇等。

这部分包括数据预处理、知识抽取和结构化数据定义三个部分。前两步主要针对非结构化数据，由于信息、数字化大部分结构化数据已经进行了有效的管理，非结构化数据在LLM之前是疏于管理的，而且数量远大于结构化数据。
* **数据预处理**，针对财报pdf这样的非结构化数据处理，考虑到针对财报文档的一些特性，表格数据密集，专业术语繁多等情况，需要在信息抽取之前对pdf这样的非结构化数据进行预处理，主要的思路是将非结构化数据 -> 结构化数据，因此首先在数据读取和数据预处理模块。
* **知识抽取**，数据预处理后，我们得到了标准的结构化的md数据，基于处理后的md数据，我们将内容划分为文本和表格两大块，针对这两块数据分别进行文本信息抽取和表格抽取。
  * **文本抽取**，包括知识切片，元数据信息抽取，embedding等一系列子任务组成
  * **表格抽取**，
    * 难点：一份财报有几十甚至上百张表格，如果对每份表格单独抽取后直接进行数据存储，这里就会面临在NL2SQL环节召回表困难的问题；有成百上千份公司的财报，如果对每一份财报数据单独存储，就无法回答用户对不同的公司比较分析的问题
    * 解决思路：合并成一张大宽表，由于不同公司的主要财报数据的表格定义都是相似的，因此可以针对财报数据的表格进行分类：
      * 公司基础信息表：包括公司基本信息表，联系方式表，注册变更表，员工信息表等等
      * 金融指标表：包括资产负债表，利润表、现金流表等等
      * 额外的信息表
    * 步骤1： 根据分类情况单独提取每一类别的表格信息进行合并，最后再将3类表格汇总成一张大宽表，生成最终的DataFrame
      * 优点：
        * 由于都汇总成了一张表，避免了数据计算分析环节nl2sql过程中表召回困难，表召回错误的情况
        * 不同的公司的表格数据都汇总到了一起，可以对不同公司的数据进行比较分析
      * 缺点：
        * 在表格提取和数据合并的过程中，存在一部分数据的丢失，导致有些信息的缺失。
    * 步骤2： 合并成多张表数据，包括基本信息表，员工信息表，资产负债表，现金流表，其他信息表等等
      * 优点：避免了大宽表的数据缺失，分析过程可以更加精准
      * 缺点：需要更细致的表格处理；NL2SQL需要解决表召回和多表连接的问题

* **结构化数据定义**，主要是第三方系统提供API接口说明，或者关系数据库表定义，以便检索时进行Function Calling或者TexttoSQL来检索。

对于这个**金融知识构建**你有什么补充和建议么？

非常感谢你对知识库进行了更清晰的定义，这有助于我们更深入地理解整个系统的设计理念。你对金融智能助手的三大模块划分也非常明确。现在，我们聚焦于你详细阐述的**金融知识构建**部分，我将针对你的思路提供一些补充和建议：

**一、数据预处理：非结构化数据 -> 结构化数据 (PDF to MD)**

* **补充：** 将PDF转换为MD格式是一个值得探索的方向，特别是考虑到MD的轻量级和易于解析的特点。然而，需要仔细考虑转换过程中的信息完整性，特别是对于复杂的表格和格式。
  * **表格处理：** MD对表格的支持相对简单。你需要定义一套清晰的规则，如何将PDF中的复杂表格结构转换为MD表格，并确保数据不丢失、单元格合并等情况得到妥善处理。可以考虑使用Pandoc等工具进行转换，并评估其效果。
  * **公式和特殊符号：** 财务报告中可能包含数学公式和特殊符号，需要确保在转换过程中这些内容能够被正确地保留或以适当的方式表示。
  * **图片和图表：** 财务报告中也常包含图片和图表。MD本身不支持直接嵌入图片，通常通过链接方式引用。你需要考虑如何处理这些视觉元素，例如提取关键信息并以文本描述的方式呈现，或者保留图片并在后续处理中单独处理。
* **建议：**
  * **分阶段转换和验证：** 可以先尝试对少量具有代表性的财报进行PDF到MD的转换，并进行人工验证，评估转换的质量和信息损失情况。
  * **探索其他中间格式：** 除了MD，也可以考虑将PDF先转换为更富表现力的中间格式，例如HTML，然后再进行结构化处理。HTML在处理表格和格式方面可能更具优势。

**二、知识抽取：基于结构化MD数据的文本和表格抽取**

* **文本抽取：** 你提到的知识切片、元数据信息抽取和embedding是标准的流程，没有太多需要补充的。确保知识切片的粒度适中，能够捕捉到关键信息，同时避免过于细碎导致上下文丢失。元数据信息（如报告期、公司名称、报告类型等）的准确抽取对于后续检索至关重要。
* **表格抽取：** 你对表格抽取的难点和两种解决思路的分析非常到位。针对这两种思路，我有一些更细致的补充和建议：

  * **思路一：合并成一张大宽表**
    * **补充：**
      * **数据类型标准化：** 在合并不同公司的相同类型表格时，需要确保数据类型的一致性（例如，金额单位、日期格式等），必要时进行标准化处理。
      * **字段对齐和缺失值处理：** 即使是相同类型的表格，也可能存在字段顺序不一致或者某些公司缺少特定字段的情况。需要设计合理的字段对齐机制和缺失值处理策略。
      * **版本控制：** 财务报告的表格定义可能会随着会计准则的变化而发生变化。需要考虑如何处理不同版本表格的合并问题，可能需要引入版本标识或者更智能的字段匹配方法。
    * **建议：**
      * **优先合并核心财务报表：** 资产负债表、利润表和现金流量表是核心，可以优先考虑将这些报表合并成大宽表。
      * **灵活的字段映射：** 在合并过程中，允许进行灵活的字段映射，例如通过字段名称的相似度或者预定义的规则进行匹配。

  * **思路二：合并成多张表数据**
    * **补充：**
      * **表关系定义：** 如果选择将表格合并成多张表，那么明确定义这些表之间的关系（例如，通过公司代码、报告期等字段进行关联）对于后续的NL2SQL至关重要。
      * **更精细的表格分类：** 除了你提到的基本信息表、员工信息表和主要的财务报表外，还可以考虑更细致的分类，例如按报告类型（年度报告、半年度报告、季度报告）或者按信息主题（例如，研发投入明细表、关联交易明细表）进行分类。
    * **建议：**
      * **自动化表格分类：** 尝试使用机器学习等方法自动化地对财务报告中的表格进行分类，提高效率和准确性。
      * **构建表格元数据索引：** 为每个表格建立详细的元数据索引，包括公司名称、报告期、表格类型、包含的关键字段等，方便NL2SQL环节进行表召回。

  * **通用建议 (针对表格抽取)：**
    * **高质量的表格识别：** 确保能够准确地从MD（或HTML）中识别出表格的边界和内容。
    * **复杂表格处理：** 财务报告中可能包含复杂的表格，例如多级表头、跨行/跨列表格等。需要设计能够处理这些复杂情况的抽取逻辑。
    * **数据清洗和校验：** 在抽取表格数据后，进行必要的数据清洗和校验，例如去除不必要的格式符号、处理异常值等。

**三、结构化数据定义**

* **补充：** 你提到了第三方系统提供的API接口说明和关系数据库表定义。在定义这些结构化数据时，需要考虑以下几点：
  * **数据字典和元数据管理：** 为每个API接口和数据库表定义清晰的数据字典，说明每个字段的含义、数据类型、取值范围等。建立完善的元数据管理系统，方便理解和使用这些结构化数据。
  * **数据质量监控：** 建立数据质量监控机制，定期检查第三方系统提供的数据是否符合预期，及时发现和解决数据质量问题。
  * **版本管理：** 当第三方系统的API接口或数据库表结构发生变化时，需要进行版本管理，确保系统的兼容性和稳定性。
* **建议：**
  * **统一的数据标准：** 尽可能地采用统一的数据标准和命名规范，方便不同来源的数据进行整合和分析。
  * **数据血缘分析：** 记录结构化数据的来源和处理过程，方便进行数据追溯和问题排查。

**总结与进一步思考：**

你对金融知识构建部分的细化非常全面，考虑到了非结构化和结构化数据的不同特点和处理难点。

**进一步思考的方向：**

* **混合方法：** 是否可以考虑一种混合的方法来处理表格数据？例如，对于核心财务报表采用多表结构以保证数据完整性，而对于一些辅助性的表格则可以考虑合并成大宽表以方便某些特定类型的分析。
* **LLM在知识抽取中的作用：** 除了传统的规则和模式匹配方法，是否可以利用LLM在知识抽取过程中发挥更大的作用？例如，使用LLM来理解表格的语义，进行更智能的字段匹配和数据清洗。
* **知识图谱的构建：** 在抽取文本和表格数据后，是否可以考虑构建金融知识图谱，将不同实体（例如，公司、指标、行业、事件）及其之间的关系表示出来，从而支持更复杂的知识检索和推理。

希望这些补充和建议能够帮助你进一步完善金融知识构建部分的细节。如果你有任何其他问题或需要更深入的讨论，请随时告诉我。

---

# Round 3 金融知识构建

你的进一步思考方向，给了我很大的启发。结合**混合方法** 、**LLM在知识抽取中的作用**、**知识图谱的构建**三个点及你的建议和补充，能不能帮我细化下**金融知识构建**这一部分的内容。

好的，结合你对知识库的重定义以及关于混合方法、LLM在知识抽取中的作用和知识图谱构建的思考，我对**金融知识构建**部分进行更细致的划分和描述：

**金融知识构建 (Refined)**

目标：构建一个融合结构化和非结构化数据的动态金融知识库，利用LLM提升抽取能力，并构建知识图谱以支持更深层次的分析。

**核心步骤：**

1. **数据接入与预处理 (Data Ingestion & Preprocessing):**

    * **非结构化数据 (财务报告 PDF):**
        * **PDF解析与初步结构化：** 将PDF财报解析为更易处理的中间格式，例如 **结构化JSON** 或 **带语义标签的HTML**。此步骤旨在保留文本内容、表格结构、格式信息以及可能的语义信息（例如，通过分析PDF的标签或版式）。
        * **分节与内容类型识别：** 将财报文档划分为不同的章节（例如，财务报表、管理层讨论与分析、附注等），并识别每个部分的内容类型（文本、表格、列表等）。
    * **结构化数据 (第三方系统):**
        * **API数据接入：** 根据API接口文档，实现数据的自动化拉取和解析。
        * **数据库连接：** 建立与关系型数据库的连接，并定义数据读取和同步策略。

2. **知识抽取 (Knowledge Extraction - Hybrid Approach with LLM):**

    * **文本信息抽取 (LLM赋能):**
        * **知识切片 (Knowledge Chunking):** 将文本内容切分为合适的粒度（例如，段落、句子、特定的信息块）。
        * **元数据抽取 (Metadata Extraction):** 利用规则和LLM结合的方式抽取报告的基本信息（公司名称、报告期、报告类型、发布日期等）。
        * **关键实体识别与链接 (Named Entity Recognition & Linking):** 使用LLM识别文本中的关键金融实体（公司、股票代码、人物、组织、行业、产品等），并尝试将其链接到已有的知识库或外部知识图谱（例如，通过股票代码关联到公司基本信息）。
        * **关系抽取 (Relationship Extraction):** 利用LLM识别文本中实体之间的关系（例如，公司A收购了公司B，公司C的营收增长了X%）。
        * **情感分析 (Sentiment Analysis):** 使用LLM分析文本中对特定实体或事件的情感倾向。
        * **战略意图与风险识别 (Strategic Intent & Risk Identification):** 利用LLM深入理解管理层讨论与分析等文本，抽取公司未来的战略规划、面临的主要风险和机遇等关键信息。
        * **Embedding生成 (Embedding Generation):** 为文本切片和关键信息生成语义向量表示，用于后续的语义检索和知识图谱构建。

    * **表格数据抽取 (Hybrid Strategy with LLM Understanding):**
        * **核心财务报表抽取 (结构化存储):**
            * 针对资产负债表、利润表、现金流量表等核心财务报表，采用结构化的方式进行精确抽取，确保数据的完整性和准确性。
            * 将抽取的数据存储到关系型数据库或专门的表格存储系统中，并建立清晰的表结构和字段定义。
            * 利用LLM进行表格的语义理解，辅助识别表头和数据单元格之间的对应关系，处理不规范的表格。
        * **其他表格抽取 (灵活处理与元数据增强):**
            * 对于附注信息、明细表等其他表格，可以采取更灵活的策略：
                * **存储原始表格：** 将表格数据以JSON或CSV等格式存储，并关联到对应的报告和章节。
                * **LLM驱动的描述与标注：** 使用LLM对每个表格的内容进行自动描述和关键信息标注，生成更丰富的元数据。例如，LLM可以识别出某个表格是关于“研发费用明细”的。
                * **选择性合并：** 对于某些具有相似结构的辅助表格（例如，不同期间的费用明细），可以考虑在LLM的辅助下进行结构对齐和选择性合并，方便进行比较分析。
        * **表格数据链接：** 利用LLM识别表格之间以及表格与文本之间的关联（例如，某个表格的数据是对文本中某个观点的支撑）。

3. **知识图谱构建 (Knowledge Graph Construction):**

    * **节点创建：** 将抽取出的关键实体（公司、指标、行业、概念等）作为知识图谱的节点。
    * **边创建：** 将实体之间的关系（例如，所属关系、财务关系、上下游关系等）作为知识图谱的边。边的类型可以根据抽取结果进行定义。
    * **属性添加：** 为节点和边添加相关的属性信息（例如，公司名称、股票代码、财务数值、关系类型等）。
    * **LLM驱动的知识融合与推理：** 利用LLM对抽取出的信息进行融合，识别潜在的隐含关系，并进行简单的推理，例如，基于历史数据预测未来的趋势。
    * **与现有知识库对齐：** 将构建的知识图谱与已有的结构化数据进行对齐和关联，形成一个更全面的知识网络。

4. **结构化数据定义与集成 (Structured Data Definition & Integration):**

    * **API接口管理：** 维护第三方系统API接口的详细文档，包括接口描述、参数定义、数据格式等。
    * **数据库Schema管理：** 清晰定义关系型数据库的表结构、字段含义、数据类型等。
    * **数据映射与转换：** 建立API数据和数据库数据与内部知识表示（例如，知识图谱的节点和属性）之间的映射关系，实现数据的无缝集成。
    * **Function Calling能力定义：** 对于需要通过调用第三方API或查询数据库来获取特定信息的意图，需要定义相应的Function Calling能力，包括函数描述、参数定义等，供智能体在检索阶段调用。

**关键技术和考虑因素：**

* **高质量的LLM模型选择和微调：** 选择在金融领域表现优异的LLM模型，并根据财报数据的特点进行微调，以提高抽取精度和效率。
* **细致的数据Schema设计：** 为结构化数据和知识图谱设计清晰、可扩展的Schema，方便后续的数据存储、查询和分析。
* **高效的数据存储方案：** 选择适合不同类型数据的存储方案，例如，关系型数据库用于结构化表格数据，图数据库用于知识图谱，向量数据库用于embedding向量。
* **数据质量保障机制：** 建立完善的数据质量检查和验证流程，确保知识库中数据的准确性和可靠性。
* **可扩展性和性能优化：** 考虑数据量增长和查询并发带来的挑战，设计可扩展的系统架构，并进行性能优化。

通过以上细化，**金融知识构建**部分将更加强调利用LLM的强大能力来处理非结构化数据，并结合传统的结构化数据处理方法，最终构建出一个更智能、更全面的金融知识库，为后续的意图识别和知识检索模块提供坚实的基础。

---

# Round 4 意图识别

现在做**意图识别**部分的细化。意图识别包括问题分类与槽位提取两步骤。

## 问题分类

用户的查询需求多种多样，包括数据查询、年报问答等。模型需要准确识别用户意图，调用相应功能模块。如用户查询公司资产负债率时，模型需要识别这是一个数据查询请求，并调用相关公式进行SQL查询；询问公司未来增长策略时，模型需调用年报问答模块，基于RAG模块提供回复。
目前考虑同时提供几种方案：

1. 基于embedding（Bert）的识别
   * 利用BGE-v1.5对用户query和意图label进行向量化，使用逻辑回归等简单的机器学习模型进行学习分类就能获得很好效果。这种方案训练时间短、准确率高，但需要根据实际业务制作query意图数据集
   * 最重要的其实是选择一个高质量的embedding模型，文本数据的多样性和复杂性很高，直接处理原始文本往往效果不佳。大多数embedding模型是在大规模语料库上预训练的，它们已经捕捉了广泛的语言特征，embedding模型能够适应和理解不同的文本语义，将输入文本转化为标准化的稠密向量表示，提供了丰富的语言特征，从而使得逻辑回归等简单的分类器也能进行精确分类
2. 大模型prompt的ICL能力
   * 通过在prompt中加入意图识别的样例和规则，引导大模型理解用户意图，生成期望输出。这种方案无需大量数据集和训练，但可能产生大量token消耗，且意图数量增加时准确率下降。
   * Prompt一般包含意图列表和相关示例，输出一般为具体的意图名称或对应的序号
3. 大模型SFT
   * 构建意图识别的指令微调数据集，输入为用户查询语句，输出为意图标签文本或json。这种方法是通过微调的方式，让大模型具备理解和学习意图的能力
   * 开源大模型微调可以试试llama-factory或者DB-GPT-Hub
4. 在大模型上进行sequence标签监督微调
   * 针对特定意图识别任务，对大模型进行类似bert的序列分类微调。通过lora微调方式在小规模模型（如1.5b、7b）上实现最佳效果，同时可以切换adapter实现下游任务切换，提升推理速度和准确率，降低资源消耗。
   * 在分类任务中，标签通常由高度集中的单词或短语组成，某些标签含义比较专业或模糊，在一些模棱两可的情况下会导致LLMs难以从字面上有效理解标签的语义。虽然Meta自LLaMA-1以来就提供了序列分类接口，但其实很少有用LLM直接用于标签分类的工作，因为从直觉上来看decoder的因果掩码避免了前向信息泄露，无法关注全局信息。但是大模型毕竟在参数量和学习的知识信息量级上要远超过往的BERT簇模型，神经网络的黑盒可能会带给我们意外的惊喜。
   * 所以我们尝试用标签监督微调LLMs的方式去实现相关分类任务。在DB-GPT-hub中，我们用lora微调qwen-2-1.5B模型，我们直接从大模型输出的最后一层中提取潜在向量，本来这层最初是为自回归下一个token预测而设计的。现在我们将这些向量通过前馈层映射到标签空间中，产生用于判别标签分类的逻辑。从实验结果来看，模型输出的准确率和稳定性是最高的。

## 槽位提取

处理用户查询时，需要识别query中的关键槽位（slot），并根据这些槽位在数据库中进行精准匹配。例如，用户查询“2023年Q1的净利润”时，系统需要识别时间（2023年Q1）和指标（净利润），据此查询数据库获取结果。我们具体也做了以下实现：

* 大模型few-shot：通过few-shot学习，利用少量标注数据对大模型进行训练，使其能够在低资源条件下进行高效的信息抽取。
* 大模型SFT：需要构建槽位抽取的指令微调数据集，输入为用户查询语句，输出为json化的槽位标签及实体。这种方法是通过微调的方式，让大模型理解并输出格式化的槽位抽取结果
* 在大模型上进行token标签监督微调：针对具体的信息抽取任务，对大模型进行类似bert的token分类微调，使其能够准确识别出query中的各个槽位，并进行相应的数据库匹配。但是你需要创建或收集BIO标注格式的槽位分类数据集

对于我们目前的进展你有什么建议和补充？

你对**意图识别**部分的细化非常到位，考虑了多种主流且有效的方法。针对你目前的工作，我将分别对问题分类和槽位提取给出一些建议和补充：

## 问题分类

你提出的四种方案各有优势和适用场景：

1.  **基于embedding（Bert）的识别：**
    * **优点：** 训练速度快，准确率高，对计算资源要求不高。BGE-v1.5等模型在文本表示方面表现出色，配合简单的分类器即可取得良好效果。
    * **补充：**
        * **数据集质量是关键：** 如你所说，高质量的query意图数据集是这种方案成功的关键。需要覆盖各种用户query的表达方式以及所有需要识别的意图类别。
        * **意图标签的定义：** 意图标签应该清晰、明确，能够准确反映用户的查询目的，并与后端的处理模块（例如数据查询、年报问答）对应。
        * **模型更新与维护：** 随着业务发展，新的意图可能会出现，或者现有意图的表达方式发生变化，需要定期更新和维护训练数据集和模型。
    * **建议：**
        * **初期可以先尝试这种方案：** 如果已经积累了一定的用户查询数据并能进行标注，这是一个快速且有效的起点。
        * **持续迭代优化数据集：** 通过分析用户查询日志和模型预测错误的案例，不断完善和扩充意图数据集。

2.  **大模型prompt的ICL能力：**
    * **优点：** 无需大量训练数据，能够快速尝试和验证一些简单的意图识别场景。
    * **缺点：** token消耗较高，成本可能较高；当意图数量较多或query表达复杂时，准确率可能会下降；prompt的工程化管理也比较复杂。
    * **补充：**
        * **精心设计的prompt：** prompt的设计至关重要，需要包含清晰的意图列表、具有代表性的示例以及明确的输出格式要求。
        * **适用于意图较少且简单的场景：** 这种方案更适合于意图数量不多，且用户query表达相对直接的场景。
    * **建议：**
        * **可作为快速原型验证的手段：** 在没有大量标注数据的情况下，可以用这种方法快速验证某些核心意图的可行性。
        * **结合其他方案使用：** 可以将这种方法作为embedding识别或SFT的补充，处理一些长尾或难以覆盖的意图。

3.  **大模型SFT：**
    * **优点：** 通过微调使模型具备更强的意图理解和泛化能力，可以处理更复杂的query和更多的意图类别。
    * **补充：**
        * **高质量的指令微调数据集：** 需要构建包含用户查询和对应意图标签的指令微调数据集。数据质量和多样性直接影响模型效果。
        * **微调策略的选择：** 需要选择合适的微调方法和超参数，例如学习率、batch size、训练轮数等。
        * **模型评估与监控：** 需要建立完善的评估指标和监控机制，及时发现和解决模型性能问题。
    * **建议：**
        * **在中期可以考虑这种方案：** 当embedding识别遇到瓶颈，或者需要处理更多复杂的意图时，SFT是一个有效的选择。
        * **利用开源工具和社区资源：** 你提到的llama-factory和DB-GPT-Hub都是很好的微调工具，可以尝试使用。

4.  **在大模型上进行sequence标签监督微调：**
    * **优点：** 你通过实验发现这种方法在准确率和稳定性方面表现最佳，尤其是在小规模模型上通过LoRA微调，可以兼顾性能和效率。
    * **补充：**
        * **标签语义的理解：** 你提到了LLMs直接理解标签语义的挑战。你的方法通过直接从模型最后一层提取特征并映射到标签空间，绕过了直接的语义理解，取得了不错的效果，这是一个很有意思的发现。
        * **标签体系的设计：** 这种方法的效果很大程度上取决于标签体系的设计是否合理，标签之间是否具有良好的区分度。
        * **adapter的切换：** 利用adapter实现下游任务切换是一个灵活且高效的方式，可以针对不同的意图识别任务训练不同的adapter。
    * **建议：**
        * **继续深入研究和优化这种方案：** 既然实验结果良好，可以继续探索不同的模型、微调参数和数据集，进一步提升性能。
        * **关注模型的泛化能力：** 除了在已有数据集上的表现，还需要评估模型在新出现的query上的泛化能力。

**总体建议 (问题分类)：**

* **初期可以采用方案1（基于embedding的识别）快速搭建一个可用的意图识别模块。**
* **中期可以尝试方案3（大模型SFT）或方案4（sequence标签监督微调），以处理更复杂的意图和提高准确率。** 方案4看起来是你目前最有潜力的方向。
* **方案2（大模型prompt的ICL能力）可以作为辅助手段，用于快速验证或处理一些特殊的、低频的意图。**
* **在选择和组合方案时，需要考虑实际的业务需求、数据量、计算资源以及对准确率和延迟的要求。**

## 槽位提取

你提出的三种方案也都是常见且有效的方法：

* **大模型few-shot：**
    * **优点：** 在标注数据较少的情况下也能取得一定的效果，能够快速尝试和验证。
    * **缺点：** 性能可能不如fine-tuning的方法，对于复杂的槽位或嵌套槽位可能效果不佳。
    * **补充：** prompt的设计对于few-shot学习至关重要，需要包含清晰的指令和具有代表性的示例。
    * **建议：** 可以作为快速原型或在标注数据不足时使用。

* **大模型SFT：**
    * **优点：** 通过微调能够使模型学习到更强的槽位识别和抽取能力，可以处理更复杂的场景。输出json格式也方便后续处理。
    * **补充：** 需要构建高质量的指令微调数据集，其中包含用户查询和对应的JSON格式的槽位标签及实体。
    * **建议：** 这是提高槽位提取性能的常用方法，值得投入精力构建高质量的微调数据集。

* **在大模型上进行token标签监督微调：**
    * **优点：** 能够准确识别query中的各个槽位，对于边界清晰的槽位提取任务效果较好。
    * **缺点：** 需要创建或收集BIO标注格式的槽位分类数据集，标注成本较高。对于嵌套或不连续的槽位可能处理起来比较复杂。
    * **补充：** BIO标注是常见的token分类标注格式，需要确保标注的准确性和一致性。
    * **建议：** 如果你的槽位类型比较明确且边界清晰，这是一个可以考虑的方案。

**总体建议 (槽位提取)：**

* **可以根据实际的槽位复杂度和数据量选择合适的方法。**
* **对于简单的、数量较少的槽位，可以先尝试few-shot学习。**
* **对于更复杂的、需要更高准确率的槽位提取任务，建议采用SFT或token标签监督微调。** SFT输出JSON格式可能更方便后续使用。
* **构建高质量的标注数据集是所有监督学习方法的基础。**

**进一步的思考方向 (意图识别整体)：**

* **多模态意图识别：** 如果未来考虑支持语音或图片等输入，可能需要研究多模态的意图识别方法。
* **意图置信度评估：** 模型在识别意图时，可以输出一个置信度分数，用于判断识别结果的可靠性，并采取相应的处理策略（例如，当置信度较低时，可以要求用户重新输入或进行澄清）。
* **结合业务流程：** 意图识别的结果需要与后端的业务流程紧密结合，确保能够正确地调用相应的功能模块并返回用户所需的信息。

总的来说，你在意图识别方面的工作考虑得非常全面，并且已经进行了深入的探索和实践。继续在这些方向上进行优化和迭代，相信能够构建出高效准确的意图识别模块。

---

# Round 5 意图识别

目前暂时不考虑**多模态意图识别**，但是**意图置信度评估**和**结合业务流程**的考虑很有启发。
请你结合你的建议和思考方向，帮我重新梳理细化一下**意图识别**这一节，包括你建议初期、中期和低频对问题分类的使用策略。

好的，结合你对意图置信度评估和结合业务流程的考虑，以及我之前的建议，我对**意图识别**这一节进行重新梳理和细化：

## 意图识别 (Refined)

**目标：** 准确识别用户查询意图，提取关键槽位信息，并评估识别的置信度，以便后续模块能够根据意图调用相应的功能并执行相应的业务流程。

**整体流程：**

1.  **用户输入 (User Query):** 用户通过自然语言输入查询请求。
2.  **问题分类 (Question Classification):** 识别用户查询的意图，例如数据查询、年报问答、专业术语解释等。
3.  **槽位提取 (Slot Extraction):** 从用户查询中提取关键参数或实体，例如时间、指标名称、公司名称等。
4.  **意图置信度评估 (Intent Confidence Scoring):** 评估问题分类和槽位提取结果的可靠性。
5.  **结合业务流程 (Integration with Business Processes):** 根据识别出的意图和槽位，以及置信度，触发相应的后端功能模块。

**1. 问题分类 (Question Classification) - 分阶段策略：**

* **初期阶段：快速启动与基础覆盖**
    * **策略：基于Embedding（Bert）的识别**
        * **原因：** 训练速度快，准确率相对较高，对计算资源要求不高，适合快速搭建基础的意图识别能力。
        * **实施步骤：**
            1.  定义清晰的核心意图类别，例如：查询财务指标、查询公司基本信息、解读年报内容、解释专业术语等。
            2.  构建并标注一个初步的query意图数据集，覆盖这些核心意图的常见表达方式。
            3.  选择一个高质量的embedding模型（如BGE-v1.5），对用户query和意图label进行向量化。
            4.  使用逻辑回归或其他简单的机器学习模型进行训练和分类。
            5.  为每个分类结果输出一个置信度分数（例如，基于分类器的预测概率）。
        * **结合业务流程：** 将识别出的意图与后端的基础数据查询、简单的年报内容检索等功能模块进行初步对接。

* **中期阶段：提升精度与处理复杂意图**
    * **策略：大模型SFT 或 在大模型上进行 Sequence 标签监督微调 (优先考虑后者)**
        * **原因：** 当初期方案的准确率遇到瓶颈，或者需要处理更复杂、更细致的意图时，需要利用大模型的强大理解和泛化能力。你实验中Sequence标签监督微调表现良好，应作为优先考虑的方案。
        * **实施步骤 (Sequence标签监督微调为例)：**
            1.  构建更全面、更高质量的意图识别指令微调数据集，覆盖更多的意图类别和更复杂的query表达。
            2.  使用LoRA等高效微调方法，在小规模大模型（如Qwen-2-1.5B）上进行Sequence标签监督微调。
            3.  优化微调参数，提升模型在复杂意图识别上的准确率和稳定性。
            4.  继续为每个分类结果输出置信度分数。
        * **实施步骤 (大模型SFT)：**
            1.  构建包含用户查询和对应意图标签文本或json的指令微调数据集.
            2.  选择合适的开源大模型（如llama-factory或DB-GPT-Hub提供的模型）进行微调。
            3.  调整微调策略和超参数，优化模型性能。
            4.  实现意图置信度的评估机制。
        * **结合业务流程：** 将识别出的更细致的意图与更复杂的后端功能模块对接，例如：更精确的SQL查询生成、基于RAG的年报问答、财务指标的计算等。

* **低频或特定意图处理：灵活应对与快速验证**
    * **策略：大模型Prompt的ICL能力**
        * **原因：** 对于一些出现频率较低或者较为特殊的意图，可能难以收集到足够的标注数据进行训练。利用大模型的In-Context Learning能力，可以通过在prompt中提供少量示例和规则，快速引导模型理解和识别这些意图。
        * **实施步骤：**
            1.  针对需要处理的低频意图，设计清晰的prompt，包含意图描述、相关示例（few-shot）以及输出格式要求。
            2.  当用户query与这些低频意图相关时，将query和设计的prompt一起输入大模型进行意图识别。
            3.  根据大模型的输出判断用户意图，并评估输出的置信度。
        * **结合业务流程：** 将识别出的低频意图与特定的后端处理逻辑或人工辅助流程对接。

**2. 槽位提取 (Slot Extraction):**

* 根据问题分类阶段选择的方法，同步进行槽位提取的细化。例如，如果问题分类采用Sequence标签监督微调，那么槽位提取可以考虑Token标签监督微调。如果采用SFT，则槽位提取可以采用输出JSON格式的SFT。
* 无论采用哪种方法，都需要构建相应的标注数据集，并进行模型训练或prompt设计。
* 确保提取的槽位信息能够准确地传递给后端的业务逻辑模块，用于数据查询或其他操作。

**3. 意图置信度评估 (Intent Confidence Scoring):**

* 为问题分类和槽位提取的每个步骤都引入置信度评估机制。
* 置信度可以基于模型的输出概率、与其他候选意图的差距等进行计算。
* 可以设定不同的置信度阈值，根据阈值采取不同的操作：
    * **高置信度：** 直接调用相应的后端功能模块。
    * **中等置信度：** 可以向用户提供多个可能的意图选项进行确认。
    * **低置信度：** 可以提示用户更清晰地表达需求，或者转交给人工客服处理。

**4. 结合业务流程 (Integration with Business Processes):**

* 建立意图与后端功能模块的清晰映射关系。
* 根据识别出的意图和提取的槽位，构建传递给后端模块的请求参数。
* 确保整个流程的顺畅性和高效性，从用户输入到最终结果输出形成闭环。

通过以上细化的策略，你可以在不同的发展阶段采用最合适的意图识别方法，并结合意图置信度评估和业务流程的整合，构建一个更加智能和可靠的财报分析助手。记住，持续的数据收集、模型评估和迭代优化是提升意图识别效果的关键。

---
# Round 6 金融知识检索 

现在做**金融知识检索**部分的细化，包括了**Text2SQL**和**金融知识检索(RAG)**两大部分。

## Text2SQL
用户查询经过意图识别后，输出意图如果为数据分析类，则会调用为Text2SQL模块进行数据查询与计算。
这部分又分为能力和业务两部分。
### 能力

* 数据库结构，在知识库搭建时会完成这些内容：
  * 构建一个元数据字典，用来描述数据库的结构，包括表名、字段名及其类型、表之间的关系等，将其插入数据查询prompt。
  * 将实体-关系（ER）图抽象成文本表示：
    * 实体和属性
      * 公司
        * 属性：公司名称、注册地址、法定代表人、成立日期等。
        * 财务报表
          * 属性：报表编号、报表类型（如资产负债表、利润表、现金流量表）、报告期间）等。
        * 账户科目
          * 属性：科目代码、科目名称、账户类型（如资产、负债、收入、费用）、金额等。
        * 关系描述：
          * 资产负债表包含了货币资金、应收账款等资产科目，以及短期借款、应付账款等负债科目。属性：购买日期（日期）、数量（整数）、总金额（小数）等。
          * 利润表包含了营业收入、营业成本等收入和费用科目。
        * 约束和约定：
          * 公司实体的主键是公司编号。账户科目实体的外键是报表编号，参照于财务报表实体的主键。
  * 优化本地数据库结构，尽量减少复杂查询，将关键信息或常用数据放入一张大宽表中进行处理
* Query查询预处理
  * 对查询语句进行信息抽取，将关键实体与关系与schema信息匹配，然后链接映射到具体的数据库表中
  * 可构建query-sql\_template对进行分类训练，按照不同难度配比生成不同模板下的SQL语料集，用户输入query，应输出对应的sql模板或相应集合，再尝试填充或直接放入prompt中。
  * 针对复杂查询可以将其分解为几个简单查询逐步生成SQL语句
* SQL优化
  * 在prompt中告诉模型使用索引和适当的查询优化策略，提升SQL查询性能，避免全表扫描等低效操作。
  * 将生成的SQL查询在数据库上执行，并验证结果是否符合预期，不符合预期应反馈给用户或执行专门的复杂查询链路

### 业务
#### 基础信息查询
基础信息查询最大的挑战就是需要找到正确的数据列，将原始查询信息进行改写。包括公司名称，年份，查询信息意图，如果用户输入'贵州航天公司2019代表人是谁'基础信息问题，如果不做任何改写，生成的sql就变成了'SELECT 代表人 FROM fin_report WHERE 公司名称='贵州航天公司'，这样生成的sql执行的结果肯定是不正确的。因此需要根据正确的数据列预先对查询进行改写，这样生成sql才是符合预期的。
#### 财务指标计算
财务分析中常用许多专业财务指标描述企业经营状况，例如资产负债率、营业利润率、速动比率等。这要求模型能够利用这些公式计算特定财务指标。因此我们需要事先建立财务计算指标公式库：

```Json

"毛利率": {"公式": "毛利率=(CAST(营业收入)-CAST(营业成本))/CAST(营业收入)", "数值": ["营业收入", "营业成本"]},
"营业利润率": {"公式": "营业利润率=CAST(营业利润)/CAST(营业收入)", "数值": ["营业利润", "营业收入"]},
"流动比率": {"公式": "流动比率=CAST(流动资产合计)/CAST(流动负债合计)", "数值": ["流动资产合计", "流动负债合计"]},
"速动比率": {"公式": "速动比率=(CAST(流动资产合计)-CAST(存货))/CAST(流动负债合计)", "数值": ["流动资产合计", "存货", "流动负债合计"]},
"资产负债比率": {"公式": "资产负债比率=CAST(负债合计)/CAST(资产总计)", "数值": ["负债合计", "资产总计"]},
"现金比率": {"公式": "现金比率=CAST(货币资金)/CAST(流动负债合计)", "数值": ["货币资金", "流动负债合计"]},
"非流动负债合计比率": {"公式": "非流动负债合计比率=CAST(非流动负债合计)/CAST(负债合计)", "数值": ["非流动负债合计", "负债合计"]},
"流动负债合计比率": {"公式": "流动负债合计比率=流动负债合计/负债合计", "数值": ["流动负债合计", "负债合计"]},
"净利润率": {"公式": "净利润率=CAST(净利润)/CAST(营业收入)", "数值": ["净利润", "营业收入"]}
```

与基础信息查询不同的是，财务指标计算需要预置指标库，将指标的计算公式通过RAG方式进行召回，帮助模型更好的理解指标的计算规则是什么。

#### 信息统计分析

统计分析类别中，常常需要涉及分组(GROUP BY)和排序(ORDER BY)， 因此，除了前面讲到的需要召回到具体查询的数据列以后，还需要召回统计维度和规则，是需要分组还是需要排序等等

## 金融知识检索(RAG)

通过对查询进行意图识别后，通过知识检索模块，根据用户的query精准的找到相关性比较高、有一定时效性、比较丰富的内容。目前分为四个阶段，query的改写，元数据过滤，多级召回以及相关性重排序。

### 查询改写

有了意图识别后，查询改写目的是将用户的query改写成语义更清晰、含义更丰富的一个可检索的Query。常用的改写手段还有查询纠错，使用大模型来进行改写等等。
通过这一系列的处理，最终目的是把用户的Query从一个主体缺失，语义不明确、不完整、有歧义、有错的改写成一个正确的、语义表达清晰的，可召回的Query。

### 元数据过滤

把索引分成许多chunks并且都存储在相同的知识空间里面，检索效率会成为问题。如果可以通过元数据属性先进行过滤，就会大大提升效率和相关度。

### 多级召回

传统Native RAG的做法是依靠向量相似度进行单独召回获取相关上下文，如果只靠向量相似度召回，可能检索的内容存在缺失或者语义不够完整的问题，因此在财报除了向量相似度召回以外，我们也需要关键词召回，文档树召回，SQL计算召回和GraphRAG召回来弥补Native RAG的单一召回完整性不够的问题。

* 关键词召回：通过构建全文索引，通过原始查询通过分词，通过BM25将相关文档块进行检索，这种召回方式对要求精确性的检索场景非常适用。
* 文档树召回：在前面的知识构建模块中讲到了可以通过构建一棵文档多叉树，因此在检索过程中，可以使用图的广度优先遍历算法将匹配到文档标题的内容的所有叶子节点进行召回，弥补了向量召回的完整性缺失问题。
* SQL召回：对涉及财报统计或者指标计算场景中，需要进行根据用户问题生成需要的sql进行数据分析。

### 相关性重排序

随着知识空间的文档越来越多，我们的检索结果并不理想，原因是chunks在系统内数量很多，我们检索的维度不一定是最优的，一次检索的结果可能就会在相关度上面没有那么理想。仅仅靠embedding模型的向量召回，这时候我们需要有一些策略来对检索的结果做重排序，比如使用planB重排序，或者把组合相关度、匹配度等因素做一些重新调整，得到更符合我们业务场景的排序。因为在这一步之后，我们就会把结果送给LLM进行最终处理了，所以这一部分的结果很重要。
与Embedding模型不同，重排序模型以查询和上下文作为输入，直接输出相似度分数，而不是Embeddings。重要的是要注意，重新排序模型是使用交叉熵损失函数进行优化的，允许不限于特定范围的相关性分数，甚至可以是负的。目前，没有很多可用的重排模型。一种选择是Cohere提供的在线模型，可以通过API访问。还有一些开源模型，如bge-reranker-base和bge-reranker-large等。


对于这一部分内容，你有什么建议和补充么？


你对**金融知识检索**部分的细化非常全面，涵盖了Text2SQL和RAG两大核心模块，并且对每个模块的能力和业务场景都进行了深入思考。下面我将针对你目前的设计提供一些建议和补充：

## Text2SQL

### 能力

* **数据库结构：**
    * **补充：** 你构建元数据字典和文本表示的ER图的方式很规范，这对于模型理解数据库结构至关重要。可以考虑将这些元数据存储在专门的知识库中，方便管理和更新。
    * **建议：** 可以考虑在元数据字典中加入字段的语义描述或者示例值，帮助模型更好地理解字段的含义。对于表之间的关系，除了外键约束，还可以描述业务上的关联意义。
* **Query查询预处理：**
    * **补充：** 将关键实体与schema信息匹配并链接映射是Text2SQL的关键步骤。构建query-sql\_template对进行分类训练是一个不错的思路，可以提高SQL生成的准确性。
    * **建议：**
        * 可以尝试使用更先进的命名实体识别和关系抽取模型，提高信息抽取的准确率。
        * 对于复杂查询的分解，可以考虑使用基于规则的方法和基于模型的方法相结合，提高分解的可靠性。
* **SQL优化：**
    * **补充：** 在prompt中引导模型进行SQL优化是必要的。执行和验证SQL查询结果也是保证系统可靠性的重要环节。
    * **建议：**
        * 可以建立一个SQL查询优化的规则库，在prompt中引用这些规则。
        * 对于执行失败或结果不符合预期的SQL，可以记录下来并进行分析，不断优化SQL生成和优化策略。

### 业务

#### 基础信息查询

* **补充：** 你指出的基础信息查询的挑战非常关键。预先对查询进行改写以匹配正确的数据列是必要的。
* **建议：**
    * 可以构建一个“查询意图-数据列”的映射表，根据用户意图和查询中的实体信息，自动将查询改写为包含正确数据列的格式。
    * 利用LLM的语义理解能力，判断用户查询的真实意图，即使表达方式与预设的模板不完全一致，也能进行正确的改写。

#### 财务指标计算

* **补充：** 建立财务计算指标公式库并通过RAG方式召回公式是很好的方法。
* **建议：**
    * 可以考虑将指标库中的公式也进行embedding，通过语义搜索召回更相关的计算公式，尤其当用户以自然语言描述指标时。
    * 在计算指标时，需要考虑数据缺失、数据类型不一致等情况的处理机制。
    * 可以允许用户自定义指标公式，并提供验证和存储功能。

#### 信息统计分析

* **补充：** 处理GROUP BY和ORDER BY等统计分析需求是Text2SQL的重要能力。
* **建议：**
    * 在query预处理阶段，识别用户是否需要进行分组或排序，以及分组和排序的维度和规则。
    * 在prompt中更明确地引导模型生成包含GROUP BY和ORDER BY子句的SQL语句。

## 金融知识检索 (RAG)

### 查询改写

* **补充：** 查询改写对于提升检索效果至关重要。你提到的查询纠错和使用大模型进行改写都是有效的方法。
* **建议：**
    * 可以尝试结合多种改写策略，例如基于规则的改写、基于同义词词典的改写以及基于LLM的语义改写，并根据实际效果选择最佳组合。
    * 在改写后，可以对改写后的query进行评估，判断其是否更清晰、更易于检索。

### 元数据过滤

* **补充：** 通过元数据属性进行过滤是提高检索效率和相关性的有效手段。
* **建议：**
    * 在知识构建阶段，尽可能完善地提取和标注文档的元数据，例如报告类型、报告年份、公司主体、关键主题等。
    * 允许用户在查询时指定元数据过滤条件，或者让模型根据用户query自动推断需要进行哪些元数据过滤。

### 多级召回

* **补充：** 多级召回能够弥补单一召回方式的不足，提高检索的全面性和准确性。
* **建议：**
    * **关键词召回：** 可以尝试不同的分词策略和BM25的参数调优，以获得更好的关键词召回效果。
    * **文档树召回：** 需要明确文档树的构建逻辑和遍历策略，确保能够召回相关的叶子节点。可以考虑根据用户query的语义，选择性地遍历文档树的某些分支。
    * **SQL召回：** 需要明确SQL召回的应用场景，以及如何将用户query转化为可执行的SQL查询。这部分可能与Text2SQL模块有重叠，需要理清职责边界。
    * **GraphRAG：** 需要详细设计知识图谱的结构和查询方式，以及如何将GraphRAG的召回结果与向量召回和关键词召回等结果进行融合。
    * **融合策略：** 需要设计合理的策略，将不同召回方式的结果进行融合和排序，例如基于不同召回方式的得分进行加权融合。

### 相关性重排序

* **补充：** 重排序能够有效提升检索结果的质量。你提到的PlanB和BGE-reranker等模型都是不错的选择。
* **建议：**
    * 可以尝试不同的重排序模型，并在你的数据集上进行评估，选择最适合的模型。
    * 可以结合多种因素进行重排序，例如原始向量相似度、关键词匹配度、文档的新鲜度、用户历史行为等。
    * 考虑对重排序模型进行微调，使其更符合你的业务场景。

**总体建议：**

* **模块化设计：** 你将Text2SQL和RAG分开设计是合理的，可以针对不同的意图和场景进行优化。
* **清晰的流程：** 确保从用户查询到最终结果的整个流程清晰、可控。
* **持续优化：** 检索效果是一个需要不断优化和迭代的过程，需要持续监控系统性能，分析用户反馈，并根据实际情况调整检索策略和模型。

你对金融知识检索部分的考虑非常深入，涵盖了多个关键环节和技术点。在实际开发过程中，需要注重每个环节的细节实现和优化，并进行充分的测试和验证。

---

# Round 7 金融知识检索

你的建议和补充很有帮助。能否结合你的建议和补充，帮我细化梳理**金融知识检索**这一部分。

好的，结合你之前的反馈和我的建议，我对**金融知识检索**部分进行细化梳理：

## 金融知识检索

**目标：** 根据意图识别模块的输出，精准高效地从金融知识库中检索相关信息，为后续的大模型生成最终答案提供高质量的上下文。本模块包含Text2SQL和金融知识检索(RAG)两大部分，分别处理数据分析类查询和其他类型的知识查询。

### 一、Text2SQL

**目标：** 将用户以自然语言提出的数据分析需求转化为可执行的SQL查询语句，并获取相应的数据结果。

**1. 能力：**

* **数据库结构理解：**
    * **元数据字典：**
        * **描述：** 存储数据库的结构信息，包括表名、字段名、数据类型、主外键关系等。
        * **建议补充：** 在元数据字典中增加字段的语义描述（例如，“营业收入”表示公司在一定时期内通过主营业务获得的收入）、示例值，以及表与表之间的业务关联意义。
        * **存储方式：** 可存储在专门的知识库或配置中心，方便管理和动态更新。
    * **实体-关系（ER）图的文本表示：**
        * **描述：** 将数据库的ER图以文本形式表达，包括实体（如公司、财务报表、账户科目）及其属性，以及实体之间的关系（如“财务报表包含账户科目”）。
        * **建议补充：** 在关系描述中，可以更详细地说明关系的业务含义，例如“一家公司可以发布多份财务报表，通过报表编号关联”。
    * **本地数据库结构优化：**
        * **描述：** 优化数据库表结构，例如创建索引、合理分表等，以提升查询性能。对于常用的关联查询，可以考虑创建物化视图或将关键信息冗余到大宽表中。
        * **考虑：** 大宽表的设计需要在数据冗余和查询效率之间进行权衡。
* **Query查询预处理：**
    * **信息抽取与schema链接：**
        * **描述：** 对用户查询语句进行命名实体识别（NER）和关系抽取，识别出关键实体（如公司名称、年份、指标名称）以及它们之间的关系，并将这些实体与数据库schema中的表名和字段名进行匹配和链接。
        * **建议补充：** 可以尝试使用基于Transformer的NER和关系抽取模型，提升准确率。对于模糊或多义的实体，可以引入消歧机制。
    * **Query-SQL模板匹配：**
        * **描述：** 构建常见的查询模式和对应的SQL模板，通过对用户查询进行分类，匹配到合适的SQL模板，然后填充模板中的参数。
        * **建议补充：** 可以根据查询的复杂程度和类型，构建不同层级的SQL模板。对于更复杂的查询，可以考虑模板的嵌套使用或组合。
    * **复杂查询分解：**
        * **描述：** 对于无法直接匹配到现有模板的复杂查询，将其分解为多个简单的子查询，逐步生成最终的SQL语句。
        * **建议补充：** 可以尝试使用基于规则的方法和基于模型的方法相结合进行查询分解。
* **SQL优化：**
    * **Prompt引导优化：**
        * **描述：** 在生成SQL的prompt中，告知模型需要考虑使用索引、避免全表扫描等优化策略。
        * **建议补充：** 可以建立一个SQL优化规则库，例如针对不同数据库类型的优化建议，并在prompt中引用。
    * **执行与验证：**
        * **描述：** 将生成的SQL查询在数据库上执行，并验证返回的结果是否符合用户的预期。
        * **建议补充：** 对于执行失败的SQL，记录错误信息并进行分析。对于结果不符合预期的SQL，可以尝试进行自动debug或反馈给用户进行确认。

**2. 业务：**

* **基础信息查询：**
    * **挑战：** 用户查询的自然语言表达可能与数据库中的字段名称不完全一致。
    * **解决方案：** 在查询预处理阶段，构建“查询意图-数据列”的映射表，例如将“代表人”映射到数据库中的“法定代表人”字段。利用LLM的语义理解能力进行更智能的查询改写。
* **财务指标计算：**
    * **机制：** 预置财务计算指标公式库（如你提供的JSON格式），当用户查询涉及财务指标计算时，通过RAG方式检索相关的计算公式。
    * **建议补充：** 可以将指标公式也进行embedding，实现基于语义的公式召回。在计算过程中，需要处理缺失值、数据类型转换等问题。允许用户自定义指标公式并进行验证。
* **信息统计分析：**
    * **需求：** 处理涉及分组（GROUP BY）和排序（ORDER BY）的统计分析查询。
    * **实现：** 在query预处理阶段识别用户的统计分析意图和维度（例如，“按年份统计”），并在生成SQL时包含相应的GROUP BY和ORDER BY子句。

### 二、金融知识检索 (RAG)

**目标：** 对于非数据分析类的查询意图（例如，年报问答、专业术语解释），从知识库中检索出最相关的文档片段或信息，作为大模型的上下文。

**1. 查询改写：**

* **目标：** 将用户输入的query改写成更清晰、更具检索性的形式。
* **方法：**
    * **查询纠错：** 自动修正用户query中的拼写错误或语法错误。
    * **LLM改写：** 利用大模型的语义理解能力，扩展query的含义、补充缺失的主体信息、消除歧义等。
    * **建议补充：** 结合多种改写策略，并对改写后的query进行评估，判断其是否提升了检索效果。

**2. 元数据过滤：**

* **目标：** 在检索之前，根据文档的元数据属性（例如，报告类型、报告年份、公司主体）对知识库进行初步过滤，缩小检索范围，提高效率和相关性。
* **机制：** 在知识构建阶段完善文档元数据的提取和标注。允许用户在查询时指定过滤条件，或者让模型根据query内容自动判断需要进行哪些元数据过滤。

**3. 多级召回：**

* **目标：** 通过多种检索方式，全面地召回与用户query相关的知识片段。
* **方法：**
    * **向量召回：** 基于用户query的embedding和知识库中文档片段的embedding进行相似度匹配。
    * **关键词召回：** 对用户query进行分词，通过BM25等算法在全文索引中检索包含关键词的文档片段。
    * **文档树召回：** 利用知识构建阶段构建的文档树，根据用户query匹配到的节点，召回其相关的叶子节点内容。
    * **SQL召回：** (需要明确与Text2SQL的区别) 可以用于检索知识库中存储的结构化数据，例如某些关键的统计结果或指标数据，作为RAG的补充信息。
    * **GraphRAG：** 利用构建的金融知识图谱，根据用户query在图谱中进行语义搜索和路径查找，召回相关的实体和关系信息。
* **建议补充：** 设计合理的融合策略，将不同召回方式的结果进行整合和排序，例如根据不同召回方式的得分进行加权融合。

**4. 相关性重排序：**

* **目标：** 对多级召回的结果进行重新排序，将最相关的文档片段排在前面，提高最终生成答案的质量。
* **方法：**
    * **PlanB重排序：** 一种基于规则或模型的重排序方法。
    * **基于Re-rank模型的重排序：** 使用专门的重排序模型（如bge-reranker-base、bge-reranker-large）对候选文档片段进行pairwise比较，直接输出相关性得分。
    * **建议补充：** 尝试不同的重排序模型，并在你的数据集上进行评估。可以结合多种相关性因素（例如，向量相似度、关键词匹配度、文档的新鲜度）进行综合排序。考虑对重排序模型进行微调，使其更符合你的业务场景。

通过以上细化梳理，**金融知识检索**模块能够更全面、更高效地从知识库中获取用户所需的信息，为后续的大模型生成高质量的财报分析结果奠定坚实的基础。在实际应用中，需要根据用户反馈和系统性能进行持续的优化和迭代。