如何通过 RAG 优化长文本输入以解决上下文窗口丢失细节的问题

直接把 10 万字文档塞进 Claude 3.5 或 GPT-4o 的上下文窗口，结果往往是 AI 出现了典型的「中间丢失 (Lost in the Middle)」现象：开头和结尾记得清，中间的关键细节全被忽略。

要解决这个问题，不能单纯依赖增加 Token 限制，得在输入端做 RAG（检索增强生成）的精细化处理。我最近在处理一份超长技术文档的知识库时，尝试了一套「分层检索 + 重排」的方案，效果比直接喂全文好得多。

核心逻辑是：不要让 LLM 在大海里捞针，而是在过滤后的几个小盆里找针。

具体操作步骤：

1. 采用语义分块（Semantic Chunking）而非固定长度分块
很多人的坑在于用 CharacterTextSplitter 每 500 字切一段，这会导致语义被截断。我改用了基于 Embedding 距离的动态切分，确保每个 Chunk 是一个完整的知识点。

2. 引入 Rerank（重排序）机制
向量检索（Vector Search）只能保证「相关」，不能保证「精准」。我配置了 BGE-Reranker，先用向量库检索出 Top 50 个片段，再通过 Rerank 模型把最相关的 Top 5 提到最前面。

3. 优化 Prompt 引导 AI 关注检索片段
在 System Prompt 中明确要求 AI 必须在检索到的 Context 中寻找答案，如果没有则承认不知道，防止其利用预训练权重进行「幻觉补完」。

我的 Prompt 配置示例：

你是一个技术文档分析专家。我会为你提供【检索片段】和【用户问题】。
请严格遵守以下规则：
1. 仅根据【检索片段】中的信息回答问题。
2. 如果片段中包含具体参数、版本号或代码示例，必须原样引用。
3. 如果检索内容无法覆盖问题的答案，请直接回答“文档中未提及相关细节”，不要尝试猜测。

【检索片段】：
{{context}}

【用户问题】：
{{query}}

踩过的坑：
最容易被忽视的是 Chunk 之间的「上下文重叠度 (Overlap)」。如果 Overlap 设为 0，检索到的片段可能会丢失前后的衔接信息。建议将 Overlap 设置为分块长度的 10%-20%，这样在检索到某个片段时，能带上一点点前后文，防止 AI 产生误解。

效率提升点：
在使用 Cursor 的 .cursorrules 中配置这类检索逻辑后，我发现处理大型项目代码库时的准确率提升了约 40%。不再会出现「明明代码里写了，但 AI 说没找到」的情况。

推荐的轻量化技术栈：
向量库： Qdrant 或 ChromaDB
Embedding： text-embedding-3-small (性价比最高)
Reranker： BGE-Reranker-v2-m3