AI 与基础模型 · 2026年2月8日

多模型编排:为每个研究任务匹配正确的模型

在 KSINQ,我们运行一个多模型架构,路由决策——哪个模型处理哪个任务——本身就是对分析质量的投资。强制推理模型做量化计算会得到更慢且不可靠的结果;强制视觉模型做长文本分析会得到浅薄的分析。

为什么不能只用一个模型

“选最好的模型,所有东西都走它”——这是最常见的偷懒做法。问题和让一个分析师同时干宏观、信用、量化、执行一样:每个任务的认知特征不同,没有一个模型全部最优。

我们运行多模型架构。哪个模型处理哪个任务,这个路由决策本身就是分析质量的一部分。

模型阵容与分工

Claude —— 核心推理。 论点构建、证据链、对抗性压力测试、跨语言综合——工作流中风险最高的认知环节。为什么选它、它哪里不行 → 详见 Claude 推理引擎评测

OpenAI o 系列(o3 / o4-mini)—— 数学与量化推理。 期权收益结构建模、带概率分布的情景分析、研报中量化声明的验证。o 系列擅长的是每一步都必须逻辑验证的多步数学推理——这和 Claude 擅长的自然语言推理是不同的认知能力。

一个具体场景:风险评估视角需要衡量论点的不对称结构——“正确的话路径回报 4 倍,错了的话信心折损 1 倍”。这个 4:1 结构的数学验证走 o 系列,论点本身的逻辑构建走 Claude。两个模型各做各擅长的部分。

GPT-5.5 —— 视觉数据解析。 盈利演示文稿里的嵌入图表、扫描的监管文件、航运单据图像、卫星图像——这些纯文本模型处理不了。GPT-5.5 从视觉来源提取结构化数据,输出再输入 Claude 做推理。拆开来看就是:解析是一个任务,推理是另一个任务,最好的解析模型不一定是最好的推理模型。

Gemma 4 —— 预处理和分类。 初步新闻过滤、低优先级来源的摘要、常规翻译、元数据提取。这些任务不需要前沿模型,用能力足够但更便宜的选项就行。省下来的预算集中到模型质量真正影响结果的分析环节。

路由逻辑

模型选择不是随机的也不是手动的。我们定义了任务类别和显式路由规则。

  • 结构化分析推理(论点构建、证据链、对抗性审查)→ Claude
  • 量化验证和数学建模 → OpenAI o 系列
  • 视觉数据提取 → GPT-5.5
  • 预处理、分类和常规提取 → Gemma 4

路由发生在工作流层面,不是对话层面。单个研究流程可能依次调用三四个模型:Gemma 4 用于初步新闻分类,GPT-5.5 用于解析航运报告的视觉数据,Claude 用于构建分析论点,o 系列用于验证量化风险评估。每个阶段的输出输入下一阶段。人类研究员审核最终综合,而非中间路由。

为什么这对投资质量重要

多模型方法不是技术奢侈。它是对分析质量的直接投资。当你强制推理优化模型做量化计算时,你得到更慢且更不可靠的结果。当你强制视觉模型做长篇分析推理时,你得到浅薄的分析。当你用前沿模型做常规预处理时,你烧掉了本可以分配给模型质量会产生实质差异的任务的预算。

打个比方:我们不会让基本面分析师替风险评估做判断,同理也不会让推理模型替量化模型算数。模型分工的逻辑和分析分工的逻辑是一回事。

路由本身的成熟度问题

坦白说,上面写的路由规则看起来很干净,实际跑起来没那么利索。

几个还没完全解决的工程问题:

任务边界模糊。 “这个任务该走推理还是走量化?“——不是每次都判断得清楚。比如一份信用分析报告里既有定性的行业判断,又有 DCF 模型的参数敏感度测试。拆成两个子任务分别路由是对的,但怎么拆、在哪里切,目前还靠人工判断。自动化程度不够。

模型迭代导致路由失效。 上个季度 o3 在某类概率推理上表现最好,这个季度 Claude 更新后可能追上了。路由规则不是写一次就完事——每次主要模型更新都得重新跑 benchmark,决定是否调整分工。我们按季度做,但理想状态应该是持续的。

错误传播。 上游模型的输出喂给下游模型,如果上游出了错(比如 GPT-5.5 从图表里提取了一个错误数字),下游 Claude 会在错误数据上构建看起来很合理的因果链。目前靠人类研究员在关键节点抽查,还没有自动化的跨模型一致性校验。

成本不线性。 理论上预处理走便宜模型、核心推理走贵模型能省钱。实际上,当一个研究流程调用四个模型、每个模型跑多轮迭代时,总成本比”全部走一个好模型”未必低多少。省的是质量风险,不一定是钱。

这些问题没有让我们放弃多模型架构——单模型方案的天花板更低——但值得记录下来,免得把实际运行中的毛糙说得太光滑。