模型能力与 API 接入

共 41 题
📑 题目列表 41 题
#
★★★

1. 如何基于质量、首 Token 延迟、总延迟与成本选择通用模型或推理模型

在接入多个模型供应商时,如何根据任务特征在通用模型与推理模型(reasoning model)之间做选择,并综合质量、首 Token 延迟、总延迟与成本四个维度进行权衡?

  • 理解通用模型与推理模型在推理深度、延迟与成本上的本质差异
  • 能按任务类型(简单抽取、复杂推理、代码、创意)建立选型决策
  • 能将延迟、成本、质量转化为可量化的业务指标

通用模型(如 GPT-4o、Claude 中速档)在普通任务上延迟低、成本低,适合即时交互;推理模型(如 o3、DeepSeek-R1、Claude 高思考档)会把大量 token 用于"思考",首 Token 延迟(TTFT)明显更高、总延迟与成本也更高,但复杂推理任务的准确率更高。选型应建立"任务-能力"映射:对准确性可接受、追求低延迟的任务(分类、抽取、改写、摘要)用通用模型;对需要多步推理、数学、代码排错、复杂规划的任务用推理模型。同时要预设"路由"机制:同一调用先尝试轻模型,置信度不足时升级到推理模型(级联路由),并结合业务对 p99 延迟与单次成本预算的约束做出决策。

核心是不要"一刀切"。推理模型的价值在"想得多",但代价是"慢且贵"。选择时应先明确业务目标:是交互体验(延迟敏感)还是答案质量(正确率敏感)。用成本-质量曲线与延迟预算两个约束交叉决定,并用量化评估(如任务级准确率、错误率、每千次调用成本)持续校准,而不是凭印象。

public ModelChoice chooseModel(TaskType task, LatencyBudget budget, CostBudget cost) {
    if (task.requiresMultiStepReasoning() && budget.allowReasoning()) {
        return ModelChoice.REASONING_MODEL;   // 推理模型
    }
    return ModelChoice.GENERAL_MODEL;          // 通用模型
}
#
★★★

2. 如何设计 Provider 适配层,同时保留 OpenAI Responses、Anthropic Messages 与 Gemini generateContent 的差异化能力

如何设计一个 Provider 适配层,用统一的抽象模型表达请求与响应,同时不丢失 OpenAI Responses、Anthropic Messages、Gemini generateContent 各自的私有能力(工具调用、结构化输出、缓存、视觉、思考控制等)?

  • 理解"统一抽象 + 能力矩阵 + 原样透传"的设计思路
  • 能区分"通用字段"与"私有扩展字段",避免最低公分母
  • 能设计能力协商与降级机制

适配层应包含三层:一是统一的内部消息模型(SystemMessage/UserMessage/AssistantMessage/ToolMessage 及内容块 ContentBlock),二是能力矩阵(CapabilityMatrix),三是"扩展透传"通道(extraParams / raw overrides)。通用能力(文本、多轮、工具调用)映射到统一字段;私有能力(如 OpenAI 的 web_search tool、Anthropic 的 citations、Gemini 的 thinkingConfig)通过名值对透传并在能力矩阵中声明。每个 Provider 适配器负责"内部模型 -> 该 Provider 请求体"与"该 Provider 响应体 -> 内部模型"的双向转换,并填充能力矩阵。业务层只面向内部模型与能力矩阵编程,需要私有能力时先查能力是否支持,不支持则降级。

常见错误是只保留所有 Provider 都有的字段,导致 OpenAI 的 web_search、Anthropic 的 tool_use 专属语义被丢弃。正确做法是"尽可能统一,必要时透传":统一层保证可移植,透传层保证能力不丢失。能力矩阵成为运行时决策依据,配合契约测试锁定两层转换正确性。

type Provider = "openai" | "anthropic" | "gemini";
interface CapabilityMatrix {
  toolCall: boolean;
  structuredOutput: boolean;
  webSearch: boolean;
  citations: boolean;
  thinking: boolean;
}
// 透传私有字段:不落入统一模型,按 Provider 原样下发
const geminiTools = { ...commonTools, ...{ webSearch: { dynamicRetrieval: {} } } };
#
★★★

3. 一条包含 system、user、assistant、tool 消息的请求从前端到模型再返回,完整生命周期和责任边界是什么

描述一条包含 system、user、assistant、tool 消息的完整请求从前端经过业务服务、模型网关到模型再返回的过程,并明确每一层的责任边界?

  • 理解四类消息在流程中的角色与来源
  • 能划分前端、业务服务、网关、模型、审计各层职责
  • 理解工具调用(tool_use/tool_result)的循环过程

生命周期:前端采集用户输入并携带会话上下文 -> 业务服务组装 system 指令(产品规则、安全护栏)、user 消息(用户输入与 RAG 证据)、历史 assistant 消息(多轮上下文),必要情况下把前端请求的工具结果作为 tool 消息注入 -> 模型网关做鉴权、限流、路由、模型选择并调用模型 -> 模型返回 assistant 消息(可能含 tool_use 请求)-> 业务服务执行工具并回填 tool 结果 -> 再次调用模型直到无 tool_use -> 最终 assistant 内容返回前端。责任边界:前端负责会话展示与输入;业务服务负责 Prompt 组装、工具执行、状态与校验;网关负责路由、限流、重试、计费与可观测;审计负责记录输入输出与决策依据;模型负责根据上下文生成 token。

关键点是工具调用是一个循环而非一次往返。system 是业务方注入的"规则",user 是真实输入,assistant 是历史事实,tool 是工具结果回填。任何一层越权或缺失都会破坏上下文一致性。责任边界决定了"谁负责校验、谁负责安全、谁负责计费"。

List<Message> messages = new ArrayList<>();
messages.add(system(systemPrompt));       // 业务规则
messages.addAll(history);                 // 历史 assistant/user
messages.add(user(prompt, evidence));     // 输入 + RAG
// 工具调用循环
while (resp.hasToolCalls()) {
    for (ToolCall tc : resp.getToolCalls()) {
        messages.add(assistant(tc));
        messages.add(tool(tc.getId(), toolExecutor.run(tc)));
    }
    resp = model.call(messages);
}
#
★★★

4. OpenAI Responses API、Anthropic Messages 与 Gemini generateContent 在多轮对话状态、缓存键和工具调用上下文上有什么不兼容设计,跨 Provider 抽象如何避免双计费与状态错位

分析三个主流 Provider 在多轮对话状态、缓存键、工具调用上下文上的不兼容设计,并说明跨 Provider 抽象如何避免双计费和状态错位?

  • 理解各 Provider 工具调用消息格式差异(tool_use id、tool_call id、functionCall)
  • 理解缓存键与"前向稳定前缀"的绑定关系
  • 能设计状态归一化与幂等,避免重复计费

不兼容点:一是工具调用标识不同——OpenAI 用 tool_call_id + function/tool,Anthropic 用 tool_use/tool_result 成对 id,Gemini 用 functionCall/functionResponse 配对;二是多轮状态中 assistant 消息是否要携带 tool_use 保持一致;三是缓存键由 token 前缀决定,不同 Provider 的缓存粒度(5 分钟 TTL vs 长保留)不同,且任何字节变化都会导致缓存失效。跨 Provider 抽象应建立统一的工具调用序列(id + 名称 + 参数 + 结果),由适配器映射到各 Provider 格式;同时维护"会话视图"而非"某 Provider 的原始消息"——Failover 时用统一视图重新序列化到目标 Provider,避免把 OpenAI 的 tool_call 原样塞给 Anthropic 造成状态错位。计费方面,以统一会话 id 为幂等键,重试与 Failover 时复用同一逻辑 id,避免同一次工具调用被两个 Provider 分别计费。

核心是"格式归一化 + 幂等键"。"状态错位"指切换 Provider 后消息序列无法正确还原工具调用链;"双计费"指同一逻辑请求因重试或切换被重复计费。统一视图是避免两者的关键,缓存键则要意识到 Provider 之间不可复用。

#
★★★

5. 同步、流式、异步任务与批处理分别适合哪些业务,取消和结果领取协议应如何设计

对比同步、流式、异步任务与批处理四种调用模式分别适合哪些业务场景,并设计各自的取消与结果领取协议?

  • 理解四种模式的延迟特征与适合场景
  • 能设计轮询/回调/Webhook 的结果领取方式
  • 能设计幂等取消与结果留存的协议

同步:适合短、快、对响应时间敏感的场景(简单分类、翻译),调用方阻塞等待;流式:适合需要即时反馈的交互(聊天、流式补全),通过 SSE 逐 token 返回;异步任务:适合耗时长或不确定的调用(长文生成、批量任务),创建任务后返回 task_id,客户端轮询或订阅 Webhook 领取结果;批处理:适合离线、大批量、延迟不敏感的需求(批量分类、离线摘要),提交作业后集中处理。结果领取协议:同步/流式直接在响应中返回;异步用 task_id + 状态查询接口(pending/running/succeeded/failed),或注册回调 Webhook 推送结果;结果需短期留存(如 24h)供重复领取。取消协议:异步任务必须支持"取消"请求,取消需幂等(同一 task_id 取消失败也不重复计费),并要求 Provider 侧真正中止生成,避免 cancel 后仍继续计费。

模式选择取决于"延迟预期"与"是否需要即时反馈"。取消协议的核心是幂等与"真正停止计费"——仅标记客户端取消还不够,要向 Provider 发取消请求。结果领取要支持"至少一次"语义,客户端可重复查询。

#
★★★

6. 如何通过模型网关、能力矩阵和契约测试实现 Provider 可替换,而不是只做“最低公分母”封装

如何通过模型网关、能力矩阵和契约测试实现 Provider 的可替换性,并避免退化成"最低公分母"封装?

  • 理解网关路由与能力矩阵的作用
  • 理解契约测试如何锁定适配层正确性
  • 理解"可替换"与"保留差异"的平衡

三层配合:一是模型网关作为统一入口,负责模型选择、路由、限流、计费与故障切换,业务不直接依赖具体 Provider;二是能力矩阵显式声明每个 Provider 支持的能力(工具、结构化输出、视觉、缓存、私有能力),业务按能力查表决定是否调用,避免把私有能力写死;三是契约测试(Contract Test)为每个适配器定义"统一请求 -> 各 Provider 请求体"与"各 Provider 响应体 -> 统一响应"的双向 golden 用例,并在 CI 中持续运行,Provider 升级或新增时自动回归。这样"可替换"体现在:切换 Provider 时只需新增/替换适配器并跑通契约测试,业务层零改动;"非最低公分母"体现在:能力矩阵与透传通道保留了各 Provider 的强项,业务按需使用。

"最低公分母"是只保共有能力的简化,导致浪费强能力。正确做法是"统一抽象 + 能力协商 + 契约验证"。契约测试是防漂移的关键,它把"两句转换"固化为可执行断言,防止某 Provider 更新导致隐性破坏。

#
★★★

7. 模型调用中的超时、重试、幂等、断路器、隔离与降级如何协作,哪些错误绝不能盲目重试

说明模型调用中超时、重试、幂等、断路器、隔离与降级如何协作,并指出哪些错误绝不能盲目重试?

  • 理解六类机制各自负责的故障类型
  • 能识别可重试与不可重试错误
  • 理解重试与幂等、断路器、降级的协作关系

超时:为连接、首 token、总调用分别设置超时,防止悬挂;重试:对可重试错误(网络抖动、429 限流、5xx 瞬时故障)按指数退避 + 抖动重试,重试次数设上限;幂等:重试时要能识别原请求,避免同一请求被重复计费(对账单、工具调用要带幂等键);断路器:当某 Provider 连续失败达到阈值时,快速熔断,停止向其发送请求,让其恢复;隔离:按租户/任务/模型维度隔离限流与故障,避免一个租户的突发拖垮全部;降级:熔断后降级到备用模型、缓存结果或报错给用户。绝不能盲目重试的错误:认证失败(401)、鉴权不足(403)、请求非法(400,参数/格式错误)、内容被拒(如内容策略拦截)、模型不存在(404)、超限后若限流为永久性(如配额永久耗尽)等——这些重试不会成功,反而浪费资源与成本。

六机制是协作的"故障处理链":超时兜底、重试处理瞬时、断路器防雪崩、隔离防扩散、降级保可用。重试的关键是"错误可重试性分类",把 4xx 业务错误与 5xx/网络瞬时错误区分开。幂等是重试的前提,否则重试即双计费。

#
★★★

8. 模型快照弃用(snapshot deprecation)与下线(shutdown)时,应用应如何提前迁移并平滑过渡到新快照?

当 Provider 弃用某个模型快照或整体下线时,应用应如何提前迁移并平滑过渡到新快照,避免业务中断?

  • 理解快照、别名与弃用周期的概念
  • 能设计灰度迁移与影子流量验证
  • 能处理行为差异带来的回归

做法:一是"别名而非写死快照"——应用代码引用模型别名(如 gpt-4o 的当前稳定快照),由平台侧维护别名到具体快照的映射,弃用公告发布后只改映射即可;二是提前监控弃用公告——订阅 Provider 的 snapshot deprecation 通知,建立"弃用倒计时";三是影子流量验证——在弃用窗口内把生产流量复制到新快照上做影子对比,比较质量、延迟、成本;四是灰度迁移——按租户/流量百分比逐步切换,设置自动回滚阈值;五是兼容窗口——弃用前保留足够时间(通常几周)让下游完成迁移,Provider 的 shutdown 是不可逆的,务必在最后日期前完成;六是回归测试——用同一评估集比较新旧快照输出,识别行为变化。

核心是"不写死快照 + 提前灰度 + 影子验证"。弃用公告是倒计时信号,应用必须把"迁移"当工程任务管理,而不是等到下线当天才发现。平滑过渡的关键是"重叠期"验证,让新旧快照并行一段时间。

#
★★★

9. 私有部署、开源权重与商用 API 在 SLA、合规、可观测性、可控参数和故障责任上如何做选型矩阵

从 SLA、合规、可观测性、可控参数、故障责任五个维度,为私有部署、开源权重、商用 API 三种形态建立选型矩阵?

  • 理解三种形态在可控性与运维成本上的差异
  • 能从合规、延迟、成本、责任角度做权衡
  • 能建立可复用的选型决策框架

商用 API:SLA 由 Provider 约定(如 99.9%),合规与数据驻留受 Provider 约束,可观测性受限于 Provider 暴露的 usage/延迟指标,可控参数限于 API 暴露的子集,故障责任在 Provider(但需自我监控与降级)。私有部署(自建推理):SLA 完全自控但需自建高可用,数据不出域、合规可控,可观测性最强(GPU、TTFT、TPOT 全量可采),可控参数最多(解码、并发、量化),故障责任全在自身。开源权重:介于两者之间,可用 API 或自部署,权重可审计、可微调,但运维门槛与责任在自身。选型矩阵:数据敏感/合规严格 -> 私有部署;延迟敏感且有算力 -> 私有部署;低成本流量 -> 商用 API;需要满量可观测与调参 -> 私有部署;无运维能力 -> 商用 API。混合架构常见:敏感数据本地、通用数据云端。

这是"控制权 vs 运维成本"的权衡。商用 API 省运维但让出控制权;私有部署拿回控制权但要承担 SLA 与故障责任。选型矩阵应把业务对数据驻留、延迟、成本、运维能力的真实需求映射到三种形态。

#
★★★

10. Function Calling 中并行调用与顺序依赖在 Responses、Anthropic、Gemini 上是否被同等支持,如何在抽象层表达依赖图

分析 Function Calling 中并行调用与顺序依赖在 OpenAI Responses、Anthropic Messages、Gemini generateContent 上是否被同等支持,并说明如何在抽象层表达工具依赖图?

  • 理解各 Provider 对多工具并行调用的支持差异
  • 能设计统一工具调用模型与依赖图表达
  • 理解"顺序依赖"如何在消息序列中自然表达

三个 Provider 都支持一次请求返回多个工具调用(同一轮 message 中可含多个 tool_use/tool_call),因此在"并行"层面基本等价——模型可一次性声明多个需要执行的工具。但"顺序依赖"(工具 B 依赖工具 A 的结果)并非 Provider 原生表达,而是通过消息序列的"回合"自然体现:先执行 A,把 A 的结果作为 tool 消息回填,再请求模型,模型拿到 A 结果后再发起对 B 的调用。抽象层应把工具调用建模为"工具调用序列 + 每个调用的输入参数与结果",由应用层编排执行顺序;如果要表达复杂的依赖图,可在调用前用循环决定"哪些工具已就绪、哪些需等待前置结果",把依赖关系转化为就绪集合(ready set)的迭代。契约测试验证各 Provider 是否在同一轮返回多个 tool_use。

关键认知:并行调用是 Provider 原生支持的(同一轮多个调用),顺序依赖是应用层用"多轮消息"实现的,不是 Provider 特性。抽象层只需保证工具结果的 id 映射正确,就能串联任意依赖 DAG。

#
★★★

11. 如何在启动期和运行期探测视觉、工具调用、结构化输出等能力,并应对 API 版本漂移

如何设计能力探测机制,在启动期与运行期探测视觉、工具调用、结构化输出等模型能力,并应对 API 版本漂移?

  • 理解能力探测的两种时机(启动/运行)
  • 能应对 Provider 能力或版本变化导致的漂移
  • 能设计能力缓存与动态更新

启动期:通过 Provider 的 models 列表接口、能力清单文档或本地配置声明,预估模型能力(是否支持视觉、工具、JSON);运行期:通过实际调用与错误反馈动态校准——例如对结构化输出,调用后校验 schema 通过率,失败则降级为自由文本 + 解析;对工具调用,若返回格式异常则降级。应对版本漂移:把能力声明做成"版本化能力契约",CI 定期拉取 Provider 公告并比对;运行期用"能力假设 + 校验兜底"——不假设能力永远存在,每次使用前校验、失败时降级并记录。能力缓存要带版本号与过期策略,避免把过期能力当现状。

能力是会变的(Provider 升级、新模型、弃用)。启动期探测给"初始假设",运行期校验给"实际反馈",两者结合才能在漂移时仍可用。核心是"永远不把能力当永久假设,失败即降级"。

#
★★★

12. 多 Provider Failover 切换时,在途会话状态(消息序列、工具调用上下文)应如何转换为目标 Provider 的消息格式,防止状态错位与重复计费

描述多 Provider Failover 切换时,如何把在途会话状态(消息序列、工具调用上下文)转换为目标 Provider 的消息格式,防止状态错位与重复计费?

  • 理解统一会话视图与 Provider 格式转换
  • 理解 tool 调用 id 的映射与重放
  • 能设计幂等与去重

做法:一是维护"统一会话视图"(conversation view),在途状态以中立格式(内部消息模型)保存,不依赖任何 Provider 的原始格式;二是 Failover 时用目标 Provider 的适配器把统一视图重新序列化——包括把工具调用 id、结果按目标格式重写(如把 OpenAI 的 tool_call 映射为 Anthropic 的 tool_use 对);三是工具调用上下文要完整保留"哪次 assistant 调用、对应哪个工具结果",避免乱序;四是幂等与去重——每个逻辑请求带唯一 request id / 幂等键,重试与 Failover 复用同一 id,避免同一工具执行被两个 Provider 重复计费;五是工具执行本身要幂等(工具结果可安全重放),失败时才有重试余地。

"状态错位"源于把 Provider A 的原始消息直接塞给 Provider B;"重复计费"源于无幂等键的重试。统一视图 + 适配器重序列化 + 幂等键三者缺一不可。

#
★★★

13. 模型 API 配额(RPM/TPM/并发)的容量规划应如何从业务峰值推算,并为重试与流式长连接预留余量

说明如何从业务峰值推算模型 API 配额(RPM/TPM/并发)的容量规划,并为重试与流式长连接预留余量?

  • 理解 RPM/TPM/并发三种配额的含义
  • 能由业务流量与 token 规模推算需求
  • 能预留重试、流式与突发余量

步骤:一是估算峰值 RPM——从业务峰值 QPS 与"每请求平均调用模型次数"(含工具循环)相乘得到;二是估算 TPM——峰值请求数 × 每请求平均输入 + 输出 token;三是估算并发——流式请求会长时间占用连接,并发 = 峰值期间同时活跃的流式连接数,需结合"每请求时长 / 平均间隔"用利特尔定律(并发 = 吞吐 × 服务时长)估算;四是预留余量——为重试(摩擦系数 1.2~1.5)、流式长连接(连接占用时间远大于请求往返)、突发流量(如营销活动峰值)预留 30%~50% 余量;五是按区域/模型分别规划,避免单一配额成为瓶颈。容量规划还要与 Provider 的限流机制配合,避免估算超限导致 429。

关键点:并发 ≠ 吞吐,流式长连接使并发需求远高于同步请求;TPM 受输入输出 token 影响,需精确估算;余量是必须的,否则在重试与突发下会触发限流。用利特尔定律做并发估算,用峰值 × 系数做 RPM/TPM 估算。

#
★★★

14. Qwen3 Hybrid Thinking、Anthropic Extended Thinking、OpenAI reasoning effort 等思考控制为何不能使用统一固定参数

解释 Qwen3 Hybrid Thinking、Anthropic Extended Thinking、OpenAI reasoning effort 等"思考控制"为何不能用统一固定参数,应如何设计抽象?

  • 理解各 Provider 思考控制机制的本质差异
  • 理解思考档位与 token 消耗的关系
  • 能设计"思考档位语义"抽象而非机械映射

原因:各 Provider 的思考控制机制机制不同——Qwen3 Hybrid Thinking 是"是否开启混合思考"的开关,Anthropic Extended Thinking 用 budget_tokens 控制思考 token 预算,OpenAI reasoning effort 用 low/medium/high 档位控制推理强度。它们不是同一参数的不同取值,而是不同的控制维度(开关 vs 预算 vs 档位),且默认值、是否影响输出 token、是否单独计费都不一样。若用统一固定参数,会丢失语义差异(例如把"medium"硬映射到某预算数字无意义)。正确做法:抽象出一层"思考档位"语义(如 off/low/medium/high),由各 Provider 适配器把该语义映射为各自的原生参数(off=Hybrid 关闭 / effort=low / budget 小),并透传私有细化字段。业务层按"思考强度意图"编程,而不是按具体参数编程。

核心是"语义抽象 vs 参数透传"。统一的是"意图"(思考强度),而非"变量名"。不同 Provider 的机制属于不同维度,只有先抽象语义再映射才可移植。

#
★★★

15. 为何在 spec 文件中写死带日期后缀的模型快照 ID(如 gpt-4o 的旧快照、preview 版本)是危险做法,模型别名加版本范围策略应如何设计

解释为什么在配置文件或代码中写死带日期后缀的模型快照 ID(如 gpt-4o 旧快照、preview 版本)是危险做法,并设计"模型别名 + 版本范围"策略?

  • 理解快照 ID 会随弃用变化
  • 理解 preview 版本的不稳定性
  • 能设计别名与版本范围管理

危险原因:快照 ID 通常带日期后缀标识具体版本,Provider 会弃用旧快照(snapshot deprecation),写死可能导致下线后调用失败;preview 版本不稳定,可能随时变化或下线,且行为与稳定版不同。策略:一是"别名 + 版本范围"——业务代码引用语义别名(如 stable、lite、reasoning),平台维护别名到具体快照 ID 的映射,并声明"允许的版本范围"(如 >= 某基准);二是发布/配置中心管理别名映射,弃用公告触发自动更新映射并走灰度;三是 CI 校验 spec 中不含裸快照日期 ID,强制使用别名;四是版本范围策略设"上限"防止追踪到未验证的新版本,设"下限"防止落后到已弃用版本。

写死快照 ID 是把"Provider 的生命周期"耦合进代码,弃用即崩溃。别名做解耦,版本范围做约束,两者让快照升级平滑、可控。

#
★★★

16. 如何建立"模型能力评估卡",推理、指令遵循、多轮一致性、幻觉率如何量化对比?

如何建立可对比的"模型能力评估卡",把推理、指令遵循、多轮一致性、幻觉率量化,用于模型选型与对比?

  • 理解各维度量化的评估方法
  • 能建立固定评估集与指标
  • 能区分客观指标与人工评估

量化方法:一是推理——用推理基准集(数学、逻辑、代码)计算正确率;二是指令遵循——构造带约束的指令任务,度量"是否严格遵循格式/长度/约束"的通过率;三是多轮一致性——在多轮对话中询问同一事实,度量前后回答是否一致(一致性通过率);四是幻觉率——用有标准答案的 RAG 任务,度量"输出是否忠实于证据"(忠实度/幻觉率)。评估卡要素:固定评估集(同一批题目)、固定评测脚本(固定 seed/参数/模型版本)、客观指标(准确率、F1、通过率)+ 关键样例人工复核、每项指标的成本与延迟。评估卡用于对比不同模型,也用于跟踪同一模型版本漂移。幻觉率常需"证据可验证"的评测集,用 ground-truth 或人工标注判定。

评估卡的本质是"标准化、可复现、可对比"。四个维度需要不同评测手段:推理用客观对错,指令遵循用约束检查,多轮一致性用一致性检查,幻觉用证据忠实度。评估集固定是关键,否则无法比较。

#
★★

17. 账单核对与单任务成本归集应如何补偿

说明账单核对与单任务成本归集应如何"补偿"(对账差额、缓存、重试等导致的成本偏移)?

  • 理解账单与本地 usage 记录差异的来源
  • 能设计对账与补偿机制
  • 理解成本归集的粒度

差异来源:缓存命中(本地预估值高于实际扣费)、重试(同一任务多次调用)、Provider 计价规则变化、流式/思考 token 波动。补偿做法:一是以"任务/请求级 usage 记录"为基准,本地记录每次调用的输入输出、缓存命中、思考 token、重试次数;二是周期对账——把 Provider 账单与本地 usage 聚合比对,对差异设容差阈值并告警;三是对有差异的项追溯补偿——如缓存命中应对应减少预估成本,重试应归并到同一逻辑任务;四是成本归集按"业务任务"聚合(一个任务可含多次调用与工具循环),而非按单次请求,便于向租户透明分摊。补偿本质是"把成本落在正确的逻辑单元上,并对账差异项做归因与修正"。

单任务成本归集的关键是"从请求级提升到任务级",否则工具循环、重试、缓存会让同一任务被拆散。对账补偿则是把 Provider 计费与本地记录对齐,处理缓存、重试带来的偏差。

#
★★

18. Provider 区域实例(region/data residency)如何与可用区、Tier、价格、速率限制相关联,应用层是否需要做实例选择

说明 Provider 区域实例(region/data residency)如何与可用区、Tier、价格、速率限制关联,以及应用层是否需要做实例选择?

  • 理解 region、可用区、Tier、价格、限流的关联
  • 理解数据驻留(data residency)约束
  • 判断应用层是否应选择实例

关联:不同 region 决定数据驻留位置(合规要求)、价格(不同区域价差)、速率限制(不同区域配额独立)、延迟(就近实例延迟低)。Tier(如标准/高吞吐)关联价格与限流。可用区决定同区域内高可用。应用层是否需要实例选择:多数情况下由网关/路由层按"数据驻留"与"就近"静态选择即可,无需业务层关心;但当合规要求数据必须落在特定 region、或需要按区域做成本/限流优化时,应用层应通过配置声明"允许的 region 集合",由网关在执行时选择。应用层应缓存 region 元数据(价格、限流、可用性),但把"选哪个实例"作为基础设施决策,而非业务逻辑。

region 选择主要是"合规 + 延迟 + 成本"的决策,通常应由网关/平台层做,业务层只声明约束(budget、region 白名单)。应用层不应硬编码实例,而应声明式约束 + 让路由层决策。

#
★★

19. 当多种消息类型组合处理时,应用层应怎样设计优先级与防"p99 突增"机制

当多种消息类型(实时交互、批量、异步、低优先级)并发组合时,应用层应如何设计优先级与防 p99 突增机制?

  • 理解优先级队列与调度
  • 理解防止长尾延迟(p99)突增的手段
  • 能设计限流、队列与抢占

做法:一是按消息类型/租户/Tier 建立优先级队列,低优先级任务(批量、离线)使用独立队列,避免与实时请求争抢;二是并发池隔离——高优先级(实时)与低优先级(批量)使用不同的执行器/连接池,低优先级不得占用高优先级额度;三是限流与排队——按优先级设置限流阈值,突发时低优先级先排队或被拒绝;四是防 p99 突增——设置显式超时与调度上限,避免个别慢请求占满线程;用加权/剥离策略在队列超长时丢弃或降级低优先级;五是监控每个优先级队列的 p99 并告警,超过阈值时自动降级。核心是"队列隔离 + 配额 + 超时 + 监控"。

防 p99 突增的关键是"隔离"——不要让慢/重的低优先级任务拖累实时请求。优先级队列 + 独立并发池 + 显式超时是标准组合。监控 p99 而非均值,才能发现长尾。

#
★★

20. 如何在路由层抽象不同推理深度参数,避免下游业务硬编码

如何在路由层抽象不同推理深度参数(如温度、思考档位、模型强弱),避免下游业务硬编码?

  • 理解推理深度参数的抽象层次
  • 理解路由层与业务解耦
  • 能设计"意图式"参数

做法:路由层定义"意图层面"的抽象参数——如 quality(质量档位:fast/balanced/high)、thinking(思考强度:off/auto/high)、speed(延迟档位),由路由层映射到具体模型的 temperature、reasoning effort、模型选择。业务层只声明"我要什么档位",不关心具体参数值。路由层维护"档位 -> (模型, 参数)"的路由表,可独立调整(如把 high 档从模型 A 切到模型 B,或调 temperature),业务无感。把温度、思考、模型强弱这些"推理深度"统一收敛为少量语义档位,可避免业务散落硬编码并在模型升级时集中调整。

抽象的意义是"业务声明意图,路由决定实现"。推理深度参数集中到路由层,业务只传档位,升级/调参集中一处,避免散落。

#
★★

21. 如何把 system、user、assistant、tool 四类消息的拼接顺序固化为契约,防止跨版本回归

如何把四类消息的拼接顺序固化为一套契约,防止跨版本回归?

  • 理解消息顺序契约的重要性
  • 能设计契约测试与构造器约束
  • 理解顺序对缓存与质量的影响

做法:一是定义"消息组装的唯一入口"——提供受约束的构造器(如 PromptBuilder),只允许按固定顺序追加:system(可选基础指令)-> 历史(user/assistant 交替)-> 当前 user -> 工具结果(tool 紧跟对应 assistant 的 tool_use)-> 预留输出;二是用契约测试锁定顺序——golden 用例断言"给定输入序列,生成的 messages 数组严格符合预期顺序",在 CI 中回归;三是把顺序规则写成文档化契约(schema),并校验"tool 消息必须紧跟其对应的 assistant tool_use 消息"、"system 必须位于最前"等不变量;四是任何顺序变更必须走契约版本升级,避免静默破坏。

消息顺序是缓存的键因子,也是模型理解的上下文组织方式。把顺序固化为构造器 + 契约测试,可防止后续改代码时无意破坏顺序导致质量回归或缓存失效。

#
★★

22. 推理模型隐藏 thinking 字段时,应用层怎样反向估算真实成本并按租户透明分摊

当推理模型隐藏 thinking 字段(不返回思考 token 明细)时,应用层如何反向估算真实成本并按租户透明分摊?

  • 理解思考 token 隐藏时的估算方法
  • 能设计成本估算与分摊
  • 理解透明披露

做法:一是当 usage 中不暴露 thinking token 时,用"总 usage 与可见 input/output 的差额"估算思考 token——若 API 返回总 token 数,可用 granted thinking budget 或历史采样建立"思考 token 占比"模型;二是用固定采样建立回归——对抽样请求记录实际总成本与输入输出,拟合思考 token 的估算公式;三是按租户分摊——把估算的思考 token 成本按请求归属到租户,并标记为"估算值";四是透明披露——在租户账单中区分"可见 token 实际成本"与"思考 token 估算成本",标注估算方法与误差范围,避免争议;五是持续校准——用实际账单回填估算参数,缩小偏差。

隐藏思考字段时无法精确计费,只能估算。核心是"采样校准 + 差额反推 + 透明标注"。直接把估算值当精确值会误导租户,必须披露估算性质。

#
★★

23. Provider 快照弃用公告应如何自动捕获并触发内部影子流量验证,避免上线即崩

如何自动捕获 Provider 快照弃用公告,并触发内部影子流量验证,避免新快照上线即崩?

  • 理解弃用公告的自动捕获
  • 理解影子流量验证流程
  • 能设计自动回滚与门禁

做法:一是订阅 Provider 的弃用公告(RSS/邮件/API/变更日志),用定时任务抓取并解析出"快照 ID、弃用日期、替代快照";二是把公告写入能力契约库并触发告警与工单;三是自动创建"影子流量验证"——在弃用窗口内,把生产流量复制到替代快照,比较输出质量、延迟、成本、错误率;四是验证通过才允许切换(灰度),设置有质量阈值的自动回滚门禁;五是若验证在弃用前未完成,保留手动阻断机制。核心是"公告 -> 自动验证 -> 灰度门禁",把"上线即崩"变成"验证后再切换"。

弃用是时间敏感事件,人工发现往往太晚。自动捕获 + 影子验证 + 灰度门禁把"被动"变"主动",在弃用前完成验证,避免新快照上线后才发现行为差异。

#
★★

24. Region 实例与可用区差异如何影响跨区域灾备,应用应缓存何种元数据

说明 Region 实例与可用区差异如何影响跨区域灾备,以及应用应缓存何种元数据?

  • 理解 region/可用区与灾备的关系
  • 理解要缓存的元数据内容
  • 能设计元数据缓存与失效

影响:region 是数据隔离与合规单元,跨 region 灾备意味着数据与模型请求需在另一 region 可恢复;可用区是同一 region 内的容错单元,同 region 可用区故障不影响数据驻留。跨区域灾备要处理:模型端点在不同 region 的可用性、配额、延迟定价差异,以及数据驻留约束(发起请求的 region 必须满足合规)。应用应缓存的元数据:各 region/可用区的模型端点可用性、配额/限流、延迟基线、价格、是否支持数据驻留约束、SLA 状态、DNS/端点映射。缓存要带版本与失效策略,避免把故障 region 当可用。灾备策略:正常就近选 region,故障时按"数据驻留合规 + 可用性"切换到备 region。

灾备的核心是"数据驻留约束 + 可用性 + 成本"的联合决策。应用缓存 region 元数据用于快速决策,但必须区分"路由决策"(平台层)与"业务约束"(业务层)。

#
★★

25. Failover 后原 Provider 的缓存键失效与未出账用量应如何补偿核算,并在租户账单中透明呈现

处理 Failover 后原 Provider 缓存键失效与"未出账用量"的补偿核算,并在租户账单中透明呈现?

  • 理解缓存键随 Provider 失效
  • 理解未出账用量(pending usage)的核算
  • 能设计透明账单呈现

做法:一是缓存键失效——Failover 后原 Provider 的 prompt 缓存不再命中,导致成本上升,应把"缓存失效导致的额外成本"与"原 Provider 已缓存未结算重复"区分开核算;二是未出账用量——Provider 账单有延迟,Failover 后原 Provider 的请求可能尚未出账,需在本地保留 usage 记录,待账单到达后对账;三是补偿核算——把 Failover 前后的成本按逻辑任务归并,避免同一任务被两 Provider 重复计费;缓存失效造成的成本增加应作为"切换成本"单独记录;四是透明呈现——租户账单中区分"正常用量""Failover 切换成本""缓存失效成本",标注发生时间与原因,避免租户质疑。

Failover 的代价包括缓存失效(成本上升)与未出账(对账延迟)。核算要"按逻辑任务归并 + 区分成本类型 + 透明披露"。

#
★★

26. 突发流量逼近配额上限时,请求排队与直接降级小模型的优先级、队列长度上限和用户告知应如何设计

当突发流量逼近配额上限时,如何设计"请求排队"vs"直接降级小模型"的优先级、队列长度上限与用户告知?

  • 理解排队与降级的权衡
  • 能设计队列长度、超时与降级路由
  • 理解用户告知与透明度

设计:一是优先级规则——高优先级(实时交互、付费)可排队,低优先级(批量、离线)应直接降级或拒绝;二是队列长度上限——队列设最大长度与最大等待时间,超限则拒绝或降级(避免排队雪崩);三是降级策略——队列拥堵时,把可降级请求路由到小模型/备用模型,优先保证"能响应"而非"最优质量";四是分流——先降级低优先级、再排队高优先级、最后告警;五是用户告知——降级或排队时向用户明确提示("高峰期,响应可能更简略"或"预计等待"),避免用户误解为故障;六是监控队列深度与丢单率,动态调整阈值。核心是"分优先级、限队列、可降级、透明告知"。

排队与降级是"保质量 vs 保可用"的权衡。正确组合是按优先级分流:低优先级降级、高优先级有限排队、超额拒绝,且全程告知用户。

#
★★

27. 异步任务取消协议应设计哪些幂等字段,避免 Provider 重复计费

异步任务取消协议应设计哪些幂等字段,避免 Provider 重复计费?

  • 理解幂等字段的设计
  • 理解取消与计费的关系
  • 能设计取消协议

幂等字段:一是 task_id(逻辑任务唯一标识,取消请求以它为主键,重复取消返回同一结果);二是 cancellation_id / request_id(每次取消请求的唯一 id,用于去重重复的取消操作);三是 idempotency-key(业务方为每个提交/取消操作生成,Provider 据此去重,防止同一次取消被重放);四是 status 状态机(pending/running/cancelling/cancelled),取消只在 running 生效,其余状态直接返回当前状态,避免重复触发。协议设计:取消请求携带幂等键 + 任务 id,服务端先检查状态再执行,返回"已取消/已在下线中/任务已结束"等确定性结果;取消后要确认 Provider 侧真正停止生成并停止计费(不是仅客户端标记)。

幂等字段的核心是"同一操作多次执行结果一致"。取消用 task_id 定位、用 idempotency-key 去重、用状态机防重复触发,才能避免对同一任务重复发起取消又重复计费。

#
★★

28. Provider 引入新的 reasoning effort 时,老业务路由规则如何自动重新校验

当 Provider 引入新的 reasoning effort(思考档位)时,老业务的路由规则如何自动重新校验?

  • 理解新档位对路由规则的影响
  • 能设计自动校验与回归
  • 理解行为变化监控

做法:一是把"档位 -> 模型/参数"路由表版本化,新档位出现时触发路由表重校验;二是自动跑回归——用固定评估集对新档位与旧档位对比质量、延迟、成本,验证新档位是否满足业务阈值;三是影子流量——把部分生产流量用新档位运行,对比输出与延迟;四是契约测试——新档位必须能映射到 Provider 原生参数且被支持,否则标记为不支持并继续用旧档位;五是灰度 + 门禁——新档位验证通过才允许路由规则引用,否则保留旧规则并告警;六是监控——记录新档位引用后的错误率、超时、成本偏离,超出阈值自动回滚路由规则。

新 reasoning effort 是"新增能力",可能造成行为变化。路由规则必须经过"契约校验 + 回归 + 灰度 + 门禁"才能引用,避免老业务因新档位出现而意外改变行为。

#
★★

29. 跨 Provider 抽象层如何保留 OpenAI Web Search 与 Anthropic Citations 私有能力

说明跨 Provider 抽象层如何保留 OpenAI Web Search 与 Anthropic Citations 等私有能力?

  • 理解私有能力的保留方式
  • 能设计透传与能力协商
  • 理解降级处理

做法:一是"扩展透传"——统一架构允许在请求中携带 Provider 私有字段(如 OpenAI 的 web_search tool、Anthropic 的 citations),这些字段不进入统一消息模型,而是由适配器原样下发到对应 Provider;二是能力矩阵声明——在能力矩阵中标记某 Provider 是否支持 web_search / citations,业务据此决定是否使用;三是响应侧保留——把各 Provider 的私有响应字段(如 citation 的 source)原样透传或映射到统一"引用"结构,供前端展示;四是不支持的 Provider 降级——引用某私有能力时,若目标 Provider 不支持,降级为普通搜索或提示"无引用",而不是报错。本质是"统一负责可移植,透传负责能力保留"。

私有能力是 Provider 的差异化价值,不能丢弃。统一抽象负责"公共核心",透传通道 + 能力矩阵负责"私有扩展",两者结合既保留能力又保证可替换。

#
★★

30. 推理参数 temperature 和 seed 如何联合控制,避免“看似复现其实漂移”

说明 temperature 与 seed 如何联合控制,避免"看似复现其实漂移"?

  • 理解 seed 在 Provider 间的语义差异
  • 理解温度与 seed 的联合作用
  • 能设计可复现验证

做法:一是理解 seed 的局限——seed 通常使"同一请求 + 同参数 + 同模型版本"可复现,但不同 Provider 对 seed 支持程度不同,且 seed 只影响采样,不屏蔽后端升级、缓存、并发等导致的漂移;二是联合控制——固定 temperature、top_p、seed、模型版本、消息序,才能提高复现性;三是验证——用"同一输入重复 N 次"统计输出一致性,而不是只看一次结果;四是处理漂移——即使 seed 相同,模型版本升级、tokenizer 变化、多/top 采样实现差异都会导致漂移,因此"复现"要绑定"版本快照",并在评估中锁定全部参数;五是"看似复现"的防——只固定 temperature 不固定 seed 无法复现;只固定 seed 不固定版本也无法复现,需联合锁定。

复现是"参数 + 版本 + 输入"联合决定的。temperature 决定随机性强度,seed 决定随机源,两者必须配合且绑定模型版本,才谈得上复现。把"固定 seed"误解为"必然复现"是常见误区。

#
★★

31. 多模态内容块的压缩策略如何区分图像质量与音频采样率,避免资费放大

说明多模态内容块的压缩策略如何区分图像质量与音频采样率,避免计费放大(token 膨胀)?

  • 理解图像、音频在 token 计费上的差异
  • 能设计差异化压缩策略
  • 理解压缩与质量、计费的权衡

做法:一是图像——按"任务所需分辨率"压缩,如仅需视觉理解时降采样到更小尺寸、用更少 token 的编码,OCR/细粒度任务才保留高分辨率;根据 Provider 的 image token 计价规则(按边长/tile 数计费)裁剪到最小可用尺寸;二是音频——按"任务所需采样率"处理,如语音识别用 16kHz 即可,而不必用 44.1kHz 高采样率;长音频按时间窗口/分段处理,避免整段编码导致 token 爆炸;三是区分维度——图像关注"分辨率/细节",音频关注"采样率/时长",两者压缩目标不同,不能统一规则;四是压缩前校验——压缩后是否满足任务质量,用评估集验证避免过度压缩导致质量下降。核心是"按能力需求定降采样,避免无谓 token 放大"。

多模态 token 计费与内容尺寸强相关。图像降分辨率、音频降采样率/分片,都能显著降低 token。难点是"降到不损失任务质量的最小值",需结合任务验证。

#
★★

32. Provider 健康检查应做成被动还是主动,如何避免给 Provider 增加额外压力

判断 Provider 健康检查应做被动还是主动,并说明如何避免给 Provider 增加额外压力?

  • 理解被动与主动健康检查的差异
  • 理解最小化 Provider 压力
  • 能设计健康检查与降级

做法:优先"被动"健康检查——基于真实请求的成败统计(错误率、超时比例、延迟)判断 Provider 健康,不额外发探测请求;主动健康检查(发送探测请求)会消耗配额与成本,且探活请求本身可能被限流或干扰统计,应谨慎使用。只有在被动信号不足(如无流量、需要确认故障恢复)时才做低频主动探测,并用"轻量请求"(极短 prompt、低成本模型)以降低压力。健康状态用于路由:故障 Provider 降级、恢复后回切。被动为主、主动为辅,探测频率低、请求轻,避免给 Provider 增加压力。

主动健康检查是"额外成本",被动健康检查用真实流量零成本。健康检查的目标是"判断故障以正确路由",用真实请求统计即可,只有在需要探测恢复时才做低频轻量主动探测。

#
★★

33. 多模型供应商接入时如何做统一的协议抽象与灰度切换?

多模型供应商接入时如何做统一的协议抽象与灰度切换?

  • 理解统一协议抽象结构
  • 理解灰度切换机制
  • 能设计切换安全

协议抽象:定义统一消息模型、统一工具调用模型、统一响应结构与统一错误码,每个 Provider 一个适配器做双向转换;用能力矩阵声明能力;用契约测试锁定转换。灰度切换:路由配置支持"按租户/流量百分比/请求特征"分流到不同 Provider;切换前用影子流量对比质量与延迟;切换中监控错误率、延迟、成本、质量指标,设置自动回滚阈值;切换后保留一定回退期。灰度切换要"可配置、可监控、可回滚",避免全量切换一次性暴露风险。

统一抽象保证"可切换",灰度机制保证"切换安全"。两者结合:抽象解决"怎么切",灰度+监控+回滚解决"切错了怎么办"。

#
★★

34. 模型 API 的限流、配额与超时重试策略如何设计,如何区分可重试与不可重试错误?

设计模型 API 的限流、配额与超时重试策略,并区分可重试与不可重试错误?

  • 理解限流、配额、超时、重试的协同
  • 能区分可重试与不可重试错误
  • 能设计重试退避

限流:客户端侧按 Provider 的 RPM/TPM 做本地限流(令牌桶),避免打爆配额触发 429;配额:按租户/任务分配配额,超限排队或降级。超时:分连接超时、首 token 超时、总时延超时,分别设置。重试:只对可重试错误重试——网络抖动、瞬时 5xx、429(限流,尊重 Retry-After)、超时(谨慎)等;不可重试——401/403(认证鉴权)、400(参数非法)、404(模型不存在)、内容被拒、422(参数验证失败)等业务错误,重试无意义。重试策略:指数退避 + 抖动 + 上限,配合幂等键防重复计费。

限流/配额是"事前防护",超时是"兜底止损",重试是"事后恢复",三者协同。重试成败的关键是错误分类,把 4xx 业务错误与瞬时错误分开,避免无谓重试浪费成本。

#
★★

35. 多模态输入的内容引用方式(base64 data URI 与远程 URL)在计费、隐私与 SSRF 风险上的差异,以及大文件上传的工程取舍?

比较多模态输入中 base64 data URI 与远程 URL 两种内容引用方式在计费、隐私与 SSRF 风险上的差异,并说明大文件上传的工程取舍?

  • 理解 base64 与 URL 的计费、隐私、SSRF 差异
  • 理解 SSRF(服务端请求伪造)风险
  • 能设计大文件上传的取舍

base64 data URI:内容直接内嵌请求,计费明确(包含在请求 token 中),隐私可控(不经过第三方 URL),但请求体大、对 Provider 有解析压力,且无 SSRF 风险(不涉及 Provider 拉取 URL)。远程 URL:Provider 主动去拉取,节省请求体大小,但 Provider 在拉取时可能遇到 SSRF 风险(若 URL 指向内网又未经校验),隐私风险(内容经第三方 URL 可达),计费可能按"拉取处理"计。大文件上传取舍:超大的 base64 会撑爆请求体,应改用分段/分块上传或先上传到对象存储再以 URL 引用;对隐私要求高、内容不宜出域的数据用 base64 或私有上传;对内容可公开或存储于可信存储的用 URL。核心是"按隐私与大小权衡,base64 保隐私、URL 省体积,但 URL 需防 SSRF 与隐私泄露"。

三种考量:计费(token 计价)、隐私(内容是否出域/可达)、安全(SSRF)。大文件用 base64 会体积爆炸,用 URL 则引入 SSRF 与隐私风险。取舍要看数据性质与规模。

#
★★

36. Provider 调整计费字段或账单格式时,账单核对脚本应如何同步升级并回归验证

当 Provider 调整计费字段或账单格式时,账单核对脚本应如何同步升级并回归验证?

  • 理解账单格式变更的应对
  • 能设计账单解析的版本化与回归
  • 理解字段映射契约

做法:一是把账单解析做成"版本化映射"——每个 Provider 的账单字段映射定义为一个带版本的 parser(schema),变更时新增版本而非原地改;二是契约测试——用历史账单样例 + 新格式样例做 golden 回归,断言解析后的字段(输入/输出/缓存/成本)正确;三是变更感知——监控 Provider 账单格式变更公告,触发重新解析与回归;四是双轨对账——变更期间新旧格式并行解析,对比结果差异,确认无偏差后再切换;五是对账逻辑同样版本化,字段缺失/新增时给出显式告警而非静默忽略。核心是"解析与对账版本化 + 契约回归 + 变更感知"。

账单格式变更若静默处理,会导致对账错误。把它当"接口变更"管理:版本化 schema + golden 用例回归 + 变更公告感知,确保升级后对账仍准确。

#

37. 模型能力快照如何抽象为版本化契约文件,让 CI 持续校验 Provider 公告

如何把模型能力快照抽象为版本化契约文件,并让 CI 持续校验 Provider 公告?

  • 理解能力快照契约文件的结构
  • 理解 CI 持续校验
  • 能与 Provider 公告联动

做法:能力快照抽象为一个版本化契约文件(如 capabilities.yaml/json),声明模型支持的能力(工具、结构化输出、视觉、缓存、思考、上下文窗口、版本范围、弃用日期)。文件带版本号,CI 定期拉取 Provider 公告(变更日志、models 接口),与契约文件比对,检测"能力新增/移除/弃用"并报警。CI 校验规则:契约文件中的能力与 Provider 实际一致;弃用日期在窗口内时触发迁移待办;引用契约的业务代码在能力变更时自动触发回归。契约文件即"代码与 Provider 之间的唯一事实来源",CI 保证其不漂移。

契约文件把"能力"变成可校验、可版本化的资产,CI 让"人肉关注公告"变成"自动比对告警"。这是能力漂移治理的工程化手段。

#

38. 多模态(图像、音频、视频、文件)调用如何统一抽象为消息内容块,并控制不同 Provider 的尺寸、压缩与计费策略

说明如何把多模态(图像、音频、视频、文件)调用统一抽象为消息内容块,并控制不同 Provider 的尺寸、压缩与计费策略?

  • 理解内容块(ContentBlock)抽象
  • 理解各模态的尺寸与计费控制
  • 能设计 Provider 适配

做法:统一抽象为 ContentBlock(type: text/image/audio/video/file,含 data/source/引用方式),消息由多个 ContentBlock 组成,业务层面向统一结构;各 Provider 适配器把 ContentBlock 映射为其原生格式(OpenAI 的 content part、Gemini 的 inlineData/fileData、Anthropic 的 source)。尺寸与计费控制:在适配层按 Provider 的计价规则(图像按像素/tile、音频按时长、视频按帧)做尺寸裁剪与压缩,使用"任务所需最小资源";在上传层统一处理大文件(分块/转存)。计费策略:按 Provider 每模态 token 规则计算成本,写入 usage 归集。本质是"统一内容块 + 按 Provider 适配尺寸/压缩/计费"。

多模态统一的关键是"内容块抽象",把异构模态收敛为统一结构,再让适配器处理各 Provider 的格式与计价差异。尺寸压缩与计费是适配层职责。

#

39. 如何验证 stream 选项是否在所有端点上对称支持,尤其是 Files、Batches、Realtime 与异步任务入口

如何验证 stream 选项是否在所有端点(Files、Batches、Realtime、异步任务入口)上对称支持?

  • 理解流式在不同端点上的支持差异
  • 能设计对称性验证
  • 理解异步与流式的组合

做法:一是建立"端点能力矩阵"——把每个端点(Chat/Responses、Files、Batches、异步任务、Realtime)与 stream 支持情况建表,标注"是否支持流式、是否支持 SSE、流式返回的字段结构";二是契约测试——对每个端点做 golden 用例,验证 stream 参数是否被接受、响应是否按流式分片返回、错位时是否报错;三是运行时验证——对批量(Batches)与异步任务验证"流式+异步"的组合语义(如批量任务不支持逐 token 流式,只支持任务级进度);四是 Realtime 验证——WebSocket 全双工是否与 HTTP SSE 语义一致;五是告警——当某端点宣称支持 stream 但实际截断返回时,检测并告警。核心是"能力矩阵 + 契约测试 + 运行时校验"。

常见陷阱是"想当然认为所有端点都支持 stream"。通过端点能力矩阵 + 契约测试显式锁定"哪些端点支持什么粒度的流式",避免业务假设与实际不符。

#

40. 如何评估国产模型与国际模型在中文场景下的性价比与生态差异?

说明如何评估国产模型与国际模型在中文场景下的性价比与生态差异?

  • 理解中文场景的评估维度
  • 能设计性价比与生态对比
  • 理解部署与合规差异

评估维度:一是中文质量——用中文基准集(中文理解、古文、成语、百科、中文推理)对比准确率与指令遵循;二是性价比——按"每百万元素成本"或"单位准确率成本"对比,考虑输入输出 token 单价、缓存价格、批量折扣;三是生态——工具调用、函数库、开源社区、插件、文档、兼容 OpenAI 接口的程度;四是部署与合规——国内模型的数据驻留、合规、备案、网络稳定性,国际模型的数据跨境与合规约束;五是延迟与稳定性——国内访问的延迟、国际模型的可用性。方法:用统一评估集 + 统一计价规则计算"每正确单位成本",结合部署/合规约束做加权决策。

中文场景下,国际模型可能有语言优势,但国产模型在中文语境、成本、合规、国内访问延迟上常占优。性价比要用"单位质量成本"而非单纯单价,生态与合规是重要非功能维度。

#

41. Embedding 接口的接入细节,dimensions 参数、批量上限、输入截断与向量归一化对检索质量与成本的影响?

说明 Embedding 接口接入中 dimensions 参数、批量上限、输入截断与向量归一化对检索质量与成本的影响?

  • 理解 dimensions 与向量维度
  • 理解批量、截断、归一化的影响
  • 能设计 Embedding 接入策略

dimensions:可配置嵌入维度,维度越高表达力越强但存储与计算成本越高,业务应选与下游匹配的维度(如两者会影响相似度计算与向量库成本);批量上限:Embedding 接口有批量请求上限,批内取平均成本低,但超限会报错,需按上限分批;输入截断:超出模型 token 上限的文本会被截断,截断会丢失语义导致检索质量下降,应主动按语义分段(chunk)而非硬截断;归一化:向量归一化(L2)使点积可用于余弦相似度比较,保证评分尺度一致,否则不同长度文本的相似度不可比。接入策略:合理 chunk + 批处理 + 归一化 + 维度匹配,兼顾质量与成本。

Embedding 的质量与成本受这些参数影响:dimensions 决定表达与成本,chunk 决定语义完整性,归一化决定可比性,批量决定效率。接入时统一处理,避免质量与成本失衡。