考察点
这道题出自腾讯 AI 产品经理一面(长上下文/算力方向)。「100 万字」是个技术参数,不是用户需求——面试官想看你有没有这个意识:直接把「支持 100 万字」当成目标去砸资源,是最典型的烧钱姿势。正确的答法是把超长文本拆成具体场景,用便宜的技术方案先验证需求成立,再按验证结果逐级升级投入。这题背后其实是腾讯的务实风格:长上下文的推理成本随长度超线性增长(KV cache 显存占用和注意力计算都在涨),每一级上下文扩展都是真金白银。追问一般往「各阶段的技术方案怎么选」「验证不通过怎么办」「成本账怎么算」走。
参考答案
第零步:先问「谁需要 100 万字,用来干什么」
接需求的第一反应是把「100 万字」翻译成场景。真实存在的长文本场景其实就那么几类:法律/金融行业读整本合同或年报(几十万字量级)、科研读论文合集、网文作者让 AI 读自己的全书改稿、企业把一整个知识库丢进来问答。这些场景有个共同点值得注意:用户要的不是模型「读完了每一个字」,而是「问什么都能找到、答得对」。这个区别决定了第一阶段根本不需要全量长上下文。
所以我会先花一两周做需求验证:找 20-30 个目标用户(律师、研究员、编辑)访谈加场景走查,确认三件事——他们现在的解法是什么(人工读?分段喂给 AI?)、痛点够不够痛(愿意付多少钱或多少时间)、高频问题集中在哪类(问答?摘要?比对?)。这一步产出的是场景优先级清单,不是 PRD。
阶段一:用 RAG + 结构化索引做「场景化长文档问答」
第一阶段不上真长上下文,用检索方案扛:文档切片、建索引,用户提问时检索相关段落再让模型回答,配上原文定位跳转(答案里标出引用自第几页)。这个方案上下文只用几千 token,成本是全文塞入的几十分之一,两周就能出 MVP。
验证节点:找 50-100 个真实用户灰度,盯三个数——问题回答正确率(人工抽评,目标 85% 以上)、「找不到内容」类失败占比(衡量检索召回,超过 15% 说明切片和检索要优化)、周留存(场景真不真,留存说了算)。这一步如果留存起不来,说明场景选错了,项目降级,后面的大投入全部省掉——这就是分阶段的价值。
阶段二:混合方案,把长上下文用在刀刃上
第一阶段跑通后,会暴露出一批检索解决不好的需求:跨章节推理(「对比第三章和第七章的论点」)、全文一致性检查(「合同里前后矛盾的地方」)、整体改写。这类需求天然需要模型看到全局。
第二阶段就上混合架构:默认走检索,识别到全局性问题时才加载全文或大半上下文。同时把上下文窗口按场景分级开放——普通问答 32K,文档级任务 128K,个别头部场景(网文改稿、整本合同审查)试点 256K-1M。这里的关键产品动作是用量和成本的透明化:超长请求耗时和成本都高,要给用户进度预期(「正在通读全文,约需 2 分钟」),内部要按 token 档位监控成本曲线。
验证节点:全局类问题的满足率、超长请求的成本占比(建议设红线,比如不超过总推理成本的 30%)、以及付费意愿测试——超长上下文是天然的高成本功能,大概率要做成付费权益,这阶段就该把价格弹性摸清楚。
阶段三:才轮到「100 万字」本身
前两阶段验证了场景和付费,第三阶段才值得为真·100 万字上下文投入:配合模型团队做长文本能力优化(KV cache 压缩、稀疏注意力这类工程优化是模型侧的事,产品侧要提的是体验需求),并把功能包装成明确的专业版能力。这阶段产品关注的核心是体验兜底:超长请求的排队策略、失败重试、部分结果返回(读到一半超时了,已读部分的结论先给用户)。
贯穿全程的两条纪律
一是每个阶段都有「不往前走」的退出标准,分阶段的本质是买后悔药;二是成本账每个阶段都要重算——长上下文服务的单位经济模型(单用户月成本 vs 付费)如果没转正,再大的技术光环也不该扩量。
可能的追问
- RAG 和真长上下文之争你怎么看,长上下文会不会吃掉 RAG? 答:长期看窗口会越来越大,但「全塞进去」在任何窗口尺寸下都不是最优解——100 万字全塞的成本和延迟,永远比「检索出 5 个相关段落」高一个数量级。所以两者长期共存:长上下文解决「需要全局视野」的问题,RAG 解决「大海捞针」的问题,产品按 query 类型路由。
- 阶段一验证失败,你怎么向坚持要做的领导汇报? 答:带数据去——留存、正确率、替代方案成本对比,同时给替代方向(比如场景没死但方案不对,可以缩小到单一场景重做);不说「做不了」,说「按现在的数据,这条路的投入产出是这样,我建议先验证 X」。
- 超长请求的用户体验怎么兜底? 答:流式输出中间结论、预估时长和进度提示、超时降级为「已读部分的回答+可继续」;绝不让用户对着空白转圈两分钟。