Open-Assistant 知乎 KOL 问答数据集构建指南爬取、清洗、转换与上传全流程【免费下载链接】Open-AssistantOpenAssistant is a chat-based assistant that understands tasks, can interact with third-party systems, and retrieve information dynamically to do so.项目地址: https://gitcode.com/gh_mirrors/op/Open-Assistant导读本文围绕 Open-Assistant 项目中的中文高质量问答数据源 Zhihu KOL 数据集卡片 展开完整讲解如何从知乎抓取 KOL关键意见领袖的问答内容将其转换为 Open-Assistant 训练管线可直接消费的 Instruction 格式并以 Parquet 形式发布到 Hugging Face Hub。读完本文你将掌握单用户 url_token 爬取、圆桌话题批量爬取、数据格式转换、质量过滤与上传发布的全套实战方案并能将这套流程复用到其他中文问答站点或社区数据的采集任务中。数据集概览为什么需要知乎 KOL 问答数据背景与定位Open-Assistant 旨在训练一个能够理解任务、与第三方系统交互并动态检索信息的对话式助手。高质量、多样化的训练数据是其核心燃料仓库根目录的 data/datasets/README.md 明确指出该仓库致力于提供可用于训练 OpenAssistant 模型的多样化、易获取的数据集集合覆盖广泛的主题、语言与任务。知乎Zhihu是中国最流行的问答社区天然包含海量的「问题—回答」二元组这与 Instruction 数据集的形态高度契合。本数据集当前阶段聚焦 KOLKey Opinion Leader意见领袖的回答原因在于KOL 回答通常更长、更结构化、信息密度更高更适合作为监督微调的目标输出KOL 内容的点赞数等互动指标可以反哺元数据如回答质量筛选项目计划后续逐步扩展到更广泛的话题和普通用户内容当前版本只收录 KOL 数据作为起步。从仓库注册表 data/datasets/init.py 可以看到zhihu-kol已被注册到INSTRUCTION_DATASETS字典中对应 Hugging Face 仓库wangrui6/zhihu-kol即该数据集已经进入 Open-Assistant 的正式指令数据集清单。数据形态示例数据集的「问题—回答」对直接以中文呈现例如 README 中给出的两个典型样本Q: ChatGPT 这个项目会开源吗 A: 别开源了开源就有中国名字了: HarmonyGPT.2014年6月21日特斯拉公司在全球范围内公开了271项专利... Q: TensorFlow 真的要被 PyTorch 比下去了吗 A: 当我找到一个tf的代码我的第一反应就是这货大概率跑不起来.这类样本真实反映了社区用户的提问风格和 KOL 的个性化回答风格是训练中文指令跟随能力尤其是互联网技术话题的天然语料。环境准备依赖安装与 Playwright 浏览器开始抓取前需要准备两件事Python 依赖和 Playwright 无头浏览器。安装 Python 依赖项目提供了完整的依赖清单 data/datasets/zhihu-kol/requirements.txt直接安装即可pip install -r requirements.txt其中与抓取链路直接相关的核心依赖包括依赖版本用途playwright1.31.0无头浏览器驱动用于圆桌话题页面渲染与链接采集requests2.28.2知乎 API 与页面请求beautifulsoup44.11.2HTML 解析提取回答正文pandas1.5.3数据表处理与 CSV 输出pyarrow11.0.0Parquet 格式转换datasets2.10.0Hugging Face 数据集加载与上传huggingface-hub0.12.1HF Hub 推送底层支持multitasking0.0.11多任务并发抓取回答内容retry0.9.2网络请求自动重试tqdm4.64.1抓取进度可视化loguru0.6.0圆桌抓取日志记录注意requirements.txt中还捆绑了大量 Jupyter/科学计算依赖如jupyter、matplotlib、tensorboard等实际生产抓取时可按需裁剪。安装 Playwright 浏览器及系统库playwright install若系统缺少浏览器运行所需的基础库需要补充安装以 Ubuntu/Debian 为例sudo apt-get install libatk1.0-0 libatk-bridge2.0-0 libcups2 libatspi2.0-0 libxcomposite1 libxdamage1 libxfixes3 libxrandr2 libgbm1 libxkbcommon0 libpango-1.0-0 libcairo2 libasound2这些库为 Chromium 在无头headless模式下渲染页面所必需缺少时 Playwright 会因启动浏览器失败而报错。注意在scrape_by_topic.py中浏览器以headlessFalse有头模式启动这是因为知乎页面需要真实浏览器环境来通过部分反爬校验。单用户抓取基于 url_token 的 KOL 回答采集url_token 与 uid 的获取知乎用户的个人主页 URL 形如https://www.zhihu.com/people/la-ge-lang-ri-96-69其中最后一段la-ge-lang-ri-96-69即为该用户的url_token。抓取的第一步是将其转换为 API 所需的数字uid。main.py 中的get_uid_by_url_token函数实现这一转换它构造一组模拟浏览器请求的 headers包含user-agent、x-requested-with: fetch、origin、referer等字段请求https://api.zhihu.com/people/{url_token}并从响应的 JSON 中提取id字段url https://api.zhihu.com/people/ url_token response requests.get(url, headersheaders) uid response.json()[id]由于知乎对无登录 API 请求存在限流该函数未做重试保护若调用失败get_user_answers外层会捕获异常并返回空 DataFrame脚本随后打印「url_token 可能有误!」并退出。拉取用户回答元数据列表get_user_answers(url_token, max_count100000)是单用户抓取的核心。它使用 iOS 端请求头模拟知乎 App 客户端调用分页接口url fhttps://api.zhihu.com/members/{uid}/answers params ((limit, 20), (offset, str(offset)))关键行为包括分页逻辑每页limit20条通过offset递增翻页直到offset total或超过max_count默认 100000即几乎不设上限时停止自动重试函数上装饰了retry(tries3)网络异常时最多重试 3 次字段提取通过operations映射表从原始 JSON 中抽取 9 个字段含嵌套字段列名全部使用中文输出列名来源字段说明作者名称author.nameKOL 显示名作者IDauthor.idKOL 数字 uid作者tokenauthor.url_tokenKOL url_token回答点赞数voteup_count可用于回答质量评估回答时间created_time创建时间戳更新时间updated_time最后更新时间戳回答IDurl末段回答唯一 IDaid问题IDquestion.id问题唯一 IDqid问题内容question.title问题标题文本其中「回答ID」通过x[url].split(/)[-1]从回答链接中截取「问题内容」直接取自问题的 title。该函数返回一个列名均为中文的 pandas DataFrame为后续正文抓取提供索引。抓取回答正文拿到「问题ID 回答ID」后get_answer_content(qid, aid)通过移动端页面请求https://www.zhihu.com/question/{qid}/answer/{aid}再用 BeautifulSoup 解析 HTMLsoup BeautifulSoup(response.text, html.parser) content .join([p.text.strip() for p in soup.find_all(p)])即将页面内所有p段落文本拼接成一段连续文本。需要注意这种粗暴拼接会丢失段落结构与列表、代码块等富文本信息同时 README 示例中可看到回答内容会保留原始换行与排版实际以页面解析结果为准。并发落盘与格式转换save_answers_to_csv将上述两步串联成一个端到端流程调用get_user_answers获取元数据 DataFrame为空则报错返回对每一行「问题ID 回答ID」组合使用multitasking.task装饰的start(qid, aid)并发抓取正文每个任务带retry(tries3)重试通过tqdm显示进度multitasking.wait_for_tasks()等待全部并发任务结束按问题ID回填回答内容源码注释特别强调使用 qid 作为 key确保并发下 qid 与 aid 一一对应调用reformat_csv_to_openassistant转换为 Open-Assistant 标准格式INSTRUCTION← 问题内容RESPONSE← 回答内容SOURCE← 固定为ZhihuMETADATA← JSON 字符串包含「回答点赞数」和「回答时间」两项以encodingutf-8-sig编码写入 CSV带 BOM便于 Excel 等工具直接打开中文内容。脚本主入口默认抓取 url_token 为nicole-97-93的 KOL 并保存为nicole-97-93.csv实际使用时可修改main.py底部的url_token变量# 知乎用户的 url_token # 例如主页为 : https://www.zhihu.com/people/la-ge-lang-ri-96-69 的用户 # 其 url_token 为 la-ge-lang-ri-96-69 # url_token la-ge-lang-ri-96-69 url_token nicole-97-93 # 回答数据保存路径 csv_path url_token .csv # 调用函数获取数据 save_answers_to_csv(url_token, csv_path)运行命令对应 README 的「Download data based on single KOL url token」python main.py圆桌话题批量抓取Playwright 端到端自动化单用户模式需要逐个提供 url_token扩展性有限。为此 scrape_by_topic.py 提供了基于知乎「圆桌」roundtable话题的批量抓取方案README 对应命令为python scrape_by_topic.py抓取思路圆桌是知乎围绕某一主题聚合问答的专题页面如科技、职场等页面中包含大量与主题相关的问题和回答链接。脚本借助 Playwright 的真实浏览器能力实现端到端自动化核心流程如下进入圆桌列表页page.goto(https://zhihu.com/roundtable)通过roundtable_topic_scrolldown 20次End键滚动加载更多圆桌主题每次滚动后wait_for_timeout(1000)提取主题链接get_all_href(page)使用page.evaluate执行页面内 JS收集全部href过滤出包含https://www.zhihu.com/roundtable/的链接并np.random.shuffle随机打乱顺序跳过早期主题starting_offset 4跳过列表前 4 个主题——源码注释说明早期圆桌话题可能尚未正式开始偏移量是任意设定的逐主题进入对每个主题页收集所有href从中过滤出含/people/的用户主页链接scrape_people_roundtable函数会将其累计写入people.csv用于反推 KOL 名单逐问题抓取回答end_to_end_auto_scrape函数进一步遍历主题页上的问题链接过滤掉含waiting的未开始问题进入每个问题页用.QuestionHeader-title选择器读取问题标题在.QuestionAnswers-answers容器内收集所有href用正则r/question/\d/answer/\d匹配出「问题ID/回答ID」对对每个回答调用get_answer_content(qId, aId, question_title)抓取正文任务间time.sleep(1)限速以降低封禁风险增量落盘每处理完一个主题就把累积的 payload 用pd.json_normalize展平并写入zhihu.csv做到边抓边存、断点可续。富化的回答数据结构圆桌流程使用的get_answer_content返回的是Content_Data数据类字段比单用户版本更丰富dataclass class Content_Data: question_id: int answer_id: int author_id: str question_title: str content: str upvotes: str answer_creation_time: str其中额外字段的提取方式体现了对页面元数据的挖掘回答创建时间从meta itempropdateCreated标签中读取源码注释说明经在线页面人工核对该 meta 内容即回答创建时间点赞数查找classButton VoteButton VoteButton--up按钮文本并清理零宽字符\u200b作者 ID遍历meta itempropurl标签筛出 content 中含/people/的那一个。这些字段在后续 Parquet 转换时会被写入 METADATA为数据筛选例如按点赞数过滤低质量回答提供依据。有头模式的取舍脚本中headless False即 Playwright 以有头模式运行。虽然无头模式更省资源但知乎对纯无头浏览器的反爬识别更严格有头模式配合真实 UA 能显著提高抓取成功率。代价是需要图形环境桌面或带显示的容器在纯服务器上运行可能需要配合xvfb之类的虚拟显示方案这一点在 README 中并未展开属于从代码推断的部署注意事项。数据标准化转换为 Open-Assistant Parquet 格式抓取产物是 CSVzhihu.csv或{url_token}.csv而训练管线需要标准化的 Parquet 文件。convert_parquet.py 完成这一转换对应 README 命令python convert_parquet.pyInstruction 格式规范根据 data/datasets/README.md 的统一定义Instruction 数据集必须包含以下列INSTRUCTION字符串指令文本此处即知乎问题标题RESPONSE字符串期望的回复此处即 KOL 回答正文SOURCE字符串原始数据源简称此处固定为ZhihuMETADATAJSON 字符串可选其他有用信息如 NSFW 标记{nsfw: true}。同时仓库对数据格式有硬性要求所有数据必须是 UTF-8 编码存储为 Parquet 时必须使用row_group_size100且indexFalsejsonl / jsonl.gz 亦可。转换实现reformat_csv_to_openassistant将圆桌抓取的 CSV 映射为标准四列METADATA 中保留 5 个溯源字段new_df[METADATA] df.apply( lambda x: json.dumps( { question_id: x[question_id], answer_id: x[answer_id], author_id: x[author_id], upvotes: x[upvotes], answer_creation_time: x[answer_creation_time], }, ensure_asciiFalse, ), axis1, )值得注意的是转换阶段还内置了一道质量过滤new_df new_df[~(new_df[RESPONSE] ) | (new_df[RESPONSE].isna())]该行意图剔除回答内容为空单个空格或缺失的行避免无效样本进入训练集。严格来说按逻辑运算符优先级这里存在一个易混淆点应为「剔除 RESPONSE 为空格或为 NaN 的行」但从意图看这是一道明确的数据清洗步骤读者可依据需求自行调整过滤条件。主流程将zhihu.csv读入转换后写为 Parquetdf pd.read_csv(input_csv) df reformat_csv_to_openassistant(df) df.to_parquet(dataset.parquet, row_group_size100, enginepyarrow, indexFalse)这正好与 data/datasets/README.md 给出的全仓库统一 Parquet 转换范式df.to_parquet(dataset.parquet, row_group_size100, enginepyarrow, indexFalse)完全一致说明该数据集严格遵守了 Open-Assistant 的数据规范。发布到 Hugging Face上传数据集上传脚本upload_hf.py 极其精简仅 4 行from datasets import Dataset ds Dataset.from_parquet(dataset.parquet) ds.push_to_hub(wangrui6/zhihu-kol)Dataset.from_parquet将 Parquet 加载为 HF Datasets 对象push_to_hub将其推送到wangrui6/zhihu-kol仓库与 data/datasets/init.py 注册表中的目标一致。对应 README 命令python upload_hf.py前置登录与规范要点在执行上传前需要先完成 Hugging Face 身份认证。依据 data/datasets/README.md 的通用流程pip install huggingface_hub huggingface-cli login # 使用你的 access token 登录登录成功后运行上传脚本即可。注意push_to_hub需要写入权限的 tokenWrite 级别只读 token 无法完成推送。另外两个需要留意的仓库规范数据集许可数据集必须具有宽松许可证permissive license隐私红线不得包含儿童性虐待材料不得包含个人隐私信息姓名、地址、电话、政府 ID、医疗信息等。知乎 KOL 回答属于社区公开内容但抓取与再发布时仍应自行评估内容合规性与授权边界——这是 README 未明说但值得实践者关注的事项。与训练管线的衔接数据集如何被消费该数据集并非孤立存在它已经被 Open-Assistant 的训练代码正式引用。在 model/model_training/custom_datasets/instruction.py 的INSTRUCTION_DATASETS注册表中可以看到zhihu-kol: {dataset_path: wangrui6/zhihu-kol},InstructionDataset 加载逻辑训练端通过InstructionDataset类消费该数据集其关键行为包括列名约定默认读取INSTRUCTION与RESPONSE两列构造函数参数instruction_columnINSTRUCTION、response_columnRESPONSE这正好对应本数据集转换脚本产出的列名空值过滤加载时丢弃q/a为空或 strip 后长度为 0 的样本并统计num_invalid打印警告词级过滤调用_filter_by_words对问题与回答进行单词级过滤见 model/model_training/custom_datasets/utils.py剔除不适合训练的内容随机打乱与拼包以seed42打乱样本顺序并按fill_min_length将多条问答拼接成训练块block满足 SFT 的序列长度要求数据格式适配__getitem__通过create_dataset_entry_qa(mode..., questions..., answers..., lang...)生成DatasetEntry。注意注册表中zhihu-kol未指定lang字段对比recipes、grade_school_math_instructions等显式标注了lang: en因此中文内容不会被子采样逻辑按语言过滤——从源码结构可以推断该数据集在训练时按默认语言处理路径参与混入。数据流总结至此整个「知乎 KOL 问答数据」从采集到训练的全链路可以概括为知乎页面/API │ main.py / scrape_by_topic.pyrequests Playwright BeautifulSoup ▼ CSV中文列名 or Content_Data 结构 │ convert_parquet.pyreformat 空内容过滤 ▼ dataset.parquetINSTRUCTION / RESPONSE / SOURCE / METADATA │ upload_hf.pypush_to_hub ▼ HF Hub: wangrui6/zhihu-kol │ model_training/custom_datasets/instruction.pyInstructionDataset ▼ Open-Assistant SFT/RL 训练管线这条链路完整覆盖了 Open-Assistant 数据贡献规范data/datasets/README.md中「创建数据集 → 转 Parquet → 登录 HF → 推送 → 注册到__init__.py」的每一步zhihu-kol已注册在 data/datasets/init.py 的INSTRUCTION_DATASETS中是一个端到端跑通的中文指令数据范例。总结与扩展建议围绕 data/datasets/zhihu-kol/README.md 描述的知乎 KOL 数据集仓库提供了两套互补的抓取方案单用户模式main.py适合已确定 KOL 名单、按人精准采集输出含 9 个中文元数据列的 CSV圆桌批量模式scrape_by_topic.py适合冷启动阶段从圆桌话题自动发现问题与回答通过 Playwright 有头浏览器规避反爬边抓边存。两条路径最终都汇入统一的 Open-Assistant Instruction 标准格式经 Parquet 化后上传 HF并被训练管线原生消费。若需扩展该方案可以关注以下几个方向扩充 KOL 名单结合scrape_people_roundtable产出的people.csv积累更多作者再回灌到main.py逐个精抓丰富元数据Content_Data中的upvotes可作为回答质量的代理指标在convert_parquet.py中按阈值过滤低互动内容补充格式规范当前正文提取仅拼接p文本若需要代码块、公式等富文本结构可基于 BeautifulSoup 进一步增强解析规则合规与隐私数据再发布前需自行评估知乎内容的使用授权与个人信息脱敏。对于希望在 Open-Assistant 上复刻中文问答数据采集流程的开发者本数据集从抓取、清洗、转换到发布的完整代码main.py、scrape_by_topic.py、convert_parquet.py、upload_hf.py提供了可直接参考或移植的成熟范式。【免费下载链接】Open-AssistantOpenAssistant is a chat-based assistant that understands tasks, can interact with third-party systems, and retrieve information dynamically to do so.项目地址: https://gitcode.com/gh_mirrors/op/Open-Assistant创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考