01

60 秒回答模板

让大语言模型处理更长文本，不能只回答“把上下文窗口做大”。我会先判断长文本问题的类型：是用户希望模型一次读完整材料，还是希望从大量文档里找到相关证据，还是多轮对话历史太长，还是要批量处理一批文档。第一类是长上下文扩展，适合合同、论文、会议纪要、代码仓库片段这类需要跨段落引用和全局一致性的任务，但成本高、延迟高，而且模型未必真正均匀利用窗口里的所有信息。第二类是 RAG，适合知识库问答、企业文档、客服政策、动态资料等场景，先检索相关片段再生成，优点是成本可控、知识可更新、可给引用，缺点是召回失败、切分不当和排序错误会直接影响答案。第三类是摘要压缩，适合长会话记忆、会议连续总结、历史信息保留，把旧内容压成结构化摘要，但有信息丢失和摘要偏差风险，不适合需要逐字证据的任务。第四类是分块处理，适合批量抽取、分类、审核、逐章总结等可拆任务，最后再合并结果；难点是跨块依赖和全局一致性。产品方案通常是组合拳：短任务直接放上下文，中等知识问答用 RAG，长会话用摘要记忆，超长文档用分块加检索加最终汇总；评估要看召回率、证据覆盖、答案正确性、成本、延迟和用户是否能追溯证据。

考点 需求分类
难度 真实面经题
回答目标 让候选人能按长文本任务类型选择长上下文、RAG、摘要压缩和分块处理，并能说明每种方案的机制、适用场景、风险和评估指标。
02

深入解析

01

先判断长文本需求的真实类型

长文本不是一个单一问题。用户可能需要完整阅读一份长合同，可能是在庞大知识库里找几段证据，可能是多轮对话历史过长，也可能是要批量处理很多文档。不同类型对应不同方案。如果不先分类，容易把所有问题都推给长上下文窗口，导致成本高、效果不稳定。

02

长上下文扩展适合全局依赖任务

长上下文扩展的思路是让模型一次接收更多 token，适合需要跨章节对照、前后口径一致、全文级判断的任务，例如长合同审阅、论文理解、复杂代码阅读和会议全局总结。优点是减少外部管线复杂度，用户体验接近“把整篇文档给模型”。缺点是注意力和 KV Cache 成本高，延迟更长，而且模型可能对窗口中部或低显著信息利用不足。

03

RAG 适合大规模和动态知识

RAG 的核心是先把文档切分、索引和召回，再把相关片段交给模型生成答案。它适合企业知识库、客服政策、产品文档、法规资料、FAQ 和需要引用依据的问答。优势是知识可更新、上下文更短、成本可控、答案可追溯；风险是检索召回漏掉关键证据、切块破坏语义、排序不准或生成阶段忽略证据。

04

摘要压缩适合保留历史状态

摘要压缩不是为了保留所有原文，而是把长历史压成任务相关状态，例如用户偏好、已讨论结论、待办事项、关键约束和未解决问题。它适合多轮对话、会议连续纪要、项目助手和个人记忆。代价是不可逆信息丢失，摘要一旦遗漏或改写错误，后续回答会继承偏差，因此重要事实需要结构化字段、引用或可回查原文。

05

分块处理适合可拆分的批处理

分块处理把长文本按章节、语义段、时间段或固定 token 切开，分别抽取、分类、总结或审核，最后聚合结果。它适合长文档摘要、批量质检、日志分析、问卷归纳和多文件扫描。关键是设计 chunk 边界、重叠窗口、局部任务和合并规则；如果任务需要跨块推理，就要增加二阶段汇总、检索回看或全局校验。

06

方案选择要用评估指标闭环

面试中要把方案和评估连起来。长上下文看全文问题正确率、引用覆盖和延迟；RAG 看召回率、证据命中、引用正确和幻觉率；摘要压缩看关键事实保留率、状态更新准确和漂移；分块处理看局部准确率、合并一致性和漏检率。最终还要比较成本、用户等待、可解释性和失败兜底。

03

易错点

  • 把长文本处理等同于扩大上下文窗口，忽略 RAG、摘要记忆和分块管线更适合的场景。
  • 认为长上下文越长效果一定越好，没有考虑成本、延迟、注意力利用和中间信息丢失。
  • 把 RAG 描述成万能方案，漏掉召回失败、切块错误、排序错误和生成不遵循证据的风险。
  • 用摘要压缩处理需要逐字证据的任务，导致关键原文丢失且无法追溯。
  • 分块时只按固定长度切，不考虑语义边界、重叠窗口和最终合并一致性。
  • 没有给出评估指标，只讲方案名称，无法判断哪个方案在产品里真的有效。
04

面试官追问

如果上下文窗口已经很长，还需要 RAG 吗？

通常仍然需要。长窗口适合一次性阅读有限材料，RAG 适合从大量、动态、可更新文档中找相关证据。把整个知识库塞进上下文成本高、延迟长，也难以保证模型关注到正确片段。

摘要压缩最大的风险是什么？

最大风险是不可逆信息丢失和摘要偏差。旧内容一旦被错误压缩，后续模型会基于错误状态继续推理。因此关键事实要结构化保存，重要结论最好保留引用或原文定位。

分块处理怎么处理跨块依赖？

可以用重叠窗口减少边界丢失，用语义切分保持段落完整，用二阶段聚合处理全局结论；对必须跨块引用的任务，还可以在最终阶段用检索回看关键块。

RAG 评估为什么不能只看最终回答？

因为错误可能来自检索没召回、排序没排上、片段切坏、生成没遵循证据或答案表达错误。只看最终回答无法定位瓶颈，需要分别评估召回、证据覆盖、引用正确和生成质量。

产品上如何给用户解释长文本能力边界？

可以告诉用户支持上传长文档或知识库问答，但要明确是否会引用依据、是否可能遗漏低相关信息、是否适合逐字审查。对高风险任务应提供证据定位、确认步骤和人工复核入口。