主题
高频面试题
模型选型与持续重评面试深挖
面试官追问模型选型，真正想听的是你怎么证明它适合这个业务，以及模型、价格和能力变化后怎么持续重评。
面试官角度分析，想考什么
你为什么选这个模型？评估集怎么构造？
考你能否把选型说成可复现的实验，而不是“我觉得这个模型效果好”。业务链路里是否应该只用一个模型？
考机制差异：意图识别、抽取、工具调用、RAG、最终回复、安全审核可能需要不同模型和不同指标。新模型出来后怎么判断要不要切？
考工程边界：公共 benchmark 只能筛候选，最终要靠业务 eval、灰度、监控、回滚和持续重评。
可直接抄走的 30 秒参考答案
text
模型选型我会先把业务链路拆开，比如意图识别、结构化抽取、工具调用、RAG、最终回复和安全审核。然后用固定业务 eval case 比较多个候选，不只看平均分，还看安全红线、格式错误、工具调用成功率、引用忠实性、成本、延迟和 case 级回归。上线后通过 trace、灰度和 badcase 回放持续重评；新模型出来也先离线评估、小流量验证，再决定是否切换和如何回滚。面试回答详解，知其所以然
这道题的核心不是回答“哪个模型最好”，而是展示你有一套可复现、可回滚、可持续演进的选型方法。模型能力变化很快，靠一次主观体验做架构决策，很容易在生产里翻车。
1. 先拆业务链路，再定义每段指标
不要只评最终答案。一个 AI 应用通常可以拆成多段：
- 意图识别
- 槽位抽取
- 工具调用
- RAG 检索与引用
- 复杂推理或规划
- 安全合规
- 最终回复
- 前端体验
每段的指标不同，适合的模型也可能不同：
- 分类/抽取：看准确率、格式错误率、延迟和成本，小模型可能更划算。
- 工具调用：看工具选择、参数生成、错误恢复和权限遵守，不只看文字质量。
- RAG 问答：看引用忠实性、拒答率、召回依赖和答案可读性。
- 复杂推理：看多步正确率、代码/数学能力、长上下文利用和可解释 trace。
- 安全审核：看漏拦、误拦、一票否决项和人工复核成本。
所以成熟方案常常不是“一个最强模型包打天下”，而是强模型、小模型、embedding、reranker、guardrail 模型一起组成链路。
2. 用业务评估集做决策，而不是只看公共榜单
评估集至少包含：
- 正常 case
- 边界 case
- 历史 badcase
- 高风险 case
- 多轮上下文 case
- 权限和安全 case
公共 benchmark 适合缩小候选池，但不能代替业务 eval。榜单任务、语言分布、上下文长度、工具 schema、输出格式和失败成本，往往都和你的产品不同。
评估时可以按这个顺序设门槛：
text
安全红线 -> 任务质量 -> 格式和工具成功率 -> 成本/延迟 -> 可用性 -> 可迁移性能规则判的部分优先程序化，比如 JSON schema、字段范围、权限、引用是否存在；开放文本再用 LLM-as-Judge 和人工抽检。严重问题要 case 级分析，不能让平均分掩盖越权泄露、错误工具调用、高风险幻觉这类一票否决项。
3. 上线后要灰度、监控和持续重评
模型选型不是一次性结论。模型版本、价格、限流、上下文能力、工具调用能力和业务数据都会变化，所以要把重评机制设计进系统：
- 离线对比：固定评估集回放，输出 case diff，而不是只看总分。
- 小流量灰度：按用户、租户、场景或任务类型逐步放量。
- 线上监控：看成功率、人工修正率、拒答率、成本、TTFT、超时、工具失败和投诉反馈。
- 快速回滚：模型、prompt、参数、工具 schema 都要能回到上一版。
- 定期重评：把线上 badcase 加回评估集，防止“新模型更强但某些关键场景退化”。
如果面试官问“为什么不用榜单第一”，可以回答：榜单决定候选，业务 eval 决定上线，线上灰度决定是否扩大使用。
面试官追问3个问题
追问一：业务 eval case 数量要多少？
- 考察点：评估设计。
- 回答方向：没有固定数字，关键是覆盖面和更新机制。早期可以用几十到几百条覆盖核心路径、边界条件、高风险场景和历史 badcase；成熟后持续从线上 trace、用户反馈和人工修正里补充。高风险业务宁可样本少但标注准，也不要堆一批没有判定标准的样本。
追问二：LLM-as-Judge 可靠吗？
- 考察点：评估可信度。
- 回答方向：适合开放文本质量、引用忠实性、语气和完整性的初筛，但不能无校准地当唯一真相。能规则判断的先程序化，比如 schema、权限、字段范围；judge prompt 要版本化，并用人工标注小集校准一致性。关键上线决策最好保留人工抽检。
追问三：什么时候切新模型？
- 考察点：上线流程。
- 回答方向：当离线评估在目标场景有明确收益，没有安全和格式回归，成本、延迟、限流和合规都可接受时，才进入小流量灰度。灰度期间要看 case 级 diff 和线上指标，不是只看平均分；同时保留旧模型、旧 prompt 和旧参数的快速回滚。
扩展知识
评估维度示例
text
准确率 / 格式错误率 / 工具调用成功率 / 引用忠实性 / 安全违规率 / TTFT / token 成本公共 benchmark 的定位
公共榜单适合缩小候选池，业务 eval 才适合做最终决策。它们是上下游关系，不是替代关系。
官方资料里的共同建议
OpenAI Evals强调用评估集系统比较模型、prompt 和工具链路；Google Gemini Models和各家模型文档都会持续更新能力、上下文、模态和价格。面试里要承认模型能力是动态变化的，所以答案应该是“持续重评机制”，不是一个静态模型名单。