字节即梦后端实习一面面经

《面试题目》

1. 你了解过 codex、Claude Code 之类工具之前用 RAG 检索代码需求，现在却直接用 graph 检索的原因吗？
2. 场景题：你是一个股票交易推荐 Agent，现在有 8000 token；突然来了 20000 token 的数据，分别是长期背景、市场与大众情绪、最近高频交易的数据，都是 JSON 格式，请问有什么方法去处理？要求写代码。

《参考解析》

代码场景下为什么从 RAG 走向图检索。要先把「代码不是普通文档」这个前提讲出来：代码有严格的语法结构、跨文件符号引用（定义—引用、调用链、继承与实现、类型依赖）、以及版本演化关系，纯文本切块再向量检索会丢掉这些结构——切块切开一个函数，检索回来的片段缺上下文；向量相似度匹配的是「文本长得像」，而查代码真正需要的是「谁调用了谁、改这里会影响哪里」。图检索（GraphRAG / 代码知识图谱）的做法是先用解析器（tree-sitter、AST、LSP、编译器前端）把仓库建成图：节点是文件、类、函数、变量、接口，边是定义、调用、导入、继承、实现，检索时按符号定位并从图上游走（按需扩展相邻节点），把结构化上下文一起喂给模型。好处有三：定位精确（按符号而不是靠语义相似度猜）、上下文可控（按调用链取相关片段而不是按 token 相似度灌一堆无关代码）、支持影响面分析（改动影响哪些调用方这类问题是图上的可达性问题）。代价也很实在：建图与增量更新成本高（仓库大时索引耗时、需要随提交更新）、语言与构建系统的解析器维护成本、以及对模糊的自然语言查询不如向量检索直观——所以现实里常见的是混合方案：向量检索负责「找到大致相关的文件与符号」，图检索负责「沿引用关系补全上下文」，再加上 grep 这类精确检索作为兜底。回答时补一句「这不是 RAG 被淘汰，而是检索的粒度与结构从文本块升级到了符号与关系」，比断言「graph 更好」更准确。

Token 预算与超长输入的处理。这道题考的是上下文工程，答法要「先定策略再写代码」。先明确约束：预算 8000 token，来了 20000 token、三类数据（长期背景、市场与大众情绪、最近高频交易）。可选策略按优先级排：分类差异化处理——长期背景变化慢、可以被压缩成摘要或写成结构化要点后长期缓存；市场情绪是中期信号，抽取关键指标（情绪分数、热度、主题词）后丢弃原文；最近高频交易数据时效性最高，保留原始记录但做下采样或聚合（按时间窗聚合 OHLCV 而不是逐笔全留）。压缩与摘要——对文本类用模型做分层摘要（先分块摘要再合并，Map-Reduce 式），对 JSON 做字段裁剪（只留策略需要的字段，丢掉冗余 metadata）。检索替代全量——把三类数据写进外部存储（向量库、KV、时序库），运行时按当前查询只召回相关片段，而不是每轮把所有数据塞进 prompt。预算分配与截断——按重要性给三类分配 token 配额（比如最近数据 50%、情绪 30%、背景 20%），超出配额时按时间与相关性丢弃，并保证截断后 JSON 仍然结构合法（不要截出半个对象）。缓存前缀——把稳定的长期背景放在 prompt 前缀并利用 prompt caching，减少重复计费与延迟。代码实现层面要点：解析 JSON 后按 schema 校验与降级（字段缺失不能崩）、用 tiktoken 之类的 tokenizer 预估长度而不是按字符数估算、对超长输入走流式处理避免一次性载入、以及把「压缩前后是否改变结论」纳入评测。最后给出一个可验证的收尾：用一批历史样本对比「全量塞入」与「分层压缩 + 检索」两种方案在推荐指标与成本上的差异——这才是面试官想听的工程闭环。

Agent 类岗位的面试重点。这类岗位（尤其是后训练与应用方向）问项目的比例远高于八股，考察点集中在三处：一是对模型能力边界的理解（什么任务适合交给模型、什么应该用确定性代码）；二是上下文与成本控制（上面那题就是典型）；三是评测与迭代（怎么定义任务成功率、怎么构造评测集、badcase 怎么回流）。准备时把自己做过的 Agent 功能按「任务定义 → 工具与检索设计 → 上下文与成本 → 评测与失败处理」四段讲清，比罗列用了哪些框架更能体现能力。