1. 项目背景与核心问题
去年春节前，我团队接到一个有趣的需求：为某社交平台开发智能祝福语生成功能。产品经理的原话是"要让用户感觉每句祝福都像量身定制的"。我们最初尝试用传统NLP模板生成，结果用户反馈"像群发的拜年短信"——这正是大多数祝福场景的痛点。
问题的本质在于：模板生成的祝福语缺乏个性化关联。当用户输入"给程序员同事的新年祝福"时，系统只会机械组合"新年快乐"+"代码无bug"这类固定搭配。这种"词库拼贴"方式既无法理解接收者的特质，也不能结合具体场景（如年终总结会 vs 团建活动）。
2. 技术方案选型
2.1 为什么选择RAG架构
传统方案存在三个致命缺陷：
- 模板库扩展成本高：新增100种职业就需要人工编写数万条模板
- 上下文感知弱：无法结合"去年一起加班赶项目"这类具体记忆
- 表达同质化：相同输入永远输出相同祝福语
我们最终采用RAG（检索增强生成）架构，核心优势在于：
- 动态检索：从向量库匹配最相关的祝福语素材
- 生成控制：用检索结果约束LLM的输出方向
- 冷启动友好：即使没有用户历史数据，也能基于基础向量库生成合理结果
2.2 系统架构设计
整套系统分为三个核心模块：
mermaid复制graph TD
A[用户输入] --> B[向量检索模块]
B --> C[LLM生成模块]
C --> D[情感增强模块]
（注：实际开发中我们使用Milvus向量库+GPT-3.5 Turbo，情感增强模块采用自定义的prompt engineering策略）
3. 关键实现细节
3.1 向量库构建的陷阱
初期我们直接使用公开祝福语数据集构建向量库，结果出现典型问题：
- 语义稀释："前程似锦"在毕业、升职、新年等场景都被检索到
- 特征冲突："早日脱单"同时出现在情人节和光棍节语料中
解决方案是采用场景维度隔离：
- 建立多级标签体系（节日类型/关系类型/场合正式度）
- 使用sentence-transformer生成向量时，将标签信息作为前缀：
python复制# 错误做法 text_embedding = model.encode("心想事成") # 正确做法 text_embedding = model.encode("春节_同事_非正式::心想事成")
3.2 检索策略优化
单纯靠余弦相似度检索会导致结果呆板。我们引入混合检索策略：
- 基础检索：Top 5相似度结果
- 多样性采样：从Top 20随机选取1条风格差异大的
- 冷启动保护：当相似度<0.3时启用备选模板库
实测发现加入10%的"意外性"结果（如给程序员的祝福里混入一条极客笑话）能显著提升"走心"感知。
4. 效果验证与反思
4.1 量化指标对比
| 方案类型 | 点击率 | 收藏率 | 平均字数 |
|---|---|---|---|
| 模板生成 | 12.3% | 1.2% | 28.5 |
| 纯LLM生成 | 18.7% | 3.5% | 52.1 |
| RAG方案 | 34.5% | 8.9% | 41.3 |
4.2 用户真实反馈
一位产品运营的留言很有代表性："系统建议的'愿你的PRD少改18版'确实让我会心一笑，比'工作顺利'生动多了"。这种场景具象化的能力正是RAG的价值所在。
5. 实践建议
- 不要过度依赖向量检索：当用户输入"给妈妈的生日祝福"时，简单直接的"妈妈生日快乐"可能比检索出的华丽辞藻更打动人
- 建立反馈闭环：收集用户实际发送的祝福语持续优化向量库
- 控制生成长度：超过60字的祝福语在移动端展示效果急剧下降
这个项目的核心收获是：技术能让祝福更"聪明"，但真正的"走心"需要设计合理的场景理解机制。现在当系统建议"祝你和猫咪一起通过ISO27001认证"时，我们就知道向量库该清理了。