爬虫老手转大模型：数据能力凭什么从采集变成 RAG 的护城河-育师

这篇我按“先跑起来、再讲取舍”的方式写《同样转大模型，爬虫背景的优势和短板分别是什么？》。概念会讲，但重点放在代码怎么组织、哪里容易踩坑。

摘要

上周需求评审，产品经理甩过来一个"简单的小需求"：给客服系统加个智能问答，能把过去两年的工单、FAQ 和内部文档都喂进去，让模型自动回复用户问题。

团队里两个同学接了这个活。一个是大模型方向的新手，上来就装好 LangChain，调了个开源 Embedding 模型，数据往向量库一丢，Demo 跑通了，截图发群里，配文"搞定了"。另一个是有三年爬虫背景的同学，没急着写代码，先问了三句话：数据从哪来？质量怎么保证？权限和日志怎么设计？

三周后，第一个 Demo 上线，客服反馈"答非所问的情况很多"；第二个同学已经跑完一轮灰度，准确率稳定在 85% 以上，而且出了问题能追溯到是哪条数据、哪个环节出的错。

这不是智商差距，是数据工程能力的差距。爬虫转大模型，最大的优势不是会写 Python，而是你早就习惯了和脏数据、权限边界、日志追踪打交道。下面我把这个转型过程中真正有价值的东西拆开来讲，不灌鸡汤，只讲能复用的东西。

爬虫技能在大模型时代的真实价值

很多人觉得爬虫就是requests.get()加BeautifulSoup，这种认知停留在十年前。现在做数据采集，真正值钱的是三件事：数据源评估、清洗策略、数据管道稳定性。

这三件事在大模型工程里，几乎原封不动地复用。

我先说结论：爬虫背景的同学转大模型，最容易上手的环节是数据准备层，最难跨越的环节是对模型输出质量的判断。前者是技能迁移，后者是认知升级。

以我最近做的一个内部知识库项目为例。输入是五类数据源：

历史工单（约 12 万条，非结构化文本）
产品文档（PDF，约 300 份）
FAQ 库（结构化，约 5000 条）
会议纪要（扫描件转文本，质量参差）
技术手册（表格为主）

第一步不是写代码，而是评估每类数据能喂给模型多少。工单里大量重复、格式不统一；PDF 里有大量图表和表格，OCR 质量不稳定；FAQ 质量最高但覆盖面窄。这个评估过程，和爬虫做数据源可行性调研完全一样——先判断值不值得采，再决定怎么采。

数据清洗：从"能抓到"到"能用"

爬虫老手最容易犯的一个错误是：以为抓到了就是完成了。大模型场景下，抓到的数据如果不清洗，比不抓更糟——模型会学到脏规则。

我们项目里有一次排查，发现模型对某个产品型号的回答经常出错。排查过程是这样的：

现象：用户问"XX 型号支持多少路录像"，模型回答"支持 8 路"，但实际文档里写的是"4 路"。

验证动作：
1. 定位到向量库里这条数据的 chunk 来源——是某份产品手册的 OCR 文本
2. 回溯原始 PDF，发现 OCR 把"4 路"识别成了"8 路"（字形相似导致的常见错误）
3. 检查清洗脚本，发现我们只做了去重和分段，没有做 OCR 后处理
4. 补充了一个关键词校对规则，对数字类实体做二次校验

排除结果：问题不是模型能力不够，是训练数据本身有误。清洗脚本补上 OCR 后处理后，同类问题消失了。

这个排查链路，和爬虫里定位"为什么这个字段抓不到"的逻辑完全一致：现象 → 溯源 → 验证 → 修复。区别只是，爬虫你验证的是数据对不对，大模型你验证的是数据能不能被模型正确理解。

下面这段代码是我们项目里清洗工单数据的核心逻辑，逐段解释：

def clean_ticket(raw_text: str, source_type: str) -> dict: """ 输入：原始工单文本、数据源类型 输出：清洗后的结构化数据，包含文本、元信息、质量评分 """ # 1. 基础清洗：去除无关字符和多余空白 text = re.sub(r'\s+', ' ', raw_text).strip() text = re.sub(r'[^\u4e00-\u9fa5a-zA-Z0-9，。！？、：；""''（）【】《》]', ' ', text) # 2. 按数据源类型做差异化处理 if source_type == "ticket": # 工单数据：提取关键实体（产品型号、故障现象、解决方式） entities = extract_entities(text) # 过滤掉内容过短或结构混乱的脏数据 if len(text) < 50 or not entities.get("product_model"): return {"status": "skipped", "reason": "insufficient_content"} elif source_type == "faq": # FAQ 数据：分离问题和答案，确保结构完整 parts = text.split('\t') if len(parts) < 2: return {"status": "skipped", "reason": "invalid_structure"} text, answer = parts[0], parts[1] entities = {"question": text, "answer": answer} # 3. 质量评分：基于长度、实体完整度、重复度 quality_score = calculate_quality(text, entities) return { "text": text, "entities": entities, "quality_score": quality_score, "source_type": source_type, "status": "cleaned" }

代码解释：

第一段是基础清洗，逻辑和爬虫里的数据预处理完全一致，去除换行、特殊字符，统一空格
第二段是差异化处理，这是爬虫经验迁移的关键——不同数据源有不同的结构特征，不能用同一套规则。工单要提取实体，FAQ 要分离问答对
第三段是质量评分，这是大模型场景特有的环节。爬虫你只关心"有没有抓到"，大模型你还要关心"抓到的数据模型能不能用好"。质量分低于阈值的直接丢弃，避免污染向量库

知识库构建：别急着上向量数据库

Demo 阶段很多人会跳过一个关键步骤：直接往向量库丢数据。这是爬虫老手最容易犯的配置错误。

我们项目里有一次失败经历：为了赶进度，把清洗后的 12 万条工单直接 Embedding 后存入 Milvus。跑了一周后，检索召回率只有 34%，而且很多返回的结果和查询问题完全无关。

失败原因分析：

业务错误：12 万条数据没有做分层，高价值的 FAQ 和低价值的重复工单混在一起，Embedding 向量被稀释
配置错误：Embedding 模型选的是通用中文模型，但对工单里的专业术语（如产品型号、故障代码）理解能力弱
环境错误：Milvus 的索引类型选了 HNSW，参数efConstruction设置过小，导致检索精度下降

调整方案：
1. 数据分层：FAQ（高质量，权重高）> 产品文档（中质量）> 工单（低质量，去重后保留）
2. Embedding 模型换成专门针对中文技术文档微调的模型
3. 索引类型换成 IVF_FLAT，参数调优后召回率提升到 78%

这个排查过程告诉我一个道理：向量库不是垃圾桶，数据质量比数据量重要一个数量级。爬虫老手的优势在于，你早就习惯了"数据清洗比数据获取更重要"这个认知，只需要把这个认知迁移到 Embedding 之前的环节。

RAG 语料生产：爬虫经验的真正用武之地

RAG 的核心是"检索 + 生成"，检索环节的质量直接决定最终输出。这里爬虫经验能发挥最大价值的是 chunk 策略设计。

很多教程会告诉你"按固定长度分段"，但这是错的。不同内容类型需要不同的分段策略：

FAQ：按问答对自然分段，不要截断
产品文档：按章节分段，保留标题层级作为元信息
工单：按"问题描述 - 解决过程 - 结果"三段式分段
会议纪要：按议题分段，保留时间戳和参会人员

下面这段代码展示了我们项目里的 chunk 策略：

def smart_chunk(text: str, chunk_type: str, max_tokens: int = 512) -> list: """ 输入：文本、数据源类型、最大 token 数 输出：分段列表，每段包含文本和元信息 """ chunks = [] if chunk_type == "faq": # FAQ：按问答对分割，不截断 pairs = re.split(r'\n{2,}', text) for pair in pairs: if pair.strip(): chunks.append({ "text": pair.strip(), "meta": {"type": "faq", "length": len(pair)} }) elif chunk_type == "document": # 文档：按标题层级分割，保留层级信息 sections = re.split(r'(?=#{1,3}\s)', text) for section in sections: # 对过长段落继续按句子分割 sub_chunks = split_by_sentences(section, max_tokens) chunks.extend(sub_chunks) elif chunk_type == "ticket": # 工单：按三段式结构分割 parts = re.split(r'(问题描述|解决过程|结果)', text) # 重组为三段 chunk_groups = group_ticket_parts(parts) for group in chunk_groups: chunks.append({ "text": group["text"], "meta": {"type": "ticket", "section": group["section"]} }) return chunks

代码解释：

这个函数的核心逻辑是按内容类型选择分段策略，不是一刀切
FAQ 保持完整问答对，避免模型看到半截问题
文档按标题层级分割，这样检索时能保留上下文关系
工单按三段式分割，让模型能分别理解问题、过程和结果
每段都带上元信息（meta），这是爬虫经验迁移的关键——你早就习惯了给数据打标签，现在只是把标签从"来源 URL"变成了"内容类型 + 分段位置"

合规边界：爬虫老手最容易忽视的盲区

这是转型过程中最需要补的一课。爬虫场景下，你关注的是"能不能抓"；大模型场景下，你还要关注"能不能用"。

我们项目里有一个合规红线：用户隐私数据不能进入向量库。工单数据里经常包含用户手机号、邮箱、地址等信息，必须在清洗阶段做脱敏处理。

下面这段代码是我们的脱敏逻辑：

def mask_sensitive_info(text: str) -> str: """ 输入：原始文本 输出：脱敏后的文本 """ # 手机号：11 位数字，1 开头 text = re.sub(r'1[3-9]\d{9}', '【手机号】', text) # 邮箱 text = re.sub(r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}', '【邮箱】', text) # 身份证号：18 位 text = re.sub(r'\d{17}[\dXx]', '【身份证】', text) # 地址：保留省市区，脱敏详细门牌 text = re.sub(r'([\u4e00-\u9fa5]{2,4}市[\u4e00-\u9fa5]{2,4}区)[^\d]{1,10}\d+', r'\1【地址】', text) return text

代码解释：