面试系列 06|AI 时代基础设施面试:从数据库内核到 LLM 推理与 Agent 运行时

面向资深数据库工程师的 AI 基础设施面试推演:推理调度、KV 状态管理、Agent 可靠性、向量检索与数据库智能化,含追问链、验证边界和迁移叙事模板。

系列导航:面试索引 · 代码评审与 Agentic 研发

数据库内核经验迁移到 AI 基础设施,要把调度、内存、状态和失败处理落实为可验证的系统契约。 能算出资源边界、解释优化何时失效,并给出对照实验,才有依据判断迁移能力。

算例均为明确题设,未测得的数据不作为个人成果;实现讨论限定所引版本。涉及个人经历的【模板】须由本人补齐。

一、先定义推理服务的目标,再谈优化开关

题 1:吞吐上涨,为什么用户反而觉得更慢?

强答要点:大语言模型(Large Language Model,LLM)服务先区分首词延迟(Time to First Token,TTFT)、词间延迟(Inter-Token Latency,ITL)、端到端时延,以及服务级别目标(Service Level Objective,SLO)。本文的服务端 TTFT 从请求到达服务边界计至首个输出词元返回,包含边界内的排队、分词和预填充;客户端 TTFT 还包含网络等开销。不同基准的计时边界可能不同,比较时必须对齐,不能只报 图形处理器(Graphics Processing Unit,GPU)上的一段执行时间。

预填充(Prefill)处理输入前缀,解码(Decode)逐步生成后续词元(Token)。常见密集 Transformer(变换器模型) 在较长输入的预填充阶段有较高计算强度,小批量解码则经常受权重和状态访存限制;这只是瓶颈假设,必须结合模型结构、上下文长度、并行方式和实际设备验证。

DistServe 把优化目标设为在首词延迟和每请求平均输出词元耗时(Time per Output Token,TPOT)约束下、达到指定 SLO 达标比例的每 GPU 有效吞吐(Goodput),而不是仅追求生成总量。TPOT 是首词之后的平均值,不能保证每个词间间隔都达标。这给出了讨论服务容量的统一入口。DistServe,OSDI 2024

追问:延迟从哪里开始计时?客户端和服务端分别打点;流式连接建立不等于首个有效词元到达。明确网络是否包含在服务承诺内;如何发现排队主导?分解入口队列、调度等待、实际执行和回传;按输入长度与输出长度分桶看尾延迟,不只看全局平均值。

差答:“GPU 利用率越高越好”没有说明有多少工作在截止时间内完成。

可交付证据:一张分阶段时延图、一张到达负载与合格完成量曲线,以及一份完整的失败分母。没有线上数据时,明确这是负载生成实验。

题 2:连续批处理为什么有效,又为什么会饿死请求?

强答要点:连续批处理(Continuous Batching)在生成迭代的边界调整活跃集合:完成的请求退出,新请求获得位置。静态批处理需要等同批长尾结束才能整体换批;迭代级调度减少空闲位置,但不消除请求之间的计算与显存竞争。

vLLM 的 PagedAttention 工作把迭代调度与按需 KV 分配结合,允许不同长度请求更有效地共享显存。PagedAttention,SOSP 2023

调度预算至少包括本轮处理词元数、活跃序列数和可分配 KV 块。只有序列数上限时,一条超长输入仍可能占用整轮计算;只有词元预算时,又可能产生过多序列管理、采样和回传开销。

追问:调度单位是什么?区分一次生成迭代、一个预填充片段和整个请求;只有明确可抢占边界,才有公平性的实现基础;解码突然需要更多显存怎么办?为增长预留余量,或在明确边界暂停、换出、重算;不能在内核已经引用地址时任意回收块。

差答:“动态 batch 就是不断加请求”遗漏退出、增长和资源回收。

可交付证据:调度器伪代码应返回已选请求、资源扣减和未选原因;用长短混合、突发到达与取消测试验证是否有饥饿。

题 3:分块预填充如何缓解干扰?

强答要点:分块预填充(Chunked Prefill)把一次长预填充拆成多个有序片段,使调度器能在片段之间推进已有解码。它控制一次迭代的工作量,减少长输入形成的大停顿;不减少输入本身必需的注意力计算,也不让后续片段脱离此前上下文。

Sarathi-Serve 在 2024 年提出以分块预填充构造减少解码停顿的调度,并研究吞吐与延迟的折中。其收益依赖模型、设备及延迟约束,不能直接迁移为所有引擎的固定倍数。Sarathi-Serve,OSDI 2024

片段越小,单次阻塞通常越短,但调度、内核启动和中间状态管理次数可能增加。片段太大则重新接近长预填充;应把片段大小作为策略参数,而不是把某个词元数当作通用常量。

追问:每块是否只关注块内词元?否;因果注意力(Causal Attention)仍需访问此前合法位置的状态。分块改变执行安排,不能任意改变模型语义;优先解码会伤害谁?新请求首词可能等待更久;需要对首词和逐词目标分别分配预算。

差答:“切成小块后计算复杂度变低”把调度优化说成算法复杂度优化。

可交付证据:固定总输入,比较不分块与不同片段策略下的首词、词间延迟和调度开销,并保留到达负载条件。

二、把 KV cache 当作派生状态管理系统

KV 缓存(Key-Value Cache,KV cache)保存模型注意力的键和值,不是业务数据库中的通用键值对。它可以从输入与模型重新计算,但其重算成本和容量增长决定推理服务的可用并发。

数据库经验可以迁移到容量估计、共享引用和分层管理;迁移边界是模型状态的语义兼容性。两个看起来相同的文本,并不自动对应可以互用的设备状态。

题 4:PagedAttention 到底把什么“分页”了?

强答要点:PagedAttention 把逻辑上连续的 KV 序列映射到不必物理连续的固定大小块,使用块表定位。共享前缀或生成分支可共享块,并在需要修改共享状态时采用写时复制(Copy-on-Write)。它借鉴操作系统分页思想,但不是让 GPU 自动通过 CPU 页表按需取回 KV。PagedAttention 论文

对于各层配置相同、使用常规键值头的模型,未分片的 KV 原始字节数可按下式估算:

1KV_bytes = 2 × 层数 × KV头数 × 每头维度 × 上下文词元数 × 每元素字节数

设模型有 32 层、8 个 KV 头、每头 128 维,采用每元素 2 字节表示。每个词元是 2 × 32 × 8 × 128 × 2 = 131072 字节,即 128 KiB;8192 个词元的原始 KV 为 1 GiB。这是算例,不包含块表、对齐、工作区、图捕获内存和共享收益。

分组查询注意力(Grouped-Query Attention,GQA)下应使用 KV 头数,不能套用查询头数。多卡部署还需看 KV 头如何分片或复制;不能默认用总大小除以卡数得到每卡占用。

DeepSeek-V2 的多头潜在注意力(Multi-head Latent Attention,MLA)使用压缩潜在表示改变 KV 状态组织,因此上述普通 KV 头公式不应原样套用。DeepSeek-V2,2024

追问:分页是否消灭碎片?减少大段连续分配造成的浪费,但尾块仍有内部碎片,元数据和块粒度也有成本;共享块能直接写吗?应由所有权和引用计数决定;共享部分必须保持不可变,独占尾部才能按规则追加。

差答:“PagedAttention 把 KV 存进磁盘”“它让注意力变成线性复杂度”“所有卡均匀分摊 KV”都跳过了关键条件。

题 5:前缀复用为什么既是索引问题,也是隔离问题?

强答要点:前缀缓存(Prefix Caching)复用保存已经计算的中间状态,匹配的是模型实际接收的词元序列及其兼容上下文。语义相近不等于前缀相同;同一段文字放到不同历史后面,其位置和注意力上下文可能不同。

SGLang 的 RadixAttention 用基数树(Radix Tree)组织可共享的前缀状态,利用程序中重复出现的提示前缀;缓存感知调度把复用机会纳入请求安排。SGLang,NeurIPS 2024

vLLM v0.10.1 的设计文档说明基于块哈希的前缀缓存,哈希依赖父块、当前块词元和额外信息,并涉及适配器、多模态输入及缓存隔离;该实现只缓存完整块,匹配前缀不代表所有匹配词元都能免于重算。这是该版本机制的依据,不把它等同于所有版本的接口承诺。vLLM v0.10.1 前缀缓存设计

追问:后缀相同为什么不够?因果模型的中间状态依赖此前序列;普通前缀缓存没有证明任意片段拼接的等价性;命中能加速哪些部分?主要减少可复用输入的预填充;后续生成仍需运行模型,并访问已有上下文。

差答:“相似问题共享 KV”混淆语义答案缓存与前缀状态缓存。

题 6:KV 放到 CPU 或 SSD,何时比重算更贵?

强答要点:先比较重算与取回的关键路径成本:取回时间 ≈ 定位与排队 + 字节数/有效带宽 + 格式转换与同步。只有预计节省的计算超过这条路径,外部缓存才可能帮助当前请求;高命中率不能替代时间估算。

设需要取回 1 GiB,端到端有效传输带宽为 25 GiB/s,仅数据移动下界就是 40 ms,尚未计排队与同步。这个示意值不能冒充网络实测;如果同一前缀重算只需更短时间,取回将延迟首词。

Mooncake 把 KV 作为中心状态组织分离架构,并利用 CPU、主存及 SSD 资源构建缓存,调度同时考虑延迟目标与过载处理。Mooncake,2024 预印本

淘汰可以按“预计复用次数 × 每次可节省的关键路径成本/占用字节”排序,但这是设计候选,尚需在线验证。活跃且仍被设备引用的块必须固定;已落盘的块只有在内容完整且兼容性元数据发布后才能进入可发现状态。

追问:最近最少使用为何不总合适?最近最少使用(Least Recently Used,LRU)不直接考虑重算代价和预期复用频率;若按变长前缀对象淘汰,还需考虑对象大小。固定大小 KV 块没有块大小差异,但重算与复用价值仍可能不同;对象写一半时节点宕机?先写不可见内容,校验完整后发布元数据;读取失败回退重算,避免把半块当有效状态。

差答:“内存不够就 swap”“加 Redis 缓存 KV”“远程内存等价于本地显存”都没有建立带宽、布局与生命周期契约。

题 7:PD 分离为什么不是默认答案?

强答要点:预填充/解码分离(Prefill-Decode Disaggregation,PD 分离)让预填充与解码使用不同工作节点或资源池,分别选择并行配置与扩容策略。它减少两阶段直接竞争,但会引入 KV 交接与多队列协调;交接可发生在同节点的不同 GPU 之间,跨节点部署才额外依赖节点间网络,传输也可能与计算重叠。

DistServe 的核心是隔离两阶段并围绕有效吞吐规划资源,同时考虑带宽与并行配置;Mooncake 更强调 KV 中心的状态管理和过载调度。两者都不是“增加网络后自动更快”的证明。DistServe、Mooncake

先用混合部署建立基线,定位干扰占比,再比较可省下的等待与新增传输时间。短输入、小规模或低带宽环境,拆分可能扩大首词时延;长上下文、高负载且资源干扰明显的环境,更值得验证分离。

追问:KV 在什么时候可被解码端消费?说明层或块级完成条件、传输完成通知与可见性;“发送完成”未必等于目标设备已可读;两池并行配置不同怎么办?明确布局重分片、转换与通信代价;传输字节数和端到端延迟不能只按总 KV 容量推算。

差答:“预填充计算密集、解码访存密集,所以必须分离”把常见特征当成无条件决策。

三、算子与生成算法的优化必须有各自的正确性边界

题 8:FlashAttention 与 PagedAttention 能互相替代吗?

强答要点:FlashAttention 通过分块、片上存储复用和在线 softmax(归一化指数函数)组织注意力计算,避免在高带宽显存(High Bandwidth Memory,HBM)中物化完整注意力分数与概率矩阵,减少中间结果的读写。常规稠密自注意力对序列长度的计算规模仍为平方级。FlashAttention 原始论文

FlashAttention-3 针对 Hopper 架构研究异步计算与数据搬运重叠、矩阵乘与 softmax 流水,以及低精度路径。其硬件专门化意味着不能把 H100 上的算子结果外推到任意设备。FlashAttention-3,2024

PagedAttention 管 KV 的物理块与访问映射;FlashAttention 管注意力计算的数据流。实际后端是否把两者有效结合,取决于布局、内核和形状支持,不是概念兼容就代表某个版本实现全覆盖。

追问:为什么在线 softmax 可行?按块维护当前最大值和归一化累加量,最大值变化时重标定旧累加量,保持数学表达等价;数学等价是否逐位一致?浮点运算次序改变会影响舍入;要区分数值误差容限、任务质量与精确字节一致。

差答:“FlashAttention 就是稀疏注意力”“它压缩了全部 KV”“把 CPU 向量化算子搬到 CUDA 即可”都混淆语义与执行。

题 9:CUDA Graph 为什么能加速,为什么会引入内存问题?

强答要点:图捕获与重放把多次操作的提交组织成可重复执行的图,从而减少 CPU 侧启动成本。所引 PyTorch 文档讨论的常规捕获与重放要求固定内核参数及其指针地址,并通过长生命周期的输入缓冲区更新内容;这里不涵盖显式图更新等其他 CUDA Graph 用法。PyTorch 官方 CUDA Graph 说明

变长服务可以按一组形状捕获,运行时选择桶并填充,或让不适合捕获的路径退回普通执行。这是服务设计方式,不能推定所有算子、通信和动态控制流都支持捕获。

图数量、静态缓冲区与私有内存池会占显存,可能挤压 KV 容量。单步更快而并发下降时,端到端有效吞吐未必增加;图优化必须和容量重新联合评估。

追问:动态批量怎么映射?解释桶边界、填充成本与未覆盖形状的回退;观察命中桶分布,避免为罕见形状捕获大量图;捕获前要做什么?预热分配及相关状态,确认捕获路径支持情况;冷启动成本与稳定运行收益分别报告。

差答:“CUDA Graph 会自动融合全部算子”“图重放等于零 CPU 开销”“RAII 析构即可安全释放 GPU 缓冲”均不成立。

题 10:推测解码到底保留了哪一种正确性?

强答要点:推测解码(Speculative Decoding)让草稿机制先提出多个候选,再由目标模型验证,从而尝试用一次较大验证工作替代多次串行生成。有效收益取决于接受长度、草稿成本、验证成本与目标设备的剩余能力。

精确推测采样使用接受与拒绝修正,在相应算法假设下保持目标采样分布。保持分布不意味着相同随机种子下逐词完全一致,也不能把任意“让大模型挑答案”的方案称为无损推测采样。Speculative Sampling,2023

EAGLE-3 在 2025 年取消早期方案的特征预测约束,采用多层特征融合并直接预测词元。介绍 EAGLE 时必须指明代际,不能把早期设计一概套到新版本。EAGLE-3

2026 年修订的系统研究在 vLLM 上比较多种推测方法,指出验证成本、接受长度变化与批量规模是解释实际效果的重要因素。这支持“必须按负载测”的结论,不支持任何统一加速倍数。Speculative Decoding: Performance or Illusion?,v2

可用 每轮提交的期望词元数/(草稿时间 + 验证时间 + 额外调度时间) 与基线比较。大批量下目标模型已经较充分使用设备,额外草稿和树验证可能争抢同一资源,使低延迟优势无法转成总容量优势。

追问:接受率高就一定快吗?不够;还要看接受长度、每轮验证规模和成本。候选更长可能提高提交量,也可能放大无效计算;采样参数改变会怎样?温度、截断策略与目标分布定义必须进入正确性讨论;不能只验证贪心路径后就承诺所有采样模式正确。

差答:“小模型代替大模型所以更快”遗漏验证;“接受率 80% 就快 80%”没有成本模型;“EAGLE 永远预测顶层隐藏状态”忽略版本变化。

题 11:量化收益为什么不能只按位宽计算?

强答要点:量化(Quantization)降低表示精度,可能节省容量和带宽;但缩放因子、分组元数据、反量化、内核支持与形状都会影响实际收益。权重变小并不自动让 KV 变小,KV 变小也不保证预填充计算更快。

AWQ 是感知激活分布的权重量化方案;KIVI 则研究 KV 的非对称量化,分别处理键和值的分布特征。两者优化对象不同,不能作为同一个“开启 INT4”的配置描述。AWQ、KIVI,2024

如果短输入解码主要搬运权重,权重压缩更值得先测;长上下文高并发可能首先受 KV 容量或读取约束。判断必须用当前负载的瓶颈证据,不能把这两种情况固化成定律。

追问:节省的字节去了哪里?分别统计权重、KV、工作区和量化元数据;检查更大批量是否重新消耗节省空间;校准集如何选?与语言、上下文长度、任务和离群值分布相关;明确校准数据与验收数据的隔离。

差答:“低位宽无损”“模型能加载就算成功”“所有任务只看平均分”都不够。

四、Agent 运行时的核心是有副作用的执行

智能体(Agent)把模型输出转成工具操作,系统因此需要处理权限、重试和外部状态。模型每一步是否聪明与运行时每一步是否可恢复,是不同的验收问题。

数据库工程师对事务边界、提交不确定性和审计的理解可直接用于这里;但外部工具通常没有统一事务,不能假设把调用写进日志就能自动回滚。

题 12:工具调用超时后,为什么不能简单重试?

强答要点:工具调用(Tool Calling)先区分只读查询、天然幂等写入、支持幂等键的创建操作和不可安全重试的副作用。模型只提出操作意图;宿主验证参数模式、调用者身份与授权,再由执行器真正提交。

每次业务意图生成稳定操作标识,记录规范化参数摘要、目标资源和授权上下文。工具执行器应尽可能把操作标识与结果原子保存;否则“远端已经提交、响应丢失”仍无法通过本地日志判定。

恢复时先查操作结果,再决定继续;结果未知就进入待核对状态。模型可以重新规划,但不能靠换一个调用标识把同一业务写入当成新意图自动提交。

1已规划 → 已校验 → 待授权 → 已提交 → 已确认
2                              └→ 结果未知 → 查询状态/人工核对
3已提交后收到取消:先查副作用是否已发生,再决定是否补偿

这里的“待授权”表示宿主按策略判断当前授权是否足够,并非每个工具调用都要求人工点击。补偿操作也可能失败,需有自己的状态与审计,不能伪装成数据库回滚。

追问:本地记录成功能否保证只执行一次?不能;本地日志与远端写入之间存在失败窗口,需要远端幂等或状态查询配合;至少一次与恰好一次怎么区分?至少一次提交可能重复;恰好一次业务效果需要限定资源、去重窗口和外部系统保证,不能由提示词承诺。

差答:“异常都重试三次”“让模型判断是否成功”“数据库事务包住所有工具”都忽略外部系统边界。

可交付证据:注入提交后丢响应、执行前超时、重复回调和取消,展示每个状态如何恢复以及何时必须停止自动执行。

题 13:MCP 标准化了连接,哪些责任仍在宿主?

强答要点:模型上下文协议(Model Context Protocol,MCP)固定讨论 2025-11-25 修订版:它定义宿主、客户端和服务端之间的协议,使用 JSON-RPC 2.0,并区分工具、资源和提示。版本号属于接口契约,不能把这一版生命周期假设扩展成所有后续版本的规则。MCP 2025-11-25 规范

宿主需要把用户意图映射到允许的工具和资源,把服务端输出保留为低信任输入。提示注入(Prompt Injection)不能只靠再写一段“不要相信恶意文本”解决;执行前仍要用独立策略检查目标、参数和副作用。

该修订版的 Streamable HTTP(可流式 HTTP)传输规定了 Origin 校验等安全要求。协议接入测试既要覆盖消息模式,也要覆盖连接和认证边界。MCP 2025-11-25 传输规范

追问:工具列表可信到什么程度?它能描述可调用接口,但不能证明实现无害;来源、版本和权限仍需配置管理;认证成功是否意味着有权读所有资源?否;身份认证与资源授权分开,宿主要传播正确用户上下文并限制凭据用途。

差答:“MCP 等于 Agent 框架”“工具描述是系统指令”“OAuth 完成就自动获得所有业务权限”都扩大了协议职责。

题 14:给编码 Agent 一个容器,算不算沙箱?

强答要点:沙箱(Sandbox)应从威胁模型倒推:不可信仓库可以包含诱导文本、测试脚本和构建钩子;模型生成的命令也可能错误。隔离边界必须由执行环境实现,不能让模型自行决定哪些文件可写。

为每个任务创建独立工作副本,限定读写挂载、执行身份、网络出口、CPU、内存与时长。只授予当前任务需要的凭据或代理能力;避免把宿主凭据目录和容器管理套接字暴露给任意构建脚本。

验证与生成环境也要分权:Agent 可以修改测试来表达新需求,但最终验收必须保留可信测试来源。补丁能让它自己改过的测试通过,并不能证明满足外部任务。

追问:仓库 README 要求导出密钥?将其视为任务数据,不是授权;命令执行前的环境权限应使该操作无法读到密钥;测试下载依赖怎么办?使用受控出口、依赖镜像或按任务开放的网络能力,记录依赖版本;不能靠全面开放网络解决可重复构建。

差答:“Docker 默认安全”“禁止几个危险命令即可”“Agent 答应不会读密钥”没有形成隔离机制。

可交付证据:一份任务权限声明及越权读写、出口访问、超时残留进程的失败测试;不需要凭空声称通过了某项安全认证。

题 15:SWE-bench 分数能证明团队研发提效吗?

强答要点:原始 SWE-bench 来自真实 GitHub 问题及对应仓库;Verified 是经人工筛选的 500 个实例。基准有不同子集与运行设置,报告分数必须同时说明使用哪一个。SWE-bench 官方说明

离线修复成功率是特定任务集合、模型、执行框架和预算下的结果,不能直接转换成工程师节省的工时。数据库内核还涉及并发、语义、性能和跨版本回归,公开问题集合未必覆盖目标团队分布。

建立内部验收时,冻结任务、仓库版本、隐藏测试和工具权限。把首次补丁通过率、最终解决率、人工审查耗时、引入回归和成本分别统计;失败任务也计入费用与时间。

追问:换模型后成绩上涨,归因给谁?固定运行框架、预算与工具;再分别更换模型或调度策略,避免多变量变化;多次尝试选最好结果公平吗?可以研究,但必须报告尝试次数、选择规则和总成本,不能与单次结果直接对比。

差答:“排行榜第一就全面接管研发”“测试通过等于需求完成”“把生成代码行数当生产力”都无法支持投资决策。

五、AI for DB 与 DB for AI 要分别承担正确性

AI for DB(人工智能辅助数据库)让模型参与 SQL 生成或内核决策;DB for AI(数据库服务人工智能)提供检索、数据管理与状态支撑。两条路线共享数据基础,但评估对象不同:前者要约束模型错误如何影响系统,后者要约束检索误差与数据可见性。

题 16:Text-to-SQL 为什么不是“生成后执行一下”?

强答要点:自然语言转 SQL(Text-to-SQL)先约定业务含义:收入是否含退款、日期使用什么时区、用户按什么键去重、允许看哪些租户。模式匹配正确不代表指标正确,SQL 能执行也不代表回答了用户的问题。

BIRD 强调数据库内容、外部知识与执行效率;Spider 2.0 则把企业工作流中的元数据、方言文档和项目上下文纳入评估。两者都说明仅验证 SQL 语法不足以覆盖真实任务。BIRD、Spider 2.0,2024/2025

流水线可分为权限过滤后的元数据检索、业务口径确认、候选生成、静态检查、受限执行和结果核对。权限由执行身份和数据库策略落实,不能让生成模型自行添加一个租户条件就视为隔离完成。

执行检查应限制扫描量、运行时间和结果规模;只读语句仍可能耗尽资源或读取越权信息。报错反馈也需要过滤,不能把凭据、完整敏感值或系统内部信息无条件回送模型。

追问:结果和参考 SQL 一样就算正确?在一个数据快照上相同可能是偶然;用空集、重复行、NULL、边界日期等数据检验语义差异;元数据过期怎么办?固定或记录模式版本,执行时校验;字段重命名和指标口径变化要触发重生成或人工澄清。

差答:“用检索增强生成就不幻觉”“加只读权限就安全”“执行结果相同就数学等价”都过度承诺。

题 17:哪些 learned 组件可以进入数据库关键路径?

强答要点:先按错误后果分层。基数估计误差通常通过计划选择影响性能;若模型介入等价重写是否合法的判断,错误则可能影响结果。性能预测可以试错与回退,语义正确性不能只由模型置信度决定。

学习型索引(Learned Index)把键到位置的映射建模,并结合搜索机制完成实际定位;其论证不是“模型预测一个地址就直接当成正确答案”。The Case for Learned Index Structures

对于学习型基数估计,可先影子运行,记录预测与实际行数,再按查询族评估计划退化。新计划的性能回归由异常耗时、资源预算与已知基线约束;回退本身也需要设计触发时机,不能等查询运行完才发现预算已耗尽。

追问:平均估计误差下降是否足够?不够;少量极端低估可能选择灾难性连接计划,要按实际延迟和最坏退化评估;分布漂移如何发现?按表、谓词和查询族观察误差与资源变化,覆盖新数据和更新;不能只在训练时随机切分同分布样本。

差答:“用大模型替代优化器”“置信度高就跳过等价检查”“训练误差低说明可上线”没有识别风险等级。

题 18:HNSW、IVF 与 DiskANN 应按什么维度比较?

强答要点:先确定向量维度、距离函数、数据分布、更新率、过滤选择率、内存预算和召回率(Recall)口径。近似最近邻(Approximate Nearest Neighbor,ANN)的验收对象应是带业务过滤和可见性条件的结果,不能只复用无过滤离线成绩。

分层可导航小世界图(Hierarchical Navigable Small World,HNSW)用分层邻接图完成导航搜索,搜索宽度影响召回与工作量;它不是具有任意数据最坏对数时延保证的 B+ 树替代品。HNSW 原始论文

倒排文件(Inverted File,IVF)将向量按聚类划入列表,查询探测若干列表;pgvector 的 IVFFlat 使用这一路线。DiskANN 则围绕 SSD 上的图搜索组织索引与数据访问,目标是在有限内存下扩展容量。pgvector v0.8.0、DiskANN,NeurIPS 2019

维度HNSWIVF 路线DiskANN 路线
缩小搜索空间的方式图导航与候选扩展先选聚类列表,再查候选图导航配合分层存储访问
主要预算图与向量的内存、构建和搜索宽度聚类质量、探测列表数和候选扫描SSD 读放大、缓存与并发 I/O
必须追问图更新、删除、过滤后连通性分布漂移、重建与列表倾斜冷缓存、设备尾延迟与更新路径
不应承诺任意分布固定低时延少量列表即可稳定高召回磁盘容量扩大而查询成本不变

追问:过滤放在 ANN 后面会怎样?候选可能大部分被滤掉,返回不足 k 条;过采样有帮助但没有任意过滤选择率下的固定保证;先过滤是否一定更好?若合格集合很小,可精确扫描;若过滤破坏图导航或需要建立大量子索引,也会产生额外成本。

差答:“HNSW 都是 O(log N)”“DiskANN 不需要内存”“ANN 后面加 WHERE 就正确”把经验性能或接口形式当成系统保证。

题 19:选 pgvector,还是把向量放在湖上?

强答要点:pgvector 提供精确检索与近似索引;v0.8.0 文档解释了过滤、迭代索引扫描(Iterative Index Scans)以及 HNSW、IVFFlat 的使用条件。它不是默认每条查询都会使用近似索引。pgvector v0.8.0 README

数据与事务元数据共存时,pgvector 可以减少跨系统可见性协调;但是否适合目标规模仍需测内存、构建、更新和查询隔离。把向量列加入现有数据库不意味着资源竞争消失。

Lance 项目把列式数据访问、向量索引与数据版本作为多模态数据基础的一部分。它是讨论湖上向量的具体实现参照,不能据此声称任意 Parquet 数据湖天然具有相同的随机访问或索引能力。Lance 官方项目

“湖上向量”设计应把数据快照、嵌入模型版本和索引覆盖范围一起发布。嵌入(Embedding)由哪个模型生成,属于数据语义;两个不同模型即使维度相同,也不能默认在同一距离空间比较。

增量路径可让旧索引负责已覆盖快照,让增量区负责新数据,查询合并并去重;后台重建后原子切换覆盖范围。这是待验证方案,正确性依赖覆盖集合、删除可见性和无缝切换,不是产品现成功能声明。

追问:索引比数据落后怎么办?明确新鲜度目标;若要求新数据立即可见,必须扫描未覆盖增量或选择同步维护,不能静默遗漏;删除何时生效?逻辑删除应在结果可见性层立即生效,物理回收可滞后;重建与缓存不能重新暴露已删除数据。

差答:“pgvector 只能小规模”“上湖就不需要数据库”“每天重建即可保证实时”都跳过工作负载与可见性。

六、把迁移叙事变成可以核对的能力证明

题 20:十多年数据库经验,凭什么胜任 AI infra 的 Staff?

强答要点:【模板】“我长期做数据库内核与 OLAP,参与 StarRocks 核心开发,现在做大型分布式 SQL 引擎与 IVM。我的迁移切入点是推理调度、派生状态管理和性能验证;我会用可复现工作证明新领域能力。”如果尚未完成 AI 实验,后一句应改为准备计划。

原有能力可迁移的问题新岗位仍需补的证据
优化器与代价分析资源预算、请求路由、是否重算GPU 执行与 KV 传输的测量模型
MV/IVM派生状态、版本、增量覆盖模型状态兼容性和缓存生命周期
向量化与 SIMD数据布局、批处理、算子瓶颈GPU 同步、访存与硬件分析
存算分离状态搬运、分层缓存和故障边界推理尾延迟与阶段容量配比
C++/Java/Rust 工程所有权、并发、接口和维护Python 调度栈及异步设备生命周期

【模板】“在【真实项目及版本】中,我负责【准确边界】。最初判断是【有记录的假设】,随后【测量或反例】迫使我们调整为【真实方案】。我本人完成【可核验部分】,团队其他成员完成【协作部分】;结果在【负载与资源条件】下成立,尚未覆盖【限制】。”

【模板】“我把这个方法迁移到【AI 实验】;对照是【基线】,改动是【单一机制】,观察到【实际结果/尚未测得】。它目前只能证明【证据范围】,不能证明已经具备生产部署经验。”没有结果时保留占位,不把计划改写为成就。

追问:你与纯 AI 背景候选人的差异?用可核对的系统判断和工程结果回答;承认训练、GPU 内核或模型结构中的具体缺口;最先负责哪个模块?选与证据最接近的调度、KV 或运行时边界,并说明接口、验收和协作方,避免一开始承诺重写全栈。

差答:“数据库和推理本质一样”“我有资深职级所以能带 AI 团队”“最近把热门项目都看过”都无法证明岗位匹配。

题 21:入职后第一项验证工作怎么选?

强答要点:先选能形成闭环的问题:有固定基线、有可控变量、有预期失败条件。单卡也可以研究混合长度调度、前缀局部性或图内存开销;没有多机设备就不声称复现了 PD 分离收益。

若岗位偏 Agent,选择带只读和写入工具的最小运行时,验证提交后丢响应、重复执行和沙箱越界;若偏向量系统,选择带真实过滤分布的检索实验,先构造精确真值再比较索引。

实验文档保留环境、版本、输入集合、启动参数、原始结果和否定发现。只写最终最优点会隐藏收益边界;一个证明“不值得上线”的实验,只要条件完整,同样体现技术判断。

追问:如何避免实验变成教程抄写?明确待证伪假设,例如“高前缀复用是否足以抵消热点路由排队”,并设计反例负载;设备不足怎么办?缩小可验证结论,区分模拟和实测;把多机通信或容量预测留作待验证项。

差答:“一个月把所有框架跑一遍”“先做一个全功能 Agent”“只要复现论文最好倍数”都没有收敛范围。

参考与验证:把面试回答落到实验协议

推理实验的最小记录

1模型:权重标识、修订版本、词元化与提示模板、最大上下文
2引擎:版本/提交、后端、量化格式、调度和图执行配置
3设备:GPU 型号与数量、互连、CPU、主存、驱动与运行库
4负载:输入/输出长度分布、到达过程、租户、取消与重试
5缓存:冷启动/热启动、前缀复用比例、各层容量与带宽
6指标:TTFT、ITL、端到端分位数、成功/失败/拒绝/取消
7成本:设备时间、状态传输、CPU 开销、每个成功任务费用
8对照:一次只改变一个机制,再验证组合是否仍有收益

闭环压测会在服务变慢时自然降低发送速度,可能掩盖排队崩溃;固定到达率的开环测试更容易观察过载,但需要正确记录发送失败和积压。两种方式回答不同问题,应在图例写清楚。

Agent 与检索实验的最小记录

1Agent:模型版本、工具定义、任务集、上下文、步骤与费用上限
2执行:权限、网络出口、工作副本、依赖、超时与进程清理
3恢复:超时发生点、幂等标识、状态查询、未知结果与补偿
4评测:可信测试来源、尝试次数、选择规则、人工复核与返工
5检索:快照、维度、距离函数、过滤分布、精确真值与并列规则
6更新:插入、删除、索引覆盖范围、嵌入版本与可见时延
7输出:原始日志、指标计算方式、失败样本与适用范围

新增来源与使用范围

适用边界是系统岗位的技术面与迁移叙事,不覆盖训练算法、完整 GPU 内核开发或某家公司的职级标准。面试前应确定目标岗位最关心的瓶颈,选两条追问链做完可复查实验,填实个人角色与结果,再据此决定哪些能力可以作为已具备经验陈述。