1. 什么是知识
知识（Knowledge）是指在自然语言到SQL（NL2SQL）转换过程中，用于帮助大模型理解业务领域特定术语、逻辑、规则等的辅助信息。
知识的配置旨在提升模型生成SQL/MQL的准确性和可解释性，尤其是在面对复杂业务场景时。
2. 为什么要配置知识
- 提升模型理解能力：通过配置业务知识，模型能够更好地理解业务领域的特定术语、逻辑和规则，从而生成更准确的MQL语句；
- 应对复杂业务场景：在业务逻辑复杂、数据模型不规范或多义词存在的情况下，配置知识可以帮助模型避免生成错误的MQL；
- 增强模型泛化能力：通过合理的知识配置，模型能够在面对新问题时，基于已有知识进行推理，提升泛化能力；
- 减少人工干预：通过配置知识，减少模型生成MQL后的人工修正工作，提升自动化程度。
3. 知识配置基本原则
3.1 配置原则
- 避免过度配置：不要过度依赖业务知识，避免让模型过于依赖外部知识而失去泛化能力。业务知识应作为辅助，而不是主导。
- 准确性：确保业务知识的准确性和时效性，错误或过时的业务知识会导致模型生成错误的SQL语句。
- 简洁性：业务知识应尽量简洁明了，避免过于复杂的描述。过于复杂的知识可能会增加大模型的推理负担，降低生成SQL&Python的准确性。
3.2 前提条件
- 明确业务需求：在配置知识之前，必须明确业务的具体需求，了解业务领域的术语、逻辑和规则；
- 数据模型清晰：确保数据模型采用维度建模，并且结构清晰，维度、指标等字段唯一且定义明确，避免因数据模型不规范导致的误解；
- 知识来源可靠：配置的知识必须来源于可靠的业务文档、专家意见或经过验证的业务规则，确保知识的准确性和时效性；
- 大模型能力评估：在配置知识之前，评估大模型的基础能力，确保大模型能够有效利用配置的知识进行推理和生成。
4. 知识分类及配置方法
4.1 知识分类
- 行业术语（名词）：当行业业务领域有特定的术语或缩写时，需要配置业务知识来帮助模型理解这些术语的含义。例如，在金融领域“ROI”代表“投资回报率”。
- 业务逻辑：当业务逻辑复杂且不易通过简单的自然语言描述时，配置业务知识可以帮助模型更好地理解并生成正确的SQL。
- 多义词：当自然语言问句中的词汇有多重含义时，配置业务知识可以帮助大模型选择正确的解释。例如，股票“交易量”可以“交易数量”，也可以指“交易金额”。
- 业务规则：当业务有特定的规则或约束时，配置业务知识可以确保生成的SQL符合这些规则。例如，某些维度只能取特定的值，模型维度要剔除一些值。
- 专有词库：若问句无法命中知识，分析后是分词的原因，需要提供自定义专有词库。
知识分类参考：
序号 | 知识类型 | 分类描述 | 细分分类 | 细分描述 |
|---|
1 | 业务知识 | 代表业务术语、业务含义、业务同义词，业务转换等 | 专业术语与定义类 | 指定义业务术语含义等业务知识，用于统一专业知识，便于大模型理解匹配指标； |
2 | 业务基础指标类 | 指针对核心业务指标计算公式（如比率类、汇总类）提供的统计逻辑； |
3 | 定制知识 | 除却包含业务含义之外，需要按照制定逻辑执行业务需求。 | 数据清洗与填充类 | 指对数据质量条件的预处理：如空值填充（如空值转0）、数据去重（如剔除空用户编号）等； |
4 | 关键词执行规则类 | - 指出现特定关键词后执行计算的步骤或需指定的返回的内容：（如"率"触发乘100）；
- 模糊匹配逻辑。
|
5 | 时间维度类 | - 指定义时间范围（如“本月”指上个月）（如近半年推7个月）及时间相关时间字段（如实收时间）的过滤逻辑；
- 上周：当统计上周指标时，时间条件设置“年周”=上周
|
6 | 系统知识 | 代表系统默认配置的一些知识。 | 开发约束与规范类 | 指规定代码实现的边界条件（如禁止返回JSON_SQL）、表关联方式（仅LEFT JOIN）及字段严格匹配要求，以及其他系统需要默认配置的知识。 |
4.2 配置方法
- 知识名称：即key，能否命中知识与key高度相关，可用分号分隔key，如：（抄表员;抄表人员;客户经理）,避免出现“情况”、“明细”、特殊字符（_%?*等）。
- 知识内容：即知识涵盖的详细信息，知识也是提示词的来源，该部分内容如果问句命中知识，会纳入提示词，由大模型进行理解学习。一般采用句式：
- “XXX”是指“XXXX”：，
- 当问句涉及或问到“XXX”，进行如下处理：xxx，
- 具体写法可参照1配置原则；
- 是否启用：分三个状态
- 启用：常用状态，知识默认启用。
- 禁用：弃用知识可选择禁用，或者删除。
- 必选：设置必须，该知识优先级高于启用。
- 嵌入问句：
- 是：嵌入问句是每个问句都会带上该知识，一般不用嵌入问句；
- 否：正常业务知识不用嵌入问句；
4.3 配置示例
业务方面，满足以下场景情况需配置知识：
- 存在同义词：尽可能列举相同含义但是不同问法的词语；
知识名称 | 知识内容 | 启用状态 |
用户分布 | 用户分布是指“用户数” | 启用 |
抄表员;抄表人员;客户经理 | (抄表员;抄表人员;客户经理)是指“抄表人名称” | 启用 |
姓名 | 问句中涉及到**姓名**字眼时，**姓名**是指用户名称 | 启用 |
公线公变 | 公线公变是指公变客户 | 启用 |
- 业务上特有的规范：一般是业务规则/规范，或则按照一定业务规则执行。
知识名称 | 知识内容 | 启用状态 |
当月;本月 | （当月;本月）指上个月的月初到月末 | 启用 |
专变客户 | 专变客户是指**用户类别名称**为**公线专变客户**和**专线专变客户**的汇总数据，处理时需要将**公线专变客户**和**专线专变客户**的数据求和汇总为**专变客户** | 启用 |
诉求 | 是指受理业务类别不为空 | 启用 |
进入第三档阶梯电价 | 当用户问句包含"第3档"时 按如下步骤执行代码： 第1步：默认增加阶梯类型='年阶梯'过滤去查询去年同期计费电量年累计 小于第三档电量 的 去年同期计费电量年累计、第三档电量、计费电量、计费电量同比增长率的数据记为df1 ; 第2步执行计算如下： df1['第二档剩余电量'] = df1['第三档电量']- df1['计费电量年累计']; 第3步执行计算如下： df1['本期预测值']=df1['计费电量']*（1+df1['计费电量同比增长率']）; 第4步执行计算如下： 新增字段 **进入第3档** 逻辑: 使用apply函数对每行数据判断:if本期预测值-第二档剩余电量大于 0则为true 。筛选出**进入第3档** 为true的数据并同时展示“本期预测值”和第二“档剩余电量”。 | 启用 |
欠费回收 | 当问句中涉及“完成”及“欠费回收”字眼时，进行如下处理：
-- 第一步获取条件下的实收电费、实收日期
-- 第二步获取应收电费
-- 第三步汇总实收电费、最大实收日期
-- 第四步过滤出应收电费等于实收电费，获取 应收电费、实收电费、实收日期，过滤条件：应收电费大于0且实收电费大于0 | 启用 |
催收重点 | 计划两个步骤：
一、获取数据,无需分析数据
注意：**需要3个sql_json通过查询3张表获得3个dataframe去merge**，每张表都对用户编号降序；
#### 获取欠费金额大于0的用户信息：用户编号、用户名称、欠费金额、扣款结果；
注意：**发生催收一定是欠费金额大于0** 、**时间和组织维需要输出**、**剔除用户编号中的#null等空数据**
#### 通过**用户交费情况事实表**中获取 **城关供电所** 的用户编号、高频交费时段；
注意：**高频交费时段**(需要新增字段)，逻辑如下：
a、横向比较**近一年**指标名为："1至5日"、"6至10日"、"11至15日"、"16至20日"、"21至25日"、"26日至31日"的这六个指标值大小，获得横向最大值对应的列名(列名要保持前面列举的指标名一致)；
b、新增**高频交费时段**列，value等于上面获得的列名；
#### 通过**客服_客服工单信息**中获取 **城关供电所**受理业务类别名称、三级业务子类名称（conds中忽略年月）；
注意：**诉求风险**（需要通过**受理业务类别名称**新增字段），逻辑如下：
a、受理业务类别名称为“投诉”或"意见"的为高诉求风险；
b、受理业务类别名称不为"投诉"或"意见"的为中诉求风险；
c、受理业务类别名称为空的为低诉求风险；
#### 需要将上述3个Dataframe通过**用户编号** left join后才能获得最终Dataframe，字段必须遵循：
**columns**=["用户编号","用户名称","高频交费时段","欠费金额","受理业务类别名称","三级业务子类名称","扣款结果","诉求风险"]
二、对上面最终的Dataframe进行分析，**分析**模板参考如下:
#### 交费时间风险,根据当前欠费用户，高频交费时段越靠近月末的，风险越高，筛选并展示出这些用户信息；
#### 欠费金额风险,按照欠费金额大小降序，取TOP10；
#### 诉求风险,对用户进行聚合，统计欠费用户的**受理业务名称**的sum次数和平均欠费金额并展示；
#### 自动缴费用户,对扣款结果不等于**交易成功**的用户进行统计分析并展示； | 启用 |
- 同词根-多词组-不同义词或容易产生歧义的指标：如果各个单位能统一口径可以配置知识，如果不能就不配置知识，由系统反问；
知识名称 | 知识内容 | 启用状态 |
售电量;电量;用电量;售电情况 | (售电量;电量;用电量;售电情况)是指**计费电量**，且**用户类别名称**not like **考核表户** | 启用 |
缴费;现金缴费用户数 | 当问句中涉及**缴费**字眼时，根据**实收日期**来做时间条件 | 启用 |
工商业;一般工商业 | (工商业;一般工商业)是指用电类别为：工商业及其它用电、普通工业和商业 | 启用 |
- 全网统一口径且数据模型中没有该指标:
知识名称 | 知识内容 | 启用状态 |
穿透式 | -- 抄核收穿透式指标包含电子化结算率、 电费发行率、 电费差错率 、陈欠电费回收率、自动对账率、分散复核率
-- 其中陈欠电费回收率是指**电费回收统计项目名称**为合计的数据 | 启用 |
分项 | (欠费分项;分项欠费)默认展示"欠电费"、 "欠违约金","欠其他","欠电度电费"、"欠基本电费"、"欠力调电费"、"欠附加费"、"欠电能电费"、"欠输配电费"、"欠市场化分摊电费"、"欠上网环节线损电费"、"欠系统运行费" | 启用 |
预收冲抵 | 预收冲抵是指**预付电费统计项目名称**的成员为电费区间合计的本月冲抵金额的数据 | 启用 |
三个档次 | 三个档次是指字段"档次"包含'第一档','第二档','第三档' ，不包含空值，日期维走核算年份,如果查用户数的话，应该使用"核算用户数"指标 | 启用 |
5. 知识上架流程
- 知识采集：由知识团队获取业务知识，并按照配置方案填入《ZHYS-智能问数知识评审表-2025-xx-xx》；
- 知识评审：由技术专家和业务专家参与评审，对知识进行权威性认证；
- 测试与验证：在测试环境中配置业务知识后，充分测试和验证，确保生成的SQL&Python符合预期。通过人工审核或自动化测试来验证，保持稳定。
- 知识发布：将该知识发布到生产环境，并测试验证。