照片书标题怎么写？这家公司用AI解决了

你手机里有多少张照片？几千张？几万张？真正印成书的不到1%。剩下的99%卡在第一步：想不出标题。

Popsa是一家做照片书的公司，覆盖50多个国家、12种语言。他们发现一个反直觉的事实——用户不是不想印照片，而是被"起名字"这件事难住了。2021年他们上线标题建议功能，2024年用生成式AI彻底重做。结果：2025年生成550万个个性化标题，用户满意度和购买率双升。

这背后不是简单的"AI替代人工"，而是一场关于自动化边界的辩论：算法规则 vs 生成式AI，谁更适合解决创意辅助问题？

正方：规则算法足够好用

Popsa最初的方案叫"标题建议图谱"（Title Suggestion Graph），纯规则驱动。

系统读取照片元数据——时间戳、地理坐标——加上设备端卷积神经网络提取的视觉特征（海滩、烧烤、宠物等）。然后按模板匹配：如果所有照片同一天拍摄，推荐"这一天"配具体日期。

这套方案的优势很明显：

• 确定性：输出可控，不会出现离谱建议

• 低成本：本地运行，不依赖云端大模型

• 速度快：毫秒级响应，用户体验流畅

• 多语言：规则模板翻译即可，12语言同步覆盖

Popsa的核心哲学是"技术替用户做重活"。规则算法完美契合——用户选完照片，5分钟内拿到设计精美的书，标题不用动脑。

但问题在2024年暴露：用户确实用了标题建议，但印出来的书，封面写着"法国2024""西班牙照片"甚至简单粗暴的"照片"。

功能在跑，情感没到位。

反方：生成式AI才能激发创意

2024年6月，Popsa团队重新框定问题：不是要"更快生成标题"，而是要"激发用户灵感"。

这改变了技术选型。他们引入Amazon Bedrock统一接口，接入三类模型：

• Anthropic Claude 3 Haiku：轻量快速，成本敏感场景

• Amazon Nova Lite：平衡质量与延迟

• Amazon Nova Pro：高质量创意输出

新架构的核心是检索增强生成（检索增强生成，RAG）。系统不凭空造句，而是结合三类输入：

1. 结构化元数据：时间、地点、照片数量

2. 视觉特征标签：CNN识别的场景元素

3. 品牌语料库：Popsa积累的历史优质标题

生成式AI的优势在于组合创新。规则算法只能匹配预设模板，RAG可以从品牌语料中检索相似案例，再用大模型重新组合，输出"夏日普罗旺斯的薰衣草香气"而非"法国2024"。

但代价同样真实：

• 成本上升：每次调用都有推理费用

• 延迟增加：云端往返 vs 本地毫秒

• 质量波动：需要大量提示工程（提示工程）约束输出

• 多语言复杂度：12语言的语料对齐和风格统一

Popsa的解法是分层路由：简单场景用轻量模型，复杂创意需求上Pro，通过Bedrock统一调度平衡成本与体验。

我的判断：自动化不是非此即彼，而是分层协作

这场辩论的真正价值，在于重新定义"自动化"的颗粒度。

Popsa没有扔掉规则算法，而是把它变成生成式AI的输入层。CNN视觉识别、元数据提取这些"老技术"仍在设备端运行，负责结构化信息；创意组合交给云端大模型，负责情感化表达。

这种分层有几个启示：

第一，边缘计算+云端智能是务实路径

不是所有任务都值得上云。Popsa把特征提取留在本地，既保护隐私（照片不上传），又降低延迟。只有需要"创意"的环节才调用大模型，成本可控。

第二，RAG是品牌安全的关键

纯生成式AI容易"幻觉"出不符合品牌调性的标题。Popsa用历史优质标题做检索库，相当于给AI上了紧箍咒——创意可以新，但不能偏。

第三，多语言不是翻译问题，是文化问题

12语言同步上线，意味着语料库需要按文化语境分类。同一组海滩照片，英语用户可能接受"Sunset Vibes"，日语用户更适合"夏の思い出"。RAG架构允许按语言检索对应语料，而非简单机翻。

第四，用户反馈闭环决定迭代速度

550万个标题生成不是终点，是数据资产。哪些标题被用户采纳、哪些被手动修改、最终购买率如何——这些反馈持续优化检索库和模型选择策略。

技术选型的底层逻辑

Popsa的案例戳中一个普遍困境：生成式AI时代，产品团队容易陷入"模型崇拜"——凡事问"能不能用大模型解决"，而非"这个问题本质需要什么"。

标题建议的本质是有限创意空间的搜索问题，不是开放式生成。用户不需要莎士比亚，需要"比'法国2024'好一点"的选项。RAG+分层模型的架构，恰好卡在"足够好"和"足够便宜"的甜蜜点。

对比纯规则方案，新系统提升了创意质量；对比纯生成方案，又控制了成本和风险。这种"混合智能"可能是未来多数AI产品的标配。

对科技从业者的行动建议

如果你正在考虑用生成式AI改造现有功能，可以复制Popsa的决策框架：

1. 重框定问题：从"更快/更便宜"转向"用户真正要什么"——Popsa发现用户缺的不是速度，是灵感

2. 拆解任务链条：哪些环节必须创意（上云端），哪些可以确定性解决（留本地）

3. 构建私有语料：RAG的效果取决于检索库质量，历史数据是护城河

4. 设计分层路由：用统一接口（如Bedrock）调度多模型，按场景动态选择

5. 埋点验证假设：用户采纳率、购买转化率、手动修改率——用数据说话而非体感

照片书是个小众赛道，但Popsa的解法有通用性。任何需要"辅助用户表达"的场景——邮件主题、社交文案、商品描述——都面临类似权衡：规则太死板，生成太不可控，混合架构可能是中间道路。

下一步，你可以检视自己产品的"标题建议时刻"：用户在哪个环节卡住？现有方案是规则还是生成？数据资产有没有被充分利用？

答案不需要颠覆式重构，有时候只是给老算法接一个新接口。