如果你正准备往大模型方向转，别急着换赛道。更重要的是判断自己该补哪块能力，以及怎么证明你真的会。

摘要

目录

• 真实案例
• 爬虫技能的价值
• 数据清洗
• 知识库构建
• RAG 语料生产
• 代码解释
• 排查过程
• 失败原因
• 适用边界
• 总结

真实案例

去年我带过一个电商售后知识库项目，团队里有两个从爬虫转过来的同学。其中一个把简历写的是"会用 Scrapy 抓取商品信息"，另一个写的是"基于 Scrapy 构建了 200 万条售后知识条目，通过 Dify 接入 RAG 后，客服工单自动回复准确率从 41% 提升到 78%"。

两个项目用的是同一套基础设施，最后的产出却完全不在一个量级。

那个准确率的数字不是编的，是我亲眼看着他们跑的。项目输入是客服历史工单文本和售后政策文档，中间经过清洗、向量化、存入向量库，输出是 RAG 检索后的回答。整个链路里，爬虫同学负责的是最脏也最关键的一环：把散落在各个售后文档、工单记录、FAQ 页面里的碎片信息，整理成能喂给模型的干净语料。

这不是写个 Scrapy 脚本就完事了的事。

真正拉开差距的是，后者在简历里写清楚了三个东西：数据从哪来、怎么验证质量、接入 RAG 后指标怎么变。前者只写了用了什么框架。

爬虫技能的价值

爬虫工程师转大模型，最容易踩的坑是把"能抓数据"当成唯一卖点。但真正值钱的是你在数据采集过程中积累的三件事。

第一是对数据源的判断力。哪些页面值得抓、哪些是噪音、什么时候需要绕过反爬、什么时候该换策略——这些判断在 RAG 语料生产里同样适用。你不需要再写 Scrapy 了，但你需要判断哪些文档值得入库、哪些内容应该过滤。

第二是数据质量意识。爬虫圈有一句老话：垃圾进，垃圾出。这句话在大模型时代被放大了十倍。一条错误的售后政策被向量化后存进知识库，模型回答时就会自信地输出错误信息，而且你很难第一时间发现。

第三是工程化习惯。爬虫项目天然要求你处理异常、记录日志、管理调度。这些习惯在 Agent 项目里直接复用——只不过你现在处理的不再是 HTTP 请求，而是模型调用、工具执行和权限校验。

数据清洗

很多转大模型的爬虫同学会低估数据清洗的工作量。你以为拿到原始文本就完事了？实际上，一份能直接喂给 RAG 的文档，至少要经过这几步。

首先是去噪。电商售后文档里最常见的噪音包括：页眉页脚、广告链接、版权声明、重复段落、HTML 标签残留。我们用过一个简单的规则过滤：提取正文段落后，计算每段的字符密度和有效词占比，低于阈值的直接丢弃。这个逻辑和爬虫里的去重思路完全一致。

其次是分段。向量检索的质量很大程度上取决于文档切分的方式。太短会丢失上下文，太长会稀释关键信息。我们最终用的策略是：按段落切分后，如果一段超过 500 字就按句号重新切，同时保留相邻段落的语义关联。

第三是元数据标注。这一点很多爬虫同学会忽略，但它直接决定 RAG 的检索精度。我们在每条语料里都打了三个标签：来源类型（工单/政策/FAQ）、适用范围（全国/特定地区）、时效性（长期有效/有截止日期）。检索时可以根据这些标签做加权，避免把过期的政策当成当前依据。

知识库构建

RAG 项目的知识库构建，本质上是把清洗后的语料变成向量。但这里有个坑：向量库不是越全越好。

我们最初建库的时候，把所有文档一股脑塞进去，结果检索命中率只有 35%。排查后发现，问题出在向量维度稀释——大量低质量的 FAQ 和重复文档淹没了高价值的政策原文。后来我们做了两件事：一是按来源类型设置不同的入库优先级，政策文档权重是 FAQ 的三倍；二是做了去重，基于文本相似度过滤掉重复入库的条目。

去重这一步，爬虫同学天然有优势。你们肯定写过 URL 去重、内容指纹这些逻辑，迁移到文本去重上就是几个函数的事情。

向量库选型上，我们最终用的是 Chroma，原因是部署简单、支持本地运行，适合内部知识库场景。如果你们公司有现成的 Milvus 或 Weaviate 集群，直接用就行。选型本身不是重点，重点是理解检索的召回率和准确率怎么测——这个后面会讲。

RAG 语料生产

语料生产是整个链条里最能体现爬虫工程能力的环节。我们用的流程是这样的：

import hashlib
from typing import List, Dict
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.schema import Document

def produce_training_corpus(raw_texts: List[str], source_meta: List[Dict]) -> List[Document]:
    """
    输入：原始文本列表和对应的元数据
    输出：可直接向量化的高质量语料列表
    """
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=500,
        chunk_overlap=50,
        separators=["\n\n", "\n", "。", "，", ""]
    )

    documents = []
    seen_hashes = set()

    for text, meta in zip(raw_texts, source_meta):
        # 去重：基于文本哈希跳过重复内容
        text_hash = hashlib.md5(text.encode()).hexdigest()
        if text_hash in seen_hashes:
            continue
        seen_hashes.add(text_hash)

        # 清洗：去除连续空白和无效字符
        cleaned = " ".join(text.split())
        if len(cleaned) < 20:
            continue

        chunks = splitter.split_text(cleaned)
        for chunk in chunks:
            doc = Document(
                page_content=chunk,
                metadata={
                    **meta,
                    "source_hash": text_hash,
                    "chunk_length": len(chunk)
                }
            )
            documents.append(doc)

    return documents

代码解释

这段关键代码的实现原理，其实就是把爬虫里那套数据处理逻辑平移过来。下面逐段拆解。

输入部分：函数接收两个列表——raw_texts 是原始文本，source_meta 是对应的元数据字典。这两个列表必须一一对应，长度相同，否则 zip 会 silently truncate，这是第一个坑。

去重逻辑：用 MD5 哈希对每条文本生成指纹，存进 seen_hashes 集合。如果哈希已存在，直接跳过。这个思路和爬虫里的 URL 去重、内容指纹完全一致，只是把 URL 换成了文本。注意这里用的是原始文本的哈希，不是清洗后的，目的是在清洗前就过滤掉重复源。

清洗逻辑：" ".join(text.split()) 这行看起来简单，实际上干了两件事——把连续空白（包括换行、制表符、多个空格）压缩成单个空格，同时去除首尾空白。然后检查清洗后的长度，低于 20 个字符的直接丢弃。这个阈值可以根据语料质量调整，电商售后文档里有些标题或标签可能很短，但不影响主体内容。

分段逻辑：RecursiveCharacterTextSplitter 是 LangChain 提供的递归字符分割器。它的核心参数是 chunk_size=500（每个 chunk 最多 500 字符）和 chunk_overlap=50（相邻 chunk 重叠 50 字符，避免关键信息被切掉）。separators 列表定义了分割优先级：先按双换行（段落）切，再按单换行切，然后按句号、逗号切，最后按字符切。这个顺序很重要，优先级高的分隔符先尝试，只有当切分结果仍然超过 chunk_size 时才降级到下一个分隔符。

输出部分：每个 chunk 被包装成 Document 对象，包含 page_content（文本内容）和 metadata（元数据）。元数据里除了原始的 source_meta，还追加了 source_hash（用于追溯去重）和 chunk_length（用于后续质量监控）。最终返回的是 List[Document]，可以直接喂给向量库。

异常处理：这段代码没有显式的 try-except，但通过隐式过滤实现了容错——过短的文本被跳过，重复的文本被跳过。如果需要更严格的异常处理，可以在循环外层加 try-except，捕获单条文本的处理异常，记录日志后继续处理下一条，避免整批任务失败。

排查过程

项目上线后，客服反馈有几个回答明显不对。排查链路是这样的。

现象：用户问"退货后运费谁承担"，模型回答"由商家承担"，但实际政策是"非质量问题由买家承担"。

验证动作：
1. 检查向量库中是否存在相关政策文档——存在，且内容正确
2. 检查检索召回结果——前 5 条结果里没有这条政策文档
3. 检查元数据——该文档的时效性标签是"长期有效"，来源类型是"政策"，权重应该是高的
4. 检查向量相似度——召回的那 5 条都是 FAQ 类型的旧回答，相似度得分反而更高

排除结果：问题出在向量相似度计算上。FAQ 类型的回答因为语言更口语化，和用户的提问方式更接近，导致相似度得分反而高于政策原文。这是典型的语料风格偏差问题。

修复：在检索时加入元数据加权，政策类文档的得分乘以 1.5 系数。修复后，同一问题的召回命中率从 35% 提升到 82%。

这个排查过程说明了一个问题：RAG 项目的调试不是黑盒，你可以通过日志和检索结果反推问题出在哪一层——是检索问题、是语料问题、还是模型问题。爬虫工程师在调试爬虫时的排错思路，在这里完全复用。

失败原因

从爬虫转大模型，最常见的失败原因有三类，区分方法如下。

业务错误：模型回答内容本身有误。排查方式是回到语料库，检查对应知识条目是否存在、是否正确。这类问题 80% 出在数据质量上。

配置错误：检索参数、向量维度、分段策略设置不当。排查方式是对比不同参数组合下的召回率和准确率，找到最优配置。这类问题需要跑 A/B 测试，不能靠猜。

环境错误：向量库连接超时、模型 API 限流、权限校验失败。排查方式是检查日志和监控，这类问题和爬虫项目的网络异常排查思路一致。

区分这三类错误的关键是先定位问题层级。如果你不确定是业务错误还是配置错误，先检查语料库——如果语料库里没有正确答案，那就是业务错误；如果有，那就是检索或配置问题。

适用边界

爬虫经验在大模型项目里的适用边界很明确。

适合的场景：RAG 知识库构建、语料生产、数据清洗、向量检索优化、内部工具类 Agent。这些场景需要的是对数据源的理解、对数据质量的把控、对工程化细节的敏感——这些都是爬虫工程师的强项。

不适合的场景：模型训练、Prompt 工程、Agent 编排的核心逻辑设计。这些需要的是对模型能力的理解和对业务场景的深度把握，爬虫经验帮不上太大忙。

取舍建议：转型时不要试图把所有爬虫技能都带上。简历上突出三个证据：数据规模（你处理过多少条数据）、质量指标（你如何保证数据质量）、业务结果（你的数据对最终效果有什么影响）。这三个证据比"精通 Scrapy"有力得多。

还有一个重要的取舍：不要只写 Demo。团队现在招大模型工程师，看的不是你能不能跑通一个 RAG 示例，而是你能不能在权限、日志、可观测性这些工程细节上给出证据。你的简历应该让人一眼看出：这个人不仅能把模型跑起来，还能让它在生产环境里稳定运行。

总结

爬虫转大模型，最值钱的不是你会写 Scrapy，而是你在数据采集过程中积累的判断力、质量意识和工程习惯。这些能力在 RAG 项目里直接复用，而且比 Demo 级别的模型调用更有竞争力。

简历上写清楚三件事：你处理过多少数据、你如何保证质量、你的数据带来了什么业务结果。这三件事说清楚了，面试官就不会只把你当成一个"会抓网页的"。

资料展示

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

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