题库中心

大语言模型（LLM）是一个通过海量文本数据训练出来的 AI 系统，它的核心能力是"理解语言模式并生成文本"。你可以把它想象成一个读过几乎所有互联网文本的"超级阅读者"，它不是在背诵原文，而是学会了语言的统计规律，从而能够"预测下一个最合理的词"，最终生成连贯的回答。

与搜索引擎的本质区别：

维度	大语言模型	搜索引擎
工作方式	基于概率生成内容	基于索引检索已有内容
输出形式	直接给出回答/结论	提供链接列表
信息来源	训练时学到的"记忆"	实时检索互联网
时效性	知识有截止日期	可以获取最新信息
创造性	能组合、生成新内容	只能返回已有内容
出错方式	可能"幻觉"出虚假信息	可能返回过时或无关结果

举例说明： 用户问"2024年诺贝尔物理学奖得主是谁？"——搜索引擎可以返回最新报道，而大语言模型可能给出错误答案（因为训练数据有截止日期），但如果问"请用比喻解释什么是量子纠缠"，LLM 可以生成一个生动易懂的解释，搜索引擎则只能返回已有的文章链接。

Transformer 是 2017 年 Google 提出的一种神经网络架构，它是当今几乎所有大语言模型（GPT、Claude、PaLM 等）的底层基础。

核心机制（通俗理解）：

• 注意力机制（Attention）： 模型在理解一句话时，会自动判断哪些词之间关系最密切。比如"苹果发布了新手机"，模型知道"苹果"指的是公司而不是水果，因为它"注意到"了"发布""手机"这些上下文。
• 并行处理： 相比之前的模型，Transformer 可以同时处理整个句子，而不是逐词处理，这大幅提升了效率和效果。

产品经理为什么需要知道：

1. 理解技术边界： Transformer 架构决定了模型有上下文长度限制（context window），这直接影响产品设计——比如不能让用户提供无限长的文本让模型处理。

2. 理解能力来源： 模型的"涌现能力"（emergent abilities）来源于 Transformer 在大规模训练时的特性，产品经理需要知道某些能力在模型足够大时才会出现。

3. 理解迭代逻辑： 从 GPT-3 到 GPT-4，核心改进之一就是 Transformer 架构的优化，产品经理需要理解为什么模型升级能带来能力提升。

产品经理不需要知道的：

• 具体的数学公式
• 训练细节（如梯度下降）
• 硬件实现细节

Token 是大语言模型处理文本的最小单位。它不完全等于"字"或"词"，而是一种介于两者之间的分词单位。

Token 的实际样例：

• 英文中，"hello" 是 1 个 token，"artificial" 可能被拆成 "art" + "ific" + "ial" 共 3 个 token
• 中文中，一个汉字通常是 1 个 token，但常见词组可能是 1 个 token
• 标点符号、空格也占 token

对产品设计的实际影响：

1. 成本控制： 大多数 LLM API 按 token 计费。如果你的产品让用户输入长文档，成本会显著增加。产品设计时需要考虑：

   • 是否需要限制输入长度？
   • 是否需要预处理（如先用轻量模型提取关键信息）？

2. 上下文窗口管理： 模型有最大 token 限制（如 4K、8K、128K）。如果对话太长，需要设计"记忆截断"策略——保留最近 N 轮对话，或对历史对话做摘要。

3. 响应时间： token 越多，生成时间越长。对于实时对话场景，需要控制每次交互的 token 数量。

4. 多语言支持： 中文比英文消耗更多 token（因为中文的分词效率较低），这会影响多语言产品的成本和体验。

举例： 一个 AI 客服产品，如果用户粘贴了一篇 5000 字的产品说明书，这大约消耗 3000-4000 token。按 GPT-4 的价格计算，单次查询成本可能达到几毛钱。产品经理需要决定：是直接处理全文，还是先用摘要模型压缩到 500 token 再处理。

模型幻觉是指大语言模型生成了看似流畅、合理，但实际上是错误、虚构或无中生有的内容。模型"自信地胡说八道"是幻觉的核心特征。

幻觉的典型表现：

• 编造不存在的论文、引用、数据
• 虚构历史事件或人物
• 给出看似专业但实际错误的医疗/法律建议
• 用错误数据进行计算

具体业务场景——医疗健康类产品：

假设一家公司做了一个"AI 健康咨询助手"，用户输入症状后 AI 给出建议。如果模型产生幻觉：

• 场景： 用户说"我最近头痛、视力模糊"，AI 回答"这可能是视神经脊髓炎的早期症状，建议您做 MRI 检查"——但实际上这个诊断是模型"编"出来的，用户真正的症状可能只是用眼过度。
• 风险： 用户可能因此产生不必要的恐慌，或者去做昂贵且不必要的检查。更严重的情况，如果模型"漏诊"了真正危险的疾病，可能危及生命。
• 法律风险： 公司可能面临医疗事故相关的法律诉讼。

应对策略：

1. 产品层面： 添加醒目的免责声明，明确告知"AI 建议仅供参考，不构成医疗诊断"
2. 技术层面： 结合 RAG（检索增强生成）技术，让模型基于权威医学数据库回答
3. 流程层面： 关键场景设置人工审核环节
4. 数据层面： 建立幻觉检测机制，对高风险回答自动标记

上下文窗口是指大语言模型在一次交互中能"看到"和"记住"的最大文本量（以 token 计）。你可以把它想象成模型的"短期记忆容量"。

具体数字参考：

• GPT-3.5: 4K token（约 3000 个中文字）
• GPT-4: 8K / 32K / 128K token
• Claude 3: 200K token

对产品设计的关键影响：

1. 对话类产品：

• 当对话超过上下文窗口时，模型会"忘记"早期内容
• 产品需要设计记忆管理策略：是截断早期对话，还是用摘要替代？

2. 文档处理类产品：

• 长文档可能超出上下文窗口
• 解决方案：分段处理、滑动窗口、先摘要再分析

3. 多轮交互设计：

• 每次 API 调用需要把历史对话作为上下文发送
• 对话越长，每次调用成本越高、响应越慢
• 需要设计合理的"历史保留策略"

4. RAG 场景：

• 检索到的参考资料也占上下文窗口
• 需要在"参考资料丰富度"和"留给回答的空间"之间取平衡

产品设计建议：

• 为用户提供"新对话"入口，避免上下文过长
• 设计对话摘要功能，让用户快速回顾
• 在后端实现智能的上下文裁剪策略

传统软件产品的开发流程是确定性的——需求明确后，开发出来的产品行为是可预测的。AI 产品的开发流程则带有概率性——即使模型训练完成，输出结果也不完全可控。

核心差异对比：

维度	传统软件产品	AI 产品
需求定义	精确的功能需求	模糊的效果需求
开发方式	编写规则	训练/微调模型
测试方式	用例测试	效果评估（准确率等）
质量标准	0 bug	接受一定错误率
迭代方式	代码更新	数据+模型迭代
上线风险	可预测	可能出现意外行为

对产品经理的实际影响：

1. 需求定义阶段：

• 传统产品："按钮点击后跳转到 A 页面"——精确无歧义
• AI 产品："智能分类准确率达到 90%"——需要和团队对齐"90%"是怎么定义的、用什么数据测的

2. 测试阶段：

• 传统产品：写测试用例，通过即通过
• AI 产品：需要准备评估数据集，跑多次取平均值，看边界 case 的表现

3. 上线后：

• 传统产品：不改代码，行为就不变
• AI 产品：输入分布变化可能导致模型效果下降（数据漂移），需要持续监控

4. 迭代方式：

• 传统产品：产品经理提需求 → 开发改 → 测试 → 上线
• AI 产品：收集数据 → 标注 → 训练/微调 → 评估 → 灰度上线 → 监控效果

数据驱动思维是指在产品决策中，以数据作为核心依据而非依赖直觉或经验。它不是"看数据做决策"这么简单，而是一套完整的方法论：定义指标 → 收集数据 → 分析洞察 → 行动 → 验证效果。

与"直觉驱动"的本质区别：

维度	直觉驱动	数据驱动
决策依据	"我觉得用户会喜欢"	"数据显示 70% 用户使用了这个功能"
评估方式	主观感受	量化指标
说服力	依赖个人权威	数据说话
可复现性	因人而异	方法可复制

在 AI 产品中的具体应用：

场景1：模型优化方向决策

• 团队有两个优化方向：提升准确率 vs 降低延迟
• 数据驱动做法：A/B 测试，看哪个指标对用户满意度影响更大
• 结果：数据显示准确率从 85% 提升到 90% 只带来 3% 满意度提升，但延迟从 2s 降到 0.5s 带来 15% 满意度提升 → 优先优化延迟

场景2：功能优先级排序

• 数据驱动做法：分析用户行为数据，找出最高频的失败场景，优先解决
• 而不是"老板说做哪个就做哪个"

场景3：AI 输出质量监控

• 不是等用户投诉才发现问题
• 而是建立自动化的质量监控仪表盘，实时追踪幻觉率、拒答率、用户纠正率等指标

数据驱动的关键原则：

• 先定义"成功"是什么样子，再开始做
• 用对比实验（A/B test）验证因果关系，而非仅看相关性
• 关注"不说话的用户"——沉默的数据往往比反馈更有价值

Prompt Engineering 是设计和优化输入提示词，以引导大语言模型产生更好输出的技术。它不需要写代码，但需要理解模型的"思维模式"。

基本原则：

1. 清晰具体： 模糊的指令导致模糊的输出

• 差："写一篇文章"
• 好："写一篇 800 字的面向非技术人员的 AI 科普文章，语气轻松，用生活中的例子说明"

2. 提供上下文： 模型不知道你脑子里想什么

• 差："总结一下"
• 好："以下是一篇用户反馈，请总结用户最关心的 3 个问题，并按严重程度排序"

3. 分步拆解： 复杂任务拆成小步骤

• 差："分析这个数据并写报告"
• 好："第一步：识别数据中的异常值；第二步：分析异常原因；第三步：用三句话总结发现"

4. 给出示例（Few-shot）： 用例子告诉模型你想要什么格式和风格

• 提供 1-2 个输入输出的示例，模型会模仿这个模式

5. 角色设定： 给模型一个身份有助于它聚焦

• "你是一位资深的金融分析师，请从风险角度评估以下投资方案"

产品经理需要掌握的程度：

• 必须掌握： 能写出清晰的 prompt、能评估 prompt 输出质量、能和工程师沟通 prompt 设计
• 加分项： 能做简单的 prompt 调优实验、理解 few-shot、chain-of-thought 等技巧
• 不需要： 写复杂的系统 prompt、理解 token 化和采样参数的底层实现

传统软件的行为是确定性的——用户点击按钮，一定跳转到某个页面。AI 产品则不同，输出带有不确定性，用户无法提前知道结果会是什么。这种不确定性带来了信任问题，而"透明度"和"用户控制感"正是解决信任问题的两大支柱。

透明度为什么重要：

1. 建立信任： 当用户知道这是 AI 生成的、基于哪些信息生成的，他们更容易接受结果。反之，如果 AI 悄悄给出建议而用户不知道来源，一旦出错，信任会彻底崩塌。

2. 降低风险： 告知用户"AI 可能出错"，用户会自己做判断。比如 AI 翻译工具标注"由 AI 翻译，请以专业翻译为准"，用户在重要文件场景会自行复核。

3. 符合法规： 欧盟 AI Act 要求 AI 系统必须告知用户正在与 AI 交互。中国《生成式人工智能服务管理暂行办法》也有类似要求。

用户控制感为什么重要：

1. 减少焦虑： 当用户知道可以"重新生成"、"编辑 AI 输出"、"关闭 AI 功能"时，他们更愿意尝试。

2. 提升满意度： 给用户"创意度"滑块、"温度"调节等控制选项，不同偏好的用户都能找到舒适的使用方式。

3. 容错设计： AI 出错时，用户需要能方便地修正——"重新生成"、"上一个版本"、"手动编辑"等功能必不可少。

设计实践举例：

• ChatGPT：显示"AI 生成内容可能不准确"，每次回答都有重新生成按钮
• Notion AI：AI 写完后，用户可以直接编辑，且可以看到 AI 的修改建议
• GitHub Copilot：代码建议以灰色虚线显示，用户按 Tab 接受或继续打字拒绝

这两个概念都描述了大语言模型在"不额外训练"的情况下完成新任务的能力，区别在于是否提供示例。

Zero-shot Learning（零样本）：

• 直接给模型任务描述，不提供任何示例
• 示例："请将以下句子分类为正面或负面：'这家餐厅的菜品非常美味'" → 模型直接回答"正面"
• 适用场景：任务简单明确、模型能力足够时

Few-shot Learning（少样本）：

• 在 prompt 中提供 1-5 个示例，模型从中学习任务模式
• 示例：

  请将句子分类为正面或负面：
  - "服务态度很差" → 负面
  - "物超所值" → 正面
  - "等了两小时才上菜" → 负面
  - "这家餐厅的菜品非常美味" → ?
  

• 适用场景：任务有特殊要求、需要特定输出格式、分类标准不常见时

产品经理需要使用的场景：

1. 产品原型验证： 在开发 AI 功能前，用 few-shot prompt 快速验证技术可行性。比如做一个邮件分类功能，先用 few-shot prompt 测试分类效果，再决定是否值得投入开发模型。

2. 定义输出格式： 通过示例告诉模型你期望的输出结构。比如要求 AI 客服按照"问题分类 → 优先级 → 建议回复"的格式输出。

3. 质量标准对齐： 通过提供"好答案"和"差答案"的示例，让团队（和模型）对齐质量标准。

4. 快速迭代： 不需要等模型训练，修改 prompt 中的示例就能改变模型行为，这在产品探索期特别有价值。

Fine-tuning（微调）是在一个已有的大语言模型基础上，用特定领域的数据进一步训练，使模型在特定任务上表现更好。通俗来说，就是让一个"通才"变成某个领域的"专家"。

微调 vs Prompt Engineering：

维度	Prompt Engineering	Fine-tuning
成本	几乎为零	需要数据标注+训练成本
时间	分钟级	天到周级
效果上限	受限于模型基础能力	可以显著提升特定任务效果
灵活性	高，改 prompt 即可	低，需要重新训练
数据需求	不需要额外数据	需要几百到几万条标注数据

产品经理应该建议微调的场景：

1. Prompt Engineering 到达瓶颈： 用 prompt 调优后效果仍不满足要求，且业务确实需要更好的效果。

2. 特定领域需求： 比如法律文书生成、医学报告摘要等领域，通用模型的专业性不够。

3. 输出格式高度标准化： 每次都需要严格的固定格式输出，用微调比每次写复杂 prompt 更稳定。

4. 降低推理成本： 微调后可以用更小的模型达到原来大模型的效果，降低 API 调用成本。

不应该微调的情况：

• 效果要求不高的通用场景
• 数据量不够（少于 100 条）
• 需求还在快速变化
• Prompt Engineering 还没充分尝试

"温度"是大语言模型的一个生成参数，控制输出的"随机性"或"创造性"。它不是一个产品术语，但理解它对 AI 产品设计非常有价值。

通俗理解：

• 温度 = 0：模型每次都选择概率最高的词，输出最"保守"、最"确定"。适合事实性问答。
• 温度 = 0.7：模型有一定随机性，输出更"自然"、更"多样"。适合对话场景。
• 温度 = 1.0+：模型非常"发散"，可能出现创意内容，也可能出现不连贯的内容。适合创意写作。

对产品体验的具体影响：

1. 客服/问答类产品：

• 推荐温度 0-0.3
• 原因：用户需要准确、一致的答案，不希望同一个问题每次得到不同回答
• 如果温度太高，用户会觉得"AI 不靠谱"

2. 创意写作/营销文案类产品：

• 推荐温度 0.7-1.0
• 原因：用户需要多样化的创意选项，太保守的输出没有价值
• 可以提供多个不同温度的输出让用户选择

3. 编程辅助类产品：

• 推荐温度 0-0.2
• 原因：代码需要精确，高温度可能产生语法错误

产品设计建议：

• 不要把温度参数直接暴露给普通用户（大多数人不理解）
• 用场景化的选项替代，如"保守/均衡/创意"三档
• 或者根据场景自动调整，用户无感知

RAG（Retrieval-Augmented Generation，检索增强生成）是一种将"信息检索"与"文本生成"结合的技术架构。它让大语言模型在回答问题之前，先从外部知识库中检索相关信息，然后基于检索到的内容生成回答。

工作流程（通俗版）：

1. 用户提问："我们公司的退款政策是什么？"
2. 系统从企业知识库中检索最相关的文档片段
3. 将检索到的内容和用户问题一起发送给 LLM
4. LLM 基于检索结果生成回答，而非依赖自身"记忆"

RAG 解决的核心问题：

1. 知识时效性问题：

• LLM 的训练数据有截止日期
• RAG 可以接入实时更新的知识库，回答最新的信息
• 例：电商平台的商品信息每天都在变，RAG 可以确保回答基于最新的商品数据

2. 幻觉问题：

• LLM 可能"编造"不存在的信息
• RAG 让模型"有据可依"，大幅减少幻觉
• 关键：可以标注信息来源，用户可以验证

3. 私域知识问题：

• LLM 不了解企业内部信息
• RAG 可以接入企业文档、知识库、数据库
• 例：内部 IT 帮助台，RAG 可以基于内部文档回答员工问题

4. 可控性问题：

• RAG 可以控制模型"基于哪些信息"回答
• 便于合规审查——可以看到模型参考了哪些来源

对产品经理的实际价值：

• 降低模型训练成本（不需要为每个领域微调）
• 更快上线（接入知识库即可，不需要等模型训练）
• 更容易维护（更新知识库比重新训练模型简单得多）
• 更好的用户体验（回答有出处，用户更信任）

核心原则： AI 处理标准化、高频、简单的问题；人工处理复杂、敏感、高价值的问题。关键是设计平滑的"交接"机制。

分层处理架构：

第一层：AI 自主处理（目标覆盖 70-80% 的常见问题）

• FAQ 类问题（退换货政策、营业时间等）
• 简单的查询类（订单状态、物流信息）
• 标准化操作（修改地址、取消订单）
• 设计要点：响应速度快、准确率高、回答有出处

第二层：AI + 人工审核

• AI 生成回复草稿，人工确认后发送
• 适用场景：涉及金额较大的投诉、敏感话题
• 设计要点：审核效率要高（3-5 秒内完成），否则用户等待时间过长

第三层：人工主导，AI 辅助

• 人工客服处理，AI 提供实时建议（知识库检索、相似案例推荐）
• 适用场景：复杂的技术问题、情感安抚
• 设计要点：AI 辅助信息要精准、不干扰人工判断

转人工的触发机制设计：

自动转人工的条件：

• 用户连续 2 次表达不满（情绪检测）
• AI 连续 2 次无法理解用户意图
• 涉及退款金额超过阈值（如 500 元）
• 用户主动要求转人工
• 涉及法律、安全等高风险话题

交接时的信息传递：

• 把完整对话历史传给人工客服
• AI 生成问题摘要，帮助人工快速了解上下文
• 标注 AI 已尝试的解决方案，避免重复

关键体验指标：

• AI 自主解决率（越高越好，降低人工成本）
• 用户满意度（AI 和人工分别追踪）
• 平均处理时间（从用户提问到问题解决）
• 转人工率（过高说明 AI 能力不足，过低可能说明转人工门槛太高）

核心挑战： 用户对 AI 的期望往往在两个极端之间摆动——要么过度期待（认为 AI 无所不能），要么过度恐惧（完全不信任 AI）。这两种极端都会损害产品体验。

具体挑战分析：

挑战1：AI 能力的"不均匀性"

• AI 在某些场景表现出色，在另一些场景表现很差
• 用户不理解"为什么有时候很聪明，有时候很傻"
• 例：ChatGPT 能写出优美的诗歌，但可能算错 15×23 = ？（实际上现在大多数 LLM 已能正确计算简单乘法，但复杂数学仍可能出错）

挑战2：AI 行为的不可预测性

• 同样的输入，不同时间可能得到不同输出
• 用户无法像使用传统工具那样"确定"AI 会怎么做
• 例：AI 写邮件功能，同样的提示词，每次生成的邮件内容都不同

挑战3：技术进步带来的期望膨胀

• 媒体对 AI 的过度宣传抬高了用户期望
• "AI 将取代人类工作"的叙事让用户期望过高
• 产品实际能力与用户期望之间的 gap 越来越大

解决方案：

1. 在产品层面管理期望：

• 使用前：明确告知 AI 的能力范围和限制
• 使用中：对不确定的回答添加置信度标识（如"根据已有信息，可能的答案是..."）
• 使用后：提供反馈渠道，让用户报告 AI 的错误

2. 渐进式引导：

• 新用户引导中展示 AI 擅长的场景，而非展示"最强"的 demo
• 让用户先从简单任务开始，逐步了解 AI 能力边界
• 例：Notion AI 先让用户用 AI 做简单的"总结"和"改写"，再引导尝试更复杂的功能

3. 设计"降级体验"：

• AI 无法完成时，优雅地降级到人工或工具辅助
• 例：AI 客服无法回答时，自动转人工，且告知用户"这个问题需要专业客服处理"

4. 持续沟通 AI 的进步：

• 通过更新日志、公告等方式，让用户知道产品在持续改进
• 但要避免过度承诺未实现的功能

AI 产品的评估需要兼顾"AI 技术效果"和"用户体验价值"两个维度，缺一不可。

以"AI 写作助手"为例的评估体系：

第一层：技术效果指标（AI 团队负责）

指标	定义	目标值
内容准确性	生成内容无事实错误的比例	> 95%
风格一致性	输出与用户指定风格的匹配度	> 85%
响应时间	从输入到输出的延迟	< 3 秒
拒答率	无法完成请求的比例	< 5%

第二层：产品体验指标（产品团队负责）

指标	定义	目标值
采纳率	用户使用 AI 生成内容的比例	> 60%
编辑率	用户对 AI 输出的修改比例	< 30%
重新生成率	用户点击"重新生成"的比例	< 20%
功能使用率	使用 AI 功能的用户占比	> 40%
留存影响	使用 AI 功能用户的留存率 vs 未使用用户	显著正向

第三层：业务价值指标（商业团队负责）

指标	定义	目标值
付费转化	免费用户转为付费用户的比例	> 5%
ARPU	每付费用户平均收入	按业务定
NPS	净推荐值	> 40

评估方法设计：

1. 自动化评估：

• 建立标准测试集（包含不同类型的写作任务）
• 每次模型更新后自动跑测试集，对比基线效果
• 监控线上数据，设置异常告警

2. 人工评估：

• 每周随机抽样 100 条 AI 输出，由人工评分
• 评分维度：准确性、有用性、自然度、安全性
• 建立评分标准和校准机制

3. 用户反馈评估：

• 在 AI 输出旁边添加"有用/无用"反馈按钮
• 收集用户的编辑行为数据（编辑了什么、编辑了多少）
• 定期做用户调研，了解深度使用体验

关键原则：

• 指标要"可行动"——每个指标都要有明确的优化方向
• 建立"基线"——任何指标都需要对比基线才有意义
• 避免"指标陷阱"——不要优化单一指标而忽略整体体验

数据标注是给原始数据（文本、图片、语音等）打上"标签"的过程，这些标注好的数据用来训练或评估 AI 模型。

常见的标注任务：

• 文本分类：给一段文字标注"正面/负面/中性"情感
• 命名实体识别：在文本中标记人名、地名、组织名
• 对话意图标注：给用户输入标注"查询订单/投诉/咨询"等意图
• 质量评估：给 AI 的回答打分（1-5分）

产品经理在数据标注项目中的关键关注点：

1. 标注规范定义（最重要）：

• 产品经理需要和团队一起制定"标注指南"
• 指南必须清晰、无歧义、有大量示例
• 例："投诉"和"建议"的边界是什么？"很不满意"和"不满意"的区别是什么？
• 标注指南的质量直接决定模型效果

2. 标注质量控制：

• 设置"黄金标准"（已知正确答案的样本），检测标注员的准确率
• 同一条数据让多人标注，计算一致性（Kappa 系数）
• 定期抽检，发现问题及时纠正
• 目标：标注一致性 > 85%

3. 成本与效率平衡：

• 标注成本通常按条计费（0.1-5元/条，取决于复杂度）
• 需要评估：标注多少数据量足够？是否可以用主动学习减少标注量？
• 优先标注"模型最不确定的样本"，而非随机标注

4. 数据隐私与合规：

• 标注数据是否包含用户隐私信息？
• 标注团队是否有保密协议？
• 标注数据的存储和使用是否合规？

常见踩坑：

• 标注指南定义模糊 → 标注质量差 → 模型效果差
• 只关注标注数量，忽略质量
• 没有做标注一致性检查，导致噪声数据混入训练集

冷启动问题在 AI 产品中有两层含义：一是"没有用户数据，模型无法个性化"；二是"没有训练数据，模型无法开始工作"。

场景一：个性化推荐的冷启动

用户刚使用产品，没有历史行为数据，AI 无法做个性化推荐。

解决方案：

• 基于内容的推荐： 根据用户注册时填写的信息（行业、职位、兴趣）推荐相关内容
• 热门推荐： 先展示全局热门内容，等用户有了行为数据再切换到个性化
• 引导式收集： 新用户引导流程中，让用户选择 3-5 个感兴趣的话题
• 跨域迁移： 如果用户在其他产品有数据（如已登录微信），可以利用已有画像

场景二：新 AI 功能的冷启动

AI 功能刚上线，没有用户交互数据，无法评估效果和持续优化。

解决方案：

• 利用公开数据集： 用开源数据集做初步训练和评估
• 内部试用（Dogfooding）： 先让公司内部员工使用，收集反馈和数据
• 种子用户计划： 邀请 50-100 个目标用户免费试用，换取使用数据和反馈
• 合成数据： 用 LLM 生成训练数据（虽然质量不如真实数据，但可以快速启动）

场景三：新领域的模型冷启动

进入一个新领域（如从通用客服扩展到医疗问诊），模型在该领域缺乏专业知识。

解决方案：

• Few-shot + 领域专家： 用领域专家提供的示例构建 prompt
• 微调： 用领域专家标注的数据微调模型
• RAG： 接入领域知识库，让模型"开卷考试"
• 人机协作： 初期全部由人工处理，AI 辅助，逐步积累数据后让 AI 承担更多

关键原则：

• 不要等"完美数据"才上线，先用可行的方案启动
• 设计好数据回流机制，让产品使用过程中自动积累数据
• 冷启动方案不是永久方案，要有明确的过渡计划

模型评测关注的是"AI 模型本身的技术表现"，由算法团队主导。产品评测关注的是"AI 功能在真实产品中的用户体验和业务价值"，由产品团队主导。

详细对比：

维度	模型评测	产品评测
关注点	模型准确率、F1、延迟	用户满意度、任务完成率
数据来源	标准测试集	真实用户行为数据
评估方式	离线测试、自动评估	A/B测试、用户调研
负责团队	算法工程师	产品经理
核心问题	"模型有多准？"	"用户觉得好用吗？"

为什么需要同时关注：

1. 模型好不代表产品好：

• 模型准确率 95%，但响应时间 10 秒 → 用户不愿等待
• 模型输出正确，但格式不符合用户习惯 → 用户不会用
• 例：翻译模型 BLEU 分数很高，但翻译出来的文字"不自然"，用户仍然不满意

2. 产品好不代表模型好：

• 用户满意度高，可能是因为产品用了巧妙的交互设计规避了模型弱点
• 这种"好的体验"可能不可持续——一旦用户尝试更复杂的场景就会暴露问题
• 例：AI 功能只开放了最简单的几个场景，所以效果很好，但覆盖面太窄

3. 两者需要对齐：

• 如果模型评测说"效果提升了 10%"，但产品评测说"用户满意度没变" → 需要深入分析原因
• 如果用户满意度下降了，但模型指标没变 → 可能是用户期望变化了，或者新用户群体的期望不同

最佳实践：

• 建立"指标对照表"——把模型指标和产品指标放在一起看
• 定期做"指标对齐会议"——算法和产品团队一起看数据
• 在产品层面定义"成功"——技术指标服务于产品目标，而非反过来

数据漂移是指产品上线后，用户输入数据的分布与模型训练时的数据分布发生了变化，导致模型效果下降。

通俗理解： 模型是在"过去的数据"上训练的，但用户的使用模式会随时间变化。当输入数据变了，模型就可能"水土不服"。

典型的数据漂移场景：

1. 季节性漂移：

• 电商客服：双 11 期间的用户咨询类型和平常完全不同
• 如果模型只用平时数据训练，双 11 期间效果会显著下降

2. 趋势性漂移：

• 社交媒体内容分析：网络热词不断变化
• 去年训练的模型可能无法识别今年的新梗、新话题

3. 用户群体变化：

• 产品从一线城市扩展到下沉市场
• 新用户群体的语言习惯、问题类型可能与训练数据不同

4. 外部事件影响：

• 疫情期间，在线教育类产品的用户行为发生剧变
• 新政策出台后，合规问答类产品的知识库需要更新

对 AI 产品的具体影响：

• 模型准确率下降
• 用户投诉增加
• AI 功能使用率下降
• 严重时可能导致业务损失

应对策略：

1. 监控机制：

• 建立输入数据分布监控仪表盘
• 设置分布偏移告警（如 KL 散度超过阈值时报警）
• 定期对比线上数据与训练数据的分布差异

2. 持续更新：

• 定期用新数据更新模型（增量训练）
• 对于 RAG 产品，定期更新知识库
• 建立数据回流机制，持续收集用户交互数据

3. 产品层面的容错：

• 设计降级方案——模型效果下降时自动切换到规则引擎
• 保持人工兜底通道畅通