AI 篇二：RAG、Text-to-SQL 与只读数据分析

AI 端要回答 IIoT 项目里的问题，不能只靠模型记忆。项目规则、术语、接口边界、上传语义和部署配置都在本地代码与文档里；生产归档、设备、配方、产能、日志又在结构化数据库里。RAG 和 Text-to-SQL 解决的是两类不同信息来源。

RAG 面向文档和知识库，回答“规则是什么、某个模块为什么这样拆、术语是什么意思”。Text-to-SQL 面向业务数据库，回答“某台设备最近产能是多少、某个配方版本关联哪些记录、某段时间有哪些过站数据”。两者都属于查询和分析，不等于修改业务系统。

这张图展示的是 RAG 和数据分析的分工。RAG 提供规则依据，Text-to-SQL 提供数据结果，最终合成时需要同时说明规则口径和数据口径。这样才能避免只给一个看起来像答案的句子，却说不清依据来自哪里。

RAG 处理项目资料

当前 AICopilot.Core.Rag 里有 KnowledgeBase、Document、DocumentChunk、EmbeddingModel 等聚合。知识库绑定 embedding model，文档进入知识库后经历解析、切分、向量化、索引等状态。DocumentStatus 中可以看到 Pending、Parsing、Splitting、Embedding、Indexed、Failed 这些状态。

AppHost 中引入了 Qdrant 资源，RagWorker 负责后台索引相关工作。HttpApi 暴露 RagController，服务层有 AICopilot.RagService。这些代码说明 RAG 不是临时把文件塞进 prompt，而是有知识库、文档、切片、向量库和后台 worker 的完整链路。

RAG 对 IIoT 项目的意义在于保持业务语义可追溯。设备身份、ClientCode、DeviceId、bootstrap、Cloud/MES 双链路、配方版本、插件约定，这些内容都来自当前代码和规则文档。AI 回答这些问题时，需要先从知识库拿到依据，再组织解释。

Text-to-SQL 处理结构化数据

结构化数据不能靠 RAG 解决。产能、日志、过站、配方记录和设备状态是数据库里的表和字段，需要用数据分析链路查询。AICopilot.Core.DataAnalysis 中有 BusinessDatabase 聚合，记录数据库名称、连接信息、provider 类型和 IsReadOnly。DbProviderType 支持 PostgreSQL、SQL Server、MySQL。

这个模型说明数据分析从设计上就需要区分数据源和权限。业务数据库可以被注册、启用或禁用，也可以标记为只读。对于 IIoT 场景，Text-to-SQL 应优先作为只读分析能力，用来查询和解释，不直接改生产数据。

只读边界来自业务风险

制造数据不是普通报表数据。设备、配方、产能、过站和日志都有业务含义。一个错误更新可能影响归档一致性、设备追溯和现场排障。Text-to-SQL 用来分析可以提高效率，但写入动作要进入更严格的业务接口或审批链路。

BusinessDatabase 默认构造参数里有 isReadOnly = true，并提供 UpdateSettings(bool isEnabled, bool isReadOnly)。这个设计适合把数据分析限定在只读语义下。即使后续开放写操作，也需要明确数据源、权限、审批和审计，而不是让模型直接拼接修改语句。

RAG 和 Text-to-SQL 需要合并结果

IIoT 项目里的很多问题同时需要规则和数据。例如：

• 查询某台设备产能异常，需要知道设备 DeviceId 归档规则，也需要查产能记录。
• 解释某批数据为什么没有进入云端，需要知道 Cloud 上传门禁和本地补偿规则，也需要查诊断或上传记录。
• 判断某个配方版本是否仍在使用，需要知道配方版本状态流转，也需要查关联生产记录。

RAG 负责告诉系统“规则怎么说”，Text-to-SQL 负责告诉系统“数据怎么显示”。两个结果合并时，需要保留各自来源。这样输出才不会把规则解释和数据事实混在一起。

和管理中台的数据关系

管理中台是产能、日志、过站和生产数据的归档中心。AI 的 Text-to-SQL 能力可以接入这类业务数据库做分析，但它不是管理中台的替代入口。正式业务变更仍然通过管理中台 API、权限和领域规则完成；AI 只做查询、解释和辅助分析。

RAG 让规则可查，Text-to-SQL 让数据可问。两者组合后，AICopilot 才能回答既有业务背景又有数据依据的问题。

两类信息来源必须分清

项目资料和业务数据库不是同一种东西。业务规则、术语字典、跨项目对齐规则、插件约定和部署说明适合进入 RAG；设备、配方、产能、日志和过站记录适合走结构化查询。RAG 能解释规则来源，Text-to-SQL 能回答数据结果，两者合起来才适合 IIoT 场景。

如果只靠 RAG，系统会知道规则，但不知道当前数据库里实际发生了什么；如果只靠 SQL，系统能查出数字，却可能不知道这些数字应该按什么业务口径解释。AICopilot 需要把这两类结果合并，而不是让其中一类代替另一类。

只读分析是默认安全边界

Text-to-SQL 在制造系统里不能默认开放写入。设备身份、配方版本、产能归档和过站数据都不是普通临时表，错误更新会影响追溯和现场排障。当前 BusinessDatabase 带有只读开关，测试里也有 SQL guardrail 和只读分析相关用例，这些都指向同一个边界：先允许查询和解释，不让模型直接改生产数据。

后续如果要开放写动作，应该走明确的业务接口、权限和审批，不应该让模型直接生成 update/delete。这样 RAG 和 Text-to-SQL 才能作为分析能力进入系统，而不是变成绕过管理中台规则的侧门。

回答要带上规则口径和数据口径

例如排查某台设备产能下降，RAG 可以说明历史产能以管理中台为准、本地只保当天运行态；Text-to-SQL 可以查这台设备在某段时间的产能记录。最终结果应该同时说明数据来自哪个归档口径、查询条件是什么、规则如何解释，而不是只给一个结论。

这种输出方式对项目复盘也有价值。它让 AI 的回答能回到资料、代码和数据，而不是靠模型记忆给出听起来合理的判断。

为什么不能只靠一个大模型

IIoT 项目里的问题通常既有规则，又有数据。只靠模型记忆，规则可能过期；只靠数据库查询，结果没有业务解释。RAG 和 Text-to-SQL 分开，就是为了让答案同时有资料依据和数据依据。

例如设备删除问题，RAG 需要找到“存在配方、产能、日志、生产或过站数据依赖时禁止删除”的规则；Text-to-SQL 可以检查这台设备是否存在相关记录。两个结果合并后，才知道是规则禁止、数据存在，还是只是需要进一步查询。

这个结构也方便后续扩展。新增业务文档进入知识库，新增归档表进入数据分析元数据，两条链路各自更新。AI 输出时再把规则口径和数据口径合成，不让模型凭空补业务结论。