战术篇（下） - 披沙拣金：驯服非结构化与代码知识

1. 非结构化文本：如客服对话、用户评论、会议纪要等，这类文本缺乏明确的结构，但蕴含着最直接的用户声音和业务洞察。

2. 代码知识：作为技术公司的核心资产，代码库本身就是一个巨大的知识库，但其结构由编程语法定义，传统的文本处理方法难以奏效。

1. 语义切片 (Semantic Chunking)：超越规则，读懂文字"言外之意"的读心者。

2. 滑动窗口与元数据增强 (Sliding Window & Metadata Augmentation)：为时序对话保留关键上下文的记忆锚点。

3. 代码感知切片 (Code-Aware Chunking)：深入代码脉络，像开发者一样理解代码的解构师。

准备工作：环境回顾

# 核心库
pip install -q langchain langchain_community langchain_openai

# 向量化与存储
pip install -q faiss-cpu tiktoken

# 语义切片需要用到
pip install -q langchain_experimental

import os
from langchain_openai import OpenAIEmbeddings

# 建议使用环境变量来管理你的API密钥
# os.environ["OPENAI_API_KEY"] = "sk-..."

# 初始化嵌入模型
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

武器一：语义切片 (Semantic Chunking) - 读心者

1. 将文本打散成单个句子。

2. 为每个句子生成嵌入向量（Embedding）。

3. 计算相邻句子嵌入向量之间的语义相似度（通常是余弦相似度）。

4. 当相似度出现一个"断崖式"下跌时，就认为这里发生了一个语义中断，并在此处进行切分。

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai.embeddings import OpenAIEmbeddings

# 一段主题连续变化的非结构化文本
unstructured_text = """
我们的新功能上线后，初期反响热烈。许多用户称赞了其创新的交互设计和流畅的用户体验。
一位来自加州的用户反馈说，这个功能为他的日常工作节省了大量时间。
然而，随着使用量的增加，一些问题也逐渐暴露出来。
部分用户报告在低配设备上存在性能问题，主要表现为加载缓慢和偶尔的卡顿。
我们技术团队正在紧急排查，初步定位是内存管理方面需要优化。
我们承诺将在下个版本中解决这个问题，并对受影响的用户表示歉歉。
"""

# 初始化语义切片器
# percentile_threshold: 设置语义中断的阈值。可以是百分比（95%），也可以是绝对值。
# 值越低，切分得越细碎；值越高，切分得越大块。
text_splitter = SemanticChunker(
    OpenAIEmbeddings(model="text-embedding-3-small"),
    breakpoint_threshold_type="percentile", # 使用百分位阈值
    breakpoint_threshold_amount=95
)

chunks = text_splitter.create_documents([unstructured_text])

# 看看切分结果
for i, chunk in enumerate(chunks):
    print(f"--- 块 {i+1} ---")
    print(chunk.page_content)
    print()

1. gradient (梯度)
• 原理: 这是最能体现"语义断崖"这个概念的方法。它将相邻句子的相似度得分看作一个序列，然后计算这个序列的"梯度"，也就是变化率。当相似度从一个高点突然下跌到一个低点时，这个变化率（梯度）的绝对值会非常大。该方法会直接找到梯度变化最剧烈的那些点作为切分点。
• 优点: 非常直观地捕捉了语义焦点的突然转变，对于识别话题的硬性切换非常有效。

2. percentile (百分位，默认方法)
• 原理: 这是最直观和常用的方法。它首先计算出所有相邻句子之间的"语义距离"（1 - 相似度，距离越大代表越不相关）。然后，它根据这些距离的分布，来设定一个阈值。例如，breakpoint_threshold_amount=95 的意思是："将所有距离中，排在前5%的那些最大距离作为切分点"。
• 优点: 适应性强。对于一篇整体内容连贯、主题单一的文档（句子间距离普遍较小），它会自动采用一个较低的距离阈值来切分；反之，对于主题跳跃的文档，它会采用一个较高的阈值。

3. standard_deviation (标准差)
• 原理: 这是一个经典的统计学方法，用于寻找离群值。它会计算所有句子间距离的平均值（mean）和标准差（std）。如果某个距离大于 mean + n * std（这里的 n 就是 breakpoint_threshold_amount），它就被认为是一个"异常"的语义中断，并在此处切分。
• 优点: 基于数据的正态分布假设，对于分布较均匀的数据效果很好。

4. interquartile (四分位数)
• 原理: 这种方法比标准差更稳健，尤其是在数据中存在极端异常值时。它使用四分位距（IQR）来定义"异常"。一个切分点被定义为任何距离大于 第三四分位数 (Q3) + n * IQR 的地方。
• 优点: 对极端离群值的存在不敏感，鲁棒性更强。

深度剖析：语义切片 vs. 传统切片

RAG问答场景下的具体影响

1. 使用 RecursiveCharacterTextSplitter 的世界：
• 切分：它可能会按照段落符，将原文切成三块。第二块可能包含"...一些问题也逐渐暴露出来。部分用户报告在低配设备上存在性能问题..."，但它的开头可能还连着上一段的"正面反馈"，结尾可能连着下一段的"技术团队排查"。
• 检索：用户的提问向量与这三个块计算相似度。第二块的得分最高，但可能第一块和第三块也有一定的分数，因为它们也提到了"新功能"。系统可能会返回第二块，甚至会把第一块也作为相关内容返回。
• 生成：LLM得到的上下文是"...用户称赞...一些问题...性能问题...技术团队排查..."。这个上下文是被污染的，包含了正面反馈和解决方案，并非纯粹的问题描述。LLM需要付出额外的"认知努力"来从中筛选出回答"性能问题"所需要的信息，增加了出错或生成冗余回答的风险。

2. 使用 SemanticChunker 的世界：
• 切分：它识别出"正面反馈"、"问题报告"、"解决方案"是三个独立的语义单元，并以此为边界切分。
• 检索：用户的提问向量与"问题报告"这个块的向量高度匹配，相似度得分远高于另外两个块。系统会以极高的置信度只返回这一个块。
• 生成：LLM得到的上下文是："部分用户报告在低配设备上存在性能问题，主要表现为加载缓慢和偶尔的卡顿。" 这是一个高度纯净、100%相关的上下文。LLM可以毫不费力地直接基于此信息生成精准的答案。

召回策略：纯粹的语义力量

1. 提问: 用户提出问题，如"新功能有什么性能问题？"

2. 查询向量化: 将用户问题通过相同的嵌入模型（text-embedding-3-small）转换为查询向量。

3. 向量检索: 在向量数据库中，计算查询向量与所有文本块向量之间的余弦相似度。

4. 返回结果: 返回相似度最高的Top-K个块。

武器二：滑动窗口 (Sliding Window) - 对话的记忆锚点

1. 按轮次切分：首先，将对话按发言人或时间戳分割成一个个独立的单元。

2. 添加元数据：为每个单元添加结构化的元数据，如speaker（发言人）、timestamp（时间戳）。

3. 滑动窗口组合：使用一个"窗口"将多个连续的对话单元组合成一个块。例如，一个大小为3的窗口，会将第1、2、3轮对话合并为块1，第2、3、4轮对话合并为块2，以此类推。

# 这是一个概念性的演示，LangChain中可以通过自定义逻辑实现

# 原始对话记录
dialogue = [
    {"speaker": "User", "timestamp": "10:01", "text": "你好，我的订单好像延迟了。"},
    {"speaker": "Support", "timestamp": "10:02", "text": "您好，请问能提供一下您的订单号吗？"},
    {"speaker": "User", "timestamp": "10:03", "text": "当然，是 #12345。"},
    {"speaker": "Support", "timestamp": "10:04", "text": "感谢。我查一下... 好的，看到您的订单了。"},
    {"speaker": "Support", "timestamp": "10:05", "text": "确实有些延迟，原因是物流出现了一些意外情况。我们预计明天可以送达。"},
    {"speaker": "User", "timestamp": "10:06", "text": "好的，谢谢你。"},
]

def sliding_window_chunking_with_metadata(dialogue, window_size=3):
    chunks = []
    for i in range(len(dialogue) - window_size + 1):
        window = dialogue[i : i + window_size]

        # 将窗口内的对话文本合并
        content = "\\n".join([f"[{turn['timestamp']}] {turn['speaker']}: {turn['text']}" for turn in window])

        # 元数据可以包含窗口的起始信息
        metadata = {
            "start_timestamp": window[0]['timestamp'],
            "end_timestamp": window[-1]['timestamp'],
            "participants": list(set(turn['speaker'] for turn in window))
        }
        chunks.append({"content": content, "metadata": metadata})
    return chunks

dialogue_chunks = sliding_window_chunking_with_metadata(dialogue)

# 看看切分结果
for i, chunk in enumerate(dialogue_chunks):
    print(f"--- 块 {i+1} ---")
    print(f"内容:\\n{chunk['content']}")
    print(f"元数据: {chunk['metadata']}\\n")

深度剖析：滑动窗口如何维持"记忆"？

RAG问答场景下的具体影响

1. 使用 naïve 切片的世界：
• 切分：对话被切分成6个独立的块，其中一块是 [10:05] Support: 确实有些延迟，原因是物流出现了一些意外情况。我们预计明天可以送达。
• 检索：用户的提问向量与这6个块计算相似度。上面的这块内容因为包含了"预计...送达"会获得最高分。系统会返回这个块。
• 生成：LLM得到的上下文仅仅是："确实有些延迟，原因是物流出现了一些意外情况。我们预计明天可以送达。" LLM无法回答用户的问题，因为它不知道这个回复是针对哪个订单（#12345）的。它可能会回答"预计明天可以送达"，但这是一个不完整且可能产生误导的答案。

2. 使用滑动窗口切片的世界：
• 切分：系统生成了包含上下文的块。其中一个块（块3）可能包含了从用户提供订单号到客服最终回复的完整交互：

[10:03] User: 当然，是 #12345。
[10:04] Support: 感谢。我查一下... 好的，看到您的订单了。
[10:05] Support: 确实有些延迟，原因是物流出现了一些意外情况。我们预计明天可以送达。

• 检索：用户的提问向量与这个块计算相似度，因为包含了问题的答案，所以会获得高分并被召回。
• 生成：LLM得到的上下文是一段完整的、包含前因后果的对话。它清楚地知道"预计明天送达"这个信息是针对订单"#12345"的。因此，它可以生成一个完美、准确的答案："针对订单#12345，客服预计明天可以送达。"

召回策略：元数据过滤与语义搜索的协同作战

1. 提问: 用户提出一个带有上下文或限定条件的问题，例如："帮我找到客服在10:04之后，对订单#12345问题的回复。"

2. 元数据预过滤 (Pre-filtering): RAG系统首先解析问题，提取出结构化查询条件。
• participants 必须包含 'Support'
• start_timestamp 必须大于 '10:04' 系统使用这些条件，对向量数据库进行元数据过滤，将搜索范围从数百万个块急剧缩小到可能只有几十个相关的块。

3. 语义再排序 (Semantic Re-ranking): 在经过滤的小范围结果集上，再执行语义搜索。将问题的剩余部分（"订单问题的回复"）进行向量化，与这几十个块进行相似度计算。

4. 返回结果: 返回相似度最高的那个块。

武器三：代码感知切片 (Code-Aware Chunking) - 解构师

1. 语言检测：确定代码的编程语言（如Python, JavaScript）。

2. AST解析：使用该语言的解析器（如tree-sitter）将代码字符串解析成AST。

3. 按节点切分：沿着AST的节点（如function_definition, class_definition）进行遍历，将每个完整的逻辑单元（一个函数、一个类）提取为一个独立的块。

from langchain.text_splitter import (
    RecursiveCharacterTextSplitter,
    Language,
)

# 一段Python代码
python_code = """
def get_user_name(user_id: int) -> str:
    \\"\\"\\"Fetches the user's name from the database.\\"\\"\\"
    db = connect_to_db()
    result = db.query(f"SELECT name FROM users WHERE id = {user_id}")
    return result.one()

class DataProcessor:
    def __init__(self, data):
        self.data = data

    def process(self):
        # some data processing logic
        return len(self.data)
"""

# 初始化Python AST切片器
python_splitter = RecursiveCharacterTextSplitter.from_language(
    language=Language.PYTHON,
    chunk_size=150,  # 这里的chunk_size更像一个"软限制"
    chunk_overlap=0
)

python_chunks = python_splitter.split_text(python_code)

# 看看切分结果
for i, chunk in enumerate(python_chunks):
    print(f"--- 块 {i+1} ---")
    print(chunk)
    print()

深度剖析：为什么必须"懂代码"？

RAG问答场景下的具体影响

1. 使用传统切片的世界：
• 切分：代码可能会在db.query那一行被无情地切开。
• 检索：用户的提问可能会匹配到包含get_user_name的前半部分，但丢失了具体的实现。或者匹配到后半部分，但不知道这个查询是做什么的。
• 生成：LLM得到的上下文支离破碎，无法提供一个完整、可执行的函数作为答案。它可能会幻觉出错误的代码。

2. 使用代码感知切片的世界：
• 切分：get_user_name整个函数被完整地切分为一个独立的块，DataProcessor类被切分为另一个块。
• 检索：用户的提问和函数名、文档字符串（"Fetches the user's name..."）在语义上高度匹配。系统会精准地召回包含整个get_user_name函数的那个块。
• 生成：LLM得到了一个完整的、有明确输入输出、并且逻辑自洽的函数代码。它可以直接将这个函数作为答案呈现给开发者，甚至可以附上解释。

召回策略：符号、文档字符串与代码体的协同

• 具体实现："那段用SQL查询用户名的代码在哪？"

• 功能描述："怎么拿到用户的名字？"

• 函数签名："我记得有个函数接收user_id..."

• 代码体 (Code Body)：函数的具体实现逻辑。

• 文档字符串 (Docstring)：对函数功能的高层自然语言描述。

• 符号与签名 (Symbols & Signature)：函数名get_user_name，参数(user_id: int)。

Part 3: 核心策略对决与选择指南

3.1 策略对决：场景化分析

3.2 最终选择指南

1. 代码优先：一旦识别出是代码，无条件选择AST切片。

2. 结构次之：如果是非代码文本，优先寻找并利用其现有结构。对于有清晰段落的半结构化文本，RecursiveCharacterTextSplitter是最高效的选择。

3. 语义保底：只有当文本完全没有结构、语义又高度混杂时，才动用SemanticChunker这把"手术刀"来进行精细的语义解剖。

4. 滑动窗口是补充：滑动窗口并非独立的切片策略，而是一种增强手段。当你使用Recursive或Semantic处理时序性数据（如对话）时，通过设置overlap或自定义窗口逻辑，可以保留上下文连续性。

小结：从知识库到知识图谱的进化