大模型时代程序员的正确姿势
过去的一年中，最炙手可热的是以扩散模型和大语言模型为代表的 AIGC 技术的普及。在可预见的未来，这种热度仍将持续下去。无论主观上是否愿意，AIGC 已经在重构我们的工作流程，重构人与人、人与机器、机器与机器的关系。上一次类似的技术变革还是上个世纪 90 年代末，互联网走向普通大众的时代。
正如互联网时代网络增进了人与人之间的联系，释放出了巨大的生产力。在 AIGC 的时代，计算机的能力得到了极大的增强，人与机器、机器与机器之间的协作构成了新的工具杠杆。加之开源软件的广泛应用使得个体、小团队重新获得了竞争优势，在 AIGC 的时代又出现了小团队拥有巨量用户的示例。
如果说二十五年前的互联网革命个体进入门槛是编程的能力，AIGC 时代则在编程能力之外还增加了对熟练开发或应用 AI 的能力。
转型 AI 的数学门槛
提起程序员转型到 AI，很多人的直觉是：搞 AI 啊，那数学得好吧，从高等数学、集合论、概率论、测度论、线性代数、泛函分析、凸优化整起。对于非数学专业和多数工科背景的人这个要求足以劝退。
但是在实践中，除了做 AI 编译器、优化器搞模型训练，绝大多数工作并不需要这些数学知识。以 Resnet 为例，设计这一网络架构只需要信息论的相关的知识就足够了，正如我们开汽车并不需要了解如何最优化发动机、电动机的工况。
我在二十年前开始学习统计自然语言处理时，也面临今天想转型到 AI 的同学一样的情况。当时全文检索系统风头正劲，准确的中文切分器能够让检索系统在构建索引的速度、索引大小与检索质量上获得一个较好的平衡。当时的主流是隐式马尔科夫的切分方案，基于 CRF 的字标注方法刚刚提出。CRF 方法的优化器采用拟牛顿法需要计算 Hessian 矩阵的近似，这个近似会占用大量内存我从工程上优化了其物理内存占用，但是完成这个工作并不需要了解拟牛顿法的数学细节，而提升 CRF 方法分词器的效果需要引入更多、更全面的特征，这一工作也不需要特别高深的数学知识。
定量的理性认知固然很好，但是很多场景下，宏观的感性认知已经足以指导我们日常的决策。
从分词算法的研究我们可以发现，引入当前数据集无关的外部领域知识可以提升系统的综合性能（f-score），但是如何更好的构造关联到字的特征向量成为新的问题。基于神经网络的语言模型可以将稀疏高维的特性向量压缩到稠密低维的特征向量，并进而 Word2vec 发现可以对计算出的词向量执行语义计算，而 GPT、BERT 等预训练大语言模型更是把英文单词都切分成了多个 token，交由神经网络本身在前 8 层 Transformer Block 进行还原。要完成这些工作，仍然不需要特别高深的数学知识，依赖的是巧妙的任务设计和对概率论的初步了解。
由于预训练语言模型非常消耗算力，以微软 UniLM 为例，24 层的模型在 2019 年已经需要 8 卡 V100 并行计算近一个月。因此，在 2019 年 Google 提出了 T5 模型，虽然较现在的 LLM 能力稍弱，但是提出了可以基于前缀文本区分任务，进而在统一的框架内对语言模型进行预训练。例如当进行翻译任务时在需要处理的文本前面附加 translate English to German:，当需要进行文本情感分析时附加 sentiment:。类似的思路表现为现在的大语言模型普遍都有 SFT 或指令对齐阶段。OpenAI 发现可以借助 Prefix 或者这里我们称它为 Prompt，可以激发模型未被设计、训练的新的能力。
到 ChatGPT 为代表的大语言模型出现，传统意义上 NLP 的所有问题都得到解决，日常大量的文本处理类的工作可以无脑的使用大语言模型。但是，拥有了堪称强大的自然语言处理工具的现下，我们要解决的现实问题远没有得到解决，这甚至不是结束的开始，充其量只是开始的结束。
以最新的论文《Top in Chinese Data Processing: English Code Models》为例，其提出对于特定的中文应用（eg. RAG，检索增强生成）语言模型中受限的中文知识反而有助于降低幻觉。这种现象的真实原因仍有待进一步研究，但是现有的部分中文大语言模型其 Tokenizer 部分是存在缺陷的，简单讲，中文历史上存在单字成词的传统，理论上在 Tokenizer 中除了单字和成语，不应该出现常见字的两字组合，更进一步的，如果字出现的频率不高，单字也可以不出现。
考虑到现实的算力限制，并不是每个程序员都有机会从头训练大语言模型，但是我们仍然需要对大语言模型的工作原理以及其工作方式的可能解释进行研究，因为创新往往需要通过观察事物并深入了解其原理后才能产生。
开发者面临的挑战与应对
在程序员的视角看，大语言模型的出现给程序开发带来了下面若干新问题，以下是针对这些问题的技术分析与建议：
1. 应用是否应该引入大语言模型？
并非所有场景都需要 LLM。如果任务规则明确、确定性高且对延迟敏感，传统规则引擎或轻量级模型可能更优。LLM 适用于模糊意图理解、内容生成、复杂推理等场景。决策时需权衡成本、延迟与准确率。
2. API 接入还是本地推理？
API 接入适合快速验证、资源受限或无需数据隐私的场景。本地推理适合数据敏感、高并发低延迟需求或定制化模型部署。需评估显存容量、推理加速库（如 vLLM, TensorRT-LLM）及硬件成本。
3. 大语言模型的局限在哪里？
包括上下文窗口限制、幻觉问题（Hallucination）、逻辑推理能力波动、知识截止时间等。设计系统时需通过外部知识库（RAG）补充事实，通过多步校验减少错误。
