每周一道 Agent 面试题 - Top K 怎么设

面试官问：你们 Agent 的 RAG 检索，Top K 是怎么定的？

这是 RAG 类问题里出现频率最高的一道，而且它有一个陷阱属性：看起来人人都能答两句，所以答得好坏的差距会被放得极大。下面完整拆一遍。

1、重点考的是什么

表面问的是一个数字，实际考四层，一层比一层深：

第一层：是否理解 top_k 是链路上的约束节点，而不是孤立参数。 top_k 卡在"检索"和"生成"的接口上：往上游看，它决定了召回率的天花板；往下游看，它决定了塞进模型上下文的 token 量，直接影响成本、延迟和答案质量。

横向看，它和至少四个环节强耦合：

• chunk 大小：同样的 k，chunk 越大塞进去的内容越多；
• rerank：有没有精排决定了你敢不敢召回宽；
• query 改写：单一 query 和多路改写需要的 k 不一样；
• 上下文组装方式：全文拼接还是让模型自己选段引用。

能把这张关系网讲清楚的候选人，说明真的搭过系统；只报一个数的，说明只是调过一个数字。

第二层：是否有评测驱动的调参习惯。 top_k 没有理论最优解，只有"在你的评测集上最优"——语料密度、chunk 策略、embedding 质量全变了，同一个 k 的含义就全变了。所以面试官想听的不是"设 5"，而是"怎么知道 5 合不合适"：有没有评测集、评测集怎么建、看什么指标、看到什么信号会调整。这一层直接区分"调过参的人"和"看过博客的人"。

第三层：是否理解上下文利用率，也就是"多给不等于多用"。 有一个在多个主流模型上被实验验证的现象（Liu et al., 2023,《Lost in the Middle: How Language Models Use Long Contexts》）：把相关段落放在长上下文的中段，模型对它的利用率显著低于放在头尾（lost in the middle）。也就是说 k 从 10 涨到 30，中间那 20 段不仅可能没用，还会稀释注意力、把模型带偏——无关段落里某个巧合的表述经常被模型当成答案的一部分。理解这层的候选人，会天然说出"上下文是资源，不是越多越好"这类判断。

第四层：是否有成本和延迟意识。 top_k 每加 1，每次查询就多一段 chunk 的 token 计费，多轮 Agent 场景里一个任务要检索 N 次，成本乘法算下来差别很大；rerank 和生成阶段的延迟也随 k 增长。把这层主动讲出来的候选人，通常真的为线上账单头疼过。

一句话：这题考的不是记忆，是工程判断力——面对一个没有标准答案的参数，你有没有一套自己的决策方法。

2、面试官的判分逻辑

面试官心里没有标准答案，全程在听方法论。典型回答对应的判分：

回答方式	判断
“设 5 就行，网上都这么设”	没做过，直接减分
“我们设的是 8”（报完数字就停）	做过，但从未追问过为什么
只讲 recall / precision 理论，说不出怎么验证	看过文章，没上过线
预算推导 + 评测指标 + 具体调整信号	做过，且有独立的工程判断
上来就堆方案：“多路召回 + RRF + 精排 + 小 k”	有知识，但没听题——问的是 k 怎么定，不是怎么把链路做复杂

注意最后一行：过度工程化也是一种失分。题目问的是一个参数，你回答一整套架构，说明要么没听题，要么在背准备好的答案。这里会有人问：下文第 3 节不也推荐"召回 50~100、精排后取 3~5"吗，和堆方案有何区别？判别标准只有一条：方案是带着推导和验证依据出现的，还是光秃秃出现的——堆方案是直接报架构结论，推导是先讲预算约束和权衡，再用评测信号说明为什么落在这个值。同一套词，一个是背诵，一个是判断。好的回答是精准的，不是全面的。

面试官会用追问来验货。 初答过关后，常见追问三连：

1. “你们的评测集多大，怎么建的？”——验证评测闭环是真的还是嘴上的；
2. “k 从 5 调到 10 之后，指标变化了多少？”——验证真的调过、看过数字；
3. “为什么不用更大的 k，反正现在上下文窗口也够大？”——验证有没有成本意识和上下文利用率认知。

三追问里挂掉任何一个，前面的加分都会打折。准备这道题时，按这三问准备素材。

更深一层的意图：这类小参数题是最经济的筛选器。面试官用 30 秒问出来，用 2 分钟验完，就能完成一次分层——因为 Agent 工程里大量决策都是"没有理论最优的局部参数"（k、温度、chunk、重试、超时、置信阈值），top_k 只是缩影。你的回答方式暴露的是你面对不确定性时的稳定习惯：拍脑袋，还是建闭环。这个习惯会在之后每一道系统设计题里反复出现，所以它值得被第一道题测出来。

一个反向加分信号：如果候选人反问"你们的 chunk 策略是什么、有没有上 rerank、语料密度大不大"，说明他理解参数不孤立，且已经在把这道题往"你们的系统"上建模——这比背出任何数值都值钱。面试到这个份上，这道题的考察目的已经超额完成了。

3、怎么回答更稳

按"约束 → 起点 → 闭环 → 联动"四层展开。这个层次本身就是加分项：它让面试官听到你脑子里有一张决策流程图，而不是一堆零散经验。

第一层：讲清 top_k 的本质权衡（约 15 秒）

• 调大：召回率升，漏答案风险降；但噪声段落比例升、token 成本升、延迟升，且中段内容容易被模型忽略（lost in the middle）；
• 调小：精准、便宜、快；但"答案所在段落没进前 k"的错误会变多；
• 核心句式：“k 是在拿噪声换召回，这笔交易划不划算，取决于后面有没有精排和评测。” 先把 trade-off 说清楚，证明你知道自己在权衡，而不是在找"正确值"。

第二层：给一个有依据的起点，而不是拍脑袋（约 20 秒）

• 先算上下文预算，这是唯一能先于实验确定的硬约束：

  top_k × 平均 chunk 长度 ≤ 可用上下文额度

  可用额度 = 模型上下文窗口 - system prompt - 对话历史 - 工具输出 - 预留生成空间。举个可口述的例子：128k 窗口，system prompt 2k、历史 8k、工具输出 4k、留 4k 生成，额度约 110k——纯窗口角度看 k 可以很大，但每段 512 token、k=30 就是 1.5 万 token 的输入，按价格算一遍，多数场景就不敢这么填了。所以预算的真实约束通常不是窗口，而是成本和利用率；

• 经验起点（有依据的默认值）：

  • 有 rerank：召回宽、保留窄——召回 50~100，精排后取 3~5；
  • 没 rerank：直接取 5~10；
  • 语料密集（一段答案散在多个 chunk 里）：偏向取大；语料稀疏（答案集中在单段）：偏向取小；

• 关键话术：把这个起点说成"从这儿开始测"，而不是结论。起点的作用只是让第一次实验别太离谱。

第三层：讲调优闭环（约 30 秒，面试官真正想听的部分）

• 建评测集：从真实日志里抽 50~200 条 query，标注相关段落或写标准答案。量不用大，关键是覆盖典型场景和已知 bad case；没有日志就人工造，标注成本几个人时，换来的是所有参数决策的地基；
• 看两个层级的指标：
  • 检索侧：recall@k——标注的相关段落有没有进前 k，这是 k 的直接责任区；
  • 生成侧：端到端答案质量——漏信息、引用错段落、编造，按错误类型归类统计，这一步决定"锅"是 k 的还是别人的；
• 调整信号（这套信号是本题含金量最高的部分）：
  • 错误集中在"引用错段落 / 被无关内容带偏" → 检索排序质量差，降 k 或补 rerank；
  • 错误集中在"漏信息" → 先确认 recall@k：相关段落没进前 k 才是 k 的锅，升 k；如果召回 50 名里根本没有相关段落，那是召回侧的问题（混合检索、query 改写、embedding 质量），升 k 没用；
  • 两类错误都少但成本扛不住 → 降 k，把省下的预算花在 rerank 上；
• 主动点破：很多时候问题根本不在 k，而在上游——chunk 切得稀碎会把一个完整答案切开导致永远召回不全，query 表述和文档表述用词不一致导致语义检索失灵。先修上游，再调 k。

第四层：讲与其他环节的联动（约 15 秒）

• chunk 越大，k 应该越小：同样是 1 万 token 预算，512 的 chunk 装 20 块，2048 的 chunk 只装 5 块——两个参数本质是同一个预算公式的两个变量；
• rerank 是用小成本换自由度：cross-encoder 对 50 个候选精排的耗时和费用，相比一次 LLM 调用几乎可以忽略，但换来的排序质量提升远大于把 k 从 5 扩到 20。所以在延迟预算允许加一跳精排的前提下，“召回宽 + 精排窄"通常优于"直接取大 k”；这个前提有两个常见例外——对首 token 延迟极敏感的场景塞不下精排，语料太小召回不满宽口子时直接取小 k 反而干净；
• Agentic RAG 的趋势：与其一次取大 k 赌覆盖率，不如小 k + 多轮检索——第一轮取 3~5，模型判断信息不够，改写 query 再查一轮。把"要不要更多上下文"变成 Agent 的决策而不是写死的参数，等于让系统自己动态调 k。

收尾金句：top_k 的正确答案是"预算约束下的经验起点 + 评测闭环迭代"——任何脱离具体系统报出的固定数字，本身就是错误答案。

四层加起来口述约 80 秒，加上收尾金句正好控制在 90 秒内，不超时、不冷场、每层都留了追问接口。

4、再遇到这个问题的解答思路

只做三件事，注意这一节不复述答案——答案会随题目变，这里沉淀的是换一道题也不会变的东西。

• 理清思路：

  • 先识别题型：这是"无理论最优的局部参数怎么设"类问题。这一族很大：top_k、temperature、chunk 大小、重试次数、超时阈值、工具选择的置信阈值、记忆写入的频率，全是同一个题型。题型识别完成，一半的解法已经到位；
  • 通用展开路径固定三步：① 这个参数在链路里牵动什么——把影响面列全（质量、成本、延迟、稳定性）；② 拿什么约束定起点——找到一个可以先于实验计算的硬约束（预算、SLO、物理上限），从它反推出安全区间；③ 拿什么手段验证——评测集 + 指标 + 调整信号，构成闭环；
  • 自检标准只有一条：答案里有没有"怎么知道这个值合适"的部分。 没有，说明你只是在报数；有，说明你在讲方法。所有同类题的及格线都在这一句上。
  • 变体识别：面试官还会换皮来问——“你们温度怎么设的？”"检索不到内容时重试几次？“听到"怎么设/怎么定/取多少”，直接套三步，不要按新题重新想。

• 梳理知识脉络：

  • 主干是 RAG 全链路：query 改写 → 召回 → 精排 → 上下文组装 → 生成。每个环节都有自己的参数族，top_k 挂在"召回与生成的接口"上。把链路图刻在脑子里，任何链路题都能按图定位；
  • 三棵支撑知识树，各自的节点要能随口展开：
    • 上下文经济学：预算公式、lost in the middle、token 成本模型、缓存与多轮放大的乘法效应；
    • 评测体系：recall@k、MRR、端到端质量、错误归类法（漏信息 / 引用错 / 编造，各自归因到不同环节）；
    • 检索工程：混合检索（向量 + 关键词 + RRF 融合）、rerank（cross-encoder）、chunk 策略（固定长度 / 语义切分 / overlap）、query 改写（多路、扩展、HyDE）；
  • 回答前先在心里把问题钉到树上：这题主要用哪两棵树、次要涉及哪一棵。定位完再开口，答案的结构和详略自然就对了——这也是避免"全面但散"的方法：讲全树不如讲准位置。

• 给出合理输出方案：

  • 口述固定三段式：权衡一句 → 依据两句 → 验证三句，收尾补一句"脱离系统报固定数字就是错的"。这个三段式是第 3 节四层的压缩口述版：权衡对应第一层，依据对应第二层，验证对应第三层；第四层联动不主动讲，留作面试官追问时的展开接口。压缩版口述约 1 分钟，按完整四层展开总时长控制在 90 秒内，都给追问留了空间——把所有东西一次讲完是新手错误，层次感比覆盖面值钱；
  • 预备一个真实案例，按五要素装填：背景（什么业务、语料什么规模）→ 起点（当时拍了个什么值）→ 发现（评测暴露了哪类错误、数字变化多少）→ 调整（怎么改的、还动了什么参数）→ 结果（指标变化 + 成本变化）。任何一环被追问，都能落到具体数字上——案例是所有方法论题的防伪标签；
  • 追问应对策略：往上下游参数引（chunk、rerank、query 改写），把单参数题升维成系统设计题——参数不孤立的人，讲任何一个参数都会自然带出它的邻居。主动权就此回到自己手里；
  • 反问准备：至少准备两个好问题——“你们语料的 chunk 策略和 rerank 情况是怎样的？”"线上指标和离线评测的偏差大吗？"既能换取信息校准后续回答，又直接展示参数不孤立的意识。

5、这些问题中哪些知识需要形成肌肉记忆

按"看到什么就自动吐出什么"的标准整理，每条给出反射内容：

• 公式反射：看到任何 top_k 相关问题，先在心里过 top_k × chunk 均长 ≤ 上下文预算，并且能立刻补充"真实约束通常是成本，不是窗口"；
• 数字反射：有 rerank——召回 50~100、精排后取 3~5；没 rerank——取 5~10。被问"那你们设多少"时 1 秒内能给出带条件的默认值；
• 概念反射：lost in the middle——“相关内容放长上下文中段，模型利用率显著低于头尾”，10 秒内讲完；recall@k——“标注的相关段落有没有进前 k，这是 k 的直接责任区”，同样 10 秒；
• 信号反射：引用错段落 → 降 k 或补 rerank；漏信息 → 先看 recall@k 定责，是 k 的锅就升 k，不是就修召回；错误分类定责这套流程要形成条件反射，因为它是整道题含金量最高的部分；
• 金句反射：“预算约束下的经验起点 + 评测闭环迭代”——收尾必背，一句话把方法论立场立住，同时堵死"所以到底设几"的追问陷阱；
• 迁移反射：听到"怎么设 / 怎么定 / 取多少"，条件反射地启动"约束 → 起点 → 闭环"三步，而不是开始回忆别人设的是几；
• 题型反射：能一口气说出同族参数至少五个（top_k、temperature、chunk、重试次数、置信阈值），说明题型识别已经内化——面试官换皮提问时不会重新归零思考。

自测方法：不看文章，能否 90 秒内把第三节的四层口述完，且每个反射点都不卡顿。卡在哪个反射，哪个就是要重点补的。

6、下篇预告

下一篇：《每周一道 Agent 面试题 - chunk 怎么切》。这两道题必须连着看，因为 top_k 和 chunk 大小是同一个预算公式 top_k × chunk 均长 ≤ 上下文预算 里的两个变量——k 怎么设的问题，一半的答案其实藏在 chunk 怎么切里。你在这篇里留下的每一个悬念，都是下一篇的入口：评测里"漏信息"错误居高不下、升 k 也压不下去，八成是答案被切散在多个 chunk 里，怎么召回都不全——这就是切分粒度的问题；k=5 时中段内容利用率低，除了降 k，换一种"短 chunk + 高密度拼接"的组装方式也能救——这就是 chunk 与上下文组装的联动问题。下一篇会拆四个问题：固定长度还是语义切分，各自的适用边界在哪；切多大，512 和 2048 背后各自赌的是什么；要不要 overlap，重叠率换召回的账怎么算；粒度和召回率的天生矛盾怎么解。看完两篇，预算公式里这两个变量就都攥在自己手里了。

7、结束语

面试题的价值不在题目本身，而在它逼你把模糊的经验讲成结构化的方法。日常做系统，参数是随手设的、效果是模糊感知的，没人逼你把"为什么是这个值"说清楚；面试把你按在椅子上，要求 90 秒内给出有层次的回答——这个压力恰恰是提炼的最好时机。top_k 这道题尤其典型：它小到人人敢答，又深到答好很难，答案里藏着的预算推导、评测闭环、错误归因，每一件都是可以立刻搬回自己系统里的实操能力。所以准备这类题的正确姿势不是背稿，而是把文章里的框架拿到自己的项目上真跑一遍：算一次预算、建一个五十条的评测集、看一次错误归类——稿子会忘，做过的判断忘不掉。最后提醒一个容易忽略的收益：当你把"无理论最优参数"的通用解法（约束 → 起点 → 闭环）练成条件反射，面试官换皮的速度就永远追不上你——下一道"温度怎么设"来的时候，你会发现自己已经在答同一道题了。