基于CrewAI与Ollama的自动化高质量数据集构建实战

1. 项目概述：从零到千条数据集的自动化构建之旅

最近在做一个需要大量高质量、结构化文本数据的实验项目，手头的数据要么质量参差不齐，要么格式不统一，清洗和标注的工作量巨大。我就在想，能不能让AI自己来生成一个符合我特定需求的、干净的数据集？这个想法催生了这次为期72小时、产出1065条高质量数据条目的自动化实验。整个系统的核心，是让两个开源的AI框架——CrewAI和Ollama——协同工作，模拟一个从“需求理解”到“数据生成”再到“质量校验”的完整数据生产线。

简单来说，CrewAI在这里扮演了“项目经理”和“质检员”的角色，它负责规划任务、协调不同的AI智能体（Agent）并确保最终输出的质量。而Ollama则是我本地运行的“专家工人”，它提供了强大的开源大语言模型（如Llama 3、Mistral等），负责执行具体的文本生成、格式转换和逻辑判断任务。整个流程完全自动化，无需人工干预，最终生成的数据集不仅数量可观，而且在一致性和准确性上远超手动收集或简单脚本爬取的结果。这套方法特别适合需要定制化数据的研究者、开发者，或者任何想快速构建高质量数据原型进行模型微调、算法测试的人。

2. 核心架构与工具选型解析

2.1 为什么是CrewAI + Ollama组合？

选择这个技术栈，是基于几个核心考量：成本可控、流程可定制、数据隐私安全。市面上当然有现成的数据生成API，但它们通常按调用次数收费，生成上千条高质量数据的成本不菲，且对于数据格式和内容的控制粒度不够细。而CrewAI和Ollama都是开源框架，部署在本地或自己的服务器上，除了电费和硬件成本，几乎没有额外支出。

CrewAI的本质是一个多智能体协作框架。你可以把它想象成一个虚拟的办公室，里面坐着不同职位的员工（智能体）。每个员工有明确的职责（角色）、擅长的技能（工具）和需要遵循的工作准则（目标）。CrewAI的“任务”（Task）系统就是工作清单，它定义了每个步骤要做什么、由谁来做、输出的标准是什么。而“流程”（Process）则规定了这些员工是依次工作（顺序执行）还是可以并行处理。在这个数据生成项目中，我设置了至少三个核心智能体：一个“需求分析师”负责解析我的初始指令并拆解成可执行的任务；一个“数据生成工程师”负责调用模型生产原始数据；一个“质量审核员”负责对生成的数据进行校验和过滤。

Ollama则是一个让我能在本地轻松运行和管理各种开源大语言模型的工具。它解决了模型下载、环境配置、服务部署等一系列麻烦事。我只需要一条简单的命令（如ollama run llama3:8b）就能启动一个模型服务，并通过标准的API接口进行调用。我选择在本地运行Ollama，最大的好处是数据完全不出本地，隐私和安全有绝对保障。同时，我可以根据生成任务的特点，灵活切换不同规模和能力的模型。比如，对于需要较强逻辑推理的审核任务，我可能会使用70B参数的大模型；而对于格式相对固定的数据填充任务，7B或8B参数的小模型就足以胜任，速度更快。

2.2 系统工作流设计

整个自动化数据生成器的核心工作流，是一个精心设计的闭环管道，如下图所示（概念图）：

[用户输入需求] ↓ [CrewAI 需求分析智能体] -> 解析需求，定义数据schema、生成规则、数量 ↓ [CrewAI 任务规划] -> 创建“生成”与“审核”任务链 ↓ |------------------| | | ↓ ↓ [生成任务] [审核任务](并行或顺序) (调用Ollama模型A) (调用Ollama模型B) | | |------------------| ↓ [数据聚合与格式统一] ↓ [结果输出：JSON/CSV文件] ↓ [日志与性能报告]

1. 初始化与需求注入：我向系统输入一个自然语言描述的需求，例如：“生成一个关于‘用户对智能家居设备抱怨’的数据集，每条数据需要包含用户ID（模拟）、设备类型、具体问题描述、情感极性（正面/负面/中性）和严重程度等级（1-5）。需要1000条，问题描述要多样且真实。”
2. 智能体协同解析：CrewAI的“需求分析师”智能体会首先解读这个指令。它会利用Ollama提供的模型能力，将模糊的需求转化为精确的、结构化的“数据生成规范书”。这份规范书会明确每个字段的定义、取值范围、生成逻辑（如用户ID的生成规则）、以及字段间的约束关系（如“负面”情感通常对应较高严重程度）。
3. 任务分解与执行：根据规范书，CrewAI创建两个核心任务：数据生成任务和质量审核任务。这两个任务可以被设置为顺序执行（先全部生成再审核）或穿插执行（生成一批，审核一批）。每个任务都绑定到特定的智能体，并指定使用哪个Ollama模型。
4. 数据生产与质检流水线：
   • 生成端：“数据生成工程师”智能体接收任务，它内部包含一个调用Ollama API的工具。它会构造详细的提示词（Prompt），引导模型严格按照规范书生成一条数据。提示词会包含示例（few-shot learning），以确保格式绝对正确。
   • 审核端：“质量审核员”智能体同样调用Ollama（可能是另一个更擅长推理的模型）。它的提示词要求模型扮演严格的质检员，检查生成的数据是否符合所有规范：字段是否齐全、格式是否正确、逻辑是否自洽（例如，一条描述“设备完全无法开机”的抱怨，其情感极性不应是“正面”）。审核不通过的数据会被丢弃或打回重生成。
5. 聚合与输出：通过审核的数据会被送入一个聚合模块，统一转换成指定的格式（如JSON Lines或CSV）。系统会持续运行，直到达到预设的数据条数（1065条）。整个过程的所有日志，包括生成耗时、审核通过率、模型响应内容等，都会被记录下来，用于后续分析和优化。

注意：在实际架构中，生成和审核任务之间最好有一个缓冲队列。不要让生成任务直接等待审核结果，而是生成后放入队列，审核任务从队列中取数据。这样可以实现松耦合，提高整体吞吐量，避免因为审核模型速度慢而拖累生成速度。

3. 实操搭建：环境配置与智能体定义

3.1 本地环境与Ollama部署

我的实验环境是一台配备RTX 4090显卡的工作站，拥有24GB显存，这让我可以流畅运行较大的模型。但即使没有高端显卡，Ollama也支持纯CPU运行，只是速度会慢一些。

第一步：安装Ollama访问Ollama官网，根据你的操作系统（Windows/macOS/Linux）下载安装包。安装过程非常简单，几乎是一键完成。安装后，打开终端（或命令行），你就可以通过ollama命令来操作了。

第二步：拉取并运行模型Ollama的核心模型库（Ollama Library）提供了众多精选模型。对于数据生成任务，我主要测试了以下几款：

• llama3:8b：Meta的最新款，在指令跟随和格式输出上表现均衡，速度较快，是生成任务的主力。
• mistral:7b：以高效率和不错的推理能力著称，在审核任务中有时比Llama 3更“严格”。
• qwen2:7b：在中文场景下表现优异，如果你的数据需求涉及中文，这是个好选择。

拉取模型的命令是ollama pull <模型名>，例如ollama pull llama3:8b。拉取完成后，使用ollama run llama3:8b就可以在交互式命令行中测试模型了。但对于我们的自动化系统，我们需要它以API服务器模式运行。

第三步：启动Ollama API服务Ollama默认会在http://localhost:11434提供兼容OpenAI API格式的接口。确保服务已启动。你可以通过访问http://localhost:11434/api/tags来查看已下载的模型列表，验证服务是否正常。

3.2 构建CrewAI智能体与任务

接下来是CrewAI的部分。我使用Python进行开发，首先安装CrewAI包：pip install crewai。

定义智能体（Agents）智能体是系统的“员工”。每个智能体需要定义角色、目标、背景描述以及它可以使用的工具。

from crewai import Agent, LLM from langchain_community.utilities import SerpAPIWrapper # 示例工具，本项目未使用 from langchain_community.tools import DuckDuckGoSearchRun # 示例工具，本项目未使用 # 首先，定义我们连接Ollama的LLM对象 # 注意：CrewAI目前可能更适配OpenAI格式，我们需要配置base_url指向本地Ollama ollama_llm = LLM( model="ollama/llama3:8b", # CrewAI的特定格式，表示使用Ollama base_url="http://localhost:11434", # Ollama API地址 api_key="ollama", # Ollama不需要真正的key，但有些框架要求非空，可随意填写 temperature=0.7, # 控制创造性，生成任务可稍高（如0.8），审核任务应较低（如0.1） ) # 1. 需求分析智能体 requirements_analyst = Agent( role="高级数据需求分析师", goal="准确理解用户模糊的自然语言需求，并将其转化为清晰、无歧义、可执行的结构化数据生成规范。", backstory="你是一位在数据科学领域有十年经验的专家，擅长与业务人员沟通，并能将业务语言翻译成技术语言。你以严谨和细致著称。", llm=ollama_llm, # 为该智能体指定使用的模型 verbose=True, # 输出详细思考过程，便于调试 ) # 2. 数据生成智能体 data_generator = Agent( role="高效数据生成工程师", goal="严格依据《数据生成规范》，快速、多样地生成符合格式和内容要求的高质量模拟数据条目。", backstory="你是一个不知疲倦的数据工厂核心引擎，你的代码（提示词）完美无缺，总能产出符合预期的结果。你痛恨格式错误和偏离要求的输出。", llm=ollama_llm, verbose=True, ) # 3. 质量审核智能体 quality_inspector = Agent( role="苛刻的数据质量审核员", goal="对每一条生成的数据进行多重校验，确保其100%符合规范，逻辑自洽，并过滤掉低质量、重复或荒谬的条目。", backstory="你曾因在金融数据审计中发现一个微小错误而避免了数百万损失。你对“差不多”零容忍，眼里容不下任何沙子。", llm=ollama_llm, # 可以为审核员指定一个不同的模型，例如 temperature=0.1 的 llama3:70b verbose=True, )

定义任务（Tasks）任务是智能体要执行的具体工作。任务需要描述、指派给哪个智能体、以及期望的输出是什么。

from crewai import Task # 任务1：需求分析 analysis_task = Task( description="分析用户需求：'{user_input}'。请输出一份详细的《数据生成规范》文档，必须包含：1. 数据集名称与描述；2. 每条数据的字段定义（名称、类型、示例、约束）；3. 数据生成的总条数；4. 对生成内容多样性、真实性的具体要求；5. 输出格式（JSON）。", agent=requirements_analyst, expected_output="一份结构清晰、技术团队可直接执行的Markdown格式规范文档。", ) # 任务2：数据生成 # 注意：在实际循环中，这个任务会被动态创建多次，或者在一个任务内处理批量生成。 generation_task = Task( description="根据附带的《数据生成规范》，生成 {batch_size} 条数据。你必须严格按照规范中的字段和格式要求输出，每条数据输出为一个独立的JSON对象。确保内容多样且真实。", agent=data_generator, context=[analysis_task], # 此任务依赖于分析任务的结果 expected_output="一个包含 {batch_size} 个JSON对象的列表，每个对象都完全符合规范。", output_file="generated_batch.json" # CrewAI支持直接输出到文件 ) # 任务3：质量审核 validation_task = Task( description="审核文件 '{input_file}' 中的每一条数据。依据《数据生成规范》，检查字段完整性、格式正确性、逻辑合理性。将审核结果分为‘通过’、‘修正’、‘拒绝’三类，并给出简要理由。只输出‘通过’的数据。", agent=quality_inspector, context=[analysis_task], # 审核也需要依据规范 expected_output="一个只包含‘通过’审核的数据的JSON列表，文件名为 'validated_{input_file}'。", )

3.3 编排流程与执行引擎

最后，我们需要一个“船长”（Crew）来把智能体和任务组织起来，并定义他们的工作流程。

from crewai import Crew, Process # 创建 Crew data_factory_crew = Crew( agents=[requirements_analyst, data_generator, quality_inspector], tasks=[analysis_task, generation_task, validation_task], # 这里是简化示意，实际生成任务会循环 process=Process.sequential, # 顺序执行：分析 -> 生成 -> 审核。对于批量，可以设计更复杂的流程。 verbose=2, # 输出详细执行日志 ) # 执行Crew（这是一个简化的一次性执行） # 在实际72小时运行中，这里是一个复杂的循环控制逻辑 result = data_factory_crew.kickoff(inputs={"user_input": "生成关于智能家居设备抱怨的数据集..."}) print(result)

然而，一次性的kickoff无法满足我们持续运行72小时、生成上千条数据的需求。我们需要自己编写外层的流程控制器。这个控制器负责：

1. 接收最终的用户需求。
2. 启动需求分析任务，得到规范。
3. 根据规范中的总条数（如1065条），决定分批策略（比如每批50条）。
4. 循环执行：为每一批数据创建一个新的“生成任务” -> 执行 -> 将生成结果保存为临时文件 -> 创建一个针对该临时文件的“审核任务” -> 执行审核 -> 将审核通过的数据追加到最终数据集文件。
5. 监控进度、处理异常（如模型调用失败）、记录日志。
6. 达到目标数量后，停止循环，生成最终报告。

这个控制器是项目真正的“大脑”，它用Python脚本实现，利用CrewAI的API来动态创建和提交任务，而不是依赖Crew的一次性编排。

4. 核心挑战与优化策略实录

4.1 提示词工程：从“粗略”到“精确”

最初的失败几乎都源于糟糕的提示词。让模型生成“一条用户抱怨”，它可能会给你一段自由的、格式不定的文字。我们的目标是结构化的JSON。提示词的质量直接决定了输出数据的质量和系统的稳定性。

第一版（粗糙，失败率高）：

请生成一条用户对智能家居设备的抱怨。

结果：模型自由发挥，格式千奇百怪，无法解析。

最终版（精确，通过率>95%）：

{ “instruction”: “你是一个高质量数据生成器。请严格按照以下要求生成一条数据：”, “requirements”: { “fields”: [ {“name”: “user_id”, “type”: “string”, “format”: “前缀‘USER_’后接6位数字，如 USER_123456”, “generation_rule”: “随机生成，不重复”}, {“name”: “device_type”, “type”: “string”, “enum”: [“智能音箱”, “智能灯泡”, “智能门锁”, “智能 thermostat”, “扫地机器人”]}, {“name”: “complaint_text”, “type”: “string”, “constraints”: “长度在15到50字之间，描述一个具体、真实的问题，例如‘唤醒词经常识别失败’而非‘不好用’”}, {“name”: “sentiment”, “type”: “string”, “enum”: [“正面”, “负面”, “中性”], “logic_link”: “必须与complaint_text描述的问题在情感上一致”}, {“name”: “severity”, “type”: “integer”, “range”: [1, 5], “logic_link”: “通常，‘负面’情感对应 severity>=3；‘正面’对应 severity<=2；‘中性’对应 severity=3。但也允许合理例外。”} ], “output_format”: “你必须输出且仅输出一个合法的JSON对象，键名与上述字段名完全一致。不要有任何额外解释。” }, “examples”: [ {“user_id”: “USER_654321”, “device_type”: “智能音箱”, “complaint_text”: “在嘈杂环境下，即使大声喊唤醒词也经常没反应。”, “sentiment”: “负面”, “severity”: 4}, {“user_id”: “USER_111223”, “device_type”: “智能灯泡”, “complaint_text”: “颜色切换很平滑，但预设的‘阅读模式’色温我觉得偏冷。”, “sentiment”: “中性”, “severity”: 3} ] }

优化心得：

1. 结构化约束：使用类JSON的格式在提示词中明确字段定义、类型、枚举值、格式和逻辑关系。模型对结构化的指令理解得更好。
2. 提供示例：Few-shot learning至关重要。提供1-3个完美的输出示例，能极大提高模型输出的格式符合率。
3. 输出格式强制：使用“你必须输出且仅输出一个合法的JSON对象”这样强硬的措辞，并在审核环节严格检查，逐步“训练”模型遵守规则。
4. 逻辑链接：在字段定义中加入logic_link，明确不同字段间的约束，让模型生成的数据在逻辑上更自洽。

4.2 稳定性保障：错误处理与重试机制

让一个系统无人值守运行72小时，稳定性是首要问题。网络波动、Ollama服务内存溢出、模型响应超时或返回非预期内容，都是家常便饭。

我的错误处理策略：

1. 指数退避重试：对于网络超时或服务暂时不可用（HTTP 5xx错误），实现重试逻辑。第一次失败后等待1秒重试，第二次失败等待2秒，第三次等待4秒……最多重试5次。

   import time import requests from tenacity import retry, stop_after_attempt, wait_exponential @retry(stop=stop_after_attempt(5), wait=wait_exponential(multiplier=1, min=1, max=60)) def call_ollama_with_retry(prompt): # 调用Ollama API的代码 response = requests.post(...) response.raise_for_status() # 如果状态码不是200，会抛出异常，触发重试 return response.json()

2. 响应内容校验：即使API调用成功，返回的内容也可能是无效的（如模型“胡言乱语”）。在将数据交给审核智能体之前，先做一层语法防火墙：用try-except包裹json.loads()，捕获所有JSON解析错误。解析失败的数据直接丢弃或触发一次“重新生成”该条数据的任务。
3. 批次隔离与状态持久化：不要一次性把所有任务扔进队列。采用“小批次”策略，比如每生成和审核完20条数据，就将这20条成功数据立即写入磁盘，并记录当前进度。这样即使程序在运行到第50小时崩溃，重启后可以从最近的检查点恢复，而不是从头开始。
4. 资源监控：编写一个简单的监控脚本，定期检查Ollama进程的内存和CPU占用。如果发现内存持续增长（可能内存泄漏），则自动重启Ollama服务。同时，监控生成和审核的通过率，如果通过率在某一时间段内骤降，可能意味着模型状态不佳或提示词出了问题，系统应发出警报（如记录到错误日志文件）并暂停。

4.3 效率提升：并行化与模型分工

串行执行“生成一条 -> 审核一条”效率极低。我的优化方法是：

1. 生成与审核并行：这是最大的性能提升点。我使用Python的concurrent.futures线程池或asyncio库。维护两个队列：生成队列和审核队列。启动多个“生成工作线程”不断从生成队列取任务（生成N条数据），完成后将数据块放入审核队列。同时，启动多个“审核工作线程”从审核队列取数据块进行审核。这样，生成和审核可以同时进行。
2. 模型分级调用：并非所有任务都需要最强大的模型。我的配置是：
   • 需求分析：使用能力较强的模型（如llama3:70b），因为这一步需要深度理解。
   • 数据生成：使用速度较快的模型（如llama3:8b或mistral:7b），在保证格式正确的前提下，追求吞吐量。
   • 质量审核：使用最严谨、推理能力最强的模型（如llama3:70b或专门调优过的审核模型），但可以适当降低其temperature（如0.1）使其判断更稳定。审核任务量通常是生成任务量的一半（因为不是每条都需要复杂审核），所以对整体速度影响可控。
3. 批次处理：不要一次只让模型生成1条数据。通过精心设计提示词，可以让模型一次生成一个包含5-10条数据的JSON数组。这能大幅减少HTTP请求和上下文切换的开销。同理，审核也可以批量进行。

5. 成果分析、问题排查与未来展望

5.1 72小时运行成果深度分析

经过72小时的不间断运行，系统成功生成了1065条通过最终审核的数据条目。以下是一些关键指标和分析：

数据集质量评估：我随机抽取了100条数据进行了人工复核。发现：

• 格式正确率：100%。所有数据均为完美JSON，字段齐全。
• 逻辑自洽率：约93%。有7条数据存在轻微逻辑问题（例如，抱怨文本是“设备完全无法连接”，但情感被标记为“中性”）。这提示审核模型的提示词还可以进一步强化逻辑约束。
• 内容多样性：良好。通过在设计提示词时要求“从不同角度、不同场景描述问题”，并让生成器在每批任务中使用不同的随机种子，有效避免了数据模式僵化。

5.2 典型问题与排查记录

在72小时运行中，遇到了形形色色的问题，以下是排查记录：

问题一：运行到第40小时，数据生成速度突然变慢，最后卡住。

• 现象：日志显示Ollama API调用超时。
• 排查：登录服务器，运行ollama list查看模型状态正常。但通过nvidia-smi发现GPU内存几乎占满。
• 原因：Ollama在长时间处理大量请求后，可能没有完全释放缓存，导致显存泄漏。
• 解决：
  1. 临时：写一个脚本定时重启Ollama服务（例如每生成500条数据后）。
  2. 优化：在调用Ollama API时，显式地在请求头中设置"keep_alive": "-1"或一个较短的时间，告诉服务端不要长时间保留模型上下文。同时，尝试使用Ollama的show命令查看模型配置，调整num_ctx（上下文长度）参数，避免设置过大。

问题二：审核环节误杀率突然升高。

• 现象：某一批次的数据，审核通过率从85%骤降到40%。
• 排查：检查该批次生成和审核的日志。发现生成环节的提示词文件因误操作被覆盖成了一个旧版本，其中缺少了关键的“输出格式”强调。
• 原因：生成数据格式变差，导致即使内容合格，也因格式问题被审核员拒绝。
• 解决：立即停止该批次任务，恢复正确的提示词文件，并让系统从上一个检查点重新生成该批次数据。教训：所有配置文件、提示词模板都应纳入版本控制（如Git），并在每次任务启动前进行校验。

问题三：生成的数据出现“重复模式”。

• 现象：连续几十条数据中，user_id的后几位数字呈现明显的递增规律，complaint_text的句式雷同。
• 原因：LLM在缺乏随机性注入时，容易陷入某种输出模式。虽然我们要求“随机”，但模型对“随机”的理解可能只是基于上下文的微小变化。
• 解决：
  1. 在给生成模型的系统提示词（system prompt）中，加入“请充分发挥创造力，确保每条数据在表述上都有显著差异”。
  2. 在每批生成任务的用户提示词（user prompt）中，加入一个随机种子或变化因子，例如“请想象今天是2023年{random_month}月{random_day}日，用户在不同时间遇到了问题”。
  3. 定期（如每200条）轻微调整生成提示词中的示例，给模型新的刺激。

5.3 扩展思路与未来优化方向

这次实验验证了用CrewAI+Ollama构建自动化数据流水线的可行性。基于此，还有更多可以探索的方向：

1. 引入“数据增强”智能体：在生成和审核之后，增加一个“数据增强”环节。这个智能体可以对通过审核的基-础数据进行变换，如同义词替换、句式改写、添加无害的噪声等，在不改变语义的前提下扩充数据集多样性，这对于训练更鲁棒的NLP模型尤其有用。
2. 实现动态难度调整：系统可以监控审核通过率。如果通过率持续高于某个阈值（如90%），说明生成任务太简单，可以自动调高生成提示词的难度（例如要求生成更复杂、更边缘的案例）。反之，则调低难度，保证产出效率。
3. 与向量数据库结合：将已生成的数据实时存入向量数据库（如Chroma、Weaviate）。在生成新数据前，先进行向量相似度检索，如果发现与已有数据过于相似，则要求生成器重新生成或修改。这能从根源上降低数据重复率。
4. 多模态数据生成：Ollama也开始支持一些多模态模型。这套架构可以扩展，例如，让一个智能体生成描述图片的文本提示词，另一个智能体调用文生图模型（如Stable Diffusion）生成图片，第三个智能体审核图文匹配度，从而构建图文对数据集。

构建这个系统的过程，更像是在设计和运营一个数字工厂。每一个智能体是一个工位，提示词是操作手册，任务流是生产线，而Ollama提供的模型则是生产设备。调试的过程就是优化生产线、培训员工、维护设备。当这个工厂能够稳定、高效地生产出符合标准的产品时，那种成就感远超手动收集数据。它解放了我的双手，让我可以去思考更本质的问题：我到底需要什么样的数据？以及如何设计更好的“工厂蓝图”。