今天是2025年8月13日，星期三，北京，晴
我们继续看RAG方向，这次集中在问数这个场景。
讲几个方案，一个是Demo级大模型问数开源项目SQLBot实现解析，看看实现细节。另一个是再看TableRAG的几个思路，看看真多文档中的表格，怎么做RAG，连同之前讲过的，温故而知新。
多总结，多归纳，多从底层实现分析，会有收获。
一、Demo级大模型问数开源项目SQLBot实现解析
大模型问数开源工作，chatbi开源项目进展，https://dataease.cn/sqlbot/v1/，https://github.com/dataease/SQLBot，打的旗号是结合RAG，那么，我们来从代码角度出发，看看到底怎么实现的？
先说具体结论，SQLBot这个RAG做SQL的项目，贡献在于一个轻量化的流程，以及一堆prompt。思路设计还不错。但性能全靠prompt，效果会处于demo环节，理论上会比vanna,opentex2sql好一些，完备一些。适合做demo。但做生产，还会很大差距。
我们拆开来看。
1、SQLBot用RAG做SQL的流程
流程分成四步骤；
1）问题接收处理
用户通过聊天界面提交问题，系统通过/chat/question接口接收请求。
2）数据源选择与模式检索
选择合适的数据源，并获取数据库模式信息作为检索的知识库，数据源选择主要通过LLMService.select_datasource()执行。
首先，获取可用数据源列表
首先根据用户类型获取数据源列表。普通用户从当前工作空间（oid）获取数据源，助手模式通过外部API获取数据源。
如果有多个数据源，系统使用LLM进行选择，使用包含数据源信息的提示词，让LLM根据用户问题选择最合适的数据源，选择数据源后，系统进行配置。
其次，模式检索，分四个step。
step1:获取数据库模式，根据数据源类型，通过不同方式获取数据库模式，普通数据源使用get_table_schema()函数；助手数据源通过AssistantOutDs.get_db_schema()获取
step2:获取表结构，使用数据库特定的SQL查询来发现表结构，支持的数据库类型包括MySQL(查询information_schema.TABLES)；PostgreSQL(查询pg_class和pg_namespace)；Oracle(查询DBA_TABLES和DBA_VIEWS)；SQLServer(查询INFORMATION_SCHEMA和系统表)
step3:获取字段信息，每种数据库都有特定的字段查询逻辑，获取字段名、类型和注释信息-
step4:模式格式化，获取的数据库模式会被格式化为标准的M-Schema格式，用于后续的SQL生成
3）SQL生成。这里会使用系统使用预定义的模板来格式化提示词。
2、其他几个关注的细节
其一，上下文过长的问题，对历史对话消息有明确的数量限制。在LLMService中设置了base_message_count_limit=5，用于限制历史消息的数量。在初始化消息时，会截取最近的几条历史记录：使用last_sql_messages[count_limit:]来限制历史消息的数量。在语法格式上，使用了M-Schema格式来表示数据库模式，格式相对简洁。
其二，多表查询的问题，SQLBot在处理涉及多表查询的用户问题时，会保留和使用多个表。流程是：通过select_datasource()选择数据源后，会获取该数据源下所有已配置的表->调用get_table_schema()函数来获取完整的数据库模式，这个函数会包含数据源中所有已选择的表->获取的多表模式信息会被格式化为M-Schema格式，包含所有表的结构信息，这个完整的多表模式会作为系统提示词的一部分传递给LLM->在SQL生成过程中，LLM根据用户问题和提供的多表模式信息，自动识别需要使用的表，并在返回的JSON中包含所用到的表名。
此外，另一种解决方式，也下放到前端环节，如前端表选择界面，用户在配置数据源时可以选择多个表，支持最多30个表的选择。前端提供了完整的多表选择界面，包括搜索、批量选择等功能。如果是用户自己选择多表，多表查询的逻辑就变成：数据源配置阶段：用户选择需要包含的多个表-》查询处理阶段：系统将所有已选择表的模式信息提供给LLM->SQL生成阶段：LLM根据用户问题自动选择需要的表进行查询->执行阶段：系统基于生成的SQL中实际使用的表进行权限检查和执行。
其三，安全性问题，表信息的后续处理上，生成的SQL会被解析，提取其中使用的表名，这些表名会用于后续的权限过滤和动态SQL处理。
其四，里面的BI可视化部分，通过给定的问题和SQL生成JSON以进行数据可视化，也是靠prompt提示llm，涉及到不同的表，可视化组件。
其五，关于sql问题的推荐部分，也依靠设定prompt来做，如：您的任务是根据给定的表结构，用户问题以及以往用户提问，推测用户接下来可能提问的1-4个问题，也是通过llm提示。
其六，其他功能，都是清一色prompt。如数据分析师，根据给定的数据分析数据，并给出分析结果。一个数据分析师，根据给定的数据进行数据预测，我将以JSON格式给你一组数据，预测之后的数据（一段可以展示趋势的数据，至少2个周期），用json数组的格式返回，返回的格式需要与传入的数据格式保持一致。
二、再看TableRAG的几个思路
既然说到要做问数，就会自然的涉及到TableRAG的工作，所以，可以看几个工作，结合之前讲到的。
1、《表格RAG可以怎么做？推理大模型存在“心口不一”？》https://mp.weixin.qq.com/s/cT4q7Fz6QW6fUIX927b5Gg，里面讲到两个工作：
1）《TableRAG: Million-Token Table Understanding with Language Models》(https://arxiv.org/pdf/2410.04739)，核心思想是通过结合查询扩展、模式检索和单元格检索来提高表格理解的效率。
2）《GTR: Graph-Table-RAG for Cross-Table Question Answering》，https://arxiv.org/pdf/2504.01346，主要思想是提了一个方案，将表格语料库重组为异质超图并采用多层次检索过程，增强跨表格问答任务的性能。
2、《表格RAG项目解读：一个过滤+澄清补充的数据工程式思路》(https://mp.weixin.qq.com/s/ZwEj2Kc9Le1uOi1E7EVXJw)，在https://github.com/YuhangWuAI/tablerag，解决的问题是从大量表中检索相关表。思路有点怪，输入用户query，先做大表过滤，拿到过滤结果后再补充额外特征信息，然后组织后送LLM生成，设计其实不是很合理，速度会很慢
3、《TableRAG: A Retrieval Augmented Generation Framework for Heterogeneous Document Reasoning》(https://arxiv.org/pdf/2506.10380，https://github.com/yxh-y/TableRAG/tree/main)
因为表格具有行列 interdependency（相互依赖），而文本是序列性的，二者融合推理难度大，将表格线性化为文本（如 Markdown）并分块，破坏表格固有结构，导致信息丢失。
所以，主要思路是采用混合（SQL 执行和文本检索）框架，统一文本理解和对表格数据的复杂操作，通过上下文敏感的查询分解、文本检索、SQL 编程与执行以及组合式中间答案生成这四个步骤进行迭代操作。
看下思路：
1）离线建库阶段
从异构文档中提取表格（D）和文本（T），将表格转换为Markdown格式，并与文本一起分块，嵌入为向量构建文本知识库。
然后，构建表格schema数据库，用标准化模板描述每个表格的结构（表名、列名、类型、示例），并建立分块与原表格schema的映射，确保分块与整体结构关联，最终将表格存入MySQL，支持后续SQL执行。
2）在线迭代推理阶段
包括四步核心流程。
step1，上下文敏感查询分解，识别查询中需要文本或表格处理的部分，结合检索到的表格schema生成子查询（q_t），需理解数据结构而非仅语法分割；
step2，文本检索。向量召回将子查询与文本/表格分块的向量计算余弦相似度，取Top-N候选，然后语义重排序：用更精细的相关性模型筛选Top-K结果。
step3，SQL编程与执行。 若检索结果含表格分块，通过映射获取对应schema，调用LLM生成SQL并在MySQL中执行，得到结果（e_t），相比Python更高效处理大规模数据和复杂计算，确保符号执行的精确性。
step4，组合式中间答案生成。融合SQL执行结果（e_t）与文本检索结果，交叉验证一致性，根据可靠性加权生成子查询答案（a_t），迭代至无新子查询，输出最终答案（A=a_T）。
