squash合并: - 意图识别层论证(8维度+10业界佐证) - 多主题上下文管理愿景+并存论证+补充论证(多轮agentic) - 架构设计文档物理分类(四子目录+INDEX+命名规范+引用同步+边界清晰化) - 前端架构技术债清单归档
4.2 KiB
4.2 KiB
多主题并存(交织并行)多角度论证
来源:multitopic-analysis 子代理 8 维度论证 + WebSearch SOTA 硬数据 + 业界产品派/学术派佐证。 纯架构论证,不改代码。供架构决策。
TL;DR
近期不做自动多主题路由。SOTA 准确率天花板(55.8/73%)远低>90% 硬阈值 + devflow 有副作用工具(误判不可逆) + 边界场景 30-50% 降级稀释 ROI + 业界零参照(头部产品全用物理隔离)。
核心结论(数据驱动)
1. 准确率天花板是硬约束(不可绕过)
- TopiOCQA F1 = 55.8(最贴近 A-B-A-B 交织 SOTA,TACL 2022)→ 误判率 25-45%
- MultiWOZ DST JGA ≈ 73.6%(受控,开放域更差)
- devflow 硬阈值(有副作用工具):需 >90-95% 才值得做
- 当前 SOTA 远低于阈值 → 自动路由不具备落地条件
2. 误判代价不对称(因 devflow 有副作用工具)
- 不做多主题(全历史):信息冗余但都在,可逆
- 多主题误判(消息3[A]误判 B):信息错误路由,LLM 用 B 回 A → 完全错位
- devflow 工具(销账/状态机/文件写)不可逆 → 误判触发不可逆副作用,比全历史更糟
3. 业界零参照(头部产品全用物理隔离)
- ChatGPT:Projects(用户手动分会话)
- Claude/Claude Code:memory 按 Project 隔离
- Cursor 2.0:子代理 + git worktree 物理隔离
- Devin 2.0:拆任务到隔离 VM
- Cline:Tasks 独立会话,跨 session 不传上下文
- 无一做单会话内自动主题路由 → devflow 若做是先行者(高风险)
4. 边界场景频率致命稀释 ROI
- 新主题/通用寒暄(15-25%)+ 模糊不能明确 A/B(10-15%)+ 跨主题对比(5-10%)= 30-50% 消息降级全历史
- 代价 100% 承担(复杂度+误判风险),收益只作用于 50-70% 消息 → ROI 为负
5. 长上下文不救场
- lost-in-the-middle(Liu et al. TACL 2023,被引 4690+):长上下文 U 型退化
- A-B-A-B 切回旧主题 A 时,A 历史信息可能落在"中间段"被遗忘 → 即使全历史也在,关键信息仍可能丢
分阶段路径
| 阶段 | 触发条件 | 动作 |
|---|---|---|
| 近期(0-3月) | 现状(29工具,单provider,中短对话) | 不做,F-09+F-15 够用,储备设计 |
| 中期(3-12月) | 用户主动反馈痛点 | 试点显式标主题(用户手动标,零误判)或半自动 fallback(高门槛>95%才隔离) |
| 远期(12+月) | 准确率>90% + 意图层稳定 + 真实痛点(三者齐备) | 完整自动多主题 + 强 fallback |
中期试点原则:绝不直接上全自动路由。优先"用户显式标主题"(零误判)或"半自动高门槛"(embedding>95% 才隔离,其余全历史)。
fallback 是硬要求(任何阶段)
- 置信度必须(低→全历史不隔离)
- 业界范式:Rasa/工业对话系统用"阈值+双层 fallback(OOS/低置信澄清)",非"自动全历史兜底"
- "低置信→全历史"看似安全,实则(a)token 高 (b)放大 lost-in-the-middle (c)边界 30-50% 触发 → 多主题愿景在边界退化为不做多主题
与 F-09 关系(架构可行但非瓶颈)
- F-09 多会话(已落地
d899c58)铺路 85%:per_conv/ContextManager/压缩/持久化可复用到 topic 层 - 多主题 = F-09 的"会话内"深化(topic 级 per-conv),架构改动 ~650-800 行
- 架构就绪 ≠ 值得做:真正瓶颈是准确率天花板 + 误判代价,非架构