Bug: per-request generation overrides are silently dropped for existing chats

快速结论：当调用 RAGFlow 的 POST /api/v1/chat/completions 接口、对已配置模型的既有会话传 temperature、top_p、frequency_penalty、presence_penalty、max_tokens 时，这些参数被请求解析器接收却不生效，生成仍使用会话保存的 llm_setting。优先升级到采用 Go 实现的最新版本。

适用环境：受影响的实现路径为 RAGFlow 的 Python 版本（api/apps/restful_apis/chat_api.py）。Issue 未明确列出具体的操作系统、Python、CUDA、显卡或依赖版本，这些项目需按你的部署实际情况确认。

最快修复方案：Issue 的结论是：生成参数处理已在 Go 版本中重新实现，并支持按请求覆盖。可切换到最新版本后重试。Issue 中未给出可确认的一步修复方案（例如单个补丁版本号或命令）。

注意事项：由于维护方是将该 Issue 作为旧 Python 实现的遗留问题关闭的，Issue 中并未逐行验证 Go 版本对所有既有聊天场景（包括现有会话、自定义模型、租户默认模型回退）的实际行为。升级前建议先在小范围测试环境用下方复现用例验证。

问题场景

使用 RAGFlow 的 HTTP API POST /api/v1/chat/completions 发起对话补全请求。请求携带有效的 chat_id，指向一个已经配置了模型（即其 dialog 已有 llm_id）的聊天助手，同时在请求体中传入 temperature、top_p、frequency_penalty、presence_penalty、max_tokens 等生成参数，并且没有传 per-request 的 llm_id 覆盖。Issue 描述的预期行为是：本次请求显式提供的生成参数应覆盖会话保存的设置。

报错原文

Bug: per-request generation overrides are silently dropped for existing chats

该问题不会抛出异常，属于静默失效：请求参数被接受，但生成结果仍按会话存储的 llm_setting 执行，接口层面可能看不到任何报错信息。

原因分析

在 Python 实现的 session_completion 中，pop_generation_config(req) 会收集调用方的生成参数覆盖项，但负责把它们合并进 dialog 的 merge_generation_config(dia, chat_model_config) 被放在了 elif not dia.llm_id: 分支内部，只在 dialog 尚未配置模型时执行。

对于最常见的场景——请求指向一个已存在且已配置 llm_id 的聊天，同时没有 per-request 的 llm_id——chat_model_id 为空、not dia.llm_id 为假，两个分支都不进入，chat_model_config 因此被丢弃，async_chat 仅按 dia.llm_setting 运行。

Issue 指出，这与 PR #15389 引入该功能时的意图不一致，也与同一仓库中 OpenAI 兼容路由（api/apps/restful_apis/openai_api.py）的处理方式不同：后者是在所有路径上无条件调用 merge_generation_config(dia, extract_generation_config(req))。因此可能原因是回归：合并逻辑被放进了条件分支，导致既有聊天不应用请求级覆盖。

环境排查

确认当前使用的 RAGFlow 版本及其后端实现：是旧 Python 实现（涉及 chat_api.py）还是 Go 版本。
确认调用的是 /api/v1/chat/completions 路径，而不是 OpenAI 兼容路由；后者在 Issue 描述中不表现此问题。
确认目标 chat_id 对应的聊天助手是否已保存模型（llm_id 已设置）。
确认请求中只使用文档支持的生成参数键，且未同时传入 llm_id。
记录请求中的参数值，并与对话实际使用的 llm_setting（保存的 temperature、max_tokens 等）对比。
Issue 未提供 Python、CUDA、PyTorch、显卡及依赖版本信息，这些不作为本问题的判定依据，避免无依据升级或降级。

解决步骤

先在测试环境保存该问题的复现用例：创建一个聊天助手，使其 dialog 已配置 llm_id，然后发送如下请求，并记录实际生效的生成参数。

{
  "chat_id": "<existing chat id>",
  "session_id": "<existing session id>",
  "messages": [{"role": "user", "content": "hi"}],
  "temperature": 0,
  "max_tokens": 256
}

对比请求参数与生成结果：若 temperature 仍为会话保存值（例如 0.7），且 max_tokens 未被 256 覆盖，则确认命中该问题。
确认当前是否为旧 Python 实现；若是，按 Issue 结论升级到采用 Go 实现的最新版本。升级前做好配置与数据备份，并在测试环境完成上一步的复现用例。
升级后使用同一请求再次验证，检查请求级参数是否覆盖了会话设置，且未被覆盖的会话设置仍然保留。
若升级到最新版本后仍能复现类似行为，按维护方建议另开新 Issue 反馈，并附上版本信息、复现请求和日志。可优先尝试确认 Go 版本中对应逻辑是否对所有既有聊天场景无条件合并请求参数。

验证方法

沿用 Issue 中回归测试的思路进行验证：对已配置模型的既有聊天发送带覆盖参数的请求，确认只覆盖调用方显式传入的键，未传入的键保持会话原值。例如会话保存 {"temperature": 0.7, "top_p": 0.3, "custom": "keep"}，请求传入 temperature: 0 与 presence_penalty: 0，期望合并结果为 {"temperature": 0, "top_p": 0.3, "custom": "keep", "presence_penalty": 0}。Issue 描述称该用例在旧 Python 实现的 main 上失败——dialog 仍保留 temperature: 0.7 且未获得 presence_penalty: 0；在修复后的版本上应通过，接口返回与生成行为应体现请求参数。