上个月接了个工业供应商比价的采集项目一开始按传统思路做五个行业采购平台光CSS选择器就写了三百多行又是调XPath又是处理动态渲染联调了一周刚上线没两天其中一个平台做了前端架构升级类名全换成了随机哈希串DOM嵌套结构也改了采集程序直接报空又加班改了三天才稳住。当时就觉得不能再这么下去了索性把解析层全部重构换成大模型驱动的语义提取。网络请求、代理调度这些底层还是用原来的框架但解析部分一行选择器都没写全用自然语言描述要提取的字段和规则。结果五个平台只用了一天就全部对接完成上个月那个平台又改版了一次我们只在prompt里补了半句规则说明十分钟就修复上线全程没碰解析代码。这段时间深度用下来最大的感受就是大模型不是给采集工具加了个新功能而是彻底重构了整个技术范式。原来的核心是「匹配DOM结构」现在的核心是「理解文本语义」。过去工程师的大部分精力都花在和前端改版、反爬策略斗智斗勇现在只需要说清楚你要什么数据剩下的交给大模型做语义识别。一、传统采集的死局越维护成本越高做过采集的人都懂这套范式的痛点是骨子里的不是优化选择器就能解决的。1. 选择器维护地狱这是最无解的问题。只要网站前端改版哪怕只是换个UI框架、改个类名生成规则CSS选择器和XPath就会批量失效。尤其是互联网公司的运营页、电商页一两个月迭代一次是常态。很多项目维护成本比开发成本还高改bug的时间比写新功能还多。2. 非结构化数据无解商品详情、技术参数、用户评论、资讯正文这些内容没有固定的DOM结构格式千变万化。写正则吧变个格式就匹配不上穷举情况吧永远有新的格式冒出来。最后往往是写了几百行规则覆盖率还是上不去总有漏网之鱼。3. 跨站点复用为零同是电商平台淘宝和京东的结构天差地别同是采购网站每个供应商的页面逻辑都不一样。传统方案每接一个新站点就要重新写一套解析规则几乎没有复用性。站点越多工作量越大边际成本根本降不下来。二、核心架构三层结构彻底告别选择器很多人对大模型采集的理解就是“把HTML丢给大模型返回JSON”这么做的结果就是成本高、噪声大、准确率低。真正落地的方案一定是「预处理降噪 语义提取 结构化校验」的三层架构每一层都有明确的分工。1. 预处理层砍掉80%无效token这是整个方案里性价比最高的一步也是最容易被忽略的一步。原生HTML里script脚本、style样式、导航栏、侧边广告、相关推荐、页脚版权这些和目标数据无关的内容通常占了页面90%以上的token量。直接丢给大模型不仅贵还会干扰提取结果。预处理的核心就是「降噪」先通过正文提取算法定位目标区域再剥离所有冗余属性class、style、onclick等只保留标签语义和核心内容文本、链接、图片地址。处理完之后token量通常能压缩到原来的10%-20%成本直接砍到十分之一同时因为排除了无关内容提取准确率反而会提升。2. 语义提取层用自然语言定义规则这是和传统方案最本质的区别不用写选择器而是用「Schema定义 自然语言规则」的方式描述需求。一般配合大模型的结构化输出或者函数调用能力先定义好输出的JSON结构和字段类型再用自然语言补充每个字段的提取规则。举个商品采集的实际例子核心prompt大概是这样你是一个数据提取助手从下面的HTML页面中提取所有商品信息严格输出JSON数组不要任何解释文字。 每个商品对象包含以下字段 - name: 字符串完整的商品标题不要省略 - price: 数字类型当前售价单位为元只保留数字去掉货币符号和千分位 - sales: 数字类型月销量格式如1.2万转换为12000900转换为900 - link: 字符串商品详情页的完整绝对URL 输出示例 [{name:XXX,price:99.9,sales:1200,link:[https://xxx.com/xxx](https://xxx.com/xxx)}] 页面HTML内容 --- {preprocessed_html} ---就是这么简单没有任何选择器没有任何正则把需求说清楚大模型直接返回结构化数据。3. 校验层守住数据可用性的底线大模型不是100%准确的偶尔会出现格式错误、字段缺失、内容偏差。所以校验层是必不可少的否则输出的数据没法直接用。我们一般做三层校验格式校验检查是不是合法JSON必填字段有没有缺失类型是不是正确。有问题自动重试一次还不行就标记异常逻辑校验比如价格是不是正数、链接是不是合法URL、数值是不是在合理区间过滤明显错误的数据一致性校验对关键数据做交叉验证比如和历史数据对比偏差太大就人工复核。经过校验之后输出的数据和传统采集的输出完全一致下游的数据库、数据分析系统一行都不用改。三、三个进阶玩法效率再提一个量级掌握了基础架构之后这几个进阶玩法能把大模型的优势发挥到极致。1. 一套规则适配多个站点同行业的网站字段定义都是类似的但DOM结构千差万别。传统方案每个站写一套选择器大模型方案同一套prompt就能通用。比如我们做的供应商比价项目五个不同的采购平台基础提取规则完全一样只需要针对每个平台微调一两句字段描述准确率都能稳定在90%以上。适配新站点的时间从原来的2-3天直接缩短到2-4小时效率提升一个数量级。2. 天然免疫DOM层反爬现在很多网站的前端反爬手段是类名混淆、标签嵌套、插入干扰元素。传统选择器碰到这种直接抓瞎要花大量时间逆向分析。但对语义提取来说这些手段完全失效。只要文本内容和链接在页面里不管标签怎么乱套、类名怎么随机大模型都能通过语义识别出目标内容。当然IP限制、验证码、行为校验这些服务端反爬还是要单独处理但前端DOM层面的对抗成本直接降为零。3. 智能链路采集不用写下一页的选择器直接告诉大模型“找到页面中‘下一页’对应的链接返回完整URL”它就能从各种按钮、文字、图标里准确识别出来。哪怕翻页按钮改了位置、换了样式只要语义是下一页就不会错。甚至可以做更深的自动遍历告诉大模型“提取页面中所有详情页的链接”不用写任何匹配规则自动完成列表到详情的链路采集。四、成本与精度最关心的两个问题算透聊到大模型大家第一反应都是“贵不贵准不准”我们算笔明白账。1. 成本比人工维护便宜太多很多人只看到token的钱却忽略了人力成本才是大头。先算直接成本预处理之后普通列表页大概500-1000 token详情页1000-2000 token。用国产主流模型每百万token大概5-15块钱。也就是说采集一万个页面成本大概在几十块钱。再算人力成本传统方案一个站点开发几千块改版一次维护又是几千块。站点多、迭代快的话一年的人力成本几万到几十万。对于中小规模、多站点、页面迭代快的采集项目大模型方案的综合成本只有传统方案的1/5甚至更低。2. 精度做好三点到90%不是随便丢段HTML进去就好用做好这三个优化准确率能提升一大截加示例在prompt里给1-2个正确的输出样例Few-shot准确率能直接提升10%以上这是成本最低的优化分块处理长页面不要一次性丢进去按内容区块拆分分别提取再合并避免大模型遗漏尾部内容定义明确每个字段的规则越具体越好比如“取红色标注的当前价格不要划线的原价”不要用模糊的表述。我们实测的不同场景准确率电商/采购商品列表92%-95%新闻资讯正文提取95%-98%工业产品参数详情88%-92%这个精度对于比价、舆情、数据分析这类业务场景完全够用。五、踩坑总结五个最容易犯的错误这段时间踩了不少坑总结几个最典型的大家少走弯路。1. 别直接丢全量HTML图省事直接把整个页面HTML传进去是新手最容易犯的错。不仅token成本高、速度慢还会把广告、推荐内容当成目标提取准确率很低。一定要先做预处理降噪。2. 别转成纯文本提取把HTML转成纯文本再提取会丢失链接、图片地址、表格结构这些关键信息。要用简化的HTML保留a、img、table等语义标签只去掉冗余属性兼顾信息量和token成本。3. 别让大模型做流程控制翻页、去重、请求调度、异常重试这些流程逻辑一定要用传统代码实现。大模型只负责内容提取各司其职既稳定又便宜。让大模型控制流程不仅贵还容易出逻辑错误。4. 别什么场景都硬上如果是表格、规整列表这种结构非常稳定的页面传统选择器的速度、精度、成本都更优。大模型适合结构复杂、多变、非结构化的场景不要为了用而用。5. 别踩合规红线这是底线。无论用什么技术采集都要遵守目标网站的robots协议不得爬取涉密数据、公民隐私数据严格遵守《数据安全法》《网络安全法》合法采集和使用公开网络数据。六、实测对比两种方案的完整数据我们在工业供应商比价项目中做了完整的对照测试五个采购平台每个平台采集1000条商品数据结果如下对比维度传统选择器方案大模型语义方案初始开发周期7天1.5天单次改版维护时间2-3天10-30分钟单新站点适配时间2-3天2-4小时数据准确率95%结构稳定时92%千页采集直接成本约2元服务器代理约5元代理tokenDOM层反爬适配成本高需逆向分析无天然免疫从数据能很直观地看出单看采集直接成本大模型略高一点但人力成本差了一个数量级页面迭代越频繁、站点数量越多大模型方案的优势越明显结构稳定的大批量采集传统方案依然有优势但多变场景下大模型的效率是碾压级的。最后说几句做了快六年的网络数据采集从正则表达式到CSS选择器从模拟浏览器到接口逆向技术工具一直在变但核心逻辑一直是「匹配结构」。大模型带来的不是某一个环节的优化而是底层范式的重构从「和DOM结构对抗」变成了「和语义内容对话」。未来的采集工程师核心竞争力不再是写选择器、写正则、逆向前端的能力而是设计高质量prompt、优化处理流程、平衡成本与精度的能力。技术永远在迭代拥抱变化才能不被淘汰。合规提醒网络数据采集需严格遵守相关法律法规及网站协议尊重数据版权与隐私保护合法合规开展技术实践。