跳到主要内容

ADR-004 — 自然语言到任务的识别策略

决策​

FinBayes 第一阶段采用 LLM Function Calling 主导的意图识别与任务分发策略，不预设独立的"意图分类管道"。

M0 阶段最小实施：

  1. 主路径：用户输入归一化后，由 Task Orchestration 子系统通过 LLM Function Calling（OpenAI-compatible 协议）暴露完整工具池 schema + 7 类任务能力描述给 LLM；LLM 自主决定调单工具 / 多工具组合 / 调 clarify 工具（M0 stub）/ 直接回答
  2. 任务类型识别 = 事后标签：LLM 调用完成后由 Task Orchestration 子系统事后回填 task_type（7 类之一）到 Task.task_type 字段并写入审计 trail（M0 必填）
  3. clarify 工具 M0 stub：意图严重不明时 LLM 应能调 clarify 工具触发澄清回路；M0 阶段 run_clarify_loop stub（M2 上线）
  4. 规则路径仅做边界拦截：边界 hook（输入 / 输出）+ 凭证识别正则 + 执行类工具注册拒绝走纯规则（详见 ADR-010 + m0-walking-skeleton §10）；规则不预先做任务分类

M1+ 演化空间：

  • TaskGroup 并发编排（M0 单任务 stub）
  • L3 缓存 + 规则兜底分类（M0 stub）
  • 在线评估发现的高频 / 高准确率 case 可在 M3+ 引入轻量规则前置（仅 boost 路径不替代 LLM 路径）

上下文​

FinBayes 是自然语言入口产品，用户表达不会被强制结构化。三种候选策略：

候选优点缺点
意图分类管道（规则 / 微调小模型先识别意图，再路由到任务）可控 / 可追溯 / 低延迟任务类型固化早 / 微调成本高 / 在多任务并发场景显得僵硬
LLM Function Calling 主导与业界 Agent 框架收敛（LangChain / OpenAI Assistants / Anthropic tool use 等）/ 自然支持多任务并发 / 维护成本低依赖 Provider 端能力 / 多轮稳定性需要 self-consistency 兜底
混合（规则前置 + LLM 兜底）高频 case 低延迟 / 罕见 case 仍能覆盖双路径维护成本高 / 边界 case 路由不一致

项目级深度调研（projects/finbayes/research/intent-recognition-and-llm-strategy/）覆盖 4 个主流 Agent 框架（LangChain / OpenAI Assistants / Claude Code / Hermes）的意图识别实践，结论一致：业界已稳定收敛在 LLM Function Calling 主导，意图分类管道仅在窄场景（金融客服 FAQ 等）使用。

FinBayes 工程范式（ADR-001）要求 M0 走通骨架 1-2 天可完成；混合策略的双路径会让 M0 工作量翻倍且无明确质量回报。

后果​

收益：

  • M0 实施成本最低：6 子系统 + LLM Function Calling 即闭环（详见 m0-walking-skeleton §1 链路图）
  • 与 ADR-008 Provider 接口（统一 OpenAI-compatible）自然衔接
  • 多任务并发由 LLM 在工具调用层决定，runtime 不需要预先做任务拆解
  • 任务类型清单变化不破坏工程层（仅改 LLM Prompt 中的任务能力描述）

成本：

  • M0 阶段 LLM 调用质量直接决定意图识别质量 —— 用户没配高质量 LLM 时识别可能不稳
  • 任务类型事后标签依赖 LLM 自报或综合层归类，可能有 5-10% 错分（M0 验收容忍，M6 评估闭环收紧）
  • 多轮上下文中 LLM Function Calling 稳定性需 self-consistency 兜底（M0 N=1 简化，M2+ 上 N≥3）

残余风险：

  • 用户用极简或模糊表达时识别准确率下降 → clarify 工具兜底（M2 上线）
  • LLM Provider 端 Function Calling 协议变化 → fixture 版本检测（详见 m0-walking-skeleton §7 + §14.5）

备选方案​

考虑过未采用：

  • 意图分类管道：与"任务类型不写死、由 LLM 动态识别"的 §4 原则冲突；微调小模型增加训练管道（与本地优先定位张力）
  • 混合策略：M0 工作量翻倍且无明确质量回报；M3+ 评估闭环发现高频 case 后可再追加（前向兼容路径）

关联​

  • 触发章节：CHAP-04 业务对象与关系 / CHAP-09 Task Orchestration 子系统
  • 影响章节：CHAP-04 / CHAP-09 / CHAP-10（sequence S1 / S7）/ CHAP-21 评估闭环
  • 项目级调研：projects/finbayes/research/intent-recognition-and-llm-strategy/recommendations.md
  • M0 实施承接：projects/finbayes/engineering/engineering-packs/m0-walking-skeleton.md §2（接口子集）+ §3（Pydantic 模型）+ §8（样例输入能力清单）
  • 关联 ADR：ADR-008（Provider 接口）/ ADR-010（输出端过滤）
  • 后续 ADR：ADR-009（Prompt 版本化，特别是任务模板的演化）