小红书产品工程师一面：一致性、知识来源与多模态评估
本场面试题
- 项目中的一致性与高并发问题，怎样讲清具体场景和处理方式？
- Agent 项目中知识库的来源怎样说明？
- 多模态融合能交给现成组件吗，实现难点在哪里？
- 怎样回答“有没有做过测评”？
面经与参考答法
小红书产品工程师一面：一致性、知识来源与多模态评估
以下短答与教学示例由编辑补充，不代表原作者的现场回答、实际架构或实测结果。
公司为小红书，标题注明商业平台技术、Product Engineer 产品工程师实习一面。正文写 6 月 28 日笔试、7 月 1 日一面，均未给年份；自述面试约一小时。发布日期只表示发布记录的时间。
选录项目一致性场景、知识库来源、多模态融合与难点、测评四组。Redis、消息队列对比和反转字符串单词的算法题已见且保留库存，本页未展开。原文没有提供项目数据模型或测评成绩。
（1）项目中的一致性与高并发问题，怎样讲清具体场景和处理方式？
先说明业务不变量、谁保存权威状态、哪些操作会并发，以及允许多长的旧值窗口，再解释事务、条件更新、幂等与缓存的各自职责。吞吐优化必须保留业务约束；只列出 Redis、锁或消息队列，不能证明一致性。
教学例子：同一资源只能成功占用一次，先在权威数据库用带条件的更新或唯一约束决定胜者，再处理缓存与通知。前端看到稍旧列表和服务端允许重复占用是两种问题，应分别验收。这个资源示例不是原项目模型。
技术核对：Azure：Cache-Aside 的一致性边界。
（2）Agent 项目中知识库的来源怎样说明？
说明资料由谁维护、是否获准使用、版本与更新方式，以及原文怎样解析、切块和进入索引。检索到的片段保留文档与位置，权限变化和过期内容要能失效；模型生成的摘要只作为派生内容，不能替代原始证据。
教学例子：内部产品手册更新后，旧版本 chunk 应失效或明确标出版本，答案引用能回到获准访问的原段落。仅说“从网上抓取后向量化”不能说明资料可信或允许使用。
技术核对：RAG 原始论文：参数与外部记忆结合。
（3）多模态融合能交给现成组件吗，实现难点在哪里？
现成模型和组件可以提供编码、识别或跨模态表示，但应用仍要解决文件格式、坐标或时间对齐、权限、模态冲突及结果验收。先说明任务是检索、理解还是生成，再判断组件覆盖到哪一步；接入一个组件并不自动形成可靠的完整链路。
教学例子：图表问答同时保留原图、OCR 文本与区域位置。OCR 把数字识别错时，即使文本检索命中了相关段落，也应回到原图核验，不能把派生描述当作原始事实。
技术核对：CLIP：图文表示对齐的具体研究实例。
（4）怎样回答“有没有做过测评”？
先如实区分做过的测评与计划，再给出任务样本、数据与系统版本、成功判据、评分方式和失败切片。可确定的格式与状态用程序验收，开放质量用量表和经校准的人工或模型判断；报告延迟、成本与安全约束，不能只给一个总分。
教学例子：一个图文问答用例应同时检查回答是否正确、引用区域是否支持结论；“生成了回答”只证明流程结束。若原项目没有评测，就说明尚缺哪些证据，不能把本文的方案说成已经做过。
技术核对：τ-bench：任务结果与重复执行可靠性。