长文本大模型选型与长文档解析落地教程

一、教程目标

本教程要解决一个很具体的工程问题：如何把”能处理超长上下文”的大模型能力，真正接入到业务系统里，稳定地完成长文档的解析、归纳与问答。

完成本教程后，你应该能够独立做到以下几点：

• 判断自己的文档到底需要”长上下文直传”还是”分段+汇总”，而不是盲目追求最大 token 数；
• 建立一套可复用的长文档处理流水线（解析 → 清洗 → 分段 → 提示词 → 调用 → 校验）；
• 准确估算一次调用消耗的上下文预算，避免输入截断导致的报错或关键信息丢失；
• 用可量化的方法验证输出质量，而不是”看着还行就上线”；
• 定位长文本场景特有的故障（中间信息衰减、条款号幻觉、输出格式不稳定、延迟与费用飙升）。

本教程不涉及模型训练与微调，聚焦”调用侧”的工程实现。

二、适用场景

长上下文能力的典型受益场景包括：

• 单篇超长文档理解：论文、书籍章节、财报、法律文本、技术规范、标书；
• 多文档汇总：把十几份同类合同或报告放在一个上下文里做横向对比与差异提取；
• 全量代码理解：一次性把小型代码仓库的关键文件交给模型做架构梳理或风险评估；
• 超长对话与多轮记忆：客服、咨询类场景中保留完整历史上下文；
• 长会议记录/多场访谈的纪要生成：跨段落归并议题、待办与决议。

反过来说，如果你的任务只是”在几千字里找一句话”，那么向量检索加短上下文通常更快更便宜，没有必要上长上下文方案。

三、前置知识：先把”长文本”这件事量化

3.1 token 与字数的换算关系

大模型计费与长度限制的单位是 token，不是字数。中文与 token 的换算比例随分词器实现不同而变化，业界常见的经验区间是 1 个汉字约等于 1～2 个 token。行业内的一个常见对照是：某类长文本模型对外宣称支持约 200 万字中文输入，按上述比例折算约为 400 万 token 量级。

结论很明确：不要凭感觉估算，要用实际分词器统计。在方案评估阶段，就应该拿 50～100 份真实业务文档跑一遍统计，得出长度分布的 P50、P95、P99 值。

3.2 上下文窗口的真实构成

一次调用的 token 消耗 = 输入 prompt + 参考文档 + 系统指令 + 模型输出。也就是说，输入与输出通常共享同一个窗口额度。这意味着：

• 你申请了 100 万 token 的窗口，不代表能塞进 100 万 token 的文档还期待模型输出长篇报告；
• 想要”输入全文 + 输出 5 万字摘要”，必须确认输出侧上限是否支撑；
• 输出侧 token 的单价通常高于输入侧，这是长文本成本的主要来源之一。

3.3 长上下文的核心价值与已知局限

价值方面，长上下文带来的不只是”塞得下”，更关键是：

1. 文档级指代消解：跨章节的”前述条款””该标的””上述主体”能被正确解析；
2. 减少切分损耗：传统分块检索会在切分边界上丢失语义连贯性；
3. 结构化输出更完整：能基于全局视角生成提纲、对比表和一致性检查结论。

局限同样需要提前认知：

• 中间信息衰减：业界普遍观察到模型对上下文首尾内容的关注度高于中间部分，超长输入时尤甚；
• 延迟与成本随长度非线性上升；
• 输出稳定性下降：上下文越长，格式偏差与遗漏的概率越高。

四、前置准备

类别	具体准备项	说明
开发环境	支持 HTTP/JSON 的开发语言运行时、文件解析库、可选 OCR 能力	通用技术栈即可，无需特定工具
权限凭据	大模型服务的访问密钥、对应配额	密钥必须走环境变量或密钥管理服务，禁止硬编码入库
存储组件	对象存储、可选的向量检索能力	用于存放原始文档、切分结果与向量索引
网络条件	服务端可访问模型服务的网络出口、超时策略	生产环境建议走专线或 VPC 内网通道
数据合规	脱敏规则、数据留存策略、审计要求	涉及个人信息、商业秘密的文档需先评估
基础知识	提示词工程、JSON 结构约定、重试与幂等概念	—

如果业务系统本身运行在百度智能云上，可以直接复用其对象存储、身份认证、日志与监控、消息队列等通用云能力来承载流水线中的存储、鉴权与可观测环节，无需额外引入组件。

五、实施步骤

步骤 1：盘点文档特征，确定技术路线

做什么：统计文档的格式分布、平均与 P95 长度、是否含大量表格与扫描件、是否需要引用溯源。

为什么：路线选择完全由数据驱动。若 95% 文档在窗口的 60% 以内，直接长上下文直传最简单可靠；若存在大量超出窗口的文档，必须设计分段汇总。

注意：不要只用”平均长度”决策，长尾的超长文档往往是故障来源。

步骤 2：建立选型评估矩阵

原始问题中”哪个模型最有前途”本质上是个选型问题，但正确做法是用自有数据评测，而不是看参数榜单。建议的评估维度：

• 上下文窗口大小（输入侧 / 输出侧分别确认）；
• 长文本效果衰减程度（用尾部关键信息召回率测试）；
• 结构化输出稳定性（要求 JSON 时的合规率）；
• 并发限制与限流策略；
• 计费方式（按 token 输入/输出分别计价、是否有长文本阶梯价）；
• 数据合规与留存政策；
• 是否支持流式输出、是否支持批量异步任务。

评测方法：准备一个 50～100 份的评测集，标注”标准答案要点”，让候选方案各跑一遍，记录要点召回率、格式合规率、平均延迟、单次成本四项指标。这比任何排行榜都可靠。

步骤 3：封装统一的模型调用层

做什么：把所有模型调用收敛到一个客户端类里，屏蔽 endpoint、模型标识、鉴权方式等差异。

为什么：一是便于后期换模型而不动业务代码；二是集中实现超时、重试、日志、token 计量，避免每个业务分支各写一套。

注意：客户端层必须记录每次调用的 prompt_tokens、completion_tokens 与耗时，这是后续成本优化的唯一可靠依据。

class LLMEndpoint:
    """通用模型调用封装（字段名以实际服务文档为准）"""
    def __init__(self, endpoint: str, model: str, credential: str,
                 timeout_s: int = 120, max_retry: int = 3):
        self.endpoint = endpoint
        self.model = model
        self.credential = credential          # 从密钥管理服务注入
        self.timeout_s = timeout_s
        self.max_retry = max_retry
    def complete(self, messages, temperature=0.2,
                 max_output_tokens=4096, stream=False):
        # 1) 组装请求体  2) 发送并处理响应
        # 3) 记录 usage 与耗时  4) 异常按可重试/不可重试分类
        ...
        return {"text": "...", "usage": {"prompt_tokens": 0,
                                         "completion_tokens": 0}}

步骤 4：文档预处理与清洗

做什么：

• 格式归一化：PDF、Word、Excel、HTML、纯文本统一转换为带结构的中间表示（段落 + 标题层级 + 表格）；
• 清洗噪声：页眉页脚、水印、目录页、重复空行、页码；
• 表格处理：保留行列结构而非拉平成文本，必要时转 Markdown 表格；
• 扫描件：先做文字识别，并对识别置信度低的段落标记告警；
• 位置映射：为每个段落记录”原始页码 + 段序偏移”，用于最终输出的引用溯源。

为什么：预处理质量决定输出质量上限。 garbage in, garbage out 在长文本场景尤其明显——页眉页脚反复出现会挤占窗口并干扰模型判断文档边界。

注意：不要在预处理阶段做”摘要式压缩”，那会丢失后续推理所需的细节。

步骤 5：设计上下文装配策略

根据文档长度选择不同策略：

策略 A：整篇直传（长度 ≤ 窗口的 70%～80%）
最简单可靠，保留全局视野。适合单篇长文档理解。

策略 B：结构提纲先行 + 分章处理
先让模型基于目录或首轮扫描输出文档提纲，再按提纲逐章节处理并回填结果，最后做一次全局一致性合并。适合超长书籍、规范类文档。

策略 C：分段 + 层次摘要（Map-Reduce）
第一段映射：把文档切成带重叠的块，逐块抽取要点，输出结构化要点列表；
第二段归约：把要点列表合并去重，生成全局摘要；
第三段细化（Refine，可选）：针对全局摘要发现的可疑点，回原文对应块重新核对。

策略 D：检索增强 + 局部长上下文
先用向量检索召回与问题最相关的 N 个片段，再把这些片段（而非全文）拼成上下文。适合”问答式”而非”总结式”任务，成本与延迟最优。

关键工程细节：

• 切分要优先按语义边界（章节、条款、段落）而非固定字符数硬切；
• 块之间保留 10%～15% 的重叠，避免边界句子被切断；
• 每个块前面必须附带”全局定位信息”：文档标题、章节路径、本块序号/总块数。否则层次摘要阶段会大量产出”本节介绍了……”这类无法定位的空洞要点。

步骤 6：编写结构化提示词

推荐的提示词骨架（按顺序）：

[角色] 你是一名严谨的文档分析助手。
[任务] 对输入文档生成结构化归纳。
[输入] 文档标题、章节路径、正文内容（用明确分隔符包裹）
[输出格式] 严格输出 JSON，字段为：
    summary(≤300字)、key_points(数组，每点≤50字)、
    risk_items(数组)、citations(数组，每项含 section 与 quote)
[约束] 只允许基于文档内容作答；无法确认的内容写入 unknown 列表；
       引用必须是原文连续片段，禁止改写后当作引用。
[禁止] 不得推测文档中不存在的条款编号、金额、日期。

要点说明：

• 低温参数：总结类、抽取类任务建议温度设为 0～0.3，保证多次运行结果稳定可复现；
• 强约束输出格式：优先用服务支持的 JSON 模式或函数调用能力，若只能依赖提示词约束，则必须在代码侧做格式校验与失败重试；
• 要求引用原文：这是长文本场景最有效的抗幻觉手段——引用不可溯源即视为不可信输出；
• 明确”不知道”出口：给模型一个表达不确定性的合法通道，能显著降低编造概率。

步骤 7：编排任务与并发控制

做什么：

• 单篇任务：解析 → 分段 → 逐段/逐块调用 → 归约 → 输出；
• 批量任务：进入消息队列，按限流额度控制并发消费；
• 长任务：改为异步任务 + 结果回查，避免同步请求长时间挂起。

为什么：批量文档处理是典型 IO 密集型任务，串行执行会让吞吐被单次延迟锁死；但并发过高会触发限流，需要在吞吐与稳定性之间取平衡点。

注意：所有写操作要设计幂等键（如”文档指纹 + 块序号”），否则重试会导致重复计费和重复数据。

步骤 8：异常处理与容错

异常类型	典型表现	处理策略
输入超长	请求被拒绝或参数校验失败	按预算动态截断/降级到分段模式
限流	状态码与频率限制提示	指数退避 + 抖动，控制并发上限
超时	长输入下响应耗时过长	提高超时阈值、启用流式、缩小单次输入
输出格式不合规	JSON 解析失败	校验失败后携带错误说明重试，最多 N 次
服务不可用	5xx 类错误	熔断 + 队列缓冲，避免雪崩

区分可重试与不可重试错误是重点：鉴权失败重试毫无意义，只会浪费时间和日志。

步骤 9：结果验证

建立三层验证机制：

1. 格式层（自动化）：JSON Schema 校验、字段完整性检查、引用片段是否真实存在于原文（做子串匹配）——这一层能自动化拦截大部分幻觉；
2. 指标层（半自动）：在评测集上计算要点召回率（标准答案要点被覆盖的比例）、冗余度（要点中重复项占比）、引用一致率；
3. 人工抽检：对超长文档、高风险业务文档保留人工复核环节，抽样比例可按风险分级设定。

注意：长文档任务中”摘要看起来通顺”和”摘要准确”经常不一致，必须依靠可量化的召回率而不是主观阅读判断。

步骤 10：可观测与上线

需要采集的核心指标：单次调用的输入/输出 token 数、P50/P95 延迟、错误率与错误类型分布、平均单次成本、缓存命中率、格式校验失败率。

日志必须脱敏：不要将完整文档内容写入普通日志，只记录文档指纹、长度、token 用量与耗时。

六、关键配置说明

以下是长文本场景的通用配置项及其取值逻辑（具体字段名与上限以所选用模型服务的文档为准）：

配置项	含义	取值建议	配置风险
输入长度预算	单次输入 token 上限	窗口 × 70%～80%，预留输出与系统提示空间	设满会频繁触发超长错误
最大输出长度	单次生成 token 上限	按业务输出篇幅设定	过小导致摘要被截断
分段大小 chunk size	单块字符/token 数	800～2000 token 起调	过大丢细节，过小增调用次数
重叠长度 overlap	块间重叠	分段大小的 10%～15%	为 0 时易在边界丢信息
温度 temperature	随机性	抽取/总结 0～0.3；创意类可放宽	过高导致结果不可复现
超时时间	单次请求等待上限	长文本建议 120s 以上，配合流式	过短导致大量误判超时
重试次数	失败重试上限	2～3 次，配合退避	过多放大故障与费用
并发度	同时进行的请求数	按配额上限的 70%～80%	过高触发限流与雪崩

七、示意性伪代码

def summarize_long_document(doc, endpoint, budget_tokens):
    blocks = split_by_semantic_boundary(
        clean_document(parse_document(doc)),
        chunk_tokens=1200,
        overlap_tokens=180,
    )
    # 为每个块注入全局定位信息
    blocks = [with_locator(b, doc.title, i, len(blocks))
              for i, b in enumerate(blocks)]
    # 场景一：整篇直传
    if estimate_tokens(blocks) <= budget_tokens * 0.75:
        return endpoint.complete(
            build_prompt(SYSTEM_EXTRACT, join_blocks(blocks)),
            temperature=0.1,
        )["text"]
    # 场景二：Map 阶段，带并发上限与重试
    partials = run_with_concurrency(
        fn=lambda b: endpoint.complete(
            build_prompt(SYSTEM_EXTRACT, b), temperature=0.1
        )["text"],
        items=blocks,
        max_concurrency=8,
        retry=2,
    )
    # 场景三：Reduce 阶段，要点过长时递归归约
    merged = merge_points(partials)
    while estimate_tokens(merged) > budget_tokens * 0.5:
        merged = merge_points(chunk_text(merged, chunk_tokens=8000))
    result = endpoint.complete(
        build_prompt(SYSTEM_MERGE, merged), temperature=0.1
    )["text"]
    # 结果验证：引用溯源 + 格式校验
    assert_json_schema(result, SCHEMA)
    assert_citations_in_source(result, doc)
    return result

八、常见问题与排查

问题 1：请求直接被拒绝，提示输入过长
原因：预算计算只算了文档，没算系统提示与预期输出。
排查：打印实际输入 token 数，按”文档 + 提示词 + 输出预留”重新核算，并降级为分段模式。

问题 2：摘要遗漏了文档中后段的关键条款
原因：中间信息衰减 + 块级要点在归约阶段被合并丢弃。
排查思路：检查归约阶段的输入是否保留了块序号；对高风险条目（金额、期限、责任主体）采用”全量保留、不合并”规则；必要时对文档尾部单独追加一次显式提问。

问题 3：输出出现原文不存在的条款编号或金额
原因：模型对上下文的推断性补全。
应对：强制要求引用原文片段并在代码侧做子串校验，校验不通过的条目直接进入人工复核队列；提示词中明确禁止推测编号类信息。

问题 4：输出 JSON 格式不稳定
原因：仅靠提示词约束格式，长输入下约束被稀释。
应对：优先使用服务提供的结构化输出能力；否则加入格式校验 + 带错误反馈的重试，并把失败率纳入监控。

问题 5：处理一篇超长文档耗时数分钟
原因：分段串行调用 + 单次输入过大。
应对：Map 阶段并行化、启用流式输出降低首字延迟、对高频重复文档做结果缓存、把”粗筛”任务交给更轻量的模型。

问题 6：费用远超预期
原因：一是同一文档被重复解析（无缓存）；二是归约阶段输入过长导致输出 token 暴涨；三是把长上下文用于本可检索解决的任务。
应对：按文档指纹缓存；归约前压缩要点冗余；按任务类型分流——总结走长上下文，问答走检索增强。

问题 7：长文档跨章节结论自相矛盾
原因：分段处理时各段独立判断，缺少全局一致性校验。
应对：增加一次 Refine 轮次，把全局摘要与冲突章节一起回灌核对；或在提示词中要求显式列出冲突项而非强行统一。

九、优化建议

• 性能：Map 阶段并行 + 结果缓存 + 轻量模型做前置过滤 + 流式输出改善体感延迟；
• 成本：按”文档指纹 + 提示词版本 + 模型版本”三元组做结果缓存；总结类任务只缓存不变内容；对超长文档先压缩再归约；大批量场景走异步批处理以利用批量任务的价格优势；
• 安全：密钥托管与定期轮换；传输加密；输入输出内容审查；文档级访问权限控制；日志脱敏与留存期限管理；
• 稳定性：重试 + 熔断 + 降级链路（长上下文不可用时自动降级为检索增强）；多模型或多区域容灾；上线前灰度验证；
• 可维护性：提示词版本化管理并纳入评测回归；调用层与业务层解耦，保证模型可替换；把所有阈值配置外置到配置中心而非硬编码；
• 可解释性：坚持”每个结论带原文引用”，让输出可审计，这是长文本能力进入严肃业务场景的前提。

十、总结

回到最初的问题——“长文本能力最有前途吗？”从工程角度看，正确的答案不是比较谁的窗口数字更大，而是：先用自己的文档评测集测出各方案在长文本上的真实衰减曲线与成本，再决定技术路线。

本教程的核心结论可以归纳为四点：

1. 长度必须量化：用实际分词器统计而非按字数估算，并按”输入 + 输出共享窗口”规划预算；
2. 路线由数据决定：窗口内走整篇直传，超出窗口走”分段 → 层次摘要 → 一致性归约”，问答型任务优先检索增强；
3. 质量必须可验证：格式校验 + 引用溯源 + 要点召回率 + 人工抽检，四层机制缺一不可；
4. 成本与延迟需要前置设计：缓存、并发控制、模型分层、异步批处理要在方案阶段就纳入，而不是上线后补救。

后续可以继续深入的方向包括：长上下文场景下的检索与生成融合排序、多文档对比的结构化抽取、以及基于评测集持续迭代提示词版本的工程化机制。