3.4 KiB
3.4 KiB
任务基本信息
- 任务：方案A：同一聊天框多话题时避免上下文污染（新话题禁用
dialog_context） - 项目：
backman-camel（FastAPI Text2SQL API） - 范围：后端接口
/g3sb/api/nl/chat、/g3sb/api/nl/chat/stream的会话上文注入策略
改动说明
-
新增：
backend/utils/dialog_context.py增加is_likely_follow_up(user_text)，用于轻量判断是否为续问/沿用口径。 -
调整：
api_server.py_load_session_text2sql_context(request, user_text)在构造上文时：- 续问：注入最近 2 轮会话摘要
- 新话题：不注入历史摘要（
max_pairs=0）
-
目的：减少多话题情况下历史 SQL/条件回流导致的串话与错误 SQL。
-
新增（本次补充）：
backend/llm/openai_client.py- 提供
OpenAIClient.chat/chat_with_json（以及与 DeepSeekClient 对齐的若干便捷方法），用于接入 OpenAI 或 OpenAI 兼容网关。 .env增补OPENAI_MODEL/OPENAI_CHAT_MODEL的注释示例（不影响现有配置）。
- 提供
影响与风险
- 破坏性变更：否（对外 API 不变）
- 风险等级：中
- 可能将少量“隐式续问”误判为新话题，导致指代消解能力下降
- 但能显著降低跨话题上下文污染导致的 SQL 错误
- 回滚：回退本次改动即可恢复旧策略（或将
max_pairs恢复为默认值 8）
测试与验证
-
建议手工验证：
- 同一 session：先做话题A数据查询，再提一个完全不同话题B（无“再/按上面”等续问词），应不再引用 A 的表/过滤条件。
- 同一 session：首轮查询后，第二轮使用“再/按上面/沿用口径”等续问词，应仍能续用上轮口径生成 SQL。
-
已执行：
python -m py_compile backend/llm/openai_client.py
配置说明（补充）
- LLM 切换：通过
.env的LLM_SERVICE_CODE在deepseek/openai之间切换（留空则按 Key 自动选择，优先 deepseek）。
前端参数适配（补充）
- lang_code：支持
zh（简体）、tc（繁体）、en（英语）；在对话分支的默认引导文案/空输入提示中生效。 - model：请求体可传
model覆盖默认模型名（与service_code搭配使用），用于按请求临时切换模型。
流式输出（补充）
/g3sb/api/nl/chat/stream：chat与sql_gen阶段的正文改为多段 SSE 分片推送（默认每段约 64 字符，可用环境变量SSE_STREAM_CHUNK_CHARS调整），与前端onDelta累加逻辑一致。- 重复 SQL 修复（补充）：为避免同一次 SSE 响应中出现两段 SQL（LLM 自吐
<data>...</data>+ 服务端末尾补发<data>{"sql":...}</data>），后端在透传 LLM delta 时会过滤掉任何<data>...</data>段，仅保留流结束时的标准结构化<data>片段供前端解析。- 现状约束：由于当前前端会直接拼接展示 delta 且保留
<data>，流式接口默认不再补发结构化<data>{"sql":...}</data>，避免“SQL + 可见<data>”造成重复展示。 - 如需补发：设置环境变量
SSE_APPEND_SQL_DATA_TAG=true才会在流末尾补发结构化<data>（仅建议给会过滤<data>的客户端使用）。
- 现状约束：由于当前前端会直接拼接展示 delta 且保留
后续事项
- 若误判率偏高，可迭代
is_likely_follow_up规则（补充关键词/短语），或升级为轻量 LLM 判别器（方案B）。