admin

  • 标题:腾讯云PG支持SQL调用大模型;达梦24年营收超10亿;PolarDB大会发布TPCC登顶;

    重点更新

    2月26日,PolarDB开发者大会上,阿里云宣布PolarDB登顶全球数据库性能及性价比排行榜,刷新TPC-C性能和性价比双榜的世界纪录。[1]

    达梦发布2024年报,全年营收[2]达10.4亿,同比增长31.49%;利润总额为3.8亿,同比增长24.06%。[2]

    腾讯云 PostgreSQL 支持通过 SQL 调用大模型 API(混元),实现如自然语言对话、文本转向量、文本排序等功能。[62]

    更新详情

    火山云(字节)
    • 云数据库 MySQL 支持了主节点过载保护功能、Sequence Engine、最大存储扩大为 6T 存储空间[64][65][66]
    • 云数据库 PostgresqL 新增 pg_hint_plan 插件
    • 云数据库 SQL Server 版提供了 SSL(Secure Sockets Layer)加密能力 [37]
    • 支持为实例创建跨地域的灾备实例,为实例提供跨地域的灾备能力 [39]
    • 在临时升配实例时,支持变更实例的规格类型 [40]
    • 云数据库 SQL Server 版提供审计功能 [41]
    • 在创建 TOS 备份恢复时,支持按照新的数据库名称恢复数据 [42]
    腾讯云
    • 云数据库 PostgreSQL 支持大版本为17的实例通过 SQL 调用大模型 API。使您的业务使用大模型能力更加便捷。[62]
    • TDSQL-C MySQL 版5.7内核版本更新2.1.13.002:支持二级缓存功能。[57]
    • TDSQL-C MySQL 版8.0内核版本更新3.1.15.005:在只读实例上 binlog 支持了2种订阅方式:基于 file_name 和 pos 的位点方式;基于时间戳的方式。[58]
    • TDSQL-C MySQL 版通用型计算规格新增支持了中国香港、弗吉尼亚地域。[56]
    阿里云
    • RDS MySQL 8.0 新增支持强制SSL加密功能,兼容MySQL直连方式。[4]
    • RDS MySQL倚天版新增开服地域德国(法兰克福)与美国(硅谷)。[5]
    • 数据库代理读写分离支持设置一致性级别:最终一致性、会话一致性和全局一致性。[6]
    • RDS MySQL高可用本地盘实例存储空间最大支持8000 GB。[7]
    Azure(微软云)
    • Azure Database for PostgreSQL 支持的最新 PostgreSQL 次要版本 [13]
    • Azure Cosmos DB 新增 Rust SDK [14]
    GCP(谷歌云)
    • alloydb_scann 扩展已更新,增强了向量搜索相关的能力 [18]
    • Bigtable 的自动备份功能正式发布 (GA)[21]
    • AlloyDB 集群支持执行就地主要版本升级 [25] [26]
    • Cloud SQL 实例支持在删除前创建数据的最终备份 [27]
    Oracle云
    • 支持将数据库恢复到特定的 SCN [31]
    • 支持从最新备份克隆数据库[32]
    • HeatWave新增支持版本 9.2.1 版本 [36]
    华为云
    • GeminiDB Influx新增集群增强版,进行了架构优化和调整,支持更大的集群规模,更高的读写性能,适用于更大规模的业务场景
    AWS(亚马逊云)
    • RDS for Oracle 支持空间信息补丁包 [43]
    • RDS 支持 MariaDB 11.4.5、10.11.11、10.6.21 和 10.5.28 [44]
    • RDS 支持 CloudWatch Database Insights [45]
    • RDS for PostgreSQL 支持次要版本 17.4、16.8、15.12、14.17、13.20 [54]
    • 您现在可以使用中国银联信用卡创建 AWS 账户 [55]

    参考链接

  • “六国都为秦所并,读史的人,往往以为一入战国,而秦即最强,这是错误的”

    《中国通史-春秋战国的竞争和秦国的统一》 吕思勉

    战国七雄都对得起“雄”字,在不同的时期都曾经雄霸一方,在战国早期,很多国家都强于当时的秦国。其中,在三家灭智分晋之后,魏斯正式被册封为侯,是为魏文侯。之后,魏文侯、魏武侯、魏惠王三代通过用贤良、施变法,魏国变得非常强大,通过“逢泽之会”称王。这期间,魏国任用了“魏成子、翟璜、李悝、乐羊、吴起、西门豹”等人。而,由吴起为主要将领,与秦国之间长达数年的河西之战中,屡次破秦,尽取秦国的河西地区,成就魏国一时的霸业。这里就来系统的看看战国早期的秦魏之间的长达数十年的河西之战。也借此可以更深入的体会一下,吕思勉所说的“往往以为一入战国,而秦即最强,这是错误的”。

    “秦魏”的地理位置

    我们可以通过如下两幅地图,可以大致了解秦魏的地缘关系。下右图,高度经过“夸张”,可以更好的反应出,两国的地形关系。秦国核心土地处于秦岭以北、黄土高坡以南,东北方向的出路是魏、赵两国。东出函谷关则需要经过韩魏两国(苏辙《六国论》)。秦魏两国之间,“黄河”可以认为是较为天然的分界线。

    河西之战的前中期

    河西之战 (战国)”就是发生在黄河以西,由当时最为强大的“魏国”主动挑起,经过多长战争,最终占领了黄河以西大量原本属于秦国的土地,并在这里设置了“西河郡”,由魏国军队主将“吴起”任首任郡守。主要的战役的发生地点和时间如下所示,此阶段,魏国胜多败少:

    具体的战役详情:

    • 前419年,魏军突然在河西地区筑城池,秦国派兵进攻,交战两年。前417年,魏军击败秦军。
    • 前413年,魏国大举进攻秦国,魏国李悝在郑县大败秦军。次年,魏文侯派太子击包围并占领了秦国的繁庞
    • 前409年,魏文侯任命吴起为主将,攻克秦国临晋、元里并筑城。次年,吴起攻打秦国至郑县,攻克洛阴、郃阳。

    至此,魏国全部占有原本属于秦国的河西地区,并在此设立西河郡。吴起担任首任郡守。

    河西之战的中后期

    在中期,秦国虽多次战争尝试收付河西地区,均未成功。在前389年的阴晋之战,最为有代表性。当时,秦惠公出兵号称五十万进攻魏国的阴晋,被吴起以步兵五万、战车五百辆、骑兵三千所击败。

    在战争的后期,魏惠王称王,迁都大梁。同时,秦国重用商鞅,逐渐强盛。河西之势也开始发生了变化。最终,在经过吴城之战魏国便逐渐势弱。在前330年,秦军再攻魏国上郡,大胜,最终收付了全部河西地区。

    具体的:

    • 前361年,魏惠王迁都大梁,魏国的战争中心转向了宋、卫、韩、赵等国。之后在元里、安邑、固阳都发生过争夺战,双方互有来回。
    • 而在前340年,吴城之战,魏国被秦商鞅击败
    • 前330年,秦军再攻魏国上郡,此役魏国防卫西河、上郡的主力全军覆没,主将龙贾被俘,魏惠王被迫于次年将西河郡全部献给秦国。至此,秦全部收复了被魏夺占的河西地区。

    魏国的强盛与衰落

    早期在三家灭智分晋之后,魏文侯、魏武侯两代人用贤良、施变法使得魏国非常强大。期间最为有代表性的人物包括李悝、吴起、西门豹等。其中李悝变法使国家强盛富足、吴起攻城略地,使得魏国声名大噪,而西门豹善治水…哦,上了小学语文课本。

    不合时宜的称王与“东扩”

    魏惠王不合时宜的称王与“东扩”,现在来看,是有违天时与地利的。在魏国最为强大时候,魏惠文王决定迁都,并秦国在游说之下称王。但此时,河西之地并未真正稳固,原本地处边陲的秦国,经过历代图治与变法(“秦国之强起于献公而成于孝公”),变得非常强大。在魏国东扩的时候,西边被秦国完全打败。不仅河西土地尽失,就连原本的旧都安邑也被占领。

    不合时宜的称王与“东扩”为后续魏国的衰落埋下种子。

    用人失误

    而后期,将相不和,魏惠王受谗言弃用吴起,也使得河西守势变弱。关于这一点,公孙痤在后来取得某次战役胜利的时候,依旧是非常认可吴起的功劳的,可见吴起之于魏国的重要。而忽视卫鞅,并任由其前往秦国,则更是此消彼长。

    再观秦国

    而秦国经过数代君王努力,最终不仅取回河西,并继续攻下河东,包括原魏国国都(安邑)。同时,拿下了东出函谷关的要到,以及部分“关东“的土地,为后续东出函谷关,一统六国做好了准备。

    最后

    这场战争来看,任用贤才、实施变法改革,使得国盛民强,是战争胜利的基础。利用地形、政策等巩固战果,才能够考虑进一步拓展疆域。通观全国之势,当时魏国虽然强大,但还不具备统一的实力,此时称王,反而成为众矢之的,而关中之地此时有没有守住,最终导致魏国衰落。

  • 标题:PolarDB大会下周三北京举行;TiDB社区活动下周六深圳举行

    重要更新

    2025 阿里云PolarDB开发者大会将于 2月26日(星期三)在北京嘉瑞文化中心举行,届时将有院士郑纬民、阿里云李飞飞、米哈游、雅迪、飞鹤等分享,感兴趣的可以现场参加。[1]

    下周六(3月1日),3.1 TiDB 社区活动深圳站举办,主题为:大规模 TiDB 国产化替代与成本优化在金融、跨境电商等行业的最新实践。感兴趣的可以现场参加。[2]

    更新详情

    腾讯云
    • 云数据库 MySQL 8.0内核版本更新20241001。[25]
    • 云数据库 PostgreSQL 支持11及以上大版本的实例开启和关闭 SSL 连接加密功能。[26]
    • 云数据库 PostgreSQL 支持在周备份计划的基础上迭代按月备份计划。[27]
    • 云数据库 PostgreSQL 支持查看所执行的任务详情,方便您了解对实例进行操作的任务进度。[28]
    火山云(字节)
    • Redis 新增支持取消事件类型为用户操作的计划内事件 [30]
    • Redis 新增支持导出分析大 Key 分析结果 [32]
    • MongoDB 新增支持对实例 Oplog 保留窗(也称 Oplog 可用时间)进行事件监控告警[37]
    • 优化了 MongoDB 账号密码校验功能,禁止使用极易被破解的弱密码[39]
    阿里云
    • RDS SQL Server 2022、2019、2016 发布新的内核小版本 [29]
    • RDS SQL Server新增存储过程sp_rds_update_db_stats,您可以更灵活高效地从采样率、并行度、超时时间及阈值百分比多维度更新数据库统计信息。[4]
    GCP(谷歌云)
    • Cloud SQL Enterprise Plus 版本的 SQL Server 实例支持完整的时间点恢复 (PITR) [8]
    • 高级查询洞察、索引顾问、主动的Query监控GA支持了 AlloyDB for PostgreSQL [9]
    • 当复制时间落后于预定义的时间长度时,Cloud SQL for MySQL 支持重建副本。[12]
    AWS(亚马逊云)
    • Aurora PostgreSQL 零 ETL 集成支持更多区域 [13]
    • Amazon RDS 支持 MySQL 8.4.4 和 MySQL 8.0.41[14]
    • Timestream for InfluxDB 增加了读取副本支持 [19]
    • RDS for PostgreSQL 支持次要版本 17.3、16.7、15.11、14.16、13.19 [23]
    • Amazon Q 生成 SQL 现已在更多区域推出[24]

    参考链接

  • 在不同的云厂商,购买相同规格的MySQL实例(如4vCPU-16GB),获得的性能相同吗?

    本次测试中,极限性能(512并发下的QPS)表现如上图:腾讯云性能最好,达3.6万;其次是阿里云2.7万,相比于上一次测试的4.0万性能下降比较明显;其次是华为、AWS、百度,再次是Azure、Google云和Oracle云。更多详细数据参考如下。

    Sysbench QPS 详细数据

    dataaliyunawsazurebaidugooglehuaweioracletencent
    457892183151720171915247630325868
    8871643352964382234154546504610518
    161437382725489697560718472783916903
    322013215377911111910858214384771723484
    4823026178621143915330964118667774726802
    6424990199471262318316987721269788930054
    96269542246113578205351042322137852935131
    128269242320014057214811068221394823036199
    192265862330914484214271120322040795836259
    256259332339614640218271141322847743835743
    384272092292414638214521155224148769035747
    512276622277814674214051135024079719636052

    Latency (Event) 详细数据

    如下表格分别为:平均延迟 和 95%延迟数据。单位为:毫秒/ms。

    dataaliyunawsazurebaidugooglehuaweioracletencent
    412.4432.9847.4535.7037.6029.0823.7412.27
    816.5233.2248.5837.6842.1631.6728.5413.69
    1620.0434.8152.4641.2947.4333.9936.7417.04
    3228.6137.4563.2148.3667.1140.0474.6324.53
    4837.5248.3775.5256.3589.6146.28111.5232.23
    6446.1057.7591.2562.89116.6154.16146.0038.33
    9664.1176.92127.2584.14165.7678.04202.5649.18
    12885.5799.30163.88107.25215.61107.68279.9063.64
    192129.99148.24238.56161.27308.43156.77434.1295.30
    256177.67196.91314.68211.08403.63201.61619.30128.89
    384254.00301.39472.05322.16598.09286.09898.19193.28
    512333.11404.42627.82430.45811.55382.501279.61255.51
    dataaliyunawsazurebaidugooglehuaweioracletencent
    418.9536.2455.8241.1047.4737.5636.8914.73
    825.7436.2457.8744.9861.0839.6546.6317.01
    1629.1941.1062.1950.1187.5641.8566.8421.89
    3244.1745.7978.6062.19147.6149.21121.0831.94
    4866.8459.9995.8177.19204.1156.84200.4741.85
    6486.0071.83121.0890.78219.3668.05267.4149.21
    96116.80101.13183.21125.52272.27123.28325.9862.19
    128147.61142.39248.83164.45331.91150.29442.7377.19
    192219.36211.60376.49227.40450.77231.53634.66116.80
    256282.25272.27511.33292.60569.67320.171376.60158.63
    384376.49411.96802.05427.07831.46539.712449.36253.35
    512484.44549.521109.09559.501129.24549.523982.86369.77

    MySQL 参数对比表格

    dataaliyunawsazurebaidugooglehuaweioracletencent
    have_sslDISABLEDYESYESDISABLEDYESDISABLEDYESDISABLED
    innodb_buffer_pool_size9.75GB11GB12GB12GB11GB9GB17GB12GB
    innodb_doublewriteONOFFOFFONONONONON
    innodb_flush_log_at_trx_commit11111111
    innodb_flush_methodO_DIRECTO_DIRECTfsyncfsyncO_DIRECTO_DIRECTO_DIRECTO_DIRECT
    innodb_io_capacity200002002002000500012000125020000
    innodb_read_io_threads44NA84424
    innodb_write_io_threads44NA84444
    log_binONOFFONONONONONON
    performance_schemaOFFOFFONOFFONOFFONOFF
    rpl_semi_sync_master_enabledONNANAONNAONNAON
    rpl_semi_sync_master_timeout1000NANA10000NA10000NA10000
    sync_binlog11110001111
    thread_pool_size8NA4NANANA164
    version8.0.368.0.398.0.39-azure8.0.32-2.0.0.28.0.31-google8.0.28-2310038.0.40-u3-cloud8.0.30-txsql
    cpu_capacity100.9106.972.773.449.4163.1101.1118.4

    云数据库的 MySQL 8.4 版本

    目前,主流版本依旧还是8.0。在2024年04月,最新发布了 8.4 版本,该版本将是下一个稳定版(LTS版),所以也有部分云厂商开始这次该版本。目前,发布了 MySQL 8.4的云厂商有Amazon、Google云和Oracle云。这里也对8.4版本的性能做了测试,并对比如下:

    各云厂商详细测试数据

    关于各个云厂商更多的详细测试数据可以参考如下专题页面:

    更多参考

  • 标题:PolarDB for AI 内置支持多种机器学习算法模型、NL2SQL等能力; 华为云新增Redis 7.0支持

    重要更新

    2025 阿里云PolarDB开发者大会将于 2月26日(星期三)在北京举行,感兴趣的可以现场参加[1]

    更新详情

    阿里云

    • PolarDB for AI 发布,内置支持多种机器学习算法模型、NL2SQL等能力 [3][4]
    GCP(谷歌云)
    • Spanner 自定义组织策略(Custom organization policies)正式发布[8]
    火山云(字节)
    • veDB MySQL 新增规格 2 核 8GiB、支持为账号和数据库设置描述信息等更新 [13][15]
    • veDB MySQL 优化了对使用 Hint 语法指定的节点不存在或发生故障时的报错信息 [19]
    AWS(亚马逊云)
    • Amazon RDS for SQL Server 支持新的小版本[21]
    • Aurora PostgreSQL 支持在 Amazon CloudWatch 查看锁争用诊断 [23]
    • Amazon DocumentDB(兼容 MongoDB)支持在 AWS Toolkit for Visual Studio Code 中操作[28]
    腾讯云
    • 云数据库 MySQL、TDSQL-C MySQL 只读分析引擎发布了新的版本 1.2404.21.0。[29][30]

    华为云

    • DCS for Redis 新增支持 Redis 7.0实例[2]

    参考链接

  • 在2015年,由 OpenAI 的 DP Kingma 等发布了 《ADAM: A METHOD FOR STOCHASTIC OPTIMIZATION》算法后,由于其迭代效率提升非常明显,所以 ADAM(或其变种)就被广泛的采用。本文将继续对上一篇介绍的梯度下降算法进行优化,并介绍 ADAM 算法(一种对随机梯度下降算法的优化算法)的实现以及效果。

    Stochastic Gradient Descent 或者说 mini-batch解决了样本量巨大时,梯度下降迭代的问题。但是,也带了一些新的问题。最为主要的是,因为样本数据的波动,而导致每次梯度下降计算时,梯度方向的波动,从而降低了梯度下降迭代的效率。

    在前面的《Mini-batch Gradient Descent和随机梯度下降(SGD)》文章中,我们对比了 mini-batch 和 batch gradient descent 的在迭代时,目标函数下降的速度。

    可以看到,batch gradient descent 的目标函数下降非常稳定,而 Mini-batch 的实现则会有明显的波动。为了尝试修正这个问题,从而提高迭代效率,在神经网络算法上,逐渐探索出了一些较为高效的优化算法:Adam SGD。该算法将 RMSprop 和 “Exponential smoothing”的想法结合在一起,形成了一个较为高效的算法,在实践中被广为使用。


    Stochastic Gradient Descent 与 Momentum

    SGD 会在每次迭代时根据样本的偏差,展现出不同的偏差,所以,在使用SGD进行迭代时,观察其 cost函数下降,应该会有更加明显的波动(后续吧自己实现的程序改造后,尝试观察一下)。

    为了加快迭代的速度,一个折中的思路是,引入一个均值替换当前的梯度方向。该如何引入这个均值呢?梯度是一个随时计算推进,不断推进的变量,常用的均值计算可以参考:Moving average。最为常见的实现是使用“Exponential moving average”,这种平均值的计算,在迭代计算时实现非常简单。

    Momentum 就是 “Exponential moving average”实现时的参数“smoothing factor”,在神经网络中,经常使用 \( \beta \)表示(原因是 \( \alpha \) 已经表示学习率了 )。

    而这里的 Momentum ,也是 TensorFlow 在构造 SGD 算法时需要的另一个参数。

    关于Exponential moving average

    或者叫“Exponential smoothing”。我们看看这个算法的具体实现是怎样的?

    原始的迭代:\( w = w – \alpha \frac{\partial J}{\partial w} \)

    使用 “Exponential smoothing” 后的迭代:

    $$
    \begin{align}
    v_0 & = 0 \quad \partial{w}_t = \frac{\partial J}{\partial w}|_{(for \, sample \, t)} \\
    v_{t} & = \beta*v_{t-1} + (1-\beta)\partial{w}_{t} \\
    w & := w – \alpha v_t
    \end{align}
    $$

    考虑 \( \beta = 0.9 \),如果数学直觉比较好的话,可以看出,原本使用梯度\( \partial{w} \)进行迭代的,这里使用了一个梯度的“Exponential smoothing” \( v_t \)去替代。上面的式子中,\( v_t \) 如果展开有如下表达式:

    $$
    \begin{align}
    v_t & = (1-\beta)\partial{w}_{t} + \beta(1-\beta)\partial{w}_{t-1} + \beta^2(1-\beta)\partial{w}_{t-2} … \\
    & = \sum\limits_{i=0}^{t} \beta^{i}(1-\beta)\partial{w}_{i}
    \end{align}
    $$

    使用“Exponential smoothing” 之后,新的迭代方向 \( v_t \),可以理解为一个前面所有梯度方向的加权平均。离得越近的梯度,权重越高,例如,\( \partial{w}_{t} \)的权重是\( (1-\beta) \);而之前的梯度,则每次乘以一个 \( \beta \)衰减。

    Exponential moving average的“冷启动问题”与修正

    仔细观测上诉的 “Exponential moving average” 公式,可以注意到一个问题,就是其最初的几个点总是会偏小。其原因是,当前值的权重总是为 \( 1- \beta \),而因为是初始的几个值,并没有更前面的数据去“平均”当前值,也就会出现,初始值总是会偏小的问题。

    通常,如果样本量很大的事时候,则可以忽略这个问题,因为初始值偏小的点占比会非常少,可以忽略。如果要一定程度上解决这个问题,也有继续对上述的 “Exponential moving average”做了一些修正,可以考虑对 \( v_t \)的结果值做一个修正:\( v_t := \frac{vt}{1-\beta^t} \)。

    一般的,因为样本的数量总是比较大的,所以我们可以忽略这个问题,而无需做任何修正。

    RMSprop

    在前面的“Gradient Descent with Momentum”中,我们看到为了解决梯度波动较大的问题,使用了 “Exponential moving average” 去尝试将一些比较偏的梯度,拉倒一个较为平均的方向上来。RMSprop的想法也是类似的,这里通过了root mean square的想法进行平均值的计算。具体的,在进行 SGD 时,每次更新梯度,按照如下的方法进行更新:

    $$
    \begin{align}
    s_0 & = 0 \quad \partial{w}_t = \frac{\partial J}{\partial w}|_{(for \, sample \, t)} \\
    s_{t} & = \beta*s_{t-1} + (1-\beta)(\partial{w}_{t})^2 \\
    w & := w – \alpha \frac{\partial w}{\sqrt{s_{t}}}
    \end{align}
    $$

    说明:这里对梯度进行平方时,如果在程序中是一个梯度向量,那么这里“平方”也就是对梯度的每一个分量进行一次平方。

    在“Exponential smoothing”的实现中,是将当前值,使用一个加权平均替代。与“Exponential smoothing”类似的,原本的梯度方向,现在使用如下的方向去替代了:

    $$
    \begin{align}
    s_t & = \frac{\partial{w}_{t}}{\sqrt{(1-\beta)(\partial{w}_{t})^2 + \beta(1-\beta)(\partial{w}_{t-1})^2 + \beta^2(1-\beta)(\partial{w}_{t-2})^2 + \cdots }} \\
    & = \frac{\partial{w}_{t}}{\sqrt{\sum\limits_{i=1}^{t}\beta^i(1-\beta)(\partial{w}_{i})^2}} \\
    \end{align}
    $$

    Adam Gradient Descent

    这可能是实际使用最多的算法,全称是 Adaptive Moment Estimation 。该实现,将 “Momentum” 和 “RMSprop” 做了一定的融合,形成了新的“最佳实践” Adam。在融合上,具体的实现与两个细节点:

    (1) 在 Adam 中均使用了“修正”计算,即 \( \hat{v_t} = \frac{v_t}{1-(\beta_1)^t} \quad \hat{s_t} = \frac{s_t}{1-(\beta_1)^t} \)

    (2) 参数更新公式,使用了两个算法的融合: \( w := w – \alpha \frac{\hat{v_t}}{\sqrt{\hat{s_t}}} \)

    Adam optimization的效果对比

    在 Adam 的论文中对于效果做了非常多的评估,感兴趣的可以参考相关论文。

    这里根据之前完成的训练程序,也进行了优化,实现了Adam算法。在 MNIST 数据集的训练上,我们来看看 Adam 的效果:

    从右图可以看到,Adam(蓝色)明显的提升了迭代效率。依旧一定程度存在 mini-batch(绿色) 的梯度波动的问题。相比于,batch gradient descent (红色)算法,迭代效率大大增加,约在第10次迭代,即在第一个epoch 的第十批样本进行训练时,cost 就下降到了比较低的程度。

    关于 root mean square

    root mean square也叫二次平均值,考虑一组数据:\( {x_1,x_2, \cdots , x_n } \),其RMS则为:

    $$ x_{rms} = \sqrt{\frac{1}{n} \sum_{i=1}^n x_i^2} = \sqrt{\frac{1}{n} (x_1^2 + x_2^2 + \cdots + x_n^2)} $$

    补充说明

    可以看到,所有的这些优化都是面向“最优化”问题的。梯度下降是一个一阶优化(First-order Optimization)的方法,其核心就在与每次迭代时,应该如何去更新响应的参数值,在梯度下降中也就是如何去选择合适的学习率。

    牛顿法是典型的二阶优化(Second-order Optimization),在迭代时使用了二阶导数,所以,通常可以获得更好的迭代效率。但是因为二阶导数的计算复杂度会上升非常多(对应的矩阵可能是所有参数的平方,应该也有人尝试去算过了…)。这也是为什么在这个场景下,依旧是使用一阶优化方法的原因。

    如果想比较好的理解学习率、Momentum、RMSprop、Adam等内容,建议先了解梯度、数值方法、最优化问题等数学方法。

    到这里这个系列算是一个小阶段了,这是一个个人学习的笔记,从数学的梯度概念开始,逐步到神经网络训练的Adam优化算法,也包含部分动手实践的神经网络算法实现。完成的系列包括了: