同一提示词每次跑结果都不同：在一把 key 上隔离随机性来源再决定要不要固定

为什么需要隔离随机性来源

使用 LLM API 时，同一提示词多次运行结果不同是常见现象。在聚合型 API 服务中，波动来源可能更多：除了模型本身的随机性，还可能涉及路由策略（选择不同后端或模型版本）以及服务商侧的更新。若想决定是否固定随机性，首先需要系统地隔离这些来源。

隔离随机性来源的步骤

1. 控制变量：固定温度与采样参数

温度控制输出的随机程度。通过显式设置 temperature 为较低值（如 0.1）或 0，可以观察结果是否趋于稳定。若低温度下仍波动，则说明随机性主要来自其他因素。

2. 检查路由与后端选择

聚合 API 可能根据负载或配置将请求路由到不同后端。建议在请求中检查响应头或元数据是否包含后端标识，或使用固定路由的参数（如指定特定模型版本）。如果服务支持固定后端，可开启后对比结果一致性。

3. 记录模型版本信息

模型提供方可能更新模型版本，导致行为变化。在响应中查找模型版本字段（如 model 或 system_fingerprint），并记录每次调用的版本信息。若版本变动与结果波动相关，则版本是随机性来源之一。

4. 多次采样与统计

对同一提示词运行多次（如 10 次），记录输出差异。通过人工或自动化的语义相似度分析，量化波动程度。如果低温度下输出仍显著不同，建议进一步检查路由或版本。

决定是否固定随机性

隔离来源后，可根据应用场景决定是否固定：

• 需要确定性输出（如测试、回归验证）：考虑使用 seed 参数（若支持）并固定模型版本与路由。注意，即使设置 seed，部分模型仍可能因并行计算产生微小差异，需结合版本固定。
• 需要创造性输出（如内容生成）：保留一定随机性，通过调整温度控制多样性，无需固定。
• 对成本敏感：聚合服务按官方价 ×1.3 扣费，贡献 key 按官方价 ×1.1 返 USDC。固定后端或版本可能影响服务可用性，需权衡成本与稳定性。

实践建议

• 在开发阶段，记录每次请求的完整参数与响应元数据，便于回溯。
• 若使用聚合 API，优先选择支持显式指定模型版本或路由的服务。
• 在生产环境中，通过监控输出一致性和版本变化，及时调整策略。

总之，通过控制变量和记录元数据，可以清晰识别随机性来源，再根据业务需求决定是否固定，从而在稳定性和灵活性之间取得平衡。