从爬虫到 RAG：信息采集能力，是我转大模型最大的底牌

关注

原创最新推荐文章于 2026-11-12 17:29:12 发布 244 阅读 AI 写同款· GEO 优化 ›

Llama GEO三层穿透架构：训练数据、社区信源与RAG检索实战指南生成式引擎优化（GEO）是当前开源大模型落地的核心技术范式，本质是让品牌内容在Llama类模型中实现‘被看见、被记住、被调用’的确定性响应。其底层逻辑植根于Llama 4的MoE专家路由机制与冻结式训练数据策略，技术价值在于将内容可信度转化为模型内部权重，从而提升RAG召回准确率与推理一致性。典型应用场景包括制造业知识库私有化部署、出海SaaS产品技术文档曝光、政务AI平台语义索引增强等。本文聚焦GEO不可替代的三层穿透架构——训练数据层强调语义锚点与跨信源引用链构建，社区信源层依托GitHub Star与阅读详情

聊《我用爬虫经验做了次 AI 项目，最先失效的是旧方法》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

去年接了个内部项目，做个企业知识库问答。业务方说"你们爬虫团队不是能抓东西吗，帮我们把内部文档搞进去"。我当时觉得简单——爬虫采集、清洗、切块、向量化、接入 LLM，链条再熟悉不过了。

Demo 跑了一周，效果还不错。结果上线第一天就崩了。

后来复盘才发现，真正的门槛根本不是模型调用，而是权限、日志和可观测性。这些在爬虫时代从来不是问题，因为爬虫本身就是干"灰色"的——你不需要权限，不需要日志，只需要能抓。但做 AI 应用的时候，这三样东西直接决定了你能不能上线。

这篇文章我想把整个踩坑过程捋一遍，尤其是数据采集能力在大模型项目里到底能怎么用、怎么避免翻车。

---

爬虫技能的价值

文章插图 1

爬虫转大模型，最大的优势不是技术栈，而是数据敏感度。

我做爬虫出身，对数据的格式、质量、来源有天然的判断力。别人拿到一份 HTML，第一反应是"怎么用"，我的第一反应是"这数据干净吗，哪里有问题"。这种能力在 RAG 项目里非常值钱。

比如文档切块（chunking），大多数人直接按固定长度切。但爬虫经验告诉我，每个文档的结构不一样——PDF 可能有标题层级，HTML 可能有表格、脚注、水印。一刀切只会破坏语义完整性。

我的做法是在切块前先做结构分析：

import re
from bs4 import BeautifulSoup

def analyze_document_structure(html_content):
    """
    输入：原始 HTML 字符串
    核心逻辑：解析 DOM 树，识别标题层级、表格、代码块等结构化元素
    输出：结构化片段列表，每个片段包含类型和文本
    异常处理：解析失败时降级为纯文本切分
    """
    try:
        soup = BeautifulSoup(html_content, 'html.parser')
        chunks = []

        # 识别标题层级，作为语义边界
        headings = soup.find_all(['h1', 'h2', 'h3', 'h4'])
        for i, heading in enumerate(headings):
            start = heading.start_index if hasattr(heading, 'start_index') else 0
            end = headings[i+1].start_index if i+1 < len(headings) else len(soup.get_text())
            chunks.append({
                'type': 'section',
                'level': int(heading.name[1]),
                'text': heading.get_text().strip(),
                'boundary': True
            })

        # 识别表格，避免跨表切块
        tables = soup.find_all('table')
        for table in tables:
            chunks.append({
                'type': 'table',
                'text': table.get_text(separator='\n').strip(),
                'boundary': True
            })

        return chunks
    except Exception as e:
        # 降级处理：遇到解析异常，返回原始文本
        return [{'type': 'raw', 'text': soup.get_text(), 'boundary': False}]

这段代码的核心逻辑是先用结构分析确定语义边界，再在边界内切块。很多教程只教你用 langchain.text_splitter 按字符数切，但实际项目里这种切法会产生大量碎片化、丢失上下文的 chunk。

爬虫转大模型的第一步，就是把对数据结构的敏感度用起来。

---

数据清洗：从脏数据到干净语料

文章插图 2

爬虫采集的数据，99% 是脏的。网页上有导航栏、广告、脚注、重复内容。这些在搜索场景下可以容忍，但在 RAG 场景下会直接污染检索结果。

我之前踩过一个坑：爬取的 PDF 文档里有大量页眉页脚的水印文字，比如"内部资料请勿外传"、"版本号 v2.3"。这些内容被向量化后，会在检索时频繁命中，但和实际问题毫无关联。

清洗的关键是先识别噪声模式，再做规则过滤：

import re

NOISE_PATTERNS = [
    r'内部资料.*?请勿外传',  # 水印
    r'第\s*\d+\s*页\s*共\s*\d+\s*页',  # 页码
    r'版本号\s*v?[\d.]+',  # 版本号
    r'copyright\s*[\d\s\-]+',  # 版权信息
    r'未经.*?许可.*?禁止转载',  # 声明文字
]

def clean_document(text: str) -> str:
    """
    输入：待清洗的文档文本
    核心逻辑：按预定义模式匹配并移除噪声，保留有效内容
    输出：清洗后的干净文本
    异常处理：模式匹配失败时跳过该条规则
    """
    cleaned = text
    for pattern in NOISE_PATTERNS:
        try:
            cleaned = re.sub(pattern, '', cleaned, flags=re.IGNORECASE)
        except re.error:
            continue  # 正则表达式无效时跳过

    # 合并多余空白
    cleaned = re.sub(r'\s+', ' ', cleaned).strip()
    return cleaned

这段代码的逻辑很直接，但噪声模式的挖掘本身才是最耗时的。我花了一个星期整理公司内部各类文档的噪声特征，才发现原来不同部门的文档格式差异这么大——技术部的 PDF 有水印，产品部的 Markdown 有模板代码块，法务部的合同有签名区块。

爬虫经验在这里的价值是快速识别和归纳数据噪声模式，这是很多转大模型的开发者欠缺的。

---

知识库构建：向量化的坑

切块清洗之后，下一步是向量化。这一步看起来简单，但其实藏着几个常见的坑。

坑一：Embedding 模型选型

很多人直接用 OpenAI 的 text-embedding-3-small，但国内项目往往需要考虑私有化部署和成本。我用过 BGE-M3 和 text2vec-base-chinese，前者在多语言和多粒度上表现更好，后者在纯中文场景下更轻量。

选型的标准不是跑分，而是在你的语料上实测召回率。我当时的做法是：

1. 抽取 200 条历史 FAQ 作为查询样本
2. 用不同 Embedding 模型向量化
3. 计算每条查询的 Top-3 召回是否覆盖正确答案
4. 对比准确率

坑二：向量库的选择

FAISS、Chroma、Milvus、PGVector，选择很多。爬虫转大模型的人容易犯的错误是只看 Demo 体验，不看生产约束。

FAISS 适合单机小数据量，但无法水平扩展；Chroma 开发体验好，但生产环境不稳定；Milvus 功能全，但运维成本高。我当时选择了 PGVector，因为团队已经有 PostgreSQL 基础设施，运维成本最低。

坑三：元数据管理

向量本身是数字，但你需要知道这个向量对应的是哪份文档、哪个章节、什么时间更新的。我在向量入库时强制要求携带以下元数据：

{
    "doc_id": "policy_2024_v3",
    "chunk_index": 12,
    "source_url": "internal://wiki/policy/2024/v3",
    "updated_at": "2024-03-15",
    "author": "hr_department",
    "department": "人事"
}

这些元数据在后续的可观测性建设里至关重要。没有它们，出问题时你根本不知道是哪个数据源出了问题。

---

RAG 语料生产：工程化是关键

Demo 阶段，语料生产往往很随意——爬下来、洗一洗、切一切、存进去，完事。但真正上线的时候，问题会集中爆发。

真实案例：上线第一天的崩溃

我负责的那个企业知识库项目，上线第一天出现了两个现象：

1. 大量请求返回"暂无相关信息"
2. 部分请求超时，响应时间超过 30 秒

按照排查流程，我先看了日志。发现第一个问题的根因是：权限变更。某部门文档的访问权限在上线前被收紧，爬虫采集的数据来源中断了，但知识库没有同步更新，导致检索时命中率骤降。

第二个问题的根因是：向量库连接池配置错误。Demo 阶段我们用的是默认配置，并发上来后连接池不够用，排队等待超时。

这两个问题都不是模型问题，而是工程和运维问题。爬虫出身的人往往不擅长这些，因为爬虫项目通常不需要考虑并发、连接池、权限管控。

排查过程

| 步骤 | 动作 | 结果 |
|------|------|------|
| 现象确认 | 检查监控面板，确认错误类型和分布 | 发现两类错误集中在不同用户群 |
| 日志分析 | 查看向量库查询日志和爬虫任务日志 | 发现爬虫任务在权限变更后失败率 80% |
| 验证假设 | 手动查询某段文档，确认权限问题 | 确认该文档已无法访问 |
| 修复验证 | 恢复连接池配置，增加重试机制 | 超时问题消除 |
| 最终确认 | 监控 24 小时，确认无新增问题 | 问题彻底解决 |

这个排查过程教会我：大模型项目的故障定位，大部分时间花在数据层和基础设施层，而不是模型层。

---

优快云资料领取方式

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

回到文章开头的差异化角度。最近圈内讨论很多"大模型应用从 Demo 转向权限、日志和可观测"，我觉得这个趋势非常准确。

爬虫时代，数据采集的边界是反爬虫策略——怎么绕过验证码、怎么代理轮换、怎么避免封 IP。这些是技术问题，但没有合规风险。

大模型时代，数据采集的边界变成了权限和授权——你有权利访问这份文档吗？这份内容能进入模型训练吗？用户的查询记录能保存多久？这些是合规问题，处理不好会有法律风险。

我在项目里做了三件事：

1. 权限校验前置

在爬虫采集阶段就接入权限检查，而不是等到检索阶段。每个文档入库前标记其访问级别，检索时根据用户权限过滤。

def filter_by_permission(chunks: list, user_role: str) -> list:
    """
    输入：候选 chunk 列表、用户角色
    核心逻辑：根据预设的权限映射表过滤 chunk
    输出：用户有权访问的 chunk 子集
    异常处理：权限映射缺失时默认拒绝访问
    """
    permission_map = {
        "public": ["public", "internal", "confidential"],
        "internal": ["internal", "confidential"],
        "confidential": ["confidential"]
    }

    allowed_levels = permission_map.get(user_role, ["public"])
    return [c for c in chunks if c.get('access_level') in allowed_levels]