Ai产品经理面试-基础概念题

考察对 AI 技术的理解深度——不要求会实现,但要求能讲清原理、边界和产品含义。​

RAG 和微调有什么区别? 什么场景该用哪个?​

难度:⭐⭐ （入门必备） 出现频率: 极高（几乎是 AI PM 面试的"必考题"）​

考察点​

•

是否理解两种技术的本质差异(外挂知识 vs 改变模型本身)​

•

能否从产品视角(成本、时效、可维护性)做技术选型,而不是只背概念​

参考答案​

​

💤

一句话对比:RAG 是给模型"外挂一个可随时更新的资料库"，微调是"把知识和行为模式写进模型本身"。​

​

​

#JEcTTCGxIzPx text { white-space: pre; }#JEcTTCGxIzPx .fb0 { stroke: var(--N900-FG, 0.15); }#JEcTTCGxIzPx .fb0 {stroke: rgba(31,35,41, 0.15)}#JEcTTCGxIzPx .fx0 { stroke-miterlimit: 10; }#JEcTTCGxIzPx .fx0 {stroke-miterlimit: 10}#JEcTTCGxIzPx .fa1 { fill: rgb(187, 191, 196); }#JEcTTCGxIzPx .fa1 {fill: rgb(187, 191, 196)}#JEcTTCGxIzPx .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#JEcTTCGxIzPx .fx1 {font-style: normal}#JEcTTCGxIzPx .fx2 { text-anchor: middle; }#JEcTTCGxIzPx .fx2 {text-anchor: middle}#JEcTTCGxIzPx .fx3 { dominant-baseline: central; }#JEcTTCGxIzPx .fx3 {dominant-baseline: central}#JEcTTCGxIzPx .fx4 { stroke: none; }#JEcTTCGxIzPx .fx4 {stroke: none}#JEcTTCGxIzPx .fc0 { fill: var(--text-caption); }#JEcTTCGxIzPx .fc0 {fill: #646a73}#JEcTTCGxIzPx .fa2 { fill: var(--text-link-disabled); }#JEcTTCGxIzPx .fa2 {fill: rgb(187, 191, 196)}#JEcTTCGxIzPx .fa3 { fill: rgb(225, 234, 255); }#JEcTTCGxIzPx .fa3 {fill: rgb(225, 234, 255)}#JEcTTCGxIzPx .fx5 { font: 700 16px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#JEcTTCGxIzPx .fx5 {font-style: normal}#JEcTTCGxIzPx .fx6 { text-anchor: start; }#JEcTTCGxIzPx .fx6 {text-anchor: start}#JEcTTCGxIzPx .fx7 { dominant-baseline: alphabetic; }#JEcTTCGxIzPx .fx7 {dominant-baseline: alphabetic}#JEcTTCGxIzPx .fc1 { fill: rgb(31, 35, 40); }#JEcTTCGxIzPx .fc1 {fill: rgb(31, 35, 40)}#JEcTTCGxIzPx .fx8 { font: 400 16px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#JEcTTCGxIzPx .fx8 {font-style: normal}#JEcTTCGxIzPx .fb1 { fill: var(--N900-FG, 0.15); }#JEcTTCGxIzPx .fb1 {fill: rgba(31,35,41, 0.15)}#JEcTTCGxIzPx .fb2 { fill: rgb(209, 217, 224); }#JEcTTCGxIzPx .fb2 {fill: rgb(209, 217, 224)}#JEcTTCGxIzPx .fa4 { fill: var(--bg-body); }#JEcTTCGxIzPx .fa4 {fill: #fff}ABC123456维度RAG微调本质知识更新可溯源性成本结构擅长解决推理时检索外部知识拼进 Prompt改知识库即可,分钟级生效天然支持引用来源建库 + 每次请求的检索开销知识类问题(知道什么)用领域数据继续训练,改变模型权重需要重新训练,周期长无法溯源,黑盒一次性训练成本 + 数据标注成本行为类问题(怎么说、什么格式、什么风格)

​

选型口诀:​

•

知识频繁更新、需要引用来源、私有文档问答 → RAG​

•

要改变模型的说话风格、输出格式、领域行为习惯 → 微调​

•

两者不互斥:很多产品是"微调过的模型 + RAG"组合​

什么是大模型的幻觉?产品上怎么缓解?​

难度:⭐⭐ （入门必备） 出现频率:极高 （海信、大厂常见题均有出现）​

考察点​

•

能否准确描述幻觉的本质(模型"自信地编造"而非"不知道")​

•

是否理解幻觉是概率生成模型的结构性问题,而非偶发 bug​

•

能否从产品视角给出分层缓解方案,而非只说"优化 Prompt"​

参考答案​

​

💤

一句话定义:幻觉是指大模型生成看似流畅、实则与事实不符或凭空捏造的内容,且往往以高置信度呈现​

为什么会发生:大模型的训练目标是"预测下一个 token",不是"保证事实正确"​

当上下文信息不足或问题超出训练分布时,模型仍会强行补全,产出似是而非的答案。​

​

产品缓解三板斧:​

​

#FZnPrqzOdVhv text { white-space: pre; }#FZnPrqzOdVhv .fb0 { stroke: var(--N900-FG, 0.15); }#FZnPrqzOdVhv .fb0 {stroke: rgba(31,35,41, 0.15)}#FZnPrqzOdVhv .fx0 { stroke-miterlimit: 10; }#FZnPrqzOdVhv .fx0 {stroke-miterlimit: 10}#FZnPrqzOdVhv .fa1 { fill: rgb(187, 191, 196); }#FZnPrqzOdVhv .fa1 {fill: rgb(187, 191, 196)}#FZnPrqzOdVhv .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#FZnPrqzOdVhv .fx1 {font-style: normal}#FZnPrqzOdVhv .fx2 { text-anchor: middle; }#FZnPrqzOdVhv .fx2 {text-anchor: middle}#FZnPrqzOdVhv .fx3 { dominant-baseline: central; }#FZnPrqzOdVhv .fx3 {dominant-baseline: central}#FZnPrqzOdVhv .fx4 { stroke: none; }#FZnPrqzOdVhv .fx4 {stroke: none}#FZnPrqzOdVhv .fc0 { fill: var(--text-caption); }#FZnPrqzOdVhv .fc0 {fill: #646a73}#FZnPrqzOdVhv .fa2 { fill: var(--text-link-disabled); }#FZnPrqzOdVhv .fa2 {fill: rgb(187, 191, 196)}#FZnPrqzOdVhv .fa3 { fill: rgb(217, 243, 253); }#FZnPrqzOdVhv .fa3 {fill: rgb(217, 243, 253)}#FZnPrqzOdVhv .fx5 { font: 700 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#FZnPrqzOdVhv .fx5 {font-style: normal}#FZnPrqzOdVhv .fx6 { text-anchor: start; }#FZnPrqzOdVhv .fx6 {text-anchor: start}#FZnPrqzOdVhv .fx7 { dominant-baseline: alphabetic; }#FZnPrqzOdVhv .fx7 {dominant-baseline: alphabetic}#FZnPrqzOdVhv .fc1 { fill: rgb(0, 0, 0); }#FZnPrqzOdVhv .fc1 {fill: rgb(0, 0, 0)}#FZnPrqzOdVhv .fx8 { font: 400 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#FZnPrqzOdVhv .fx8 {font-style: normal}#FZnPrqzOdVhv .fb1 { fill: var(--N900-FG, 0.15); }#FZnPrqzOdVhv .fb1 {fill: rgba(31,35,41, 0.15)}#FZnPrqzOdVhv .fb2 { fill: rgb(209, 217, 224); }#FZnPrqzOdVhv .fb2 {fill: rgb(209, 217, 224)}#FZnPrqzOdVhv .fa4 { fill: var(--bg-body); }#FZnPrqzOdVhv .fa4 {fill: #fff}ABC1234层级手段产品含义生成端检索端呈现端Prompt 约束、拒答策略RAG + Rerank引用溯源(Citation)明确"不知道就说不知道",降低强行作答概率用高质量外部知识约束生成,减少凭空编造让用户可核验来源,即使出错也能快速发现

​

选型思路:​

高风险场景(医疗、金融、法律)优先"宁可不答也不乱答";低风险场景(创意写作)可容忍一定随机性。​

缓解幻觉不是消灭幻觉,而是在业务可接受的风险水位下做工程化控制。​

Prompt、RAG、SFT 分别是什么?有什么区别?​

难度:⭐⭐ 入门必备 出现频率:极高,抖音校招、大厂常见题均有出现​

考察点​

•

能否区分三种手段的作用层级(指令层 / 知识层 / 能力层)​

•

是否理解成本、迭代速度和适用场景的差异​

•

能否给出"从轻到重"的技术选型思路​

参考答案​

​

💤

一句话对比:​

Prompt 是"怎么问"​

RAG 是"查什么资料再答"​

SFT 是"把行为模式写进模型"​

​

​

​

选型口诀:​

先用 Prompt 试效果 → 知识不够加 RAG → 风格/行为改不了再考虑 SFT。​

三者可组合,很多产品是"Prompt 工程 + RAG + 微调模型"的叠加方案。​

​

产品视角:面试时重点不是背定义,而是能举例——"客服机器人要回答公司最新政策"用 RAG;"要让模型按固定 JSON 格式输出"先用 Prompt,不行再 SFT。​

预训练、微调、SFT 的区别与应用场景​

难度:⭐⭐ 入门必备 出现频率:极高,大厂常见题、理想面经、抖音校招均有出现​

考察点​

•

能否讲清三者在训练链路中的位置(底座 → 通用对齐 → 领域定制)​

•

是否理解"预训练学知识,微调学行为"的核心差异​

•

能否结合业务场景说明选型,而非只列概念​

参考答案​

​

💤

一句话对比:​

预训练是"读书学通用知识"​

微调是"上岗培训学特定技能"​

SFT 是微调中最常见的"照例题学"方式​

​

​

​

关键区分:​

•

预训练决定模型的"知识上限"和"语言能力",通常由模型厂商完成,产品团队不涉及​

•

微调/SFT 决定模型的"行为模式"——怎么说、什么格式、什么风格​

•

SFT 是微调的主流实现方式,面试中说"微调"时大概率指的就是 SFT​

​

💤

应用场景:​

•

预训练:构建基座,产品侧一般选型而非自研​

•

SFT:客服话术统一、医疗报告格式固定、代码补全风格对齐​

•

与 RAG 的关系:知识类问题优先 RAG,SFT 解决"怎么说"而非"知道什么"​

​

如何构建大模型效果评测体系?​

难度:⭐⭐⭐ 进阶 出现频率:极高,小米(7 道评测题)、百度、理想、蚂蚁面经均重点考察​

考察点​

•

能否区分离线评测和在线评测,并说明各自价值​

•

是否理解"评测不是算法的事,产品要定义什么是好"​

•

能否设计分层指标体系,而非只说"看准确率"​

参考答案​

核心观点:评测体系的核心问题是"谁来定义好"——产品负责定义标准,算法负责量化和优化。​

三层指标体系:​

​

​

离线 vs 在线:​

•

离线评测:用标注好的测试集跑分,迭代快、可复现,适合模型选型和能力对比​

•

在线评测:A/B 测试、用户反馈(点赞/点踩)、人工抽检,反映真实场景效果​

构建步骤:​

明确核心场景和用户目标(解决什么问题算"好")​

构建覆盖典型 case 的评测集(含边界 case 和 bad case)​

定义可量化的评测维度(不只看一个准确率)​

建立迭代闭环:评测 → 发现问题 → 优化 → 再评测​

​

💤

PM 的关键贡献:不是写评测代码,而是定义"什么算答对了"——这往往比算法更难,因为业务场景的"好"没有唯一标准。​

​

难度:⭐⭐ 入门必备 出现频率:高 JD 押题、大厂常见题均有出现​

AI 产品中如何平衡准确性与响应速度?​

考察点​

•

能否识别准确性和延迟之间的结构性张力​

•

是否理解不同场景对两者的容忍度差异​

•

能否给出产品层面的权衡策略,而非只说"都要"​

参考答案​

​

💤

核心矛盾:​

提升准确性往往意味着更多计算(更大模型、更多检索、多轮推理),而用户等待耐心有限​

两者不是简单的此消彼长,而是需要在场景层面做取舍​

​

场景分级策略:​

​

​

产品权衡手段:​

分层响应:先快速返回简要回答,后台继续深度检索后补充​

场景路由:简单问题走轻量链路,复杂问题走完整链路​

用户预期管理:展示"正在深度分析..."等状态,降低等待焦虑​

缓存策略:高频问题预生成答案,牺牲一定时效换速度​

​

💤

回答框架:先问"这个场景的用户愿意等多久",再问"答错的代价有多大",在两个约束下找最优平衡点。​

​

什么是 Agent?它和 Chatbot 的区别是什么?​

难度:⭐⭐ 入门必备 出现频率:极高,字节多轮面经、小红书 prep 帖、大厂常见题均有出现​

考察点​

•

能否准确描述 Agent 的核心特征(感知、规划、行动)​

•

是否理解 Chatbot 是 Agent 的子集或简化形态​

•

能否从产品视角判断何时需要 Agent,何时 Chatbot 就够​

参考答案​

​

💤

一句话对比:​

Chatbot 是"能聊天的机器人"​

Agent 是"能自主完成任务的智能体"​

​

​

​

Agent 的关键组成:​

规划(Planning):把复杂目标拆解为可执行步骤​

工具调用(Tool Use):调用外部 API、数据库、搜索引擎等​

记忆(Memory):跨步骤保持上下文和中间结果​

反思(Reflection):检查执行结果,必要时调整策略​

选型思路:​

•

用户只是"问问题得答案" → Chatbot 足够​

•

用户要"完成一件事"(订机票、写报告、分析数据) → 需要 Agent​

•

很多产品是渐进式演进:从 Chatbot 开始,逐步增加工具调用能力​

LoRA 和全量微调有什么区别?什么场景选哪个?​

难度:⭐⭐ 进阶 出现频率:高,抖音校招面经出现​

考察点​

•

能否讲清 LoRA 的核心原理(低秩适配,只训练少量参数)​

•

是否理解两者在成本、效果、灵活性上的权衡​

•

能否结合团队资源和业务需求做选型判断​

参考答案​

​

💤

一句话对比:​

全量微调是"重新培训整个员工"​

LoRA 是"只培训关键技能模块"​

​

​

​

选型口诀:​

•

数据量大(万级以上)、任务复杂、追求极致效果 → 全量微调​

•

资源有限、需要快速迭代、多任务并行 → LoRA​

•

大多数产品团队的现实选择 → LoRA,性价比最高​

​

💤

产品视角:PM 不需要会实现 LoRA,但需要知道"团队只有一张 GPU"时 LoRA 是合理选择;"要同时服务 10 个垂直场景"时 LoRA 的多适配器切换是优势。​

​

什么是数据飞轮?对 AI 产品为什么重要?​

难度:⭐⭐ 入门必备 出现频率:高 JD 押题、大厂常见题均有出现​

考察点​

•

能否描述飞轮的闭环逻辑(使用 → 数据 → 优化 → 更好体验 → 更多使用)​

•

是否理解数据飞轮是 AI 产品最核心的竞争壁垒之一​

•

能否结合具体产品举例,而非只背定义​

参考答案​

​

💤

一句话定义​

数据飞轮是指产品使用中持续产生数据,数据用于优化模型/体验,更好的体验吸引更多用户、产生更多数据——形成自我强化的正向循环。​

​

飞轮四步循环:​

​

代码块​

Plain Text

用户使用产品 → 产生行为数据(对话、反馈、标注)​

↓​

数据用于优化(微调、评测集扩充、Prompt 迭代)​

↓​

产品体验提升(更准确、更懂用户)​

↓​

吸引更多用户 → 产生更多数据 → 循环加速​

​

为什么对 AI 产品特别重要:​

•

AI 产品的边际成本递减:数据越多,模型越好,服务成本相对下降​

•

数据壁垒难以复制:竞品可以抄功能,但抄不走你的用户数据​

•

冷启动后的护城河:飞轮转起来后,后来者追赶成本指数级上升​

产品如何设计飞轮:​

埋点采集:用户反馈(点赞/点踩)、对话日志、纠错行为​

闭环机制:bad case 自动进入评测集 → 优化 → 验证 → 上线​

激励机制:让用户愿意贡献数据(如"你的反馈帮助我们改进")​

经典案例:推荐系统(用户点击 → 优化推荐 → 更多点击)、AI 客服(对话数据 → 优化回答 → 更高解决率)。​

如何判断一个业务问题是否适合用 AI 解决?​

难度:⭐⭐ 入门必备 出现频率:高,JD 押题、美团面经均有出现​

考察点​

•

能否识别 AI 适合和不适合的问题类型​

•

是否理解"AI 不是万能钥匙",有明确的适用边界​

•

能否用结构化框架评估,而非凭感觉判断​

参考答案​

​

💤

核心原则:​

AI 适合解决"模糊、开放、大规模"的问题,不适合"精确、规则明确、小规模"的问题。​

​

四维评估框架:​

​

​

快速判断清单:​

人能不能做?→ 人能做且规则清晰 → 传统规则引擎可能更好​

错了代价多大?→ 代价极高 → 需要人工审核兜底,或暂不适合​

有没有数据?→ 无历史数据 → 先积累数据,或从 RAG/Prompt 轻量起步​

ROI 算不算得过来?→ 人工成本 < AI 成本 → 不值得做​

常见误判:​

•

"有 AI 就能做" → 忽略了数据、成本、风险​

•

"ChatGPT 能答就说明能做" → demo 效果和生产级产品差距巨大​

•

"竞品做了所以我们也做" → 没评估自身场景是否匹配​

AI 产品的黑箱问题如何影响用户信任?产品层面怎么做?​

难度:⭐⭐ 入门必备 出现频率:高,JD 押题出现​

考察点​

•

能否解释"黑箱"的含义(用户不理解 AI 为什么给出这个结果)​

•

是否理解信任缺失对产品留存和采纳的致命影响​

•

能否给出具体的产品设计手段,而非空谈"提高透明度"​

参考答案​

​

💤

黑箱问题:​

​

产品层面缓解策略:​

​

​

对信任的三重打击:​

不可预测:同一问题可能得到不同答案,用户无法建立稳定预期​

不可纠错:出错时用户不知道如何反馈、系统不知道如何改进​

不可问责:出问题后难以定位是模型、数据还是流程的问题​

产品层面缓解策略:​

设计原则:不是让用户"理解模型原理",而是让用户"感到可控"——通过产品设计降低黑箱带来的不确定感。​

追问延伸​

•

追问 1:"Citation 引用溯源能解决黑箱问题吗?" → 部分解决:用户至少能验证知识来源,但生成逻辑仍不透明;是性价比最高的信任建设手段之一。​

•

追问 2:"B 端和 C 端用户对黑箱的容忍度一样吗?" → 不同:B 端更关注可审计、可复现;C 端更关注结果好不好用。B 端需要操作日志,C 端需要简洁可信的呈现。​

•

追问 3:"用户说'不相信 AI 的答案',你怎么提升采纳率?" → 从低风险的辅助功能切入(如"AI 建议,你来决定");用数据证明 AI 建议的准确率;设计"AI 错了轻松纠正"的反馈路径。​

生成式 AI 产品上线前，PM 的合规清单有哪些？​

难度:⭐⭐⭐ 进阶 出现频率:中高，合规岗交叉面、大厂/出海 AI 产品常见​

考察点​

•

能否按「适用性 → 内容与标识 → 备案评估 → 个保与训练数据 → 上线验收与运营」给出可执行框架，而不是背几条口号​

•

是否分清「事实义务 / 产品建议 / 必须升级法务」三类，知道哪些不能由 PM 口头保证​

•

能否主动链到训练数据红线、出海对照等相邻问题，并声明不以第三方读物代替法规原文​

参考答案​

​

💤

一句话：​

上线前合规不是「过一次审就完」，而是先判定自己是不是生成式 AI 服务提供者，再按清单把内容安全、标识、备案/安全评估、个保与投诉通道、对外承诺做成可验收项；​

细节勾选以正课清单为准，法律结论一律交法务。​

​

答题框架（六块，面试口述用）：​

​

​

口述时加三条「加分边界」：​

事实 vs 建议 vs 需法务：能复述公开法规要求的，标事实；产品流程动作标建议；版权归属、备案是否适用、无显式标识特例等标需法务。​

中国包 ≠ 出海包：做完中国内容审核 ≠ 满足 GDPR / EU AI Act；反过来也一样。按市场拆合规包，对照摘要见正课中欧美表——每格以官方出处为准，不背第三方摘要当法条。​

资料层级：答题与过审材料应锚定官方法规/政府公报；选题读物（如行业问答 PDF）只启发结构，禁止把 PDF 条款当法规原文。​

结合场景举例（一句话即可）：面向中国用户的写作/绘图 Bot → 默认按提供者准备协议、内容策略、标识与投诉入口；若用海外模型 API，额外开「出境 + 供应商条款」闸门（见 data-compliance）；若产品有强传播属性，上线前必须拉合规确认是否要安全评估与算法备案。​

追问延伸​

•

追问 1：「调用海外大模型 API，算不算数据出境？我们还要不要当提供者？」 → 面向境内用户提供服务时，产品方通常仍要按提供者准备合规材料；把中国用户数据传到境外部署的 API，需评估出境路径（评估/标准合同/认证等门槛）。细节与厂商「默认是否训练」政策见 data-compliance.md，适用性需法务。​

•

追问 2：「生成内容的版权归用户还是平台？能不能保证商用绝不侵权？」 → 面试正确答法：服务规范要求尊重知识产权，但「纯 AI / 人机协作」权属与侵权分配司法与登记实践仍在发展，需法务；产品侧做预期管理、高风险商用人工复核、协议里 notice-and-takedown，禁止口头保证「绝对不侵权」或「法院已认定版权归本公司」。展开见正课「生成内容版权」节。​

•

追问 3：「中欧美合规差在哪？我们做一套审核全球通用行不行？」 → 不行。中国侧重生成服务专项义务（内容、标识、备案评估等）+ 个保；欧盟是 AI Act 风险分级 + GDPR；美国无同构联邦「生成式 AI 法」，多为行业法/州隐私/执法与自愿框架。用对照表说话，每格引用官方出处，细节链正课，落地顾问意见为准。​

什么是 token?它如何影响产品的成本和体验?​

难度:⭐⭐ 入门必备 出现频率:高,Brave 交叉面经、仓库规划题​

考察点​

•

能否用通俗语言解释 token 是什么​

•

是否理解 token 同时影响成本(按量计费)和体验(上下文长度限制)​

•

能否在产品设计中找到优化 token 使用的方法​

参考答案​

​

💤

一句话定义:​

Token 是大模型处理文本的最小单位,可以理解为"模型眼中的字/词片段"——英文约 4 字符一个 token,中文约 1.5-2 字一个 token​

​

Token 的双重影响:​

​

​

成本优化思路:​

精简 Prompt:去掉冗余指令,用结构化格式替代自然语言啰嗦​

控制输出长度:限制 max_tokens,要求简洁回答​

RAG 精准检索:只塞相关片段进上下文,而非整篇文档​

缓存复用:相同问题复用已有回答,避免重复调用​

模型分级:简单问题用小模型,复杂问题用大模型​

体验优化思路:​

上下文管理:长对话做摘要压缩,保留关键信息​

流式输出:边生成边展示,降低首 token 等待感​

合理预期:告知用户上下文限制,引导拆分复杂问题​

PM 要会算的账:日活 × 人均对话轮次 × 每轮 token 数 × 单价 = 日成本。写 PRD 时应估算 token 消耗,避免功能上线后成本失控。​

追问延伸​

•

追问 1:"接入大模型后成本涨了 10 倍,你怎么降本?" → 分层路由(简单问题用小模型)、缓存高频问答、优化 Prompt 减少无效 token、设置用量上限和熔断机制。​

•

追问 2:"上下文窗口越大越好吗?" → 不一定:窗口大意味着单次成本高、推理慢;"够用就好",配合 RAG 和摘要策略比盲目追求大窗口更实际。​

•

追问 3:"怎么估算一个功能的月均模型成本?" → 预估 DAU × 使用率 × 人均调用次数 × 平均 token 数 × 单价,留出 2-3 倍 buffer 应对波动。​