背景概述
参加了一次某大厂能源管理产品的线上推介分享会，但是关于算法推荐架构这部分分享嘉宾细节基本没讲就宏观的概括了一下，ppt上也只占了三分之一的大小，看回放的时候感觉还是有些内容的。自己简单用processon临摹了一下，有些看不清的内容也人肉补全了。
本文主要分析一下这个某大厂的整体暖通智控产品的实现逻辑和方法。
技术架构概述
整个算法架构两部分组成
实时推理部分：基于实时采集的数据和预设的配置及发布的算法进行快速的最优控制参数求解并下发命令或推送建议。
离线训练部分：包含模型的对象，分类，以及模型评价指标等，以及与线上模型迭代的衔接。
1）离线训练
【EDA：探索性数据分析】
Exploratory Data Analysis，名字太专业了，其实也是我经常干的一些事没想到说法这么高级。
通过数据可视化工具Excel或bi或spss进行原始数据或指标数据进行分析判断，察觉里面一些相关性和异常特点或者规律，还有很多高级统计的工具和方法可以进行一些降维处理。
Seq2Seq ：是一种循环神经网络的变种，自然语言处理中的一种重要模型，可以用于机器翻译、对话系统、自动文摘。最直接的就是在钉钉和腾讯会议的自动会议纪要系统中抽取的摘要和关键词场景。
Nbeats：实现能让模型的分解具有可解释性的时间序列预测。
XGBoost：是大规模并行boosting tree的工具，它是目前最快最好的开源提升树 boosting tree工具包，比常见的工具包快10倍以上。
Prophet的方法是将时间序列看成是关于t的一个函数，用拟合函数曲线的方法进行预测，所以这和传统的时间序列模型有本质上的区别，他更倾向于机器学习的建模方式
3)设备和管道模型
管道模型写得比较含糊，二次侧模型应该是对应的扬程或者压力相关的预测。
天气预测单独拿出来了，应该是把下雨，风速等相关影响冷塔效率的关键要素也追加进去了。
上面两条在分析的过程中又发现自己完全多想了。
原来第一排的模型名字，只是分类而已，所以并没有天气风俗降雨量那些模型
二次侧模型基本就是完整的制冷量模型的基础指标数据了，并没有包含水力平衡要素。还是属于比较基础模型。
4)小结
模型的迭代和离线训练都是直接从tsdb获取数据，按理说飞浆这么强大的ai工程平台应该会做一些更高级的大数据技术栈的离线处理方式，可能还是因为单独建筑暖通项目部署的时候还是到达不了“大数据”的程度。
整体来看离线训练部分的模型对象还是比较常规，没太多亮点和特色信息。
1)数据范围
主要两部分，一个是实时采集数据包括天气和设备物接入时序类数据，第二部分是静态约束数据包括预设的边界条件还有设备层级，其实就是设备之间的逻辑链路关系
时序数据存在tsdb，配置信息在mysql，确实连技术栈都这么基础，不像百度的基因。
2)相似日计算
应该是包含了负载相似日+环境相似日+模式相似日。
直接通过相似日就能直接获取到“候选解”，这部分有些跳跃，但根据候选解再进入到冷冻单元模型，二次侧模型即可以判断整个流程中是通过相似日迅速定位到哪些日子的控制参数的专家经验控制值，然后拿着这些候选操作方式去计算冷冻单元的完整耗电量，再通过管路侧的模型，计算出来完整的制冷量。
有了以上两个预测出来的核心指标再进行排序，逻辑很简单，满足制冷量的，能耗最优的控制参数，就是最终需要的“最优解输出”
3)小结
用一种比较取巧“相似日”计算的方式（XGBoost应该就是在这应用了）来减少后面对于模型服务的计算消耗，因为直接基于天气进行控制参数遍历势必会消耗非常多的算力和时间。过去的相同状态控制策略中，最节能的那一种就是整个寻优工程里面的最优解。
那跑不掉了，这家大厂使用的面向独立项目的全黑箱模型，基于历史操控经验，去取历史最优的控制策略当最优解，对过往的专家控制经验依赖极大。但确实也是当下最直接高效能见效的方式。所以这种单个项目也远远谈不上“大数据”也用不上那么强大的“飞浆”工程化底座了。
热门跟贴