当前位置：首页 > news >正文

别再迷信 Prompt 工程了，爬虫工程师的合规红线才是 RAG 系统的生死线

news 2026/7/13 20:46:38

聊《爬虫转大模型实战，第一道门槛可能不是算法》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

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

摘要：
很多人认为从爬虫转做大模型应用（LLM App），核心难点是调参或写复杂的 Prompt。但我复盘了几个上线后崩盘的项目，发现真正的拦路虎是：数据进来的那一刻，权限校验缺失、日志不可追溯、以及合规边界模糊。本文不讲虚的，直接从数据采集的源头聊起，看看如何将“爬取能力”转化为“高质量语料生产”与“可观测性”的核心竞争力。

---

1. 爬虫技能的隐性价值：不只是抓取 HTML
2. 数据清洗：从“能爬下来”到“能喂给模型”
3. RAG 语料生产：颗粒度切分里的学问
4. 合规边界：大模型时代的“新爬虫协议”
5. 工程化视角：权限、日志与可观测性
6. 总结：你的新护城河在哪里？

---

爬虫技能的隐性价值 <a name="爬虫技能的隐性价值"></a>

在做爬虫的时候，我们习惯关注成功率、并发数和反爬策略。但在大模型应用的语境下，这些能力的本质发生了位移。

以前，你的目标是把网页变成字符串存进 MySQL；现在，你的目标是把非结构化数据变成向量数据库里的高密度 Token。

很多转行的大模型开发者容易犯一个错误：觉得爬虫技术过时了，直接上现成的开源抓取框架或者甚至依赖 LLM 自身去联网搜索。这是一个巨大的误区。

真实的业务场景中，通用搜索引擎无法覆盖垂直领域的私有数据。比如企业内部的知识库、特定行业的最新研报、或者需要登录态才能访问的论坛数据。这时候，你熟悉的Session管理、动态渲染处理（Playwright/Selenium）、以及 IP 代理池调度，就不再是“爬虫技能”，而是“AI 数据的获取与预处理管道”。

我曾参与过一个医疗问诊辅助的项目，初期直接用开源文档构建知识库，结果检索准确率极低。后来我们发现，大量的有效信息藏在医院官网的公告栏和医生个人主页里，这些数据没有 RSS 订阅，也没有标准的 API。团队里懂爬虫的同学重新搭建了一套针对特定域名结构的提取器，不仅拿到了数据，还通过 HTML 结构分析了医生的职称权重。最终，基于这部分数据微调后的 RAG 系统，在专业术语识别上的 F1 值提升了 15%。

所以，不要轻视你的爬虫底子。在 AI 时代，它是你获取独家、高质量训练语料的唯一路径。

数据清洗：从“能爬下来”到“能喂给模型” <a name="数据清洗"></a>

爬取只是第一步，清洗才是决定模型表现的上限。

大模型对噪声极其敏感。一段包含大量广告、导航栏、JS 代码的 HTML，直接扔进 Embedding 模型，只会产生一堆垃圾向量。

实战中的取舍

在处理 HTML 转 Markdown 的过程中，我踩过一个坑：为了保留更多上下文，我没有严格过滤<script>和<style>标签，导致向量库中混入了大量 CSS 类名和 JS 函数名。当用户提问时，模型经常会混淆“网页结构”和“实际内容”，回答变得不知所云。

正确的做法是建立严格的过滤规则：

1. 移除所有非文本节点：图片、视频、脚本、样式表。
2. 标准化分隔符：不同来源的数据格式各异，必须统一转换为 Markdown 格式，利用标题层级（# H1, ## H2）来保留逻辑结构。
3. 去除低质量片段：通过字符长度、特殊符号比例来判断是否为乱码或广告页。

这里分享一个我在项目中使用的 Python 清洗脚本片段，基于readability-lxml和自定义正则：

import re from readability import Document def clean_html_for_rag(html_content: str) -> str: """ 将 HTML 清洗为适合 RAG 嵌入的纯文本 Markdown """ doc = Document(html_content) # 提取主要内容，去除头部尾部冗余 title = doc.short_title() content = doc.summary() # 简单的清洗：移除多余空白和特殊字符 content = re.sub(r'\s+', ' ', content) content = re.sub(r'[^\x00-\x7F]+', '', content) # 移除非 ASCII 字符，视情况而定 # 转为 Markdown 格式以便模型理解层级 # 注意：这里需要根据实际 HTML 结构调整，通常 readability 已经处理得不错 final_text = f"# {title}\n\n{content}" return final_text.strip()

这段代码看似简单，但在生产环境中，你需要配合 HTML 解析树进行更精细的结构提取，比如提取表格、列表，甚至保留图片的 Alt 文本作为描述。

RAG 语料生产：颗粒度切分里的学问 <a name="rag-语料生产"></a>

清洗好的数据如何入库？这就涉及到 Chunking（切分）策略。

很多初学者喜欢固定字符数切分，比如每 500 个汉字切一块。这在处理小说或散文时没问题，但在处理技术文档、法律条文或代码片段时，会导致语义断裂。

我的建议是：基于语义边界的自适应切分。

1. 利用标题层级：以H2或H3作为自然分割点。
2. 重叠窗口（Overlap）：相邻 Chunk 之间保持 10%-20% 的重叠，防止关键信息被切掉。
3. 元数据增强：每个 Chunk 都要携带来源 URL、文章标题、发布日期、作者等元数据。这些信息在检索排序（Rerank）阶段至关重要。

例如，在一个金融资讯 RAG 系统中，我引入了基于段落长度的动态调整。如果一段话超过 300 字且没有子标题，我们会尝试根据句号进行二次切分，确保每个 Chunk 都是一个完整的语义单元。

合规边界：大模型时代的“新爬虫协议” <a name="合规边界"></a>

这是我最想强调的一点，也是区分“野路子”和“正规军”的关键。

在大模型时代，数据采集的合规风险比传统爬虫高出数个量级。

版权风险：直接爬取受版权保护的书籍、文章用于训练或 RAG，极易引发法律诉讼。你需要建立“白名单”机制，只处理公开授权或 CC 协议的数据。
隐私保护：爬取的用户评论、个人信息，必须在入库前进行脱敏处理（PII Masking）。使用正则或 NLP 模型识别手机号、身份证、姓名，并用占位符替换。
Robots.txt 的演变：虽然 Robots.txt 主要用于指导爬虫，但在 AI 语境下，它还可以作为“数据许可”的参考。尊重站点的排除指令，不仅是法律要求，更是企业级应用的基本素养。

我曾在一个项目中发现，团队成员为了提升召回率，绕过了某付费墙的限制抓取内容。结果上线后被法务叫停，整个知识库需要重新构建。这个教训告诉我们：合规不是限制，而是系统的生命线。

工程化视角：权限、日志与可观测性 <a name="工程化视角"></a>

最近业界有个趋势：大模型应用从 Demo 转向权限、日志和可观测性。这对于爬虫出身的开发者来说，其实是老生常谈，但我们往往忽略了它在 AI 场景下的新含义。

1. 权限校验（Authorization）

在 RAG 系统中，不同角色的用户应该看到不同的数据。

`python
# 伪代码：在检索时注入权限过滤
results = vectordb.similaritysearch(
query=user_query,
k=5,
filter={"department": user.department} # 关键！在向量层面过滤
)
`

场景：HR 员工只能查询公司的“员工手册”，而不能查询“薪酬体系”。
实现：你不能只在 UI 层做控制。必须在 Embedding 检索阶段，就将用户的角色标签（Role Tag）作为 Filter 传入向量数据库。
代码示例：

2. 日志与可观测性（Observability）

LLM 的输出具有随机性，调试难度极大。

Trace ID 贯穿始终：从用户输入、Token 计数、Embedding 向量的生成、向量检索结果、到 LLM 的最终输出，每一个环节都要打上 Trace ID。
成本监控：记录每次请求的 Token 消耗，分析哪些 Query 成本高但收益低，从而优化 Prompt 或调整检索策略。
失败重试机制：当网络波动导致爬取失败，或向量服务超时，需要有完善的降级策略，而不是直接报错给用户。