ChatBI

什么是ChatBI?

BI: 商业智能(Business Intelligence)

ChatBI:

词槽模式

词槽模式的挑战

• 分词多样性
• 更新频繁的专有名词, 黑化
• 多轮对话追问
• 表达能力受限于"槽位" , 如:
  • 自定义函数, 子查询, 分组后再过滤, 窗口函数¹
  • 多意图, 嵌套意图
• 国际化支持(英文, 法语, 德语…)

为什么需要窗口函数？

举个简单例子: 如果想查询每个学生的成绩，同时显示他所在班级的平均分，用传统聚合函数需要先 GROUP BY 班级计算平均分，再通过 JOIN 关联回原表；而窗口函数可直接在一行中同时返回学生个人成绩和班级平均分，无需额外关联，大大简化了分析逻辑.

窗口函数的核心构成

函数名(列名) OVER (
    [PARTITION BY 列名]  -- 可选，将数据分组（类似GROUP BY，但不压缩行）
    [ORDER BY 列名 [ASC/DESC]]  -- 可选，对分区内的行排序
    [ROWS/RANGE 边界条件]  -- 可选，定义窗口的具体范围（如前N行、当前行及后N行）
)

• 函数部分：可以是聚合函数（SUM、AVG、COUNT 等），也可以是专用窗口函数（如 RANK、ROW_NUMBER、LAG 等）。
• OVER()：是窗口函数的标志，括号内的参数定义了 “窗口” 的范围和规则。

为什么行数不变?

窗口函数的本质是给每一行数据 “附加” 一个基于某组数据（窗口）的计算结果，而不是像GROUP BY那样将多行合并成一行。

举个具体例子：
假设有一张学生成绩表（原始数据 3 行）：

学生 ID	班级	成绩
1	一班	90
2	一班	80
3	二班	85

如果用窗口函数计算 “每个学生所在班级的平均分”：

SELECT 
  学生ID, 班级, 成绩,
  AVG(成绩) OVER (PARTITION BY 班级) AS 班级平均分
FROM 成绩表;

结果是：

学生 ID	班级	成绩	班级平均分
1	一班	90	85	（一班平均分：(90+80)/2=85）
2	一班	80	85	（同一窗口的计算结果复用）
3	二班	85	85	（二班只有 1 人，平均分 = 自身成绩）

可以看到，结果仍然是 3 行，与原始数据行数完全一致。窗口函数只是在每行后多了一列 “班级平均分”，这列的值由 “窗口”（这里是每个班级的所有行）计算得出，但原始的每行数据都被完整保留。

对比普通聚合函数：为什么行数会变？

如果用普通聚合函数（搭配GROUP BY）计算班级平均分：

SELECT 班级, AVG(成绩) AS 班级平均分
FROM 成绩表
GROUP BY 班级;

结果只有 2 行（按班级合并）：

班级	班级平均分
一班	85
二班	85

此时，原始的学生 ID、个人成绩等细节都被 “聚合” 掉了，行数自然减少。

拆解语法：每部分都有明确作用

1. AVG(成绩)：指定计算逻辑

AVG(成绩)是聚合函数，这里表示要计算 “成绩” 的平均值。但单独的AVG(成绩)会计算整个表的总平均分（如SELECT AVG(成绩) FROM 成绩表），而我们需要的是 “每个班级的平均分”，因此需要搭配OVER()来限定范围。

2. OVER (PARTITION BY 班级)：限定计算范围

OVER()是窗口函数的标志，括号里的PARTITION BY 班级是核心：

• PARTITION BY 班级：将整个表按 “班级” 拆分成多个独立的 “窗口”（可以理解为 “分组”）。比如 “一班” 是一个窗口，“二班” 是另一个窗口。
• 此时，AVG(成绩)的计算范围就从 “整个表” 缩小到了 “每个窗口内的成绩”，即 “每个班级的平均分”。

3. AS 班级平均分：给结果列命名

这部分是别名，方便后续理解列的含义，没有特殊逻辑，只是为了让结果更易读。

方案对比

技术路线	类比	优势	劣势	适用场景
词槽	传统 NLP 驱动来完成拖拽构建看板操作	1. 速度最快 2. 可解释性强 3. 可干预性强	1. 相对拖拽式 BI，易用性差别小 2. 问题空间和解决方案空间都是最小的	对提问要求高，能产出结果有限，或许是高频、快速响应场景（类似客服机器人）。 与固定看板相比优势不明显。
Text2DSL	搜索已有数据资产，加少量查询条件生成	1. 人工构建的资产，可以追责 2. 可解释性较强，可以看指标定义 3. 可干预性较强，可以修改查询条件	1. 相对传统搜索，提升主要是生成了查询条件 2. 较高的建设维护成本 3. 指标数量多时，需要用户来自行分辨	企业已经积累了大量的指标资产场景，可以先利用起来。 私有化部署的模型，能力不足以生成复杂代码。
Text2SQL	模拟数据分析师通过企业内知识来写 SQL	1. 智能化程度最高，利用了大模型能力 2. 问题空间和解决方案空间都是最大的 3. 最大化利用知识的泛化性	1. 速度慢 2. 依赖自然语言来进行解释和理解 3. 复杂问题不容易干预结果（依赖对话交互）	业务变化快，需要极致敏捷探索的场景。 作为通用工具提供给 Agent，实现更高级的分析、洞察与决策建议。

拓展: https://zhuanlan.zhihu.com/p/721580508

RAG

RAG指的是Retrieval Augment Generation, 检索增强生成

来源: https://www.bilibili.com/video/BV1TC41177rC/?vd_source=7c9ec9a66bf7ed5e2779d762e6656916

ChatBI提升回答准确率的典型难点

• 企业内部专有知识, 例如产品名, 口径等
• 查询逻辑的复杂度
• 用户反馈信息的收集和利用

ChatBI与RAG结合

数据分析与RAG结合

代码生成

• 任务拆解: text2SQL 领域的 schema linking 等(在text2SQL中拆成两步, 先选表和字段,范围缩小了, 再生成SQL) .
• 代码验证与自我修复: 类似fact checking, 如告诉 LLM , 产生了幻觉, 生成的 SQL 有什么样的错误, LLM可以自动修复.
• 抽象与复用: semantic layer², tool use. 如, 数据分析中同环比, 看起来很简单, 但是相应的SQL式很复杂的, 但是又是常用的, 所以, 可以把这段SQL封装成函数, 相当于一个工具.

RAG优点

• 引入企业内部知识, 与LLM通用能力结合

• 有效降低幻觉问题

• 相比fine-tune(微调)³ :

  • 更好的可控性:

    风险控制的可控性：RAG 能 “划红线”，Fine-tune 易 “越界”

    • RAG 的边界可控：
      可通过设置检索规则（如 “仅允许从官方权威文档中检索”）或过滤机制（如屏蔽敏感内容），严格限制模型输出的知识范围。

      例：在医疗问答中，RAG 可限定 “仅参考国家卫健委发布的诊疗指南”，避免输出错误偏方。

    • Fine-tune 的 “隐性风险”：
      微调可能让模型学到数据中的偏见或错误，且难以单独剔除, 可能会导致欠拟合。即使训练数据干净，模型也可能 “联想” 出超出训练范围的内容（胡编乱造, 即 “幻觉”），且难以控制, 也就是过拟合。

      例：用某企业产品数据微调后，模型可能错误生成该企业未发布的产品信息，且无法通过简单操作阻止这种 “越界”。

  • 易于控制数据安全: A部门, B部门所用到的企业知识是不同的, 而且不希望每个部门看到其他部门所用到的知识

  • 更适合新知识的嵌入

  • 更新成本低: 企业知识可能是每天都有更新, 对于fine-tune来说 就会每天fine tune(微调) 一个新的模型, 而且不同部门可能还要fine tune不同的model.

  • 总体效果更优

为什么需要 Fine-Tune? 预训练模型的 “短板” 与解决方案

想象一下, 你有一个能识别各种动物的 AI 模型, 但你需要它专门识别宠物猫的品种. 这时, 直接用原始模型效果可能不理想, 因为它没有针对 “猫品种” 进行优化. Fine-Tune 的核心价值就在于:

• 节省资源: 无需从头训练模型( 耗时耗算力) , 直接基于已有模型优化。
• 提升精度: 让模型在特定领域( 如医疗/金融) 的表现远超通用模型。
• 适配小数据场景: 即使只有少量特定领域的数据, 也能有效优化模型。

Fine-Tune 的核心原理：用新数据 “微调” 模型参数

1. **预训练模型(Pre-trained Model) **
   先用海量数据( 如 ImageNet 图像库/ Wikipedia 文本) 训练一个通用模型, 这个模型已经学会了 “基础能力” (如图像特征提取/ 语言理解) .
2. 微调过程
   冻结模型的大部分参数( 尤其是底层), 只让少数层( 通常是最后几层) 在新数据( 如宠物猫图片/医疗报告)上学习. 就像让一个已经学会 “画画” 的人, 再专门学习 “画猫” 的细节.
3. 关键公式
   微调后的模型参数 = 预训练参数 + Δ 参数（通过新数据学习得到）

RAG V.S. Agent

• 代码生成是固定流程, LLM作为一个function, 比如下图中的Lang Chain的"代码生成" 阶段就是调用了LLM, 此时, LLM类似于一个函数, 只不过LLM的输入是prompt⁴, 而输出就是代码.
• 有的时候不需要LLM做知识召回, 比如用户问: “你好”, 此时LLM就不需要做知识召回⁵, 查找相关的大量的文献了. 那么可不可以让大模型自己想什么时候做知识召回?
• 答案是可以的. 如下方的Agent 方式.
• 全自动Agent, PDCA⁶, 但是有一个问题: Agent可能对于一个错误无法修正, 或者走了很多的弯路才得出正确答案.
• Hybrid方案: 不是固定的RAG, 也不是完全自由的RAG, 是两者的结合. 常见的有: Agent切分, LLM可以作为一个router路由器, state machine状态机
  • Agent切分: 拆解为多个相对独立、功能单一的子智能体的过程.
    • 多智能体协作系统：在无人车编队行驶场景中，将每辆车视为一个智能体，同时每个智能体内部还可进一步切分，如环境感知 Agent、通信 Agent、决策规划 Agent 等，它们既相互协作完成编队行驶任务，又通过内部切分实现高效的功能处理。
    • 复杂知识图谱问答系统：可切分为知识检索 Agent、语义理解 Agent、答案生成 Agent 等。知识检索 Agent 负责从知识图谱中查找相关信息，语义理解 Agent 解析用户问题，答案生成 Agent 整合信息并生成答案。
  • LLM as router: 一个问题到来之后, 不需要利用人工(if…else…)来判断, 让大模型判断需不需要召回, 类似于一个路由器.
  • 状态机: 不仅可以if else, 还可以做循环for loop. 一次循环所得结果不够好, 那么可以再次循环, 知道得到满意的结果状态才退出循环.

RAG技术支持

• 知识库存储: ElasticSearch, pgvector, milvus, chroma…
• Embedding model⁷: OpenAI, gte, bge, m3e…
• LLM: OpenAI, Qwen, MiniMax, DeepSeek…
• 开发框架: langchain家族, llama index

数据分析RAG相关难点

1. Evaluation评估

• Promptfoo: Prompt测试与对比工具
• Langfuse、Langsmith: LLM 应用全流程调试与监控平台（Langsmith 是 LangChain 生态工具，Langfuse 独立但功能类似）
• RAGAs、DeepEval: RAG 系统专用评估框架（RAGAs 更轻量，DeepEval 功能更全）

2. 召回准确率

• query 和 document 的向量空间一致性

  • 类似于HyDE的方案

    HyDE（Hypothetical Document Embeddings）是一种用于提升检索增强生成（RAG）系统性能的方案，核心是改善检索时的文档匹配效果， 让模型能够更精准地召回与用户问题相关的文档。以下从设计目的、工作原理、优势及应用案例等方面详细介绍：

    设计目的

    在传统的 RAG 系统中，基于用户查询（query）去检索文档时，可能会出现检索结果与用户真实需求不匹配的情况。比如，用户的问题表述较为模糊或者抽象，直接用用户的原始查询向量去匹配文档向量，难以召回高质量的相关文档，从而影响最终生成答案的质量。HyDE 方案就是为了解决这类检索偏差问题，提高文档检索的相关性和准确性。

    工作原理

    • 生成假设文档：当用户输入一个查询（query）时，HyDE 会利用大语言模型（LLM）生成与该查询相关的假设文档（hypothetical document）。这个假设文档可以理解为，模型根据用户的查询，推测出的可能包含相关信息的文本内容。例如，用户查询 “如何提高马拉松成绩”，LLM 生成的假设文档可能包含一些关于训练方法、饮食建议、体能训练等方面的文本描述。
    • 获取假设文档嵌入向量：对生成的假设文档进行 Embedding 处理，得到假设文档的向量表示。这个向量捕捉了假设文档的语义信息。
    • 重新检索：使用假设文档的向量与知识库中的文档向量进行相似度匹配，重新检索相关文档。相较于直接使用原始查询向量，假设文档向量能够更好地捕捉到语义关联，从而召回更符合用户需求的文档。

• 混合召回

  • 向量召回

    向量召回就是通过计算查询向量与数据向量之间的距离，找出距离较近（相似度较高）的数据，将这些数据作为与查询相关的召回结果。

  • 全文检索召回(BM25等)

    全文检索召回（Full-Text Retrieval Recall）指的是从文本集合中，基于用户查询（query）召回所有与查询内容相关文档的能力，核心是通过关键词匹配等方式找出语义相关的文本。而 BM25 是全文检索中最经典的排序算法之一，常用于衡量文档与查询的相关性，进而实现高效召回。

• 缩小检索范围: self-query, query路由等

  • self-query（自查询）：在 RAG（Retrieval Augmented Generation）技术中，self-query 检索技术是指利用 LLM（大型语言模型）将非结构化查询转化为结构化查询。通过让语言模型自动将自然语言查询解析为更结构化、更可操作的格式，从而提高信息检索的准确性和效率，使得检索过程更具智能化和自动化。例如，用户输入一个较为模糊的自然语言查询，self-query 技术可以将其转化为明确的、带有特定条件和参数的结构化查询，从而更精准地在数据库或知识库中进行检索，缩小检索范围。
  • query 路由（查询路由）：query 路由是一种根据查询的内容和意图将查询定向到特定流水线的技术。它通过分析每个查询并选择最佳检索方法或处理流水线来提供准确的响应。这通常需要实施多索引策略，将不同类型的信息组织成单独的、经过优化的专门索引。例如，基于事实的问题可能会被路由到一个专门存储事实性数据的索引进行检索，而需要总结或解释的问题则会被发送到另一个包含相关知识和算法的流水线进行处理，这样可以针对性地在不同的索引或处理流程中进行检索，避免在整个数据集中盲目搜索，从而缩小检索范围，提高检索效率和准确性。

• fine-tune embedding model

3. 召回查全率

召回率 = 检索到的相关文档数量 ÷ 所有相关文档的总数量

举个例子：假设用户查询 “人工智能应用”，整个文档库中共有 100 篇相关文档，而系统最终只检索到其中的 80 篇，那么召回率就是 80%。
这个指标直接反映了系统是否能 “不漏掉” 与查询相关的内容 —— 召回率低，意味着很多相关文档被遗漏；召回率高，则说明系统能覆盖大部分相关信息。

• 问题分解 (问题很复杂) , 改写, 与领域知识结合
• 召回与agent推理结合: self-rag, crag

多轮召回：

4. 生成的正确性

• fusion & re-rank
  • rule based
  • model based
  • rerank: 重排序
    
• prompt engineering: 如果经常犯一些错误, 可以通过改写提示词(优化提示词), 让LLM不这些错误
• SQL/code validation
• fact check

5. 生成的相关性

• question similarity check

  问题相似度检测指通过算法判断两个或多个问题在语义上的相似程度，核心是识别 “不同表述但意图相同” 的问题。
  例如: 让LLM根据生成的回答,在生成问题, 检测生成的问题和原始问题的相似度有多少, 如果相似度很低, 那么说明LLM 在胡说八道.

• self critic & refine

  自我批判与优化指让模型对自己生成的内容进行反思、评估，并迭代优化输出结果，模拟人类 “检查 - 修改” 的思维过程。
  例如：模型先回答 “什么是光合作用”，再自动检查 “是否遗漏了关键条件（如光照、叶绿体）”“表述是否准确”，然后补充修正。

展望未来

• 知识变迁管理

  指对系统所掌握的知识进行动态跟踪、更新和维护，以应对现实世界中知识的时效性变化（如事实更新、概念迭代）。

  • 核心问题：如何让模型识别 “旧知识” 的过时性（如 “某国首都变更”“科学理论被推翻”），并高效纳入 “新知识”，同时避免新旧知识冲突。
  • 关键技术：
    • 知识图谱动态更新（实时标记知识的生效时间、来源可信度）；
    • 增量训练（在不遗忘旧知识的前提下，用新数据微调模型）；
    • 溯源验证（对模型输出的知识标注来源，方便人工或算法核验时效性）。

• 与 long-context 结合

  指大语言模型处理超长输入文本的能力。传统模型的上下文窗口有限（如早期 GPT-3 仅支持 4000 tokens），而长上下文模型可支持数万甚至数十万 tokens 的输入（如 GPT-4 Turbo 支持 128k tokens）。

  • 核心价值：
    • 直接处理完整文档（如整本书、长篇报告、代码库），无需人工拆分；
    • 保留更长的对话历史，让模型在多轮交互中记住早期细节（如连续几天的对话中保持逻辑连贯）；
    • 提升复杂任务效率（如长文档摘要、跨章节逻辑推理、多文档对比分析）。
  • 技术挑战：如何在扩展上下文长度的同时，保证模型的计算效率、注意力分配准确性（避免对关键信息的 “注意力稀释”）。

• 记忆管理, 自我提升

  模拟人类的记忆机制，让模型能主动存储、调用和优化自身 “经验”，实现能力的持续迭代。

  • 记忆管理：
    • 区分 “短期记忆”（当前对话中的临时信息）和 “长期记忆”（可复用的通用知识、用户偏好、历史交互模式）；
    • 对长期记忆进行结构化存储（如按主题、场景分类），并支持快速检索（类似人类 “回忆” 过程）。
  • 自我提升：
    • 基于用户反馈或任务结果，自动总结错误模式（如 “某类问题回答准确率低”）；
    • 针对性调整处理策略（如对薄弱领域强化知识调用，或优化提示词生成逻辑）；
    • 类比人类 “复盘”：完成任务后生成 “反思报告”，记录成功经验和改进点，用于后续同类任务。

• 多模态融合

  指将文本、图像、音频、视频、数据表格等多种类型的信息（“模态”）整合处理，让模型具备跨模态理解和生成能力。

  • 核心能力：
    • 跨模态理解：如 “根据图片描述内容”“将音频转文字并分析情感”“结合表格数据生成总结性文本”；
    • 跨模态生成：如 “根据文本描述生成对应图像”“给视频添加符合场景的背景音乐”“将科研数据（表格）转化为可视化图表并配文字解读”。
  • 技术核心：构建统一的多模态表示空间，让不同类型的信息能被模型 “统一理解”（如将图像和文本转化为可计算的向量，且语义相关的向量距离更近）。

拓展：token?

在自然语言处理（NLP）和大语言模型（如 GPT、LLaMA 等）中，token 是模型理解和处理文本的基本单位，简单说就是 “模型能读懂的最小语言片段”。它不是固定对应单词或字符，而是根据语言规律和模型设计被拆分的片段。

为什么需要 token？

人类通过 “单词”“汉字” 理解语言，但模型无法直接处理原始文本，必须先将文本拆分成更小的、可计算的单元（token），再转化为数字向量进行运算。token 的存在让模型能高效处理不同长度、不同语言的文本。

token 具体是什么样子？

• 英语中：可能是一个完整单词（如 “hello”）、词根词缀（如 “un-”“happiness” 拆成 “happi”“ness”），甚至是标点符号（如 “,”“!”）。
  例：“I’m happy today!” 可能被拆分为 [“I”, “'m”, “happy”, “today”, “!”] 5 个 token。
• 中文中：通常是单个汉字或短词（因为中文没有空格分隔，模型会按语义拆分）。
  例：“我很开心” 可能被拆分为 [“我”, “很”, “开心”] 3 个 token。
• 特殊字符：空格、换行符等也可能被算作独立 token。

token 的关键作用

1. 文本量化：将无法直接计算的文本转化为模型可处理的 “数字序列”（每个 token 对应一个唯一编号，再映射为向量）。
2. 长度限制：大语言模型的 “上下文窗口”（能处理的最大文本量）通常以 token 为单位（如 GPT-4 支持 128k token），超过限制需截断或拆分文本。
3. 成本关联：调用 API 时（如 OpenAI），输入和输出的 token 数量直接影响费用（按 token 计费）。

如何估算 token 数量？

• 英语：1 个 token 约等于 4 个字符，或 0.75 个单词（粗略估算：1000 单词≈1300 token）。
• 中文：1 个 token 约等于 1-2 个汉字（1000 汉字≈700-1000 token）。
• 工具辅助：可使用 OpenAI 的 Tokenizer 工具、Hugging Face 的transformers库等直接计算文本的 token 数。

总结

token 是模型处理文本的 “最小语言积木”，它将连续的文本拆分成可计算的片段，是模型理解、生成语言的基础。理解 token 有助于合理控制文本长度、预估模型性能和使用成本，尤其在长文本处理（如文档分析、多轮对话）中至关重要。

---

1. 窗口函数是 SQL 中一种强大的数据分析工具，它能在不改变原始数据行数的情况下，对一组行（称为 “窗口”）进行计算并返回结果，核心价值在于在同一条记录中同时获取基础数据和聚合分析结果，避免了传统聚合函数（如 SUM、AVG）使用 GROUP BY 时对数据的压缩. ↩︎

2. 语义层(Semantic Layer) 是位于数据存储与用户应用之间的 ‘‘翻译官’’, 它用业务人员能理解的语言(如"销售额" “客户转化率” ) 包装复杂的数据逻辑(如表关联/计算规则) , 让非技术人员也能轻松查询和分析数据. ↩︎

3. Fine-Tune（微调） 是机器学习中的一种重要技术，它通过用少量特定领域的数据 “校准” 预训练模型，让模型在特定任务（如医疗影像诊断、法律文书分析）上表现更好。简单来说，就是让 “通用 AI” 变得 “更专业”。 ↩︎

4. Prompt（提示词） 是用户输入给 AI 模型的指令、问题或文本，本质是 “告诉 AI 该做什么” 的沟通方式。它不仅是简单的提问，更能通过设计引导 AI 生成符合需求的输出 —— 比如让 ChatGPT 写一首诗，或让 DALL・E 画一只 “会飞的猪”，这些指令都是 Prompt. ↩︎

5. 知识召回指的是从大规模的知识存储（如数据库、文档库、知识图谱等）中，搜寻并获取与用户查询或当前任务相关信息的过程. ↩︎

6. Plan-Do-Check-Act是一种适配 AI 项目全生命周期的持续优化方法论，核心是通过 “计划 - 执行 - 检查 - 处理” 的循环，解决 AI 模型开发、部署及应用中的不确定性，推动模型效果、安全性和实用性的螺旋式提升. ↩︎

7. Embedding Model（嵌入模型） 是将文本、图像、音频等非结构化数据，转化为计算机可理解的低维稠密向量的工具。 ↩︎