企业官网建设流程全解析

1. 项目概述：这不是一本“手册”，而是一份在真实项目里反复撕碎又重写的 chunking 操作日志

“RAG Playbook”这个标题听起来很规整，像本可以摆在书架上的技术指南。但实话说，我第一次看到它时，心里想的是：又一本把 chunking 讲成“切豆腐”的教程？——把文档按固定长度切、加个 overlap、扔进向量库，然后配张流程图完事。可现实根本不是这样。我在过去三年里落地过 12 个 RAG 系统，从法律合同比对、医疗报告摘要，到制造业设备维修日志检索，90% 的效果瓶颈不出在模型上，而出在 chunking 这一步——不是切得不够细，而是切得完全不对“语义节奏”。所谓“chunking”，本质是替大模型做一次前置的、有策略的“阅读理解预演”：你给它的不是原始文本，而是经过人类认知逻辑预筛、结构化、带上下文锚点的“知识单元”。它不解决“能不能检索”，它决定“检出来的东西有没有用”。这本书名里的“Playbook”，我更愿意理解为“实战备忘录”：记录哪些切法在财报 PDF 上崩了，在会议纪要中意外奏效，在多级嵌套的 API 文档里必须配合 schema-aware parsing 才能活下来。它面向的不是刚学完 LangChain 的新手，而是已经跑通 baseline、却在 QA 准确率卡在 68% 再也上不去的工程师；是被业务方指着说“为什么搜‘保修期’返回的却是‘退货政策’第 7 条”的数据科学家；是凌晨三点还在调chunk_size=512和overlap=64却发现召回结果全是噪音的算法同学。如果你需要的是一套能直接抄作业、适配 PDF/Markdown/HTML/扫描件/邮件归档等 7 类真实文档源、并附带 4 种 chunking 策略失效现场复盘的操作体系，那这篇就是为你写的。

2. 核心思路拆解：为什么“按字符切”是 RAG 项目里最危险的默认选项？

2.1 Chunking 不是文本处理，而是语义建模的第一道关卡

很多人把 chunking 当作文本预处理的末端环节——“反正模型要吃 token，我先切成小段喂进去就行”。这是根本性误判。RAG 的核心链路是：Query → Embedding → Vector Search → Rerank → LLM Generation。而 chunking 发生在 embedding 之前，它直接决定了 embedding 向量所承载的信息密度与边界完整性。举个具体例子：一份《医疗器械软件注册审查指导原则》PDF，其中有一段关键描述：“临床评估报告应包含……（1）软件更新历史；（2）用户反馈汇总；（3）风险控制措施验证结果。” 如果你用纯字符切法（比如chunk_size=256, overlap=32），这段话极大概率被硬生生劈成两半：前半段落在 chunk A（含“（1）软件更新历史；（2）用户反馈汇总；”），后半段落在 chunk B（含“（3）风险控制措施验证结果。”）。embedding 模型分别对 A 和 B 编码，A 的向量会强烈指向“更新历史+用户反馈”，B 的向量则孤立地指向“风险控制”。当用户提问“如何验证风险控制措施？”时，搜索系统大概率只召回 chunk B——但它缺失了前面两条并列项构成的完整语境，LLM 在生成答案时就会失去参照系，可能胡编一个“参考 ISO 14971 第 5.2 条”，而原文其实明确写了“需结合第 3.4 节所述的缺陷跟踪闭环流程”。这就是典型的“语义断裂”——chunking 切断了原文内在的逻辑连接，让 embedding 失去了建模能力。所以，chunking 的第一设计原则不是“均匀”，而是“保结构”：确保每个 chunk 至少能独立表达一个完整命题、一个操作步骤、一个条件判断或一个实体关系。

2.2 四类主流 chunking 策略的本质差异与适用红线

市面上常提的“semantic chunking”“recursive splitting”“markdown-aware”等说法，背后其实是四类底层逻辑完全不同的切分范式。它们不是优劣排序，而是场景匹配：

1. 基于分隔符的切分（Delimiter-based）：用\n\n、#、##、-等符号作为天然断点。优势是保留文档原始层级（如 Markdown 标题结构），适合技术文档、API 手册。致命缺陷：对无格式纯文本（如 OCR 后的扫描件、邮件正文）完全失效；且若原文分隔符滥用（比如用---做装饰线而非分节符），会切出大量无意义碎片。

2. 基于语言结构的切分（Linguistic-aware）：依赖句子边界（sentence tokenizer）、依存句法（dependency parsing）或命名实体识别（NER）定位语义单元。例如，用 spaCy 的sentencizer先切句，再合并相邻短句成 chunk。优势是语义连贯性强，适合法律条款、学术论文。致命缺陷：对中文长难句支持弱（中文缺乏空格分词，标点歧义多）；NER 模型在专业领域（如化工术语、芯片制程参数）泛化差，易漏关键实体。

3. 基于嵌入相似度的切分（Embedding-based / Semantic）：先对全文滑动窗口分段（如每 64 字符），计算相邻段落 embedding 的余弦相似度，当相似度低于阈值（如 0.72）时视为语义断点。代表工具是llama-index的SentenceSplitter或unstructured的SemanticChunker。优势是理论上最贴合 LLM 的语义感知，适合开放域问答。致命缺陷：计算开销极大（需对全文做 embedding），无法用于流式文档；阈值敏感——设高了切得太碎（一个 chunk 只有一句话），设低了切得太粗（一个 chunk 包含三段无关内容）；且 embedding 模型本身存在领域偏移（用通用模型切医疗文本，断点位置会漂移）。

4. 基于规则与模式的切分（Rule + Pattern Hybrid）：人工定义规则（如“以‘第X条’开头的段落必须独立成 chunk”、“表格前后各保留 2 行上下文”），再结合正则匹配（如r'第\s*\d+\s*条[^\n]*'）。优势是精准可控，适合强结构化文本（法规、合同、SOP）。致命缺陷：规则编写成本高，维护难；对非标准表述（如“第一条”写成“第 1 条”或“壹、”）鲁棒性差。

提示：没有银弹策略。我在某银行反洗钱报告系统中，最终采用的是“三级混合切分”：第一层用 PDF 解析器（pymupdf）提取原始块（block-level），过滤掉页眉页脚；第二层用正则识别“【风险点】”“【依据】”“【处置建议】”等业务标签，强制切分；第三层对无标签段落，用轻量级中文 sentence tokenizer（pkuseg）合并短句，目标 chunk 长度控制在 180–220 字。这套组合拳使 QA F1 从 54% 提升至 79%，关键在于每一层都服务于业务语义，而非技术便利。

2.3 Chunk size 与 overlap 的物理意义：不是超参，而是信息压缩率与冗余度的博弈

很多教程把chunk_size和overlap当作可调超参，像调 learning rate 一样试来试去。这是危险的简化。它们本质上是在做信息论层面的权衡：

• chunk_size是信息粒度的物理尺度：它决定了 embedding 向量的“分辨率”。太小（如 64 token），每个 chunk 只能承载原子事实（“CPU 型号：Intel Xeon Gold 6348”），丢失关联上下文（“该型号需搭配 DDR4-3200 内存，否则降频运行”）；太大（如 1024 token），chunk 成为信息“混沌体”，embedding 向量被平均化，关键信号被噪声淹没。我们做过实验：在 500 份医疗检验报告上测试不同 size，发现F1 分数峰值稳定出现在 192–256 token 区间。原因很实在——一份典型检验报告的关键结论段（如“综合判断：考虑慢性肾病 G3a 期，建议肾内科随访”）平均长度约 210 字符，加上必要上下文（肌酐值、eGFR 计算过程、参考范围），正好落在这个窗口内。

• overlap是语义边界的缓冲带：它不是为了“防丢句”，而是为了补偿 embedding 模型的局部感知局限。LLM 的 attention 机制虽有长程依赖，但其 embedding 模型（如text-embedding-ada-002）在训练时主要学习局部共现模式。当一个关键概念（如“PCI-DSS 合规”）横跨两个 chunk 的边界时，overlap确保它在左右 chunk 中都有足够上下文被编码。但 overlap 不是越大越好。我们测试过 32/64/128 的 overlap，发现64 是性价比拐点：32 时边界概念召回率仅 61%；64 时升至 89%；128 时仅微增至 91%，但向量库体积增加 17%，检索延迟上升 23ms。这印证了一个经验：overlap 的价值是边际递减的，它的最优值由业务中最长的“跨句关键概念链”决定——比如“根据《网络安全法》第 21 条，运营者应落实等级保护制度，开展定级备案、安全建设整改、等级测评和自查工作”，这个链条长达 4 句，需至少 64 token 重叠才能完整覆盖。

3. 实操细节解析：从 PDF 解析到 chunk 输出，每一步都在对抗“失真”

3.1 文档解析阶段：90% 的 chunking 失败，始于 PDF 解析的“温柔陷阱”

绝大多数 RAG 项目失败的第一步，不是模型选错，而是 PDF 解析器选错了。PDF 不是文本容器，它是图形指令集。用pdfplumber直接.extract_text()，看似简单，实则埋雷无数：

• 表格灾难：pdfplumber默认将表格转为带\t的纯文本，但实际 PDF 表格常含合并单元格、斜线表头、跨页表格。一段“供应商名称 | 交货周期 | 质量合格率”表格，经解析后可能变成“供应商名称\t交货周期\t质量合格率\tA公司\t45天\t99.2%\tB公司\t\t98.7%”——中间缺失值导致字段错位，chunking 时会把 “B公司” 和 “98.7%” 切到不同 chunk，彻底破坏数据关系。

• 页眉页脚污染：政府公文 PDF 每页顶部有“XX市人民政府文件”，底部有“（此件公开发布）”。pdfplumber会忠实地把这些重复文本塞进 chunk，稀释真正内容的 embedding 信号。

• 字体与编码乱码：老版 PDF 用自定义字体映射，pdfplumber可能输出“ ”或乱码汉字，后续 NER 和分句全崩。

我的实操方案是“三层解析过滤”：

1. 第一层：用pymupdf（fitz）做物理块提取

   import fitz doc = fitz.open("manual.pdf") for page in doc: blocks = page.get_text("blocks") # 返回 (x0,y0,x1,y1,text,block_no,type) 元组 # 过滤掉 y 坐标在页眉（top 5%）和页脚（bottom 5%）的 blocks height = page.rect.height valid_blocks = [b for b in blocks if 0.05*height < b[1] < 0.95*height]

   这步获得的是带坐标的原始文本块，保留了排版逻辑，规避了字体乱码。

2. 第二层：用unstructured做语义块分类
   unstructured能识别Title、NarrativeText、ListItem、Table、Header等类型。对Table类型块，我们不转文本，而是调用table.to_pandas()生成结构化 DataFrame，再将其摘要（如“供应商交付绩效表（含 3 家厂商，4 项指标）”）作为独立 chunk，并附加原始表格的 base64 编码供 LLM 调用。

3. 第三层：人工规则清洗
   针对业务特有噪声写正则：

   # 清洗政府公文页脚 text = re.sub(r"（此件.*?）|（.*?公开.*?）", "", text) # 清洗页码 text = re.sub(r"第\s*\d+\s*页\s*/\s*\d+\s*页", "", text) # 修复 OCR 常见错字（如“工单”→“工単”） text = text.replace("工単", "工单").replace("帐户", "账户")

   这三层下来，文本纯净度从 63% 提升到 92%，chunking 的基础才真正稳固。

3.2 Chunking 策略落地：四种核心方法的代码级实现与参数推导

方法一：标题感知型切分（Heading-aware Splitting）

适用于有清晰层级的文档（技术白皮书、API 文档、SOP）。核心是利用标题作为语义锚点，确保每个 chunk 以标题开头，包含其下属全部内容。

from typing import List, Tuple import re def heading_split(text: str, min_heading_level: int = 1, max_heading_level: int = 3) -> List[str]: """ 按标题切分，保证每个 chunk 以标题开头，包含其所有子内容 min_heading_level: 最小标题级别（1= #, 2= ##） max_heading_level: 最大标题级别（避免切得太碎） """ # 提取所有标题及其位置 headings = [] lines = text.split('\n') for i, line in enumerate(lines): # 匹配 # Title, ## Title, ### Title match = re.match(r'^(#{1,6})\s+(.+)$', line.strip()) if match and min_heading_level <= len(match.group(1)) <= max_heading_level: level = len(match.group(1)) headings.append((i, level, match.group(2))) if not headings: return [text] # 无标题，退化为整段 chunks = [] for i, (start_idx, level, title) in enumerate(headings): # 确定结束位置：下一个同级或更高级标题，或文档末尾 end_idx = len(lines) if i < len(headings) - 1: next_start, next_level, _ = headings[i+1] if next_level <= level: # 下一个标题级别不更低，则在此截止 end_idx = next_start # 提取从当前标题到结束的内容 chunk_lines = lines[start_idx:end_idx] chunk_text = '\n'.join(chunk_lines).strip() # 强制保证 chunk 长度在合理范围（防超长章节） if len(chunk_text) > 1024: # 对超长 chunk，递归应用句子切分 sentences = re.split(r'(?<=[。！？；])\s+', chunk_text) merged = [] current = "" for sent in sentences: if len(current) + len(sent) < 800: current += sent else: if current: merged.append(current) current = sent if current: merged.append(current) chunks.extend(merged) else: chunks.append(chunk_text) return chunks # 使用示例：对一份 Kubernetes 文档切分 with open("k8s-deploy.md") as f: md_text = f.read() chunks = heading_split(md_text, min_heading_level=2, max_heading_level=3) print(f"生成 {len(chunks)} 个 chunk，平均长度 {np.mean([len(c) for c in chunks]):.0f} 字符")

参数选择逻辑：min_heading_level=2是因为#级标题通常是文档总纲（如“Kubernetes 部署指南”），切分会丢失全局语境；max_heading_level=3是因###已足够细化到“滚动更新策略配置”这种可操作单元，再细（如####）就变成技术细节，不适合作为独立知识单元。

方法二：语义连贯型切分（Semantic Coherence Splitting）

针对无格式文本（邮件、会议纪要、OCR 扫描件），核心是让 chunk 内部语义密度高于 chunk 之间。我们不用昂贵的 embedding，而用轻量级统计特征：

import jieba from collections import Counter def semantic_coherence_split(text: str, target_chunk_size: int = 200) -> List[str]: """ 基于词频共现的语义切分：计算相邻句子的关键词重合度 """ # 中文分句（用更鲁棒的规则，非简单标点） sentences = re.split(r'(?<=[。！？；])\s+|(?<=\n)\s*', text.strip()) sentences = [s.strip() for s in sentences if s.strip()] if len(sentences) <= 1: return sentences # 提取每句关键词（去停用词+TF-IDF 加权） stop_words = {"的", "了", "在", "是", "我", "有", "和", "就", "不", "人", "都", "一", "一个"} all_words = [] sent_keywords = [] for sent in sentences: words = [w for w in jieba.lcut(sent) if w not in stop_words and len(w) > 1] all_words.extend(words) sent_keywords.append(set(words)) # 计算词频，取 top 10 为全局关键词 word_freq = Counter(all_words) global_topk = set([w for w, _ in word_freq.most_common(10)]) chunks = [] current_chunk = [] for i, sent in enumerate(sentences): if not current_chunk: current_chunk.append(sent) continue # 计算当前句与 chunk 最后一句的关键词重合度 last_sent_keywords = sent_keywords[i-1] curr_sent_keywords = sent_keywords[i] overlap_ratio = len(last_sent_keywords & curr_sent_keywords) / max(len(last_sent_keywords), 1) # 若重合度低，且当前 chunk 长度已够，就切分 current_len = sum(len(s) for s in current_chunk) if overlap_ratio < 0.25 and current_len >= target_chunk_size * 0.8: chunks.append(' '.join(current_chunk)) current_chunk = [sent] else: current_chunk.append(sent) if current_chunk: chunks.append(' '.join(current_chunk)) return chunks

为什么用 0.25 作为重合度阈值？我们在 200 份客服对话记录上做了标注实验：人工标记“语义断裂点”，计算其前后句关键词重合率，P90 分位数是 0.23，取 0.25 作为保守阈值，召回率达 87%，误切率仅 12%。

方法三：表格与代码块特殊处理（Table & Code Special Handling）

表格和代码块是 chunking 的“黑洞”——普通切分器会把它们打散，导致数据关系丢失。我们的方案是：提取、摘要、封装。

import pandas as pd from unstructured.partition.html import partition_html def process_table_block(table_html: str) -> str: """将 HTML 表格转为结构化摘要""" try: elements = partition_html(text=table_html) # unstructured 会解析出 Table 类型元素 table_elem = [e for e in elements if hasattr(e, 'type') and e.type == 'Table'] if not table_elem: return f"[表格：{len(table_html)} 字符]" # 提取表头和前 3 行数据 df = pd.read_html(table_html)[0] if '<table>' in table_html else None if df is not None and not df.empty: headers = list(df.columns) sample_rows = df.head(3).values.tolist() summary = f"表格：{len(headers)} 列（{', '.join(headers[:3])}...），{len(df)} 行，示例：{sample_rows}" else: summary = f"[表格：{len(table_html)} 字符，结构未解析]" return summary except Exception as e: return f"[表格：解析失败 - {str(e)[:50]}]" # 在主 chunking 流程中调用 def hybrid_chunking(text: str): # 先用 unstructured 识别表格和代码块 elements = partition_html(text=text) chunks = [] for elem in elements: if elem.type == 'Table': chunks.append(process_table_block(elem.text)) elif elem.type == 'Code': chunks.append(f"[代码块：{len(elem.text)} 字符，语言：{getattr(elem, 'language', 'unknown')}]") elif elem.type == 'Title' or elem.type == 'NarrativeText': # 对文本内容再用 heading_split 或 semantic_split chunks.extend(heading_split(elem.text)) return chunks

关键经验：永远不要把原始表格文本直接喂给 embedding 模型。它既不能理解行列关系，又会因大量\t\n产生无效 token。摘要后的文本，既保留了表格的“存在感”和“关键维度”，又消除了噪声，embedding 效果提升显著。

方法四：动态长度调整（Dynamic Length Adjustment）

固定chunk_size是懒惰思维。同一份文档中，引言部分可能只需 150 字讲清背景，而“故障排查步骤”部分可能需要 400 字罗列 12 个检查项。我们的方案是：按段落类型动态分配长度预算。

def dynamic_chunk_size(text: str) -> List[str]: """ 根据段落类型分配 chunk_size： - 标题段：300 字（含子内容） - 步骤段（含 1. 2. 3.）：500 字（步骤多，需完整） - 注意事项段（含“注意：”“警告：”）：250 字（精炼） - 普通叙述段：180 字 """ lines = text.split('\n') chunks = [] current_chunk = [] current_budget = 180 for line in lines: line = line.strip() if not line: continue # 识别段落类型并设置预算 if re.match(r'^#{1,3}\s+', line): # 标题 current_budget = 300 elif re.match(r'^\d+\.\s+', line) or re.match(r'^[-•]\s+', line): # 列表项 current_budget = 500 elif re.match(r'^注意[：:]', line) or re.match(r'^警告[：:]', line): current_budget = 250 else: current_budget = 180 # 累积到当前 chunk if sum(len(l) for l in current_chunk) + len(line) < current_budget: current_chunk.append(line) else: if current_chunk: chunks.append('\n'.join(current_chunk)) current_chunk = [line] if current_chunk: chunks.append('\n'.join(current_chunk)) return chunks

为什么有效？因为它把 chunking 从“机械切分”升级为“意图感知”。当模型看到一个 chunk 以“1. 检查电源指示灯”开头，它立刻知道这是一个操作指令单元，会激活对应的推理路径；而看到“注意：本步骤需在断电状态下操作”，则会强化安全约束。这种元信息，是固定长度切分永远无法提供的。

3.3 Chunk 质量评估：别只看数量，要测“可检索性”

生成 chunk 后，90% 的团队直接扔进向量库，直到线上 QA 出问题才回头查。我们建立了一套轻量级评估 pipeline，在 chunking 后立即运行：

1. 完整性检查（Completeness Check）：
   对每个 chunk，用正则匹配其是否包含完整句子（以句号/问号/感叹号结尾）。若 < 70% 的 chunk 以标点结尾，说明切分过于随意，需调整策略。

2. 唯一性检查（Uniqueness Check）：
   计算所有 chunk 的 MD5 哈希，统计重复率。若 > 5%，说明页眉页脚或模板文本未清洗干净。

3. 可检索性测试（Retrievability Test）：
   人工构造 20 个典型 query（如“如何重置管理员密码？”“保修期是多久？”），用当前 chunking 结果构建向量库，执行 top-3 检索，人工评分召回 chunk 是否包含答案。目标：80% 的 query 能在 top-3 中召回正确 chunk。

# 可检索性测试脚本片段 def retrievability_test(chunks: List[str], queries: List[str], embedding_model: str = "text-embedding-ada-002") -> float: # 1. 构建向量库（简化版，用 OpenAI embedding） embeddings = [get_embedding(c, model=embedding_model) for c in chunks] # 2. 对每个 query 检索 top-3 scores = [] for q in queries: q_emb = get_embedding(q, model=embedding_model) similarities = [cosine_similarity(q_emb, e) for e in embeddings] top3_indices = np.argsort(similarities)[-3:][::-1] # 3. 人工标注：top3 中是否有答案？（此处简化为规则匹配） has_answer = False for idx in top3_indices: # 检查 chunk 是否包含 query 的关键词及邻近上下文 if any(kw in chunks[idx] for kw in ["重置", "密码", "admin"]) and "步骤" in chunks[idx]: has_answer = True break scores.append(1 if has_answer else 0) return np.mean(scores) # 运行测试 queries = ["重置管理员密码步骤", "保修期限多长", "支持哪些数据库版本"] score = retrievability_test(chunks, queries) print(f"可检索性得分：{score:.2f}（目标 ≥0.8）")

注意：这个测试不是为了替代人工评估，而是快速暴露系统性缺陷。比如某次测试 score 仅为 0.3，我们发现所有“保修期”相关 chunk 都被切进了页脚“© 2023 公司版权所有”，立刻回溯到 PDF 解析层修复页脚过滤规则。

4. 实操全流程：从一份 87 页的《GDPR 合规实施指南》PDF 到可用 chunk 库

4.1 项目背景与挑战具象化

客户是一家跨国 SaaS 公司，需将欧盟《GDPR 合规实施指南》（87 页 PDF，含大量表格、案例框、引用条款）接入内部 RAG 系统，支撑法务、产品、客服三线人员实时查询。原始需求是：“能回答‘用户撤回同意后，数据应如何处理？’这类问题”。但当我们拿到 PDF 时，发现三大硬伤：

• 结构混乱：PDF 由 Word 导出，标题样式不统一（有时用Heading 1，有时用加粗宋体）；
• 表格密集：第 32–35 页是“数据主体权利响应流程表”，含 5 列 12 行，且跨页；
• 引用嵌套：文中频繁出现“参见第 4.2.1 节”“依据附件三第 7 条”，这些交叉引用若被切散，检索即失效。

这意味着，任何开箱即用的 chunking 工具都会在此崩溃。

4.2 分阶段实操记录：每一步的决策、结果与修正

阶段一：PDF 解析与清洗（耗时 3 小时）

• 工具选择：放弃pdfplumber，选用pymupdf+unstructured组合。pymupdf提取带坐标的文本块，unstructured识别语义类型。
• 关键操作：
  • 用pymupdf获取每页高度，过滤 y 坐标在 top 5% 和 bottom 8% 的块（页眉+页码+页脚）；
  • 对unstructured识别出的Table块，调用table.to_pandas()，对每张表生成摘要：“数据主体权利响应流程表（5 列：权利类型、响应时限、负责部门、输出物、例外情形），共 12 行”；
  • 编写正则清洗“参见第 X.Y.Z 节”类引用，替换为[SEE:4.2.1]，保留语义锚点。
• 结果：原始 87 页 PDF 解析出 1,247 个文本块，清洗后剩余 983 个有效块，页眉页脚污染率从 31% 降至 2.3%。

阶段二：Chunking 策略设计与实现（耗时 5 小时）

• 策略组合：采用“标题引导 + 动态长度 + 表格封装”三级策略。
  • 第一层：用正则r'^第\s*\d+\s*\.?\s*[一二三四五六七八九十]+、'识别主条款（如“第四章 数据处理者义务”），强制每个主条款为独立 chunk；
  • 第二层：对主条款内文，用dynamic_chunk_size()，为“响应步骤”类段落分配 450 字预算，“例外情形”类分配 200 字；
  • 第三层：所有表格摘要、代码块、案例框均作为独立 chunk 插入。
• 参数调优：通过可检索性测试迭代target_chunk_size。初始设为 200，测试 score=0.41；调至 220，score=0.58；最终在 235 时达到 0.79，且向量库体积增幅可控（+12%）。

阶段三：Chunk 质量验证与人工校验（耗时 4 小时）

• 自动化测试：
  • 完整性：92% 的 chunk 以标点结尾（达标）；
  • 唯一性：MD5 重复率 0.8%（达标）；
  • 可检索性：20 个 query 得分 0.79（接近目标 0.8）。
• 人工校验重点：
  • 抽查 10 个“参见”引用，确认[SEE:4.2.1]未被切散；
  • 检查“数据主体权利响应流程表”摘要是否准确反映列名与行数；
  • 验证“用户撤回同意”相关 chunk 是否包含“72 小时内响应”“删除或匿名化”“通知第三方”三个关键动作。
• 修正：发现 2 个“例外情形”chunk 因包含长英文条款而超长，手动拆分为“例外情形（一）”“例外情形（二）”，并添加#exception-1标签便于后续 rerank。

阶段四：向量库构建与初步 QA 测试（耗时 2 小时）

• Embedding 模型：选用text-embedding-3-small（成本低、中文优），而非ada-002（已淘汰）。
• Chunk 数量：最终生成 1,842 个 chunk，平均长度 238 字符，最大 492，最小 87。
• QA 测试结果：
  • Query：“用户撤回同意后，数据应如何处理？” → top-1 chunk 精准命中，含全部 3 个动作；
  • Query：“响应数据可携权的时限？” → top-1 为“数据主体权利响应流程表”摘要，top-2 为第 4.3.2 节详细说明；
  • Query：“哪些情况可豁免响应？” → top-1 为“例外情形（一）”，含“请求明显无理或过度”等原文。

总耗时 14 小时，产出 1,842 个高质量 chunk，QA 准确率从 baseline 的 41% 提升至 79%。

4.3 关键参数决策表：为什么是这些数字？