爬虫转大模型：从上线前检查开始讲

2026/7/17 0:30:37

聊《大模型岗位变了，爬虫工程师该补的还是算法吗？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

前阵子面试了几个从爬虫转大模型方向的候选人，还有一个是做了三年 RPA 自动化的同行。大家都有一个共同的困惑：明明数据抓取和清洗玩得挺溜，怎么一进到大模型应用开发，特别是涉及到 Agent 和 RAG（检索增强生成）的时候，就感觉“水土不服”？

最近行业里有个挺明显的趋势，很多团队开始从 Demo 阶段向生产环境迁移。这时候业务方提的需求不再是“怎么让模型回答更准”，而是“怎么保证这个 Agent 不会乱查数据库”、“怎么记录它每一步的思考路径以便追溯”。说实话，这恰恰是传统爬虫工程师最容易忽视，或者说觉得“这不是我活”的灰色地带。

今天我不讲那些虚头巴脑的算法原理，就结合我最近重构的一个内部知识库项目，聊聊爬虫技能如何转化为真正的 AI 工程竞争力，以及为什么“权限隔离”和“可观测性”才是你现在该补的课。

爬虫技能的价值：不仅仅是“爬”

很多人认为爬虫转大模型，只需要学会写 Prompt 或者调一下 LangChain 就行。这是最大的误区。

爬虫工程师的核心能力其实是非结构化数据的结构化提取和边缘情况处理。在构建 RAG（检索增强生成）系统时，我们面临的最大痛点不是模型不够聪明，而是喂给模型的数据太脏、太碎。

记得我做那个内部合规文档检索项目时，最初的想法很简单：爬取所有 PDF 和 HTML，切分成 chunk，存入向量数据库。结果上线第一天，用户反馈：“为什么问‘报销政策’，它给我弹出了三年前的旧版文档？”

这就是爬虫老手的直觉发挥作用的时候了。传统的 ETL 思维告诉我们，数据是有时效性和上下文的。于是我没有直接扔给模型，而是加了一层预处理管道：

1. 元数据提取：不只是提取文本，还保留了文档的发布日期、版本号和审批人字段。
2. 语义去重：利用爬虫中的指纹技术变种，识别内容高度相似的章节，避免向量库中出现冗余噪声。
3. 层级保留：HTML 的结构标签（h1, h2）对应知识的层级关系，这在后续的重排序（Rerank）步骤中至关重要。

所以，你的核心竞争力不在于你会写 Selenium 还是 Scrapy，而在于你懂数据是怎么来的，又该怎么被清洗。

数据清洗与知识库构建：从“抓下来”到“喂得进”

在爬虫时代，我们关心的是反爬策略；在大模型时代，我们关心的是 Token 成本和上下文窗口。

很多初学者把网页直接丢进 Embedding 模型，结果发现准确率惨不忍睹。这是因为网页里充满了导航栏、广告、脚注这些“噪声”。我在项目中尝试了一种基于规则加 LLM 辅助的清洗策略：

import re from langchain.text_splitter import RecursiveCharacterTextSplitter def clean_html_content(raw_html: str) -> str: # 简单的正则去除脚本和样式，实际生产中建议用 BeautifulSoup 或 Trafilatura cleaned = re.sub(r'<script[^>]*>.*?</script>', '', raw_html, flags=re.DOTALL) cleaned = re.sub(r'<style[^>]*>.*?</style>', '', cleaned, flags=re.DOTALL) cleaned = re.sub(r'<[^>]+>', ' ', cleaned) # 规范化空白字符 cleaned = re.sub(r'\s+', ' ', cleaned).strip() return cleaned # 针对大模型的切分策略，注意保留段落完整性 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, length_function=len, separators=["\n\n", "\n", ". ", " ", ""] ) docs = ["你的原始文本...", "这里是另一段..."] split_docs = text_splitter.create_documents(docs)

这里的关键取舍是：Chunk Size 不是越大越好。过大的 Chunk 会稀释关键信息，过小则丢失上下文。我在调试中发现，对于技术文档，保持“段落+子标题”的完整切分，召回率比单纯按字数切分提高了近 15%。这就是爬虫工程师对文本结构敏感的优势所在。

RAG 语料生产：合规边界才是生死线

这是我想重点强调的部分。以前做爬虫，我们头疼的是 IP 被封、验证码拦路；现在做 AI 数据工程，我们头疼的是数据合规和权限控制。

业务方提了一个很尖锐的需求：“这个 AI 助手能不能让实习生看到财务部的机密文件？”

如果你只懂爬虫，你可能会说：“我把所有文件爬下来存一起，向量数据库不分权限。” 结果就是严重的合规事故。但在大模型应用架构中，必须引入访问控制列表（ACL）。

我的做法是将权限信息作为 Metadata 的一部分嵌入到向量存储中。当用户发起查询时，不仅进行向量相似度搜索，还要并行进行权限过滤。

# 伪代码示例：在检索阶段注入权限过滤 def rag_query_with_acl(user_permissions, query_embedding): # 1. 向量检索获取候选集 candidates = vector_db.similarity_search(query_embedding, k=10) # 2. 硬过滤：移除用户无权访问的文档 filtered_candidates = [ doc for doc in candidates if check_permission(doc.metadata['access_level'], user_permissions) ] # 3. 软过滤：基于权限内的相关性重排序 # 只有拥有高权限的用户才能看到深层推理链 if user_permissions.get('role') == 'admin': reranker_input = filtered_candidates else: reranker_input = filtered_candidates[:5] # 普通用户只展示最相关的5条 return generate_response(reranker_input)

这一步，其实就是把爬虫时代的“robots.txt”思维升级为“RBAC（基于角色的访问控制）”思维。爬虫讲究“能爬多少”，AI 工程讲究“能看多少”。

权限、日志与可观测性：从 Demo 到生产的最后一公里

最近热点都在谈 Agent 的工程化。很多团队 Demo 做得花里胡哨，一上线就崩。原因往往不是模型不行，而是缺乏可观测性。

在爬虫项目中，我们有详细的请求日志、响应状态码、重试机制。但在 LLM 应用中，由于模型的随机性和复杂性，Debug 变得极其困难。

我建议在架构初期就引入全链路日志：
1. Trace ID：每个用户请求生成唯一 ID，贯穿 Prompt 发送、Token 消耗、向量检索、结果组装全过程。
2. 中间状态快照：记录每一次 Re-ranking 前后的文档变化，以及 System Prompt 的实际生效版本。
3. 成本监控：实时统计每个对话的 Token 使用量，防止无限循环导致的费用爆炸。

没有这些，你就只是在“祈祷”模型不出错。有了这些，你才能在问题发生后的几毫秒内定位是检索错了，还是 Prompt 引导偏了。