1. 为什么模型数量不是AI投研工具的护城河
1.1 一个被反复验证的行业错觉
过去两年，我参与过三个AI投研类产品的从零搭建，也帮不少团队做过技术选型咨询。一个特别普遍的现象是：几乎每个项目立项时，团队最兴奋的讨论都集中在“我们要接多少个模型”上。GPT-4、Claude、Gemini、文心、通义、Kimi、DeepSeek……列一张表，恨不得把市面上叫得出名字的全接进来，仿佛模型数量就是产品竞争力的直接体现。
但真正上线跑三个月之后，数据会告诉你一个残酷的事实：用户根本不关心你背后用了几个模型，他们只关心你给出的结论能不能用、敢不敢用、好不好用。
我见过一个团队，接了七个大模型，做了复杂的路由分发，结果用户留存率还不如另一个只用一个模型但把投研工作流打磨到极致的竞品。这不是个案，这是行业里反复上演的剧本。
1.2 投研场景的特殊性：容错率极低
投研和通用聊天机器人有本质区别。你跟AI闲聊，它说错一句话你笑笑就过去了。但在投研场景里，一个数字错误、一个逻辑跳跃、一个数据来源不可靠，都可能导致用户做出错误的判断。这意味着投研工具的核心竞争力不在“能生成什么”，而在“生成的东西有多可靠”。
模型数量多，反而可能带来一个隐蔽的问题：不同模型对同一个问题的回答不一致时，你怎么办？我实测过，让五个主流模型分析同一份财报，关于“经营性现金流是否健康”这个判断，五个模型给出了三种不同结论。如果你只是简单地把它们的结果拼在一起呈现给用户，那不是智能，那是添乱。
1.3 真正的竞争力在哪里
我的观察是，AI投研工具的竞争力集中在三个层面，而且这三个层面都和模型数量无关：
- 数据管道的质量：你能不能拿到及时、准确、结构化的数据，并且把它们清洗成模型能理解的格式。这一步做不好，后面用再强的模型也是垃圾进垃圾出。
- 工作流的编排能力：投研不是一问一答，而是一个多步骤的推理过程。拆解问题、检索数据、计算指标、交叉验证、生成结论，每一步都需要精心设计。
- 输出结果的可验证性：用户能不能追溯每一个结论的数据来源和推理链条。这决定了用户敢不敢把你的输出写进自己的研究报告里。
下面这张表是我总结的“模型数量导向”和“工作流导向”两种思路的对比，你可以对照看看自己的项目处于哪个状态：
| 维度 | 模型数量导向 | 工作流导向 |
|---|---|---|
| 核心指标 | 接入模型数 | 任务完成准确率 |
| 技术难点 | API对接与路由 | 数据管道与推理链设计 |
| 用户感知 | 感知弱，容易同质化 | 感知强，形成使用依赖 |
| 迭代方向 | 追新模型 | 优化特定场景的准确率 |
| 竞争壁垒 | 低，谁都能接 | 高，需要领域积累 |
2. 投研工作流的核心环节拆解
2.1 从用户提问到最终输出：一条完整的链路
一个典型的AI投研工具，用户输入可能是“帮我分析一下这家公司最近三个季度的毛利率变化趋势及原因”。这句话看起来简单，但背后需要完成的工作量远超大多数人的想象。
我把它拆成六个环节：意图识别 → 数据检索 → 数据预处理 → 分析计算 → 推理生成 → 结果校验。每个环节都有各自的坑，而且这些坑跟用哪个模型关系不大，更多是工程和领域知识的问题。
意图识别环节，用户说的“毛利率”可能指的是不同口径，是整体毛利率还是分产品毛利率？是GAAP还是Non-GAAP？如果这一步不澄清，后面全错。我的做法是建一个投研领域的意图分类体系，用少量标注数据微调一个轻量模型专门做这件事，而不是丢给大模型去“理解”。
数据检索环节更考验工程能力。财报数据、行情数据、公告文本、研报观点，来源不同、格式不同、更新频率不同。你需要建统一的数据层，把结构化数据存进时序数据库，把非结构化文本做向量化处理。这里我踩过最大的坑是：向量检索的召回率在专业领域远低于预期。通用embedding模型对“EBITDA margin”和“息税折旧摊销前利润率”的语义相似度判断经常出错，后来我们换成了在金融语料上微调过的embedding模型，召回率才从62%提升到89%。
2.2 数据预处理：最不起眼但最致命的环节
很多人把数据预处理当成脏活累活，觉得没什么技术含量。但我的经验恰恰相反：投研工具的输出质量，70%取决于数据预处理的质量。
举个具体的例子。财报里的数字有单位，有正负号，有括号表示负数的情况，有“—”表示未披露的情况。如果你不处理干净，模型看到的就是一堆混乱的字符。我见过一个工具把“营业收入（万元）”后面的数字直接当成“元”来处理，结果所有财务指标都放大了10000倍，用户差点据此做出错误决策。
我的做法是建一套数据校验规则，至少包括：
- 单位一致性检查：同一张表里的数字单位必须统一
- 勾稽关系验证：利润表的净利润要和资产负债表的未分配利润变化对得上
- 异常值标记：同比变化超过阈值的自动标记待人工复核
- 缺失值处理：明确区分“未披露”和“为零”
这些规则听起来简单，但真正落地需要你对财务体系有深入理解。这也是为什么纯技术团队做投研工具往往不如有金融背景的团队做得好的原因。
2.3 分析计算：该用代码的地方别用模型
这是我想重点强调的一个原则。很多团队为了追求“AI感”，把所有环节都交给大模型处理，包括数值计算。这是一个巨大的错误。
大模型做算术的准确率，即使在最好的情况下也不如一行Python代码。你让模型去算一个同比增长率，它可能给你一个看起来合理但实际错误的结果。而且这种错误很隐蔽，用户如果不自己验算根本发现不了。
我的原则是：能用确定性代码完成的，绝不交给模型。指标计算、同比环比、排序筛选、统计汇总，全部用代码实现。模型只负责它真正擅长的事情：理解自然语言、提取关键信息、生成解释性文字。
具体来说，我会把投研分析拆成两类任务：
- 确定性任务：数值计算、数据查询、条件筛选、格式转换 → 代码实现
- 非确定性任务：意图理解、文本摘要、观点提取、结论生成 → 模型实现
这个边界划清楚之后，整个系统的准确率和可维护性都会大幅提升。
2.4 推理生成：提示词工程只是冰山一角
说到模型环节，大多数人第一反应是提示词工程。但我的经验是，在投研场景里，提示词的重要性被高估了，上下文管理的重要性被严重低估了。
什么叫上下文管理？就是你在调用模型之前，往它的上下文窗口里放什么信息。放多少数据？放哪些数据？以什么格式放？这些决策对输出质量的影响远大于提示词怎么写。
我做过一个对比实验：同一份财报数据，一种方式是直接把原始文本塞进上下文，另一种方式是先提取关键财务指标做成结构化表格再塞进去。用同样的提示词，后者的准确率比前者高出34个百分点。原因很简单：模型在大量无关文本中找关键信息的能力有限，你帮它把信息整理好，它就能把精力放在推理上。
还有一个容易被忽视的点是上下文长度和模型表现的关系。不是上下文越长越好。我实测发现，当上下文超过一定长度后，模型对中间部分信息的利用率会明显下降。所以我现在会做上下文压缩，把最相关的信息放在开头和结尾，中间放次要信息。
3. 多模型协作的正确打开方式
3.1 什么时候需要多个模型
我不是说多模型一定不好。在某些场景下，多模型协作确实能带来价值。但前提是你要清楚为什么要用多个模型，而不是为了多而多。
我总结了几种真正需要多模型的场景：
场景一：任务类型差异大。投研工具里既有需要强推理的分析任务，也有需要快速响应的查询任务，还有需要处理长文档的摘要任务。不同任务对模型的能力要求不同，用同一个模型可能在某些任务上表现不佳。
场景二：成本敏感。简单任务用便宜的小模型，复杂任务用贵的大模型，这是合理的成本优化策略。但前提是你要能准确判断任务难度，否则可能省了小钱亏了大钱。
场景三：需要交叉验证。对于关键结论，用两个不同模型分别生成，然后对比差异。如果两个模型结论一致，可信度就高；如果不一致，就标记出来让用户注意。这个思路在投研场景里特别有价值。
3.2 多模型路由的工程实现
如果你确定要用多模型，路由层的设计就很关键。我的做法是建一个任务分类器，根据输入的特征决定用哪个模型。这个分类器可以是一个轻量模型，也可以是一套规则。
具体实现上，我会维护一个模型能力矩阵，记录每个模型在不同任务类型上的表现：
| 任务类型 | 模型A | 模型B | 模型C | 选择策略 |
|---|---|---|---|---|
| 财务指标提取 | 92% | 88% | 85% | 优先A，A超时降级B |
| 长文档摘要 | 78% | 91% | 82% | 优先B |
| 推理分析 | 85% | 83% | 90% | 优先C |
| 简单查询 | 95% | 94% | 93% | 选成本最低的 |
这张表需要定期更新，因为模型版本在变，你的数据分布也在变。我一般每两周跑一次评测，根据最新数据调整路由策略。
3.3 多模型输出的融合策略
多个模型给出不同答案时怎么处理？我试过几种策略：
- 投票法：多数一致的结果作为最终输出。简单但粗糙，适合事实性问题。
- 置信度加权：根据每个模型的历史准确率加权。需要维护准确率数据。
- 差异呈现：把不同结果都展示给用户，让用户自己判断。适合分析类问题。
- 仲裁模型：用一个更强的模型来评判哪个答案更好。成本高但效果好。
实际使用中，我会根据问题类型选择不同策略。事实性问题用投票法，分析类问题用差异呈现，关键决策用仲裁模型。
4. 实操中踩过的坑与解决方案
4.1 数据质量问题的排查思路
数据问题是最难排查的，因为它往往不会直接报错，而是以一种隐蔽的方式影响输出。我总结了一套排查流程：
第一步：确认数据源。检查数据是从哪个接口来的，接口返回的原始数据长什么样。很多时候问题出在数据源本身，而不是你的处理逻辑。
第二步：检查中间结果。在数据管道的每个环节打日志，记录数据的形态和关键统计量。这样当最终输出异常时，你可以快速定位是哪个环节出了问题。
第三步：对比基准。拿你的输出和权威数据源做对比。比如你算的毛利率和Wind上查到的差了多少，差异在哪个方向。
第四步：构造测试用例。把发现的问题固化成测试用例，每次更新代码都跑一遍，防止回归。
4.2 模型幻觉的识别与抑制
投研场景里模型幻觉是致命的。我遇到过模型编造不存在的财务数据、引用不存在的研报、给出没有依据的结论。抑制幻觉的方法我试过很多，有效的有这几个：
- 强制引用：要求模型每个结论都必须附带数据来源，没有来源的结论直接丢弃
- 数值校验：模型输出的所有数字都要和数据库里的原始数据比对，不一致的标记出来
- 逻辑链检查：让模型把推理步骤写出来，然后检查每一步是否有依据
- 温度调低：投研场景不需要创造性，把温度调到0.1以下能显著减少幻觉
但说实话，完全消除幻觉目前做不到。所以我的策略是假设模型一定会出错，在设计上让错误容易被发现和纠正。比如所有关键数字都用代码计算而不是模型生成，模型只负责解释和总结。
4.3 性能与成本的平衡
投研工具的用户往往对响应速度有要求，但大模型的推理速度摆在那里。我的做法是分层处理：
- 即时响应层：常见查询走缓存或轻量模型，响应时间控制在1秒内
- 标准分析层：常规分析任务走主力模型，响应时间5-15秒
- 深度分析层：复杂分析任务走最强模型，响应时间30秒以上，但会先给用户一个进度提示
成本控制方面，我会监控每个模型的token消耗和对应的任务完成率，定期优化路由策略。一个实用的技巧是：对输入做压缩，对输出做限制。输入压缩能省大量token，输出限制能防止模型啰嗦。
5. 从项目实践看投研工具的未来方向
5.1 领域知识比模型能力更重要
做了这几个项目之后，我越来越确信一件事：在垂直领域，领域知识的注入比模型能力的提升更能带来效果改善。
同样的模型，你给它喂了高质量的领域数据、设计了符合领域逻辑的工作流、加入了领域专家校验环节，输出质量能提升一个档次。反过来，你用最强的模型但不懂投研业务，做出来的东西用户一眼就能看出外行。
所以我现在做项目，技术选型上不会花太多时间纠结用哪个模型，而是把精力放在领域知识库的建设、工作流的打磨、以及和领域专家的深度合作上。
5.2 可解释性是投研工具的生死线
投研用户和普通用户最大的区别是：他们需要为自己的决策负责。所以他们对工具的要求不是“给我一个答案”，而是“告诉我这个答案是怎么来的”。
这意味着你的工具必须做到：
- 每个数据点都能追溯到原始来源
- 每个计算步骤都能展示中间结果
- 每个结论都能给出推理依据
- 每个不确定性都能明确标注
这些要求跟模型能力关系不大，更多是产品设计和工程实现的问题。但恰恰是这些“不性感”的工作，决定了用户会不会真正把你的工具用起来。
5.3 我个人的一点判断
如果你正在做AI投研工具，或者打算做，我的建议是：先把一个场景做透，再考虑扩展。不要一上来就想着覆盖所有投研需求，选一个最痛的场景，比如财报分析、比如公告解读、比如行业对比，把这个场景的准确率做到90%以上，让用户真正敢用、愿意用。
模型方面，选一个主力模型深入打磨，把上下文管理、提示词、输出校验都做到位。等这个场景跑通了，再考虑引入第二个模型做补充或交叉验证。
这个路径看起来慢，但实际上是最快的。我见过太多团队在模型选型上反复横跳，今天换这个明天换那个，最后什么都没积累下来。反而是那些认准一个方向深耕的团队，做出了真正有竞争力的产品。
最后分享一个我在实际项目中总结的小技巧：建一个“错误案例库”，把每次发现的错误输出都记录下来，标注原因和修复方式。这个库是你最宝贵的资产，它比任何模型评测榜单都更能指导你的优化方向。每次迭代前翻一翻这个库，确保同类错误不再出现，你的工具就会越来越可靠。
