在做祝福生成这类应用时，几乎所有团队都会自然走到同一个想法： **“既然模型写祝福不够好，那我多给它一些‘好祝福’参考，不就行了吗？”** 于是你开始做这些事：收集公众号、朋友圈、公司模板里的祝福语按风格分类：商务、轻松、传统、科技梗全部入向量库，准备 RAG检索几条最像的，让模型“参考着写” 从工程视角看，这条路非常顺。但从结果来看，往往会出现一种非常奇怪的现象：输出变长了辞藻更多了句式更“像祝

在做祝福生成、感谢、道歉这类“关系型表达”的 RAG 系统时，很多工程师都会有一个非常自然的直觉： “既然关系重要，那我就把关系写得更完整一点。” 于是你会看到这样的数据设计：一整段项目合作经历一整次旅行的完整叙述几百字的关系背景说明 然后统一切成一个 chunk，入库，embedding，检索。 但上线之后，效果却很奇怪：祝福变长了语气更正式了细节更多，但反而不走心模型开始说一些“看似用心，实际

“祝福语生成”这种场景，一旦你做过一版微调（比如「码上拜年」），很快就会有人问下一句： “既然我们有大量祝福语样本，那要不要上 RAG？用向量数据库检索几条相似的，再让模型改写一下，会不会更稳？” 这句话听起来很对，甚至非常工程化：有数据 → 入库 → 检索 → 生成，闭环就有了。 但祝福这件事偏偏很刁钻：它不是知识问答，不是事实查证，更不是“召回越多越好”。它靠的是“分寸”“关系”“语气”，靠的

在很多团队里，微调往往被当成一种“技术升级路径”： 先 Prompt不行就 RAG再不行就微调 但如果你做过几个真实项目，很快就会意识到一个问题： **微调并不是“最后一招”，而是一种对任务性质的判断结果。** 有些问题，即便你已经花了大量精力调 Prompt、搭 RAG，最后还是会隐约感觉到一句话： “它好像不是靠堆技巧能解决的。” 春节祝福生成，就是这样一个非常典型的场景。 这篇文章要做的，就

几乎所有祝福类应用，在跑通第一个版本之后，都会遇到一个非常现实的问题： “既然能写拜年祝福，那能不能顺便写感谢信？再顺便加个道歉模板？” 从产品角度看，这个需求非常合理。从工程角度看，这却是一个危险的拐点。 因为你正在从：单一表达目标走向多种情绪、不同语气、不同风险等级的表达任务 而你要做出的第一个技术选择是： **是继续微调一个模型，还是为每一种表达拆模型？** 这篇文章，就是围绕这个问题展开的

在大模型项目里，评估往往被认为是一个“技术收尾”的环节：跑几个指标对比一下 loss看看示例输出 但一旦你进入创意生成类任务，比如春节祝福、文案创作、风格写作，这套方法几乎立刻失效。 因为你会发现：loss 在降，但输出没变好BLEU 在升，但读起来更像模板指标很好，但用户说“没感觉” 于是问题变成了： **“走心”这种东西，到底能不能被评估？如果能，该怎么评？** 「码上拜年」这个祝福 AI 的

在过去一年里，几乎所有团队在遇到生成效果问题时，都会下意识问一句： “是不是该加个 RAG？” RAG 已经成为一种工程直觉：只要模型答得不好，就怀疑是“没看到资料”。 但春节祝福这个场景非常残酷地揭示了一件事： **有些问题，模型不是“不知道”，而是“知道了也不该这么说”。** 这正是微调和 RAG 分道扬镳的地方。 这篇文章，不是要否定 RAG，而是借「码上拜年」这个案例，认真回答一个工程问题

 如果你只是把“春节祝福 AI”当成一个节日小工具，这个案例确实显得有点轻。但如果你从微调落地的角度看，它反而非常典型，甚至可以说是“教科书级”的。 因为它几乎完美符合以下条件：模型能力是足够的，但体验明显不对问题不在“会不会”，而在“像不像人”用户感知高度敏感，但很难用指标量化用 Prompt 能凑合，用 RAG 几乎无解 而这类场景，正是大多数团队在真实业务中反复遇到、却迟迟不敢微调的原因： 

说句实话，我第一次接触向量数据库的时候，根本没想过要自己搭一套。 原因也很现实：市面上已经有不少成熟产品文档、SDK、Demo 一应俱全看起来直接用现成的就好 所以一开始我的想法非常简单： 我只需要一个“能做语义检索的东西”，至于它内部怎么跑的，说实话并不关心。 直到后来在项目里遇到几个非常具体的问题：检索结果为什么会抖为什么同样的数据，换个参数效果差这么多数据量一上来，延迟突然失控 那时候我才意

如果你已经看过 PPO 的原理文章，大概率会有一种感觉： “逻辑我好像懂了，但真让我跑一次，我还是不知道从哪开始。” 这是完全正常的。 因为 PPO 实战，和你熟悉的 SFT / LoRA 微调，几乎是两种完全不同的工程体验。 在 SFT 里，你面对的是：固定数据固定标签固定 loss一条清晰的训练曲线 但在 PPO 里，你面对的是：动态生成的数据不稳定的 reward多个 loss 共同作用行为

如果你认真回想一下，会发现一个很有意思的现象。 第一次用到这些词的时候——第一次上 LoRA第一次跑 PPO第一次把 RAG 接进来第一次听说 DPO 它们几乎都真的帮过你。LoRA 让你显存不炸RAG 让模型突然“知道很多事”PPO / DPO 让模型行为“看起来更对齐” 但问题在于：这些词第二次、第三次、第四次出现时，往往已经不是在帮你了。 它们开始被用在一种非常危险的语境里： “是不是该上一

在很多隐私事故复盘里，经常能听到一句话： “模型后来突然开始输出用户相关信息。” 但如果你真正把训练过程、数据演化、评估日志一段段翻回去看，你几乎一定会发现： 它一点都不突然。 模型“记住用户信息”，往往不是某一轮训练造成的，而是经历了一个非常稳定、非常可复现的阶段演化过程。 而真正危险的地方在于：每一个阶段，看起来都“合理”没有明显的红线没有人会当场喊停 直到某一天，输出“越界了”。 这篇文章要

在很多团队内部讨论中，这个问题经常被问出来： “我们只是做了业务微调，不会把 base model 的安全对齐搞坏吧？” 这个问题听起来很合理，但它隐藏了一个更深层、也更危险的误解： 把安全对齐，当成一种“独立存在、不会被影响的能力”。 现实情况是： **安全对齐不是一层外壳，而是和模型整体行为分布纠缠在一起的。** 所以问题从来不是：会不会削弱 而是：**在什么阶段以什么方式削弱到什么程度削弱的

在很多事故复盘里，经常会出现一句话： “模型已经做过 PPO / DPO 了，按理说应该更安全。” 这句话本身没有恶意，但它隐藏了一个极其危险的假设： 安全是一个“单调递增”的属性。 也就是说，只要你做了对齐训练：风险就会下降边界就会更稳行为就会更可控 但真实工程世界里，事情往往是反过来的。 你会看到一些非常反直觉的现象：明显违规内容确实少了明确拒答更自然了但某些灰区输出反而更稳定、更自信 于是问

在向量检索项目里，常见的抱怨包括：“这个 embedding 好像不太行”“换个模型试试？”“是不是 TopK 太小了？” 但有一个问题，经常被直接跳过： **我们到底是在一个什么样的“空间”里，定义什么叫“相似”？** 向量检索的整个系统，其实建立在两个非常底层、但经常被默认的选择之上：向量维度距离函数 而这两个选择，一旦定下： **你就已经决定了：哪些东西更容易被找出来，哪些东西会被系统性忽略

如果你回顾一个 RAG 项目的演化过程，往往会发现一条非常一致的路径：初期： “模型老说不知道，肯定是文档没召回全。” 中期： “那就把 TopK 开大一点。” 后期： “再多加点文档，总有一个能用。” 在这个过程中，有一个隐含假设始终没有被质疑过： **“模型看到的信息越多，答案就会越可靠。”** 但只要你把系统跑到真实业务规模，这个假设几乎一定会崩。 于是你会看到一些非常诡异的现象：模型不再说

在 RAG 项目里，切分方式通常是最早被确定的部分之一：文档进来切一切建向量后面再慢慢调 而且在当时，这个选择往往显得并不重要： “反正后面还有 embedding、TopK、rerank、模型兜底。” 但你只要做过一两个完整项目，就会慢慢意识到一件事： **切分方式不是一个“前处理细节”，而是整个系统如何理解世界的第一步。** 尤其是在 语义切分 和 结构切分 之间，它们的差异，远远不只是“切得

在很多 RAG 项目里，都会经历一个非常相似的阶段：初期：  chunk 切得比较细，模型经常说“信息不足” 中期：  觉得是上下文不够，于是 “我们把 chunk 切大一点吧” 后期：  模型不再说“不知道”了  但开始给出  听起来很完整、但经不起推敲的答案 于是大家开始困惑： “不是信息更多了吗？为什么模型反而开始胡说了？” 这篇文章要讲清楚的，就是这件事。 在展开之前，我先把全文最重要的一

在大模型微调项目里，几乎所有团队都会走到同一个阶段：显存开始吃紧batch size 一减再减sequence length 不敢动然后开始讨论： “要不要换 LoRA / QLoRA？” 但非常诡异的一点是：换了方案显存确实降了一点但OOM 还是会来而且很难解释“为什么这次又不行了” 你会发现，讨论显存时，大家常常在说：“这个方案省显存”“那个方案显存占用低” 但很少有人真正说清楚： **它到底