跳到主要内容

总结 — FinBayes 意图识别与 LLM 策略

研究范围​

FinBayes 的核心是把用户的自然语言（含未来语音 / 文件附件 / URL / 表单等多模态输入）映射到结构化金融认知任务（解释 / 分析 / 比较 / 复盘 / 风险识别 / 交易准备 / 交易决策辅助 等）。这件事做不好，下游所有内容（证据组织 / 综合 / 输出 / 状态沉淀）都受影响。本调研研究业界做法、技术成熟度、可选方案，为 ADR-004 决策提供依据。

7 条最重要的研究发现​

1. 业界 Agent 没有采用显式"意图分类管道"​

研究的 4 个主流项目（Claude Code / OpenClaw / Hermes Agent / Claude Code 源码分析）统一采用 LLM Function Calling 主导工具决策 的范式。无任何项目在管道前置做"意图分类"。

FinBayes 之前提议的"意图本体 + 多阶段管道"方向有过度设计的嫌疑。意图本体应重定位为"事后任务类型标签 / 合规元数据"，不是前置分类器。

2. 主流 LLM Function Calling 已足够成熟​

BFCL leaderboard 头部模型（Claude Sonnet 4.x / Opus 4.5、GPT-4o / GPT-5、DeepSeek V3.2、Qwen2.5-72B、Llama 3.1 405B）都超 80%。选型是"什么场景配什么"的问题，不是"能不能用"的问题。

3. 多轮工具调用是悬崖式崩塌​

FinMCP-Bench 显示头部模型在金融多轮 function calling 上 exact match 仅 3.08%（vs 单工具 60%+）。不能依赖 LLM 原生处理复合任务。意图层必须显式拆解多轮 / 复合 query 为单工具任务串行调用。这是工程层责任，不是模型层。

4. 金融专用 LLM 不适合做主路由 / 工具调用​

FinGPT / FinLLaMA / XuanYuan / DISC-FinLLM 等都没针对 Function Calling 做专项训练。它们在金融 NLP 任务（情感 / 实体 / 分类 / 考试）上有优势，但不适合 intent → tool 路由。

更反直觉的发现：Qwen2.5-72B（通用 LLM）在 FinEval 上达 76.5% 金融知识平均准确率，已匹敌 GPT-4o，金融安全维度超 Claude 3.5。

→ FinBayes 应用通用 LLM + RAG / system prompt 注入金融知识，不引入金融专用 LLM 做主路由。

5. L3 缓存命中率应保守预估 15-25%​

业界真实数据：FAQ / 高重复类 40-60%，对话类 5-15%。金融认知任务接近对话类。命中率不会到社区博客说的 60%+。

Break-even 15-20%（语义缓存查询有 30ms 开销）。低于此线，缓存反而是负担。

6. LLM 自报的 confidence 不可信​

研究综述显示 LLM verbalized confidence 与实际正确率严重脱钩。consistency-based（多次采样投票）显著优于 verbalized。

→ FinBayes 在高风险任务（交易决策辅助）必须做 self-consistency N≥3。成本部分由 L3 缓存抵消。

7. 业界没有"LLM 不可用时优雅劣化"的产品级方案​

业界共识是"LLM 不可用 = Agent 服务不可用"。FinBayes 的"本地优先 + LLM 不可用时劣化"超出业界普遍实践，需要自己设计 4 层劣化策略。

给 ADR-004 的核心推荐​

决策点推荐
主架构业界标准（LLM Function Calling + 工具池 + 澄清作为工具）+ 金融特定扩展（事后任务标签 / 多模态预处理 / 用户上下文注入 / 边界保护 hook）
L1 主力 LLMClaude Sonnet 4.x，备选 GPT-4o（低延迟）/ DeepSeek V3.2（国内合规）/ Qwen2.5-72B（中文特化）。做 LLM 路由，不锁定单一厂商
L2 本地兜底 LLMQwen2.5-7B / 14B 量化版（Ollama），不用金融专用 LLM
L3 缓存 + 规则Redis + bge-small-zh embedding（阈值 0.88）+ 正则词典 + logistic regression 兜底分类器。预期 18-22% 命中
L4 受限菜单 UI借鉴 Amazon Alexa FROST 模式（fallback recommendation 而非空白）
用户自配置 ProviderFirst-class 场景。Provider Registry + 用户级配置 + 系统默认 fallback。两层路由（系统默认 + 用户覆盖）
多轮 / 复合任务处理意图层显式拆解，不依赖 LLM 原生处理
Confidence 评估高风险任务 self-consistency N≥3
金融专用 LLM 角色仅作 RAG 知识源 / 离线训练数据生成 / 特定子任务（如情感分析），不进主路由

ADR-004 应该明确的"不做"​

  • 不引入金融专用 LLM 作为 L1 / L2 主路由模型
  • 不指望 L3 命中率超过 30%
  • 不依赖 LLM verbalized confidence
  • 不依赖单一 LLM 厂商
  • 不指望 LLM 原生处理多轮复合任务
  • 不预设"意图分类管道"作为前置阶段

主要风险与未决问题​

详见 09-open-questions.md。摘要：

  • 多轮金融工具调用的稳定性是已知工程挑战，需 FinBayes 在意图层做拆解工程
  • 用户自配置 Provider 的能力发现（Function Calling 支持 / 上下文长度 等）需要 runtime 探测
  • 用户 Provider key 的安全存储跨平台（macOS Keychain / Windows Credential Manager / Linux Secret Service）实现差异
  • 本地嵌入式 LLM 在不同硬件下的性能差异（M2 Ultra vs M1 vs 普通笔记本）
  • 金融场景中 LLM 幻觉的影响（编造价格 / 编造事件 / 编造来源等）需要工程层 schema 验证 + 来源约束

后续调研方向​

详见 09-open-questions.md。重点：

  • Tool Search 三段式（OpenClaw 模式）在 FinBayes 工具池超过某个数量时的具体设计
  • 意图本体作为"事后任务标签"的具体回填机制（LLM 工具调用 → 任务类型映射）
  • 多模态预处理的具体方案（不同文件格式 / URL 类型的解析精度评估）
  • 持续监测金融专用 LLM 是否补齐 Function Calling 训练（如果补齐，重新评估其在 L2 的位置）

引用源​

详见 references.md。