大模型玩家七七

这是一个被“看起来很合理”的直觉坑住的问题 在做祝福生成这类应用时，几乎所有团队都会自然走到同一个想法：     于是你开始做这些事： 收集公众号、朋友圈、公司模板里的祝福语 按风格分类：商务、轻松、

这是一个非常“反直觉”的工程问题 在做祝福生成、感谢、道歉这类“关系型表达”的 RAG 系统时，很多工程师都会有一个非常自然的直觉：     于是你会看到这样的数据设计： 一整段项目合作经历 一整次旅

这个问题看似小，其实很“工程” “祝福语生成”这种场景，一旦你做过一版微调（比如「码上拜年」），很快就会有人问下一句：   “既然我们有大量祝福语样本，那要不要上 RAG？用向量数据库检索几条相似的，

当“写得不错”，已经不再让人满足 在这样的祝福生成场景中，当你第一次看到微调后的模型输出，通常会有一种很明确的感受：     它不再像模板，不再那么官方， 很多句子甚至可以直接复制发送。   但用着用

微调不是“升级方案”，而是一种判断结果 在很多团队里，微调往往被当成一种“技术升级路径”：     但如果你做过几个真实项目，很快就会意识到一个问题：     有些问题，即便你已经花了大量精力调 Pr

当“祝福 AI”开始被提更多需求时 几乎所有祝福类应用，在跑通第一个版本之后，都会遇到一个非常现实的问题：     从产品角度看，这个需求非常合理。 从工程角度看，这却是一个危险的拐点。   因为你正

这是一个“没有标准答案”的评估问题 在大模型项目里，评估往往被认为是一个“技术收尾”的环节： 跑几个指标 对比一下 loss 看看示例输出   但一旦你进入创意生成类任务，比如春节祝福、文案创作、风格

这不是“用不用 RAG”，而是“RAG 能不能解决这个问题” 在过去一年里，几乎所有团队在遇到生成效果问题时，都会下意识问一句：     RAG 已经成为一种工程直觉： 只要模型答得不好，就怀疑是“没

我一开始真没打算“自己搭一个” 说句实话，我第一次接触向量数据库的时候，根本没想过要自己搭一套。   原因也很现实： 市面上已经有不少成熟产品 文档、SDK、Demo 一应俱全 看起来直接用现成的就好