今天是我从金融支付Spring后端转向LLM应用开发的第一天，学习了吴恩达《Generative AI for Everyone》的前两节课，特意避开了容易混淆的老版传统机器学习课程，只聚焦生成式大模型的基础逻辑，先建立全局认知，不深入数学推导。
核心学习要点
一、传统监督式AI vs 生成式AI：搞懂"监督"到底指什么
很多人刚接触都会疑惑"监督学习"名字的由来，这里的"监督"和上线后"输入A输出B"的响应式交互无关，它描述的是训练阶段的数据形态：
- 传统监督式AI：训练时必须提供「输入 + 人工标注的标准答案」，相当于有老师在旁监督批改，模型通过对比标准答案修正误差，输出多是固定分类、识别结果（比如情绪正负判断、语音转文字）。
- 生成式大模型（基座预训练阶段）：采用自监督学习，不需要人工逐条标注答案，直接投喂海量原始文本，模型自主从上下文里学习语言规律，通过"给定前文预测下一个token"的方式训练，最终能生成全新的开放式内容。
二、LLM的本质：不是"创造"，是"预测续写"
大语言模型并不是凭空生成内容，它的核心逻辑是基于海量语料学习到的语言规律，拿到一段前缀文本，就顺着逻辑预测下一个最合理的token，逐词拼接成完整内容。 它的输出不一定100%准确，但可以用来做文本续写、内容提纲、头脑风暴，帮我们拓展思路、提高信息整理效率。
三、基座模型、微调模型、API服务模式：三者区别与选型
这是企业落地最实用的一个知识点，三者定位和成本完全不同：
- 基座模型（Base Model）：原始预训练完成的基础大模型，通用语言能力强，但没有经过指令对齐，不会针对性回答问题，也不贴合特定业务场景，训练成本极高。
- 微调模型（Fine-tuned Model）：在基座模型基础上，用领域专属数据做二次训练，让模型适配特定行业场景（比如金融、医疗），效果更精准，但需要投入标注数据、算力和时间成本。
- API服务模式：厂商把训练好的基座/微调模型封装成HTTP接口对外提供服务，使用者只需要调用接口，不用关心模型训练、算力部署、运维维护。
结合我所在的金融支付行业，优先选择API服务模式是最务实的落地路径：不用投入高额的训练和部署成本，也不用承担模型运维的复杂度，只需要聚焦在业务系统集成、数据脱敏、权限管控、合规审计这些后端工程师擅长的事情上。
开放式思考问题
- 结合你所在的行业，比如金融、支付这类强合规场景，生成式AI最先能落地的小功能是什么？
- 自监督学习和传统监督学习的成本差异，会怎么影响中小企业的大模型选型？