高频面试题

主流模型对比

面试官问 GPT、Claude、Gemini、Llama、Qwen、DeepSeek 怎么选，真正想听的是你的比较框架，而不是背一个很快过期的排行榜结论。

适合阶段：AI 应用开发 / 模型选型面核心能力：Capability Matrix · Benchmark Boundary · Provider Risk

面试官角度分析，想考什么

• 主流 LLM 应该从哪些维度对比？
  考你能否把模型能力拆成可评估维度，而不是只说“GPT 强、Claude 长、Gemini 多模态”。

• 公共 benchmark 和业务 eval 怎么配合？
  考机制差异：榜单适合筛候选，业务评估才决定是否上线。

• 工程上如何降低模型和供应商风险？
  考落地取舍：成本、延迟、限流、上下文、工具调用、合规、抽象层、灰度和 fallback。

可直接抄走的 30 秒参考答案

主流模型对比我不会只背榜单，而是按业务链路拆维度：理解表达、复杂推理、代码、工具调用、结构化输出、长上下文、多模态、检索配套和安全合规，再结合成本、延迟、限流、区域可用性和供应商风险。公共 benchmark 只能帮我筛候选，最终要用自己的 eval case 和线上灰度决策，并通过 provider adapter、fallback 和可回滚配置降低锁定风险。

面试回答详解，知其所以然

这道题的核心不是记住某个时间点的模型排名，而是建立一套不会过期的比较方法。模型版本和价格都会变，但能力拆分、业务评估和供应商治理的逻辑长期有效。

1. 先按任务能力拆比较矩阵

• 通用理解和表达：普通问答、摘要、改写。
• 复杂推理：规划、代码、数学、多步分析。
• 工具调用：工具选择、参数生成、多轮工具链路和错误恢复。
• 长上下文：长文档、长对话、代码库分析。
• 多模态：图片、文档、语音、视频。
• 结构化输出：JSON、表格、枚举、schema。
• 检索配套：embedding、rerank、引用忠实性和知识库问答。
• 安全合规：拒答、敏感信息、区域合规。

常见模型家族可以这样形成初步直觉：

• 闭源旗舰模型：适合复杂推理、多模态、高质量体验和高风险场景，但成本、限流和供应商依赖更高。
• 闭源轻量模型：适合分类、抽取、改写、客服草稿、低成本在线链路。
• 开源模型：适合私有化部署、数据不出域、成本可预测和深度定制，但需要推理运维、模型安全和质量评估能力。
• 专用 embedding/rerank 模型：适合检索链路，不要用 chat 模型替代所有模型角色。

这只是候选筛选，不是最终结论。最终结论必须回到业务 eval。

2. 公共榜单只能筛候选，业务 eval 才能做上线决策

公共 benchmark 有价值，但边界很清楚：它们的任务分布、语言、上下文长度、工具 schema、安全要求和失败成本，未必等于你的业务。

公共榜单筛候选
-> 业务 eval 做对比
-> case diff 找风险
-> 小流量灰度验证
-> 持续重评和回滚

业务评估要同时看质量和工程指标：

• 成本：input/output token 单价、缓存优惠、批处理价格。
• 延迟：TTFT、tokens/sec、稳定性。
• 可用性：限流、SLA、区域、失败率。
• 生态：SDK、工具调用、日志、eval、监控。
• 可迁移性：接口抽象、prompt 兼容、schema 兼容。
• 安全性：越权、泄露、拒答、合规、内容安全。

例如代码榜单高，不代表你的客服工具调用稳定；长上下文强，不代表 RAG 引用忠实；多模态能力好，也不代表在你的证件、票据或工业图片上识别可靠。

3. 工程上要管理供应商锁定和迁移风险

模型对比最后要落到架构治理。生产系统不要把某个 provider 的字段、prompt 写法、工具格式和错误码散落在业务代码里。

• provider adapter：统一模型调用、streaming、tool calling、structured output 和错误类型。
• 能力注册表：记录每个模型支持的上下文长度、模态、工具、价格、区域和限流。
• 模型路由：简单任务走小模型，复杂推理走强模型，检索链路用专用 embedding/rerank。
• fallback 策略：限流、超时、区域不可用时有降级模型或排队机制。
• 迁移评估：切换模型前回放 eval case，重点看格式、工具参数、拒答、安全和 token 成本变化。

面试里最成熟的回答不是“我选某某模型”，而是“我知道怎么比较、怎么上线、怎么替换、怎么回滚”。

面试官追问3个问题

追问一：榜单第一为什么线上不一定好？

• 考察点：业务评估意识。
• 回答方向：榜单任务和业务任务不同。你的场景可能有私有知识、工具调用、长上下文、多轮状态、中文语料、安全红线和延迟预算。榜单第一只能说明它在某组公开任务上表现好，不能证明它在你的链路里工具参数更稳、引用更忠实或成本更合适。

追问二：是否所有任务都用最强模型？

• 考察点：成本和架构能力。
• 回答方向：不是。简单分类、抽取、改写、路由可以用轻量模型，复杂推理、长文档综合和高风险判断再用强模型；embedding、rerank、安全审核也可以用专用模型。前提是每段都有评估和 fallback，不能为了省钱把复杂任务错路由到弱模型。

追问三：模型切换最容易出什么问题？

• 考察点：迁移风险。
• 回答方向：最容易出在 prompt 敏感性、结构化输出差异、工具调用参数、tokenizer 差异、上下文长度、流式事件格式、拒答策略和延迟成本上。切换前要回放 eval case，切换时小流量灰度，发现问题能按模型、prompt、参数和工具 schema 快速回滚。

扩展知识

模型对比表不应只有“效果”

效果 + 成本 + 延迟 + 上下文 + 工具 + 多模态 + 合规 + 可迁移 + 可回滚 = 选型依据

官方模型文档的正确用法

OpenAI Models、Google Gemini Models 等官方页面适合确认模型能力、上下文、模态和接口支持；公共榜单适合观察候选趋势。但最终上线决策应该回到 模型选型与持续重评 里的业务评估集和灰度流程。