别急着给长上下文 LLM 下定义，先看这次卡在哪。

下面几个场景，我都是在 RAG 分块检索上撞过墙的：

• 用户想了解一个 SaaS 产品的所有功能点，但产品文档有 300 多页
• 技术负责人需要快速理解一个开源项目的完整架构，代码量 10 万行+
• 法务要检查一份 200 页的合同，找出所有风险条款
• 研究团队想对几十份行业报告做横向对比

共同点：要的是「整体理解」，不是「捞几段最相关的片段」。

为什么突然要处理长上下文

去年还在跟 4k、8k 窗口较劲，文档稍长就得切块做 RAG。需求侧可不会等：产品要啃完整用户协议，技术要评估整个代码库架构，运营要对几百页竞品报告做横向总结。RAG 在这类任务上短板就露出来了。

需求：从片段检索到整体理解

RAG（Retrieval-Augmented Generation）的核心思路很简单：把长文本切成小块，按相关性检索最相关的几块，再让模型基于这些片段生成答案。这个思路在问答题场景下效果很好，但在需要整体理解时就会出问题。

我踩过最典型的坑是一个代码库评估项目：用户想了解一个开源项目的整体架构，RAG 检索到的片段主要是某个核心模块的实现细节，但完全错过了其他关键模块的存在。结果生成的架构图只有三分之一的内容，用户看完反而更困惑了。

另一个坑是合同审查：RAG 检索到了"违约责任"的具体条款，但漏掉了前面"免责条款"里的关键约束，导致风险评估完全偏了。

这时候才确认：有些场景下，长上下文是硬需求，RAG 补不上那块「全局视图」。

实现：从 RAG 到长上下文的实践路径

先判断要不要上长上下文

我会先问三个问题：用户要局部答案还是整体理解？信息是否散在多个不相关段落？要不要跨段落看引用、依赖或因果？三个里有两个是「是」，再考虑长上下文。

选模型

长上下文 LLM 不是越大越好，得看场景。我测过几个主流方案：

实际选择时，我会优先考虑：语言覆盖、部署方式、成本预算、响应速度。比如中文内容会优先 Qwen，需要本地部署就看 LLaMA。

就算上了长上下文，预处理也不能省：去重复和页眉页脚、保留章节和表格结构、在关键处插 [第3章] / [重要条款] 这类标记。分块按内容类型来：

代码类文档：按文件或模块分块

def chunk_code(content, max_size=4096): files = content.split(’=== FILE:’) chunks = [] for file in files: if len(file) > max_size: # 按函数/类进一步分割 chunks.extend(split_by_functions(file, max_size)) else: chunks.append(file) return chunks

合同类文档：按条款分块

def chunk_contract(content, max_size=4096): clauses = content.split(r’第\d+条’) chunks = [] current = "" for clause in clauses: if len(current) + len(clause) > max_size and current: chunks.append(current) current = clause else: current += clause if current: chunks.append(current) return chunks

### 混合架构

纯长上下文往往不是最优解。我这边最终是 RAG + 长上下文混用：

```mermaid
flowchart LR
    A[输入长文本] --> B[预处理与去噪]
    B --> C{内容类型判断}
    C -->|代码/结构化内容| D[按模块/文件分块]
    C -->|文档/非结构化内容| E[按语义段落分块]
    D --> F[分块索引]
    E --> F
    F --> G[第一轮检索]
    G --> H{判断是否需要全局理解}
    H -->|否| I[基于检索片段生成答案]
    H -->|是| J[全文送入长上下文模型]
    J --> K[生成整体理解]
    K --> L[结合检索细节优化结果]
    L --> M[最终输出]

这个架构的核心是：先用 RAG 快速定位相关信息，再判断是否需要全局理解。如果需要，就把全文送入长上下文模型做整体分析，最后结合检索细节优化结果。

踩坑：真实场景里的坑点

坑一：中间段落消失

长上下文模型最经典的坑是"U-shaped attention"：模型对开头和结尾的内容更关注，中间部分容易被忽略。

我在一个法律文档分析项目里就遇到过这个坑：一份 100 页的合同，模型准确识别了开头的目的条款和结尾的违约条款，但完全漏掉了第 40-60 页里的核心服务范围。最后只能通过在关键段落插入强调标记来缓解。

def add_emphasis_markers(content):
    # 在关键段落前后插入标记
    sections = re.split(r'(第\d+条[^\n]+)', content)
    marked = []
    for i, section in enumerate(sections):
        if i % 2 == 1:  # 这是标题
            marked.append(f"\n[重点关注: {section}]\n")
        else:
            marked.append(section)
    return ''.join(marked)

坑二：语义漂移

当输入长度接近模型上限时，模型开始出现语义漂移：理解逐渐偏离原文，甚至开始"编造"不存在的内容。

我在代码库评估时遇到过这个问题：当输入超过 100k token 时，模型开始"看到"根本不存在的函数和类，导致架构评估完全错误。最终解决方案是：设定合理的长度上限，超过就分段处理再合并结果。

def safe_long_context_process(content, model, max_length=100000):
    if len(content) <= max_length:
        return model.generate(content)
    else:
        # 分段处理
        chunks = split_content(content, max_length)
        results = []
        for chunk in chunks:
            result = model.generate(chunk)
            results.append(result)
        # 合并结果
        return merge_results(results)

坑三：成本爆炸

长上下文处理的成本比想象的要高。我算过一笔账：

这还只是直接成本，如果考虑到响应时间（长上下文通常需要 30-60 秒），用户体验成本更高。实际项目里，我会根据业务价值决定是否使用长上下文。

坑四：Token 计算偏差

另一个容易被忽视的问题是 Token 计算偏差。不同模型的 Token 算法差异很大，同样的文本在不同模型上的 Token 数量可能差 20-30%。

我在一个多语言项目里吃过亏：中英文混合的文档，按 GPT-4 的 Token 算法是 80k token，但换到 Claude 3 就变成了 110k token，直接超出上下文窗口。最后只能用统一的 Token 计算工具做预处理。

import tiktoken

def estimate_tokens(text, model="gpt-4"):
    try:
        encoding = tiktoken.encoding_for_model(model)
    except KeyError:
        encoding = tiktoken.get_encoding("cl100k_base")
    return len(encoding.encode(text))

结果：什么场景值得用长上下文

经过这半年的实践，我对长上下文的使用边界有了更清晰的判断：

值得用长上下文的场景：

1. 需要整体理解的文档分析（完整产品功能梳理、架构评估）
2. 跨段落关系理解（合同条款间的约束关系、代码模块间的依赖）
3. 一致性要求高的场景（多份文档对比、统一标准检查）
4. 用户明确要求"完整分析"的场景

继续用 RAG 更好的场景：

1. 明确的问答需求（“第 5 条是什么？"）
2. 局部信息查询（“这个函数的参数有哪些？"）
3. 成本敏感的大规模处理
4. 响应时间要求高的实时场景

混合架构最优的场景：

1. 先整体理解再细节查询（“先给我整体架构，再详细说明某个模块”）
2. 需要跨文档关联分析
3. 评估类任务（技术选型、竞品分析）

实际项目里，我现在的做法是：默认先用 RAG 快速响应，如果用户连续追问或明确表示需要整体理解，再切换到长上下文模式。这样既控制了成本，又保证了体验。

结尾

RAG 和长上下文我都在用，差别主要在任务：要片段答案就 RAG，要整体理解再开长窗口。默认先 RAG 控成本和延迟，用户连续追问或明确要「通读」再切长上下文。

动手前我会先问一句：你是要个大概，还是要把全文逻辑捋顺？前者 RAG 往往够用；后者再算 token 账单也不迟。

版权声明: 本文首发于 指尖魔法屋-AI长上下文LLM踩坑记录（https://blog.thinkmoon.cn/post/382-ai-long-context-llm-rag-long-text-practice/） 转载或引用必须申明原指尖魔法屋来源及源地址！