小红书 AI 产品经理岗面经合集：上下文管理、检索增强与一致性设计

《面试题目》

面经 01 · 小红书AI产品经理岗（2026-05-12）

1. 检索 Agent 中是如何做上下文管理的？
2. 大语言模型的输出是如何进行约束的？
3. AI Coding 题目：不可以直接把题目丢给 AI，要自己先提炼出需求，用 Codex 来做。

面经 02 · 小红书AI产品经理岗（2026-05-08）

4. 请做一下自我介绍
5. 你提到“问题导向”，具体是怎么体现的？
6. PE（产品工程师）和传统后端开发有什么区别？
7. 作为实习生经验不足，如何快速参与业务并给出建设性意见？
8. 你在项目中是如何体现“问题导向”的？
9. 多轮对话效果变差的本质原因是什么？
10. ReAct 能解决上下文问题吗？为什么？
11. 你是怎么做上下文压缩的？
12. 如何保证压缩过程中不丢关键内容？
13. 如何判断哪些是关键内容？
14. 长对话（20~30 轮）怎么处理？
15. 压缩本身会丢信息，你怎么控制？
16. 为什么要用 topK + 元数据过滤？
17. topK 是怎么实现的？（embedding 吗？）
18. 为什么不能只用 embedding？
19. 为什么要结合关键词检索？
20. embedding 相似 ≠ 语义相似，为什么？
21. embedding 为什么会不准确？
22. 如何提高 embedding 检索的准确率？
23. 文本切分（chunk）策略怎么设计？
24. 如果文本特别长（超过 token 限制）怎么办？
25. 有没有了解业界的上下文压缩或检索方案？
26. 你的系统一致性是怎么做的？
27. Redis + MQ 是最终一致性还是强一致性？
28. 秒杀场景可以用最终一致性吗？
29. 你到底实现的是强一致还是最终一致？
30. 如果要实现强一致性，应该怎么做？
31. 多级缓存体系是怎么设计的？
32. 如果没有缓存会有什么问题？
33. 什么是缓存穿透？
34. 手撕：从二叉树中一个结点出发，返回所有路径长度为 target 的路径。vibe coding，一定要用 js 写。

面经 03 · 小红书AI产品经理岗（2026-04-16）

35. 如何理解 AI 全栈工程师？
36. 你认为的 AI 开发是怎么样的？AI 应用的架构和传统应用的架构有什么不同，如果让你来会怎么设计？
37. 你认为链式调用和用 agent markdown 调用的区别是什么，哪个更好？
38. LangChain 和 LangGraph 的区别是什么？
39. 中间件 ES 跟 MySQL 有什么区别？
40. 倒排索引是怎么设计的，怎么检索？
41. ES 怎么分片？
42. MySQL 怎么分库分表？
43. MySQL 有一个查询，设计一万张表，每张表无序，让你在每张表都查询排序后前 100 条数据，这个查询很慢／超出内存，要怎么设计避免？
44. Java 语言和 Python 语言，哪个在 AI 开发上更爽，为什么？
45. RPC 框架有用过吗？OpenFeign 和 gRPC 有什么区别，底层如何实现服务和客户端通信？用到的序列化协议是什么？
46. Java 中实现 Serializable 接口有什么用，这个空接口怎么做到的运行时识别？

面经 04 · 小红书AI产品经理岗（2026-03-25）

47. 再详细讲一下你的核心项目，说明项目的核心价值和行业意义
48. 你所在的项目团队架构是怎样的？你在其中如何发挥协同作用？
49. 目前 AI 内容生态行业的发展现状如何？存在哪些机遇和挑战？
50. 小红书做独立 AI 功能（而非嵌入现有流程）的意义是什么？与行业内其他产品的差异性在哪？
51. 做 AI 产品时，为什么选择自研模型／对接第三方模型，而不使用竞品的成熟方案？
52. 小红书 AI 功能的打分体系（如内容生成质量、搜索精准度）是如何建设的？核心维度有哪些？

《参考解析》

上下文管理：压缩、选择与外部记忆

多轮对话效果变差，本质是四件事叠加：一是注意力被稀释，关键约束埋在前几轮的长文本里，模型对中段信息的召回明显下降；二是上下文污染，中间轮次里模型自己给出的错误结论会被当成事实继续引用；三是目标漂移，用户换了话题但旧的指令仍在生效；四是 token 成本与延迟随轮次线性上涨，工程上开始被迫截断。回答时把这四条摆出来，比只说“上下文太长”高一个层次。

ReAct 不解决上下文问题，它解决的是“模型不知道该查什么”的问题。ReAct 让模型交替输出推理与动作、拿到外部观察结果再继续，代价是每一轮都往上下文里追加思考与工具返回，上下文只会更长。真正的解法是在 ReAct 外面套一层上下文治理：工具返回只留结构化结论不留原始文本、历史轮次做滚动摘要、把稳定不变的信息（人设、格式要求、业务规则）放到系统提示而不是对话历史里。

长对话（20~30 轮）的处理要分层：近几轮保留原文保证连贯，更早的压成摘要，跨越整段会话的稳定事实（用户偏好、已确认的结论、未完成的待办）抽成结构化的状态区而不是塞进摘要。这样做的理由是摘要会随轮次二次失真，而状态区是逐轮被覆盖更新的，属于“外部记忆”。

上下文压缩：丢什么、留什么要说得出判据

压缩不能靠模型自由发挥，要先定义“不可丢”的清单：任务目标与验收标准、硬约束与禁忌、已经确认的结论与数字、未完成的待办与指代对象、用户的显式偏好。压缩的产物最好是结构化字段加少量原文引用，而不是一段新的散文——散文会引入第二次表述误差，而且无法被程序校验。

控制信息损失有几种实用手段：保留原始问句的引用（关键处带原文片段，供后续核对）、按轮次分两级摘要（轮次级摘要 + 会话级摘要，需要时能回钻）、压缩后做一次回读校验（让模型回答“当前任务目标是什么、还有哪些没做完”，答错就回退到未压缩版本）。被追问“怎么判断哪些是关键内容”时，可以给一个可操作的判据：删掉这句话之后，后续某一步的决策会不会改变；会改变的就必须留。

检索链路：topK、元数据过滤与混合检索

topK 指向量检索返回的候选条数，它其实是“召回率与噪声”的旋钮：太小会漏掉正确片段，太大会把无关内容塞进提示词、反而干扰生成。元数据过滤是把范围先缩小（时间、品类、权限、地域、版本），过滤放在向量检索之前还是之后是关键取舍：前置过滤能显著减少计算量与误召回，但如果过滤条件本身把正确片段排除掉就无解；后置过滤更安全但浪费算力。工程上的常见做法是先用结构化条件粗筛，再在子集里做向量召回。

不能只用 embedding 的原因很实在：向量模型对专有名词、型号、编号、缩写、精确数值不敏感，而这些恰恰是业务查询里最需要命中的；同时近似最近邻本身有召回损失，域外语义还会漂移。所以要配一路关键词或倒排检索（BM25），两路结果用 RRF 之类的分数融合或加权合并，再上一个交叉编码器做精排。这套“召回宽、精排严”的结构，比单纯调 topK 有效得多。

embedding 相似不等于语义相似，怎么补救

“退款”和“退货”、“苹果手机”和“苹果公司”在向量空间里可能很近，因为对比学习优化的目标是“整体语义相近”，而不是“在具体业务上可以互换”。长文本被压成一个定长向量时信息会坍缩，否定词（“不支持”与“支持”）和多义词也容易被抹平；训练语料与业务语料分布不一致时，模型的相似度排序会整体偏掉。

补救手段按性价比排：一是混合检索加精排，把判断从“向量距离”交回给能看全句的交叉编码器；二是查询改写与假设性答案生成（把用户问题扩写成一段更接近文档语料的文本再检索）；三是用元数据与业务标签做强约束，让不该互通的类别在检索阶段就隔开；四是要求生成结果引用原文片段，把“检索错了”暴露在答案里而不是被模型圆过去。判断检索做得好不好，别只看 topK 命中，要看端到端指标：答案正确率、引用准确率、以及人工抽检的坏例分布。

缓存与一致性：先给结论，再给边界

多级缓存分三层：进程内本地缓存（如 Caffeine，纳秒级但容量小、多实例不一致）、分布式缓存（Redis，毫秒级、共享但要走网络）、数据库兜底。设计要点是每层都有自己的过期策略与回源逻辑，热点 key 用互斥重建防击穿，过期时间加随机抖动防雪崩。缓存穿透是查询一个数据库里根本不存在的 key，每次请求都打到库上，解法是缓存空值（设短过期）或用布隆过滤器在入口挡掉。没有缓存的后果不只是慢：数据库连接被打满，故障会从单点扩散到全站。

Redis + MQ 的默认答案是最终一致性：缓存与数据库通过消息异步对齐，中间有窗口，靠重试、幂等和对账收敛。秒杀场景通常也用最终一致，因为强一致要以串行化和吞吐为代价；它的正确性靠“预扣库存 + 消息落库 + 幂等 + 事后对账”这一整套，而不是靠锁把所有操作串起来。真要做强一致，可选路径是数据库事务加行锁、分布式锁串行化临界区、或干脆让缓存在决策链路上不参与读写（缓存只服务展示）。面试官反复追问“你到底实现的是哪一种”，要的就是一句明确结论加成立条件，切忌用“基本一致”“准强一致”这类模糊说法糊过去。

AI 应用架构与工程杂项

链式调用和 Agent 调用的区别在确定性：链式是把流程写死（每一步的输入输出、失败分支都预先确定），可观测、可测试、成本可控，适合流程稳定的业务；Agent 由模型决定下一步调什么工具，灵活但不确定、贵、难评测，适合分支多、事先写不全的任务。实际系统里主流做法是“主流程链式 + 局部 Agent”，而不是全交给 Agent。AI 应用与传统应用架构的差别也要说清：输出是非确定性的，所以必须有离线评测集与线上质量监控；提示词是一等配置，要版本化；上下文与 token 是成本项，要核算。

ES 与 MySQL 的差异按“索引结构决定适用场景”讲：ES 用倒排索引，擅长全文检索、相关性排序和聚合分析，但不擅长事务与频繁更新；MySQL 用 B+ 树，擅长按主键／索引做点查与范围扫描，保证事务与一致性。所以常见架构是 MySQL 存权威数据、ES 做检索副本。倒排索引是“词项 → 文档列表”的映射，另存词频与位置用于打分和高亮；ES 分片在索引创建时定死，主分片数不可改（只能 reindex），副本可调，分片过多会有小文件与查询扇出问题。

“一万张无序表各取排序后前 100 条”考的是别把一万次全表扫描串起来：正确思路是让每张表自身有序（建索引或改聚簇／物化视图），再用并行查询加多路归并（堆）取全局前 100，或者干脆在写入侧预聚合出排行榜。RPC 那题要顺带说清序列化：OpenFeign 是声明式 HTTP 客户端、走文本协议（JSON），调试友好但开销大；gRPC 基于 HTTP/2 与 Protobuf，二进制、多路复用、支持流式，性能更好但可读性差、浏览器支持要额外代理。Serializable 是标记接口，运行时判断靠类元数据而不是接口方法——序列化框架会解析类的结构并计算 serialVersionUID，反序列化时比对版本，不一致就报错。

手撕题：二叉树中的定长路径

先跟面试官对齐题意，这道题的“从一个结点出发”有两种解释。若要求路径只能向下（从某结点到它的后代），用 DFS 回溯加前缀和：遍历时维护从根到当前结点的前缀和，用哈希表记录每个前缀和出现的次数，当前前缀和减去 target 在表里出现几次，就有几条以当前结点结尾的合法路径，整体 O(n)。若不要求从根出发、且允许路径“拐弯”（两个结点之间的任意路径），就得在每个结点上做一次向下搜索，最坏 O(n²)；此时要主动说明复杂度并给出优化方向（按深度分组、只在同深度集上匹配），而不是硬写一个指数级解法。用 JS 写时注意递归深度和返回值结构（返回路径数组还是只计数），写完手动跑一个三结点的小例子验证边界。