AI 写代码会由于“上下文超长”变笨？详解 RAG 在代码库问答中的“滑动窗口”切片策略

📉 前言：上下文越长，AI 越糊涂？

你是否遇到过这种情况：
把几千行代码丢给 ChatGPT，问它“这个变量在哪里定义的”，它却开始胡言乱语？
这被称为**“迷失在中间 (Lost in the Middle)”**现象。当 Prompt 长度超过一定阈值（比如 30k tokens），大模型对中间段落的注意力权重会暴跌。

在代码库问答 (Codebase QA)场景中，简单的 RAG（检索增强生成）往往效果不佳，原因是切片（Chunking）方式太粗暴。

• 如果你把一个函数切成两半，上半部分在 Chunk A，下半部分在 Chunk B。
• 检索时，向量数据库可能只找回了 Chunk B。
• 结果：AI 看不到函数签名和参数定义，自然无法理解代码逻辑。

今天，我们来硬核拆解一种**“防断裂”**的高级切片策略——滑动窗口 (Sliding Window)。

🪟 核心原理：什么是滑动窗口？

传统的切片是**“切蛋糕”**：
[0-500],[501-1000],[1001-1500]
问题：500 和 501 之间的逻辑断了。

滑动窗口是**“铺瓦片”：
[0-500],[400-900],[800-1300]
核心： 设置一个 Overlap (重叠区)。
保证每个切片都包含上一个切片的尾部上下文**。在代码中，这意味着如果一个函数被切断，它的关键部分（如变量声明）大概率会同时出现在两个 Chunk 中，确保语义连续。

RAG 代码库问答架构图：

💻 实战代码：基于 LangChain 实现滑动窗口

我们使用 Python 的LangChain库来实现这一策略。
对于代码，单纯的字符数切分是不够的，我们需要结合编程语言的分隔符。

Step 1: 准备环境

pipinstalllangchain langchain-text-splitters tiktoken

Step 2: 编写切片逻辑 (Splitter.py)

这里我们使用RecursiveCharacterTextSplitter.from_language，它是专门为代码优化的。

fromlangchain_text_splittersimport(Language,RecursiveCharacterTextSplitter,)# 模拟一段长代码（假设这是一个复杂的 Python 类）python_code=""" class AuthController: def __init__(self, db_session): self.db = db_session self.secret_key = "sk-12345" def login(self, username, password): # ... 假设这里有 500 行复杂的校验逻辑 ... user = self.db.query(User).filter_by(name=username).first() if not user: return False # ... 更多逻辑 ... return self.generate_token(user) def generate_token(self, user): # ... 令牌生成逻辑 ... return f"token_{user.id}_{self.secret_key}" """# === 核心配置 ===# chunk_size: 每个块的大小 (Token数或字符数)# chunk_overlap: 滑动窗口的重叠区域 (关键！)python_splitter=RecursiveCharacterTextSplitter.from_language(language=Language.PYTHON,chunk_size=100,# 设小一点以便演示chunk_overlap=30# 30% 的重叠率，保证上下文连续)docs=python_splitter.create_documents([python_code])# === 验证结果 ===print(f"总共切成了{len(docs)}个块")fori,docinenumerate(docs):print(f"\n--- Chunk{i+1}---")print(doc.page_content)print("-"*20)

运行结果分析：
你会发现，Chunk 1的结尾可能是if not user:，而Chunk 2的开头重复了user = self.db.query...和if not user:。
这就是Overlap的作用。当检索到 Chunk 2 时，模型依然知道user变量是从哪来的，不会因为切片导致变量未定义（Undefined Variable）的幻觉。

🧠 进阶策略：AST 语法树切片 (Tree-sitter)

仅仅靠滑动窗口（字符级）还不够完美。
最极致的策略是AST (抽象语法树) 切片。

原理：
不按字符切，而是按代码结构切。

• 保持Class定义完整。
• 保持Function定义完整。
• 如果函数太长，才在函数内部进行滑动窗口切分。

逻辑流程图：

📊 性能对比：有无 Overlap 的区别

我在一个包含 10万行 Java 代码的遗留系统中进行了测试。

📝 总结

做代码 RAG，千万别直接用处理小说/新闻的方式处理代码。
代码是高度耦合的文本。

1. 必须要用 Overlap：推荐设置为 Chunk Size 的 10%-20%。
2. 选对 Splitter：使用 LangChain 的from_language，利用分隔符优先切分。
3. 大上下文不是万能药：精准的检索（Retriever）比超长的 Context Window 更重要，也更省钱。