聊《别急着换赛道：爬虫经验在 AI 项目里到底值多少？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

最近面试了几个从爬虫转大模型的同学，问得最多的问题是："我抓了三年数据，现在做RAG是不是从零开始？"

我的回答是：你抓数据的能力，在大模型项目里值不少钱，但前提是你要把"采集"这件事重新理解一遍。

---

目录

• 爬虫技能在AI项目里的真实价值
• 数据清洗：从"能抓回来"到"能用"
• 知识库构建：结构化是核心
• RAG语料生产：工程化才是护城河
• 合规边界：权限、日志和可观测
• 总结：怎么准备转型

爬虫技能在AI项目里的真实价值

很多人以为爬虫转大模型就是换个框架，其实不是。爬虫的核心能力是信息获取与结构化，这在RAG项目里直接对应两个关键环节：数据源接入和语料预处理。

我之前做过一个企业知识库项目，客户有几十套系统，数据散落在各个角落。传统做法是让开发一个个对接API，但我的爬虫经验让我直接写了个统一采集层，把分散的数据源标准化输出。这部分工作在大模型项目里，本质上就是数据工程。

招聘JD里经常写"有数据采集、清洗经验优先"，翻译一下就是：你懂怎么把脏数据变成模型能用的东西。这点爬虫出身的人天然有优势。

---

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

爬虫阶段你关注的是抓全，大模型阶段你关注的是抓准。

我踩过的坑：有一次做RAG语料，直接把爬来的HTML用BeautifulSoup解析后喂给Embedding模型，结果召回质量很差。后来才发现，HTML里的导航栏、广告、脚注全混进去了，噪声太大。

失败原因：Embedding模型对语义相似度敏感，导航栏的"首页|产品|关于"和正文内容在向量空间里距离很近，导致检索时这些无关片段频繁出现在Top-K结果里。更麻烦的是，广告文案往往包含大量关键词堆砌，进一步污染了向量分布。

清洗不是简单去标签，要建立质量判断标准。我的做法是：

import re
from bs4 import BeautifulSoup

def clean_html(html: str) -> str:
    """
    清洗HTML语料，移除噪声元素并提取正文。

    适用边界：适用于新闻类、博客类、文档类网页。
    不适用场景：SPA单页应用（内容动态渲染）、PDF转换的HTML、
    表格密集型数据页面（会丢失结构信息）。
    """
    soup = BeautifulSoup(html, 'html.parser')

    # 移除噪声元素：script/style是代码，nav/footer/header/aside是页面框架
    # 注意：article/main才是正文容器，不要移除
    for tag in soup(['script', 'style', 'nav', 'footer', 'header', 'aside', 'iframe', 'noscript']):
        tag.decompose()

    # 优先从article或main标签提取， fallback到全文
    content_tag = soup.find('article') or soup.find('main') or soup.body
    if content_tag:
        text = content_tag.get_text(separator='\n', strip=True)
    else:
        text = soup.get_text(separator='\n', strip=True)

    # 清理空行：3个以上换行压缩为2个，避免段落间空白过大
    text = re.sub(r'\n{3,}', '\n\n', text)
    # 清理行内多余空格和制表符
    text = re.sub(r'[ \t]+', ' ', text)
    # 移除首尾空白
    text = text.strip()

    return text

代码解释：

• decompose() 和 extract() 的区别：前者直接从树中删除节点，后者删除但保留引用。这里用 decompose() 更彻底，避免残留属性污染。
• 优先查找 article/main 标签：现代网页通常用语义化标签标记正文，直接提取比全文过滤更准确。
• 正则替换顺序很重要：先压缩连续换行，再清理行内空格。如果反过来，可能会把正常的段落分隔符也抹掉。

---

知识库构建：结构化是核心

爬虫转RAG最容易忽略的一点：结构化能力。

爬数据时你可能习惯了JSON、CSV这些格式，但做知识库时，你需要考虑的是切分策略、元数据设计、向量索引这些新东西。

我的经验是：

1. 切分不要一刀切。长文档按章节切，短文档按段落切，代码文档按函数切。
2. 元数据要带够。来源URL、采集时间、作者信息，这些在检索时都能用上。
3. 向量索引选对。长文本用Chunk-based，短文本用Document-based，别混着用。

适用边界：上述策略适用于中文技术文档、产品手册、FAQ类内容。对于法律条文、医学指南等强结构文本，建议保留层级关系而非简单切分；对于对话记录、评论数据，切分后会丢失上下文，需要改用滑动窗口或对话单元切分。

---

RAG语料生产：工程化才是护城河

最近行业有个趋势：大模型应用从Demo转向权限、日志和可观测。这对爬虫出身的人是个机会。

为什么？因为RAG系统的核心就是数据流水线，而数据流水线的工程化能力，正是爬虫开发者最熟悉的领域。

我之前搭过一个RAG语料生产系统，关键模块包括：

• 数据采集调度（定时/触发）
• 质量评估（去重、去噪、完整性检查）
• 向量化管道（批量处理、错误重试）
• 索引更新策略（增量/全量）

这套系统的架构，和爬虫的调度系统几乎一样。区别只在于输出物从"结构化数据"变成了"向量库"。

故障排查流程：

当发现召回质量下降时，按以下步骤定位：

1. 检查数据源变化
   - 对比最近一次成功召回时的语料样本
   - 检查是否有新页面结构变更导致清洗规则失效

2. 检查Embedding质量
   - 抽样100条向量，用PCA降维可视化，观察是否有异常聚类
   - 对比不同Embedding模型的召回率（text-embedding-3-small vs bge-large）

3. 检查索引状态
   - 确认向量库中文档数量与预期一致
   - 检查是否有重复ID覆盖或丢失
   - 验证元数据字段是否完整写入

4. 检查检索参数
   - 调整top_k（默认10，有时5更准）
   - 检查是否开启了混合检索（关键词+向量），权重是否合理

实际案例：有一次召回率突然从85%掉到60%，排查发现是某个数据源改版，新增了大量"相关文章"推荐模块，清洗规则没覆盖到这个新区域，导致噪声数据入库。修复方式是补充选择器规则，召回率恢复到83%。

---

合规边界：权限、日志和可观测

这里要重点说。爬虫转大模型，合规意识不能丢，反而要更强。

企业级RAG项目对权限控制很敏感。比如：

• 哪些数据能进知识库
• 谁有权访问哪些内容
• 检索结果要不要做权限过滤

这些都需要在系统设计阶段就想清楚。我之前的做法是：在数据入库前加一层权限标签，检索时根据用户角色做过滤。

日志和可观测性也一样。爬虫阶段你可能只关心抓没抓到，但RAG阶段你需要知道：

• 每次检索的耗时
• 召回质量分布
• 错误率和重试情况

这些指标决定了你的系统能不能真正上线。

适用边界：权限过滤方案适用于角色明确的B端系统。对于C端公开内容，重点转向版权合规和robots协议遵守；对于内部敏感数据，需要增加审计日志和数据脱敏，不能仅靠角色过滤。

---

总结：怎么准备转型

如果你现在是爬虫开发，想转大模型方向，我的建议是：

1. 不要从头学Python。你的基础已经够了。
2. 重点补RAG相关技能：Embedding、向量数据库、Prompt工程。
3. 做一个完整项目。从数据采集到RAG问答，把整条链路跑通。
4. 关注工程化能力。权限、日志、可观测，这些是Demo和生产的区别。

爬虫经验不是包袱，是把双刃剑。用对了，它在AI项目里很值钱；用错了，你可能只会抓数据，不会做知识。

---

参考资料：LangChain官方文档、向量数据库最佳实践、RAG工程化指南。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

需要这份AI大模型资料清单的话，在评论区回复「清单」即可；我会根据大家的问题继续补充对应的实战内容。