所以，也就对比着来看。

这本书读起来并不轻松，不管是文字上的，还是心情上的。当然，从过往读过的与明朝历史有关的书籍，其实都不轻松。之前读完《麒麟》，佩服作者对历史树洞的细节观察以及线索的串联。在宏大历史的脉络中，有很多小人物的小舞台，也很精彩。历史的“以小见大”，是一种写作技能，没有对历史的充分理解和认识，是无法去健壮主题本身，并让主题充满逻辑性。

这本书读起来很沉重。

第一，穿插在其中的各类场景比较沉重，可以说从朱抗出场，基本能猜测“回不来了”，但没想到中途之后就下线了，本以为这个老戏骨还能在哪些点上再掀起突然的故事小波澜，但没有，想想，有一定合理性。读完之后让人更有一种无助与无赖之感。比如绍祖查完案回京后的公示结果，比如绍祖的宦海浮沉，又比如田粥姐和绍祖说的那句“你我不是一样的人”，又比如胡惠兰的突然身亡。

第二，还沉重在“个人心思”。书中每个人都有自己的“心思”，又或者是沉重的负担。朱抗有他的西洋负担；田粥姐起初有王第三与绍祖之间的负担，后来又有“是否一路人”的负担；绍祖负担更多，个人与家庭、与朝廷、与老师，乃至与母亲之间对待田粥姐不一样态度的负担。然而，这些“心思”，每每都是到了最后才去诉说，反而没有得到解脱。所以，读起来很沉重。

当然，本书还沉重在历史。本书主要以一场败仗而引出的一段调查，从而牵扯出的各类沉重的事情。其中出现的各类人物，基本每个人都在一定的环境下，做了最无奈的选择。即使绍祖，也有很多无奈之举，比如查案朱抗不让喝酒，这也算一种无奈吧。

这本书读起来要费心。

《麒麟》这本，你总归在一些细节处，发现作者描写的精妙之处，前后逻辑非常严谨和自洽，而那些精妙之处，不禁让人佩服作者对人性、对历史树洞细节的观察。

而这本，确实缺少了这些，但却是需要费心去读的一本书。

这本书缺少了很多人物心理特征的描写，不会过多去替人物进行心理阐述，一些涉及心理活动的地方，基本都含糊而过，卖些关子，所以，在读的过程中，需要读者自己去思考。当然，可能却是案件调查环境恶劣，前后都有追兵，所以容不得去多想，想想，作者没这么去做，也是合理的。

因为没有心理特性活动描述，所以基本都以具象化的故事情节去进行衔接，在关键处，去弥合当初所提的那一沉思，基本到最后，你才能知道“原来是这样”。这种手法，其实个人觉得极度考验故事能力，如何让作者时刻记得人物当时的一沉思，而最后又是以怎样的惊人的事实去callback这一沉思，作者在描写朱抗的心结上，抓得比较紧。

一本书，有一千种读法，能抓住每个人读着的惊喜的点都不一样，当然，也会有一些唏嘘的故事点。

比如扣儿，作者还专门用了一章作为标题，着重体现扣儿的灵气，我也以为最后扣儿会起到一个小亮点或者牛逼的人生，但后来回京，基本故事就下线了。

比如田粥姐，总以为最后又回到当年豪爽的性格，但作者也以绍祖结婚后逐步忘却，最后穿上一遇结束。和在枯树堡、追王第三的情节反差很大。

再比如胡惠兰，突然就那么下线了，让我莫名唏嘘。

唏嘘的同时，想想，应该并不是作者太心狠，那个时候的历史本身就是沉重的，所以人物的结局亦或是突然并带沉重的。

当然，作者另一方面也转合一下，比如香芸的结局，不知是故事本身就这样，还是觉得故事太沉了，最后再诉一笔结局，顿感，作者还是比较用心的。

其他的就不多说了，只言片语，写的并不全面；历史，也无法只言片语说完。

只留待每个人潜心体悟。

(完)

—————–EOF——————

记录一些常用的财务报表公式，用于日常所用，也可用于日常企业分析。

1.1 短期偿债能力比率

流动比率=流动资产/流动负债;

速动比率（酸性测试比率）=速动资产/流动负债（速动资产=货币资金+应收账款/票据+交易性金融资产);

现金比率=货币资金/流动负债;

现金流量比率=经营活动现金流量净额/流动负债;

营运资本=流动资产-流动负债=长期资本-长期资产;

长期资本=长期负债+股东权益

1.2 长期偿债能力比率

资产负债率=负债/资产;

产权比率=负债/股东权益;

权益乘数=资产/股东权益=1+产权比率;

长期资本负债率=长期负债/长期资本;

现金流量与负债比率=经营活动现金流量净额/负债;

利息保障倍数=息税前利润（EBIT）/利息支出=（净利润+利息费用+所得税费用）/利息支出;（利息费用=费用化利息；利息支出=费用化利息+资本化利息）

现金流量利息保障倍数=经营活动现金流量净额/利息支出;

1.3 营运能力比率

时期数（流量指标）/时点数（存量指标），时点数（存量指标）应取多个时点的加权平均数，减少季节性、偶然性或人为因素的影响。

时期数（流量指标）：利润表数据、现金流量表数据;

时点数（存量指标）：资产负债表数据;

应收账款周转次数=营业收入/应收账款；（使用未计提坏账准备的多个时点的应收账款的加权平均数）

tips：如果应收账款与日俱增，但货币资金回款日益减少，则企业的赊销可能出现了严重的问题。

存货周转率=营业收入/存货；（评价存货的变现能力）（存货多个时点加权平均数）

存货周转率=营业成本/存货；（评价存货管理的业绩）（存货多个时点加权平均数）

tips：如果前端存货（原材料）占比增加，一般预示企业存在大额销售订单、未来的销售会增长；如果后端存货（产成品）占比增加，一般预示企业销路不畅、产品积压。

总资产周转次数=营业收入/总资产；（总资产多个时点加权平均数）

总资产周转天数=365/总资产周转次数=365*总资产/营业收入；（总资产多个时点加权平均数）

总资产周转天数=Σ各项资产周转天数；（资产多个时点加权平均数）

总资产与营业收入比=Σ各项资产与营业收入比；（资产多个时点加权平均数）

1.4 盈利能力比率

营业净利率=净利润/营业收入;

总资产净利率=净利润/总资产;（总资产多个时点加权平均数）

权益净利率=净利润/股东权益=总资产净利率*权益乘数=营业净利润*总资产周转率*权益乘数；（总资产多个时点加权平均数）

1.5 市价比率

每股收益=（净利润-优先股股息）/流通在外普通股加权平均股数;

市盈率=每股市价/每股收益;

每股净资产=（净资产-优先股清算价值-拖欠的优先股股息）/流通在外普通股股数;

市净率=每股市价/每股净资产;

每股营业收入=营业收入/流通在外普通股加权平均股数;

市销率=每股市价/每股营业收入;

tips：股票股利、股票分割，不用考虑时间权重。

管理用财务公式

2.1 管理用资产负债表

净经营资产=净（金融）负债+股东权益;

净经营资产=经营营运资本+净经营性长期资产;

经营营运资本=经营性流动资产-经营性流动负债;

净经营性长期资产=经营性长期资产-经营性长期负债;

净（金融）负债=金融负债-金融资产

2.2 管理用利润表

净利润=经营损益+金融损益=税后经营净利润-税后利息费用;

2.3 管理用现金流量表

实体现金流量=税后经营净利润+折旧摊销-经营营运资本的增加-资本支出;

营业现金毛流量=税后经营净利润+折旧摊销=（营业收入-付现经营营业成本-折旧摊销）*（1-T）+折旧摊销=税后营业收入-税后付现经营营业成本+折旧摊销*T;

tips：折旧摊销*T为折旧摊销抵税，带来的现金流入。

营业现金净流量=营业现金毛流量-经营营运资本的增加;

实体现金流量=营业现金净流量-资本支出;

资本支出=净经营长期资产的增加+折旧摊销;

实体现金流量=股权现金流量+债务现金流量;

股东现金流量=股利分配-股权资本净增加;

股权资本净增加=股票发行-股票回购;

所有者权益的增加=股权资本净增加+留存收益的增加;

债务现金流量=税后利息费用-净负债增加;

净负债的增加=新借的负债本金-偿还的负债本金;

实体现金流量=税后经营净利润-实体净投资=税后经营净利润-净经营资产的增加;

税后经营净利润=净利润+税后利息费用;

净经营资产的增加=所有者权益的增加+净负债的增加

2.4 管理用杜邦分析公式

权益净利率=净经营资产净利率+（净经营资产净利率-税后利息率）*净财务杠杆;

净经营资产净利率=税后经营净利润/净经营资产;

税后利息率=税后利息费用/（净负债);

销售百分比法 销售百分比的假设：假设某些资产、负债与销售额存在稳定的百分比关系，通过预计营业收入和相应的百分比，进而预计所需的资产、负债金额，最终确定需要筹集的资金量。

融资总需求=净经营资产的增加=基期净经营资产*营业收入增长率;

外部融资需求=融资总需求-可动用金融资产-留存收益的增加;

外部融资需求=增加的营业收入*经营资产销售百分比-增加的营业收入*经营负债销售百分比-可动用金融资产-预计营业收入*预计营业净利率*（1-预计股利支付率）;

内含增长率 内含增长率的概念：只靠内部积累，即：只靠增加的留存收益，实现销售增长。（即：外部融资需求为“0”、可动用金融资产为“0”）

0=增加的营业收入经营资产销售百分比-增加的营业收入经营负债销售百分比-预计营业收入预计营业净利率（1-预计股利支付率）

两边同时除以“增加的营业收入”

0=经营资产销售百分比-经营负债销售百分比-{（基期营业收入+增加的营业收入）/增加的营业收入}预计营业净利率（1-预计股利支付率）

分子分母同除以“基期的营业收入”

0=净经营资产销售百分比-{（1+增长率）/增长率}预计营业净利率（1-预计股利支付率）

增长率=（营业净利率净经营资产周转率利润留存率）/（1-营业净利率净经营资产周转率利润留存率）

可持续增长率

可持续增长率的概念：在不增发新股或回购股票，不改变经营效率（即：不改变营业净利率和资产周转率）和财务政策（即：不改变权益乘数和利润留存率）时，下期销售所能达到的增长率。

在可持续增长模型下，增加的所有者权益=增加的留存收益；可持续增长率=所有者权益增长率;

可持续增长率=（本期净利润*本期利润留存率）/期初股东权益;

可持续增长率=（权益净利率*利润留存率）/（1-权益净利率*利润留存率）

—————–EOF——————

问题大概是这样，本周五10点半左右，产线在群里反馈灾备无法发布。

接到问题后，口头咨询了产线版本构建的时间是什么时候，产线反馈为前一天晚上，因目前的版本设定在第二天00:04这个时间点同步到灾备的镜像中心，所以接到问题后，立马排除了“产线版本为当天构建，没到版本同步的时间”的原因。

所以，就立马登陆到镜像中心去查看版本同步记录。

一看发现，确实版本在前一天未成功同步版本到灾备中心。

没办法，只能去看报错。但镜像中心也很诡异，竟然没有保留同步失败记录的详细日志(后来到社区查看，应该是开源产品的bug，同时，还发现了产品本身其他一些bug。orz…….)。

这就头疼了！

虽然不影响生产业务的运转，但说明容器云灾备的整个方案中，是有没考虑到的点，不禁让我陷入质疑技术人生的沉思……

还是不要多想，先动手排查起来。

其实主中心同步版本到灾备，无非就是个介质包推送的过程，而且本身基于的是docker的机制，所以从大的方案上来看，应该没什么问题。

所以，第一个想到的，是不是主中心到灾备的网络端口封闭了。立马telnet去查看，发现一切正常。

那是不是推送镜像介质有问题呢？

我立马手动用脚本push了一把，发现，确实没法push，返回的状态码是401以及x509 ipsans不存在，也就意味着主到灾备的ssl认证未通过。但事实上，因目前主备中心共用一个域名(配置同个域名，目前流量到不了灾备，所以配的是ip模式)，但是主到备我设置的是insecure ip模式，并不需要认证。

这就奇怪了！

第一，按照我司的ssl证书，也要到明年2月份左右才会过期进行更换，所以不可能这么快。虽然笃定这么觉得，但还是去灾备核实了镜像中心部署用的ssl证书，做了下ssl的检测，确实没有过期，而且用的证书本身就是从主中心V2V同步过来的；

第二，我未设置secure模式，为什么现在需要去认证呢？

思来想去，会不会因为docker认证出了问题。

首先，我先在灾备环境本地进行了镜像push，没什么问题，可以确定，ssl证书和认证是没问题的，那就是跨中心有问题。

先补充个小技术点：docker在做镜像认证的时候，为了安全性，会进行auth认证，如果认证成功，会在相关的配置文件中去写下auth的口令，以后可正常进行认证。这个口令他会以{ip/域名：{auth:“xxx”}}的形式进行保存。

我立马去翻看了文件，发现确实没有灾备ip的口令信息。

终于离真相接近了一步。因考虑到是生产，只能中午乘着午休的空隙时间去进行修复。期间，电话了厂商的技术专家，描述了问题，厂商中午也开始介入进行排查。

中午吃完饭，我立马开始进行修复，首先，更强制性地把灾备的ip在docker中设置成insecure模式(之前设置走的是镜像中心的配置)；第二，把灾备的认证口令，在主镜像中心的docker配置中进行强制纳入。

开始进行重启……….

糟糕！还是不行！确实有一种把键盘敲碎的冲动！

我和厂商做了下沟通，厂商查了很多方案，也表示无解，说确实没遇到过这个问题。

好吧，那咱们再用最后一个绝招，重启！虽然，我已经预判了这个结果肯定不行，但还是像“抓住最后一根救命稻草一样”，试试看吧。

果然不行！哈哈哈哈。

我和厂商确实都emo了…….甚至心里怀疑是不是网络发包篡改了什么。当然，我还是比较坚信我的网络知识的储备比较完善，所以打消了这个念头。

因不影响生产运行，下午上班后，就让厂商技术专家继续去内部沟通问题。我这边因有其他更紧急事情处理，就忙去了。

后来大概下午16点左右，我突然想到，灾备这边一直不让过认证，是不是灾备的镜像中心有什么问题，但中午我也在灾备中心去进行了灾备镜像的认证，也没什么问题。好像就跨中心有问题。

那到底还会因为什么呢？

没办法，因为镜像中心是开源的，只能去社区看镜像中心的源码，看能找到什么线索。

看源码，那肯定就是从源码的初始化开始着手。

突然，我发现一个小点，就是镜像中心在启动的时候首先会去获取一个cfg的配置，cfg中有一段配置，长的样子为[hostname:””]，这个配置后来证实应该与ssl证书的secure模式有关联。也就是说，要么你主机的hostname做硬性配置，它进行加载；要么你自行在配置文件中进行配置。我翻看了下灾备的cfg的配置，发现配置的就是[hostname:”镜像中心名称.xxx.com.cn”]，第一念头就是：那应该没问题啊。

再一想，不对！目前主到灾备因为配置域名流量无法到灾备，所以用的是ip的模式。那么假如去做push的时候，但对方走的是域名+证书的形式，而我走的ip的形式，导致认证没过？

基于这个猜想，我把cfg中的hostname配置改为hostname:ip的形式，然后重启。

手动进行了触发，发现可以正常同步了！

经过这两天夜里的同步观测，发现基本同步正常。

虽然，同步正常了，而且也检查了这期间的所有服务器、介质、镜像中心的运行态，都没发生重启或者其他变更，但还是有两个谜团没解开：

1、在发现问题之前，所有的镜像都正常进行了同步，否则这个方案上不了生产，但为什么又突然无法同步呢？

2、我当时明显走的是insecure模式，是跳过认证的，为什么又需要突然认证？

这两个谜团只能留待进一步去深入发现组件运行机制了。

从这个问题，有一些点还是值得后期改善：

1、不管是开源产品还是成熟产品，总归是软硬件以及人写的，人写的，就会有bug，所以在日常开发运维这些产品的时候，除了该掌握的产品业务本身外，尽量能够对产品的运行机制、技术背景等做详细了解，从而在遇到问题能够去兜底；

2、不管是开源产品还是成熟产品，一定要去尽量部署配置化与标准化，特别是对于产品产品介质的版本情况、配置情况等做好标准化，这是减少技术债的一个重要途径；

3、任何一家厂商都不是万能的，也不会时刻帮着你解决问题，更不可能解决所有的技术问题，有些时候遇到一些问题，尽量能够主动出击，逐步积累；

4、云原生技术在给企业带来便利的同时，对于云原生本身的技术是一个硬骨头，而从目前行业来看，云原生的应用基本是趋势，技术研究，有一定必要；

5、同一份介质或者软件，完整复制到另外一台进行部署运行，一定要做好技术考量是否能保证运行，因为会涉及到很多配置细节

(完)

—————–EOF——————

就是IT怎么进行降本增效和创新变革，从而去应对新时代IT行业发展的挑战。

同时，从整个两天会议参加的人群情况来看，基本上还是以年轻人为主，周围所讨论的也主要是大模型为主；所有的展台也基本上是展现大模型与coding的结合，从这些情况来看，可以看出：

1、23年，行业都在探索大模型的演进与发展，但截至到目前，各个公司包括各大厂，都还是未探索出killer apps，也就是像微信、抖音、支付宝这类的能够去改变人们工作、生活方式的超级应用和场景，目前最多的只是在利用大模型来改变工作的方式，而这类场景并没有真正进入到生产的交互，也就是实质性能够给产业带来助力，给公司收益带来大的帮助；

2、两天会议，和周围一些参会的人做了一些交流，还是能看出，IT行业基本进入到第三个纪元，如果把基于移动开发所代表的移动互联网，作为IT人员转型的第一个纪元的话，微服务所产生的各类中台的发展作为第二个纪元，现在个人感觉应该开始进入IT人员技术、理念、工作方式的第三个纪元，而第三个纪元，就是以AI去驱动IT人员自身工作的发展，乃至通过AI去驱动各个产业的逐步变革，这可能不光是产业资本的力量所驱动，也是作为一个社会个体也需要去面对和考虑的内容。

3、IT进入的门槛在未来几年，按照我个人的猜测，基本是越来越高，大模型的的演进，虽然目前并未有杀手级应用，但随着行业的探索、时间的推移，社会智力的综合提升，大模型的智能、健壮性无疑是逐步提高的，势必会给IT人员的工作带来不小的影响。就拿以大模型为支撑的coding助手来讲，虽然现在还不是很完善，但随着此垂直领域的深度发展，基础性常规性代码的自动化产生与应用，趋势无法避免。

接下来简单记录下我参加的几场会议的感受。

第一天我重点参与了一些大厂的综合大模型和云资源的话题的分享，比如腾讯、字节、阿里、亚马逊，收获颇多。有一些点做下记录。

第一，围绕着大模型的应用场景一直在探索，但23年，还是以大模型的训练推理为主。因资源投入等，目前能有资源去投入大模型的，也就主要以腾讯、字节这类大厂为主，虽然23年进入了百模大战的元年，国内也出现了几百的大模型，但整体和openai所代表的chatgpt相比，还是差距很大。国内很多大模型虽然也在全球的模型社区进行打榜评测分数竞争，包括对于训练的模型参数的大规模化的竞争，但整体还是有不少问题或者不完善的地方。国内大厂也需要极度关注投入产出比，目前做的很多基于大模型的应用，也并未带来真正的实际收益，国内基本还处于行业早起的探索铺垫中；

第二，听了几场关于云资源的话题分享。其中包括云所代表的基础设施的稳定性、云的使用等。行业对于云的使用还是持积极的态度，普遍结论认为，云一类的基础设施，比如云的伸缩性、云所提供的各类成熟的基础软件等，都无疑会给无基础设施投入条件的公司带来很大的帮助。同时，随着serverless等无服务化技术的越来越成熟，在资源高峰低峰的混合部署启动上带来很大的便利，在资源降本上，有了很大的技术铺垫。这里记录几个个人认为比较重要的会上的认知话题。

首先，要将云成本纳入到系统建设之前的非功能需求中。以前我们一直在强调包括安全、可用性、可扩展等非功能需求，而现在，需要将云资源成本也纳入到非功能需求，一个系统到底需要多少资源，这些资源该怎么使用，都是需要去进行评估的。目前很多大厂都开始把此内容纳入到需求交付过程中。 另外，从资源决定架构的交付模式转变到架构决定资源的交付模式。以往我们在做项目交付的时候，都是先把资源评估好，以及年度需要去采购哪些资源，有些时候资源可能会有很大的冗余。而现在的交付模式一定要转变到通过架构去决定资源的交付。架构，代表着稳定性，好的架构，能够去进行资源、研发实施的降本增效，永远不能忽视架构的重要性。架构和资源都是相互匹配的，是可计算的，无任何的玄学。

最后，“我们一直都是这么做的”，这句话在IT过往的交付和运维过程中，一直都是很多人的口头禅，而新的时代，要逐步去杜绝这句话，这种方式极度危险，基础设施的资源的投入，不会一层不变，也不会一直都是这么做的，要不停用的新的理念去拥抱新的变化和时代。

第三，挑选听了几场垂直领域的大模型的分享会。记录如下一些要点。

首先，垂直领域的小模型，公司做适当的投入是能够训练出来的。大模型的训练和推理，重要的基础条件就是GPU资源。从一些专家的分享来看，都不建议以烧钱的方式去进行模型投入，因为从目前来看，ROI不明显。但行业垂直小模型的训练是可实践的。其中，我重点了解了腾讯某个事业部自行训练的一个模型，其主要做text2sql领域，也就是报表口语化。这个需求的背景来源于腾讯内部的高管经常需要去看各种数据以及分析结果，然后结合这些数据去进行一些战略研究。以往的方式，都是领导直接跟运营或者IT团队进行需求提起，然后进行特定抽数整理，因报表很杂很多，人力消耗不少，所以该团队就结合模型进行了训练和推理。比如，腾讯的高管在窗口输入“我想看一下23年某事业部游戏道具的收益”，那么通过模型会自动去形成sql,同时通过sql去生成最终的报表。另外，看的一个案例就是好未来猿辅导的一款数学教育产品，主要就是通过模型训练，形成一款数学解题分析题目的应用，也是结合各类数据做的垂直领域的小模型投入。

另外，目前模型的投入所带来的产出并不明显。根据在现场的讨论，其实现在也很多表面的场景，比如生成会议纪要、比如读取文档生成摘要等，目前产品都有，但没法商业化，也就是不知道怎么带来收益。这里，大家都讨论了一个话题，大模型刚出来，大家都觉得和客服的结合是最大的一个场景，但随着探索发现，结合是没问题，但是在自动化客服的过程中，到底能带来怎样的收益，一直没探索出真正的场景，也就是现有的应用，无非就是解答用户的问题和诉求，但真正要做的，就是在和用户交互的过程，是能够带来商业上的转化，这才是是否投入该去考虑的。

最后，技术门槛和模型复制的问题。模型相关的领域，首先是一个基础学科的领域，对于很多基础的数学、计算机等课程必须有很多的了解；其次，目前开始变成一个工程化的命题，在整体模型的训练、推理、部署上都有不小的难度，需要非常多的知识的辅助，所以是有技术门槛。对于模型价值，会发现，一个模型的训练产生，除了科学的含义，其实也有不少玄学，也就是“数据炼丹”。有些时候，一些结果的涌现，训练的人都不知道为什么出现了这个结果，可能不一定能合理完整地去解释现象后面的本质，而且有可能同一个现象的产生，大家训练用的算法和数据都不一样。按照我对模型训练的实践来看，其实最具有价值的就是数据+模型参数。所以很明显可以看出，如果一个模型在场景上获得成功，那么这个模型其实别人是很难去复制的，因为数据+模型参数都是当事人自己去选择的，即使当事人公布了又或者有文档，但在新的人或者团队的手上，也不一定能在新人的训练推理过程中得到想要的结果。个人觉得，除了商业价值外，这也是模型的价值，也是IT一部分不可替代的价值，所以，作为团队来讲，一些领域的投入，是可以长期去考量的。

最后，在记录一些其他的话题或者感想。

在整个会议的期间，我又挑选了两场关于数据中台、业技融合的话题。如下：

1、今年所看的数据治理和数据中台的话题，其实都是在说明一个事情，怎么去降本增效。我拿其中爱奇艺这一场来举例子。23年之前爱奇艺整体的数据中台的技术架构和我们是差不多的。都是围绕着Hadoop／hive／hbase/es等，其中日志这块也是使用es为主。在数仓分层上，也是以ods/dwd/dwa进行。但是23年开始，爱奇艺进行了重构，也就是逐步将hive／hbase等逐步数据湖化，其中也把es的日志存储换成了大数据平台的日志存储。整体大数据平台都统一成了iceberg数据湖技术。从表面看，这可能是爱奇艺做技术重构的一个现象，但从深处分析，其实是降本的体现。以往大数据平台的多个组件需要不同的人的分工合作和运维，还是有不少的资源投入，特别是人员的投入，就像分享嘉宾自己所说，es做日志存储不光运维难度大，在人力资源和硬件资源上也消耗很大，所以23年，他们把所有日志都重新汇集到了数据湖。这点，深有感触，也是我们当时进行日志重新汇集的一个目的。23年，爱奇艺对大数据平台的技术栈进行了统一化和重构，虽然难度很大，但确实是面对公司压力的一个自我革命。

2、业技融合。业技融合深层次看其实是偏效能的问题，目的也是提高效率，降低事情成本。整个会议中，就只有一场，我也大概学习了一下。业技融合是一个很复杂的工程，并且需要从上至下的很完善的流程去进行驱动，整体而言，其和数据治理类似，非IT本身能够去全面做到，也非技术本身的难度话题，其需要有制度上完善的运营流程。这块看后期PPT是否分享，涉及的话题很大也很细。

整体两天会议，还是让我个人有极大的危机感，包括和周围相对年轻的人员的沟通发现，整个IT行业目前都很卷，但就看怎么能够去卷得有价值，而不是单纯去卷，关注价值导向，是新时代IT人的最求本质。 最后的最后，看到周围更年轻的同学，不得不感叹年轻真好啊！技术的发展，IT的新变化，对于更年轻的人来讲，充满着各种挑战，充满着各种创造。提升自己，永远是最本质的手段！

(完)

—————–EOF——————

同时，通过多个启动时间数据的验证，证明使用了OpenJ9的应用在启动时间上与以往的Oracle HotSpot减少了50%，提高了应用启动的速度。

而应用是随时会随着业务变化，经过一段时间的动态数据验证(主要是通过压测)，我们更好地去观测和分析OpenJ9在真实流量情况下的运行情况。

首先，先说下结论。

1、整体使用OpenJ9和HotSpot的应用，做压测对比，在流量缓和的情况下，整体性能相当；

2、若在流量到达顶峰(比如某应用的真实顶峰TPS为500)，OpenJ9的性能稍逊于HotSpot，需要对使用OpenJ9的应用进行CPU和内存提升；

3、同时，我们在压测的过程中发现，OpenJ9的应用的fullgc次数高于HotSpot的(原生情况，未开启相关JVM参数调优)，且CPU高。次数高的原因，除了性能外，还与OpenJ9所使用的GC策略有关系，OpenJ9在GC策略上，会进行Idle heap GC，其是指，通过计算发现有一些heap空间长时间不用，它就会主动发起回收；而Hotspot，会通过年龄代和使用可触达进行判别，所以在策略上还是有一定差异；CPU高，是因为FullGC的工作是需要CPU协助的。

所以，从以上结论，我们可以得到一个初步的OpenJ9使用策略。

1、产线应用在评估是否用OpenJ9之前，一定要先评估下自己的未来流量情况(当然，不用OpenJ9也需要评估^_^，这是对自己应用技术负责的态度) ，若日常流量不高(比如有些系统每天就几个人使用又或者在特定时刻才会有流量高峰) ，则可以按照真实使用情况考虑是否用OpenJ9并评估资源申请情况；

2、对于一些流量比较大的应用，若期望使用OpenJ9进行将本增效，产线应用可以通过压测等手段，合理进行内存申请与流量低谷资源释放，从而真正达到“资源降本”的目的。

如下内容是通过客观的压测，所出的相关数据报告，可做参考。

我们通过对开源社区的spring cloud gateway进行压测，统一网关的场景属于CPU和IO都较为密集的应用，所以能客观分析用了OpenJ9的真实指标情况。其次，也重点压测了包括短链平台、分布式ID生成平台的情况，结论和如下网关的数据大体相当。

所以，本次以网关压测的数据进行考究，所压测的接口的业务场景为：报文加解密。通过对此接口压测，单实例(2C2G)的峰值为500TPS，此次参照这个基准进行压测。

—————–EOF——————

按照对目前司内敏态应用的日常生产运行分析以及目前降本增效的大背景下，22年12月份，个人开始对敏态应用的资源做进一步地思考，争取以技术的手段去解决一些降本增效事情。通过调研与技术考察，我们发现，除了系列大厂有能力和资源对底层设施做优化乃至重构外，其实社区中也不断涌现出了很多能帮助我们进一步做技术布局与降本增效的技术方向和产品。

目前我部的应用系统的后端技术语言都围绕着java整个体系进行，所以在运行层都依托于JVM进行，从目前的司内调研情况来看，分为敏态和稳态系统，有如下情况：

1、其中敏态应用基本都基于JDK8，其中敏态包括上容器云的和非上容器云的，上容器云的应用都统一使用成熟的瘦身版本的OpenJDK支撑应用的运行，非上容器云的都普遍以基础架构统一部署的oracle openjdk；

2、稳态的应用都普遍以传统的方式部署，且jdk的版本多样，从1.6到1.8几乎都存在，而且很多稳态应用还是基于1.6的版本进行。

不管是基于1.6的，还是基于1.8的，其实从技术层面上来看，JVM都依托的的oracle的hotspot，此底层运行基础设施不变。而openjdk一定程度上来说，是一款比较重的产品，所以这就给了我们一定的方向思考，我们是否可以在jdk乃至jvm这些底层基础设施上做一些优化考量？

经过考察、研究、数据验证以及技术团队的系列应用试运行(非生产)，计划进行部内OpenJ9的推广。

首先，我们先看下什么是OpenJ9。以下是我的总结。

1、IBM开源贡献给社区，经过多年的发展，目前已相当成熟；

2、其和oracle/sun的hotspot一样，也是jdk的一个实现；

3、其是更轻的JVM

为了更形象，我参照社区的技术分析，做了张简图。

从上图可以知道，不管是oracle的(目前我们在用的)，还是OpenJ9的，其实他的上层的java规范是不变的，说的直白点，目前针对于研发同学，应用无需做改造，大家其实都是java这个老祖宗的后代，同源同宗。

只是不同的是JVM的区别，可以这么理解，IBM和社区进一步结合云的趋势，让自己的技术视野变得更广阔。这里多说一句，我们应该知道，类似于阿里这类大厂，其实都有自己的JVM团队，他们其实就是在hotspot的角度上去做优化，最终其实还是hotspot。

既然说了这么多，那OpenJ9又有哪些特点呢？我们先看一个官方说明(后面，我们也会进一步去进行验证)。

` 42% faster startup time，启动时间快42% 66% smaller footprint after startup，启动后占用内存减少66% Faster ramp-up time in the cloud，云端环境快速提升吞吐量 63% smaller footprint during load，高负载时减少63%的占用空间 `

从以上官方社区的说明我们可以看到，其在应用启动速度、应用内存占用上都有了很大的变化。其中，启动速度对应着研发效能；内存占用对应着降本，从目前来看，起码在政策背景上，技术符合司内宣导方向。

为进一步说明其特新，我们看一张OpenJ9的架构图。

从架构图中我们可以看到，除了和hotspot类似的组件模型外(编译、执行、垃圾回收模型等)，其增多了SCC和DDR两个新特性，那这两个是做什么用的呢？

SCC，Shared class cache，表面意思就是他能够通过一定的分析，把编译好的字节码进行缓存，所以这个点，其实就是它整体应用启动速度能够加快 的一个关键原因。

DDR，Direct dump reader，增强了字节码查询工具、指令集等，这个对于研发来说，在性能优化的过程中，才会有一定的体现。

除了以上的特性，OpenJ9和HotSpot还有一些小的对比，比如在GC的策略上、AttachAPI上以及一些指令工具上，具体不做详细介绍，后期随着内部推广的深度进行，进一步做分析。感兴趣的可以到社区去进行学习了解。

接下来，我这边就以技术团队的相关服务做验证。

所有验证会分为几个阶段。

第一阶段，应用本身的启动时间、内存/CPU的数据占用；

第二阶段，应用并发验证；

第三阶段，稳定性测试与对比

我这里挑选了两个服务，一个是分布式任务调度平台、一个是统一网关。第一个应用是CPU密集型的应用，第二个应用日常流量比较大，IO相对密集。本次验证，为第一阶段的验证。

我们先看下应用的启动时间对比。

这里，我做了应用在三种情况下的启动时间对比。其中hotspot和openj9(未开启指令)在正常情形下，启动速度其实差不多，有些时候openj9反而会慢一点。而一旦开启了quickstart/scc等指标，我们会发现，整体启动速度下降一半，有很大的变化。

接下来，我们验证相关应用在资源占用上的情况对比与分析。本次主要验证的是一段时间区间的静态验证。

左图，是在hotspot上的运行情况，右图使用的是openj9，可以看到在内存占用上还是有不小的差异。

应用都为在容器云上运行，都分配的为1024M的内存，从数值来看，HotSpot下，应用启动后到平稳运行所占用的内存为：875.52M；OpenJ9下，应用启动后到平稳运行所占用的内存为：323M，减少了超过50%内存使用量，效果还是比较明显。

同时，我们在看下堆的情况，这里拿了两个静态峰值做了对比。

可以看到，在整个堆的占用上，相差一半左右。

接着，我们再看下非堆的使用情况。

非堆的使用上，差异有40M左右的差异。

所以，从这些静态数据对比来看，我们其实可以去猜测，OpenJ9的JVM在对象的创建以及内存的分配上大概是做了一些方面的优化，目前个人也逐步在对所可能涉及到的优化原理猜想进行验证中，后面随着推广的展开，也会进一步去做更多的分享。

除了以上的静态数据验证外，接下来也会有详细的并发动态验证数据，届时会有更详细的测评指标供给大家查看。

—————–EOF——————

系统地去阐述这个主题，不是一件容易的事情。记得早些年读经济读物的时候，忘了是谁说的一个观点，很有借鉴性。大体意思我总结一下：

如果去系统地研究论述经济学的观点或者经济趋势，正常分为两种，一种就是以一种局外人的角度去研究历史，通过历史上所发生的事情去阐述自己的观点；另外一种就是通过数据、案例、政策等研究，验证自己的观点。第一种方式在很多通俗化的经济读物比较流行，也比较能被大众所结接受，比如《万历十五年》，看是阐述明朝史，实际上也是反应当时的经济政策与发展情况，比如《伟大的博弈》着重描述华尔街金融史；第二种方式比较理性，通常通过研究数据、政策去验证自己的观点，这类正常都比较偏学术化，比如国内周其仁、任泽平所出的一些书籍，没有一定的经济学基础确实无法通读。

所以我也用我所了解的些许信息发展史来谈谈什么是信息。

谈起历史总会从人类计划的起源开始，当时人类是没有现在的通俗化语言去沟通，所以古人类为了将很多经验流传给后世，就通过在石壁上作画的方式，对于涉及到计算的场景，比如打猎的收获，就通过绳结的方式处理……

那个时候的信息还是比较粗陋，离大规模信息分析还很遥远，基本通过纯手工记录作业方式。所以我估计当时应该都是以小的种群或者部落存在，因为信息的结构组成的简单无法满足大规模集群的诉求，同时产生信息的速度也减少了种群间的沟通。

后来文字开始产生，比如公认的来源于中东地区的最早的文字-楔形文字。那时的文字应该都像图画一样，以现实生活中的物体进行图形简约化。另外，比如中国古代将文字刻在甲骨上，从而成为现在定义的甲骨文。在文字起源的过程中，我们不能忽视一个重要的文字-数字，如果把文字定义成用来连接人类之间的沟通的载体的话，那么我认为数字是进一步促进人类经济活动、解放人类生产力的可量化的衡量工具，在历史上的位置非常高。

那个时候的文字普遍都以大自然存在的物体进行记载，比如龟甲、贝壳、石头等等，在信息的传播上还有很大的进步空间。

文字的逐步产生丰富了信息的组成结构，同时也丰富了人类之间经验记载、经济活动、日常沟通协作的方式，并且也逐步促进了更大的组织的诞生-国家。我们从小就听到很多耳熟能详的故事。比如『烽火戏诸侯』，比如战时的狼烟，烽火狼烟其实都是传播信息的一种手段，用于更快地对信息做传播。另外在计算机领域有一个分布式的问题：拜占庭问题，其就是古时信息传播的人工篡改性，特别是对于一些很重要的军事活动，一个字的差异，可能会是一个国家的灭亡。

那个时候的文字逐步趋向于统一性，多样性的文字除了会带来双方信息的处理难度，同时在进一步地普及化也有一定的阻碍。

历史的车轮在一步步向前，那一年造纸术的诞生决定了至今的文字信息的记载、传播方式。当时造纸术的出现有部分原因是解决原材料稀缺的原因，但同时也带来了如何去规模化，当然，人类是聪明的，不断地去寻找发明各种工具去解决繁杂的人工问题。同时，人类不断地去思考其他领域的信息处理，比如我们熟知的比较有争议的地动仪，其实就是通过机械化的工具去处理大自然给我们的信息。

工作机械化的逐步普及，在降低产品的生产成本，促进产量，也将人类带到了一个新的时代-工业时代。

蒸汽机的发明在当时来说，除了解决人类的生产作业外，其实也带来了信息的处理速度。比如我们所了解的『飞歌传输』、『神行太保日行八百里』、古时候的驿站，其实就是因为当时的信息的传播手段没那么方便，而蒸汽机的出现其实进一步地促进了交通业的发展，也促进了信息传播的速度。

当然，人类永远是不会停止进步的步伐，因为在不远的将来，人类即将会到来一个最伟大的时代-『电的时代』。

生活在现代的人们其实应该感谢那些科学家给我们发明了电，并且感谢那些默默无闻的人将大规模的电生产出来供给我们日常的所需。前几年，一直有个很火的讨论，就是没有电会怎么样，网友们的很多回答其实也代表了电的唯一重要性。

可能仅仅是一根线，但是其中包裹的内容却是驱动着整个世界的运转。而信息的传播和处理的方式也让人类有了新的认识以及思考逻辑。

也就是从那个时候开始，人类可能自己也不知道自己正在进入一个新纪元-信息的时代。

熟悉计算机的发展史的应该知道，巴贝奇的差分机的试验，以及后面更复杂的分析机，通过打孔计算存储的方式，代表了第一代计算机的前身。而在计算机真正出现的这个历史进程中，电报的出现进一步提升了人类信息的产生与传播速度。有一本比较著名的书叫做《世界是平的》，我个人觉得电报的出现是将世界『铲平』的开始，因为通过电报的方式，人类可以随时去进行远点沟通，更快地去获取自己所知道的信息。

记得之前看过一部电影叫做《听风者》，里面通过听的方式去寻找电台，从而截取并破解传播的信息，所以虽然技术得到了进步，但是信息的产生、接受与处理中的问题，和古人一样，时刻会碰到。

也就在这个时刻，出现了两个影响影响整个信息的产生到接受处理进程的人，一个叫做图灵，一个叫做香农。

首先是图灵，图灵当时思考一个问题，就是如何让机器能够思考。就是如何将信息灌输到机器中，机器帮忙进行处理，并输出满意的结果，也就是所谓的『图灵完备』。这在现代来说，太简单不过了，但是对于当时来说，需要去思考数字逻辑等关系，而且当时并没有计算机的出现。

另外一个就是香农了。他给信息增加了度量单位信息量，就是bit。学过物理的应该知道，质量和能量是物理中很重要的概念元素，所以信息量是第三大补充，地位可想而知。同时，香农提出了信息熵的概念，也就是如何来描述信息源的不确定性问题。所以香农的这些研究形成了一个新的领域，信息论，虽然当时香农觉得他只是想去解决信息的传输问题，但他没想到会发展成一个学科。

当然也因为他们，才有了我们现在的互联网。而这个进程中涌现了太多的创造并引领历史的人。

几年前河北大学一名老师在自然上发表了一篇论文，就是基因的可编辑性，虽然后来被发现是实验造假，但是从这个事情可以看出信息的深度探索逐步到生物领域。这几年一直比较火的人工智能、神经网络等领域，就是人类在探索如何将人类自身所了解的信息进一步地智能化、可预测化。而且在这个进程中发现，除了计算机领域专门处理信息的人员还在思考信息如何处理外，包括心理学家、生物学家等各个领域的人也都在思考探索他们领域中的信息的处理。

还有比如今年年初，央行开始试行数字货币，其代表着社会经济活动的进一步信息化。

至此，我们发现万物皆是比特。用尼葛洛庞帝的那本书概括，就是数字化生存。我们如今都生活在数字化的时代，每天都在不断去产生、处理、接受各种信息，而且整个信息的流动越来越快。

当然，我们可以在展望拥抱一下未来。也许某一天信息的传播真能穿透银河到达另一个世界。

记得很多年前看过一部电影，叫做《异次元骇客》，电影的主题就是讲述了每一个世界的人其实都是上面一个世界的人的信息创造，而且创造他们的人可以将自己的意识转移到他们脑袋并进行一系列的活动，与《黑客帝国》里的场景类似，当时看完颇为震惊。

最后，回到我们当初，希望升起的狼烟能够减少『烽火戏诸侯』的出现。

(完)

—————–EOF——————

预训练其实是属于迁移学习的一种，就是在一个通用的已经训练好的基础模型上进一步再做大规模语料的训练。 之所以需要预训练，主要还是考虑到训练的成本、时间周期以及投入产出比。我个人目前的实践研究也主要是使用社区现成的基础模型进行训练，主要还是训练资源(主要在GPU卡的投入上)有限。不过，自己去从头开始训练一个模型的理论和实践过程还是要清楚的。

做模型训练无非就是要经历如下几个过程：

1、寻找通用数据集；

2、对通用数据集进行清洗和处理，目前开源社区也有很多现成可用的数据集，比如Wiki文本、医疗数据、知乎问答数据等，这些都是可以拿过来做自己的训练数据集合，但如果需要训练某些特定领域的数据集，那只能自己来处理，模型的优劣和上限最本质还是由数据的质量来决定，算法和策略不占主要因素；

3、有了数据集之后，就是做Tokenizer和Embendding，目前社区已经有很多现成工具进行对语料进行处理，比如HuggingFace Transform的一些Tokenizer词元包；

4、做了词的处理之后，就可以去选择一些预训练语言模型，其实在OpenAI的ChatGPT火之前，就已经有很多预训练模型了，近几年主要的训练模型也基本围绕着Transformer的骨架进行，只是会去区分，比如是Encoder-Only、Decoder-Only、Encode-Decoder中的哪一种，这个都可以根据自己的诉求进行选择。Encoder主要是属于自编码类型，就比如选择题或则掩码猜词都可以选择此类模型；Decoder主要是自回归模型，他会根据前面的词元去预测下面的词条，比如我们所知道的GPT就是Decoder-Only，生成式模型。像google的BERT就是ENcoder-Only，我研究学习的主要参照的是T5模型，其是Encoder-Decoder模式，只是在遵循Transformer的基础上做了系列模型优化。Transformer以及Attention机制确实带来的了变革，解决了以前RNN/LSTM等模型的一些问题，所以如今只要把Transformer弄懂了，基本能做不少事情。当然，以前传统的模型还是需要去研究和实践，有对比才能对新的东西有更深刻的理解；

5、选择了模型之后就可以去想办法做预训练了。当然肯定逃不开coding，这里会涉及如下的一些工作：

加载生成Tokenizer

对模型参数进行设置，比如会涉及模型的层数和维度、词表的大小、全连接层的大小、头的大小等，目前预训练模型都会有相关的论文呈现，一些参数的设置，可以在训练之初阅读论文进行学习获取

初始化模型

通过Tokenizer词元(可以自己生成，比如耗费资源)和准备的预训练语料生成预训练数据集

设置模型训练超级参数，会涉及训练的批次/轮数、训练的精度(比如是否需要进行量化)、学习率、模型优化算法等，这些参数有些可以从论文的最佳实践中获取，有些需要自己按照社区或者个人经验去进行微调

设置模型训练器，比如T5模型，是Seq2Seq类型，社区有专门的模型训练器进行使用，只需要模型参数定义好了就可以设置使用

进行训练，保存各类训练结果，这里会涉及梯度计算、loss计算等

模型评测，进行计分

保存模型

6、通过以上步骤，你可以去训练自己的一个模型了，训练好的模型会自动保存生成系列模型文件，比如.bin、.safetensors或者pks参数文件等。这些模型文件包括你所训练生成的tokenizer其实都属于模型的一部分，在模型做推理的过程中都会去调用。

当然，一个预训练模型训练好了之后，还没完，后面还会涉及各类调整，比如基于特定语料的Fint-tune、RLHF/DPO优化，后面我会结合个人的训练情况再进行整体阐述。

(完)

—————–EOF——————

一、 Word Embedding 的含义

主要指【词嵌入】，其实就是将词在向量空间中进行映射，按照我个人的理解就是将最原始的one-hot向量映射为一个更稠密的连续向量，并通过一个语言模型去学习这个向量的权重，而这个更稠密的连续向量也被称为分布式表示，处理的这个过程叫做Embedding过程。

Word Embedding 是自然语言处理中一种语言模型和特征学习技术，这些技术会把词汇表中的单词或是短语映射成由实数构成的向量上。

二、 Word Embedding 的类型

第一种，基于计数的方法

1、BOW 词袋模型 这是最简单的映射方法，属于one-hot。 什么是one-hot类型，举个例子，比如我有一个句子：I like my home，如果要对这句话中的词汇进行向量表示，我们可以采用如下方式：

1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1

如上，第一行行向量就可以表示”I”，第二行可以表示”like”，以此类推…… 其中向量的size代表词汇的长度，向量某个位置的值指代这个单词是否出现。

但如上的表示方法其实也有一些缺点： 1、因为所形成的矩阵属于非常稀疏，真实的值远小于实际的值，而真实训练过程中其实会涉及非常大的预料，那么所涉及的矩阵点乘所占用的内存空间会很大； 2、每一个向量和另外一个向量之间正交(向量与向量之间乘积为0)，无法去表现词之间的关系

2、n-gram 模型

n-gram模型基于一个假设，第n个词出现与前n-1个词相关，而与其他的词不相关。整个句子出现的概率就等于各个词出现概率的乘积。 可以以如下联合概率来进行表示：P(W)=P(w1,w2,w3,…wn)=P(w1)P(w2|w1)P(w3|w1,w2)P(W4|w1,w2,w3)… n-gram有如下的特点： 1、某个词的出现依赖于其他若干词； 2、我们获得的信息越多，预测越准确 但也有如下缺点： 1、参数空间过大，会导致参数计算非常巨大； 2、数据非常稀疏 因为如上的缺点，后来引入了马尔可夫假设：一个词的出现，仅仅与之前的几个词有关系。 正常对n-gram的分类可以有bi-gram、tri-gram，但都因为参数空间过大以及数据稀疏的问题，导致在计算和资源使用效率上不尽人意。

3、共现矩阵Cocurrence matrix

根据窗口内的单词的共现关系来生成词向量，最后得到的共现矩阵，值为两个词作为邻居同时出现在窗口的次数。 我们还是以 I like my home这句话为例子，如果用共现矩阵来进行表示，如何进行呢？

     I  like  my  home
I    0    1    0   1

like 1    0    1   0

my   0    1    0   1

home 0    0    1   0

如上，通过窗口的方式，就能够词之间的关系。但其也有一定的缺点： 1、当词的数量巨大的时候，有维度灾难； 2、当词袋中有新的词汇进入的时候，很难去对矩阵进行添加和扩展 在日常使用共现矩阵进行语言模型的构成的时候，面对维度灾难，我们通常都会去进行降维，比如通过SVD奇异值分解或者PCA主成成分分析等方法，进行特征维度下降。

第二种，基于预测的方法

这里主要就是指Word2Vec，其是通过神经网络的方式来完成Word Embedding。

其最初是通过一个前馈神经网络来预测一个词出现的概率分布。整个模型如下图所示：

这就是以前NNLM模型。

这里介绍两种模型算法，第一种CBOW，第二种skip-gram。

什么是CBOW？我们还以I like my home为例子，假如，我将这句话改为I _ my home，从而预测 _ 是like的概率。 这种方式就是通过一个句子的上下文，从而预测目标词。模型可以用如下图所示：

那什么是skip-gram呢？正好相反。 比如我将I like my home改成_ like _ home，从而预测like之前和之后出现哪些词的概率最大，这个就是通过目标词去预测上下文。

如上两种方式的预测就会通过神经网络去进行完成。

后面会详细介绍这几种方式。

(完)

—————–EOF——————

常见的tokenizer方式包括：word-level(词粒度)、byte-level(字粒度)、character-level(子词粒度)。 我们来对比下这几种方式的差异。

word-level

基本单元是单词，比如如下一段话：

I love my home.

如果以word-level的方式进行，那么就会得到I/love/my/home/.

byte-level

其又称为字符粒度，按照当前语言的最小符号来进行划分。 还以上面这句话所示，就会得到I/l/o/v/e/m/y/h/o/m/e/. 比如中文，我爱我家。,那么，就会得到我/爱/我/家/。

character-level

我们在构造词表的时候，肯定是希望词表能够尽量少，同时，又能囊括我们想要的几乎所有的词。目前社会在发展，其实也催生出了很多新时代用词或者网络用语，如何处理好这些，也是我们需要考虑的一个内容。 前面两种维度或多或少都有一些问题。比如基于单词，对于一些新词无法去进行处理；比如基于字符的，又分得太细，词表也会很大。 所以就衍生出subword子词的切分方法。 比如这句话：I want to buy gpu! 通过子词切分，我们能得到：I/want/to/buy/gp/##u/! 可以看到，其实在切分的时候，会按照整个词的存在进行切分，比如以gpu来讲，切分了gp和u。

其实subword也有一些切分原则：1、高频词依旧为完整的词；2、低频词尽量分成有意义的词，就比如gpu=>gp/##u。 按照如上的切分方式也有一些好处，比如能学习到词缀之间的关系、词表规模处于适中、不会有UNK信息导致词丢失等。

目前基于subword进行切分的方法有BPE、WordPiece、SentencePiece、Unigram

后期篇章重点介绍子词分类的相关内容。

(完)

—————–EOF——————