这一篇博客，原本不在我的计划内。

作为一个经常折腾技术、以分享学习经历为乐的程序员，一直以来，我的博客里全是代码、配置和那些冷冰冰的技术笔记，几乎从不聊任何感性的东西。关于张雪峰老师去世的消息，起初我只在博客的说说页面里发了两段文字以表示遗憾，以为这只是又一个公众人物的离去，以为几天后我的遗憾感就会随着时间而淡去。但随后的几天，事情的发展超出了我的想象。我看到了那场空前绝后的互联网追思，无数素昧平生的学子、家长们自发地为他点起烛火；我更看到了遗体告别仪式那天，百姓自发齐聚、十里长街相送的震撼场景。

这种巨大的社会共鸣像一记重锤一样击中了我的内心。随着时间的推移，这种后劲远比我想象中要大，即便已经过了快一个礼拜，这种淡淡的悲伤感不仅没有消散，反而演变成了一种类似于“失去挚友”的钝痛。我意识到，能让万千普通人如此自发地悲恸，绝不仅仅是因为他教了几个志愿填报的技巧，而是他触动了某些关于理想、功利与初心的底层逻辑。

于是，我决定写下这篇博客——这是我的第一篇非技术文章。

我一直自认为算是一个“理想主义者”，在做事时我总会带有某种“精神洁癖”，执着于去做那些我真正热爱、认为有价值的事，而尽可能规避掉很多我认为毫无意义的世俗任务——比起去钻研那些怎么多水几篇论文、怎么把简历包装得滴水不漏的投机技巧，老老实实做点真正有用的东西才更让我愉悦。又或者，在遇到他人发自真心地求助某个技术难题时，我经常会不计成本地扎进去为他解答困惑，甚至比做自己的事还上心（也因此经常被女朋友数落）。甚至在面对一些所谓的“职场生存法则”或“人情世故”时，我也有种近乎幼稚的固执：我总觉得靠本事吃饭才是最体面的，而不愿意去钻研那些复杂的社会关系，或者为了所谓的“前途”去迎合某种自己并不认可的秩序。

这种近乎奢侈的执拗，很大程度上得益于我较为优渥的家庭出身，它给了我足够的容错率去谈论热爱与情怀。我可以在深夜为一个优雅的想法而兴奋，是因为我暂时不需要在清晨为了碎银几两去计算每一分钟的产出。（十分巧合的是，我所热爱的计算机专业，恰好也是当下就业市场里的最优解，这让我的“清高”显得更加顺理成章）。

相比之下，张雪峰的言论在很多人眼中是极端的“世俗功利主义”——他主张普通家庭的孩子在专业选择上必须以就业为强导向。在某些“精英”看来，这似乎是在抹杀孩子们的梦想，是在把人工具化。但我虽身处一个高容错的环境，却极度认可他的绝大部分观点。

因为我清醒地意识到，对于大多数普通家庭的孩子来说，社会的试错成本高得离谱。我眼中的“热爱”与“理想”，对他们而言可能是一场赌上全家积蓄的豪赌。一步选错，可能不仅是三五年的蹉跎，更是几代人努力积攒下的上升通道被瞬间关闭。在那种连“生存”都还带着紧绷感的现实面前，一味劝人空谈理想和个人爱好，而不去考虑如何在这个弱肉强食的社会里先“活下来”，其实是一种极其傲慢且不负责任的行为。

张雪峰那些听起来扎心、甚至带点“钱味儿”的大实话，撕开了温情的面纱。他不是在推崇功利，而是在面对那个试错成本极高的系统时，给那些没伞的孩子在大雨里撑开了一把最实在的伞。这把伞虽然看起来并不华丽，甚至有些笨重，但它真的能遮雨。

面对这样一个极具争议的人物，自然少不了批评的声音。

有人说，他贩卖了社会的焦虑，加速了内卷，甚至破坏了原本微妙的就业平衡。

但在我看来，这种指责多少有点本末倒置。焦虑从来不是因为张雪峰才产生的，它一直像深海里的暗流，真实地存在于每一个普通家庭的餐桌前。 他所做的，不过是利用互联网这个扩音器，把那些原本只流通于所谓“精英阶层”内部的信息差，用最糙、最直白的方式同步给了广大的普通人。

如果放任这种信息不对称，让普通孩子在温水煮青蛙的幻觉里耗尽家里的底气，让畸形的教育体系和就业环境在低效率的空转中透支社会的未来，那才叫真正的残忍。

用我所熟知的专业知识来解释，这本质上是一场最终目标是阶层破局与生存策略、环境参数（政策 / 就业）时刻在动态变化的 “强化学习”。

在一个奖励函数极度不可见、且环境参数实时波动的黑盒系统中，普通家庭的孩子往往在进行盲目的随机探索，或是在信息茧房里追求基于兴趣爱好的局部最优解。

而张雪峰的存在，就像是在这个系统中提出了一个基于全局先验知识的启发式搜索策略。他通过拆解潜规则，寻找那些被精英阶层隐藏、却能显著提升生存概率的“最优路径”。这种过程，实际上构成了系统自我完善的正向对抗反馈：当一方通过寻找最优解打破了旧有的信息垄断，原本傲慢且迟钝的系统为了维持某种动态平衡，就不得不被迫加速自我迭代，让规则走向透明。

一般而言，想要改良一个庞大且僵化的系统，往往有两种路径：一种是自上而下、难度极高的系统重构；另一种则是像他这样，作为“外部扰动”不断提出对抗性的最优解，倒逼系统进化。

也许他个人的初衷并没有带着某种救世式的伟大，但他的行为对社会改良的客观价值在我看来是积极的。他让规则不再是少数人的黑箱，他让“普通”二字在算法的博弈中，终于有了一份可以收敛的胜率。

至于说社会变“卷”，那本质上是资源分配和评价体系的问题。如果一个社会已经险恶到让大部分普通家庭的孩子连追求理想的入场券都拿不到，那么提前告诉他们真相、教他们如何避坑，不仅没有错，反而是一种极大的慈悲。在这个系统里，盲目的乐观才是最廉价的毒药。

还有人揪着他的商人身份不放，觉得他服务卖得贵，吃相难看。

作为在浙江这个具有浓厚商业氛围的省份长大的人，我反而觉得这种指责挺幼稚的。服务收费天经地义，何况这一行的市场行情价格本就不低。作为行业顶流，如果他的定价不设门槛，那涌入的需求量足以瞬间瘫痪他的整个团队。

更何况，他并没有把路堵死。只要你愿意花点时间，在他的直播间里完全可以“白嫖”到相当有价值的信息。而更让我动容的，则是他在赚到钱之后做的事：他给那些真正负担不起的贫困家庭提供免费咨询，甚至直接资助学费。相比那些通过捐款来合理避税、以此换取社会名望的企业家，张雪峰的善意显得极其“笨拙”且纯粹。除了那些挂在明面上的希望工程、教育资助项目，他更多的是在做那种“不见光”的善事。他嫌通过机构走流程太慢、中间环节太杂，干脆直接加微信、走支付宝打钱。这种私下的资助，不做任何公关宣传，甚至连张像样的通稿都懒得发。

从流传出来的聊天截图里可以看到，他的关心甚至细碎到了家长的一日三餐。面对患病的家长，他不由分说地转账五千块，嘴里说着最地道的“大实话”：“这钱你先拿着，买点营养品……东北话，别撕吧。我也没多给，大事解决不了，吃穿用没问题。”

这些话里没有居高临下的施舍，只有一种平等的、带温情的体谅。在任何一个精明的商人眼里，这种“投入产出比”极低、甚至连慈善名号都挂不上的杂事，完全没必要浪费时间去做。但他却像个捡拾幸存者的独行侠，在大众所看不见的角落里，一件件地做着。这种带点草莽气息的侠气，在当下的资本环境下，其实已经纯粹得有些过分了。

或许有人会觉得奇怪，我一个平时只关心技术，甚至带点“精神洁癖”的理想主义者，为什么会对一个满口“就业、赚钱、避坑”的世俗老师产生如此强烈的共鸣？甚至在这些天里，感受到一种不亚于失去好友的钝痛？

起初我也在反思这种情绪的来源，后来我才意识到，我和他其实是在同一套“底层逻辑”下运行。

我追求技术的纯粹，厌恶“水论文”和投机取巧，是因为我希望这个世界能像代码一样逻辑清晰、奖惩公平；而张雪峰教人钻营功利、拆解社会潜规则，是因为他深知这个世界的运行规则对普通人有多残酷，他想用最直白的“生存算法”，为那些没伞的孩子换一张通往理想的入场券。

他教人功利，是为了让人有资格不功利；他谈论金钱，是为了让人未来不必只为了金钱而活。

这种“知行合一”的慈悲，在我看到他对待员工和家长的那些细节时，彻底击穿了我最后的心理防线。我突然意识到，这个被贴上“功利”标签的人，其实活成了我眼中最纯粹、最硬核的理想主义的样子。

这件事的起因其实非常微不足道：张雪峰在公司群里看到员工随口提到喜欢魏大勋，这原本只是一句转瞬即逝的闲聊，但他悄悄记在了心里。后来，他私下联系魏大勋本人要来了几张签名照。当他像个“拿到糖的孩子”一样，得意地举着照片走进办公室送给员工时，所有人都惊呆了。两位员工甚至激动得冲上前抱住了他，而他只是被逗得满脸笑容，像个下班回家给自家孩子带了心仪已久的礼物的老父亲。

看着这些截图，我甚至能隔着屏幕、隔着时间和空间感受到张雪峰在那一刻的快乐。

我太熟悉这种感觉了——那种不计回报地耗费大量时间，为一个素昧平生的网友排查到 Bug 后的快感；又或者在偶然听说他人遇到技术困难、而那刚好涉及我的专业领域时，我会按捺不住兴奋地和对方讨论，甚至恨不得把自己的所有专业想法都灌输给他。当最终得到对方一句“这个方案可行”的评价时，那种精神上的充盈感，远比账户里多出几百块钱要厚实得多。

张雪峰这种真实感，简直让我感触太深。他送出签名照时那种得意地晃晃照片、笑得像个“拿到糖的孩子”一样的神态，根本不是什么高高在上的一个老板的恩赐。那是一个人发现了别人的微小愿望，并动用自己的能力精准实现了它之后，获得的一种极其纯粹、极其“理想主义”的满足感。

在任何一个精明的商人眼中，这种事压根就没有产出比。但他却乐此不疲，甚至在处理这些琐事时，比谈成一桩大生意还要兴奋。这种“不被功利逻辑异化”的真实，在这个处处讲究回报的时代，纯粹得甚至有些刺眼。

如果说送签名照还带点对某种微小愿望的执着与痴迷，那是一种极其私人、甚至有点“不务正业”的快乐，那么他对员工生活的那种细碎操心，则彻底撕碎了那些关于“商人必无良”的刻板印象。

看着这几张流传出来的聊天截图，我看到了一个把“家人观”践行到极致的真实人格：在七夕节催着全员提早下班去接老婆、对象；员工报喜生了娃，二话不说转账 6666 元。

甚至在员工家人感染新冠、生命垂危、全网一药难求的至暗时刻，他二话不说，将自己仅剩的、用来压箱底的救命药直接匀出一大半，只为让员工能开车送去上海救人。当员工家人脱离险境、想要转账 8000 元以示感谢时，他又一次云淡风轻地拒收了，只留下那句最直白最暖心的回应：“大可不必，我弄这个药就不是为了挣钱。你们都是我的家人，只要大家平安。”

而最让我感到震撼的，其实不是这些，而是这几张截图里透出来的、那种在普通职场环境里极难见到的聊天氛围。在很多人的印象里，公司工作群或是机械的“收到”，或是战战兢兢的汇报，甚至连一个表情包都要反复斟酌。但在这张截图里，那种流动的气息完全不同——那是一种极其松弛的家人感。这种氛围不是靠无聊的团建“团”出来的，也不是靠“狼性文化”逼出来的，而是一个老板在无数次“不计产出”的善意里，一点点喂出来的信任。在群里，大家不需要小心翼翼地敲出“收到”，而是可以毫无顾虑地在老板面前发一些表情包。

还有公司的福利，这我就更不用说了：

引用站外地址，不保证站点的可用性和安全性

盘点那些让人羡慕嫉妒恨的神仙公司——峰学蔚来

知乎

这还只是冰山一角，更细节的福利可以从网上内部员工的一些评论中窥知一二。我随便列举几条：

• 每月额外3天小长假
• 入职满2年：苏州购房无息借款（金额 = 个人年薪）
• 入职满3年：深造学费报销50%
• 生育奖励：一胎2万、二胎4万、三胎8万（很多公司可是反感员工生育的）
• 年度体检、子女教育补贴、宠物福利
• 提前为员工预存半年工资

我突然明白，为什么他的员工会自发地在群里喊出那些听起来甚至有些“肉麻”的口号，为什么在那个工作群聊中的聊天氛围会如此松弛。他是在这片充满了 996 和职场 PUA 的荒原上，凭空为普通人造出了一个“理想主义的避风港”。

除了那些硬核的福利和侠气的捐赠，最让社会大众动容的，其实是他在实现阶级跨越后，依然活得像个再普通不过的平凡人。

在这个崇尚“赢者通吃”的商业环境里，我见过太多寒门出身的老板，在实现阶级跨越后，反而成了最冷酷的压榨者。他们往往带着一种“我当年也是这么苦过来的”的逻辑，加倍地在员工身上索取，试图通过剥削后来者来补偿自己曾经缺失的安全感。

但张雪峰不同。他属于那种典型的“因为自己淋过大雨，所以总想给别人撑一把伞”的人。

他深知普通家庭的孩子在苏州这种城市扎根有多难，所以他提供购房无息贷款；他知道底层父母供出一个大学生有多不易，所以他给员工预存了足量工资，以提升公司遇到危机时员工的抗风险冗余度。

他虽然已经实现了阶级跨越，却从未在精神上剪断过与“土地”的连接，始终活得像个再普通不过的平凡人，与大众没有任何距离感。在这个稍微有点成就就恨不得香车美女、保镖随行的环境下，他却显得极其“违和”：他会像千千万万个普通的中国父亲一样，骑着那辆有些简陋的电动车，穿梭在苏州的街头接送女儿上下学（我直接爆哭好吗😭）；他会在除夕、元宵节等节日自费买来绚烂的烟花，不是为了某种商业站台，而只是单纯想在这个略显沉重的时代，放给路过的、素昧平生的百姓们看。

这种“不被异化”的真实，才是最可贵的。

他明明早已拿到了通往所谓的“上流阶级”的入场券，却始终愿意把脚踩在泥土里。这种“知行合一”的平民底色，解释了为什么他离去时，会有万千普通人自发地为他点起烛火。他不仅是在教人如何“往上爬”，更是在用他自己的生活方式告诉我们：一个人即便飞得再高，也可以不丢掉那份对普通生活的热爱，不丢掉对平凡大众的悲悯。

写到这里，我终于明白了这几天我心中的意难平究竟是什么，也找到了那个困扰我许久的 Bug 的解法。

我所伤感的，不再仅仅是一个志愿填报专家的离去，而是一个“在功利世界里，依然守住了人味儿”的鲜活样本的缺失。这种“人味儿”，不仅仅是那种爱开玩笑、不摆架子的“活人感”，而是一种近乎执拗的“人性”底色。

在商业丛林的生存法则里，大多数人一旦跨越了阶级，逻辑就会自动发生重构：他们会开始拥抱那一套高高在上的精英主义，把员工看作报表上的人力成本，把受众看作待收割的数据流量。但在张雪峰身上，我看到了一种罕见的、从未被异化的人性。

这种人性，是他即便拿到了通往社会顶层的入场券，却依然能精准感知到泥土里每一个普通家庭的痛点——他知道寒门学子试错成本的沉重，所以他甚至不惜用略显冒犯的直白去拆解规则；他知道普通员工在异乡扎根的无助，所以他提供购房贷款、预存工资，甚至细碎到关心一张签名照、一份七夕的惊喜。他最珍贵的地方在于，他在追求世俗意义上的“赢”的过程中，从未以献祭“人性”为代价。 他没有把自己活成一个冰冷的、精密计算的赚钱机器。相反，他赚来的每一分钱，似乎都成了他守护人性中那点温情的防御工事。

曾经有很多听说「我这个有着“精神洁癖”的程序员以后要创业」这件事的人对我说：“别太天真，这个世界的运行法则是冷酷的，有良心的人当不了老板。”这句话一度像一个无法跳出的死循环，横在我的面前，让我对未来产生了一种隐隐的恐惧：是不是想要获得世俗意义上的成功，就必须献祭掉自己的初心？必须变得精算、利己、且高高在上？

但张雪峰老师用他短暂而绚烂的一生，硬生生地跑通了这个 Demo。

他让我看到，即便是在最讲究存活率、最现实、最功利的商业丛林里，善良与成功不仅不互斥，甚至可以互为底色。他不是因为成功了才去施舍，他是带着那种质朴的、哪怕已经跨越阶级也从未熄灭的“草根血性”，在冰冷的规则里杀出了一条温情的路。

他用行动告诉我们：一个人即便飞得再高，也可以不丢掉对平凡生活的热爱，不丢掉对淋雨者的悲悯。

屏幕里的他，肉眼可见的疲态，戴着黑色半框眼镜框，微微向前探身，就像之前无数次退出直播间之前的那样笃定地对镜头说：“我们晚上7点直播间再见啊。”

可这一次，峰哥，你失约了😭😭😭。

七点钟的那个直播间，再也不会亮起那束熟悉的光。那些你尚未讲完的理想，那些你还没来得及送上岸的孩子，那些你曾想给普通家庭撑起的伞…最终都成了这个春天最深沉的意难平。

他走了，那个始终保留着一份赤子之心的人，走了，留下了这把笨重却无比结实的伞。

他走得太行色匆匆，留下了一张还没来得及兑现的蓝图，和无数双望向远方的眼睛。

但他在冰冷的规则里杀出的那条温情的路，不该就此断绝；

他在极端的功利中守住的那份人性的底色，不准就此抹去；

他亲手验证过的这段关于“良知与成功并存”的逻辑，更不能就此成为绝唱！

这把伞既然有人撑起过，就证明这雨天里，本就可以有伞；

这条路既然有人走通过，就证明这荒原上，本就可以有路！

尹山湖的烟花绚烂璀璨，如你的人生，虽行至中途便戛然而止，却在那段极为有限的时间里，迸发出了最耀眼的光芒。那是你燃尽了自己，为无数寒门学子在迷茫中点燃的信号弹。这漫天的火树银花，是群众为你最后的告别，也是最沉甸甸的认可。

在漫天烟火中（虽只是在屏幕前刷到，却也足够震撼，有朝一日，我也要去一次那个地方，补一场烟火），突然想起你曾经常半开玩笑式地对大家说过的那句话：“人生真好玩，下辈子还来。”

峰哥，这一次，可别再失约了。

丙午马年的春节之前，我跑了趟杭州，约了两个在杭州的朋友去雀庄打了两把立直麻将。其中一位朋友是个日麻小白，为了帮助他快速习得基础玩法，我发给了他一个很早以前做的网页：雀魂役种一览。

都说到这了，就顺便讲下那天的麻将趣事（一点也不有趣）吧。下面场景在同一个半庄出现两次：

还是同一个半庄，我亲位：

然后我幸运地铳了：w立、七对、d2，一把万二大牌，喜提第二（不是哥们你w立七对叫我怎么防？？？）。

我决定以后打雀再也不坐新手的上家了…

正题

说回正题，我发现我乱糊的网页版似乎没有那么方便（因为当时懒得写前端，选了一个使用websocket通信的懒人框架），一段时间不看它就得刷新重连，体验非常不好。正好这段时间我在捣鼓微信小程序，遂想着要不做个小程序吧，也更易于推广给别人用。

说干就干，在vibe coding的加持下，很快我就把已有的功能全部移植了过去。接下来还能搞点什么呢？作为一个科学麻将爱好者，我想到了牌效分析功能，即任给一手牌，要能计算出切各张牌后的进张效率，而这个功能的底层逻辑则是需要能精确地计算出一手牌的向听数。

N向听（Nシャンテン，N-ready），指的是手牌距离听牌仍需N枚有效牌。如果一手牌还需1枚有效牌才能达致听牌，则称为1向听（イーシャンテン，1-ready），如此类推。
麻将维基：向听数

很早以前我曾写过麻将和牌判断算法，一般而言，判断一手牌是否和牌有两种方法：DFS和打表法。当时我都实现了一遍。对于经常需要检查是否和牌的场景，通过DFS枚举手牌拆分方法会显得迟钝，于是这种场景得考虑给和牌型打个表。那么对于向听数的计算而言，是否有类似的算法呢？有的兄弟，有的！

向听数算法

方便起见，我们先考虑14张牌的情形。立直麻将共有三种和牌形状，其中最常见的「$mAAA+(4-m)ABC+DD$」型，被称为一般型，另外还有七对和国士无双型，后两者的向听数非常容易计算，可以直接略过，唯一需要注意的是立直麻将的七对子牌型不允许出现两个相同的对子，因此计算时需要做一些额外的处理。

我们主要来考虑一般型的向听数。根据向听数的定义，我们可以额外定义「0向听」表示听牌、「-1向听」为和牌。

启发式的思考过程

那么如何计算向听数呢？首先我们来思考一下人类玩家自己是怎么算的。不妨从和牌型倒着推算：

1. 一手已经组成四个面子和一个雀头的牌，是-1向听。
2. 将其中一个面子换成一个搭子+一个孤张，则显而易见，这手牌的向听数+1。
3. 将其中一个面子换成三个孤张，则向听数+2（其中两个孤张需要替换为第三个孤张的靠张才能形成面子）。
4. 如果把雀头换为两张不同的牌，则在组合中没有其他对子的情况下，需要额外替换一张牌形成雀头，此时向听数需要再加1。
5. 一手牌最多只需要4组面子+搭子的组合，因此对于搭子数而言，应设置其上限为4-面子数。

根据上面naive的思考，似乎一个完美的算法已经形成了：

对于一手牌的某种拆分方法，记其中的面子数为 $m$，搭子数为 $d$，雀头数为 $q, q\in\left\lbrace0、1\right\rbrace$，可以计算出向听数 $s$ 如下：

随便找几组牌测试看看：

好像看起来没什么问题。容易发现，对于一手牌而言，其拆分方法可能有很多种，我们需要对它进行不同的拆分，得到上述参数后分别计算向听数，并取其最小值，才能得到最终的向听数。

特殊情形

偶然间发现这样一手牌：

我们按上面向听数的计算公式，得到：

计算结果为1向听，但这一手牌移除3组面子和一个雀头后，剩下的三个孤张「东南西」，没有一张能摸成搭子，故这手牌理应是2向听。

这种特殊情况的存在使得原先的算法需要进行一定程度的调整，经过一番搜索，我找到了这篇文章：

引用站外地址，不保证站点的可用性和安全性

麻将向听数的计算与编程实现

www.bilibili.com

最终的算法

愚钝的我研读了一下上面这篇文章后，感到醍醐灌顶，于是在这里记录一下对这个调整后的算法的理解。

首先，定义一个概念： 爆满，是指手牌中数量已经达到4张的牌的状态。

我们发现前面提到的特殊情形正是由于爆满的存在而产生的。更不巧的是，这里爆满的牌是三种字牌，而字牌不能形成顺子，这才导致向听数的计算公式产生了bug。

为应对这些复杂的情况，文章作者提出了一些新的参数。

• G3：面子（顺子或刻子）的总数。

• G2：搭子（差一张牌就能变成面子）的总数（不能是脏搭子）。

• DG2：脏搭子（组成搭子的两张牌都处于爆满状态）的数量。

• P：雀头的数量，只能是0或1。

• DN：脏数牌（孤立的数牌，并处于爆满状态）的数量。

• DZ：脏字牌（孤立的字牌，并处于爆满状态）的数量。

• R：剩余的牌的数量。

• N：手牌的数量，取值为2、5、8、11、14。

• K：K=(N-2)/3，需要做出的面子的数量，取值为0、1、2、3、4。

  下面是算法对应的部分代码：

s = -1R = N - 3 * G3 - 2 * (G2 + DG2 + P) - DN - DZK = N // 3

先对部分参数进行初始化，s代表向听数，从和牌型开始计算，逐步往上加，因此初始化为-1，R表示未形成面子、搭子、雀头，但也未处于爆满状态的牌的数量。

接下来的一段代码，将处理搭子溢出：

if G3 + G2 + DG2 > K:    t = K - G3 - DG2    if t <= 0:        R += 2 * G2        DN -= 2 * t    else:        R += 2 * t    G2 = K - G3else:    G2 += DG2

逻辑是：当面子+搭子的总数超过K时，溢出的搭子必须被拆为孤张，由于孤张的脏牌对向听数优化的贡献较低，这里可以贪心一下，优先拆普通搭子。普通搭子拆完以后，继续拆脏搭子。同时这一步将更新剩余孤张数R以及脏数牌的数量DN。

接下来处理雀头：

if P == 0:    if R > 0:        if DZ > 0:            R -= 1            DZ -= 1        elif DN > 0:            R -= 1            DN -= 1        else:            R -= 2        s += 1    else:        if DZ > 0:            if DZ >= 2:                DZ -= 2            else:                DZ -= 1                DN -= 1        else:            DN -= 2        s += 2

当没有雀头时，我们至少需要额外一个进张来形成雀头，这会导致向听数+1。不过，根据剩余牌的类型，又能分为几类情况。

首先只有非脏牌的孤张牌才能形成雀头，这要求R > 0，此时，我们可以直接用其中的某张孤牌来做雀头；否则，手上所有孤立牌都处于爆满状态，已经摸不成雀头了，故至少需要再进两张牌才能凑一个雀头出来。这两种情况分别对应了上面代码中的 s += 1以及s += 2。

既然进来了新的牌凑成了雀头，我们当然得打掉对应数量的牌，按牌的利用价值，我们优先打走脏字牌，其次是脏数牌。最后才会打走孤张非脏牌。

接下来，函数进行收尾：

R += DNDZ -= G2 + 2 * Rif DZ > 0:    s += DZ // 3

这部分似乎不大好理解。不如通过刚刚的那手牌来看看是怎么回事。

对于上面这手牌，最优的参数组合是：G3 = 3, G2 = 0, DG2 = 0, P = 1, DN = 0, DZ = 3。另外我们可以计算得到 K = 4, R = 0。

DZ -= G2 + 2 * R这一步意味着我们希望在组面子的过程中消耗掉一些脏字牌。上面这手牌中，G2和R均为0，因此最后会剩余3张脏字牌。如果是三个普通的孤张，相比于一个面子而言，会“贡献”两向听，这一部分已经体现在 $s=2\times(4-m)-\max(d,4-m)-q$ 这个公式里了（每3张散牌的存在会减少一个面子），但如果三个孤张都是脏字牌——无法成搭，那么我们还需要额外的一次换牌，将其中一张脏字牌替换成普通的孤张，才能顺利组成面子，因此还需要额外+1。

这也是最后这行代码s += DZ // 3所做的事。

在进行了以上调整后，函数计算向听数：return 2 * (K - G3) - G2 + s，这个公式本质上和前面那个naive的公式是一样的。

综上，这个函数相当于对数量达到4张的牌做了更完善的处理。

3n+1型的向听数计算

上面这个函数只适用于3n+2型的向听数计算，应用到3n+1型需要做一些修改。除了 s 初值修改为0外，还需要修改一下对 P 和 DZ的处理代码。不过思路是差不多的。

打表

编码

字牌和数牌行为存在差异，因此我将字牌和数牌分别进行了编码。而三种数牌则是全排列对称的，因此只需要编码一种数牌就行了。

接下来需要定义一个距离。由向听数的计算方法，我们容易得到距离为0、1、2的牌（可以形成面子和搭子）才会影响向听数，3及以上不影响向听数。因此定义距离函数如下：

我们可以将一手同花色的牌编码为枚数序列：s1和距离序列：s2两个序列，需要满足：

1. len(s1) 至多为9（同种花色至多9种，如果是字牌，则为7）
2. s2 的长度为 len(s1) - 1
3. 对于数牌，s2 序列的总和不超过8（$\infty$视为其最小值3）
4. 对于字牌，s2 的元素总为 $\infty$

仅这样做仍有非常大的组合数量，实际上我们还能去重。我们可以通过 $\infty$ 将序列分割为多个子序列，容易发现：

1. 这些子序列任意交换顺序，不影响向听数。
2. 对每个子序列进行倒序排列，不影响向听数。

举两个例子：

示例1：

上面两手牌的枚数序列分别是：

逗号表示子序列的分割符（对应位置有一个距离为 $\infty$​ 的跳跃）。这即为「不同子序列的换序」，这种操作不影响向听数。

示例2：

上面两手牌的枚数序列分别是：

这即为「子序列的倒序」，同样不影响向听数。

我们可以根据这两点，定义一个序列间的偏序关系，从而对每个序列进行标准化。比如，可以定义其偏序关系为依次比较其枚数序列的字典序、其距离序列的字典序。

枚举与DFS

这一部分比较容易理解。

分别枚举各个花色的总枚数，生成其枚数的分拆，对每一种分拆枚举可行的距离序列。

对每一对枚数、距离序列，通过DFS得到所有可行的参数组合，再把四种花色的参数组合起来，调用前面的向听数函数计算得到向听数，取其最小值即为序列的向听数。

囿于篇幅这里省略了相关代码。

由于编码优化的不是很好，最终得到了一个30mb的压缩包（

最后嫖了一个huggingface space，把小程序后端部署起来了。本文相关代码可以在这个space中找到。

欢迎各位立直麻将爱好者使用帮我测试bug

相信很多朋友都听过这个问题，也很清楚答案：

我在一开始把问题想的简单了，我的思考如下：

考虑 $m=2$ 的情形，此时共有两个红眼睛土著，记为 $R_1,R_2$，从他们各自的视角来看，外面均还有一个红眼睛，此时，以 $R_1$ 的视角来看这个场景，由于 $R_1$ 并不知道自己是红还是蓝，因此，在 $R_1$ 看来，外面的 $R_2$：可能并不知道「有红眼睛的人」这件事（如果我 $R_1$ 是蓝的， $R_2$ 可不就是不知道嘛），所以，当探险家喊出那句知识的时候，其实还带给了 $R_1$ 一个额外的信息，即：“现在 $R_2$ 已经知道「有红眼睛的人」这件事了”，那么 $R_1$ 心想：“如果我是蓝眼睛，在 $R_2$ 视角下场上将没有红眼睛，此时 $R_2$ 足够聪明，他会立刻意识到自己是场上唯一一个红眼睛的人，也即 $R_2$ 会在第一天晚上自杀”。

对 $R_2$ 而言，同样如此，因此两人等了一天，发现第一天晚上无事发生。此时足够聪明的二位在第二天同时意识到了自己是红眼睛，因此，他们会在第二天晚上自杀。

接下来，通过数学归纳法，“容易”推导出对一切 $m=k$，有结论： $k$ 个红眼睛会在第 $k$ 天晚上自杀，而剩下的蓝眼睛则会在下一天意识到自己是蓝眼睛，因此会在 $k+1$ 天晚上自杀。

归纳如下，假设结论已经对 $m=k$ 成立，我们来思考 $m=k+1$。

下面是错误证明

对每一个红眼睛土著而言， 外面都能看到 $k$ 个红眼睛土著，那么在他们视角看来，外面的环境满足 $m=k$ 情形 （满足吗？？？），因此他们只需等待 $k$ 天，若外面的 $k$ 人没有在第 $k$ 天晚上自杀，这每个红眼睛土著都会意识到自己是红眼睛，因此会在第 $k+1$ 天晚上自杀。

这个证明显然是错的，因为在这个证明中，除了 $k=2$ 时用到的那个额外信息（每个人都知道有红眼睛的人）之外，没有用到任何其他信息。如果这个证明成立，那么当岛上的红眼睛数量大于2时，即使没有探险家的那句话，这些人也必然会在一定天数后自杀，因为他们不需要探险家的喊话就能意识到“每个人都知道有红眼睛的人”，从而导致连锁反应。

显然探险家的喊话带给人群的信息不止是前面所述内容。

那么 $m=3$ 和 $m=2$ 的区别在哪呢？多了这一个红眼睛的人后，$R_1$ 先天就知道 “$R_2$ 知道「有红眼睛的人」这件事”，因为在 $R_1$ 看来， $R_2$ 的视角下，至少有 $R_3$ 的存在。

此时 $R_1$ 想要站在上帝视角来旁观 $R_2$ 和 $R_3$ 的行为，从而能够根据他俩的行为来推断自己的眼睛颜色，需要满足什么条件呢？

回想之前的 $m=2$ 情形，我们清楚一个结论：如果 $R_1$ 是蓝眼睛，那么当 $R_2$ 知道 “$R_3$ 知道「有红眼睛的人」这件事”时，这个 $m=2$ 状态将会发生坍塌。

那么只要把 $R_1$ 放到我们的位置， $R_1$ 就相当于站在了上帝视角。此时 $R_1$ 相比于之前人群中的 $R_1$ 而言，多获取到了一个知识：$R_2$ 知道 “$R_3$ 知道「有红眼睛的人」这件事”。在这个知识的加持下， $R_1$ 能够确定只要外面的两人在第二天晚上没有自杀，自己必然是红眼睛。同理，这个结论对 $R_2,R_3$ 也成立。

而上面所说的知识显然也可以从探险家的那句喊话中得到。所以，我们就从 $m=2$ 的情形推出了 $m=3$ 的情形。

从前面的思考中，我发现了这个有点像多层嵌套的知识的结构，不如将它称为“多阶知识”。

这个场景下，一阶知识就是探险家喊出的那句话：“你们当中有红眼睛的人！” 提供的直接知识：“有红眼睛的人”，这个一阶知识 （在$m\ge2$时） 显然每个人都知道，探险家正是因为这个原因，以为自己的喊话没有提供额外的信息。但他忽略了喊话行为带来的高阶知识。

这个知识对应的二阶知识是“每个人都知道有红眼睛的人”，三阶知识是“每个人都知道每个人都知道有红眼睛的人”，以此类推。

重新考虑前面的数学归纳过程，同样的，假设结论已经对 $m=k$ 成立，我们重新来思考 $m=k+1$。

对每一个红眼睛土著而言， 外面都能看到 $k$ 个红眼睛土著，那么在他们视角看来，外面的环境差不多可以满足 $m=k$ 情形，只需要一个额外的条件。

显然，$m=k$ 时结论成立，需要这 $k$ 个人同时知道原知识的 $k$ 阶知识：“每个人都知道每个人都知道…每个人都知道有红眼睛的人” （共 $k-1$ 个“每个人都知道”）。

现在我们继续站在 $R_1$ 的视角考虑，外面的 $k$ 个红眼睛如果知道上面的 $k$ 阶知识，就可以从这 $k$ 个人的行为推出自己眼睛的颜色。因此这里 $R_1$ 只要获取一个下面这样的知识，就可以站在上帝视角去观察外界的行为。这个知识即：

而原知识的 $k+1$ 阶知识相当于每个人都知道 $k$ 阶知识，它自然包含了前面 $R_1$ 需要获取的知识。而这个 $k+1$ 阶知识显然也可以从探险家的喊话中推导出。

接下来就和之前一模一样了。

这个问题其实抽象出来了两个概念：共有知识与公共知识，一个群体中，大家都知道的结论被称为共有知识，但如果有一个足够权威的人将这个共有知识公之于众，则它会变成一个公共知识。从这个问题中可以看出，一个公共知识相当于一个无穷高阶的知识，而一个共有知识，仅仅相当于一个一阶知识。

当然，如果群众里面有一个傻子，结论就失效了😊。

引用本站资源，请放心访问

在消费级显卡上部署QwQ-32B模型

逸风亭博客

不过这个模型是一个推理模型（Reasoning model），它面对任何问题都会“陷入沉思”，思考过后之后才给出回答，对于某些需要快速响应但比较简单的任务而言就有点令人不耐烦了，因此，后来我又重新尝试了其他的模型，例如Qwen3-32B，这个模型则是个混合推理模型（Hybrid reasoning model），也就是说这个模型存在两种模式：思考模型与非思考模式，可针对复杂问题启用多步逻辑推理，简单任务则快速响应。

模型部署

这部分总体与上面那篇文章中部署QwQ的过程类似，使用llama_server进行部署，不过为了与Cherry Studio良好适配，我还进行了一些调整。

首先是到处乱抄糊了一个jinja模板，命名为了my-template.jinja

{%- if messages[0].role == 'system' %}    {{- '<|im_start|>system\n' + messages[0].content + '<|im_end|>\n' }}{%- endif %}{%- set ns = namespace(multi_step_tool=true, last_query_index=messages|length - 1) %}{%- for forward_message in messages %}    {%- set index = (messages|length - 1) - loop.index0 %}    {%- set message = messages[index] %}    {%- set current_content = message.content if message.content is not none else '' %}    {%- set tool_start = '<tool_response>' %}    {%- set tool_start_length = tool_start|length %}    {%- set start_of_message = current_content[:tool_start_length] %}    {%- set tool_end = '</tool_response>' %}    {%- set tool_end_length = tool_end|length %}    {%- set start_pos = (current_content|length) - tool_end_length %}    {%- if start_pos < 0 %}        {%- set start_pos = 0 %}    {%- endif %}    {%- set end_of_message = current_content[start_pos:] %}    {%- if ns.multi_step_tool and message.role == "user" and not(start_of_message == tool_start and end_of_message == tool_end) %}        {%- set ns.multi_step_tool = false %}        {%- set ns.last_query_index = index %}    {%- endif %}{%- endfor %}{%- for message in messages %}    {%- if (message.role == "user") or (message.role == "system" and not loop.first) %}        {{- '<|im_start|>' + message.role + '\n' + message.content + '<|im_end|>' + '\n' }}    {%- elif message.role == "assistant" %}        {%- set content = message.content %}        {%- set reasoning_content = '' %}        {%- if message.reasoning_content is defined and message.reasoning_content is not none %}            {%- set reasoning_content = message.reasoning_content %}        {%- else %}            {%- if '</think>' in message.content %}                {%- set content = (message.content.split('</think>')|last).lstrip('\n') %}                {%- set reasoning_content = (message.content.split('</think>')|first).rstrip('\n') %}                {%- set reasoning_content = (reasoning_content.split('<think>')|last).lstrip('\n') %}            {%- endif %}        {%- endif %}        {%- if loop.index0 > ns.last_query_index %}            {%- if loop.last or (not loop.last and reasoning_content) %}                {{- '<|im_start|>' + message.role + '\n<think>\n' + reasoning_content.strip('\n') + '\n</think>\n\n' + content.lstrip('\n') }}            {%- else %}                {{- '<|im_start|>' + message.role + '\n' + content }}            {%- endif %}        {%- else %}            {{- '<|im_start|>' + message.role + '\n' + content }}        {%- endif %}        {%- if message.tool_calls %}            {%- for tool_call in message.tool_calls %}                {%- if (loop.first and content) or (not loop.first) %}                    {{- '\n' }}                {%- endif %}                {%- if tool_call.function %}                    {%- set tool_call = tool_call.function %}                {%- endif %}                {{- '<tool_call>\n{"name": "' }}                {{- tool_call.name }}                {{- '", "arguments": ' }}                {%- if tool_call.arguments is string %}                    {{- tool_call.arguments }}                {%- else %}                    {{- tool_call.arguments | tojson }}                {%- endif %}                {{- '}\n</tool_call>' }}            {%- endfor %}        {%- endif %}        {{- '<|im_end|>\n' }}    {%- elif message.role == "tool" %}        {%- if loop.first or (messages[loop.index0 - 1].role != "tool") %}            {{- '<|im_start|>user' }}        {%- endif %}        {{- '\n<tool_response>\n' }}        {{- message.content }}        {{- '\n</tool_response>' }}        {%- if loop.last or (messages[loop.index0 + 1].role != "tool") %}            {{- '<|im_end|>\n' }}        {%- endif %}    {%- endif %}{%- endfor %}{%- if add_generation_prompt %}    {{- '<|im_start|>assistant\n' }}    {%- if enable_thinking is defined and enable_thinking is false %}        {{- '<think>\n\n</think>\n\n' }}    {%- endif %}{%- endif %}

可以注意到主要是在提示词中拼接了工具的调用过程（即和function call相关）。另外还有最后增加了一个thinking mode的开关：enable_thinking，通过指定此参数为False，可以直接让<think>标签对闭合，以使得模型跳过思考。

接下来是启动文件：

#!/usr/bin/env bashllama-server \    --model "./model/bartowski/Qwen_Qwen3-32B-GGUF/Qwen_Qwen3-32B-IQ4_XS.gguf" \    --alias "Qwen3-32B" \    --n-gpu-layers 65 \    --ctx-size 49152 \    --context-shift \    --parallel 3 \    --cache-type-k q8_0 \    --cache-type-v q8_0 \    --threads 16 \    --flash-attn \    --mlock \    --n-predict -1 \    --jinja \    --chat-template-file ./chat_templates/my-template.jinja\    --props \    -cb \    --host 127.0.0.1 \    --port 18000

稍做了一些修改，例如把监听的地址改成了本地，后面我还专门写了一个代理脚本作为中间层供非本地交互。

代理脚本如下：llm_proxy.py：

import osimport jsonfrom typing import Optional, Setfrom fastapi import FastAPI, Request, Header, HTTPExceptionfrom fastapi.responses import JSONResponse, StreamingResponse, Responseimport httpxUPSTREAM_BASE = "http://127.0.0.1:18000"PROXY_API_KEYS = set()UPSTREAM_API_KEY = "" # 可选, 若上游需要鉴权则设置app = FastAPI(title="LLM Proxy")_api_keys: Set[str] = set()_api_keys_file = "./.llama_api_keys"def read_api_keys() -> Set[str]:    keys = set()    with open(_api_keys_file, "r", encoding="utf-8") as f:        for line in f:            k = line.strip()            if k:                keys.add(k)        print(f"[INFO] Loaded API keys: {len(keys)} keys")    return keys_api_keys = read_api_keys()def check_auth(auth: str | None):    if not _api_keys:        return  # 未设置则不启用代理鉴权    if not auth or not auth.startswith("Bearer "):        raise HTTPException(status_code=401, detail="Missing Authorization Bearer")    if auth.split(" ", 1)[1].strip() not in _api_keys:        raise HTTPException(status_code=403, detail="Invalid API key")def upstream_headers(orig_auth: str | None):    h = {"Content-Type": "application/json"}    if UPSTREAM_API_KEY:        h["Authorization"] = f"Bearer {UPSTREAM_API_KEY}"    return hdef _should_stream(path: str, payload: dict) -> bool:    """仅对 chat/completions 和 completions 且 stream=true 的 POST 开启 SSE 透传。"""    p = path.lower()    if ("chat/completions" in p or p.endswith("/completions")) and isinstance(payload, dict):        return bool(payload.get("stream"))    return False@app.get("/")def root():    return {"name": "LLM Proxy", "upstream": UPSTREAM_BASE, "v1_proxy": True}@app.get("/props")async def proxy_props(request: Request):    async with httpx.AsyncClient() as client:        resp = await client.get(            f"{UPSTREAM_BASE}/props",            params=request.query_params,            headers=request.headers        )    return JSONResponse(status_code=resp.status_code, content=resp.json())@app.get("/health")async def proxy_props(request: Request):    async with httpx.AsyncClient() as client:        resp = await client.get(            f"{UPSTREAM_BASE}/health",            params=request.query_params,            headers=request.headers        )    return JSONResponse(status_code=resp.status_code, content=resp.json())def modify_post_payload(payload):    ctk = payload.get("chat_template_kwargs")    if not isinstance(ctk, dict):        ctk = {}    chat_template_kwargs = ['enable_thinking']    for k in chat_template_kwargs:        if k in payload:            v = payload[k]            if v is not None:                ctk[k] = v    payload["chat_template_kwargs"] = ctk    return payload@app.api_route("/v1/{full_path:path}", methods=["GET", "POST", "PUT", "PATCH", "DELETE", "OPTIONS"])async def v1_catch_all(    request: Request,    full_path: str,    authorization: Optional[str] = Header(default=None),):    """    原样转发 /v1/** 的所有请求到上游。    - JSON 请求：优先使用 json= 传递（便于上游解析）。    - multipart/二进制：透传 content。    - chat/completions & completions + stream=true：SSE 流式透传。    """    check_auth(authorization)    upstream_url = f"{UPSTREAM_BASE}/v1/{full_path}"    method = request.method.upper()    params = dict(request.query_params)    raw_body = await request.body()    ct_req = request.headers.get("content-type", "")    headers = upstream_headers(authorization)    fwd_headers = {**headers}    if ct_req:        fwd_headers["Content-Type"] = ct_req    payload: Optional[dict] = None    if "application/json" in ct_req.lower() and raw_body:        try:            payload = json.loads(raw_body.decode("utf-8"))        except Exception:            payload = None    if payload is not None and isinstance(payload, dict):        payload = modify_post_payload(payload)    if method == "POST" and payload is not None and _should_stream(full_path, payload):        async def iter_stream():            async with httpx.AsyncClient(timeout=None) as client:                async with client.stream(                    "POST",                    upstream_url,                    headers=fwd_headers,                    json=payload,                    params=params,                ) as r:                    r.raise_for_status()                    async for chunk in r.aiter_bytes():                        yield chunk        return StreamingResponse(iter_stream(), media_type="text/event-stream")    async with httpx.AsyncClient(timeout=None) as client:        kwargs = dict(url=upstream_url, headers=fwd_headers, params=params)        if method in {"POST", "PUT", "PATCH"}:            if payload is not None:                kwargs["json"] = payload            else:                kwargs["content"] = raw_body        r = await client.request(method, **kwargs)    ct_resp = r.headers.get("content-type")    resp_headers = {}    for k in ("content-type", "content-disposition", "cache-control", "x-request-id"):        if k in r.headers:            resp_headers[k] = r.headers[k]    return Response(        content=r.content,        status_code=r.status_code,        media_type=ct_resp,        headers=resp_headers,    )

这部分实现了一个比较简陋的鉴权功能，其他的操作就是把请求内容透传到上游即可。

为了适配Cherry Studio和我的后端服务llama_server，还需要将enable_thinking这个参数的位置移动一下，放置到chat_template_kwargs，不然模板不会渲染。

通过命令启动：

uvicorn llm_proxy:app --host 0.0.0.0 --port 8000

至此，服务端的配置已经完成。

配置 Cherry Studio

创建模型

在「模型服务」tab下找到「阿里云百炼」，删掉所有的默认模型，将API修改为刚刚的自部署服务，填写一个密钥。随后添加新模型：

之所以使用「阿里云百炼」是因为这个服务能开启、关闭思维链（也有一些其他服务支持思维链，不过我没有尝试）

配置默认模型

将三个默认模型全部设为Qwen3-32B，对于后面两个模型，需要修改一下提示词，在默认的提示词前面加上/no_think，避免模型过多思考影响效率。

切换到「助手」tab，右键「默认助手」，依次选择「编辑助手」->「模型设置」，然后将「工具调用方式」选择「函数」。

这里说明一下两种不同的工具调用方式有什么区别。

1. 提示词
   这个方式较为通用，是Cherry Studio为了让所有语言模型都能够调用工具实现的功能，通过在系统提示词中临时教模型如何使用工具来实现这个功能。通过提示词方式调用工具有个很大的问题在于系统提示词会非常非常长：”In this environment you have access to a set of…”，详见下图：
   
2. 函数
   在payload中添加一个参数：tools，将工具列表传入模型服务。这种方式需要模型具备function call能力，其请求如下图：
   

而Qwen3系列模型都具备function call能力，因此这一项勾选「函数」比较好，就别傻愣傻愣的每次都教它一遍了。

配置嵌入模型和重排模型

有时候我们会用到嵌入、重排功能，比如在使用知识库、搜索网页的时候。我们可以使用硅基流动提供的免费模型：

配置知识库

配置网络搜索

由于我的服务器性能不大行，只能跑得起5万token的上下文，因此在网络搜索的时候要尽可能减少传过去的内容。

于是，在网络搜索这里我用了RAG方法对搜索结果进行了一定程度的精简。

除了上面这些之外，Cherry Studio还提供了一个插件：划词助手，这插件是真的好用，支持基于大模型的翻译、解释、总结、润色优化等功能，你甚至可以在系统上任何能够划词的软件上打开它：

以上就是我使用Cherry Studio的一部分操作和配置，这款软件还有更多有实用价值、高自由度的功能（例如丰富的MCP工具）等待体验。

32B模型如果做一个4bit量化的话，大约只需要占16G的显存，这样的话，一块24G显存的消费级显卡（如NVIDIA GeForce RTX 3090）也能把这个模型部署起来。拥有一个本地部署的性能匹配满血DeepSeek-R1的模型岂不美哉？于是，我紧锣密鼓地一顿部署，很快便搞定了。

下载模型

模型的官方链接位于Qwen/QwQ-32B，不过我这里选择了另一个HuggingFace 上的由bartowski提供的 该模型的 llama.cpp/ggml 格式量化版仓库：bartowski/Qwen_QwQ-32B-GGUF。

找到文件：Qwen_QwQ-32B-IQ4_XS.gguf，用wget下到本地即可。

安装 llama.cpp

这是一个用cpp写的大模型推理框架，链接如下：

引用站外地址，不保证站点的可用性和安全性

llama.cpp

GitHub

仓库给了一个编译文档，不过我直接对着文档操作失败了，所以在这里记录一下我的操作。

在编译之前，需要确保已经安装好了一些基本的组件：

sudo apt updatesudo apt install -y build-essential libcurl4-openssl-devsudo snap install cmake --classic

另外如果编译CUDA版，还需要装好cuda-toolkit：

$ nvcc --versionnvcc: NVIDIA (R) Cuda compiler driverCopyright (c) 2005-2024 NVIDIA CorporationBuilt on Tue_Feb_27_16:19:38_PST_2024Cuda compilation tools, release 12.4, V12.4.99Build cuda_12.4.r12.4/compiler.33961263_0

增加CUDA路径

export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH

Clone仓库

git clone https://github.com/ggml-org/llama.cppcd llama.cpp

开始编译

env -i \  PATH="/snap/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin:/usr/local/cuda/bin" \  CC=/usr/bin/gcc CXX=/usr/bin/g++ \  CUDACXX=/usr/local/cuda/bin/nvcc \  cmake -B build -DGGML_CUDA=ON \        -DCMAKE_C_FLAGS="-pthread" \        -DCMAKE_CXX_FLAGS="-pthread" \        -DCMAKE_EXE_LINKER_FLAGS="-pthread" \        -DCUDAToolkit_ROOT=/usr/local/cudacmake --build build -j4  # 4核足以，开太多会把我ssh挤掉

编译完成后，将编译出的文件移动到系统上：

sudo cmake --install build --prefix /usr/local

这时直接运行llama-server仍可能会报错：

llama-server: error while loading shared libraries: libmtmd.so: cannot open shared object file: No such file or directory

运行一下下面的命令即可：

# 确保 /usr/local/lib 在动态库配置里，并刷新缓存echo '/usr/local/lib' | sudo tee /etc/ld.so.conf.d/llama.confsudo ldconfig

部署 QwQ-32B

创建一个jinja模板./chat_templates/QwQ.jinja：

{%- if tools %}    {{- '<|im_start|>system\n' }}    {%- if messages[0]['role'] == 'system' %}        {{- messages[0]['content'] }}    {%- else %}        {{- '' }}    {%- endif %}    {{- "\n\n# Tools\n\nYou may call one or more functions to assist with the user query.\n\nYou are provided with function signatures within <tools></tools> XML tags:\n<tools>" }}    {%- for tool in tools %}        {{- "\n" }}        {{- tool | tojson }}    {%- endfor %}    {{- "\n</tools>\n\nFor each function call, return a json object with function name and arguments within <tool_call></tool_call> XML tags:\n<tool_call>\n{\"name\": <function-name>, \"arguments\": <args-json-object>}\n</tool_call><|im_end|>\n" }}{%- else %}    {%- if messages[0]['role'] == 'system' %}        {{- '<|im_start|>system\n' + messages[0]['content'] + '<|im_end|>\n' }}  {%- endif %}{%- endif %}{%- for message in messages %}    {%- if (message.role == "user") or (message.role == "system" and not loop.first) %}        {{- '<|im_start|>' + message.role + '\n' + message.content + '<|im_end|>' + '\n' }}    {%- elif message.role == "assistant" and not message.tool_calls %}        {%- set content = (((message.content | default('', true))).split('</think>')|last).lstrip('\n') %}        {{- '<|im_start|>' + message.role + '\n' + content + '<|im_end|>' + '\n' }}    {%- elif message.role == "assistant" %}        {%- set content = (((message.content | default('', true))).split('</think>')|last).lstrip('\n') %}        {{- '<|im_start|>' + message.role }}        {%- if message.content %}            {{- '\n' + content }}        {%- endif %}        {%- for tool_call in message.tool_calls %}            {%- if tool_call.function is defined %}                {%- set tool_call = tool_call.function %}            {%- endif %}            {{- '\n<tool_call>\n{"name": "' }}            {{- tool_call.name }}            {{- '", "arguments": ' }}            {{- tool_call.arguments | tojson }}            {{- '}\n</tool_call>' }}        {%- endfor %}        {{- '<|im_end|>\n' }}    {%- elif message.role == "tool" %}        {%- if (loop.index0 == 0) or (messages[loop.index0 - 1].role != "tool") %}            {{- '<|im_start|>user' }}        {%- endif %}        {{- '\n<tool_response>\n' }}        {{- message.content }}        {{- '\n</tool_response>' }}        {%- if loop.last or (messages[loop.index0 + 1].role != "tool") %}            {{- '<|im_end|>\n' }}        {%- endif %}    {%- endif %}{%- endfor %}{%- if add_generation_prompt %}    {{- '<|im_start|>assistant\n<think>\n' }}{%- endif %}

创建启动命令文件llama_deploy.sh:

llama-server \    --model "./model/bartowski/Qwen_QwQ-32B-GGUF/Qwen_QwQ-32B-IQ4_XS.gguf" \    --alias "QwQ-32B" \    --n-gpu-layers 65 \    --ctx-size 32768 \    --parallel 1 \    --cache-type-k q8_0 \    --cache-type-v q8_0 \    --threads 16 \    --flash-attn \    --mlock \    --n-predict -1 \    --jinja \    --chat-template-file ./chat_templates/QwQ.jinja \    --host 0.0.0.0 \    --port 8000

然后运行llama_deploy.sh，即可完成部署。

测试

在Cherry Studio中还能轻松调用工具：

前段时间忙里偷闲和女朋友一起去了趟云南（你可以查看相册），在出发之前，由于怕女朋友高反，遂问了一圈各种AI应该带什么药、做什么准备措施，以及高反的主要症状等。在做足了功课后，职业病又犯了：我能不能自己搞个大模型小模型，让它具备专业的医学知识，以使得用户提问时，其能从专业的角度给予回答？

说干就干，由于需要一定的实用性，就不考虑 7b 以下的模型了，但7b的模型我的垃圾显卡又训不动，怎么办呢？于是我想起了曾经听说过的一种技术：检索增强生成（Retrieval Augmented Generation, RAG），这种方法不需要训练模型，直接用预训练好的模型即可。

RAG是什么？

检索增强生成 (英语：Retrieval-augmented generation, RAG ) 是赋予生成式人工智能模型资讯检索能力的技术。检索增强生成最佳化大型语言模型(LLM) 的交互方式，让模型根据指定的一组文件回应使用者的查询，并使用这些资讯增强模型从自身庞大的静态训练数据中提取的资讯。
维基百科

回到我的需求：使大模型获得一定的医学知识。要使大模型具备一定的专业知识，最方便的不需要额外训练的方法当然就是直接将专业知识作为上下文喂给大模型，让它基于这些内容进行回答。但我们又知道，我们给模型提供的上下文越多，其中的关键信息越会被淡化，哪怕长度未到上限，仍可能引发回答幻觉。

为尽可能减少专业知识领域的幻觉问题，这种名为检索增强生成的方案应运而生。

简单说来，就是通过一些文本相似度算法，从非常多的专业语料数据中检索出与用户的提问相关度较高的内容，一并作为上下文喂给模型。如此，模型的上下文内容中仅仅包含了与用户提问相关度最高的信息，而非所有的专业知识，上下文与用户提问的相关性大幅提升，而其长度则大幅下降，从而使得模型能给出更专业、更可信的回答。

纸上得来终觉浅，在知道其原理后，我们来尝试一下吧！

RAG方法的实践

数据集准备 & 处理

我上哪去弄那么多医学相关的文本数据？逛逛开源社区肯定错不了，稍一搜索，我找到了它：FreedomIntelligence/huatuo_encyclopedia_qa，这是一个中文医学问答数据集，共包含364420条 Q-A 对。

一般情况下，对于大段大段的长篇文本，为了制作RAG的数据库，我们还需要考虑如何将其进行切片，而这种处理好的一条一条的数据就几乎不用考虑切片问题了，特别适合作为RAG的数据。

我们使用一个集成的非常好的框架：langchain来进行处理。RAG方法需要将文本数据制作成嵌入向量存储到数据库中，在检索时匹配语义相似度最高的向量（这里相似度指标可以使用欧氏距离、余弦相似度等）。总之，无论如何，我们总是需要将文本先转化为嵌入向量，因此需要一个嵌入模型，这里我使用了BAAI系列的嵌入模型：BAAI/bge-large-zh-v1.5。

from langchain.embeddings import HuggingFaceEmbeddingsembeddings = HuggingFaceEmbeddings(    model_name="BAAI/bge-large-zh-v1.5",    model_kwargs={        "device": "cpu"    })

这里的设备可以改成cuda以提速。有了嵌入模型，接下来我们需要使用一个向量数据库，将全部文本数据转化成的嵌入向量存入。鉴于数据的规模不大，我使用了一个比较轻量的向量数据库：faiss。

langchain对这个数据库进行了比较好的封装，我们可以直接调用：

from langchain.vectorstores import FAISSfrom datasets import load_datasetfrom langchain.docstore.document import Documentimport jsonimport osos.makedirs("RAG_DB", exist_ok=True)data = load_dataset("FreedomIntelligence/huatuo_encyclopedia_qa", split='train')docs = []for row in data:    content = json.dumps(row, ensure_ascii=False)    docs.append(Document(page_content=content))db = Nonebatchsize = 512index = 0with tqdm(range(len(docs))) as bar:    while index < len(docs):        batch = docs[index: index + batchsize]        index += batchsize        if db is None:            db = FAISS.from_documents(batch, embeddings)        else:            db.add_documents(batch)        bar.update(len(batch))db.save_local("RAG_DB/medical")

这一步骤比较耗时，防止等的不耐烦，遂加了个进度条。每次往数据库中添加512条Q-A对，大约花了一个半小时才搞定。

至此，数据已经处理完成。

实现文本检索

既然已经制作好了数据库，这一步就很容易了，langchain同样封装好了相似度计算的部分，它默认使用的是欧氏距离作为相似度指标（距离越小，相似度越高）。我们从数据库对象中提取一个retriever出来，就可以直接使用了：

retriever = db.as_retriever(search_type="similarity", search_kwargs={"k": 10})

随便写个问题测试一下：

可以看到检索的效果还是比较好的，拿到了检索器，剩下的操作就很简单了，只要部署起一个大模型，稍微实现一下后端逻辑，再用Gradio整个界面出来，就万事大吉了！

部署大模型

说是大模型，其实就是个7b的小模型罢了。这里我使用了Qwen/Qwen2.5-7B-Instruct。

将模型下载到本地：

hf download Qwen/Qwen2.5-7B-Instruct --local-dir ./model/Qwen2.5-7B-Instruct

通过vllm启动：

python3 -m vllm.entrypoints.openai.api_server \  --model ./model/Qwen2.5-7B-Instruct \  --tokenizer ./model/Qwen2.5-7B-Instruct \  --dtype float16 \  --host 0.0.0.0 \  --port 8000 \  --max-num-seqs 4

稍等片刻启动完成后（吃掉了约20G显存…（模型自身占用$7\times2=14$GB，KV-cache占用约6.7GB）），我们就可以直接通过OpenAI提供的api来与之交互：

from openai import OpenAIclient = OpenAI(    base_url="http://localhost:8000/v1",    api_key="n")messages = [{"role": "user", "content": "你是谁？"}]response = client.chat.completions.create(    model="./model/Qwen2.5-7B-Instruct",    messages=messages)

编写RAG业务逻辑

为得到相似度得分，排除掉特别不相关的内容，我们可以自己写一个retrieve函数：

def retrieve(question: str):    docs = db.similarity_search_with_score(question, k=10)    docs = [json.loads(doc.page_content) for doc, score in docs if score.item() < 0.9]    docs = [json.dumps({        "question": doc.get("questions")[0][0],        "answer": doc.get("answers")[0]    }, ensure_ascii=False) for doc in docs]    return docs

给一个系统提示词：

system_prompt = """你是一位医学专家。你擅长根据文档回答用户的提问。要求：1. 只使用提供的文档内容来回答问题。2. 不要添加任何额外的内容，如果文档中没有相关信息，请直接回答"无法回答"。3. 如果没有搜到相关文档，请回答"未查询到相关文档"。"""

再编写一个用户提示词模板：

from langchain.prompts import PromptTemplateprompt_template = PromptTemplate.from_template("""文档: {context}问题: {question}""")

接下来，我们通过langchain框架将RAG的流程实现一下：

from langchain_core.runnables import RunnableMap, RunnableLambdarag_chain = (    RunnableMap({        "history": lambda x: x["history"],        "question": lambda x: build_context_query(x["question"], x["history"])    })    | RunnableLambda(lambda x: {        "question": x["question"],        "history": x["history"],        "context": retrieve(x["question"]),    })    | RunnableLambda(lambda x: {        "question": x["question"],        "history": x["history"],        "context": "\n".join(x['context']),        "references": x['context']    })    | RunnableLambda(lambda x: {        "prompt": prompt_template.format(question=x["question"], context=x["context"]),        "history": x["history"],        "references": x["references"]    })    | RunnableLambda(lambda x: {        "response": stream(x["prompt"], x["history"]),        "references": x["references"]    }))

这是一个串联过程，看似复杂，实则容易理解，限于篇幅，不再详细解释。

需要解释一下这里定义的一个函数：build_context_query，它用来处理用户输入的提问，如下：

def build_context_query(question: str, history: list) -> str:    """构建包含历史上下文的查询"""    if not history:        return question        return summarize_context_query(question, history)def summarize_context_query(question: str, history: list) -> str:    """使用大模型总结历史提问，生成更准确的检索查询"""    if not history:        return question        # 构建历史对话列表    history = [f'Q: {user_msg}\nA: {response}' for user_msg, response in history[-3:]]  # 最近3轮    system_prompt = f"""你是一个重写助手，任务是将用户当前的问题结合历史对话重写为一个**自包含、清晰明确的问题句子**，以便发送给问答系统。请遵循以下规则：1. 仅重写问题，**不回答**；2. 替换句中的所有代词（如“它”、“这”、“那”等）为具体的名词或短语，当可能存在多个指代对象时，使用最新的历史对话中的信息；3. 推理指代、补全省略，使问题独立完整；4. 不引入历史中未提及的信息； 5. 只输出**重写后的问题句子**，不添加任何解释或注释。"""        summary_prompt = f"""历史对话：{chr(20).join([f"{i+1}. {q}" for i, q in enumerate(history)])}当前问题：{question}你重写的问题："""        try:        messages = [{"role": "system", "content": system_prompt},                    {"role": "user", "content": summary_prompt}]        response = client.chat.completions.create(            model="./model/Qwen2.5-7B-Instruct",            messages=messages,            stream=False,            max_tokens=50        )                summarized_query = response.choices[0].message.content.strip()        print(f"原始问题: {question}")        print(f"重写问题: {summarized_query}")        return summarized_query            except Exception as e:        return question

这一长串代码，实际仅处理了一件事：根据最近3轮的历史聊天信息，把用户的提问重新整理一下。

在实际使用中，我们发现，用户和模型的对话很可能是这样的：

user: 艾滋病是什么？assistant: 艾滋病是一种危害性极大的传染病...user: 它如何治疗？

由于RAG在检索召回相似文档时仅仅依赖于用户的提问，而不会关注上下文信息，这里RAG检索的问题：「它如何治疗？」中缺乏关键信息——这个它指什么？（即使用户认为上下文中存在这一信息），为了解决这一问题，我想了个骚操作：让大模型根据历史对话记录来对用户的提问进行重写。这就是上面代码所做的事。

亲测还是比较好用的：

后来发现工程上似乎就是这么做的，这个任务叫Query Rewriting（查询重写）。

需要注意的是，我仅仅在查询重写这一步骤中使用了历史信息，并没有在与大模型的对话上下文中使用它们。

完整代码 & 使用体验

将业务逻辑用Gradio糊一个前端，再实现一下流式响应，一个简单的医学问答大模型平台就完成了！

完整代码如下：

RAG/medical.py

from langchain.prompts import PromptTemplatefrom langchain_huggingface import HuggingFaceEmbeddingsfrom langchain_community.vectorstores import FAISSimport osimport jsonfrom tqdm import tqdmembeddings = HuggingFaceEmbeddings(    model_name="BAAI/bge-large-zh-v1.5",    model_kwargs={        "device": "cpu"    })db_path = 'RAG_DB/medical'if os.path.exists(db_path):    db = FAISS.load_local(db_path, embeddings, allow_dangerous_deserialization=True)else:    print("数据库不存在，正在加载数据集...")    from datasets import load_dataset    from langchain.docstore.document import Document    data = load_dataset("FreedomIntelligence/huatuo_encyclopedia_qa", split='train')    docs = []    for row in data:        content = json.dumps(row, ensure_ascii=False)        docs.append(Document(page_content=content))    db = None    batchsize = 512    index = 0    with tqdm(range(len(docs))) as bar:        while index < len(docs):            batch = docs[index: index + batchsize]            index += batchsize            if db is None:                db = FAISS.from_documents(batch, embeddings)            else:                db.add_documents(batch)            bar.update(len(batch))    db.save_local(db_path)        system_prompt = """你是一位医学专家。你擅长根据文档回答用户的提问。要求：1. 只使用提供的文档内容来回答问题。2. 不要添加任何额外的内容，如果文档中没有相关信息，请直接回答"无法回答"。3. 如果没有搜到相关文档，请回答"未查询到相关文档"。"""        prompt_template = PromptTemplate.from_template("""文档: {context}问题: {question}""")def retrieve(question: str):    docs = db.similarity_search_with_score(question, k=10)    docs = [json.loads(doc.page_content) for doc, score in docs if score.item() < 0.9]    docs = [json.dumps({        "question": doc.get("questions")[0][0],        "answer": doc.get("answers")[0]    }, ensure_ascii=False) for doc in docs]    return docsdef format_references(docs, title="参考内容"):    """将 Document 列表格式化为折叠式 Q-A Markdown 文本"""    qa_blocks = []    for i, doc in enumerate(docs, 1):        content = json.loads(doc)        question = content.get("question")        answer = content.get("answer")        qa_blocks.append(f"Q{i}: {question}\n\n<details><summary>A{i}:</summary>\n\n{answer}\n\n</details>")        body = "\n\n---\n\n".join(qa_blocks)    markdown = f"<details><summary>{title}</summary>\n\n{body}\n\n</details>"    return markdownTITLE = '医学RAG问答系统'DESCRIPTION = '输入医学问题，我会基于专业内容为你解答。'

main.py

import gradio as grfrom langchain_core.runnables import RunnableMap, RunnableLambdafrom openai import OpenAIfrom RAG.medical import *import warningswarnings.filterwarnings("ignore", category=FutureWarning)client = OpenAI(    base_url="http://localhost:8000/v1",    api_key="n")def stream(prompt: str, history=None):    messages = []        messages.append({"role": "system", "content": system_prompt})    messages.append({"role": "user", "content": prompt})        response = client.chat.completions.create(        model="./model/Qwen2.5-7B-Instruct",        messages=messages,        stream=True    )    for chunk in response:        if chunk.choices[0].delta.content:            yield chunk.choices[0].delta.content        def summarize_context_query(question: str, history: list) -> str:    """使用大模型总结历史提问，生成更准确的检索查询"""    if not history:        return question        # 构建历史对话列表    history = [f'Q: {user_msg}\nA: {response}' for user_msg, response in history[-3:]]  # 最近3轮    system_prompt = f"""你是一个重写助手，任务是将用户当前的问题结合历史对话重写为一个**自包含、清晰明确的问题句子**，以便发送给问答系统。请遵循以下规则：1. 仅重写问题，**不回答**；2. 替换句中的所有代词（如“它”、“这”、“那”等）为具体的名词或短语，当可能存在多个指代对象时，使用最新的历史对话中的信息；3. 推理指代、补全省略，使问题独立完整；4. 不引入历史中未提及的信息； 5. 只输出**重写后的问题句子**，不添加任何解释或注释。"""        summary_prompt = f"""历史对话：{chr(20).join([f"{i+1}. {q}" for i, q in enumerate(history)])}当前问题：{question}你重写的问题："""        try:        messages = [{"role": "system", "content": system_prompt},                    {"role": "user", "content": summary_prompt}]        response = client.chat.completions.create(            model="./model/Qwen2.5-7B-Instruct",            messages=messages,            stream=False,            max_tokens=50        )                summarized_query = response.choices[0].message.content.strip()        print(f"原始问题: {question}")        print(f"重写问题: {summarized_query}")        return summarized_query            except Exception as e:        return questiondef build_context_query(question: str, history: list) -> str:    """构建包含历史上下文的查询"""    if not history:        return question        return summarize_context_query(question, history)rag_chain = (    RunnableMap({        "history": lambda x: x["history"],        "question": lambda x: build_context_query(x["question"], x["history"])    })    | RunnableLambda(lambda x: {        "question": x["question"],        "history": x["history"],        "context": retrieve(x["question"]),    })    | RunnableLambda(lambda x: {        "question": x["question"],        "history": x["history"],        "context": "\n".join(x['context']),        "references": x['context']    })    | RunnableLambda(lambda x: {        "prompt": prompt_template.format(question=x["question"], context=x["context"]),        "history": x["history"],        "references": x["references"]    })    | RunnableLambda(lambda x: {        "response": stream(x["prompt"], x["history"]),        "references": x["references"]    }))def qa_interface(message, history):    result = rag_chain.invoke({"question": message, "history": history})    generator = result["response"]    references = result["references"]    response = ""    for token in generator:        response += token        yield response    references_text = format_references(references)            response += "\n\n" + references_text    yield responsechat = gr.ChatInterface(    fn=qa_interface,    title=TITLE,    description=DESCRIPTION)chat.launch(server_name="0.0.0.0")

使用体验如下：

这事在圈内激起了不小的波澜，众所周知，大模型的训练过程十分消耗算力，尤其是常规的RLHF阶段使用的PPO算法，流程复杂又烧钱。比如OpenAI在训练ChatGPT时，动辄上万张A100、H100堆起来跑，而Nvidia几乎是算力的唯一供应商。

而DeepSeek团队推翻了这一现状：训练一个性能能够对标主流水平的大模型，并不需要那么多的卡（仅使用约2k张H800）。他们通过一套更高效、轻量的流程大幅简化了训练的成本与复杂度，其中最核心的改进便是引入了Group Relative Policy Optimization（GRPO）算法。那么，这个算法究竟是何方神圣？感兴趣的朋友可以直接阅读下面的原论文：

引用站外地址，不保证站点的可用性和安全性

DeepSeek-R1

$\text{ar}\chi\text{iv}$​

插句题外话，博主在当时几乎第一时间就把论文下载了下来：

然而由于实验室搬砖科研等各种事，一直拖着没认真读（唉，读了又怎么样呢？当时的显存连个7b的模型都放不下）。时隔多月，终于显存和心理都空出一点空间，总算能静下心来，把这个 GRPO算法好好研究、复现了一遍。

DeepSeek-R1的论文其实对整体的训练流程也做了不少改进，但核心贡献还是在于其在强化学习阶段引入的GRPO算法，因此我主要研究了这个强化学习算法的细节。

博主写这篇文章的目的，就是记录一下自己对 GRPO 算法的理解，以及在复现过程中整理的一些关键细节和实践心得。

GRPO算法的思想

GRPO算法，即组相对策略优化（Group Relative Policy Optimization），其核心思想是：不再单独对一个token序列打分，而是在同一个prompt下采样多条输出，形成一个分组，然后在分组中计算输出间的相对优劣，得到每条输出的组内相对得分，以此指导模型更新。

除此以外，GRPO算法和先前的PPO算法还有一些区别：

1. GRPO算法省去了Reward Model与Critic Model。
2. 论文针对任务数据集特点设计了一些基于规则的Reward Function，来对输出进行打分。
3. 与PPO算法中token-level的优势函数不同，GRPO算法中的优势函数是sample-level的，即一个输出的所有token共享同一个组内优势值。
4. GRPO算法将PPO算法的Reward中添加的KL正则项移到了损失函数中。
5. GRPO算法使用了另一种不同的KL散度估计方法。

我们来逐点分析。首先看第二点，论文中提到：

We do not apply the outcome or process neural reward model in developing DeepSeek-R1-Zero, because we find that the neural reward model may suffer from reward hacking in the large-scale reinforcement learning process, and retraining the reward model needs additional training resources and it complicates the whole training pipeline.

我在微调RLHF的时候确实也遇到过这种情况。常规PPO算法非常依赖于Reward Model的质量，但基于神经网络的Reward Model在用于强化学习时经常会遇到Reward Hacking，即模型在训练时学会了钻Reward Model的漏子，用一些不好的输出获取非常高的得分，即模型学会了“讨好”奖励模型，而不去努力产生高质量的输出（不好，这怎么像极了我做科研时的样子）。

而对神经网络攻击稍有了解的朋友就会知道，神经网络模型作为一个高度不可解释的黑盒系统，很容易被“投其所好”地构造出满足特定输出的输入 —— 即使这些输入在人类看来是无意义甚至错误的。

正是由于这种脆弱性，我们训练的语言模型只需要偶然间发现一条让奖励模型输出高分的捷径，它就可能在这条离谱的道路上越走越远，或产生模式崩坏、或输出质量奇差的内容。

不好，跑题了。。。

那么论文提到的基于规则的Reward函数主要有两种：

1. 基于正确性的奖励（Accuracy rewards）：对于一些有“标准答案”的任务，例如具有准确答案的数学问题、代码生成任务等，可以根据模型答题是否准确来给一定的奖励。
2. 基于格式的奖励（Format rewards）：根据模型的输出结果是否满足一定的格式要求来进行给分。如论文提到将模型的思维过程置于<think>和</think>标签之间，如模型输出的内容满足此条件则给奖励。

不过，对于通用型任务而言，Accuracy rewards不一定能定义，这种情况下，也许还得和前面PPO算法类似，去训练一个通用的Reward Model来辅助。

对于第一点，既然都定义了基于规则的奖励函数了，那么Reward Model、Critic Model自然是不需要了。

我们来看第三点。

在PPO算法中，优势函数的计算分为以下步骤：

1. 通过Critic Model计算每个token的Value。
2. 通过每个token的Value计算TD delta（时序差分序列）。
3. 通过时序差分序列按GAE算法计算优势函数。

对这一过程的细节不太了解的朋友可以翻看我前面的文章：PPO算法、RLHF实践。

由此可见，PPO算法中的优势函数也是token-level的，即每个token对应一个优势值。

但在GRPO算法中，则有所不同，如论文中所写，GRPO算法使用的优势函数是通过组内每个样本的Reward计算得来的：

诶，我们发现，这样一来，相当于每个样本中的所有token是共享同一个优势函数值的。

再看第四点和第五点，我们回顾PPO算法的优化目标：

在Reward中添加了一个KL散度惩罚项，而GRPO算法中则将这一项惩罚项移到了损失函数中：

容易发现，除掉多了个分组大小 $G$​ 以外，GRPO的损失函数前半部分与PPO是完全一致的，而后面多出来的部分就是KL散度惩罚项。

PPO中，计算KL散度的公式是：

而在GRPO中，论文采用了下面这个公式：

显然，前者是后者的一个一阶近似，故后者能够更准确地估计真实的KL散度。

GRPO算法复现

• Pretrained-Model：Qwen/Qwen2.5-1.5B-Instruct (太惨了，即使套了LoRA也只训的动1.5B)
• Dataset：openai/gsm8k 包含数千道英文小学数学题的数据集，每条数据包含一个answer字段，提供问题的解答，并且固定了纯数字答案格式：置于末尾####之后。
• Task：让模型具备使用思维链解决数学问题的能力。

奖励函数定义

与论文一致，我们主要定义了两个奖励函数：

1. 准确性奖励：我们要求模型给出问题的答案，如答案准确则奖励。
2. 格式奖励：要求模型将思考过程包含在一对<think>和</think>之间，并且将最终答案包含在一对<answer>和</answer>之间，如格式准确则奖励。

另外，考虑到严格达成两个奖励函数非常困难，我们还相应地提供了两个稍宽松的奖励。

1. 只要答案是一个纯数字，就给一定的奖励。
2. 只要匹配到了<think>、</think>、<answer>和</answer>中的一部分，就给一定的奖励，但如果匹配到多个，则扣除奖励。

奖励函数的定义详见此文件。

数据处理

我们直接套用Qwen/Qwen2.5-1.5B-Instruct模型对应的tokenizer所提供的chat template，并定义一个系统提示词：

You are given a problem.Think about it and provide your working out.Place it between <think> and </think>.Then, provide your numeric answer between <answer> and </answer>. For example:<think>...</think><answer>...</answer>

核心代码：

def extract_hash_answer(self, text: str):    if "####" not in text:        return None    return text.split("####")[1].strip().replace(',', '')def __getitem__(self, idx):    data = self.dataset[idx]    question = data['question']    answer = self.extract_hash_answer(data['answer'])        prompt = self.tokenizer.apply_chat_template([        {"role": "system", 'content': self.system_prompt},        {"role": "user", 'content': question}    ], add_generation_prompt=True, tokenize=False)        return {        'prompt': prompt,        'answer': str(answer)    }

训练流程

甚至连伪代码都懒得写了，大概写一下流程吧：

1. 定义一个数据收集容器：Data Buffer。
2. 从数据集中取一条 prompt，生成 $G$ 条输出序列，从而得到大小为 $G$ 的分组。
3. 根据定义好的奖励函数，对步骤 2 生成分组内的所有输出序列计算得分，然后在组内进行比较，求得相对得分（作为优势函数）。由此，得到一组数据。
4. 将步骤 3 得到的数据添加到Data Buffer。
5. 若Data Buffer的大小达到一次迭代需要的数据量（等效 Batch size），则进入步骤 6，否则回到步骤 2。
6. 遍历Data Buffer，每次取Batch size个数据，按前面的公式计算KL散度、损失函数，并进行策略迭代。
7. 遍历完成，清空Data Buffer，回到步骤 2。

本部分完整代码见文末仓库。

训练效果

训练曲线：

注意到总体 Reward 还是在上升的，并且我们还分别记录观察了三个独立的Reward函数的变化趋势，发现模型在准确率、格式方面都有所提升，唯独这个Soft Format在上升到一定程度后有所下降，观察到模型有时会重复输出answer的闭合tag：</answer>，目前还不知道是什么原因（明明给了一定的惩罚？）。

另外，每隔10次迭代，打印了一下模型生成的结果，发现模型确实能做对一些题，并且在格式上也有所对齐，思考过程有模有样。下面贴出几个例子。

最终，博主将迭代了400个step的模型与未经过训练的初始模型进行了测试与对比，结果如下：

Qwen Accuracy: 0.4314 Formatted: 0.6088 GRPO Accuracy: 0.5610 Formatted: 0.9121

可见经过GRPO迭代的模型已经具备了较强的格式对齐能力，在准确率方面也有了一定的提升，意味着训练还是有一定的效果的。

本文相关代码已开源于下面仓库：

引用站外地址，不保证站点的可用性和安全性

tiny-llm-training

GitHub

为了解决常规RLHF算法中的这些问题，研究者随后提出了DPO（Direct Preference Optimization）算法，它能够绕过RLHF算法中的奖励模型训练以及后面的强化学习训练阶段，在完成监督微调之后，直接通过人类偏好对比数据对模型进行对齐优化，相当于实现了不需要RL的RLHF。

建议有兴趣深入了解的朋友直接阅读原论文。

引用站外地址，不保证站点的可用性和安全性

Direct Preference Optimization

$\text{ar}\chi\text{iv}$​

PPO算法的优化目标

前面提到的PPO算法作为一种强化学习算法，其在大语言模型训练任务上，优化的最终目标实际上是生成token序列的Reward的期望值，假设我们已经有了一个完美的Reward Model：$R(x,y)$，表示给定prompt $x$ 且模型输出token序列为 $y$ 时的Reward，我们可以将优化目标简单写为：

不过，考虑到实际训练时需要对模型策略的KL散度做一个约束，我们还要在优化目标中添加一个惩罚项，于是优化目标实际上是：

上式中，$\beta$ 是惩罚系数，$\pi_{\text{ref}}(y\mid x)$ 则是参考模型给出的概率分布。$\mathbb{D}_{\text{KL}}(* \| *)$ 表示两个概率分布的KL散度，其定义如下：

求解优化目标

将KL散度表达式代入优化目标，得到：

将其改为求极小值，除以常数 $\beta$，并稍加变形，得到：

这里，论文做了一个操作，强行让对数部分成为一个新的 KL散度，即让分母部分通过一个归一化操作成为概率分布：

定义 $Z(x)$：

可见 $Z(x)$ 是关于 $x$ 的函数，并且只与 $\pi_\text{ref}$ 、奖励模型有关，与待训练模型 $\pi_\theta$ 无关。

将 $Z(x)$ 引入优化目标 $\log$ 运算的分母，再从外部减去，我们得到：

此时，左侧的对数就变成了一个KL散度的形式了，我们记

容易验证 $\pi^*(*\mid x)$ 是一个概率分布，因此，上式可以写为：

显然，由于上式的右侧项 $\log Z(x)$ 与 $\pi_\theta$ 无关，我们可以忽略它。又从KL散度的性质得到，当且仅当

时，KL散度达到最小值0。

看上去我们已经直接求出了目标的显式解，但可惜的是，这个 $Z(x)$ 并不好计算，因为它需要对于一个prompt $x$，遍历所有Reference Model可能产生的 $y$ 才能精确计算，如用蒙特卡洛方法估计，也得采样相当数量的 $y$​，这个过程十分消耗算力。

另外，这个解还依赖于我们训练好的完美的 $R(x,y)$，因此在论文作者看来还不够方便，毕竟他们的目标是想要跳过后面两个步骤。

新的优化目标

将 $R(x,y)$ 用两个概率分布以及 $Z(x)$ 反过来表示：

我们考虑前面训练Reward Model时用到的偏序数据对 $(x,y_c,y_r)$：其中 $x$ 为 prompt，$y_c$ 表示 chosen 的回复，$y_r$ 表示 rejected 的回复。

对于偏序数据的建模，论文中提到了Bradley-Terry Model。

简单说来，它通过一个定量公式估计了一对比较对象的两种比较结果分别发生的可能性：

其中，$i \succ j$ 表示在某种标准上 $i$ 超越了 $j$，$p_i,p_j$​ 分别表示两个对象的某种得分（得分必须为正数）。

在建模 $(x,y_c,y_r)$ 这一文本问答的偏序数据时，论文采用了下述公式：

其中 $\sigma(s)=\frac{1}{1+\exp(-s)}$ 为 Sigmoid 函数。

考虑到我们在最大化一个概率分布时，一般会去最小化其负对数似然，因此我们可以写出优化目标：

这个目标有一个很大的好处在于，当我们把

代入时，会发现正好把那坨 $Z(x)$ 消掉了，从而得到下式：

这便是最终的优化目标。由此，我们的目标函数只与 $\pi^*$ 相关，已经绕开了之前奖励模型的训练过程。

综上，我们基本将论文中涉及到的核心过程推导了一遍，构造了一个无需奖励模型的优化目标，相比于PPO算法，DPO算法的最终形式简洁了不少，省去了显式的奖励模型训练过程，在优化过程中用到的模型也少了一半，节省了计算资源。

代码实现

数据集

偏好数据集仍然使用了与之前相同的OpenLLMAI/comparison_data，数据集的定义方法与前面训练Reward Model时类似，不过为了便于后续计算损失函数，这里我额外算了一个label_mask，用来屏蔽prompt和padding部分，防止这部分参与loss的计算。

def build_inputs(self, prompt_ids, response_ids):    input_ids = prompt_ids + [self.tokenizer.bos_token_id] + response_ids    input_ids = input_ids[:self.max_length]    if len(input_ids) < self.max_length:        input_ids += [self.tokenizer.eos_token_id]    bos_pos = input_ids.index(self.tokenizer.bos_token_id)    label_mask = [0] * (bos_pos + 1) + [1] * (len(input_ids) - bos_pos - 1)    pad_len = self.max_length - len(input_ids)    if pad_len > 0:        input_ids += [self.tokenizer.pad_token_id] * pad_len        label_mask += [0] * pad_len    attention_mask = [1] * (self.max_length - pad_len) + [0] * pad_len    return input_ids, attention_mask, label_mask

计算 $\pi(y\mid x)$ ，采用了取对数概率（logits）然后求和的方式，不过在计算得到了logits之后，需要先用前面计算得到的label_mask对prompt和padding部分做一个屏蔽，再进行求和：

def masked_sum(values, labels_mask):    return (values * labels_mask[:, :-1]).sum(-1).squeeze(-1)

训练

核心部分的代码如下：

for step, batch in tqdm(enumerate(dataloader, 1), desc=f"Epoch {epoch + 1}/{num_epochs}", dynamic_ncols=True, total=len(dataloader)):    input_ids = batch['input_ids']    label_mask = batch.pop('label_mask')    with torch.no_grad():        logits_ref = model_ref(**batch).logits        log_prob_ref = calculate_action_logsoftmax(logits_ref[:, :-1], input_ids[:, 1:])        log_prob_ref = filter_mask(log_prob_ref, label_mask)        log_prob_ref_chosen, log_prob_ref_rejected = log_prob_ref.chunk(2, dim=0)    with accelerator.accumulate(model):        logits = model(**batch).logits        log_prob = calculate_action_logsoftmax(logits[:, :-1], input_ids[:, 1:])        log_prob = filter_mask(log_prob, label_mask)        log_prob_chosen, log_prob_rejected = log_prob.chunk(2, dim=0)                reward_chosen = log_prob_chosen - log_prob_ref_chosen        reward_rejected = log_prob_rejected - log_prob_ref_rejected        loss = -logsigmoid(beta * (reward_chosen - reward_rejected)).mean()        accelerator.backward(loss)        if accelerator.sync_gradients:            accelerator.clip_grad_norm_(lora_parameters, 1.0)            optimizer.step()            scheduler.step()            optimizer.zero_grad()

在每个训练 step 中，执行如下操作：

1. 计算参考模型 model_ref 的对数概率 log_prob_ref。
2. 计算待训练模型 model 的 log_prob。
3. 计算两个 Reward：分别对 chosen 和 rejected 样本计算 reward（即与 reference model 输出对数概率的差值）。
4. DPO loss：使用 -logsigmoid(beta * (r_c - r_r)) 作为 loss，其中 beta 是温度系数。
5. 反向传播、梯度裁剪、迭代。

训练效果

最初尝试训练时遇到了一些问题：

1. 一开始学习率设太高了（5e-5），结果模型在训练中后期迅速崩坏，什么都不输出（摆烂是吧？？？）。遂将学习率调至1e-6，问题解决。
2. 由于我在之前做SFT时的数据量不是很大，如果这里将全部数据（大约10万条）全部用于训练，模型会忘记如何正常回答问题，对于所有问题都一视同仁地拒绝回答（或许边DPO边SFT可以缓解这个问题）。于是，取出25000-30000条数据用于训练即可。

分别观察Chosen Reward、Rejected Reward以及Loss的趋势：

训练过程相比于PPO更加稳定，模型也逐渐能够给出符合我们希望的正向价值观的输出，下面是几个DPO模型与SFT模型的面对诱导性问题和正常问题的回答对比示例：

• 诱导性问题：

• 正常问题

可以看出，DPO 训练后的模型在面对诱导性问题时表现出更强的拒绝能力，而在正常问答中依然能保持良好响应，整体效果令人满意。

本文涉及的完整代码已整理并开源，详见：

引用站外地址，不保证站点的可用性和安全性

tiny-llm-training

GitHub

本篇将结合我自己实现的 RLHF 流程，来介绍 PPO 算法在其中是如何具体应用的。

其中涉及到的代码均位于此仓库：

引用站外地址，不保证站点的可用性和安全性

tiny-llm-training

GitHub

如有实现上的误区还请指出！

为什么要做RLHF

虽然模型已经能够回答地对题，但其生成行为仍受到训练语料限制，容易出现回答不符合人类偏好的问题。实际使用中，我们微调好的模型经常无法分辨问题是否得当，会毫无保留地“畅所欲言”，比如下面的prompt：

我们训练的模型若有其事地列举了一堆看上去很有道理的相关步骤，然而我们其实希望它拒绝回答这一类价值观错误的问题。

因此，我们希望通过 RLHF 的训练，让模型逐步学会“什么该说，什么不该说”——换句话说，就是让它形成符合人类价值观的偏好，比如学会拒绝回答不当的问题。

那问题来了：怎么把前面提到的 PPO 算法，真正应用到大语言模型的训练里？

其实思路和标准的强化学习流程是类似的。我们首先需要搞清楚语言模型里的trajectory（动作轨迹）怎么定义。Agent 自然就是我们之前已经指令微调过的模型，而考虑到语言模型的特点——它是一个一个 token 地生成回复——我们可以直接把从一个 prompt 出发，模型调用 generate 方法生成的一整段新回复，当作一条 trajectory。

每个 token 的选择就相当于一次动作，动作空间是整个词表，而每个动作的概率来自模型输出的 softmax 值。

而最终的Reward，则由我们前面训练好的Reward Model提供。

数据集处理

本次实践中，我使用的对比数据集与前面训练Reward Model时相同，使用了OpenLLMAI/comparison_data

里面的数据基本都是一些比较危险的指令。下面是两条数据的示例：

对数据的处理过程也非常简单，我们暂时只需要取它的query部分，然后让模型根据query去生成内容就行了。

由于需要模型在数据后面继续生成新的数据，因此这里在对数据做padding时，就不能像以往那样把[PAD]填充到数据后面了，我们选择在数据的前面进行padding。

这便是全部的数据处理流程。详细的数据集代码见此文件。

训练阶段

在训练的过程中，我们会用到四个模型，分别是：

• Actor Model：我们主要训练的模型就是它，也就是强化学习里的 Agent。
• Reference Model：参考模型，主要为了防止把Actor Model训崩。还记得前面曾提过的需要对新策略和原始策略之间的KL散度进行惩罚吗？这个模型的目的就是约束住Actor Model的变化幅度，否则，模型容易陷入灾难性遗忘问题。注意：这个模型不需要训练。
• Critic Model：评价模型，相当于强化学习算法中对每个状态值函数的预测函数，需要在训练中微调。
• Reward Model：奖励模型，在模型完成一个trajectory后（预测完整个句子后），给出一个最终得分。注意：这个模型同样不需要训练。

在训练开始之前，我们需要完善一些训练中需要用到的方法，也就是在前面PPO算法中提到的一些值的具体计算方法。

动作概率

在 RLHF 的 PPO 算法中，动作概率 指的是语言模型在某个位置生成该 token 的概率。假设通过一个 prompt 生成了一个 response，那么其 动作序列 $\{a_t\mid t=0,\dots,T-1\}$ 就是新生成的 response token 的序列，而对应的 策略概率 可以按如下公式进行计算：

上式中：

• $\pi_\theta$ 为模型策略。
• $x$ 为prompt，$a_{<t}$ 表示生成的前 $t-1$ 个 token的序列，$a_t$ 表示 t 位置生成的token。
• $f_\theta(x,a_{<t})$ 表示生成的前$t-1$ 个token序列对应的 logits 值。
• $[a_t]$ 表示取出下标为 $a_t$ 处的值，也就是取出对应位置上的概率值。

计算函数如下：

def calculate_action_logsoftmax(logits, chosen_ids):    log_probs = logits.log_softmax(dim=-1)    return log_probs.gather(2, chosen_ids.unsqueeze(-1)).squeeze(-1)

由于generate函数不会返回生成序列的logits值，为了得到这个值，我们需要将生成出来的完整序列重新输入模型，通过forward方法以获取到序列对应的logits：

logits_old = model(generated_ids, generated_attention_mask).logits

K-L散度

K-L散度衡量两个概率分布之间的差异程度，在RLHF中被用以稳定训练。实际训练时，计算Reference Model和Actor Model输出分布的K-L散度值，作为奖励惩罚项，也就是不希望K-L散度值太大。

一种常见实现是直接计算对数概率差：

kl = -coeff * (log_prob_old - log_prob_ref)

当策略模型生成的动作概率与参考模型相差较大时，则给一个比较大的K-L散度加在Reward上，作为惩罚项，提醒模型冷静更新参数，不要在离谱的道路上越走越远（灾难性遗忘）。

一般而言，强化学习算法的每个动作都得有个reward作为反馈，但我们的Reward模型仅给整个句子打了一个分，那怎么办呢？

这里就可以采用这个K-L散度作为每个生成的token（采样动作）的reward，考虑到最后一个token的特殊性，我们将Reward Model给出的值添加到最后一个token对应的K-L散度之上。由此计算得到了每个动作对应的reward。

@torch.no_grad()def calculate_reward_with_kl(end, log_prob_old, log_prob_ref, reward, coeff=0.1):    """    Calculate the reward with KL divergence penalty.    KL-Reward for each non-eos token with index `idx` is calculated as        -0.1 * (log_prob_old[idx] - log_prob_ref[idx])    For eos token with index `end_pos`, the KL-Reward is calculated as        -0.1 * (log_prob_old[end_pos] - log_prob_ref[end_pos]) + reward.clamp(-5, 5)    """    kl = -coeff * (log_prob_old - log_prob_ref)    reward_kl = kl.clone()        for idx, end_pos in enumerate(end):        if end_pos >= reward_kl.shape[1]:            end_pos = -1        reward_kl[idx, end_pos] += reward[idx].clamp(-5, 5)        return kl, reward_kl

时序差分误差与优势函数

使用Reward Model中对每个句子计算得到的value向量作为每个动作的状态值的估计。这样，我们可以基于标准的时序差分方法，计算每个位置的 TD 残差：

然后，将prompt部分截去，得到最终的TD残差序列，代码如下：

@torch.no_grad()def calculate_td_delta(reward_kl, value_old, gamma=1.0, prompt_length=0):    V_s = value_old[:, :-1]    V_next = value_old[:, 1:]    td_delta = reward_kl + gamma * V_next - V_s    return td_delta[:, prompt_length - 1:]

对于优势函数的估计方法，已经在前面介绍过了，我们可以使用刚刚得到的TD残差序列来估计优势函数：

@torch.no_grad()def calculate_advantage(td_delta, lmbda=0.95, gamma=1.0):    advantage = []    adv = 0.0    for delta in td_delta.flip(dims=[1]).unbind(dim=1):        adv = lmbda * gamma * adv + delta        advantage.append(adv)    advantage.reverse()    return torch.stack(advantage, dim=1)

训练流程

在有了上面这些基本的函数后，我们就可以运行PPO算法了。下面是用Python语法给出的算法伪代码：

for batch in dataloader:    with torch.no_grad():        ### 通过 prompt 生成一些数据        generated_ids = model.generate(batch['input_ids'], batch['attention_mask'])        generated_mask = (generated_ids != pad).long()        ### 计算 log_probs_old, log_probs_ref        logits_old = model(generated_ids, generated_attention_mask).logits        logits_ref = model_ref(generated_ids, generated_attention_mask).logits        log_prob_old = calculate_action_logsoftmax(logits_old[:, :-1], generated_ids[:, 1:])        log_prob_ref = calculate_action_logsoftmax(logits_ref[:, :-1], generated_ids[:, 1:])        ### 计算 value 和 reward        value_old = model_critic(generated_ids, attention_mask=generated_attention_mask)        reward = model_reward.get_reward(generated_ids, attention_mask=generated_attention_mask)    ### 计算 kl 散度，并叠加到 reward 上        kl, reward_kl = calculate_reward_with_kl(log_prob_old, log_prob_ref, reward)        ### 计算 TD 残差，并估计优势函数        td_delta = calculate_td_delta(reward_kl, value_old)        adv = calculate_advantage(td_delta)    ### 计算待更新的策略下的动作概率，以及 ratio    logits_new = model_actor(generated_ids, attention_mask=generated_attention_mask).logits    log_prob_new = calculate_action_logsoftmax(logits_new[:, :-1], generated_ids[:, 1:])    ratio = ((log_prob_new[:, max_length - 1:] - log_prob_old[:, max_length - 1:])                         * generated_attention_mask[:, max_length:]).exp()    ### 计算 actor loss    loss_actor_1 = adv * ratio    loss_actor_2 = adv * torch.clip(ratio, 1 - eps, 1 + eps)    loss_actor = -torch.min(loss_actor_1, loss_actor_2).mean()    ### 计算 critic loss    value_new = model_critic(generated_ids, attention_mask=generated_attention_mask)    loss_critic_1 = (value_new[:, max_length:] - adv - value_old[:, max_length:])[:, :-1] ** 2    clip_value_new = torch.clip(value_new, value_old - eps, value_old + eps)[:, max_length:]    loss_critic_2 = (clip_value_new - adv - value_old[:, max_length:])[:, :-1] ** 2    loss_critic = torch.max(loss_critic_1, loss_critic_2).mean()        ### backward & step    (loss_actor + loss_critic).backward()    optimizers.step()    schedulers.step()    

训练效果

在训练过程中，我们重点监控两个指标：KL 散度（KL/mean）和平均奖励（Reward/mean），用于衡量模型策略的变化幅度与优化方向的有效性。

上图展示的是当前策略与参考模型之间的 KL 散度，反映了两者在生成策略上的偏离程度。可以看到，KL 值在训练初期迅速上升，约在第 1000 步左右达到峰值后逐渐回落。这种趋势是 PPO 训练中的典型现象，表明策略开始收敛，更新变得更加稳定。同时，KL 惩罚项有效抑制了策略的大幅漂移，防止了训练过程中的策略崩坏。

而下图记录了模型在训练过程中的平均奖励（Reward/mean）变化情况。可以看到，Reward 在初始阶段整体为负，说明模型生成的响应尚未获得足够的正向反馈。随着训练推进，Reward 曲线逐步上升，说明模型输出越来越符合 Reward Model 的偏好。

不过，在写这篇博客时，训练才进行了不到五分之一，因此这里仅展示了训练早期的指标变化趋势。从现有的趋势来看，训练整体进展比较稳定。

从一些例子也可以看出，模型在面对这种问题时，已经倾向于给出更加符合人类偏好的回答。对于带有诱导性或存在争议的问题，模型不再简单地照单全收，而是能适度表达拒答、提醒或提出更中立的观点。这种行为变化正是 RLHF 带来的对齐效果：通过奖励信号引导模型学习价值导向明确、语用更恰当的响应策略。

训练代码见此文件。比较奇怪的是，训练最开始几个迭代，模型在推理时有时会遇到下面这种报错：

/pytorch/aten/src/ATen/native/cuda/TensorCompare.cu:112: _assert_async_cuda_kernel: block: [0,0,0], thread: [0,0,0] Assertion `probability tensor contains either `inf`, `nan` or element < 0` failed.

初步怀疑可能是数据类型（float16）的问题，不过训练跑起来以后就不影响了。

至此，我们已经粗略复现了RLHF训练流程，训练也产生了一定的效果，模型在处理敏感或主观性问题时，已有了更加稳妥和人类偏好的回应倾向。然而，我们也注意到了，PPO算法也存在着明显的局限性：

1. 训练过程复杂：PPO算法需要多阶段训练模型，且流程繁琐。
2. 显存占用较多：PPO算法训练过程中需要多个模型相互配合，如果将它们都放在CUDA上，则会占用非常多的显存，对硬件配置要求较大。
3. 训练稳定性较差：PPO算法的训练过程对参数十分敏感，超参数若设置不当，训练容易崩盘。

因此，事实上目前这个算法在工程上已经很少使用了，相关领域开始转向更简洁、高效的替代方法。博主也将逐步尝试这些新范式的实现，后续会在博客中持续更新其他更好的算法的原理与实践过程。

模型结构

Reward Model 有两种主流的形式：

• ORM（Outcome Reward Model）：对序列整体生成一个得分。
• PRM（Process Reward Model）：在序列的生成过程中，分多个步骤，对每一步分别进行打分。

考虑到训练的模型比较简单，我们采用ORM的形式。

Reward Model作为一个为语言模型的生成结果打分的模型，自然需要一定的语言能力，因此通常会选择与策略网络相同架构的语言模型，作为Reward Model的backbone。但与策略网络不同的一点是，Reward Model不输出token序列的概率分布，而是对整个输入序列计算一个标量，作为序列得分，用于评估序列的质量。

具体而言，我们的做法是在backbone的最后接上一个回归头（Regression Head），通常它只是一个简单的线性层，以backbone输出的最后一个token的最后一层隐藏状态作为输入，并输出一个标量值作为Reward。

另外还有一种被称为Token-Level Reward Model的评估方案，一看就知道，是对句子中的每一个token计算得到上面的标量值。我在训练时采用的就是这种方案。

数据 & 训练方法

数据准备方面，常见的数据格式是针对每一条prompt，准备两个候选回答，并标注哪个回答更符合人类偏好。一种典型的输入格式如下表所示：

在训练时，我们仍然将数据拼接为与前面训练SFT时的相同格式，即：prompt_ids + bos_token_id + response_ids + eos_token_id，不过这里存在两条不同的response，因此每条数据最终会生成两条序列数据。

我们将两条序列数据分别经过Reward Model的backbone，再将其最后一层隐藏状态作为回归头的输入，最终得到两个得分序列，记为 v_chosen和v_rejected。

然后我们逐token计算两个序列的得分之差：v_chosen - v_rejected。

最终，我们按下面方式进行计算得到两个序列的Pair-Wise Loss：

loss = -F.logsigmoid(v_chosen - v_rejected)

为了保证训练稳定性与泛化能力，我们在训练 Reward Model 时通常不对整个模型进行微调，而是采取参数冻结+局部调整的方式，具体而言，我们会将backbone模型的参数冻结，而仅对回归头进行训练。在数据集规模较大的时候，也会在backbone中插入少量LoRA层进行微调，在保证训练稳定性的同时适当增强模型的理解能力。

在我的训练实践中，采用了第一种手段，即只训练回归头。

可以看到随着训练的进行，两种回复得到的Reward差距也有了明显提升。

本文涉及到的训练代码详见下面仓库：

引用站外地址，不保证站点的可用性和安全性

tiny-llm-training

GitHub

• 数据集文件：RM/dataset.py
• 模型文件：RM/model.py
• 训练文件：rm_training.py

到了这里，我们就已经把 RLHF 中的关键角色、主要算法介绍完了。下一篇文章，我们将进入大模型训练的最后一块拼图：RLHF，看看它是怎么把这些角色串联起来、协同合作，让大模型更贴近人类偏好。

为了进一步提升模型输出的质量和对齐程度，研究者引入了基于人类反馈的强化学习（RLHF）。通过奖励模型对不同响应进行偏好打分，再利用强化学习算法对语言模型进行微调，使其在生成文本时更加贴合人类价值与偏好。其中，PPO（Proximal Policy Optimization） 是 RLHF 阶段最常用的优化算法，也是在 InstructGPT 和 ChatGPT 等模型中取得显著效果的关键技术。

本文将先从这个PPO算法入手，拆解此算法的核心理论。

策略梯度算法

PPO算法是一种On-Policy的策略梯度算法，关于策略梯度，我在之前的一篇文章中曾提到过其核心公式的推导：

这里 $J(\theta)=\mathbb{E}_{s\in S}[V_{\pi_\theta}(s)]$ 表示采取 以 $\theta$ 为参数的动作策略 $\pi_\theta$​ 时，能获得的所有状态下的回报的期望值。

简单来说，我们希望优化 $\theta$，让 $J(\theta)$ 变得更大。但策略梯度算法在实际应用时极不稳定，这种更新的方法容易让策略变化太剧烈，尤其是对于像大语言模型这样参数量巨大的网络（也算一种策略网络）而言，更是难以承受。为了引入对策略变化的约束，后续又提出了一些新的方法，例如TRPO、PPO等，前者直接在训练时强行限制新旧策略之间的KL散度，而后者则提出了一种更简单并且非常有效的手段。

我这里也以一个简单的小游戏：flappy bird，为具体的例子，对PPO算法进行了一个简单的实践。

引用站外地址，不保证站点的可用性和安全性

flappy-bird-ppo

GitHub

PPO算法

我们回到 $J(\theta)$ 期望内部的 $V$ 函数的定义：

我们要最大化 $J(\theta)$，其实就相当于最大化 $V$ 函数：

将 $V$ 函数中的期望展开为积分：

我们发现，在给定状态 $s_t$ 的情况下，$Q(s_t,a)$ 为关于动作 $a$ 的单变量函数，此时有两种情况：

1. $Q(s_t,a)>0$，说明它给我们带来的价值是正的，意味着这是一个比较好的动作，我们就应该进一步提升当前状态下这个动作被取到的概率，也就是 $\pi_\theta(a\mid s_t)$ 的值。
2. $Q(s_t,a)\le 0$​​，说明它没有给我们带来价值或带来了负价值，意味着这个动作比较差，同理我们应该进一步降低当前状态下这个动作被取到的概率。

重要性采样

对于上面的两种情况，我们实际上不关心当前动作概率具体的值是多少，而更关心是否要将此概率进一步提升或降低，那么很自然地会想到，可以将优化前后的概率值做一个比值：

我们可以固定分母，优化分子，同时这个值还可以体现新概率相对于旧概率的变化。

对于情况 1，我们希望新概率变大，故需要对 $\pi_\theta(a\mid s_t)_{\text{new}}$ 梯度上升；对于情况 2，我们希望新概率变小，故需要对 $\pi_\theta(a\mid s_t)_{\text{new}}$ 梯度下降。合而为一，我们总是需要对下式：

进行梯度上升。

这就将原先的优化目标转化为了：

这个操作也被称为重要性采样。

约束

回想策略梯度算法的缺陷：难以在优化过程中控制新旧策略的差异，导致策略剧烈波动，使得训练不稳定。

在经过了重要性采样以后，如何规避这个缺陷？

盯着重要性采样引出的优化目标看，这不答案已经拍脸上了吗？直接约束新旧概率之间的差距不就行了？

对于这件事，PPO算法使用的约束方法是对新旧概率的比值，也就是优化目标左边那一坨东西，进行一个裁剪：

将概率的比值保持在区间 $[1-\epsilon, 1+\epsilon]$​​​ 之内，简单粗暴地控制了策略的差异。由于clip在区间外不产生梯度，这个操作使得与原策略差距过大的动作不会让模型产生参数更新。让策略模型在训练过程中能够逐步收敛，不至于在一次更新中产生过大的变化。

另外，在大语言模型的训练中，我们还要对新策略和原始策略之间的KL散度进行惩罚，这同样也是为了防止新策略跑的离旧策略太远。计算KL散度有多种方式，这里暂时不管。

优势函数

设想我们的 Agent 当前处在一个水深火热的状态 $s_t$ （水和火怎么来的你先别管），在这个糟糕的状态下，无论这个 Agent 采取哪个动作 $a$，价值函数 $Q(a\mid s_t)$​ 都是负的，由刚刚重要性采样部分得出的结论，我们发现对于每个动作都要降低它被取到的概率，这不就是摆烂么。难道对于 Agent 而言，原地摆烂才是最优解？

恐怕大部分心理承受能力比较普通的人类玩家面对这种情况都会选择战术性摊手摆烂吧。

但 Agent 毕竟不是情绪化的玩家。作为没有任何感情的 Bot，它应该做的绝对不是摆烂，而是在逆境中找到那一记也许能够力挽狂澜的神之一手，无论最终结局如何。

从强化学习的角度来看，我们先前优化目标中的 $Q$ 函数就显得不够合理了，因此需要找出一个新的函数来代替 $Q$​ 函数，其能够更准确地衡量某一个动作在当前局势下的优劣程度。

这便是优势函数。

我们定义 $s_t$ 状态下，采取动作 $a$ 的优势函数如下：

也就是采取了 动作 $a$ 以后，能得到的预期回报与「遵循策略时能带来的预期回报的期望」之差。

说白了就是衡量你这个动作能让局势改善多少。如果有所改善，说明该动作是比原策略更优的，我们要增大这个动作的概率，反之亦然。

于是我们的优化目标变为了：

不过这个优化目标还并不完整，直接使用这个函数进行梯度上升仍有一定问题，且看下文。

最终的目标函数

前文提到的目标函数存在一定的问题，因此在实际的应用中，还需要对优化目标进行以下 $\min$ 计算：

方便起见，定义 $r \overset{\triangle}{=} \frac{\pi_\theta(a\mid s_t)_{\text{new}}}{\pi_\theta(a\mid s_t)_{\text{old}}}$​，则 PPO 算法最终的优化目标如下：

对于这个操作，可能有一些初学者会有疑惑：已经clip了为什么还要取min？这一点许多其他博客都没有提到，其实可以简单分析一下如果不取min会发生什么预想之外的事：

1. 第一种情况：$A(s_t,a)>0$ 时，此时这个动作是好的动作，因此需要把动作概率向上调整。此时又分为三种情况：

   • $r\ge1+\epsilon$：此时，优化目标会把 $r$ 进行一个 clip，变成 $1+\epsilon$，此时由于clip函数在阈值外不产生梯度，优化目标就不会对策略网络产生梯度累积，这意味着这个概率过大的动作不再被用于参数的更新，这是合理的。

   • $1+\epsilon>r>1-\epsilon$：此时不截断，正常计算梯度，正常更新策略网络参数，也非常合理。

   • $r\le1-\epsilon$​：此时，与前面第一条子情况同理，由于产生了截断，优化目标同样不会对策略网络产生梯度累积，意味着这个概率过小的动作也没有被用于网络参数的更新，但这是不合理的：因为我们本应该将这个动作的概率调大。

2. 第二种情况：$A(s_t,a)\le0$ 时，与第一种情况同理，我们会发现对于 $r\ge1+\epsilon$​ 的动作，将由于clip运算阻断了梯度，从而不参与网络参数的更新，这同样是不合理的。

对于上述没有取 min 运算的情况，有几条不合理性，而这些不合理都可以通过做min运算得到解决。我们同样分类讨论：

1. $A(s_t,a)>0$ 时，需要把动作概率向上调整，此时若：

   • $r\ge1+\epsilon$：取 min 运算后，得到的是截断后的值，故梯度反馈为0，不更新参数，非常合理。
   • $1+\epsilon>r>1-\epsilon$：min 运算不产生效果，正常计算梯度，更新参数，非常合理。
   • $r\le1-\epsilon$：min 运算后，得到的是未被截断的值，故梯度反馈不为0，能够正常更新参数，非常合理。

2. $A(s_t,a)\le0$ 时，需要注意此时 min 运算作用在两个负数上，故会得到与前面相反的结果，即对于$r\ge1+\epsilon$ 的动作，进行了min 运算后得到的反而是未被截断的值，故这种情况下仍能够正常更新参数，也变得合理了起来！

因此，这个取min运算是非常重要的，如果没有这个运算，在某些情况下参数会得不到我们希望的更新。

如何估计优势函数

优势函数这个东西看上去十分抽象，要怎么去估计呢？

为方便起见，我们记 $A_t^{(k)}$ 为 $A(s_t)$ 的 $k$ 阶近似估计，$Q_t^{(k)}$ 为 $Q(s_t,a)$ 的 $k$ 阶近似估计，$V_t\overset{\triangle}{=}V_{\pi_\theta}(s_t)$ ，写出 $t$ 时刻优势函数的 1 阶近似估计：

我们发现，它正好相当于 $t$ 时刻的TD残差 $\delta_t$。

同理，2 阶近似估计：

将其做一些变换，得到：

同理，我们也可以写出 $k$ 阶近似估计的通项：

同样可以将上式变成：

恰好是TD残差 $\delta$ 序列的带衰减累计求和。

近似阶数 $k$ 越大，我们得到的估计值的偏差越小，但其中包含的随机变量（$\{R_{t+i}\ \mid \ i=0,\dots,k-1\}$）越多，因此方差反而变大。

接下来有个操作叫 $\lambda-\text{return}$ 算法，它的作用是平衡这些估计的偏差与方差。

简而言之，该方法使用一个 $(0,1)$ 上的系数 $\lambda$ ，对这些估计进行加权求和，即：

阶数越高的估计值，权重越小，以此降低其方差。由此得到的和式能够兼顾偏差和方差。

由于所有的 $A_t^{(i)}$ 都是 $A_t$ 的估计，上式的期望差不多相当于 $\frac{1}{1-\lambda}A_t$, 因此我们还应该乘上一个系数 $1-\lambda$，才能得到真正对 $A_t$ 的估计：

这便是广义优势估计 (GAE) 算法。

对于PPO算法的基本原理就讲到这儿，接下来让我们来看看这个算法是如何应用在大语言模型的训练流程中的。为了让PPO能够发挥作用，我们还缺少一个模块，那就是用来计算上文中多次出现的 $R_i$ 的值（Reward）的模型，也就是所谓 Reward Model，下一篇文章，博主将介绍如何训练一个 Reward Model。

我们已经知道，在大规模语料数据上进行的预训练使模型具备了广泛的语言知识，但它学到的仅仅是“如何预测下一个词”的通用能力，距离解决特定任务（如问答、摘要、对话）还有相当的差距。

而监督微调正是让大语言模型从通用语言能力升级到任务导向能力的必经之路。换言之，SFT让模型不仅仅局限于能够把话写通顺，还能写的对题。

引用站外地址，不保证站点的可用性和安全性

tiny-llm-training

GitHub

监督微调是什么

监督微调（Supervised Fine-Tuning, SFT）是指在预训练模型的基础上，利用一个特定任务的人类标注数据集对模型进行进一步训练，从而教会模型如何更好地执行具体指令或任务，例如问答、摘要、对话、翻译等。

与预训练阶段在海量无标注自然语言数据集上进行训练不同，SFT 使用成对的输入-输出样本，通过显式的任务目标，引导模型“怎么按人类意图作答”。这一阶段通常只微调模型的一部分参数，例如最后几层，既能保留预训练所得的通用语言知识，又能高效适应特定任务。

数据集 & 处理方法

这一阶段的训练数据可能长这样：

{    "prompt": "请简要介绍一下蔡徐坤是谁。",    "response": "蔡徐坤是中国内地流行歌手、演员、音乐制作人，曾因参加《偶像练习生》节目而走红。"}

不过，为了适合语言模型的输入格式，这类数据通常会被拼接成统一的 prompt 模板格式，明确区分“指令”和“回答”的结构，引导模型学会角色扮演和任务对齐。例如：

Human: 请简要介绍一下蔡徐坤是谁。Assistant: 蔡徐坤是中国内地流行歌手、演员、音乐制作人，曾因参加《偶像练习生》节目而走红。

或者这种格式：

### Instruction:请简要介绍一下蔡徐坤是谁。### Response:蔡徐坤是中国内地流行歌手、演员、音乐制作人，曾因参加《偶像练习生》节目而走红。

在实际训练时，这些格式会被进一步编码成 token 序列，并通过 label masking 的方式只对回答部分计算损失，这是因为我们的目的是让模型学会如何输出回答部分。下面代码给了一个具体的例子：

def __getitem__(self, idx):    data = self.dataset[idx]    instruction = data['instruction']    input = data['input']    output = data['output']    if input:        prompt = f"指令:{instruction}\n{input}\n输出:"    else:        prompt = f"指令:{instruction}\n输出:"    prompt_ids = self.tokenizer.encode(prompt, add_special_tokens=False)    response_ids = self.tokenizer.encode(output, add_special_tokens=False)    input_ids = prompt_ids + [self.tokenizer.bos_token_id] + response_ids    labels = [-100] * (len(prompt_ids) + 1) + response_ids    input_ids = input_ids[:self.max_length]    labels = labels[:self.max_length]        if len(input_ids) < self.max_length:        input_ids += [self.tokenizer.eos_token_id]        labels += [self.tokenizer.eos_token_id]    pad_len = self.max_length - len(input_ids)    if pad_len > 0:        input_ids += [self.tokenizer.pad_token_id] * pad_len        labels += [-100] * pad_len    attention_mask = [1] * (self.max_length - pad_len) + [0] * pad_len    return {        "input_ids": torch.tensor(input_ids, dtype=torch.long),        "attention_mask": torch.tensor(attention_mask, dtype=torch.long),        "labels": torch.tensor(labels, dtype=torch.long)    }

上述代码的完整版见此文件。该方法做了两件事：

• 将数据处理为 prompt_ids + bos_token_id + response_ids + eos_token_id的形式，构成完整的输入序列。
• 使用-100为labels中的prompt部分以及pad部分打上掩码（因为这些内容模型不需要学习）。

LoRA

LoRA（Low-Rank Adaptation） 是一种轻量级参数微调方法，其核心思想是矩阵的低秩分解，具体而言，是在不改变原有大模型参数的基础上，以两个低秩矩阵的乘积的形式添加一个可学习的增量参数模块，从而达到高效微调的目的。

在SFT中，LoRA是一种常见的微调手段，这是因为对大模型进行全量微调不仅参数量太大、显存开销高，而且容易干扰原预训练模型（过多学习指令数据集导致模型忘记原有的语言能力），相比之下，LoRA 只在模型中插入少量可训练参数，既降低了资源需求，又避免了灾难性遗忘，使得微调过程更稳定、灵活，适合小数据集和多任务扩展场景。

LoRA 在不修改原始权重矩阵 $W\in\mathbb{R}^{m \times n}$ 的前提下，通过添加一个低秩矩阵近似项 $\Delta W$ 来引入可学习的增量：

其中 $A\in\mathbb{R}^{n \times r}$ 和 $B\in\mathbb{R}^{r \times m}$ 是两个秩为 $r$ 的矩阵。在训练时，我们冻结原始权重矩阵 $W$，仅学习 $A$ 和 $B$，从而极大的减少了可学习的参数量，同时还能保证原始模型的表达能力不受过多干扰。

一个简单的LoRA层实现：

from torch.nn import Moduleclass LoraLinear(torch.nn.Module):    def __init__(self, linear, r=128, alpha=32):        super().__init__()        self.linear = linear        self.r = r        self.alpha = alpha        self.scale = alpha / r        self.lora_A = torch.nn.Parameter(torch.randn(linear.in_features, r) * 0.1)        self.lora_B = torch.nn.Parameter(torch.zeros(r, linear.out_features))        self.linear.weight.requires_grad = False    def forward(self, x):        y = self.linear(x)        y += self.scale * (x @ self.lora_A @ self.lora_B)        return y

训练过程

在完成数据预处理和模型结构准备（如插入 LoRA 模块）后，监督微调的训练流程与预训练阶段非常类似，核心仍是语言模型的自回归目标：

其中 $x$ 和 $y$ 分别为用户的prompt和人类标注的参考回答。

训练流程的详细代码见此文件。

到了这里，我们已经了解了大语言模型训练中的第二块拼图 —— 监督微调（SFT）。它的核心目标，其实就是让模型“听话”：不仅能说得通顺，还要能说得符合人类的预期。

接下来，我们还希望模型变得更聪明——通过人类反馈优化（比如 RLHF），进一步学会给出更加符合人类偏好的回应。

为了解决这个问题，我们需要从文本如何被编码成模型可读的序列说起。

早期的编码方案

字符级编码

以英文为例，在早期的文本编码方案中，每个字符都被单独视为一个token，这也被称为字符级编码。例如，对于句子：”hello world!”，它的token序列（尚未映射为数字）为：['h', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd', '!']。

这种编码方式的优点十分明显：实现简单、通用性（可扩展性）强，词表较小，可以处理几乎所有语言中的所有字符，不会存在OOV（Out-Of- Vocabulary）问题。然而，它也存在显著的局限性：

• 由于每个字符都被单独编码，序列长度显著增加，模型在处理长文本时计算开销大，训练效率低。
• 字符粒度太细，模型难以捕捉词语层面的语义结构——试问有谁是按字符理解语言的？

词级编码

相比字符级编码，词级编码以「词（word）」作为基本单位，将每个词直接映射为一个 token。这是人类语言理解的自然粒度，因此这种编码方案在早期 NLP 模型中（如 Word2Vec、LSTM）被广泛采用。

同样对于句子：”hello world!”，采用词级编码得到的token序列为: ['hello', 'world', '!']。

这种编码方式的优点在于：

• 直观，与人类语言习惯一致，每个token具有完整的语义信息。
• 编码序列短，处理效率高。

但这种编码方式也存在缺点：

• 每个词都得编码成一个token，导致词表庞大。

  Many people estimate that there are more than a million words in the English language. In fact, during a project looking at words in digitised books, researchers from Harvard University and Google in 2010, they estimated a total of 1,022,000 words and that the number would grow by several thousand each year.

  English Live

• 词表虽然变大了，但出现未登录词的可能性反而上升了：一旦有什么新的单词没收录在表里，模型只能以<unk>代替，导致信息损失严重。

• 跨语言迁移能力较差。

我们可以看到，前述的两种分词编码方法要么粒度太细，模型读不懂语义；要么粒度太粗，新词一来就懵逼，只能用 <unk> 顶上。可见这两种方式都不太理想。

为了取得两者的平衡，让模型在表达能力与编码效率之间取得更好的平衡，子词级编码方法被提出。这类方法试图将文本划分为比「词」更小、但比「字符」更有语义的信息单元，从而兼顾词汇覆盖率与建模能力。其中最具代表性、也是目前应用最广泛的方案，就是BPE（Byte Pair Encoding）算法。

BPE 算法

如前文提到的，在自然语言处理中，研究者经常会面临两个极端：

• 下策：以字符为编码单位，不容易OOV，但缺点过于致命：模型完全不知道这些字符合起来是什么意思，学习难度过大。

• 上策：以词为编码编码单位，可以保留完整的语义信息，例如：internationalization这个词整体作为一个token，语义信息丰富，看上去省事省心一步到位。然而，问题来了——如果是internationalizations呢？多了个 s，抱歉，模型词典里没有，不认识。由此可见，词级编码面临一个大bug：词表巨大、组合爆炸、扩展性差。你得穷尽所有单词的各种变形、拼写版本……搞得像字典编辑部天天加班。

于是，一种「花下策的成本，达到上策的效果」的中策应运而生：BPE算法。（当然，实际上成本肯定是要高于下策的，但性价比已经相当高了）

其实这个算法很早就已经被提出了，当时是用于数据压缩，其基本思路是通过寻找文本中出现频率最高的相邻字节对，将其合并为一个新的字节，然后重复该操作直到达成某种终止条件。

本文略过该算法在数据压缩领域的应用，直接介绍如何将这种思路用于tokenizer。

算法流程概览

偷懒了，这里直接放个训练过程的伪代码。

至于训练结束后如何进行分词，主要就是用了上面算法输出的合并规则序列 $\mathcal{M}$​​，分词过程的基本思路是：

实例演示

以一个简单的语料集为例，假设我们拿到了数据：

low lower lowestplay played playing playerhappy happier happiestrunning runs runnerinternational internationalization internationalizeunderstanding misunderstand misunderstanding

我们首先拿到所有单词按字符的拆分，同时在末尾添加一个符号</w>表示词尾：

将所有出现过的字符记录下来，作为当前的词表（词表大小为19）：

{'w', 'r', 'e', 'u', 'a', 't', 'i', 'z', 'n', 'y', 'm', '</w>', 'd', 'g', 'h', 'p', 'l', 's', 'o'}

假设我们的目标词表长度为25。

我们统计每一对相邻字符出现的频率，并按频率从高到低排序，我们得到相邻字符对的频率表（省略了后面的部分）：

('e', 'r'): 10('i', 'n'): 7('u', 'n'): 6('n', 'a'): 6('n', 'd'): 6('s', 't'): 5('r', '</w>'): 4...

找到出现频率最高的组合：('e', 'r')，然后遍历所有拆分列表，将所有该组合进行合并，得到新的单词拆分方式：

将组合er添加到词表中，不过此时单词的拆分中仍存在独立的e和r，故将它们保留在词表中。当前词表大小：20。

继续统计每一对相邻字符（此时，由于我们前面合并了e和r，故在统计时需要把er看作一个整体）。我们得到新的相邻字符对的频率表：

('i', 'n'): 7('u', 'n'): 6('n', 'a'): 6('n', 'd'): 6('s', 't'): 5('er', '</w>'): 4...

合并i与n，将in加入词表，不移除i和n。当前词表大小：21。

统计新的相邻字符频率：

('u', 'n'): 6('n', 'a'): 6('n', 'd'): 6('s', 't'): 5('er', '</w>'): 4...

合并u与n，将un加入词表：

此时，发现已经没有单独出现的字符u了，因此从词表中移除u。当前词表大小：21。

持续进行上述操作，直到达到下面两个终止条件之一：

1. 词表大小达到我们的预设值：本例中为25。
2. 没有可合并的高频相邻字符对。（可自定义频率阈值）

代码

from collections import defaultdictcorpus = [    'low lower lowest',    'play played playing player',    'happy happier happiest',    'running runs runner',    'international internationalization internationalize',    'understanding misunderstand misunderstanding']class BPE:    def __init__(self, corpus, vocab_size):        self.corpus = corpus        self.vocab_size = vocab_size        self.alphabet = {'</w>'}        self.word_freqs = defaultdict(int)        self.split = {}        self.merges = {}        self.initialize()        self.vocab = self.alphabet.copy()    def initialize(self):        for words in self.corpus:            for word in words.split(' '):                self.word_freqs[word] += 1                self.alphabet.update(set(word))        self.split = {word: list(word) + ['</w>'] for word in self.word_freqs.keys()}    def print_split(self):        max_len = max(len(word) for word in self.split)        for word, s in self.split.items():            padding = " " * (max_len - len(word))            print(f"{word}{padding} → {' '.join(s)}")    def get_stats(self):        pairs = defaultdict(int)        for word, freq in self.word_freqs.items():            word_split = self.split[word]            for i in range(len(word_split) - 1):                pairs[(word_split[i], word_split[i + 1])] += freq        return pairs    def merge_pair(self, pair):        self.merges[pair] = ''.join(pair)        for word in self.word_freqs:            split = self.split[word]            if len(split) == 1:                continue            idx = 0            while idx < len(split) - 1:                if (split[idx], split[idx + 1]) == pair:                    split[idx] = ''.join(pair)                    del split[idx + 1]                else:                    idx += 1    def find_single_item(self, item):        for split in self.split.values():            for i in split:                if i == item:                    return True        return False    def train(self):        while len(self.vocab) < self.vocab_size:            pairs = self.get_stats()            if not pairs:                break            sorted_pairs = sorted(pairs.items(), key=lambda x: x[1], reverse=True)            max_pair, max_freq = sorted_pairs[0]            if max_freq <= 1:                break            self.merge_pair(max_pair)            self.vocab.add(''.join(max_pair))            for i in max_pair:                if not self.find_single_item(i):                    self.vocab.remove(i)            print("Vocab size: ", len(self.vocab), end='\r')    def tokenize(self, text):        pre_tokenized_text = text.split(' ')        splits_text = [[_ for _ in word] for word in pre_tokenized_text]        for pair in self.merges.keys():            for split in splits_text:                idx = 0                while idx < len(split) - 1:                    if (split[idx], split[idx + 1]) == pair:                        split[idx] = ''.join(pair)                        del split[idx + 1]                    else:                        idx += 1        result = sum(splits_text, [])        return result    def export_vocab(self, vocab_path="vocab.json"):        vocab = {token: idx for idx, token in enumerate(self.vocab)}        import json        with open(vocab_path, "w", encoding="utf-8") as f:            json.dump(vocab, f, ensure_ascii=False, indent=2)        print(f"Saved vocab to {vocab_path}")    def export_merges(self, merges_path="merges.txt"):        with open(merges_path, "w", encoding="utf-8") as f:            f.write("#version: 0.2\n")            for pair in self.merges.keys():                f.write(f"{pair[0]} {pair[1]}\n")        print(f"Saved merges to {merges_path}")bpe = BPE(corpus, 25)bpe.train()