# 长文档 LLM 最佳实践：全文、分段提取还是检索后回答

更大的上下文额度并不能直接决定文档处理方式。无论 GPT、Claude 还是 Gemini，都先判断用户需要全局综合、完整清单，还是某一小部分内容的答案。本篇比较应用设计方法，不做上下文长度排名，也不暗示平台内置检索服务。

## 按问题选择策略

| 策略 | 适合尝试的情况 | 主要待验证问题 | 额外工作 |
| --- | --- | --- | --- |
| 全文输入 | 有限文档需要跨章节推理 | 内容已提供，但重要细节仍被忽略 | 测量请求规模，验证完整性 |
| 分段提取再合并 | 每节都需执行同样的提取 | 关系跨越分段边界或结果重复 | 稳定来源 ID、重叠策略、合并规则 |
| 检索后回答 | 大资料库中大量问题只涉及少量片段 | 相关证据根本未送到模型 | 索引、检索评估与访问过滤 |

没有一种天然最便宜或最准。全文可能反复发送大量输入，分段增加调用和合并步骤，检索需要基础设施并可能遗漏关键依据。对比时纳入实际应用成本与模型费用。

## 分段前建立来源记录

保留文档 ID、版本、章节 ID 和原始顺序。删除的套话若可能影响理解，应明确记录。表格行要带表头，数值要带单位；错误拆表可能改变含义，却不会报语法错。

下面是本地应用记录，不是 LLM API 请求，也不是平台上传端点：

```json
{
  "document_id": "release-plan-demo",
  "version": "v1",
  "chunks": [
    {"id": "section-a", "order": 1, "text": "Cedar 计划于 11 月 12 日发布，该日期为暂定。"},
    {"id": "section-b", "order": 2, "text": "最终日期取决于 C 节的无障碍审核。"},
    {"id": "section-c", "order": 3, "text": "无障碍审核尚未完成。"}
  ]
}
```

询问“已确认的发布日期”时，只有 A 节不足以回答。全文方案应保留暂定状态，分段方案应保留指向 C 节的依赖，检索方案不能只抓到包含日期的段落。这个样例展示失败模式，不是模型实测结果。

## 为真实响应预留空间

按所选模型的计量方式计算或估算整个请求，包括任务说明、原文、会话历史和已启用的工具定义。字符数不是通用 token 数。检查平台当前输入输出限制并为所需输出留空间，上游宣传额度不等于路由有效额度。

使用原生输出字段：已文档化的 GPT Chat 路由使用 `max_completion_tokens`，Claude Messages 使用 `max_tokens`，Gemini 内容请求使用 `generationConfig.maxOutputTokens`。不同 tokenizer 与推理行为下，相同数字不代表相同可见输出预算。检查原生结束状态，不能因为表格语法完整就认为内容完整。

## 合并证据，而不只是合并摘要

要求每段结果带来源 ID 和未解决的跨段引用。只有描述同一事实的证据才能去重，冲突陈述保留供后续复核。“摘要的摘要”可能丢掉例外，紧凑的证据表通常更方便人工审计。逐行检查方法见 [Claude 证据提取](/zh/docs/llm/claude-evidence-extraction)。

检索流程应先检查需要的来源是否被选中，再评价生成模型。区分“没有检索到”与“提供了但没有使用”。将内容发送给模型前执行文档权限过滤，不能让回答包含用户无权查看的资料。

## 用边界案例比较方案

样例应包含跨章节依赖、重复名称、冲突日期、表格单位和分段边界附近的事实。记录答案验收、遗漏来源、调用次数、人工时间和实际总成本。索引与检索开销和模型用量分开记录，不凭假设计算缓存优惠。

先用[评估表](/zh/docs/llm/evaluation)做预算内小样本，再按[成本指南](/zh/docs/llm/cost-and-usage)核账。本篇没有执行评测。2026-11-03 通过 [GPT-6.1 Sol](https://developers.openai.com/api/docs/models/gpt-6.1-sol)、[Claude 模型](https://platform.claude.com/docs/en/models/overview)、[Gemini 模型](https://ai.google.dev/gemini-api/docs/models)及平台[协议指南](/zh/docs/llm/protocols)核对身份和协议，不承诺固定上下文容量。