1. 项目背景：工业供应商数据采集的痛点
在工业自动化领域，供应商数据的采集与分析一直是企业供应链管理的重要环节。作为在天津滨海新区负责千万级工业自动化供应商数据采集的项目负责人，我遇到了一个比反爬虫机制更棘手的问题——非结构化数据的结构化提取。
传统爬虫技术在处理这类数据时存在明显局限：每个供应商的产品页面结构各异，有的使用表格展示技术参数，有的采用纯文本描述，还有的混合了图片和文字说明。这种差异性使得传统的XPath/CSS选择器完全无法通用化应用。每当新增一个供应商，我们的工程师就需要花费1-2天时间人工分析页面结构、编写新的选择器并进行测试调试。按这个速度，完成1000个供应商的数据采集需要近3年时间，项目进度完全失控。
更糟糕的是维护成本。即使成功编写了选择器，一旦供应商更新页面结构，原有选择器就会失效，需要重新分析和修改。我们不得不专门安排一名工程师，其70%的工作时间都消耗在选择器的维护上。这种情况严重影响了数据采集的效率和可靠性，传统方法的提取准确率仅能达到60%左右。
2. 技术方案选型：LLM的突破性应用
面对这些挑战，我们开始探索大语言模型（LLM）在非结构化数据结构化提取中的应用。与传统方法相比，LLM方案具有三大显著优势：
首先，它完全不依赖页面结构。我们只需将清洗后的非结构化文本输入LLM，就能直接输出标准的JSON格式数据。这意味着新增供应商时，通常只需要微调Prompt（如果需要的话），整个过程仅需10分钟左右，效率提升了36倍。
其次，数据提取准确率从传统方法的60%跃升至95%以上。LLM能够理解文本的语义内容，而非依赖固定的结构模式，这大大提高了数据提取的可靠性。
最后，维护成本降低了90%。工程师不再需要花费大量时间维护选择器，可以专注于数据清洗和业务逻辑开发，显著提升了团队的整体生产力。
3. 核心挑战与技术实现
3.1 非结构化数据的本质特征
在爬虫场景中，非结构化数据指的是那些没有固定结构、无法用传统XPath/CSS选择器或正则表达式直接提取的数据。工业领域的非结构化数据主要表现为：
- 产品描述：不同供应商使用完全不同的格式和术语
- 技术参数：有的用表格，有的用段落文字，有的甚至嵌入在图片中
- 联系方式：分散在页面的不同位置，格式各异
- 认证信息：表述方式千差万别
这类数据的核心特点是语义一致但表现形式多样。例如，一个产品的"工作温度范围"，可能被表述为"Operating Temp: -20℃~60℃"、"工作环境：-20至60摄氏度"或"使用温度范围：零下20度到正60度"等多种形式。
3.2 LLM解决方案架构
我们的技术架构包含以下几个关键组件：
- 数据采集层：使用Scrapy框架进行网页抓取，获取原始HTML
- 预处理层：通过Boilerpipe或Readability-lxml提取正文内容，去除广告、导航等噪音
- LLM处理层：将清洗后的文本输入LLM（我们主要使用GPT-3.5/4），通过精心设计的Prompt进行结构化提取
- 后处理层：对LLM输出进行校验和标准化
- 存储层：将结构化数据存入MongoDB或PostgreSQL
python复制# 示例代码：LLM数据处理流程
import openai
from bs4 import BeautifulSoup
def extract_structured_data(html_content):
# 预处理：提取正文文本
soup = BeautifulSoup(html_content, 'html.parser')
main_content = soup.find('div', class_='product-detail').get_text()
# 构造Prompt
prompt = f"""
请从以下工业产品描述中提取结构化信息：
{main_content}
需要提取的字段包括：
- 产品名称
- 技术参数（JSON格式）
- 供应商联系方式
- 认证信息
- 价格范围
请以JSON格式返回结果。
"""
# 调用LLM API
response = openai.ChatCompletion.create(
model="gpt-3.5-turbo",
messages=[{"role": "user", "content": prompt}]
)
return response.choices[0].message.content
3.3 Prompt工程实践
Prompt设计是LLM应用成功的关键。经过大量实验，我们总结出以下最佳实践：
- 明确指令：清晰说明需要提取哪些字段，以什么格式返回
- 提供示例：在Prompt中包含1-2个示例，展示理想的输出格式
- 字段描述：对每个需要提取的字段给出详细说明，特别是专业术语
- 格式约束：严格要求返回格式（如JSON），并指定字段名称
- 容错处理：指示LLM对无法确定的信息返回null而非猜测
提示：对于工业领域专业术语，建议在Prompt中提供术语表，确保LLM正确理解技术参数的含义。
4. 性能优化与实战技巧
4.1 准确率提升策略
我们从60%到95%的准确率提升并非一蹴而就，而是通过以下策略逐步实现的：
- 数据清洗预处理：去除HTML标签、统一编码格式、纠正明显错别字
- 分段处理：对长文本进行合理分段，避免超出LLM上下文限制
- 多轮验证：设计验证Prompt检查前一轮提取结果的合理性
- 领域适应：使用工业领域文本对基础模型进行微调
- 结果校验：建立规则引擎检查LLM输出的合理性（如温度范围不能是字符串）
4.2 处理效率优化
千万级数据规模下，处理效率至关重要。我们采用的优化措施包括：
- 批量处理：将多个供应商数据打包成一个请求，减少API调用次数
- 缓存机制：对相似页面结构使用缓存结果，避免重复处理
- 异步处理：使用Celery或Ray实现分布式处理
- 模型选择：在准确率和延迟之间权衡，对简单任务使用较小模型
python复制# 示例代码：批量处理优化
import asyncio
from aiohttp import ClientSession
async def batch_process(urls):
async with ClientSession() as session:
tasks = []
for url in urls:
task = asyncio.create_task(fetch_and_process(session, url))
tasks.append(task)
return await asyncio.gather(*tasks)
async def fetch_and_process(session, url):
async with session.get(url) as response:
html = await response.text()
return extract_structured_data(html)
4.3 成本控制方案
LLM API调用成本是另一个需要考虑的因素。我们的成本控制策略包括：
- 文本精简：去除无关内容，减少输入token数量
- 结果压缩：设计简洁的返回格式，减少输出token
- 本地小模型：对简单任务使用本地部署的较小模型（如LLaMA）
- 混合策略：先用规则引擎处理简单情况，复杂情况才调用LLM
5. 常见问题与解决方案
5.1 数据提取不完整
问题现象：LLM遗漏了部分字段或信息
解决方案：
- 检查Prompt是否明确列出了所有需要提取的字段
- 在Prompt中强调"请提取所有相关信息，不要遗漏任何细节"
- 对重要字段单独设置提取指令
5.2 格式不一致
问题现象：相同字段在不同供应商数据中格式不同
解决方案：
- 在后处理层添加标准化逻辑
- 在Prompt中明确指定输出格式（如"温度范围统一使用'℃'单位"）
- 使用正则表达式进行后处理
5.3 处理长文本效率低
问题现象：大篇幅文本处理速度慢且成本高
解决方案：
- 将长文本分成逻辑段落分别处理
- 先提取摘要再处理细节
- 使用Map-Reduce策略：先整体分析，再局部细化
6. 合规性与最佳实践
在工业数据采集过程中，合规性至关重要。我们建立了以下保障措施：
- robots.txt遵守：严格遵循目标网站的爬取政策
- 请求频率控制：设置合理的请求间隔，避免对目标网站造成负担
- 数据使用限制：仅采集业务必需的数据，不获取个人隐私信息
- 版权尊重：对受版权保护的内容谨慎处理
注意：不同国家和地区对数据采集的法律规定不同，建议在项目开始前进行合规性评估。
在实际项目中，我们从传统方法切换到LLM方案后，不仅解决了非结构化数据提取的难题，还带来了以下额外收益：
- 团队可以快速响应业务需求，新供应商接入时间从几天缩短到几小时
- 数据质量显著提升，下游分析系统的工作效率提高40%
- 工程师从繁琐的选择器维护中解放出来，专注于更有价值的业务创新
这个案例证明，在合适的场景下，LLM能够为传统爬虫技术带来革命性的改进。当然，LLM不是万能的，它最适合处理那些语义明确但表现形式多样的非结构化数据。对于高度结构化或对实时性要求极高的场景，传统方法可能仍然更合适。