Langchain-Chatchat如何处理超长文本？分块策略与上下文优化

在企业知识管理日益智能化的今天，一个常见的挑战浮出水面：如何让大语言模型“读懂”上百页的技术手册或法律合同？

尽管像 GPT、ChatGLM 这样的大模型在理解自然语言方面表现出色，但它们都有一个硬性限制——输入长度通常不超过 32768 个 token。而一份完整的 API 文档动辄数万字，直接喂给模型显然行不通。于是问题就变成了：我们能不能把“整本书”拆成“可读段落”，再智能地拼出最相关的那几页送给模型？

这正是 Langchain-Chatchat 的核心使命。作为一款开源的本地知识库问答系统，它不依赖公有云 API，所有数据处理都在内网完成，完美契合企业对隐私与安全的严苛要求。其背后的关键技术，正是科学的文本分块策略和精巧的上下文优化机制。

当你上传一份 PDF 技术白皮书时，Langchain-Chatchat 并不会简单粗暴地按字符数切开。相反，它会像一位经验丰富的编辑那样，先通读全文，识别段落边界、句子结尾，甚至章节标题结构，然后在语义连贯的地方下刀。

这个过程由 RecursiveCharacterTextSplitter 驱动。它的名字听起来复杂，逻辑却很直观：优先尝试用 \n\n（空行）分割段落；如果不行，退而求其次用句号 ., !, ? 切分句子；最后才考虑单词间的空格。这种“递归降级”的方式，最大程度避免了把一句话生生掰成两半。

更重要的是，它支持 chunk overlap（块间重叠）。比如设置 chunk_size=512 和 chunk_overlap=50，意味着每个文本块最多包含 512 个 token，且相邻两个块之间有 50 个 token 是重复的。这看似浪费存储，实则巧妙解决了上下文断裂的问题——当一个问题的答案横跨两个 chunk 时，重叠区域能帮助检索系统同时命中两者，从而还原完整语义。

from langchain.text_splitter import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", "。", "！", "？", ".", "!", "?", " "],
    length_function=len
)

这段代码虽短，却是整个知识库构建的基石。实践中你会发现，separators 的顺序至关重要——把段落分隔符放在前面，才能保证结构性优先于细粒度切割。而对于中文文档，加入全角标点如“。！”是必不可少的细节。

不过，光是切得好还不够。试想这样一个场景：用户问：“JWT 令牌是如何生成并用于认证的？” 系统从向量数据库中召回了五个相关文本块，分别来自《安全规范》第8页、《API 手册》第3章、以及一份旧版配置说明。其中两条高度相关，两条部分匹配，一条完全是噪声。

这时候，如果直接把这些 chunk 拼起来送进 LLM，很可能导致模型被干扰项带偏，或者因为总长度超限而被迫截断关键信息。这就引出了第二个关键技术：上下文优化。

传统的语义检索仅基于 embedding 向量的余弦相似度，虽然速度快，但在面对同义词、近义表达或专业术语变体时容易失效。例如，“登录接口”和“认证端点”在向量空间中可能相距甚远，但实际上指向同一功能。

Langchain-Chatchat 的解决方案是引入 re-ranking（重排序）机制。它不像初检那样一次性扫描全库，而是对 top-k 的候选结果进行精细化打分。常用的方法是使用 Cross-Encoder 模型（如 BGE-Reranker），这类模型能够将 query 和 document 一起编码，在 token 层面进行深度交互，从而更准确判断相关性。

from sentence_transformers import CrossEncoder

reranker = CrossEncoder('bge-reranker-large')

def rerank_chunks(query, chunks):
    pairs = [[query, chunk] for chunk in chunks]
    scores = reranker.predict(pairs)
    ranked = sorted(zip(chunks, scores), key=lambda x: x[1], reverse=True)
    return [item[0] for item in ranked]

optimized_context = rerank_chunks("如何实现用户身份验证？", retrieved_chunks)

别小看这几行代码带来的提升。实验表明，在标准测试集上，单纯使用向量检索的 MRR@10（平均倒数排名）可能是 0.4 左右，而加入 reranker 后可轻松突破 0.6，意味着第一结果就是正确答案的概率提升了 50% 以上。

当然，性能提升是有代价的——Cross-Encoder 计算成本较高，不适合做首轮检索。因此最佳实践是“两阶段检索”：先用 FAISS 或 Chroma 快速筛选 top-50 候选，再用轻量级 reranker 精排 top-5。这样既控制了延迟，又显著提高了质量。

更进一步，当最终选定的上下文总长度仍超出目标模型的 context window 时，系统还需执行动态裁剪。常见的策略包括：

• 前置保留：保留得分最高的前几个 chunk，舍弃后续内容；
• 中心扩展：以最高分 chunk 为中心，向前后扩展一定数量；
• 摘要压缩：使用 MapReduce 或 Refine 模式，先对多个 chunk 分别摘要，再综合生成最终提示。

这些策略并非孤立存在，而是可以根据业务需求灵活组合。例如，在法务咨询场景中，准确性高于一切，可以启用 full reranking + 中心扩展；而在客服机器人中，则更适合采用缓存 + 前置保留来保障响应速度。

值得一提的是，Langchain-Chatchat 还特别注重结果溯源。每一个返回的回答都会附带来源标注，比如“（来源：API手册 P45）”。这不仅是增强用户信任的设计，更是企业级应用的基本要求。实现这一点的关键，是在分块阶段就为每个 chunk 注入元数据——文件名、页码、章节标题等。这些信息不参与 embedding 生成，但在输出时会被提取出来，形成可追溯的知识链路。

在实际部署中，还有一些工程层面的经验值得分享：

• chunk_size 不宜过大：建议控制在目标 LLM 上下文窗口的 1/3 以内。例如，若模型最大支持 8k tokens，单次输入 prompt 应留足空间给指令模板和生成回复，实际可用 context 最好不超过 2k–3k。
• overlap 要适度：太少（<32）可能导致上下文丢失；太多（>10% chunk_size）会造成存储膨胀和计算冗余。推荐值为 50–100 tokens 或 chunk_size 的 10%。
• embedding 模型需匹配语言体系：中文场景优先选用 BGE、COSMOS、text2vec 系列，避免使用英文主导的模型导致语义偏差。
• 敏感信息预处理不可忽视：对于身份证号、密钥、内部 IP 等字段，应在入库前添加脱敏规则，防止意外泄露。

整个系统的运作流程可以概括为一条清晰的 pipeline：

[用户提问]
      ↓
[NLU预处理 → Query Embedding]
      ↓
[向量数据库检索（FAISS/Chroma/Milvus）]
      ↓
[召回 top-k chunks]
      ↓
[上下文优化：重排序 + 裁剪 + 元数据注入]
      ↓
[构造 Prompt 输入 LLM（如 ChatGLM/Qwen）]
      ↓
[生成回答 + 标注来源]

在这个链条中，分块策略决定了“记忆”的颗粒度，上下文优化则决定了“思考”的效率。二者协同，使得即使面对百页级文档，系统也能快速定位关键信息，并生成精准、可信的回答。

举个真实案例：某金融科技公司在接入 Langchain-Chatchat 后，将其上千份合规政策文件导入系统。原本需要人工翻查数小时的问题，现在平均 3 秒内即可获得带出处的答案。更关键的是，由于全程运行在私有环境中，无需担心敏感数据外泄。

回过头来看，Langchain-Chatchat 的真正价值并不只是“能用”，而是提供了一套可复制、可调优、可审计的知识服务范式。它没有追求通用 AI 的宏大叙事，而是聚焦于解决企业中最常见的痛点：信息分散、查找困难、响应缓慢。

未来，随着小型化 LLM 和更高效 embedding 模型的发展，这类系统的推理成本将进一步降低。我们可以预见，类似的架构将成为组织内部知识流动的标准基础设施——就像当年的搜索引擎重塑了互联网一样，今天的本地知识库正在重塑企业的信息生态。

而这一切的起点，不过是把一段文字切得更聪明一点，再把几段话拼得更有逻辑一些。