京东后端一面：会话存储分层、RAG 评测指标与中间件取舍

《面试题目》

1. 技术这个层面，有没有解决过一些难题？可以分享一下。
2. 你刚提到活跃上下文，有些放 MySQL、有些放 Redis，这个持久会话消息你怎么区分的？
3. Redis 应该只是缓存吧？会话结束后会同步回 MySQL？
4. 所以它其实不做模型读取，只是页面展示的时候缓存一下？
5. 你们这个评测集，recall 为什么只到 XX？
6. 从 RAG 知识库整体评测的角度，该看什么指标才算做得好？
7. 你这批题已经知道了，等于开卷考试，那整体回答质量怎么评测？
8. 这些跟整体评测质量是什么关系？
9. 现在大模型工具挺多的，用它写代码有什么心得？
10. 你写了不少 Java 底层和中间件，有印象的分享一两点？
11. 两个中间件都能做同一件事的时候，你一般怎么取舍？
12. 最快什么时候能来实习？
13. 还面过哪些其他公司？
14. 你怎么看待现在这么多新兴行业——机器人、内容平台，还有一些大厂？如果这些都有机会，你怎么选？
15. 反问。

《参考解析》

会话数据放 MySQL 还是 Redis：判断依据是访问模式而不是数据本身重不重要。Redis 适合「高频读写、容忍丢失、有 TTL」的活跃数据——最近几轮对话、会话状态、限流计数；MySQL 适合「需要长期保留、要能查询和审计」的结构化数据——完整消息记录、会话元信息、计费依据。常见架构是「Redis 存热窗口 + MySQL 存全量」，写入时先落 MySQL（保证不丢），再更新 Redis（保证读快）；读取时 Redis 命中就用，未命中回源 MySQL 并回填。要回答清楚降级路径：Redis 挂了会话还能不能继续（回源会慢但可用），以及一致性：两边同时改的时候以哪边为准。

评测集 recall 只到某个值的诊断：先分清是「召回没捞到」还是「标注本身有问题」。排查顺序：构造一批 query 看召回结果人工比对（是漏在检索阶段还是漏在切块阶段）→ 检查切块粒度（相关内容被切碎或跨块断裂）→ 检查是否只用了单路向量检索（专有名词、型号、代码标识符需要稀疏检索补）→ 检查 embedding 是否和领域不匹配（通用模型对垂直术语不敏感）。指标层面还要看 Recall@K 随 K 的变化，K 放大一点就涨很多说明是排序问题，涨不动说明库里根本没有。

RAG 整体该看的指标：分检索和生成两段。检索看 Recall@K、MRR、nDCG、上下文精确率（进上下文的材料里有多少是有用的）。生成看忠实度（回答能否被给定材料支持，有没有编造）、答案相关性（是否回答了问题）、引用正确率（引用的出处是否真的包含该论断）、完整度。业务侧再加任务完成率与人工采纳率。只看一个「准确率」会掩盖问题。

开卷式评测怎么办：把评测集拆成公开集和留出集——公开集给大家调参，留出集只看不调；再定期用真实流量新采样一条「新鲜集」，它的价值在于没人见过。另外让评测集的构造方式对模型不可见（题目改写成真实用户的问法，而不是教科书式提问），并做对抗性构造：同一问题的不同表述、带错别字的口语、需要多跳的复合问题。评测的可信度来自「题不是我们挑的、分不是我们自己打的」。

大模型写代码的心得：落到工程习惯上才有说服力——需求拆到函数级再交给模型、给它可验证的验收标准（先写测试再让它改）、小步提交便于回滚、让它先读现有代码风格再改、对它的输出永远自己 review 一遍而不是直接跑通就合并。判断对错靠运行结果和测试，不靠读起来像不像。

中间件取舍：先看语义需求：需不需要消息持久化、需不需要顺序、需不需要事务、能不能容忍重复。再看运维成本：团队是否已有该组件的运维经验、监控告警是否完备、出问题有没有人能兜。最后看性能与容量的量级是否真的需要。结论通常是「选团队已经在用的那个，除非它有硬伤」——引入一个新中间件带来的复杂度，往往超过它省下的那点性能。