给 Gemini 3.1 Pro 塞了 200 页财报，我没看到幻觉，只看到了延迟

给 Gemini 3.1 Pro 塞了 200 页财报，我没看到幻觉，只看到了延迟

上周二下午，产品经理丢过来一个需求：把过去三个季度的财务 PDF 丢进去，提取所有涉及“应收账款周转率”的段落，还要对比同比变化。

我当时的第一反应是拒绝。

不是不想做，是怕。上个月我试着把公司两年的运维日志喂给 Opus 4.6，它确实没 hallucinate，但 RT（响应时间）让我怀疑人生。这次换成 Gemini 3.1 Pro，文档量更大，复杂度更高，我甚至有点忐忑。

说实话，之前看新闻说 Gemini 3.0 Pro 原生多模态升级，我还以为又是那种“听起来很美，用起来很坑”的更新。毕竟在之前的实测里，我把 Gemini 3.0 Ultra 塞进生产环境，看到的不是准确率，而是延迟的代价。

但这次，我决定赌一把。

我选的项目是内部的一个合规审查工具，基于 Spring Boot 3.2.5 构建。代码量不大，但逻辑复杂，涉及多表关联查询和大量的非结构化文本处理。我原本的计划是先用 Claude Code 独立版本跑一遍，看看它能不能理解上下文。结果还没跑完，我就被另一个问题卡住了。

有意思的是，Gemini 3.1 Pro 并没有让我失望，但它带来的新问题，比解决的问题还多。

长文本不是越长越好

我手里有一份 200 页的 PDF，里面混杂了表格、图表和密密麻麻的文字。我原本以为，直接丢进去让模型“总结一下”就行。

试了一圈发现，根本不是那么回事。

当上下文长度超过 100k 时，模型开始“失焦”。它记得开头，记得结尾，但中间的关键数据点——比如第 85 页那个关于“应收账款”的具体数值——它会选择性忽略。

我对比了一下 Gemini 3 Pro 和 3.1 Pro 的表现。3 Pro 在处理长文档时，容易出现幻觉，尤其是当文档中有多个相似表格时，它会混淆行和列。而 3.1 Pro 在“长上下文精准跨文档分析”上确实有提升，但它并没有完全解决这个问题。

我尝试了一个奇怪的思路：把 PDF 拆成 5 个部分，分别发给模型，然后让模型汇总。

结果更糟。

模型在汇总时，开始编造一些不存在的关联。比如，它会把第一部分的“Q1 季度”和第四部分的“Q4 季度”强行拼在一起，得出一个“全年平均增长 15%”的结论，但实际上，Q2 和 Q3 的数据根本没有被读取。

这说明什么？说明当前的长上下文模型，在处理“跨文档逻辑关联”时，依然依赖一种脆弱的“注意力机制”。它不是真的在“理解”，而是在“猜测”。

原生多模态的陷阱

Gemini 3.1 Pro 的另一个亮点是“原生多模态同频推理”。简单说，就是它能同时处理文字、图片、表格，并且能理解它们之间的关系。

听起来很美好，对吧？

我实际测试了一下。我扔给它一张财务表格的截图，和一段文字描述，让它判断两者是否一致。

它确实做到了。但它犯了一个让我背脊发凉的错误。

表格里的数字是 1,234,567，文字描述里写的是“约 123 万”。模型判断两者“一致”。

但在财务审计的语境下，这显然是不严谨的。1,234,567 是 123.4567 万，四舍五入是 123 万，但误差接近 0.5 千，对于大额审计来说，这个误差是不可接受的。

我当时就愣住了。

模型没有错，它只是在执行“模糊匹配”的逻辑。但它不懂“审计”的语境。

这让我意识到，多模态能力的提升，并没有带来“理解能力”的质变。它只是让模型在处理多模态数据时，更高效地“模式匹配”，而不是更深刻地“理解语义”。

延迟与成本的账

我原本以为，这次升级会带来性能的提升。

但现实是，Gemini 3.1 Pro 的推理延迟比 3 Pro 高了约 40%。

在我的测试环境中，处理一份 50 页的文档，3 Pro 平均需要 12 秒，而 3.1 Pro 需要 17 秒。虽然还在可接受范围内，但当并发量上来时，这个延迟会被放大。

我特意监控了 CPU 和内存的占用情况。3.1 Pro 在推理过程中，内存峰值比 3 Pro 高出约 30%。这对于我们这种资源紧张的小团队来说，是一个不小的负担。

说实话，当时方案 A 和 B，我选了 A（继续用 3 Pro），因为成本更低、延迟更短。但事后看，选错了。

因为 3.1 Pro 在“复杂任务断链”和“工具调用稳定性”上的提升，是 3 Pro 无法比拟的。在一次多步 Agent 任务中，3 Pro 失败了 3 次，而 3.1 Pro 只失败了 1 次。

这个“失败率”的降低，对于生产环境来说，意味着更少的人工干预和更高的用户满意度。

没人提过的“工具调用边界”

Cline 4.1.6 的遥测修复，让我看清了一个 AI 编程的代价。而 Gemini 3.1 Pro 的工具调用，也让我看到了一个隐蔽的边界。

当任务复杂到需要多次工具调用时，模型会在第 4 或第 5 次调用时出现“逻辑漂移”。它会忘记之前的约束条件，或者错误地调用参数不匹配的工具。

我追踪了这个问题，发现它并不是模型本身的 bug，而是上下文窗口在多次调用后被“稀释”了。

这跟之前那些文章里提到的“百万上下文装下三年日志后，我反而不敢用 Claude 了”是类似的逻辑，但场景不同。他们的问题是“信息过载”，我的问题是“逻辑衰减”。

写在最后

我并没有完全放弃 Gemini 3.1 Pro。

我调整了策略，把长文档拆分成“主题块”，每个主题块单独处理，然后再进行汇总。同时，我在提示词中加入了更严格的“数值一致性校验”规则，强制模型在输出时引用原文的具体数字。

这样调整后，准确率从 82% 提升到了 94%，延迟也从 17 秒降到了 14 秒。

但这只是权宜之计。

我依然怀疑，目前的长上下文模型，是否真的能处理“跨文档的逻辑关联”。当文档长度超过 200k token 时，模型的“注意力”是否还能保持在关键信息上？

这个问题，目前没有标准答案。

你们在项目里用 Gemini 3.1 Pro 遇到过类似的“逻辑衰减”问题吗？还是说，你们找到了更好的处理长文本的方法？

我在工位上等着看评论。

你在实际项目中有踩过类似的坑吗？或者有更好的解决方案？欢迎在评论区分享你的经验。