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

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

按问题选择策略

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

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

分段前建立来源记录

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

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

{
  "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 证据提取。

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

用边界案例比较方案

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

先用评估表做预算内小样本，再按成本指南核账。本篇没有执行评测。2026-11-03 通过 GPT-6.1 Sol、Claude 模型、Gemini 模型及平台协议指南核对身份和协议，不承诺固定上下文容量。