面灵AI→

货拉拉大模型二面:上下文压缩与记忆沉淀

轮次
二面
时间
2026-09
来源
牛客网

《面试题目》

  1. 问实习的难点和怎么解决。
  2. 你怎么评估 LLM 沉淀的结果?冲突、重合怎么处理?
  3. 你这个 firstcoder 当初的想法是什么?和别的 coding agent 有什么不同?
  4. 上下文为什么要压缩呢?
  5. 上下文和记忆的区别是什么?
  6. 记忆是怎么沉淀的?
  7. 你的测评怎么做的?你还知道别的什么测评集吗?侧重点有什么不同?
  8. 自我介绍。

《参考解析》

上下文为什么要压缩:三个硬约束。第一是窗口有限——即使 128K 甚至更长的上下文,prompt 越长成本越高(注意力是 O(L²)),而且长上下文里模型对中段信息的召回明显变差(lost in the middle);第二是信噪比——多轮工具调用会把大段无关的原始输出(网页 HTML、日志、目录树)塞进对话,真正有用的结论可能只有几行,不压缩会稀释指令跟随能力;第三是稳定性和时延——上下文越长首 token 时延越高,同一任务多轮对话还容易触发重复、跑偏。压缩的常见手段分层:① 结构化截断,工具输出只保留头部+尾部+匹配到关键词的行(例如 grep 命中行),而不是整篇灌进去;② 摘要替换,把较早的多轮对话用模型或规则压成要点摘要,保留决策和未完成事项;③ 外置存储,把大块内容放进文件或检索库,上下文里只留引用和索引,需要时再按需取回(这也是 memory 与 context 分离的动机);④ 分层记忆,把「当前任务状态」和「跨会话知识」分开维护。

上下文与记忆的区别:上下文是「本次推理可见的 token 序列」,随会话结束即消失,受窗口大小限制,写入即全文可见;记忆是「跨会话持久保存的信息」,存在外部存储(文件、向量库、结构化表),需要显式检索/注入才能进入上下文,因此有「写入—索引—召回—更新」这一整套生命周期。可以这样类比:上下文是 RAM,记忆是磁盘。正因如此,记忆系统的难点不在存,而在「什么时候召回、召回多少、冲突了信谁」。

记忆怎么沉淀、冲突与重合怎么处理:沉淀通常走「抽取 → 归一 → 写入 → 维护」四步。抽取是从对话或工具结果里把可复用的事实/偏好/结论抽成结构化条目({主体, 属性, 值, 来源, 时间, 置信度}),最好带原始出处以便回溯;归一化要处理同义表述(「用 bun 不用 npm」和「包管理用 bun」是同一件事)和粒度对齐(别把一次性的临时决定当成长期偏好)。冲突处理是核心:先按主体+属性做键去重,同一键多值时的策略有三种——时间优先(取最新,并保留历史版本)、来源优先(用户显式指令 > 模型推断 > 观测默认值)、置信度优先(多次出现且一致的加权更高);如果确实是矛盾且无法判定,正确做法不是悄悄覆盖,而是保留两条并标记冲突,在召回时把冲突提示给模型或向用户确认。重合则是去重加合并,合并时注意别把条件和适用范围丢掉(「在项目 A 里用 X」不能被合并成「总是用 X」)。评估沉淀质量可以看四个指标:抽取准确率(人工抽样)、召回命中率(该用的场景有没有取到)、错误记忆率(取到过时/错误条目导致答错的比率)、以及更新时效(用户改口后多久生效)。

firstcoder 与其它 coding agent 的差异怎么讲:这类问题面试官想听的是「你的设计判断」,不是功能列表。可以从四个维度对比:① 上下文策略(别人靠长窗口硬扛,你靠压缩 + 记忆分层,长任务上更稳);② 记忆沉淀(把项目约定、踩过的坑沉淀成仓库级记忆,跨会话复用,而不是每次从零读代码);③ 验证闭环(生成的代码必须过编译/测试才算完成,用可验证信号约束模型,而不是靠模型自称完成);④ 交互范式(工具集与并行度、失败重试与回滚、人在环的介入点)。回答时用「别人怎么做 → 我为什么不同 → 效果差在哪」的三段式,并准备好具体数据(例如同一个任务节省的 token 数、一次通过率)。

评测怎么做、评测集怎么选:评测按层次分三类。组件级:检索看 recall@k / MRR,记忆看命中与错误记忆率,代码生成看编译通过率、单测通过率。任务级:端到端成功率(SWE-bench 系列最典型,用真实 issue + 隐藏测试判定修没修好;HumanEval/MBPP 偏函数级、LiveCodeBench 防数据污染)、以及多轮 Agent 任务集(WebArena、GAIA、τ-bench 这类考察工具调用与长程规划)。主观质量级:用 LLM-as-judge 或人工打分,注意位置偏置和长度偏置,做双盲与参考答案对照。不同评测集的侧重点可以说清:SWE-bench 重「仓库级真实修复」,HumanEval 重「单函数正确性」,LiveCodeBench 重「时效与污染控制」,GAIA 重「多步工具协作」,τ-bench 重「遵循业务规则的多轮对话」。自建评测的两个要点:一是从真实 badcase 反推用例(比造题有效),二是把评测集做成回归门禁,每次改动都跑,否则指标只是好看。