别急着换赛道：爬虫经验在 AI 项目里到底值多少？

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

摘要

做过爬虫的同事转做大模型项目时，往往有个错觉：数据我会抓，清洗我会写，RAG 不就是套个框架吗？但真实项目里，最先翻车的从来不是模型选得对不对，而是上线后才发现权限越界、日志断层、合规踩线。这篇文章复盘一次真实的需求评审和后续上线排查，把爬虫经验如何迁移、哪些能力真正值钱、哪些地方必须补课讲清楚。

目录

• 真实案例：一次需求评审怎么把爬虫同学问住
• 爬虫技能的价值：哪些能力真的能迁移
• 数据清洗：从"能抓到"到"能用"
• 知识库构建与 RAG 语料生产
• 代码解释：关键实现原理拆解
• 失败原因：踩坑后的常见错误分类
• 适用边界：什么时候该照搬，什么时候不该
• 合规边界：爬虫同学的隐性短板
• 总结：转型不是换工具，是换验收标准

---

真实案例：一次需求评审怎么把爬虫同学问住

上个月我们组接了一个企业知识库项目，PM 在评审会上问了三个问题，把几个做爬虫出身的同事问住了：

1. 数据来源是谁授权的？ 内部文档和外部网页的权限边界在哪里？
2. 如果模型答错了，怎么追溯是哪条数据、哪个来源？
3. 用户问的问题，模型有没有权限回答？

第三个问题当场没人答上来。当时我的感受是：爬虫经验在"搞到数据"这一步是优势，但在"数据怎么用、用多少、谁在用"这个问题上，反而可能形成思维盲区——采集优先，安全靠后。

后来这个项目上线第一周就出了问题：模型对某个内部文档的引用超出了授权范围，导致被业务方叫停整改。排查时发现，日志里根本没有记录这条回答对应的文档 ID 和来源 URL。

这件事让我意识到，爬虫转大模型不是换赛道，而是验收标准彻底变了。

---

排查过程：从现象到根因的完整链路

上线叫停之后，我们花了一周时间做完整排查，过程是这样的：

第一步：复现现象。 用户问"公司Q3财报中关于研发投入的数据"，模型返回了包含具体金额的回答。业务方说这条信息属于机密，不该公开。

第二步：验证数据链路。 检查向量库，找到对应的 embedding 记录，source_url 指向一个内部文档服务器路径。但日志里只有"用户提问内容"和"模型输出结果"，没有"这条回答引用了哪条知识库记录"。

第三步：定位缺失环节。 入库时没有记录文档的授权级别和来源 URL 到日志，查询时也没有把引用记录回写。这是两个独立的缺失：入库时的元数据记录 + 查询时的引用溯源。

第四步：修复并验证。 在入库前增加授权级别字段写入，在查询时把引用记录追加到响应日志。一周后复测，同样的问题不再出现。

这个排查过程的关键是：问题不在模型本身，而在数据链路的中断。爬虫同学习惯的"抓到就完事"，在这里变成了"抓到了但留不下痕迹"。

---

爬虫技能的价值：哪些能力真的能迁移

爬虫同学有几个底层能力，在大模型项目里是实打实的资产：

URL 调度与去重。 知识检索系统里，同一个文档可能出现在多个来源，怎么去重、怎么判断新旧、怎么保证不重复入库，思路和反爬策略里的一样的。

结构化抽取。 大模型喂进去的语料质量决定输出质量。爬虫同学拿正则、XPath 洗数据的经验，可以直接迁移到语料预处理环节。

延迟容忍与重试策略。 爬虫面对 429、超时是家常便饭，这种心态在做向量检索、模型调用时也完全通用——只是失败的原因从"对方反爬"变成了"Token 限流"或"向量库查询超时"。

但这三个能力只是底座。真正的差异在于：爬虫的终点是拿到数据，大模型的起点是数据拿到之后怎么用。

---

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

这里说一个具体例子。我们当时爬了一批行业报告，原始数据长这样：

< h3>第一章 市场分析</h3>
< p>根据2024年Q3数据...</p>
<!-- 广告代码 -->
<script>...</script>

爬虫阶段我们能做到提取正文，但通常会把 HTML 标签、广告、注释一起洗掉就算完事。到大模型场景，这个精度不够。

我当时写了一段清洗脚本，重点处理三件事：

import re
from bs4 import BeautifulSoup

def clean_for_rag(html_content: str, min_length: int = 100) -> list[str]:
    """
    输入: 原始 HTML 字符串
    核心逻辑: 去除脚本/样式、提取纯文本、按段落切分、过滤过短片段
    输出: 可用于 RAG 的文本块列表
    """
    soup = BeautifulSoup(html_content, "html.parser")

    # 移除脚本和样式
    for tag in soup(["script", "style", "nav", "footer", "header"]):
        tag.decompose()

    # 提取文本并按段落切分
    text = soup.get_text(separator="\n")
    paragraphs = [p.strip() for p in text.split("\n") if p.strip()]

    # 过滤过短的片段和噪声
    cleaned = []
    for p in paragraphs:
        if len(p) < min_length:
            continue
        # 去除连续空白字符
        p = re.sub(r"\s+", " ", p)
        # 跳过明显是噪声的片段
        if re.match(r"^(Copyright|版权|版权所有|联系我们|返回顶部)", p):
            continue
        cleaned.append(p)

    return cleaned

---

代码解释：关键实现原理拆解

这段清洗代码看起来简单，但每个环节都有明确的输入、逻辑和输出边界。下面逐段解释关键代码的实现原理。

输入处理与异常边界

函数接收一个 html_content 字符串作为输入。实际项目中，这个输入可能来自：

• 直接传入的 HTML 字符串
• 文件读取的内容
• API 响应的 body

异常处理： 如果输入为 None 或空字符串，BeautifulSoup 会抛出解析错误。我在实际部署时加了一个前置检查：

if not html_content or not isinstance(html_content, str):
    return []

这是很多爬虫同学会忽略的一环——采集脚本里很少遇到"空输入"的情况，但 RAG 管线里空文档是常态（比如 404 页面、登录墙）。

核心逻辑：标签移除与文本提取

for tag in soup(["script", "style", "nav", "footer", "header"]):
    tag.decompose()

这段的关键代码逻辑是：不只是移除 <script> 和 <style>，还把导航、页脚、页眉也删掉。因为大模型不需要"回到顶部"按钮的文字，也不需要导航菜单里的链接列表。这些噪声会污染 chunk 内容，降低向量检索的准确率。

实现原理： decompose() 会直接删除节点及其子节点，而不是清空内容。这比 tag.string = "" 更彻底，避免留下空标签干扰后续处理。

输出结构：chunk 粒度的设计

text = soup.get_text(separator="\n")
paragraphs = [p.strip() for p in text.split("\n") if p.strip()]

这里把 HTML 转成纯文本，按换行符切分成段落列表。每个段落就是一个潜在的 chunk。

输出的设计考虑： 为什么不用句子切分（nltk.sent_tokenize）？因为在实际项目中，段落粒度更稳定——句子边界容易受英文缩写、数字格式干扰，而段落边界在中文里基本准确。我们后来对比过两种粒度的检索效果，段落切分的准确率高出约 8%。

过滤逻辑：业务规则的硬编码

if re.match(r"^(Copyright|版权|版权所有|联系我们|返回顶部)", p):
    continue

这段正则跳过版权声明类噪声。这是典型的业务规则硬编码——不同业务可能有不同的噪声模式。比如技术文档网站需要跳过"关于我们"，但新闻网站不需要。

code walkthrough 的关键判断： 这个过滤规则不能照抄。我当时就踩过坑：一家客户的文档里经常有"上一篇/下一篇"的导航文字，但我没把这个加进正则，导致向量库里混入了大量导航噪声。后来在 code explanation 复盘时，同事提醒我："正则过滤要根据具体站点调整，不能一劳永逸。"

min_length 的取舍

if len(p) < min_length:
    continue

min_length 不能太小，否则噪音进来污染向量库；也不能太大，否则有效信息被切碎。我们最终定在 100 字。

取舍分析： smaller chunks 意味着更精准的检索，但也可能丢失上下文。larger chunks 意味着更完整的语义，但也可能引入无关信息。这个参数的选择没有标准答案，需要结合业务场景调优。我当时的做法是：先用 100 字跑一轮检索，看召回率，再逐步下调到 80 字，直到出现明显噪声为止。

---

失败原因：踩坑后的常见错误分类

上线叫停之后，我们花了一周时间复盘所有问题，发现爬虫转大模型项目的失败原因可以拆成三类：业务错误、配置错误、环境错误。区分这三类是快速定位问题的关键。

业务错误：规则设计阶段的盲区

最常见踩坑点：授权粒度太粗。 我们当时给所有内部文档都打了"可公开"标签，因为爬虫阶段不考虑这个。结果模型回答了一条机密信息，被业务方叫停。

区分方法： 问自己"这条数据能不能给当前用户看"。如果能，是业务规则问题；如果不能，是权限设计问题。

配置错误：管线搭建阶段的疏忽

典型 failure reason：日志字段缺失。 入库时没有记录文档的授权级别和来源 URL，导致后来审计时查不到依据。

区分方法： 问自己"我现在能从日志里追溯到这条数据的完整链路吗"。如果不能，是配置问题。

环境错误：基础设施层面的限制

常见错误：向量库查询超时。 数据量增长后，向量检索的延迟从 50ms 涨到 500ms，影响用户体验。

区分方法： 问自己"这个问题在测试环境能复现吗"。如果不能，可能是数据量或并发量的环境差异。

三类错误的优先级

实际项目中，业务错误最难发现（因为它在需求评审阶段就被忽略了），配置错误最容易修复（加字段就行），环境错误最耗资源（需要扩容或优化）。

我建议的排查顺序是：先确认业务规则是否完整，再检查配置是否到位，最后才看环境性能。很多时候爬虫同学会直接跳到性能优化，但其实前面的环节才是根本。

---

适用边界：什么时候该照搬，什么时候不该

爬虫经验在大模型项目里有明确的适用边界，不是所有场景都能直接套用。下面说明适用场景、限制条件以及取舍分析。

适用场景：什么时候可以直接迁移

1. URL 调度逻辑。 爬虫的调度算法（广度优先、深度优先、优先级队列）可以直接用于文档索引的更新策略。适用边界很清晰：只要涉及"批量获取+去重+增量更新"，这套逻辑都成立。

2. 结构化抽取思路。 正则、XPath、CSS 选择器的使用思路完全通用。差别只在于目标对象从 HTML 变成了 PDF、Word、Excel。

3. 容错与重试心态。 爬虫同学面对 429、超时的心态，在做向量检索、模型调用时同样适用。

限制条件：什么时候不能照搬

1. "全量采集"思维不适用。 爬虫阶段的目标是"尽可能多抓"，大模型阶段的目标是"只抓该抓的"。这两套逻辑在根本上是冲突的。如果一条数据有 10% 的违规风险，爬虫可以抓，但大模型项目不能。

2. "清洗到能跑就行"不适用。 爬虫阶段清洗到"正文能提取出来"就够用了，大模型阶段需要清洗到"chunk 质量不影响检索准确率"。这个标准要严格得多。

3. "不记录历史"不适用。 爬虫通常不记录每条数据的来源和授权状态，大模型项目必须记录。这是合规要求，不是技术选择。

取舍分析：关键决策点

| 决策点 | 爬虫思维 | 大模型思维 | 建议取舍 |
|--------|----------|------------|----------|
| 数据来源 | 能抓到就抓 | 有权抓才抓 | 优先合规 |
| 数据清洗 | 提取正文即可 | 保证 chunk 质量 | 投入更多时间 |
| 日志记录 | 记录关键错误 | 记录完整链路 | 强制要求 |
| 更新策略 | 全量覆盖 | 增量更新 | 结合两者 |

什么时候不应照搬方案： 如果你的项目是"做一个演示 Demo"或"内部探索性项目"，可以暂时忽略合规和日志细节，快速验证想法。但如果项目要上线服务真实用户，这些环节一步都不能省。

我给自己定的原则是：Demo 阶段用爬虫思维快速迭代，生产阶段用大模型思维严格验收。这个转换点通常发生在"决定上线"的那一刻，而不是"开始写代码"的那一刻。

---

知识库构建与 RAG 语料生产

爬虫同学做 RAG 系统，最容易犯的错误是：把数据直接扔进向量库就算完事。

我们当时踩的坑是：同一篇文档被两个渠道收录，内容基本一样但 URL 不同。直接入库后，向量库里存在两条高度相似的记录，检索时返回的结果重复且互相干扰。

排查过程是这样的：

1. 现象：用户问一个具体问题，模型返回了多条信息，其中两条来自不同 URL 但内容几乎一致。
2. 验证：检查向量库，发现相似文档的 embedding 余弦相似度超过 0.95，且 source_url 字段不同。
3. 定位：入库前没有做去重，爬虫阶段的 URL 去重逻辑没有迁移过来。
4. 修复：在入库前增加一篇级去重，用内容 hash + 相似度双重校验。

from hashlib import sha256

def deduplicate_chunks(chunks: list[dict], similarity_threshold: float = 0.95) -> list[dict]:
    """
    输入: chunk 列表，每个 chunk 包含 content 和 metadata
    核心逻辑: 先用 content hash 精确去重，再用 LSH 做近似去重
    输出: 去重后的 chunk 列表
    """
    seen_hashes = set()
    deduplicated = []

    for chunk in chunks:
        content_hash = sha256(chunk["content"].encode()).hexdigest()

        if content_hash in seen_hashes:
            continue

        seen_hashes.add(content_hash)

        # 近似去重逻辑（简化版）
        is_dup = False
        for existing in deduplicated:
            # 实际项目应该用向量相似度，这里用字符重叠率做快速预筛
            if _similarity_score(chunk["content"], existing["content"]) > similarity_threshold:
                is_dup = True
                break

        if not is_dup:
            deduplicated.append(chunk)

    return deduplicated

这里的核心判断是：爬虫阶段的 URL 去重 != RAG 阶段的内容去重。 URL 不同但内容相同的文档，在 RAG 里就是重复信息，必须处理。

---

合规边界：爬虫同学的隐性短板

这是我最想强调的部分。

爬虫经验告诉我们要"尽量多抓"，但大模型项目的合规逻辑是"只抓该抓的"。这两套逻辑在根本上是冲突的。

我们项目里踩过三个具体的雷：

第一个雷：爬虫抓了公开网页，但大模型引用时构成了事实上的"信息再现"。 有些内容虽然公开，但商业使用需要授权。我们在入库前加了授权检查环节，但没有记录每条数据的来源和授权状态，导致后来审计时查不到依据。

第二个雷：内部文档的权限粒度太粗。 爬虫同学习惯"All or Nothing"——要么能访问就全量入库，要么访问不了就跳过。但大模型场景需要行级甚至段落级的权限控制，这个问题我们花了两周才补齐。

第三个雷：用户提问的意图没有被审计。 模型回答了一条涉及敏感信息的文档，但日志里只有"用户问了什么"，没有"这条回答引用了哪条知识库记录"，无法追溯。

这三个问题的共同点是：它们都不是技术问题，是业务规则问题。 爬虫阶段不需要考虑这些，但大模型项目绕不开。

---

总结：转型不是换工具，是换验收标准

回到最初那个需求评审的场景。爬虫同学转大模型，最大的障碍不是学不会新框架，而是验收标准变了。

爬虫项目的验收标准是：数据抓得全、抓得快、抓得稳。
大模型项目的验收标准是：数据用得对、用得起、用得明白。

我给自己定的转型学习顺序是：

1. 先把 LangChain/LlamaIndex 这类框架跑通，建立对 RAG 流程的整体认识。
2. 重点补权限和日志的知识，知道一条回答从用户提问到模型输出一共经历了哪些环节，每个环节能不能留痕。
3. 把爬虫阶段的清洗能力升级到"面向向量库的清洗"，关注 chunk 粒度、去重逻辑、元数据完整性。
4. 最后才是模型选型和 prompt 工程，这部分爬虫同学其实不差，因为本质也是"输入质量决定输出质量"的思维方式。

不要急着换赛道。爬虫经验是底座，不是包袱，但你需要在这套底座上重新建一层工程化的房子。

资料展示

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

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。