Gemini 2.5 进阶用法：从入门到精通

一个让我头疼的问题

上个月我在做一件事：分析一个 40 万字的法律合同语料库，提取其中的违约条款并做分类。之前用普通模型，要么上下文塞不下，要么塞进去了后半段就开始“失忆”。我试过把文档切成小块分别处理，结果跨文档的关联信息全丢了——比如 A 合同里引用了 B 合同的条款，切块之后就断了。

后来我把这套流程迁移到 Gemini 2.5 Pro 上，配合它的长上下文和思考模式，整体准确率提升明显，而且省掉了大半的工程量。这篇文章就把我的完整踩坑过程整理出来，从基础设置讲到进阶技巧。

第一步：理解三个核心能力

在动手之前，你得先知道 Gemini 2.5 和普通模型差别在哪：

1. 超长上下文：100 万 token 的窗口，一本长篇小说可以直接整个扔进去
2. 思考模式（Thinking）：模型会在回答前先“打草稿”，适合推理密集的任务
3. 原生多模态：PDF、图片、音频、视频都能直接读，不用先转文本

我一开始犯的错误是把它当成普通模型用——每次都只发一小段文字。这就像买了辆卡车却只用来送快递信件。

第二步：思考预算的正确用法

这是我觉得最被低估的功能。通过 thinkingBudget 参数可以控制模型“思考”多少：

from google import genai
from google.genai import types

client = genai.Client(api_key="YOUR_KEY")

response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents="分析这段合同条款是否存在对我方不利的陷阱条款",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(
            thinking_budget=8192
        )
    )
)

我的实战经验：

• 简单的改写、翻译任务，把 thinking_budget 设成 0（2.5 Flash 支持关闭），速度快、成本低
• 数学推导、代码调试、法律分析这类任务，给到 4096–16384，效果差距非常明显
• 我做过对比：同一批 50 道逻辑题，关闭思考的正确率约 70%，开到 8192 预算后到了 92%，但延迟从 2 秒涨到 15 秒左右

踩过的坑：一开始我给所有任务都开满思考预算，结果一个批量处理 500 条文本的任务跑了快一个小时。后来我学会按任务类型分流——写个简单的路由判断，短文本直出，复杂任务才开思考。

第三步：长文档的正确投喂方式

回到开头那个合同分析的例子。我直接把整个语料库（转成文本约 30 万 token）一次性传进去：

from google.genai import types

# 上传大文件走 Files API，而不是塞在 prompt 里
doc = client.files.upload(file="contracts_all.pdf")

response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents=[
        types.Part.from_uri(file_uri=doc.uri, mime_type=doc.mime_type),
        "找出所有违约责任条款，按'赔偿金额明确/仅原则性约定/缺失'三类整理成表格"
    ]
)

几个关键发现：

• 超过 20MB 或很长的 PDF 一定要走 Files API，直接 base64 塞请求里又慢又容易报错
• “中间信息丢失”现象是真实存在的。我把关键指令放在 prompt 最后面，比放在开头效果好。所以我的模板是：背景介绍放开头，具体任务指令和输出格式要求放结尾
• 对于超长文档，先用一个便宜的调用让模型生成文档结构摘要，再针对相关章节做精读，比一次性硬读更省钱且效果稳定

第四步：结构化输出，告别正则解析

以前我让模型输出 JSON，经常因为多一个逗号导致解析失败。Gemini 2.5 支持强制 JSON Schema：

import pydantic

class BreachClause(pydantic.BaseModel):
    clause_id: str
    category: str  # 明确金额/原则性约定/缺失
    summary: str
    risk_level: int  # 1-5

response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents=long_doc_text,
    config=types.GenerateContentConfig(
        response_mime_type="application/json",
        response_schema=list[BreachClause]
    )
)
clauses = response.parsed  # 直接就是 Pydantic 对象列表

用了这个之后，我的解析失败率从大概 5% 降到 0。强烈建议所有批量提取任务都用 Schema 约束，别靠 prompt 里写“请输出 JSON 格式”这种祈祷式做法。

第五步：结构化提示词模板

分享我现在稳定使用的模板，针对长上下文场景调优过：

【角色】你是一名资深合同审查律师。

【背景】以下是某公司 2023 年签署的全部供应商合同合集。

【任务】
1. 定位所有违约责任相关条款
2. 按风险等级分类
3. 标注条款所在的合同名称和章节

【约束】
- 不要推测文档中不存在的内容
- 引用时保留原文编号
- 找不到的类别输出空数组，不要编造

【输出格式】
（这里放 JSON Schema 或示例）

【文档开始】
{document}
【文档结束】

现在开始执行任务 1-3。

注意任务指令在文档之后——这是我反复测试后效果最好的排布。

实用技巧汇总

• 温度别乱调：提取、分类任务用 temperature=0 到 0.2，创意写作才往上加
• 用 2.5 Flash 做初筛：我的流程是 Flash 快速扫描定位相关段落，Pro 精读分析，成本降了 80%
• 缓存长上下文：同一个文档要问多个问题时，用 context caching，重复内容的费用大幅降低
• 视频理解很能打：我试过丢一个 40 分钟的会议录像进去要纪要，它真的能看完并带时间戳输出，这省了我好几个小时的回放工作

局限性，说实话

1. 长上下文不等于完美记忆：80 万 token 的文档里，中间部分的细节召回仍然不如开头结尾，关键信息最好出现在首尾
2. 思考模式慢：交互式场景下 15 秒以上的延迟体验很差，适合后台批处理
3. 价格不便宜：Pro 模型长上下文跑满一次成本不低，量大的任务务必先在小样本上验证 prompt，再放量
4. 中文长文档分词偶有瑕疵：处理扫描版 PDF 中文合同时时有错字，重要场景建议人工抽查

总结

Gemini 2.5 真正的价值在于把原来需要“切块 + 检索 + 拼接”的复杂管道简化成一次调用。但前提是你得会用：按任务分配思考预算、用 Schema 锁定输出、Files API 处理大文件、Flash+Pro 分层调用。掌握这四招，它就能从“聊天玩具”变成真正的生产力工具。