申请到了 DALL·E 的账号，赶紧玩了几下。DALL·E 是个人工智能绘图程序，可以根据输入的文字绘制图片。它的水平肯定比不上经过训练的画师，但是对于我这种没有绘图能力的人来说，可能会有些帮助，比如，以后制作文档时，也许可以让它帮忙绘制一些插图。
我先画了一幅程序猿自画像：
(Photo of a chimpanzee sitting in front of a computer and programming)
儿子也画了一幅自己喜欢的图画：
(Cartoon of apples, peaches, grapes and many kinds of fruits growing on one tree under a clear sky with the moon shining on the background)
去年学习语言模型时，我尝试了一个小练习，训练了一个生成古诗的模型。虽然这个项目已经搁置了一段时间，但回顾其中的实践与思考，仍有不少值得总结之处。
选择古诗而非其他文体作为实验对象，原因在于古诗相较其他文体的生成难度相对较低，尤其对于机器学习模型而言。主要体现在以下几个方面：
文本长度短，记忆力要求低
文体的长度直接影响生成的难度。当前主流的语言模型“记忆力”有限，随着生成文字的增加，内容偏离主题的风险也随之提升。
一首古诗不过几十字，这种长度对个人电脑的训练能力十分友好。而像散文，通常篇幅在几百字以上，若要生成高质量的结果，则需要更强的硬件资源和分布式计算支持。至于小说，动辄数十万字，还需考虑情节铺垫和悬念回收等复杂结构，这对现阶段的技术而言仍是巨大的挑战。（但是可以预见，将来的模型可处理的文本长度会大幅增加，这些可能就不再是问题了。）
训练数据丰富且无版权限制
古诗作为历史文化遗产，其训练数据不仅数量丰富，而且大多不受版权限制。这一特性使得获取和使用数据的成本极低 ，为模型训练提供了良好的基础。
诗词曾是中华文化的瑰宝，尤其在唐宋时期达到辉煌的巅峰。然而，随着时代变迁，其社会影响力和受众群体逐渐式微，最终沦为一种小众爱好。其现状可以从以下几点观察：
失去大众市场
在唐宋之后，诗词逐渐退居二线，但由于科举制度的存在，写诗依然是士子必备的基本功。然而，现代社会中诗词的实际需求几乎消失，取而代之的是各种大众化的文艺形式，比如影视、音乐和网络文学。诗词不再具备广泛的市场需求。
观众寥寥，创作者维艰
任何文艺形式要兴盛，必然依赖大量广泛的观众群体。然而，今天的诗词圈正好相反：许多诗词网站依赖创作者支付会员费用维持运营，而不是通过吸引观众带来收益。写诗从一种创作行为变成了消费行为。这种缺乏观众支持的现状，也让新一代的创作者难以壮大。
应用价值局限
如今诗词的实际应用多局限于形式上的点缀——例如庆典活动中的背景装饰，甚至观众对这些诗词的质量关注甚少。相比古诗词的艺术价值，当代诗词的创作难以企及同样的高度，其鉴赏价值也因此受到限制。
尽管诗词的应用价值有限，但语言生成模型在其他领域仍大有可为。以我的个人经验为例，工作中定期需要撰写总结、评语、心得等各类文档，这些任务虽繁琐，却遵循固定格式，具备一定的规律性。如果语言生成模型能够在这方面实现更高水平的自动化，将极大提高效率。若能获取相关训练数据，我非常愿意尝试这一方向的模型开发。
此外，拓展到更广泛的文艺创作需求，相较于文字生成，音乐生成或许更具市场潜力。比如，许多视频节目需要配乐，而大部分配乐需求并不涉及复杂的艺术创作。如果AI能够实现这一领域的批量化、定制化创作，无疑会是一个广阔的应用场景。
早期的计算机解决问题时，大多遵循一种简单直接的思路：将解题规则逐步列出，再将其翻译成计算机可以执行的指令。这种方法在写诗领域也有过尝试，尤其是针对诗词中那些结构严谨、规则分明的特点。例如：
这些规则易于形式化，因而成为早期写诗程序最常采用的方法。然而，基于规则的算法产出的诗句却鲜有令人满意者。例如，这样的句子就出自规则生成的结果： “音挑山落但，下剩物拼贪。”这样的句子不但无法理解，也谈不上美感。
为何基于规则的写诗算法难以奏效？原因可归结为以下几点：
诗意的复杂性远超规则本身
写诗远非仅遵循表面格律规则即可，它还需兼顾以下层面：
这些层面的规则复杂且微妙，很多只能意会而难以言传。即便是明确的规则，逐字逐句罗列其所有约束条件也是一项极为繁重且几近不可能完成的任务。
规则本身也需要灵活性
优秀的诗歌并非一味遵循规则，而是懂得如何在恰当时机打破规则。例如：“白发三千丈”这一夸张的表达，完全无视自然界的真实情况，却以极强的画面感和情感力量成为传世佳句。由此可见，遵循规则是基础，但超越规则是艺术。
有用的规则往往不可量化
基于规则的写诗算法只能处理那些可量化的形式规则，而真正决定诗歌优劣的，是深植于人类经验、文化积淀和艺术直觉中的隐性规律。这些规律很难被精确描述，更难以转化为计算机可执行的指令。
正因如此，基于规则的算法在写诗领域难以突破，最终停滞不前。尽管它为后续的发展奠定了探索的基础，但也暴露了这种方法的局限性：仅靠规则，计算机难以触及诗歌的艺术核心。
以下是改进后的版本，增强了逻辑性、可读性和文采：
计算机与人类在能力上存在显著互补：计算机能够以极快的速度生成大量符合规则的文字，而人类在从中挑选出最合适的表达时展现了远超计算机的直觉和审美能力。换句话说，计算机擅长的是“量”，而人类擅长的是“质”。然而，当你不明确告诉计算机如何挑选最佳结果时，它只能随机组合文字，产生的质量自然不容乐观。
一种看似简单的改进思路是不断添加更多规则，为计算机挑选出更合适的文字提供指导。然而，问题在于：
规则的复杂性
写诗涉及的规则过于繁多且细致，想要全面罗列几乎不可能。人类的直觉和经验虽能在某些情况下提供灵感，但要系统化地表达这些隐性规则，无论从数量还是复杂度来看，都是极大的挑战。
规则的局限性
规则是人为制定的，往往只提供方向性指导，无法涵盖所有细节问题。而且，规则本质上是动态的：前人制定规则，后人便可能通过创新打破规则 。例如，“白发三千丈”这种夸张的表达，若完全依赖既定规则，很可能永远无法生成。
相比之下，规律是一种客观存在，深植于大量已有作品之中。这些规律有些是作者刻意为之，有些则是在创作中自然而然形成的。规律不仅超越了规则的局限性，还更贴近真实创作过程。想象一下，一个人学习写诗的历程：从掌握基本格律开始，到大量阅读经典作品，体会何为“好诗”，再到尝试借鉴这些特点，最终形成自己的风格。这种学习路径其实就是通过“发现规律”来指导创作。
利用统计学方法，我们可以从现有的诗词作品中提炼出一些显而易见的规律。例如：
高频词的统计
《全宋词》中的高频词包括“东风”“何处”“人间”“风流”“归去”“江南”“西湖”“斜阳”“明月”等。这些词因为使用频率高，往往容易被大众接受且令人感觉“顺眼”。如果计算机优先从这些高频词中选择，而非完全随机挑选，其生成的诗句就显得自然得多。例如，将这些高频词随机组合，便能得到这样的句子：
“回首明月，悠悠心事空；西湖何事寂寞中，风吹斜阳匆匆。”
虽非佳作，却不再令人别扭。
词语的搭配规律
仅靠高频词仍显不足，因为即便词语本身流行，搭配不当也可能产生极为拗口的句子，比如：“江南大漠凭栏鱼”。因此，还需引入词语搭配的统计规律。例如，“流水”常与“浮萍”“落花”“恋恋”“相随”等词搭配。如果诗句中已经选择了“流水”，后续用词便应优先从这些搭配中挑选。
对仗与修辞的规律
对仗是古诗中一项重要技巧。例如，“云对雨，雪对风；晚照对晴空。”通过总结这样的对仗规律，计算机可以更准确地生成符合古典风格的句子。此外，夸张、比喻、谐音等修辞手法也可以通过数据挖掘找到适当的应用场景。
尽管基于统计的规律挖掘能显著提升计算机作诗的能力，但它的潜力仍然受到研究者视野的限制。大多数规律总结工作是由缺乏创作经验的外行完成的，包括我在内，我并不擅长写诗。即便我们能提取出高频词、对仗结构和搭配习惯，也无法触及那些更为隐秘但至关重要的规律 - 比如何时使用特定的夸张手法能创造强烈的艺术冲击，或何种谐音梗能令人拍案叫绝。这些深层次规律往往超出人类的想象。
那么，我们能否进一步解放计算机的潜力？不仅让它总结规律，还能让它主动发现那些超出我们认知范围的隐性规律？让计算机不仅充当“辅助分析工具”，更成为“创作规则的研究者”，甚至在一定程度上超越我们的视野？答案或许正藏在深度学习和生成模型的潜力之中。
“机器学习”，顾名思义，是让计算机通过学习从数据中自动归纳出知识，而非依赖人工设定规则。简单来说，研究者向计算机提供一个训练集，比如《唐诗三百首》，不需要明确告诉它学习的具体细节，只需让它通过数据中的模式自行学习，并根据这些知识生成输出。
虽然“机器学习”这一概念并不新鲜，它的历史可以追溯到几十年前，但近年来，由于算法改进和硬件性能的飞跃，其应用在自然语言处理领域取得了巨大的突破。在自然语言处理中，常见的任务包括分类（如垃圾邮件检测）、问答、摘要生成、翻译、对话生成等。尽管这些任务看似各异，它们实际上可以用统一的“文字生成”框架来解决。所谓文字生成，就是根据输入的“上文”生成合适的“下文”。例如：
对于简单的任务，例如垃圾邮件分类，可以用朴素贝叶斯分类器等传统算法解决。然而，文字生成是一个极其复杂的问题，必须借助更先进的技术——人工神经网络。
人工神经网络模仿生物大脑 ，通过大量“神经元”相互连接组成的网络进行学习和推理。神经网络的核心并不在于神经元本身，而在于连接神经元之间的权重（Weights），这些权重就是我们常说的“参数”。
模型的规模通常以参数量来衡量。当年我在学校做作业时，设计的网络可能只有几百个参数。而文字生成问题极其复杂，我曾训练的诗词生成模型，参数量已达上亿级别。
如今，在文字生成领域表现出色的模型如 GPT-3，其参数量高达 1750 亿个。虽然这个数字看似庞大，但如果将其类比为生物大脑中的“突触”（即神经元之间的连接点），它实际上仍远小于人类大脑的规模（人脑约有 100 万亿个突触）。尽管如此，这种规模的计算能力已经足以让模型在语言处理上展现出惊人的“智能”。尽管目前的模型还无法真正达到人类情感创作的深度，但它们正在以惊人的速度缩小这一差距。
有了强大的机器学习能力，像我这样的诗词门外汉似乎也无需了解太多创作技巧，只需将现有的诗词交给模型，让它“学习”即可。然而，这样训练出的模型只能复制已有数据中的特性，难以超越其局限性。例如：
假设《唐诗三百首》中只有关于“牛”的诗句，却没有提到“羊”。模型可以轻松学会“牛吃草，牛挤奶”，并在创作中重复这些内容。但它很可能永远不会主动生成“羊吃草，羊挤奶”，尽管在人类看来，这种类比是显而易见的 。这暴露了机器学习模型的局限性：它只会重复训练集中的模式，而缺乏人类直觉中那种跨领域的类比能力。
为克服上述问题，现代语言模型通常引入预训练机制。在正式训练模型生成诗词之前，先用更大、更广泛的语料库（例如维基百科）进行预训练，让模型学习普遍的世界知识和语言规律。通过这种方式，模型能够建立更全面的认知。例如，通过预训练，模型知道“牛”和“羊”都是食草动物，具有相似的生活习性。当进入诗词训练阶段时，即便训练集中只有“牛吃草”的诗句，模型也能推理出“羊吃草”这样的创作内容。
这种方法显著扩展了模型的创作潜力，使其不再局限于训练集中的内容，而是能够结合预训练知识进行更有创造力的生成。事实上，预训练的引入也是近年来大规模语言模型取得成功的重要原因之一。通过这种方式，机器不仅能够学习规则和规律，还能在一定程度上模拟人类的类比和联想，为写诗等创作任务注入更多灵感与可能性。
在开始练习之前，我先研究了一些公开的诗词生成模型。简单的LSTM（长短期记忆网络）或seq2seq（序列到序列）模型虽然在处理语言生成问题上有一定的表现，但生成的诗句通常缺乏自然流畅感。真正效果较好的模型，几乎都是近年来基于超大预训练模型（如BERT、GPT）训练而成的。我在GitHub上找到了一些例子，其中某些生成的诗句质量之高，甚至让我这个理科生都难以分辨是AI创作还是人类创作。
通常情况下，模型越大，生成效果越好。然而，模型规模越大，训练所需的时间和资源成本也随之增加。此外，不同的预训练模型在使用上也有差异：有些可以直接用于文本生成，而另一些则需要额外添加神经网络层进行调整。
出于学习和练习的目的，我选择了GPT-2的小型模型。这种模型虽然在长文本生成方面可能稍显不足，但在诗词生成的场景中已经足够胜任。更重要的是，GPT-2可以直接进行文本生成，使用起来非常方便。
尽管GPT-2的小型模型已经简化了训练和使用过程，但其成本仍然需要仔细权衡。以下是一些关键的成本和性能因素：
训练成本
使用GPU进行模型训练可以显著提高速度。训练一个小型GPT-2模型通常需要一到两天时间，即使租用云端GPU，费用仍在可接受范围内。然而，对于长期部署和发布，GPU的成本可能成为一大障碍。
预测性能
使用CPU运行GPT-2模型进行预测时，每次生成大约需要十秒钟，这对于实时应用来说显得过慢。相比之下，使用GPU可以将预测时间缩短到十分之一甚至更少，但同时也显著增加了运行成本。
云服务器成本
当前云服务的价格差异较大。例如，仅使用CPU的云服务器，每年费用大约￥70；而配备GPU的服务器，每年费用则高达￥7000左右。这种成本差距直接影响到模型的实际部署选择。
综合考虑了性能和成本，我最终选择在本地用GPU完成短期训练任务，而在日常运行中依赖CPU。虽然这种配置可能牺牲了一些响应速度，但在预算限制内，仍然是较为平衡的方案。
在整个项目中，整理训练集是最耗时费力的一项工作。对于大多数机器学习项目来说，训练集通常是“越大越好”，但在诗词生成任务中并非如此。虽然古人创作了大量诗词，但真正流传至今、被认可为高水平作品的只是极少数。如果将质量参差不齐的诗词都纳入训练集，模型很可能学不到优秀的创作风格，反而会受到劣质样本的干扰。
理想情况下，训练集应仅包含那些公认的高水平诗词。此外，过大的训练集还可能激励模型生成一些不常用的生僻字或词。这些词语若使用不当，会显著 降低作品的可读性。而高频词汇如“风月”“山水”等，无论如何搭配，通常都能保证生成的诗句具有较好的流畅性和观感。
小规模的高质量训练集虽然能够提升生成内容的质量，但其覆盖的主题往往较为有限。我目前使用的训练集相对较小，主要包括《千家诗》《唐诗三百首》以及一些我个人偏爱的诗词作品。这个数据集在常见的风花雪月题材上表现尚可，但在涉及未训练过的主题（如现代科技或建设类题材）时，生成效果明显不足。
如果资源允许，可以采用更大的训练集，同时为不同质量的诗词样本分配权重。这样一来，高质量的作品可以对模型的训练产生更大的影响，提升整体生成效果。
诗词的合辙押韵是一项重要特性，但我在练习中并未对此进行专门处理。直接向程序添加人为指定的平仄、尾韵等规则并非最佳方案。事实上，许多流传千古的经典古诗在现代普通话语音体系下，已经不再完全押韵，或仅实现宽松的韵律要求。审美上，人们对这些诗词早已适应，因此过度强调押韵可能反而影响生成诗词的自然性与美感。
最优解是让模型通过学习数据集中的韵律信息，自主掌握如何生成自然的押韵诗句。然而，目前我的训练集中仅包含文字信息，缺乏音韵相关的标注。解决 办法是将发音信息加入数据集。例如，将“风雨送悲声”扩展为“风feng1雨yu3送song4悲bei1声sheng1”。通过这种“字+拼音”的格式，模型可以学习到平仄与押韵的规律，从而提升生成的诗词在韵律上的自然性。
目前的训练集也未包含文字的书写信息，因此模型无法掌握诸如拆字对联等更复杂的诗词创作功能。如果将汉字的结构信息纳入数据集，例如通过图像表示文字的书写方式，或者将其抽象为偏旁部首的组合，模型就有可能学习到与汉字结构相关的创作技巧，从而实现更多元化的生成能力。
在机器学习中，损失函数（Loss Function） 是指导模型学习的“指挥棒”。模型训练的本质，就是通过不断调整参数，让这个损失函数的值变得最小。
我最初使用了语言模型最标准的交叉熵损失（Cross-Entropy Loss）。简单来说，它的作用是让模型预测下一个字的概率分布尽可能接近人类写出的真实文本。。
然而，交叉熵只关注“预测得准不准”，却不关心“写得美不美”。它无法直接理解古诗特有的硬性约束，比如押韵和平仄。为了解决这个问题，通常有几种进阶思路：
对于我的这个小练习项目，主要还是依赖第一种（数据层面）和基础的交叉熵训练，因为后两者的实现成本和技术门槛相对较高。
此外可以考虑引入一些额外的损失函数或修改训练策略，以显式地引导模型学习诗歌的特有规律：
韵律损失（Rhyme Loss）： 可以通过计算生成诗句的韵脚与目标韵脚之间的差异来定义韵律损失。例如，可以使用编辑距离（Levenshtein Distance）或基于发音相似度的指标来衡量韵脚的相似程度。将韵律损失与交叉熵损失加权求和，可以促使模型生成更符合韵律要求的诗句。更进一步，可以考虑平仄格律，设计更精细的韵律损失函数。
对仗损失（Parallelism Loss）： 对于律诗等讲究对仗的诗歌形式，可以设计对仗损失来衡量上下句之间的结构相似性和语义关联性。例如，可以计算上下句词向量的余弦相似度，或者使用句法分析等方法来比较句子的结构。
主题一致性损失（Topic Coherence Loss）： 为了保证生成的诗歌围绕一个中心主 题展开，可以引入主题一致性损失。例如，可以使用主题模型（如LDA）提取诗歌的主题向量，并计算生成诗句与主题向量之间的相似度。
词语多样性损失（Word Diversity Loss）： 为了避免模型生成重复或单调的词语，可以引入词语多样性损失。例如，可以惩罚模型生成高频词或重复使用某个词语的行为。一种简单的方法是计算生成诗句中不同词语的数量，并将其作为损失函数的一部分。
除了修改损失函数，还可以通过调整训练数据来弥补模型学习的不足。例如，在训练集中尽量避免包含过多重复词语的诗句，或者人为地标注诗句的韵脚、对仗关系等信息，以帮助模型更好地学习这些规律。通过精心设计损失函数和训练数据，可以有效地提高模型生成诗歌的质量和艺术性。
模型训练时间是一个重要的考量因素，它直接关系到开发效率和资源成本。正如我之前的经验，使用GPU进行训练可以显著提高速度，相比CPU训练，速度提升可达一到两个数量级。这主要是因为GPU拥有强大的并行计算能力，能够高效地处理神经网络中的大量矩阵运算。
训练时间的长短与多种因素相关，包括：
在我最初的实验中，由于模型和数据集规模相对较小，使用GPU训练一两个小时就能取得不错的效果。然而，在这个阶段，模型偶尔会产生一些“莫名其妙”的结果，例如不符合语法规则的句子或意义不明的词语组合。这通常是由于模型尚未充分学习到语言的内在规律。
增加训练时间可以使模型更好地拟合训练数据，从而减少此类错误。然而，过长的训练时间也可能导致过拟合（Overfitting），即模型过度学习了训练数据中的噪声和细节，而失去了泛化能力，导致在新的数据上表现不佳。此外，正如我个人的感受，过长的训练时间可能会使模型变得过于“规范”，从而削弱了预训练数据带来的“天马行空”的创造力。
这种现象可以用偏差-方差权衡（Bias-Variance Tradeoff）来解释。较短的训练时间可能导致模型偏差较大，即未能充分学习到训练数据中的规律；而过长的训练时间则可能导致模型方差较大，即对训练数据中的噪声过于敏感。理想的训练时间应该在偏差和方差之间取得平衡，使模型既能准确地捕捉数据中的规律，又能保持一定的泛化能力和创造力。
因此，确定最佳的训练时间需要进行仔细的实验和调优。一种常用的方法是使用**验证集（Validation Set）**来监控模型的训练过程。在每个训练周期结束后，使用验证集评估模型的性能，并根据验证集上的表现来调整训练参数和提前终止训练，以避免过拟合。
总之，训练时间的选择是一个需要在效率、泛化能力和创造力之间进行权衡的过程。通过合理的实验和调优，可以找到最佳的训练策略，使模型既能生成规范的诗句，又能保持一定的 创造性和艺术性。
对于任何生成模型而言，最终的评判标准都落实在其输出质量上。由于我并非诗词领域的专家，因此只进行一些最浅显的比较分析。
1. 对联生成：展现一定的理解能力
对联是对诗歌创作能力的初步考察。以“倦鸟无心归去”为上联，模型生成的下联“野花有意偷开”展现出一定的理解能力。“倦鸟”与“野花”构成意象上的对比，“无心”与“有意”形成情感上的反差，“归去”与“偷开”则在动作上呼应，整体对仗工整，意境也颇为和谐。虽然我并不认为模型真正“理解”了野花的“有意”，但它成功地捕捉到了训练数据中“野花”与“开放”、“烂漫”等意象的关联，并将其运用到对联生成中。
然而，模型也并非总是表现出色。例如，看到这一副生成的对联时，我差点一口老血喷到屏幕上：“千家百姓，共建和谐社会；三宫六院，同沾雨露春风”。这副对联虽然在形式上对仗工整，但内容上却显得格格不入。“和谐社会”是现代政治语境下的概念，“三宫六院”则是古代帝王生活的写照，两者在时空和语境上存在巨大的冲突。这表明模型在理解语境和常识方面仍然存在不足。
2. 诗歌生成：空灵意境与主题缺失
模型生成的诗歌在描绘自然景物方面表现出一定的优势，能够营造出空灵的意境，例如：
风卷残阳去，云敛暮雨收。身羁千里外，白发几时休。 故国关山隔，天涯岁月悠。相思无处寄，明月满西楼。
这首诗描绘了夕 阳西下、暮雨初歇的景象，表达了漂泊天涯、思乡怀人的情感。诗句流畅自然，意境较为完整。
然而，模型生成的诗歌也暴露出一些问题：
正如我之前所说，诗人一生的经历和情感都会融入到作品中，而模型缺乏人类的经历和情感，因此难以创作出具有深刻内涵和独特风格的诗歌。从某种意义上说，模型更擅长生成“空洞”的诗歌，即那些不需要具体内容支撑、以描景抒情为主的诗歌。但这并非完全是缺点。在某些场景下，例如商业宣传、节日祝福、对领导歌功颂德等，这种“空洞”的诗歌反而更受欢迎。
3. 示例诗歌：展示生成能力
以下是一些经过挑选和改进的，（其实模型本身还不没达到稳定生成高质量诗歌的水平）供读者参考：
城南雨过花含泪，陌上风来柳化烟。远客扶杖回首望，长亭别后共谁言。
晓日照野烟，春风拂青山。谁家新酿熟，香透小楼间。
潭清月冷影自长，山空竹瘦共疏凉。浮云过眼心如水，一任清风送晚香。
痒来无奈手频抓，愈搔愈烈乱如麻。世间欲念多如此，不动心时气自华。
太虚如洗夜澄清，银汉悠悠接远星。下界尘埃皆是幻，心归云外自安宁。
一念不生即是禅，本来无字不须传。拈花不管人知否，云在青天水在渊。
《溪山独步》 独爱云山境，岚烟锁竹扉。翠微笼野舍，冷蕊点槿篱。 荷锄带月返，闭户焚香迟。醉卧松根石，唯有梦相依。
《忆秦娥·春思》 飞花坠，纷纷一晌伤离别。伤离别，凝眸深处，烟波凄切。 鲛绡湿透春衫冷，淡匀红粉画楼空。画楼空，雁归天际，梦断锦书绝。
这些例子展示了模型在生成诗歌方面的潜力。虽然仍然存在一些不足，但考虑到这只是一个个人练习项目，取得这样的结果已经相当不错。
最近测试了一些翻新旧照片的算法，主要是试着把模糊的小照片翻新成清晰的大照片。据说淘宝上有很多人做这个生意，主要是靠手工来修复的。网络少也有不少PS修复旧照片的教程。不过我不会使用PS，所以只能依靠算法了。修复旧照的人工智能的算法也是有一些的，但目前来说，人工智能算法的修复效果在总体上还是比不了人工修复的，但某些情况下表现也还不错。
第1步 选照片
首先找一张老照片：
要想效果好，照片一定要找上图这样的：大头照，而且只有少量折痕和磨损。我也测试了一些质量更差的照片（人脸所占像素太小，有大片磨损等），人工智能对于它们目前还还无能为力。
第2步 去网纹
很多老照片都不是光滑的，像纸上有排列规则的凸点，扫描之后的图片上就会有网纹。上图的旧照片上可以明显看到这些网纹。我找的几个人工智能程序都是解决特定问题的，无法很好的处理这些网纹，所以先要人工去除这些网纹。网上搜了一下，没有专门去除网纹的程序，只有PS相关的教程。PS是收费软件，我也没有。好在有一些免费的图像处理软件可以替代PS。我用了GIMP（GNU Image Manipulation Program）加上FFT插件。FFT是快速傅里叶变换的缩写，用于把时域信号转换为频域信号。
上图经过傅立叶变换，在频域上的图像如下（灰度图部分）：
由于原照片里的网纹是规则的（有固定频率），频域图会在一些特定的频段里出现高能量区域，也就是上图用红圈圈出来的部分。我只画了三个圈，但其它那些亮点（除了中心低频区域外），都是网纹造成的，只要把这些亮点全部涂黑，再做反傅立叶变换，新生成的图片就是被去除了网纹的照片了。
第3步 上色
GitHub上最受欢迎的黑白照片上色程序是这个：https://github.com/jantic/DeOldify
我试了一下，效果只能说马马虎虎，上了色的照片看上去还是像旧照片，只是把原来的纯 黑白色调中加入一点肉色，一看就不是真的彩色照片。
如果会PS的，肯定还是PS效果好。
第4步 清晰化
我在GitHub上找到了两个照片变清晰的软件，一个是微软的 https://github.com/microsoft/Bringing-Old-Photos-Back-to-Life
一个是腾讯的 https://github.com/TencentARC/GFPGAN
两个软件各有千秋，比如微软的可以修复裂痕，但腾讯的可以放大照片。具体那个效果更好，要针对不同情况测试一下。
这两个软件都是侧重于对人头像进行优化，对其它区域的优化会差一些，所以经过它们优化的照片常常是人脸非常清晰，但衣服还是模糊的。再有它们对于眼镜的处理都不太好。常把眼镜当成皱纹；或者把眼镜上的反光当作眼睛来处理。有时候生成的照片非常诡异吓人。
另外，它们也没法处理太小的人像，或是有缺损的人像。
处理后的效果
最近学习了 React，并借助 Docusaurus 重新制作了书籍网页：https://lv.qizhen.xyz/
实际上，Docusaurus 已经帮我做了绝大部分工作，React 技能几乎没派上用场，毕竟书籍的格式还是比较简单固定的，不需要非常炫酷的界面。
之前我使用 Docsify 制作网页，对其简洁的界面和实用的功能一直很满意。然而，Docsify 的最大问题在于它采用客户端渲染，导致搜索引擎无法有效爬取页面内容。在墙外，Google 几乎垄断了搜索市场，但它对客户端渲染页面的支持并不理想。国内的搜索市场竞争虽然激烈，但各大引擎在这方面表现得比 Google 更差。因此，为了提高网页的可见性和 SEO 效果，我决定寻找更适合服务端渲染的工具，最终选择了 Docusaurus。
Docusaurus 确实比 Docsify 更复杂，入门门槛也稍高。Docsify 专注于文档页面，而 Docusaurus 除了文档，还支持个人主页和博客等多种内容形式。因此，Docusaurus 的配置和插件系统更为复杂，但灵活性也更高。Docusaurus 支持服务端渲染，生成静态 HTML 页面，这使得 Google 可以顺利爬取我的网页内容。尽管国内搜索引擎目前依然无效，但问题可能出在我的域名未通过工信部认证，而非 Docusaurus 本身的限制。与 Docsify 的“所见即所得”不同，Docusaurus 需要经过 build 步骤才能生成最终页面，这对初学者来说可能有些不习惯。此外，作为较新的工具，Docusaurus 的中文资料相对较少，但社区活跃，更新速度快。
尽管学习曲线略陡，但 Docusaurus 的整体体验非常令人满意。特别是在 SEO、功能扩展和界面设计上，Docusaurus 显示 出强大的潜力和灵活性。
初次尝试搭建电子书网站时，由于缺乏经验，许多技术问题都是在实践中逐步暴露的。先大致总结一下。
最开始弄的时候，没有借助任何工具，直接就开始搭网页了。当然底层的库用的还是别人写好的，比如最主要的部分，把Markdown格式文档（MD）转换成HTML格式用的是marked.js。上层的代码也并非完全从头开始写， 我也参考了别人的代码。不用工具，自己写的最大好处是让我学习了很多以前不会的技能。以前是没做过网站前端开发的，Javascript也没用过。现在能做个简单网页了。
但是学习过后，发现如果把网页功能完善起来，全自己开发太费时间了。而且继续花时间对我学习的帮助也没有之前那么大了。于是我还是用了工具把网页从新做了一边。最著名的工具大概是 gitbook-cli，一个GitBook发布的旧版本的开源工具。这个工具是在线下把Markdown格式文档转换成HTML格式文档的。更新一个页面的流程大约是这样：找到需要更新的MD文档，修改保存，运行gitbook-cli，生成HTML文档，把生成的HTML文档上传至GitHub。步骤有点繁琐，不是我想要的。而且gitbook-cli有四五年没更新了吧，直接下载后不做点配置都根本运行不起来了。所以放弃了。
后来是用的Docsify重新生成了网站。Docsify还是很简单易用的，不过bug也是很多。有一些bug我直接在本地修改了，但有一些是我没法改的，比如最简单的，它对于HTML tag中图片的路径解析跟别人都不一样，比如：<img src="images/image192.png">。它用绝对路径来解析，而其它MD转换工具全部用的相对路径。这个问题我估计Docsify自己也没法改了。不过我现在还有临时解决办法，先将就着用一段时间吧。Docsify生成的网站最大的问题还是没办法被搜索引擎检索，当然也可以说这是搜索引擎不够强大，但是我也没法改变搜索引擎，只能再改进自己的网页了。
Docsify和我最开始写的网页原理完全相同，都是在客户端做渲染，服务器并没有给客户端发送任何HTML格式内容，而现在的搜索引擎只认HTML，它们是不会运行渲染程序的。所以也就没法抓到任何内容。要想被搜索引擎认识，还是得有HTML文件才行。有些网站是可以帮我们做这件事的，比如GitBook。我在GitBook上也生成了一份电子书，https://labview.qizhen.xyz/ 。在GitBook上做电子书网页，基本没有任何可以配置的东西，所有的网页都长一个模样。这也不是设么大问题，但它无法提供留言功能，还是非常不爽的，我就喜欢看留言。GitBook收费版可能有留言功能，不过穷人并没有尝试付费版。
穷人也不是完全没办法，我们开可以利用GitHub Actions这个免费功能来实现HTML文档的自动生成和部署。GitHub Pages默认就集成了一个Action流程，它可以在每次用户更新 MD 文 件之后就调用Jekyll这个工具，为更新的MD文档生成HTML文档在部署到服务器上。只不过GitHub Pages默认的工具对生成的网站有一定格式限制，比较适合做博客，不适合发布书籍。其实可以不用它默认的工具，而是利用GitHub Actions调用一个更适合电子书的转换工具，在MD文件更新后做自动转换和部署。近期我还不会尝试这件事，因为React这个东西我才学了一半，业余时间就那么一点，先抓紧时间学完React再去建新网页。至于转换工具，我会去使用 Docusaurus，因为它使用React写的，正好让我学完了可以实践一下。
我把书的原稿开源后放到了 GitHub 上，并制作了一个页面方便阅读。制作的网页是一个单页面应用，也就是说书中的所有内容都在同一个页面中：https://lv.qizhen.xyz/。别看每个章节的地址栏都会显示不同的 URL，比如：https://lv.qizhen.xyz/#docs/structure_condition，实际上 # 号后面的部分只是同一页面的不同参数而已。
浏览器展示的内容 是 HTML 格式，但 GitHub 的网站并没有存储 HTML 格式的文档。所有文档都以 Markdown（.md）格式保存。GitHub 的网站不会动态地将 Markdown 格式的文件渲染为 HTML 再传给读者的浏览器，而是直接发送 Markdown 数据。最终由浏览器端运行的一段 JavaScript 程序将 Markdown 数据渲染成 HTML。
GitHub 的服务器似乎不支持后台渲染。做成前台渲染的单页面应用对用户体验会更友好，比如页面切换速度较快，还可以动态改变背景配色等。但这种做法对搜索引擎并不友好。
搜索引擎在检索网站时存在两大问题：
总之，搜索引擎无法读取书中的任何内容，这也就意味着用户不可能通过搜索引擎找到它。
目前我还没有解决这个问题的方案。不过，在 GitHub 上搭建博客有很多其他方法，有些工具可以生成静态 HTML 页面，这种方式应该不会有类似的问题。等有时间再尝试其他工具吧。
此外，GitHub 自带的搜索功能对于中文书籍几乎没有用。它按“词”进行搜索，但 GitHub 定义的“词”是两个空格或符号之间的字符串。对于代码或英文文档来说，这种方式非常适合。然而，由于中文词语之间没有空格，GitHub 搜索中文时只能整句匹配。只有当文章中的某句内容与搜索内容完全一致时，搜索结果才会显示出来。
都是实名认证弄出来的麻烦，看这趋势，以后国内外的网络世界恐怕要彻底分离了。
前一阵子，我买了一个域名 https://www.qizhen.xyz/ 。为什么选择 .xyz 后缀呢？因为便宜！穷人也想要个独立域名，所以只能降低要求。随后，我把家里的电脑配置成了一台服务器。要让别人能访问我的服务器，需要使用内网穿透软件。考虑到墙内的限制，首选当然是国内的软件。我试用了“花生壳”等几款较为知名的软件，功能做得不错。不过，这些软件需要手机认证，这还算好，我请国内的亲戚帮忙认证，虽然麻烦，但总算通过了。
但接下来的问题就更麻烦了：一是客户端不允许国外 IP 登录；二是使用的域名必须是工信部注册的。我尝试通过腾讯云办理工信部备案，结果发现实名认证更加严格。不仅需要打开微信小程序进行实时视频认证，还会检测我的 IP 地址。因为我的 IP 位于国外，认证直接失败了。
好吧，这难不倒软件工程师。我转而尝试自己搭建 FRP 服务实现内网穿透。在腾讯云上购买了一台国内最便宜的服务器。但接着发现一个新问题：根本无法连上服务器！起初我以为是配置出错，后来才 意识到是墙的原因 - 服务器 IP 和我的 IP 之间根本无法互通。原本以为墙只是阻挡特定网站，没想到国内运营商可能为了省事，干脆直接封禁了一整段 IP 地址。或许换其他云服务商会好些，但我选择腾讯云是因为它支持微信登录，即便我的微信是美国账号，这确实方便了不少。无奈之下，我只能改用腾讯云在美国的服务器。这台服务器的 IP 地址能被国内外用户访问，问题总算勉强解决了。
政策带来的限制虽麻烦，但产品如果足够好，总能找到替代方案。然而，如果产品质量也很差，那就真的无路可走了。新浪的产品就是这样。前些天看到一则新闻，说近几年新浪微博的收入大幅增长。我不禁感到惊讶：还有人用微博吗？
曾几何时，新浪是我每天必登录的网站，也是获取新闻的重要来源。新浪的博客、微博都曾风靡一时。然而，随着产品质量不断下降，身边的朋友也逐渐远离这个平台。我自己曾尝试过使用新浪博客，但它的用户体验极差，尤其是敏感词问题。经常是我费尽心力写了一篇技术文章，发布时却被提示“包含敏感词，无法发布”。然而，系统根本不告诉你哪些是敏感词，导致完全无从修改。
后来，我果断放弃了新浪，改用 WordPress 作为博客平台。虽然国内读者都无法访问了，但至少我还发的出文章。现在看来，幸好当初没坚持使用新浪博客，因为，再后来我甚至完全无法登陆新浪了。登录新浪博客时需要手机验证，但无论是国内手机号还是国外手机号，我都无法通过验证。大概还是因为我的 IP 地址位于国外吧。
虽然我无法登陆新浪微博，但却意外发现我的微博账号似乎被一个机器人接管了！它正在自动关注其他账号并转发内容，大约每小时关注一个陌生账号，并不断转发一些毫无意义的内 容。我查看了一下以前几个好友的微博账号，发现他们大多已经很久未登录，有几个也被类似的机器人控制着，重复着自动关注和转发的任务。
现在，我总算明白了新浪微博的“活跃用户”数据是从哪里来的。令人唏嘘，曾经的新浪居然堕落到如此地步。
花了好几天时间，其中一天我甚至请了假专门来整理。虽然目前仍然存在一些排版上的问题，但这些只能慢慢修改完善了。
Markdown 格式在某些功能上还是有局限性的，尤其是处理表格时。最大的问题是它不支持无表头的表格。将 Word 文档转换为 Markdown 格式时，大部分表格不得不直接使用 HTML 标签。这虽然在显示上没有问题，但编辑起来却相当麻烦——满眼都是标签，想要找到需要的内容变得异常困难。
在这里要特别感谢 lhb5883 网友，他最初建议我使用 GitHub 搭建博客。这才让我发现，原来 GitHub 既没有被墙（希望我不是乌鸦嘴），也确实是最适合托管开源项目的平台。唯一让我担心的是，LabVIEW 用户中可能有很多人不熟悉 GitHub 的使用方法。
这堵“墙”给我造成了许多麻烦，更糟的是，它似乎还在变得越来越高。有些人可能认为这堵墙只是为了圈住里面的人，但实际上它是双向的。我在国外访问国内网站也越来越困难了。例如，我已经完全无法使用新浪博客了。最开始还能浏览页面但无法查看评论，后来甚至连正文加载都不正常了。而现在，登录还必须每次通过国内手机接收验证码。
目前，国内用户量较大的网站几乎都要求手机注册和验证。这意味着，我无法再正常使用大多数常用网站。如果只是注册时需要手机号，我还能请国内的亲戚帮忙，但有些网站每次登录都要手机验证，这就彻底把国外用户挡在门外了。
这次把书开源的过程中，我学到了一些网页构建的知识。在此之前，我几乎没有任何网页开发经验。不过，对于是否将博客也迁移到 GitHub，我仍有些犹豫。原因是旧博客的内容非常多，包括大量的图片、链接以及留言等，这些迁移起来的工作量可能远远超过一本书。我还需要进一步研究是否有更高效的迁移方案，争取找到更简单的做法。
最近阅读了一篇关于算法的文章，其中提到了一个有趣的话题 - 不可解问题。这让我产生了很多思考，并试图梳理一下这个领域的核心概念和相关问题。
不可解问题的本质是它们无法通过任何算法解决。更具体地说，无论我们多么聪明地设计程序，都无法在有限时间内为这些问题得出明确答案。这类问题往往与“无限性”或“逻辑不完备性”密切相关。
根据我的理解，不可解问题大致可以分为以下几类：
这类问题的本质在于问题的规模或维度是无限的，因此无法在有限时间内穷尽所有可能的答案。
打印出所有的整数：
如果试图设计一个算法来“打印出所有整数”，会发现这是不可能完成的任务。因为整数的集合是无限的，无论算法运行多久，都无法穷尽所有的整数。
停机问题（Halting Problem）：
阿兰·图灵提出的停机问题是计算理论中的经典不可解问题。它描述的是：对于任意一段程序代码，无法设计一个通用算法来判断它是否会在有限时间内停止运行。
这是由于程序的行为可能涉及无限递归或复杂的条件分支，导致算法无法预见所有可能性。图灵通过“对角线论证法”严格证明了停机问题的不可解性。
这类不可解问题源于数学或逻辑体系的局限性。某些问题无法在现有公理体系下被证明或否定，因此在当前框架下它们是“不可解”的。
哥德尔不完备定理：
哥德尔证明了在任何足够强的公理化数学体系中，都存在既无法证明也无法否定的陈述。这意味着某些数学问题无法在该体系内被解决，除非扩展公理体系。
哥德巴赫猜想：
哥德巴赫猜想（“任何大于2的偶数都可以表示为两个素数之和”）尚未被证明或证伪。因此，它可能属于暂时不可解的问题。
如果有一天数学家发现，现有公理体系无法涵盖哥德巴赫猜想的证明，可能会将它作为新公理加入数学体系，使其成为“可解”的问题。
不可解问题不仅是理论上的障碍，也是计算机科学和数学发展的驱动力。它们促使我们深入思考算法的边界、公理体系的完备性，以及问题求解的本质。
停机问题和其他类似的不可解问题让我们意识到，不是所有问题都能用算法解决。这为计算理论奠定了基础，并促使研究者探索可解问题与不可解问题之间的边界。
逻辑体系中的不可解问题，例如哥德尔不完备定理，揭示了数学体系的局限性。这一发现激发了数学家不断完善和扩展公理体系，并推动了领域的进一步发展。
虽然某些问题在理论上不可解，但它们的某些特定子集可能是可解的。例如，在停机 问题中，特定条件下的程序（如无递归的程序）可以通过分析得出是否会停机。
不可解问题并非“绝望”的代名词，而是帮助我们认识到问题复杂性和解决方式多样性的一个起点。在实际工作中，我们并不总是追求绝对的解，而是希望找到高效、实用的近似解法。这种思路也体现在人工智能和机器学习等领域：虽然可能无法设计一个算法解决所有问题，但我们可以为大部分问题找到足够好的解决方案。
与此同时，我也好奇：是否还有其他类型的不可解问题？例如，能否定义与随机性或量子现象相关的全新不可解问题？
最近看到新闻，今年诺贝尔医学奖授予了三位在免疫系统研究领域作出杰出贡献的科学家。这几天正好在照顾生病的豆豆，观察着发烧、炎症这些身体的“防御反应”，我对免疫系统的工作机制有了更感性的认识。作为一名软件工程师，在陪伴孩子的间隙，我的思绪不知不觉转到了老本行——计算机病毒防御上。我发现 ，人类免疫系统的精妙设计，为计算机安全防护提供了绝佳的蓝图。
如果深入分析，我们会发现目前的计算机防御体系与生物免疫系统有着惊人的对应关系，但以往我们可能误解了它们的对应角色。
生物学原理： 固有免疫是人体的第一道防线（如巨噬细胞）。它不需要“见过”特定的病菌，而是通过识别广谱的“危险特征”（如细菌细胞壁的通用成分）来立即通过炎症反应通过攻击。 计算机映射： 这对应着现代安全软件中的**“启发式分析”与“行为监控”**。防御系统不需要知道病毒的名字，只要检测到“像坏人”的动作——比如一个程序试图在短时间内修改大量文件（勒索行为），或者未经授权注入系统进程——就会立即拦截。这是一种通用但粗颗粒度的防御。
生物学原理： 当固有免疫无法搞定时，适应性免疫登场。它通过分析特定抗原，生成专门的“抗体”。这种机制启动慢，但极度精准，且具有记忆功能（疫苗原理）。 计算机映射： 这正是最传统的**“特征码匹配”**。安全厂商分析出病毒的独特代码片段（抗原），更新到病毒库中。杀毒软件扫描时，如果发现文件指纹与特征库匹配，就进行清除。它的缺点显而易见：对于全新的病毒（零日攻击），在特征库更新前，系统是“裸奔”的。
调节性 T 细胞（Tregs）是免疫系统的“刹车片”，负责告诉免疫细胞“这是自己人，不要开火”。如果没有这套机制，免疫系统就会攻击人体自身组织，导致红斑狼疮等自身免疫疾病。
这一概念直击当前计算机防御的痛点：误报（False Positives）。
在安全领域，“误报”就是计算机的“自身免疫病”。作为程序员，我们都经历过自己编译的工具被杀毒软件误删，或者正常的系统更新被防火墙拦截。这是因为安全软件缺乏高级的“免疫耐受”机制——它分不清什么是恶意的破坏，什么是管理员或开发者的“特权操作”。
基于上述思考，我认为未来的（或者说正在演进的）防病毒软件将不再是简单的“杀毒工具”，而是一个具备完整免疫逻辑的智能系统：
未来的防御不应仅依赖静态规则，而应利用机器学习建立设备及其用户的“正常行为基线”。
我们需要引入类似“调节性 T 细胞”的机制来区分“自我（Self）”和“非我（Non-self）”。
未来的系统在遭遇新型攻击时，不应被动等待厂商更新病毒库，而应具备本地反击能力。
尽管这种仿生学的防御愿景令人兴奋，但实现起来困难重重：
计算机安全技术正在经历从“被动查杀”到“主动免疫”的范式转变。随着人工智能的发展，我们期待未来的计算机能像人体一样，既能雷霆万钧地消灭入侵者，又能温柔精准地呵护系统自身的运行，真正实现“智能免疫”。
那将是人机共生的新高度，也是我在照顾豆豆时，对技术未来的小小遐想。